source: generationip.asia
Fail2ban is a very useful and powerful solution to limit the bruteforce on your server. but fail2ban doesn’t provide you a way to contact directly the IP provider’s of bruteforce attacks source. I have modify an fail2ban action file’s and create a script for that.
INSTALLATION
Go to the fail2ban action folders :
# cd /etc/fail2ban/action.d
ssh est excellent pour accéder à distance à ses fichiers, ou même utiliser son ordinateur à distance.
Mais que faire contre les attaques de type brute-force ?
(Essai de toutes les combinaisons de lettre pour trouver le mot de passe).
C’est simple:
sudo aptitude install fail2ban
Et voilà !
Si quelqu’un fait 6 essais ratés de connexion sur le serveur ssh, son adresse IP sera bannie pendant 10 minutes.
C’est suffisant pour rendre inutile ce genre d’attaque.
Pour voir les actions du programme, faites:
sudo cat /var/log/fail2ban.log
En fait, fail2ban peut être configuré pour faire plein d’autres choses.
Dans le principe, il surveille les fichiers log de votre choix, et déclenche alors des actions.
Dans le cas de ssh, il surveille /var/log/auth.log et lance des commandes iptables pour bannir les adresses IP.
Regardez le fichier /etc/fail2ban/jail.conf
Il contient déjà les lignes pour bloquer les attaques sur les serveurs ftp (vsftpd, wuftpd, proftpd…), postfix, apache…
Vous pouvez les activer en remplaçant enabled = false par enabled = true.
iptables recent module usage by exampleiptables -F iptables -A INPUT -p icmp --icmp-type echo-request -m recent --rcheck --seconds 10 --hitcount 2 --name ICMPCHECK -j DROP iptables -A INPUT -p icmp --icmp-type echo-request -m recent --set --name ICMPCHECK -j ACCEPT
iptables -F iptables -A INPUT -p icmp --icmp-type echo-request -m recent --update --seconds 10 --hitcount 2 --name ICMPCHECK -j DROP iptables -A INPUT -p icmp --icmp-type echo-request -m recent --set --name ICMPCHECK -j ACCEPT
SSHPORT=22
iptables -F
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --update --seconds 60 --hitcount 3 --name BRUTEFORCE -j DROP
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --set --name BRUTEFORCE -j ACCEPT
SSHPORT=22
iptables -F
iptables -X
iptables -N BRUTECHECK
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -j BRUTECHECK
iptables -A BRUTECHECK -m recent --update --seconds 60 --hitcount 3 --name BRUTEFORCE -j DROP
iptables -A BRUTECHECK -m recent --set --name BRUTEFORCE -j ACCEPT
SSHPORT=22
N1=1000
N2=2000
iptables -F
iptables -X
iptables -N KNOCK1
iptables -N KNOCK2
iptables -N OK
iptables -A KNOCK1 -m recent --set --name SEENFIRST
iptables -A KNOCK1 -m recent --remove --name KNOCKED
iptables -A KNOCK1 -j DROP
iptables -A KNOCK2 -m recent --rcheck --name SEENFIRST --seconds 5 -j OK
iptables -A KNOCK2 -m recent --remove --name SEENFIRST
iptables -A KNOCK2 -j DROP
iptables -A OK -m recent --set --name KNOCKED
iptables -A OK -j DROP
iptables -A INPUT -p tcp --dport ${N1} -j KNOCK1
iptables -A INPUT -p tcp --dport ${N2} -j KNOCK2
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -m recent --seconds 10 --rcheck --name KNOCKED -j ACCEPT
iptables -A INPUT -p tcp --dport ${SSHPORT} -m state --state NEW -j DROP
#!/bin/bash
HOST="172.16.20.2"
SSHPORT=22
KNOCKS="1000 2000"
for PORT in $KNOCKS; do
echo "Knock: $PORT"
telnet $HOST $PORT &> /dev/null &
P=$(echo $!)
echo "PID: ${P}"
sleep 1
kill -KILL ${P}
done
ssh -p${SSHPORT} ${HOST}Source: Pejman Moghadam
Source: MDLog:/sysadmin
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 includesipt_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** --name SSH -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.
References: http://www.netfilter.org/documentation/HOWTO/netfilter-extensions-HOWTO-3.html#ss3.16
If you run a wordpress blog these days, you are likely to experience brute force attacks where nefarious individuals attempt to break in to your website by quickly a list of userids and passwords against your wp-login.php. Here’s how I automated detection and blocking of WordPress brute force login attacks.
One can typically detect a wordpress brute force attack by parsing through your webserver’s access_log file. The access_log file records all of the access requests that a web server handles. A brute force attack typically will have frequent and numerous attempts to the wp-login.php file as shown below:
Example: In the access_log file below, we detect a brute force login attack on our WordPress blog. We detected it by noticing frequent and constant requests to the wp-login.php file.
31.192.210.159 - - [11/Sep/2014:02:01:43 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:44 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:45 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:47 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:49 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:50 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:51 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:52 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:54 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1" 31.192.210.159 - - [11/Sep/2014:02:01:55 +0000] "POST http://www.uptimemadeeasy.com/wp-login.php HTTP/1.1" 200 3389 "http://www.uptimemadeeasy.com/wp-login.php" "Mozilla/5.0 (Linux; U; Android 2.2) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"
Typically in an event like this, I lookup the IP address in the ARIN database as I showed in a previous article: What Personal Information Can You Get From Your Web Server? Frequently, I find that the address is from APAC or RIPE addresses.