fail2ban not banning ssh bruteforce but regex works

Question

I've just noticed an SSH bruteforce at my server, which actually should have been banned by fail2ban, but for some reason it doesn't ban it. Most people who have problems with fail2ban, seem to have problems with their regex, which seems to be fine here.

part of jail.conf

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

fail2ban-client status ssh

Status for the jail: ssh
|- filter
|  |- File list:    /var/log/auth.log 
|  |- Currently failed: 0
|  `- Total failed: 0
`- action
   |- Currently banned: 0
   |  `- IP list:   
   `- Total banned: 0

fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf

Running tests
=============

Use regex file : /etc/fail2ban/filter.d/sshd.conf
Use log file   : /var/log/auth.log


Results
=======

Failregex
|- Regular expressions:
|  [1] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*(?:error: PAM: )?Authentication failure for .* from <HOST>\s*$
|  [2] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
|  [3] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*Failed (?:password|publickey) for .* from <HOST>(?: port \d*)?(?: ssh\d*)?$
|  [4] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*ROOT LOGIN REFUSED.* FROM <HOST>\s*$
|  [5] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*[iI](?:llegal|nvalid) user .* from <HOST>\s*$
|  [6] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*User .+ from <HOST> not allowed because not listed in AllowUsers$
|  [7] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*authentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=<HOST>(?:\s+user=.*)?\s*$
|  [8] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*refused connect from \S+ \(<HOST>\)\s*$
|  [9] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S
+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*Address <HOST> .* POSSIBLE BREAK-IN ATTEMPT!*\s*$
|  [10] ^\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\
S+\))?[\]\)]?:?(?:\[\d+\])?:)?\s*User .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$
|
`- Number of matches:
   [1] 0 match(es)
   [2] 0 match(es)
   [3] 380 match(es)
   [4] 0 match(es)
   [5] 353 match(es)
   [6] 26 match(es)
   [7] 0 match(es)
   [8] 0 match(es)
   [9] 0 match(es)
   [10] 0 match(es)

Ignoreregex
|- Regular expressions:
|
`- Number of matches:

Summary
=======

Addresses found:
[1]
[2]
[3]
    198.245.50.151 (Sat Dec 21 15:18:12 2013)
    198.245.50.151 (Sat Dec 21 15:18:15 2013)
    198.245.50.151 (Sat Dec 21 15:18:18 2013)
    198.245.50.151 (Sat Dec 21 15:18:21 2013)
    198.245.50.151 (Sat Dec 21 15:18:24 2013)
..................
Date template hits:
23379 hit(s): MONTH Day Hour:Minute:Second
0 hit(s): WEEKDAY MONTH Day Hour:Minute:Second Year
..................

Success, the total number of match is 759

Any ideas, why fail2ban does not ban, even if I have lots of regex matches?

Answer 1

In my case (fail2ban 1.0.2 installed manually, Centos 7) the same issue was resolved by setting backend = auto instead of backend = systemd. This setting should be somewhere in your jail.conf or jail.local file. Hope this will help somebody.

Answer 2

This question is pretty old, but I encountered the same problem, and after many many searches, finally found the solution.

My problem was due to a change on my Timezone: some time ago, I used the following command to set my correct timezone.

sudo dpkg-reconfigure tzdata

My system time was ok, but the times of entries in auth.log were indeed shifted. And this was the problem for fail2ban: it has to compare entries of auth.log to check if it has to ban, keep, or unban... and logged entries were always considered as too old because of wrong time.

I just had to restart syslog daemon with:

sudo service rsyslog restart

Then, times were not any more shifted in auth.log, and fail2ban did its job successfully.

I hope this will help!

Answer 3

Ok, this is not an official solution but it does work:

3 months working perfectly until fail2ban upgraded and stopped banning. I can tell how hard I investigated to solve this issue and at the end this is the only way that works.

This should work

 sudo service fail2ban stop
 sudo service fail2ban start

This will not work

sudo service fail2ban restart

IMPORTANT: Test with another device (3G cell) an intentional failed ssh logging to verify fail2ban is working. If not, service stop/start again. Sometimes some jails don't load correctly. Never trust!!!!!

EXTRA NOTES:

• Using jail.local
• 4 jails enabled: ssh, dovecot, apache and wootwoot
• All jails working as a charm for months with no issue
• Ubuntu server 14.04
• fail2ban 0.9

Answer 4

I just found it necessary to reboot my server before changes to sshd's port went into effect ... changing ports is pretty effective and simple.

Answer 5

I tried all the solutions here before I Googled it again and found the answer on ServerFault:

Running service rsyslog restart was all I needed to do and now it works as expected (of course there's the possibility that all the solutions here were necessary as well...). Unlike the poster of this question, I never deleted or edited the log file, so why this is the solution I know not.

Answer 6

Sometimes this is because the __bsd_syslog_verbose is wrong. fail2ban expects /var/log/auth.log to start with YYYY.MM.DD (ie: 2014.10.15) yet the logs read MMM DD (ie: Oct 15)

To fix this you will need to do the following:

cp /etc/fail2ban/filter.d/common.conf /etc/fail2ban/filter.d/common.local

Edit common.local and set:

__bsd_syslog_verbose = (<[^.]+ [^.]+>)

Restart fail2ban :

Ubuntu (don't use restart):

sudo service fail2ban stop
sudo service fail2ban start

Answer 7

Fail2ban not banning and regexp matching a lot? It's probably that your jail is missing a ban action. You have two options:

Option 1) Inside your jail [ssh] include

[ssh]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
action = %(action_mwl)s # <<== THIS IS FOR BANNING
maxretry = 6
findtime = 6000
bantime = 86400

Option 2) Include a global action for all your jails just writing this (example)

# Choose default action.  To change, just override value of 'action' with the
# interpolation to the chosen action shortcut (e.g.  action_mw, action_mwl, etc) in jail.local
# globally (section [DEFAULT]) or per specific section
action = %(action_mwl)s

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

BTW, at the top of jail.conf I can read a recommendation for using jail.local instead of jail.conf. May be it could be helpful to follow their instructions:

To avoid merges during upgrades DO NOT MODIFY THIS FILE
# and rather provide your changes in /etc/fail2ban/jail.local

Answer 8

I had a similar behavior on a Ubuntu raring (13.04) box. Fail2ban was failing to notice changes in the /var/log/auth.log file. Changing the backend value in the jail.conf file did not change anything.

I finally fixed this up by installing the latest version of Fail2ban using the Backport builds are available from NeuroDebian as described on the download page from the Fail2ban website.

Answer 9

often when I have this trouble (on Debian boxes) it's something related to tzdata and wrong time. If the regexp works (and it's working) the only things that can prevent fai2ban from trggering is something screwed up with date/time. Try to install ntp and keep in sync your date.