GIT – Block Brute Force Attack : Using PAM to Block Brute Force Attacks, Using to Block Brute Force Attacks.

1.Using PAM to Block Brute Force Attacks

The idea to use PAM (Pluggable Authentication Modules for ) to block brute force attacks sounds like a good idea, right? After all, we are using PAM for most of the authentications mechanisms, so adding a module to check against repeated failures would be great. Surprisingly even if this sounded like something normal, I found only one PAM module that was written for this purpose. This is called pam_abl and you can find it here:http://hexten.net/pam_abl

In order to use pam_abl we first need to it on our system. Unfortunately this is not available in any Linux distribution as a precompiled package, so the only way to it is from sources. The installation is not complicated just that this will make updates more complicated.
Let me show you the steps needed to install pam_abl on  (on other distributions it should be similar with some paths changed).

First we need to the source from: http://sourceforge.net/project/showfiles.php?group_id=148927
We need to have pam and libdb development libraries in order to compile the module. In case you don’t have them already on Debian install them using:

apt-get install libpam0g-dev libdb4.4-dev

Now all we have to do is compile the module after uncompressing it in a temporary folder:

 make install

and copy the sample configuration file to /etc/security/:

cp conf/pam_abl.conf /etc/security

That’s it… Not complicated at all. Now in order to show you how this module can block brute force attacks against ssh I have added to my ssh pam config a line to call the pam_abl module. After this the file looks like:

# /etc/pam.d/ssh:
auth required pam_env.so # [1]
auth required /lib/security/pam_abl.so config=/etc/security/pam_abl.conf
@include common-auth
@include common-account
@include common-session
##session optional pam_motd.so # [1]
session optional pam_mail.so standard noenv # [1]
session required pam_limits.so
@include common-

I have changed the configuration file (pam_abl.conf) to block only offending hosts, and not users to not cause some DOS on my existing users by random scans. This is how the pam_abl config file looks like after my changes:

# /etc/security/pam_abl.conf:
host_db=/var/lib/abl/hosts.db
host_purge=2d
host_rule=*:3/1h

#user_db=/var/lib/abl/users.db
#user_purge=2d
#user_rule=!:10/1h,30/1d

Basically this will block any user coming from any host (symbolized by *) after 3 failed login attempts in 1h.
You should check the author’s documentation for more details about the syntax of the configuration file.

Any host trying to brute force my testing ssh server will be blocked after 3 failed attempts and in the system logs (/var/log/auth.log on Debian for authentication events) we can see:

sshd[6892]: Failed password for root from 192.168.0.103 port 40235 ssh2
sshd[6892]: Failed password for root from 192.168.0.103 port 40235 ssh2
sshd[6892]: (pam_unix) 1 more authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.103 user=root
sshd[6900]: (pam_unix) authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.0.103 user=root
sshd[6900]: Failed password for root from 192.168.0.103 port 40236 ssh2
pam_abl[6909]:Blocking access from 192.168.0.103 to service ssh, user root

After this the server will continue to respond to authentication request to the offending host, but it will fail them even if they match the proper password.

References:
http://hexten.net/pam_abl
http://hexten.net/assets/pam_abl_doc/index.html

2.Using iptables to Block Brute Force Attacks 

We can use the iptables recent module to write some iptables rules that can block brute force attacks. In order to use this method you need a kernel and iptables installation that includes ipt_recent. If your linux distribution doesn’t include the ipt_recent module or you are using a custom compiled kernel you might need to first include the iptables recent patch that can be found on the author’s website or in the iptables patch-o-matic area. If you are using Debian/Ubuntu you don’t need to do anything special as this is already included in your system.

Let’s see how we can use the iptables recent module to block brute force attacks agains ssh. Let’s see a simple example:

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --nameSSH -j DROP

This will basically allow only 3 NEW connections (as matched by the state NEW) in the timeframe of 300sec (5min). Any new connection will be automatically dropped.

The main disadvantage of using this method is that it will not make any distinction betweensuccessful and failed logins. If you are not careful and open too many connections yourself you might found yourself locked out. One walk-around for this issue is to whitelist our own administrative ips (still if we can do this for all the locations that need to connect to the system, then we can protect ourselves with simple firewall rules and we don’t need this added complexity). So at least for the hosts that we can (static ips) we should do this (replace with as many lines needed containing $WHITE_LIST_IP):

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -s $WHITE_LIST_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH-j DROP

Even if we lock ourselves out, our existing connections will remain up since we are matching only on NEW connections. If needed we can take appropriate actions.

In case we want to have the blocked hosts logged, then we will have to add another iptables rule:

iptables -N SSHSCAN
iptables -A INPUT -p tcp --dport 22 -s $WHITE_LIST_IP -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSHSCAN
iptables -A SSHSCAN -m recent --set --name SSH
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH-j LOG --log-level info --log-prefix "SSH SCAN blocked: "
iptables -A SSHSCAN -m recent --update --seconds 300 --hitcount 3 --name SSH-j DROP

You can peek at the internal database kept by the module, by looking inside:/proc/net/ipt_recent/* (DEFAULT will contain default matches; in our example the name of the file is SSHSCAN):

cat /proc/net/ipt_recent/SSHSCAN

This solution is very effective and easy to implement. You just add the needed iptables rules to your existing firewall setup and you are set. Still, it has many limitations when compared with the other methods shown: like limited time frames, it will not differentiate against failed/successful logins, etc.

You can add the following rules in your iptables.

#Protect from SYN Attack
-A INPUT -p tcp –tcp-flags ALL NONE -j DROP
-A INPUT -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP
-A INPUT -p tcp –tcp-flags SYN,RST SYN,RST -j DROP
-A INPUT -p tcp –tcp-flags FIN,RST FIN,RST -j DROP
-A INPUT -p tcp –tcp-flags ACK,FIN FIN -j DROP
-A INPUT -p tcp –tcp-flags ACK,PSH PSH -j DROP
-A INPUT -p tcp –tcp-flags ACK,URG URG -j DROP
-A INPUT -i eth0 -p tcp -m state –state NEW -m tcp –sport 1024:65535 –dport 20 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp –sport 1024:65535 –dport 1024:65535 -m state –state ESTABLISHED -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp –sport 1024:65535 –dport 1024:65535 -m state –state RELATED,ESTABLISHED -j ACCEPT

References:
http://snowman.net/projects/ipt_recent/
http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16

Print Friendly

Comments

comments

Bài viết liên quan