Fail2Ban is not adding iptables rules

Question

Fail2Ban is not adding iptables rules to block attackers. I'm running CentOS 6.5 (32 bit)

Here's what I did:

fail2ban was installed via yum using the EPEL repo.
I copied jail.conf to jail.local.
I changed the ban time in jail.local to be 3600
```
bantime  = 3600
```

For iptables I have these rules defined regarding SSH

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           
2    ACCEPT     all  --  0.0.0.0/0            0.0.0.0/0           state ESTABLISHED 
3    fail2ban-SSH  tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22 
4    ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           tcp dpt:22

My jail.local config for SSH:

[ssh-iptables]

enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
logpath  = /var/log/secure
maxretry = 5

Latest log entries:

2014-08-13 10:11:04,481 fail2ban.server : INFO   Changed logging target to /var/log/fail2ban.log for Fail2ban v0.8.11
2014-08-13 10:11:04,482 fail2ban.jail   : INFO   Creating new jail 'ssh-iptables'
2014-08-13 10:11:04,514 fail2ban.jail   : INFO   Jail 'ssh-iptables' uses pyinotify
2014-08-13 10:11:04,533 fail2ban.jail   : INFO   Initiated 'pyinotify' backend
2014-08-13 10:11:04,536 fail2ban.filter : INFO   Added logfile = /var/log/secure
2014-08-13 10:11:04,537 fail2ban.filter : INFO   Set maxRetry = 5
2014-08-13 10:11:04,540 fail2ban.filter : INFO   Set findtime = 600
2014-08-13 10:11:04,540 fail2ban.actions: INFO   Set banTime = 3600
2014-08-13 10:11:04,727 fail2ban.jail   : INFO   Jail 'ssh-iptables' started

I then start fail2ban, yet after a while (an hour or so) I check /var/log/secure and I'm still getting brute force attacks:

Aug 13 10:31:35 webhost sshd[15619]: Invalid user china from 128.199.147.79
Aug 13 10:31:35 webhost sshd[15620]: input_userauth_request: invalid user china
Aug 13 10:31:36 webhost sshd[15620]: Connection closed by 128.199.147.79
Aug 13 10:35:04 webhost sshd[15661]: Invalid user klaudia from 106.187.90.33
Aug 13 10:35:04 webhost sshd[15662]: input_userauth_request: invalid user klaudia
Aug 13 10:35:05 webhost sshd[15662]: Connection closed by 106.187.90.33
Aug 13 10:41:56 webhost sshd[15772]: Invalid user cassandra from 106.187.90.33
Aug 13 10:41:56 webhost sshd[15773]: input_userauth_request: invalid user cassandra
Aug 13 10:41:57 webhost sshd[15773]: Connection closed by 106.187.90.33
Aug 13 10:44:10 webhost sshd[15807]: Invalid user knight from 106.187.90.33
Aug 13 10:44:10 webhost sshd[15808]: input_userauth_request: invalid user knight
Aug 13 10:44:12 webhost sshd[15808]: Connection closed by 106.187.90.33

No new rules have been added to iptables...

Chain fail2ban-SSH (1 references)
target     prot opt source               destination         
RETURN     all  --  0.0.0.0/0            0.0.0.0/0

If I try and debug the problem with fail2ban-regex:

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

Running tests

Use   failregex file : /etc/fail2ban/filter.d/sshd.conf
Use         log file : /var/log/secure

Results

Failregex: 1374 total
|-  #) [# of hits] regular expression
|   5) [1374] ^\s*(<[^.]+\.[^.]+>)?\s*(?:\S+ )?(?:kernel: \[\d+\.\d+\] )?(?:@vserver_\S+ )?(?:(?:\[\d+\])?:\s+[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?|[\[\(]?sshd(?:\(\S+\))?[\]\)]?:?(?:\[\d+\])?:?)?\s(?:\[ID \d+ \S+\])?\s*[iI](?:llegal|nvalid) user .* from <HOST>\s*$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [4615] MONTH Day Hour:Minute:Second
`-

Lines: 4615 lines, 0 ignored, 1374 matched, 3241 missed
Missed line(s):: too many to print.  Use --print-all-missed to print all 3241 lines
</code>

The missed lines are:

Lines: 4621 lines, 0 ignored, 1376 matched, 3245 missed
|- Missed line(s):
|  Aug 10 03:46:30 webhost sshd[12340]: input_userauth_request: invalid user simulator
|  Aug 10 03:46:30 webhost sshd[12340]: Connection closed by 106.187.90.33
|  Aug 10 03:55:01 webhost sshd[12430]: input_userauth_request: invalid user simulation
|  Aug 10 03:55:02 webhost sshd[12430]: Connection closed by 106.187.90.33
|  Aug 10 04:01:33 webhost sshd[12505]: Connection closed by 128.199.147.79
|  Aug 10 04:02:46 webhost sshd[12539]: reverse mapping checking getaddrinfo for new.jerl.im [128.199.254.179] failed - POSSIBLE BREAK-IN ATTEMPT!

I don't know enough about fail2ban to know what's wrong with my sshd filter. I would have thought the default config would have been enough? How do I fix this?

I think I'm having a similar experience here : http://serverfault.com/questions/632774/fail2ban-on-centos-6-5-never-bans — SteadH, Oct 05 '14 at 14:32

score 1 · Answer 1 · answered Apr 06 '17 at 01:07

When I ran across this problem it was because the "iptables" command was not working. I believe I could have fixed this by changing the line

iptables = iptables <lockingopt>

to

iptables = /sbin/iptables <lockingopt>

but, just to be on the safe side, and because I was only using iptables-allports.conf, I simply replaced all occurances of with /sbin/iptables in that file.

score 0 · Answer 2 · answered Aug 13 '14 at 10:20

0

Check that you was enable IPTABLES jail and SSH filter. Also check f2b logs - is f2b trying to ban someone?

answered Aug 13 '14 at 10:20

Paul Rudnitskiy

413
2
5

The jail is enabled, and no one is getting banned. It appears to be a filter problem, but I'm really not sure.. – Aditya K Aug 13 '14 at 10:40

score 0 · Answer 3 · answered Oct 13 '14 at 17:27

I don't know what log your using /var/log/secure or /var/log/auth.log but whatever one it is you need to tell fail2ban which one it should read from, also as mentioned if you have changed the default port for ssh(22) then again you need to tell fail2ban and open it in your firewall(iptables etc). The regex IS working as intended, it IS matching the important lines in the log i.e

Aug 13 10:31:35 webhost sshd[15619]: Invalid user china from 128.199.147.79

The others it has listed as missing are not important to fail2ban because they do not provided <HOST> or <IP> which fail2ban needs to enable banning of the client. So fail2ban is set up correctly for ssh so if all your definitions match your system set-up then it should be banning, remember you have to trigger the 'findtime' and 'maxretry' values to get banned. Don't forget to '$ fail2ban-client reload' after any changes.

score 0 · Answer 4 · edited Jun 11 '20 at 10:02

0

From my SysAdmin experience, please try systemdfor backend, and use banaction instead of action if you are using CentOS.

For example,

in your jail.local

[DEFAULT]

bantime = 4640000

banaction = firewalld-custom

backend = systemd

let me know if this works.

edited Jun 11 '20 at 10:02

Community

1

answered Feb 27 '15 at 09:44

Mark

564
1
4
11

score 0 · Answer 5 · answered Jan 24 '19 at 11:43

I noticed that if your jail name is too long, it wont be added to iptables.

You can check that /var/log/fail2ban.log will contain a warning about the name being too long, and thus creating an error during iptables rule creation.

This will allow fail2ban to detect and ban, however wont actually ban because the rule does not exists in the iptables config (iptables -v -x -n -L )

Fail2Ban is not adding iptables rules

5 Answers5