Running rootless fail2ban on debian
Where possible we prefer to run services as a non-root user. fail2ban also supports this, however the run-rootless.txt docs don't fully detail all the necessary steps.
Some of the steps are explained in the /etc/default/fail2ban
config script. In addition to these a few other steps are needed. Below are all the steps to get a working rootless fail2ban on debian wheezy.
- Edit
/etc/default/fail2ban
- set the variable on the last line
FAIL2BAN_USER="fail2ban"
- set the variable on the last line
- Run the command to create the user
useradd --system --no-create-home --home-dir / --groups adm fail2ban
- Edit your
/etc/fail2ban/jail.local
with the overrides for your local environment.- The key argument here is the
banaction
. - Add any other trusted IP's to the
igonreip
setting.
- The key argument here is the
[DEFAULT]
banaction = iptables-xt_recent-echo
ignoreip = 127.0.0.1/8 10.1.1.0/24
bantime = 3600
destemail = ops@domain.org
chain = F2B
- Add the following line to
/etc/fail2ban/action.d/iptables-xt_recent-echo.local
- Since fail2ban runs as a non-root user it won't be able to add the necessary iptables "recent" module entry. We'll add this manually later.
[Definition]
actionstart =
- Set up iptables with lines such as the following.
- NOTE THIS IS NOT A COMPLETE IPTABLES RULE SET, ONLY THE LINES FOR FAIL2BAN!!
- These tell iptables to use the "recent" module to look for IP's from which it will drop the packets. The table referenced is
/proc/net/recent/fail2ban-ssh
as referenced by the --name argument. This is the file fail2ban will add IP's to, and iptables will be responsible for removing these IP's after the --seconds timeout.
$IPTABLES -N F2B
$IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -j F2B
$IPTABLES -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT
$IPTABLES -A FORWARD -i eth0 -p tcp --dport 22 -j F2B
$IPTABLES -A FORWARD -i eth0 -p tcp --dport 22 -j ACCEPT
$IPTABLES -A F2B -p tcp --dport 22 -m recent --update --seconds 3600 --name fail2ban-ssh -j DROP
$IPTABLES -A F2B -j RETURN
- Restart fail2ban and test
/etc/init.d/fail2ban restart
- If you get the error
Restarting authentication failure monitor: fail2banfind: '/proc/net/xt_recent': No such file or directory
it means you haven't activated the iptables rule with the "recent" module from the previous step.
Written by Jinn Koriech
Related protips
2 Responses
Very helpful - you need to insert a first IPTABLES command for the new chain:
iptables -N F2B
Make sure you only set one "banaction" in /etc/fail2ban/jail.local (if you copied it from jail.conf).
Also change /etc/logrotate.d/fail2ban to work for the non root user.
If you are running the latest dropbear (1.4) not OpenSSH:
Correct the fail2ban regex filter to have capital "L"ogin & "B"ad:in /etc/fail2ban/filter.d/dropbear.conf:
failregex = ^%(__prefix_line)sLogin attempt for nonexistent user ('.*' )?from <HOST>:.*\s*$
^%(__prefix_line)sBad password attempt for .+ from <HOST>:.*\s*$
** Looks like the lastest Dropbear deb package from http://cdn.content-network.net/mirror/apt.balocco.name has now incorporated this correction **
Hey! Thanks for the great article!
How should I formulate the iptables rules for ssh-ddos? I just copied the "$IPTABLES -A F2B -p tcp --dport 22 -m recent --update --seconds 3600 --name fail2ban-ssh -j DROP" rule and changed "fail2ban-ssh" to "fail2ban-ssh-ddos" but I get "2014-03-16 13:52:08,587 fail2ban.actions.action: ERROR echo / > /proc/net/xt_recent/fail2ban-ssh-ddos returned 200" in fail2ban.log when I start fail2ban. Otherwise it seems to work like it should.