No description
Find a file
2025-12-08 07:35:54 +01:00
src new b ranges also count as something new 2025-12-08 06:57:24 +01:00
.gitignore more files 2025-12-04 15:52:13 +01:00
.vimrc build using Docker 2025-12-05 10:03:05 +01:00
.zshrc build using Docker 2025-12-05 10:03:05 +01:00
build.sh make sure Dockerfile rebuilds when there is a new version available 2025-12-07 11:48:25 +01:00
Dockerfile make sure Dockerfile rebuilds when there is a new version available 2025-12-07 11:48:25 +01:00
LICENSE LICENSE 2025-12-04 15:36:37 +01:00
README.md README: build on Linux 2025-12-08 07:35:54 +01:00
run.sh run.sh: commented out command to update the work repo 2025-12-07 11:58:59 +01:00
setarch.sh build using Docker 2025-12-05 10:03:05 +01:00

AutoFW

This tool is inspired by fail2ban, but is simpler and less forgiving. There are no configuration files, and addresses stay blocked until they are explicitly removed. You provide it with a list of whitelisted and blacklisted IP addresses and ranges, and its output is a list of commands to blacklist slightly larger IP ranges covering multiple IP addresses.

It assumes UFW for now.

Examples

  • For a.b.c.0 and a.b.c.1 you will get a block on a.b.c.0/31.
  • For a.b.c.0 and a.b.c.255 you will get a block on a.b.c.0/24.
  • If there are at least 4 blacklisted IP blocks on the form a.b.z.0, for multiple values of z, you will also get a block on a.b.0.0/16.

Building

On a Linux machine.

  • The Dockerfile shows which tools and libraries are needed, even though in your particular Linux distribution the packages may be called something else.
  • Then go to the src directory and run cmake . and make.

On a non-Linux machine.

Here we use Docker.

  1. Install the Docker command line client on your machine.
  2. Run ./build.sh. This will build a binary for aarch64 or x84_64, depending on your host.
  3. You can add the parameter arm or x86 to the ./build.sh script to build for a particular architecture, if your host machine supports that.
  4. The result will be a binary in the bin sub directory.
  5. You can then run ./run.sh for an interactive environment. In this case the full repo will be copied to new repo-x directory (where x depends on the architecture), so your changes do not disappear when the Docker container exits. This script also takes the parameter arm or x86.

Usage

First you create a file autofw.whitelist, containing IP addresses and ranges that should always be allowed to connect to your server.

Then create a script that performs the tasks below. This can be run by cron.

  1. Collect all IP addresses and ranges to block into a new file, say autofw.badips. It may be a good idea to filter out entries in the whitelist.
  2. Run ufw insert 1 deny from $ip for each entry in autofw.badips. The ufw tool will automatically ignore duplicates.
  3. Collect all blacklisted addresses using the following command: ufw status verbose | grep "DENY IN" | awk '{print $4}' > autofw.blacklist
  4. Run ./autofw > ufw.updates.
  5. Run the ./ufw.updates script.
  6. Finally run ufw reload to activate the new rules.

Both the whitelist and blacklist can contain both individual IP addresses and ranges on the form a.b.c.d/e, where e is between 0 and 32. In our own installation at Braxo we also sort the list of bad IP addresses and remove duplicates, between steps 1 and 2. This way we can easily know if something has changed, or if we can just skip the rest of the steps.

To block machines trying to attack your SMTP server sending invalid commands, you can use a command such as the one below. Then simply add additional commands as needed, based on your own log files from whatever applications you are running.

cat /var/log/mail.log |
	grep 'non-SMTP command' |
	awk '{print $8}' |
	tr '[]' ' ' |
	awk '{print $2}' >> autofw.badips

If you run ufw insert 1 deny from x.y.z.w manually at some point, that IP will stay blocked. It will then possibly be merged with any of the other blocked IP addresses.

The output from ./autofw is a list of UFW commands. Here we assume we have blocked a.b.c.115 and a.b.c.116, and whitelisted e.f.g.h. The reason we first delete the rule for e.f.g.h and then add it back, is to make sure it comes first. This way whitelisted addresses can never be blocked.

yes | ufw delete deny from a.b.c.115/32
yes | ufw delete deny from a.b.c.116/32
ufw insert 1 deny from a.b.c.112/29
yes | ufw delete allow from e.f.g.h/32
ufw insert 1 allow from e.f.g.h/32

TODO

  • Better git/ssh setup.
  • IPv6
  • Other firewall backends, such as raw iptables.