37

Protéger votre blog d’un blast réalisé via des proxys anonymes

apache serveur HSL’un des blogs que j’héberge sur un serveur dédié été victime d’un blast bien sévère (ou mal paramétré?) hier soir…

Plusieurs tentatives de commentaires par seconde via la méthode POST, je vous laisse deviner la suite: un plantage du serveur Apache qui n’a pas tenu la charge, les requêtes en POST n’étant pas mises en cache par Varnish.

Voici comment j’ai pu bloquer l’attaque (pour que mon Apache ne soit pas cassé – cf photo).

Analyse des logs

J’ai tout d’abord dû rebooter le serveur électriquement puisque vu la charge CPU, la connexion SSH était inaccessible.
Ensuite via la commande #tail -100 /var/log/apache/access.log, j’ai pu constater de nombreux appels de la page /wp-comments.php d’un blog sur une des hôtes virtuelles.
L’adresse ‘IP était différente à chaque fois mais comme je récupère l’en-tête %{X-Forwarded-For} dans mes logs de cette manière

LogFormat "%{X-Forwarded-For}i %l %u %t "%r" %>s %b "%{Referer}i" "%{User-Agent}i"" combined

j’ai pu me rendre compte que c’était toujours la même IP qui se cachait derrière chaque proxy!

En effet, quand vous passer par un proxy anonyme (et non un High Anonymous Proxy – Elite), votre adresse IP n’est pas complètement masquée puisqu’elle est transportée dans les en-têtes HTTP via HTTP_X_FORWARDED_FOR.
Il me suffisait donc de bloquer l’adresse IP initiale du spammeur dans la configuration d’Apache.

Blocage de l’IP dans Apache

J’ai ouvert mon fichier de configuration Apache (ou .htaccess si vous n’y avez pas accès) en ajoutant la directive suivante:

RewriteCond %{HTTP:X-FORWARDED-FOR} ^123.45.67.89$
RewriteRule .* - [F]

* 123.45.67.89 est à remplacer par l’IP qui vous attaque.

Dès qu’une requête contenant l’adresse IP spécifiée dans l’en-tête X-forwarded-For est faite, une erreur 403 est retournée.
Me voilà débarrassé du spammeur, le serveur Apache tourne à nouveau correctement, sans utiliser toutes les ressources CPU: serveur OK 🙂
J’espère que cela vous sera utile.

37 commentaires

  1. Super astuce, comme d’habitude j’ai envie de dire. Je vais surveiller tous nos sites clients pour mettre en pratique ton truc dès que possible 🙂 Non, ce n’est pas une invitation au rodéo sur nos sites du TiPi 😉

  2. Merci pour cette astuce bien utile ! Si je comprends bien, puisqu’on a Spammeur -> Proxy -> Varnish -> Apache, le X-Forwarded-For renvoie toujours l’IP du spammeur (quand il n’a pas de proxy elite) ?

    • Il revoit l’IP du spammeur car la requête est en POST et dans ce cas, ça passe à travers Varnish et le Xforwarded correspond à l’IP de départ. En GET, on aurait juste l’IP du proxy à priori

  3. C’est bonnard comme manip pour se débarrasser des spammeurs acharnés.
    Faut dire qu’il y en a qui font preuve d’une obstination assez hallucinante, et qui souvent, n’ont pas encore trouvé le bouton qui permet de dé-doublonner les listes. J’ai des cas de gonzes qui blastent tous les deux jours toutes les pages d’un même WP.
    Thanks pour la solution !

  4. Bonne astuce mister.
    Après tu as une autre méthode qui t’évite de restreindre par IP. En règle générale (j’ai pas dis tout le temps hein), ce type d’attaque bourrine en frontal la page de commentaires en POST.
    Il suffit alors de faire un check du referrer et de bloquer tout ce qui vient pas de chez toi et qui n’est pas conforme à tes attentes ;).

    Après comme je viens de le dire, ce n’est pas le cas de toutes les attaques beaucoup de softs de spam – bien utilisés – permettent de contrer facilement la technique que je viens de citer.

    P.S. : En bloquant l’adresse avec IPTables, tu économiseras encore plus de ressources 🙂

    • Merci pour tes précisions 😉 Le referer est aussi une bonne alternative, mais comme tu le dit, ça ne marche pas tout le temps puisqu’il est assez simple de forcer le referer.
      J’ai essayé de bloquer l’IP via Iptables, mais comme elle est dans le X-Forwarded, je ne sais pas comment faire…

  5. Merci du partage : je le mets dans un coin en espérant ne jamais en avoir besoin ^^
    Par contre, dans le cas de l’utilisation de « bons » proxys privés, il y aurait une solution ?

  6. Maintenant, il faut nous donner la solution pour un mutualisé OVH 😀
    En tout cas ça aide pas mal.

    Si le spammeur utilise des proxy privés maintenant, quelle serait ta méthodologie pour bloquer toutes les tentatives de commentaire ?

  7. J’adore tes petites astuces 😉
    Il faudrait que tu pense à faire un ebook sur l’installation, la configuration, l’optimisation et la protection d’un serveur dédié pour les nul 😉

  8. A voir si tu ne peux pas directement configurer fail2ban et iptables pour prendre en compte les x-forwarded-for … j’ai trouve quelques resultats sur google, mais rien de concluant pour les 30 secondes que je m’etais allouees pour la recherche ;-).

  9. OMG

    ça c’est un article pour moi ! En ce moment j’ai pas mal de soucis avec des spammeurs qui cherchent des failles.
    Et qui surchargent inutilement mon serveur.

    Bon, Aymeric, ce qu’il faudrait, c’est une interface avec un champ qui alimente soit le .htaccess soit un fichier à partir duquel on lui bloque l’IP.
    Ce serait tellement mieux et plus rapide 🙂 #FAINEANT 🙂

  10. Salut Aymeric !

    Bonne idée. Perso, j’ai été un poil plus loin il y a quelques mois, en bloquant de la même manière via htaccess un range d’IP propre à un pays avec REMOTE_ADDR
    Ça peut un peu radical mais c’est efficace …

    J’étais la cible de centaines de personnes qui me spammaient comme des cochons. en provenance du Bénin pour ne pas le citer 😉

    Pour ceux que ça intéresse :

    RewriteCond %{REMOTE_ADDR} ^41\.[0-9]+\.[0-9]+\.[0-9]+
    RewriteRule .* – [F]

    Ça marche aussi en testant sur le GEOIP_COUNTRY_CODE

    Peu après ces coquins sont passés sur des proxys privés localisés en France … ^^
    J’ai sorti l’artillerie lourde :

    RewriteCond %{HTTP:VIA} !^$ [OR]
    RewriteCond %{HTTP:FORWARDED} !^$ [OR]
    RewriteCond %{HTTP:USERAGENT_VIA} !^$ [OR]
    RewriteCond %{HTTP:X_FORWARDED_FOR} !^$ [OR]
    RewriteCond %{HTTP:PROXY_CONNECTION} !^$ [OR]
    RewriteCond %{HTTP:XPROXY_CONNECTION} !^$ [OR]
    RewriteCond %{HTTP:HTTP_PC_REMOTE_ADDR} !^$ [OR]
    RewriteCond %{HTTP:HTTP_CLIENT_IP} !^$
    RewriteRule ^(.*)$ – [F]

    Je me coupe d’une certaine part de trafic, j’en suis conscient mais il faut savoir ce que l’on veut et adapter ces règles selon son taux de spam et le temps que l’on souhaite consacrer à la modération …

    PS : Quand est-ce qu’on se la fait cette bouffe ?

    • Tout à fait! mais cette plate-forme étant plus souvent spammé que le reste, j’ai volontairement utilisé WordPress dans le titre, mais bon je peux le remplacer par blog pour plus de clareté;)

  11. Super technique !
    Est-ce que le plugin wordpress qui s’appelle Bad Behavior permet de faire la même chose sans trop s’y connaître ?
    Merci pour l’astuce.

    • Hello, merci pour le plugin, je ne connaissais pas. Si Julien à travaillé dessus, j’ai une entière confiance;) au fait, j’ai acheté ton livre sur le Php, super bien expliqué et clair (surtout la partie POO), manque juste de contenus…!

      • Ah good ça, enfin un retour sur le livre =D

        Pas trop chiant le code en jaune ? Perso, j’ai tenté de faire changé ça à l’éditeur, mais pas moyen !

        Qu’est-ce que tu entends par « manque juste du contenu » ?

        Petit teasing : le mémento WordPress est prévue pour le 14 décembre 😉

          • Il est vrai qu’on n’a malheureusement pas eu le temps d’atteindre l’objectif des 250 pages. Quelques tutos qui été prévus initialement sont passés à la trappe. On les ajoutera très certainement lors de la prochaine édition.

            A part cela, tu es globalement satisfait ?

          • oui globalement satisfait! mais pour le prix je m’attendais à plus de contenu 😉 (pas encore regardé le CD)

  12. Je ne connaissais pas « HTTP:X_FORWARDED_FOR » et ca va m’être très pratique pour contrer certains arnaqueurs se cachant derrière des proxys, mais étant en fait très probablement localisés en Afrique.
    Le site en question n’utilise pas wordpress, mais au final cela revient au même.

    • Je confirme que CloudFlare contient un service de sécurité qui permet d’éviter de se faire spammer et il vire les IP qui attaque avec des requêtes un peu louche.

      Décidement, CloudFlare devient de plus en plus indispensable. Sécurité, mise en cache, que vont-ils encore nous servir ? =D

  13. Merci beaucoup Aymeric pour cette solution que tu as appliqué sur mon site. Tout fonctionne parfaitement bien désormais ! Je garde toutes ces infos de côté !

  14. Il devait y avoir beaucoup d’IP différentes utilisées non ? Car je suppose qu’il y a un système qui empêche de faire trop de requête à partir d’une même IP. Donc même s’il utilise peut être une 10aine de proxy, la sécurité devrait le bloquer non ?

  15. Zut, je me suis fait attraper, je savais que je n’aurais pas dû m’attaquer au site d’Aymeric 🙂

    Plus sérieusement, merci pour la manipulation, c’est vrai que c’est assez lassant de se faire blaster en masse. Comme quoi même dans le Black Hat il existe des limites à ne pas dépasser.

  16. Pour les amateurs (coucou c’est nous ^^), tu peux préciser le « blast » ? c’est un plantage c’est ça ? Cela arrive souvent ? Merci pour tes précisions, j’essaie de rattraper mes lacunes -_-

    • non, un blast (« souffle » en anglais), c’est une campagne de Spam visant à pousser un maximum de liens sur différentes plateformes.

  17. Excellent cet article, un blast c’est lourd mais comment faire avec les gars qui aspire juste une page de temps en temps, par exemple, le repérage est compliqué, en tout cas merci pour la formule bloquage IP.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *