Fail2Ban Not Banning on CentOS 7 with SELinux

On a LEMP stack with WordPress and the WP fail2ban plugin, WordPress authentication issues get logged to /var/log/messages perfectly fine.

$ sudo fail2ban-client version
0.9.2

In the last couple of days I get about 25K of these lines in there, some brute force attempt from Sweden:

Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29203]: Blocked authentication attempt for mydomain from 217.70.32.9
Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29204]: Blocked authentication attempt for mydomain from 217.70.32.9
Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29796]: Blocked authentication attempt for mydomain from 217.70.32.9
Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29203]: Blocked authentication attempt for mydomain from 217.70.32.9
Aug 17 10:48:58 ip-172-1-6-5 wordpress(mydomain.com)[29204]: Blocked authentication attempt for mydomain from 217.70.32.9

The wordpress.conf jail has been enabled and the regexp test works:

$ sudo fail2ban-regex /var/log/messages /etc/fail2ban/filter.d/wordpress.conf

Failregex: 25865 total
|-  #) [# of hits] regular expression
|   1) [180] ^\s*(<[^.]+\.[^.]+>)?\s*(?:\S+ )?(?:kernel: \[ *\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?wordpress(?:\(\S+\))?[\]\)]?:?|[\[\(]?wordpress(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)?\s(?:\[ID \d+ \S+\])?\s*Authentication failure for .* from <HOST>$
|   2) [25685] ^\s*(<[^.]+\.[^.]+>)?\s*(?:\S+ )?(?:kernel: \[ *\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?wordpress(?:\(\S+\))?[\]\)]?:?|[\[\(]?wordpress(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)?\s(?:\[ID \d+ \S+\])?\s*Blocked authentication attempt for .* from <HOST>$

However, none get banned.

$ sudo fail2ban-client status wordpress
Status for the jail: wordpress
|- Filter
|  |- Currently failed: 0
|  |- Total failed: 0
|  `- File list:    /var/log/messages
`- Actions
   |- Currently banned: 0
   |- Total banned: 0
   `- Banned IP list:

Confirming firewalld knows about this:

$ sudo ipset list

Name: fail2ban-wordpress
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 65536 timeout 3600
Size in memory: 16528
References: 1
Members:

From jail.local

bantime  = 3600
findtime  = 600
banaction = firewallcmd-ipset

# Protect agains WP Login bruteforce attemps via
# https://wordpress.org/plugins/wp-fail2ban/installation/

[wordpress]

port     = http,https
logpath  = /var/log/messages
maxretry = 3
enabled = true

Note how above we get 5 retry attempts within one second, which should of course trigger a ban.

I see no worrying denied messages in /var/log/audit/audit.log regarding SELinux preventing this from working though I'm far from an expert on SELinux.

The logging works. The regex works. Fail2Ban runs. The jail has been enabled. Firewalld is expecting things. But nothing is happening.

Manually banning it works too:

$ sudo fail2ban-client set wordpress banip 217.70.32.9

$ sudo fail2ban-client status wordpress
Status for the jail: wordpress
|- Filter
|  |- Currently failed: 0
|  |- Total failed: 3
|  `- File list:    /var/log/messages
`- Actions
   |- Currently banned: 1
   |- Total banned: 1
   `- Banned IP list:   217.70.32.9

$ sudo ipset list
Name: fail2ban-wordpress
Type: hash:ip
Revision: 1
Header: family inet hashsize 1024 maxelem 65536 timeout 3600
Size in memory: 16592
References: 1
Members:
217.70.32.9 timeout 3457

This appears to confirm my jail.local is being loaded:

$ sudo fail2ban-client status
Status
|- Number of jail:  6
`- Jail list:   1, 2, 3, 4, 5, wordpress

I was using backend polling, but I am now running Gamin. Setting Fail2Ban loglevel to debug, this appears to work when I wrongly log in myself:

2015-08-18 22:57:52,874 fail2ban.filtergamin    [29664]: DEBUG   File changed: /var/log/messages

The regex checker keeps increasing its matches too. But still, I can do that 20 times in 2 minutes without getting banned...

Where should I look next?

Solution 1:

After mucking around for hours, it finally dawned on me that the timestamp in /var/log/messages was 2 hours out of sync. This, of course, has repercussions when it comes to fail2ban figuring out findtime.

$ timedatectl
      Local time: Tue 2015-08-18 23:50:11 CEST

In /var/log/messages:

Aug 18 21:50:11 ip-172-1-6-5 systemd: Started Time & Date Service.

To solve:

$ sudo systemctl restart rsyslog.service

Now my failed logins get logged with the correct timestamp and indeed, I get banned.