potential ufw and fail2ban conflicts

Question

Will running both fail2ban and ufw cause problems? I noticed that fail2ban modifies iptables rules, but ufw already has a ton of iptables rules defined... so I'm not sure if fail2ban will mess these up.

Solution 1

You can use ufw and fail2b together, but as indicated earlier, the order of (ufw) rules is what is important.

Out of the box, fail2ban uses iptables and inserts rules first in the INPUT chain. This will not do any harm or conflict with ufw.

If you wish to fully integrate fail2ban to use ufw (rather then iptables). You will need to edit a number of files including

/etc/fail2ban/jail.local

jail.local is where you define your services , including what port they are listening on (think changing ssh to a non-default port) and what action to take.

**Please note*: Never ever edit jail.conf, your changes should be made in jail.local! That file begins with this:

# Changes:  in most of the cases you should not modify this
#           file, but provide customizations in jail.local file,
#           or separate .conf files under jail.d/ directory

Using ssh as an example, note the definition of a non-default port as well =)

[ssh]
enabled = true
banaction = ufw-ssh
port = 2992
filter = sshd
logpath = /var/log/auth.log
maxretry = 3

You then configure fail2ban to use ufw in (one .conf file for each service)

/etc/fail2ban/action.d/ufw-ssh.conf

The syntax is

[Definition]
actionstart =
actionstop =
actioncheck =
actionban = ufw insert 1 deny from <ip> to any app OpenSSH
actionunban = ufw delete deny from <ip> to any app OpenSSH

Note: You configure fail2ban to use ufw and to insert new rules FIRST using the "insert 1" syntax. The delete will find the rule regardless of order.

There is a nice blog post that goes into more detail here

http://blog.vigilcode.com/2011/05/ufw-with-fail2ban-quick-secure-setup-part-ii/

[EDIT] For ubuntu 16.04+

by default a "defaults-debian.conf" in /etc/fail2ban/jail.d with content

[sshd]
enabled = true

will activated a the ssh protection of fail2ban.

You need to put it at false.

Then create a jail.local like you would do in general, mine would be like this:

[ssh-with-ufw] 
enabled = true 
port = 22 
filter = sshd 
action = ufw[application="OpenSSH", blocktype=reject] 
logpath = /var/log/auth.log 
maxretry = 3

There is already a ufw.conf in the fail2ban default installation so no need to create one.

The only specific change for you jail.local would be at action line where you need to put the application concerned for the protection and what you want to get as result.

ufw tend to detect automatically a certain amount of app running using the network. To have the list just type sudo ufw app list. It's case-sensitive.

reload fail2ban and you'll no longer see the fail2ban chain and if any IP get a block you'll see it in sudo ufw status

Solution 2

Installing 0.9.5 of fail2ban included a ufw action which I simply had to to set for the banaction

Solution 3

I have been using fail2ban and ufw for years on couple of different computers, and never had any problems. To setup fail2ban:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local
sudo nano jail.local

Now edit the file as you wish, for example if you want to block unauthorized ssh find the lines:

[ssh]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

if "enabled" is set to "false", change it to "true" as noted here. After you set the rules you need to restart the fail2ban process:

sudo /etc/init.d/fail2ban restart

If you've opened the port 22 on your ufw firewall fail2ban will ban the clients that try to connect more than 6 times without success, it will not break your firewall.

Comments

[david6]

Which Ubuntu version? ('ufw' has improved slightly between 10.04 LTS and 11.x)

[Johnny1am]

@david6: sorry, I don't recall what version I was running when I originally asked the question.

[Sathish]

So in short: without doing the integration as explained, both ufw and fail2ban work like they should. Fail2ban will insert its blocking definitions before ufw's rules are applied. On the other hand if one would like to have the blocks show up in ufw status, you need the integration. Besides having the blocks show up in ufw status, there would be no other benefit? Particularly because the author of the blog says the following: Out of the box Fail2ban works with iptables rules, however these don’t play nice with our simpler UFW commands(...)

[Panther]

Exactly. "Don't play nice" equates to do not show up when you check them with ufw status. The benefits of integration are that you are using one tool , ufw, to manage and display your firewall rules. Nothing wrong with using fail2ban as is, out of the box, in terms of function. The problem would be that to see fail2ban rules you would need to use iptables -L -v -n , and as you can already see, when using ufw the output is long and difficult to follow. The advantage of integration is that the rules and the syntax is then easier to understand (assuming that is why you use ufw in the first place)

[Antonio Cangiano]

For the record, if you click anywhere on the site you linked, you'll be redirected to malware/adware.

[Goran Miskovic]

@bodhi.zazen Any click on the linked article will redirect to a rogue website as Antonio correctly pointed out. I am reluctant to take security advice from such article.

[Panther]

@GoranMiskovic - Link works here, not sure what you mean by a "rogue website" - If you do not like the site, don't use it. The instructions I posted in the answer above still work without the link.

[terdon]

@GoranMiskovic I don't understand what you mean. I don't see any redirecting anywhere.

[Goran Miskovic]

Click on the link to part 1 of the article. That will bring you to facebook.com-prize.us. There is a way better article.

[Panther]

@GoranMiskovic - I can not replicate your reported behavior here. What DNS service are you using ?

[Eric J.]

It looks like that site is serving ads from a disreputable ad network that sometimes serves up an ad that runs malicious code when clicked.

[vigilian]

@antivirtel are we still have to create a ufw-ssh conf since there is a ufw.conf in action.d ?

[Joril]

For the record, the action is present in version 0.8.13 too

[Michael Härtl]

I would add a note that it is not recommended to use the ufw action because it does not block established connections. So you can still get 1000s of attacking requests before the ip rule finally blocks an IP. The default is working great. Seing the blocked IPs in ufw status is pointless as you can use the fail2ban-client tool to see the banned IPs.