v0.5.1 - Allow source-IP restrictions on WWTC rules

Summary

This release only includes one small change: you can now specify IP-ranges in wider-world-to-container rules, allowing you to restrict the source from which a service can be reached.

Other than that various dependencies have been updated.

Installation

While you can use Cargo to install dfw as a binary, using the Docker image is the preferred
way to go, especially if you don't want to install Rust and Cargo on your host:

$ docker pull pitkley/dfw:0.5.1
$ docker run -d \
      --name=dfw \
      --restart=unless-stopped \
      -v /var/run/docker.sock:/var/run/docker.sock:ro \
      -v /path/to/your/config:/config \
      --net host --cap-add=NET_ADMIN \
      pitkley/dfw:0.5.1 --config-path /config

This will download a lightweight image, coming in at under 6 MB, and subsequently run it using
your configuration.

v0.5.0 - iptables-restore fixes

Summary

The iptables-restore backend was added in the last release, and as noted, it wasn't as thoroughly tested.

Some more time and testing has shown that there were some bugs with the implementation of the iptables-restore backend. Namely:

• Commands from the initialization section weren't applied.
• Using iptables-restore with the --noflush option is not feasible for our use-case.

Both of these issues have been fixed, with the second one being the important one for the end-user, since the behaviour of the iptables-restore backend has changed from 0.4.0 to 0.5.0! Rather than trying to work around any chains or rules that might exist, DFW now takes over any iptables table it modifies -- i.e. the most important nat and filter.

If you have any externally managed rules in your iptables and are using the iptables-restore backend, these rules will be overwritten without regard. If you need to add rules, use the initialization section of the DFW configuration.

(The iptables backend is unaffected from this change.)

Changes

Changes to the dfw binary

• Added argument --log-level which allows you to specify the verbosity of DFW's logging.

Changes to the dfw library

• The iptables-restore backend now acts flushing (033d27c)
• Removed the unnecessary IPTablesProxy struct (4e62ff2)

_{Internal changes: updated GitLab CI config, updated dependencies, updated tested Docker versions.}

Installation

While you can use Cargo to install dfw as a binary, using the Docker image is the preferred
way to go, especially if you don't want to install Rust and Cargo on your host:

$ docker pull pitkley/dfw:0.5.0
$ docker run -d \
      --name=dfw \
      --restart=unless-stopped \
      -v /var/run/docker.sock:/var/run/docker.sock:ro \
      -v /path/to/your/config:/config \
      --net host --cap-add=NET_ADMIN \
      pitkley/dfw:0.5.0 --config-path /config

This will download a lightweight image, coming in at under 6 MB, and subsequently run it using
your configuration.

v0.4.0 - iptables-restore backend

Summary

This release contains mainly internal stuff, but additionally adds a new backend: iptables-restore. This means that instead of using the iptables binary directly, DFW will use iptables-restore if you specify --iptables-backend iptablesrestore.

The main advantages of iptables-restore in comparison to iptables are:

1. We only need to call out to one process instead of spawning an iptables process for every rule created.
2. A new set of rules replaces the old set atomically, so there is no potential gap in your firewall while DFW is still processing.

_{(Please note: the iptables-restore backend is not as thoroughly tested as the iptables backend!)}

Changes

• Added argument --iptables-backend which allows selection of what backend to use:
  • iptables (default)
  • iptablesrestore
  • iptablesdummy (same as --dry-run)
• Added iptables-restore as a new backend
• Added example configurations
• Extended/updated list of Docker versions tested

_{Internal changes: updated GitLab CI config, cleaned up macros used, updated dependencies.}

v0.3.0 - First release on crates.io

(cargo-release)  version 0.3.0