Fail2Ban anti w00tw00t
Est-ce que w00tw00t.at.ISC.SANS.DFind:) vous dit quelque chose ?
Si vous administrez un serveur, vous avez probablement déjà rencontré cette bizarrerie dans vos logs apache, ou tenter de vous en débarrasser ?
Afin de limiter les scans de se type, nous allons utiliser Fail2Ban.
Fail2Ban examine des logs de divers serveurs (ssh, apache, ftp, postfix etc…) à la recherche d’erreurs répétées (via un regex) et ajoute une règle iptables pour bannir l’adresse IP.
Installation de Fail2Ban :
sudo aptitude install fail2ban
Par défaut Fail2Ban contient plusieurs filtres qui se trouvent dans /etc/fail2ban/filter.d/ mais la detection de w00tw00t n’en fait pas partie.
Nous allons donc créer un nouveau filtre, car Fail2Ban à besoin de 2 choses pour fonctionner.
- Un fichier log à surveiller
- Un fichier qui contient le filtre (regex qui match se que vous souhaitez)
- Et bien sûr, configurer Fail2Ban pour qu’il utilise les filtres
Nous avons 2 méthodes différentes pour détecter et bloquer les scans w00tw00t.
Soit par le fichier access.log, soit error.log
Le fichier access.log contient les statistiques d’accès apache avec une belle erreur 400 Bad Request.
Exemple dans access.log :
81.200.84.* - - [08/Dec/2009:09:00:29 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 307 "-" "-" 81.83.*.* - - [09/Dec/2009:03:18:46 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 307 "-" "-" 193.77.*.* - - [09/Dec/2009:07:38:23 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 307 "-" "-" 81.83.*.* - - [10/Dec/2009:11:34:05 +0100] "GET /w00tw00t.at.ISC.SANS.DFind:) HTTP/1.1" 400 307 "-" "-"
Le fichier error.log contient les erreurs apache :
[Tue Dec 08 09:00:29 2009] [error] [client 81.200.84.*] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:) [Wed Dec 09 03:18:46 2009] [error] [client 81.83.*.*] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:) [Wed Dec 09 07:38:23 2009] [error] [client 193.77.*.*] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:) [Thu Dec 10 11:34:05 2009] [error] [client 81.83.*.*] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
On peu donc utiliser Fail2Ban avec l’un des deux fichiers de log. Personnellement je le fait avec les deux. On sais jamais 
Nous allons créer une nouvelle règles anti w00tw00t qui va surveiller access.log pour commencer.
sudo touch /etc/fail2ban/filter.d/apache-w00tw00t.conf
Ensuite avec votre editeur favoris éditer et ajouter ceci :
# Fail2Ban configuration file # # [Definition] # # # Option: failregex # Notes.: Regexp to catch Apache w00tw00t attempts. # Values: TEXT # failregex = ^<HOST> -.*"GET \/w00tw00t\.at\.ISC\.SANS.*".* # # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex =
J’utilise personnellement nano en ligne de commande.
sudo nano /etc/fail2ban/filter.d/apache-w00tw00t.conf
Copier coller le filtre, puis pour enregistrer taper Ctrl+o et Ctrl+x pour quitter nano.
Nous allons maintenant configurer Fail2Ban pour qu’il utilise le filtre que nous venons de créer.
Le fichier de configuration de Fail2Ban se trouve dans /etc/fail2ban/jail.conf
Ajouter ceci avec votre éditeur :
[apache-w00tw00t]
enabled = true
port = http,https
filter = apache-w00tw00t
logpath = /var/log/apache*/*access.log
maxretry = 1
Pour vérifier que notre filtre va bien fonctionner, nous utilisons fail2ban-regex qui va tester le fichier de configuration.
sudo fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/apache-w00tw00t.conf
Normalement il devrait matcher les IP. Si se n’est pas le cas, c’est que vous n’avez pas bien configurer Fail2ban, soit qu’il n’y a pas eu d’attaques de w00tw00t.
Pour en être certain, faites :
grep ‘w00tw00t’ /var/log/access.log
Ensuite il suffis de redémarrer Fail2Ban pour activer le nouveau filtre.
sudo /etc/init.d/fail2ban restart
2ème méthode avec error.log :
Nous pouvons aussi utiliser le fichier error.log pour détecter les scans w00tw00t. Pour celà inutile de créer un nouveau filtre. Je vais utiliser et modifier celui que Fail2Ban à déjà installer. Le filtre /etc/fail2ban/filter.d/apache-overflows.conf qui filtre déjà des erreurs de protocole.
Le voici :
# Fail2Ban configuration file # # Author: Tim Connors # # $Revision: 668 $ # [Definition] # Option: failregex # Notes.: Regexp to catch Apache overflow attempts. # Values: TEXT # failregex = [[]client <HOST>[]] (client sent HTTP/1.1 request without hostname|Invalid method in request|request failed: URI too long|erroneous characters after protocol string|Invalid URI in request .*) # Option: ignoreregex # Notes.: regex to ignore. If this regex matches, the line is ignored. # Values: TEXT # ignoreregex =
Se filtre va matcher client sent HTTP/1.1 request without hostname, signature des scans w00tw00t et autres requêtes mal former de certains script kiddies.
Apache rejette cette requête parce qu’elle n’est pas conforme. Toute requête HTTP 1.1 doit comporter dans son en-tête un champ « Host: »
Exemple :
GET /page.html HTTP/1.1
Host: monsite.com
Ensuite modifier le jail.conf comme ceci :
[apache-overflows]
enabled = true
port = http,https
filter = apache-overflows
logpath = /var/log/apache*/*error.log
maxretry = 1
Puis redémarrer Fail2Ban pour activer le nouveau filtre.
sudo /etc/init.d/fail2ban restart
Liens :
Voici le site de Fail2Ban ou vous trouverez pas mal d’info.
Et le site spamcleaner.org ou vous trouverez une autre méthode pour bloquer les w00tw00t directement via iptables et sans Fail2Ban, et pas mal d’autre infos sur la sécurité anti spam.
Personnellement je ne recommande pas cette méthode de spamcleaner car si vous héberger un forum ou un webmail, n’importe qui postant un sujet où un email avec w00tw00t dans le messages sera banni avec iptables.
Commentaires récents