4

I have correctly installed fail2ban in my machine, activating the rules for ssh, ssh-dos and recidive; it all works ok.

Lately, I have seen an increasing patterns of repetitive attacks from different hosts form the same networks, which circumvent the "recidive" rule by switching IP after a ban:

2015-01-25 11:12:11,976 fail2ban.actions: WARNING [ssh] Ban XXX.41.124.29
2015-01-25 11:12:13,165 fail2ban.actions: WARNING [ssh] Ban XXX.41.124.42
2015-01-25 11:12:16,297 fail2ban.actions: WARNING [ssh] Ban XXX.41.124.28
2015-01-25 11:12:20,446 fail2ban.actions: WARNING [ssh] Ban XXX.41.124.104

I would like to detect it and make a "recidive24" rule that blocks all these kind of attacks banning the whole /24 subnetwork.

I found a suggestion in the debian bug archive for fail2ban, and I have applied it, but:

  1. If I apply the full /24 ban when the ssh jail is triggered, I have the problem that it is easy from someone on my same network to block me out, by just attacking from ONE IP;

  2. The recidive jail would be perfect, but it is not triggered by the storm changing IPs...

So I would like to change the recidive filter specification so that it just look at the first three bytes of the IP, but I am at a loss here... the regexp that do the ban is (from /etc/fail2ban/recidive.conf) is

# The name of the jail that this filter is used for. In jail.conf, name the 
# jail using this filter 'recidive', or change this line!
_jailname = recidive

failregex = ^(%(__prefix_line)s|,\d{3} fail2ban.actions:\s+)WARNING\s+\[(?!%(_jailname)s\])(?:.*)\]\s+Ban\s+<HOST>\s*$

...and it will match a complete IP.

The question: How can I change this failregex so that it matches just the first three bytes of the host IP?


I though about filtering the fail2ban log file with another daemon and writing a second file where the last byte is 0 every time, and trigger the recidive jail using it, but it seems really clumsy...

1

I tried fail2ban in Centos 7 and found that it fails to block IP addresses sometimes. It keeps adding them to jail but they were still able to access sshd. There is some incompatibility with firewalld.

I now use a different approach. I modified /etc/hosts.deny like this:

sshd: 43.*.*.*
sshd: 58.*.*.*

Just don't add your own IP networks there by accident.

To grep IP addresses from the secure log, use:

grep sshd /etc/hosts.deny

To get the 10 most active IP addresses from the sshd log with access count, use:

d=[0-9]{1,3}
s=[\.\-]
n=[^0-9]
ip="$d$s$d$s$d$s$d"
egrep $ip /var/log/secure | sed -r "s/^.*$n($ip).*$/\1/g" | sed s/-/./g | sort | uniq -c | sort -g | tail -10

(source: http://whoishacking.com)

  • Yes, but this is manual... ;-) – Rmano Apr 22 '15 at 20:39
1

fail2ban has indeed a hostsdeny.conf in /etc/fail2ban/action.d which means you only have to declare action = hostsdeny

An example from howtoforge :

# Here we use TCP-Wrappers instead of Netfilter/Iptables. 
# "ignoreregex" is used to avoid banning the user "myuser".

[ssh-tcpwrapper]

enabled     = true
filter      = sshd
action      = hostsdeny
              sendmail-whois[name=SSH, dest=you@mail.com]
ignoreregex = for myuser from
logpath     = /var/log/messages
  • ...but this is just banning one IP, it seems. Are you sure it is banning all the subnet? I do not see it in the definition of the action either... – Rmano Oct 20 '16 at 9:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.