Scans web, engluer les requètes automatisées

Aujourd’hui un petit billet pour s’amuser un peu avec les scripts kiddies.

Si vous hébergez votre propre serveur web, vous avez sûrement remarqué l’accès indésirable à votre serveur http par des requêtes plus ou moins automatisées dans le but de découvrir une faille potentielle.

Dans le genre :

[Sun Jul 12 06:26:57 2009] [error] [client 1.2.3.4] File does not
exist: /var/www/phpmyadmin
[Sun Jul 12 06:26:58 2009] [error] [client 1.2.3.4] File does not
exist: /var/www/phpMyAdmin

Bien entendu, en bon admin que vous êtes, vous avez greffé ModSecurity sur votre Apache préféré, ce qui limite grandement la casse et renvoi le petit merdeux bonhomme dans sa chaumière avec un joli code 400 :

[Wed Jul 15 19:30:36 2009] [error] [client 87.229.108.30] ModSecurity: Warning. Operator EQ match: 0. [id "960009"] [msg "Request Missing a User Agent Header"] [severity "WARNING"] [hostname "1.2.3.4"] [uri "/phpMyAdmin/main.php"] [unique_id "6cDOIV4XBY0AABEgIhMAAAAD"]
[Wed Jul 15 19:30:36 2009] [error] [client 87.229.108.30] ModSecurity: Access denied with code 400 (phase 2). Pattern match "^[\\\\d\\\\.]+$" at REQUEST_HEADERS:Host. [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"] [hostname "1.2.3.4"] [uri "/phpMyAdmin/main.php"] [unique_id "6cDOIV4XBY0AABEgIhMAAAAD"]

Et bien sûr couplé également à un fail2ban ou un ossec dans les règles :

/var/ossec/active-response/ossec-hids-responses.log
Wed Jul 15 19:30:36 CET 2009
/var/ossec/active-response/bin/firewall-drop.sh add - 87.229.108.30

Pan, gant Mapa, gravier et bonjour chez toi

C’est bien mais moi, qu’on vienne m’embêter, je n’aime pas ça et sadique comme je sais l’être, je suis assez fervent de rendre la monnaie de leur pièces a ces « cliqueurs-de-truc-ki-marche-tout-seul-pour-hack »

Donc j’ai chercher un moyen de m’amuser avec eux et surtout, ce qui est le pire pour un spammeur/script-kiddies, leur faire perdre du temps.

Cette technique d’engluage, appelée aussi « sticky honeypot », est déjà utilisée pour ralentir les vers, bots, etc… grâce à l’excellent LaBrea.

Ce programme est ce que l’on appele un « tarpit« . Un service réseau dont le seul but est de ralentir la connexion a ce service aussi longtemps que possible.

En effet, un spammeur pour qui l’envoi de masse et la rapidité sont primordiaux, si le serveur de mail en face met 10 secondes a lui répondre au lieu de 1 seconde, vous comprendrez qu’il a de quoi enrager…

Bref, je vous invite à lire les différents articles sur les liens données ci-dessus si vous voulez jouer avec cette technique (il y a même un patch Tarpit pour iptables ;-) )

  • ModSecurity, la solution qui va bien

Je cherchais une solution plutôt simple et rapide à mettre en oeuvre (après tout, ce n’est qu’un Proof of Concept :-D ), et utilisant déjà ModSecurity, il devait exister un moyen de combiner tout cela.

Après avoir fouillé la documentation et effectué quelques recherches sur le Nain Ternet, j’ai découvert une option magique de ModSecurity : « pause ».

Avant toutes choses, je vous invite fortement à utiliser l’excellentissime ModSecurity sur vos serveurs Apache. Vous trouverez de très bons articles et documentation sur le site de Breach (l’éditeur de ModSecurity, chez HSC, ou le tuto de Lindev.

Pour résumer, ModSecurity est un filtre qui va intercepter les requêtes adressées à votre serveur Apache et vérifier dans une liste de règles pré-définies ou écrites par vous si elles correspondent et réagir en conséquence.

Contre les injections SQL, les attaques transversales ou tout les petits trucs joyeux du monde web, c’est quand même ce qu’il se fait de mieux.

Bref, Modsecurity permet de définir ses propres « SecRule » et c’est cela que nous allons utiliser pour retarder les requètes.

Je considère que votre module ModSecurity est actif et fonctionnel.

Basons nous sur les scans « RoundCube » qui tourne actuellement suite à des failles de sécurité découvertes dans le Webmail (http://isc.sans.org/diary.html?storyid=5659).

J’utiliserais le fichier ./modsecurity.d/modsecurity_crs_15_custom_rules.conf pour intégrer mes règles :

SecRule REQUEST_URI "/roundcube" "pause:30000,log,status:400,deny"
SecRule REQUEST_URI "/roundcubemail" "pause:30000,log,status:400,deny"
SecRule REQUEST_URI "/roundcubemail-0.1" "pause:30000,log,status:400,deny"
SecRule REQUEST_URI "/roundcubemail-0.2" "pause:30000,log,status:400,deny"
SecRule REQUEST_URI "/roundcube-0.1" "pause:30000,log,status:400,deny"
SecRule REQUEST_URI "/roundcube-0.2" "pause:30000,log,status:400,deny"
SecRule REQUEST_URI "/round" "pause:30000,log,status:400,deny"

Petite explication.

- Je définis une règle de sécurité par le champ « SecRule »

- Je demande a ModSecurity de vérifier les requêtes qui contiennent le chemin /round, /roundcube, etc..

- Si la règle match, on attend 30000 millisecondes, on log, on sort une erreur 400 et un accès refusé.

Ne reste plus qu’a tester :-D   :

guiguiabloc@bofh:~$ wget -E -H -k -K -p http://monserveur.net/round
--15:05:54--  http://monserveur.net/round
=> `monserveur.net/round'
Résolution de monserveur.net... 12.34.56.67
Connexion vers monserveur.net|12.34.56.67|:80...connecté.
requête HTTP transmise, en attente de la réponse...400 Bad Request
15:06:25 ERREUR 400: Bad Request.
 
Terminé --15:06:25--
Téléchargement: 0 octets dans 0 fichiers

Ah Ah Ah ! Je me gausse :-) :-) :-)

Ou comment faire perdre du temps aux scanners web…

Je sais, ce n’est qu’une goutte d’eau dans le vase immense du Nain Ternet mais c’est fichtrement amusant…

Amusez vous bien :-D

PS : Ce billet me permet en même temps de remercier les colles Cleopatre pour toutes ses années d’école passées a les renifler :-p

Ce billet a été posté dans linux, sécurité et taggé , , . Bookmark ce permalink.

4 commentaires sur “Scans web, engluer les requètes automatisées

  1. hello

    pas mal ce truc et c’est efficace, now plus de w00tw00t.at.ISC.SANS.DFind

    car c’est chiant ca aussi :)

    merci

    ++

  2. Pingback: GuiguiAbloc, un blog qui merite d'être connu, technique, reseau, linux, système - linux - geek

  3. salut, concernant cette technique, si on ouvre plein de requêtes sur l’url en question, le serveur Apache risque de ne plus avoir assez de connexion et d’attendre les 30000 secondes avant qu’une connexion se libère …

  4. @plop bah oui, c’est pour cela que c’est juste « pour jouer » avec les bots scanner de web, aucunement pour mettre cela en production :) (et qu’en on mange plus de 700 connexions simultanées sur son site web, on a d’autres solution, du moins j’espère pour le webmaster :p )