Un peu de sécurité: log /w00tw00t.at.ISC.SANS.DFind:)

Un p’tit post orienté sécurité, enfin léger quand même 🙂

En parcourant les logs d’Apache sur mon serveur, je suis tombé sur pas mal d’entrées bizarres type /w00tw00t.at.ISC.SANS.DFind:)

Voici un extrait des logs exactes d’Apache:

[...]
[Sun Jun 24 03:39:36 2012] [error] [client 31.210.99.87] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 03:39:36 2012] [error] [client 31.210.99.87] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 03:43:27 2012] [error] [client 31.210.99.87] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 03:52:21 2012] [error] [client 31.210.99.87] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 03:56:43 2012] [error] [client 62.212.66.26] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 06:00:13 2012] [error] [client 31.210.99.87] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 06:13:58 2012] [error] [client 31.210.99.87] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 06:26:48 2012] [error] [client 31.210.99.87] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 06:26:48 2012] [error] [client 31.210.99.87] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[Sun Jun 24 06:37:36 2012] [error] [client 66.226.79.80] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)
[...]

Si votre IP se trouve dans la liste, j’ai deux mots à vous dire 😉

Bon, j’imagine des machines infectées par un quelconque virus qui scanne à tout va ou une attaque en règle de mon serveur à la recherche d’une quelconque faille (j’avoue, je me suis pas trop penché sur la question par manque de temps… j’vous avais dit que l’article allait être léger côté sécu ;-)).

Bref, ça pollue mes logs et ça m’énerve.

La solution la plus simple que j’ai trouvée et la plus rapide pour éviter d’être trop pollué, c’est la méthode à base de fail2ban, outil déjà installé et configurer sur mon serveur pour éviter les attaques de bourrin sur le service ssh, type attaque par dictionnaire.

L’idée est que si un client crée se genre d’entrée dans les logs Apache, alors il sera “banni” pour une durée déterminée (fixée dans le fichier de /etc/fail2ban/jail.conf de fail2ban).

Je rappelle au passage que le principe de fail2ban est de jeter un oeil en permanence aux fichiers de log (ceux que vous souhaitez) et à l’aide de filtres configurés, fail2ban bloquera (ou pas) les IP incriminées via iptables.

La chaine de traitement:

Connexion cliente louche -> Apache2 logs -> fail2ban analyze -> iptables => client bloqué au niveau réseau

Pour l’attaque qui nous concerne ici, il faut donc un filtre spécifique à insérer dans le fichier /etc/fail2ban/filter.d/apache-w00tw00t.conf (j’ai honte; j’ai récupéré ce fichier sur un autre site dont j’ai malheureusement perdu l’URL. Promis, si je le retrouve, j’ajoute le lien… le lien en début du fichier, je l’ai laissé mais y passe pas depuis la Chine):

# Based on http://howflow.com/tricks/block_w00tw00t_scan_hosts_with_fail2ban
# Real life exemaple:
# [Sat Jun 27 16:43:08 2009] [error] [client 94.23.57.77] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.DFind:)

[Definition]

# Option:  failregex
# Notes.:  regex to match the w00tw00t scan messages in the logfile.
# Values:  TEXT
failregex = ^.*\[client <HOST>\].*w00tw00t\.at\.ISC\.SANS\.DFind.*

# Option:  ignoreregex
# Notes.:  regex to ignore. If this regex matches, the line is ignored.
# Values:  TEXT
ignoreregex =

Ensuite, allez modifier le fichier /etc/fail2ban/jail.conf pour insérer le paragraphe:

[apache-w00tw00t]
enabled  = true
filter   = apache-w00tw00t
action   = iptables-allports
logpath  = /var/log/apache*/*error.log
maxretry = 1
# ban for 24h
bantime  = 86400

Bien sûr, à adapter suivant votre configuration… et votre niveau d’agacement 😉

Comme vous pouvez le déduire du maxretry fixé à 1, il faut qu’il y ait au moins une tentative pour que fail2ban détecte l’attaque… mais peut-être la tentative de trop si vos mots de passe sont tout pourris ou que vos applications contiennent une ou plusieurs failles de sécurité.

Donc: faisez gaffe !!

Leçons à retenir:

• matez régulièrement vos fichiers de log, ça peut vous en apprendre pas mal ;-), logwatch peut-être votre ami. Et là, vous me répondrez: “okay, mais j’ai un parc de plus 3000 serveurs; comment je fais pour mater tous les logs tous les jours ?”. Ce à quoi je répondrais: “bin vous avez qu’à embaucher plus de monde ;-)”… autre solution, adoptez une solution type log centralization associé à SEC (le “simple” est vraiment à mettre entre quotes) associé à votre outil de supervision habituel (Zabbix, Nagios, Centreon, etc….), très efficace;
• mettez à jour vos applications dès qu’une faille sécurité apparaît;
• choisissez des mots de passe costaux: votre moteur de recherche préféré pourra vous aider à trouver les règles/conseils de création de mots de passe solides.