Re: Rate-limiting to halt brute-force attack

[Emilio Lazo Zaia <emiliolazozaia@gmail.com>]

In order to block 3 SSH attempts in 40 seconds, I'm doing the following:

First, this will syslog all silently dropped SSH attempts (after third 
in 40 seconds):
# iptables -A LOG-BlockdSSH -m recent --rcheck --seconds 40 --hitcount 3 
--name BlockdSSH --rsource -j LOG --log-prefix "iptables/BlockdSSH: " 
--log-tcp-options --log-ip-options

But LOG chain passes the packet to the following rule, so we must drop it:
# iptables -A LOG-BlockdSSH -m recent --rcheck --seconds 40 --hitcount 3 
--name BlockdSSH --rsource -j DROP

This registers the IP address in a set of recent module:
# iptables -A BlockdSSH -m recent --set --name BlockdSSH --rsource -j DROP

Any new SSH attempt from that IP address will reset the counter to 10 
days (--update), and also log that packet:
# iptables -A NoJodan -p tcp -m tcp --dport 22 -m recent --update 
--seconds 864000 --name BlockdSSH --rsource -j LOG-BlockdSSH

This creates the set "SSH" containing all SSH connections, regardless 
they are "good" or not:
# iptables -A NoJodan -p tcp -m tcp --dport 22 -m recent --set --name 
SSH --rsource

If the limit is reached, this rule chains to BlockdSSH; that will LOG 
and block any connection from that IP address:
# iptables -A NoJodan -p tcp -m tcp --dport 22 -m recent --update 
--seconds 40 --hitcount 3 --name SSH --rsource -j BlockdSSH

You must create these chains and make all new packets enters into 
NoJodan chain.

For example, the first SSH packet will not match first rule of NoJodan 
because the recent extension hasn't that IP address in the BlockdSSH 
set, so the packet will continue and will not be diverted to 
LOG-BlockdSSH. Second rule will match and the IP address is registered 
in SSH set in recent. Third rule will not match because is the first 
packet and not the third in 40 sec.

Second packet (seconds later) also will not match first NoJodan rule, 
will be registered in the SSH set, and also third rule does not affect him.

Third packet will not match first rule because it isn't registered in 
BlockdSSH. This packet will match the second rule but also the third 
rule in which the limit is 3/40sec. That packet will go to iptables 
BlockdSSH chain. In this chain, that will be registered in the set named 
"BlockdSSH" because it reached the limit (I did choose the same name as 
the iptables chain: BlockdSSH), so now this IP address is the the black 
list and the packet is dropped.

Fourth packet will match the first rule in NoJodan, because this IP 
address was registered in the BlockdSSH set (black list set) in recent 
and will be forwarded to LOG-BlockdSSH chain. In this chain the packet 
is being logged and dropped (first and second rule).

They must wait 10 days or change their IP address to have a respond from 
SSH server.

I don't know why I'm doing that BlockdSSH chain will target to DROP 
instead of LOG-BlockdSSH. Surely these rules may be improved.

You may adapt this idea to your ports and times. Also this may be used 
to block port scanning (modifying LOG chain to not log every packet), 
ping flood, etc.

Regards.


On 16.11.2012 09:52, Dimitri Yioulos wrote:
> Hi, folks.
>
>   A few days ago, a major brute-force attack was launched
> against our (sendmail) mail server. It looks like a bot is
> aiming lots of zombies at us. Here's how OSSEC hids reports
> an attempt from one of the zombies:
>
> OSSEC HIDS Notification.
> 2012 Nov 13 09:08:16
>
> Received From: (plymouth) 192.168.1.2->/var/log/messages
> Rule: 40111 fired (level 10) ->  "Multiple authentication
> failures."
> Portion of the log(s):
>
> Nov 13 09:07:44 plymouth ipop3d[29926]: Login failed
> user=hod auth=hod host=201-93-132-240.dsl.telesp.net.br
> [201.93.132.240]
> Nov 13 09:07:44 plymouth ipop3d[29925]: Login failed
> user=lee auth=lee host=201-93-132-240.dsl.telesp.net.br
> [201.93.132.240]
> ~
> ~
>
> To remediate, I've put fail2ban in place on the mail server,
> and it's working. However, the attacks are still beating at
> the door, and it's significantly increased the load on the
> mail server . I'm now thinking of adding rules to our
> iptables/Netfilter firewall to rate-limit the brute-force
> connections. The rules I'd add are these:
>
> iptables -A INPUT -p tcp --dport 110 -m state --state NEW -m
> recent --set
>
> iptables -A INPUT -p tcp --dport 110 -m state --state NEW -m
> recent --update --seconds 15 --hitcount 3 -j DROP
>
> As the mail server sits in a DMZ, and packets are forwarded
> to it, is the INPUT chain the best place to put these
> rules, or should they go in the FORWARD chain (with
> appropriate modifications)?
>
> Of course, I don't want to stop legitimate mail. Is this the
> best course of action?
>
> Thanks.
>
> Dimitri
>