github
/
fail2ban
mirror of https://github.com/fail2ban/fail2ban
1
0
Fork 0
Code Issues Releases Wiki Activity

Created Fail2Ban and Docker (markdown)

master
kittonian 2022-02-24 12:04:07 -06:00
parent 791877721b
commit 78d2b834ce
1 changed files with 51 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
Fail2Ban-and-Docker.md Normal file

@ -0,0 +1,51 @@
There are so many tutorials, most inaccurate, regarding best practices with Fail2Ban and Docker environments. Some will suggest running duplicate Fail2Ban instances, while others will tell you to change the default chain across the board to DOCKER-USER. Both of these are bad ideas. Let's look at them both.
**Running Duplicate Fail2Ban instances:**
The idea that you want more server resources used just to accomplish what is a relatively simple task is a bit silly. A single Fail2Ban instance can protect your entire server and there is no need for duplicate instances.
**Changing the default chain to DOCKER-USER:**
While this will protect your docker based software, it will leave any bare metal services wide open (i.e. SSH and often FTP). Again, bad idea.
**The correct way to consider your server protection:**
When you are running both bare metal and Docker based software, you should use the jail.local file to custom configure each jail independently. This way, not only can you provide a specific name for each chain (i.e. f2b-<name>), which will separate out the banned IP addresses, but you can also use the `chain = CHAINNAME` option to specify the IPTables chain in which it should reside.
Let's look at SSH running on the host, and Apache running in a Docker container. Yes, I know I am specifying a very lengthy bantime, but I am a big fan of getting rid of attackers, instead of banning them for a short period of time and then potentially having them come back and try again. Modify these values however you wish. The only two items of note here are the banaction and chain entries.
Remember, you can always manually unban an IP address across all jails with `fail2ban-client unban IPADDR`.
Edit your /etc/fail2ban/jail.local file with the following entries:
```
[DEFAULT]
banaction = iptables-allports[name=fail2ban]
ignoreip = 127.0.0.1/8 ::1
bantime = 8640000
findtime = 3600
maxretry = 3
action = %(action_mwl)s
[apache]
enabled = true
filter = apache-auth
port = http,https
logpath = /path/to/*error_log
banaction = iptables-allports[name=apache]
chain = DOCKER-USER
action = %(action_mwl)s
[sshd]
enabled = true
filter = sshd
port = 22
logpath = /var/log/auth.log
banaction = iptables-allport[name=sshd]
chain = INPUT
action = %(action_mwl)s
```
With this configuration, any IP that is banned due to Apache will be placed in the f2b-apache chain and that jump will be placed at the top of the DOCKER-USER chain. Likewise, any IP that is banned due to SSH will be placed in the f2b-sshd chain and that jump will be placed at the top of the INPUT chain.
Now you are directly protecting the services in which the attack is occurring, rather than trying to manage an all-in-one solution that will either tax your system resources OR not really offer you the protection you want/need.