But I don't like spam !

Les attaques de spam de commentaires sont devenues si courantes que le moindre site publiant son premier article sous Wordpress est à peu près certain de se retrouver ajouté dans les bases exploitées par des botnets dans les minutes qui suivent. Même si elles ont évolué avec les années, devenant de plus en plus violentes et industrialisées, elles ont toutefois toujours le même objectif : améliorer le positionnement de sites – pas toujours liés au viagra, poker, et autres emprunts toxiques – dans les moteurs de recherche.

Les attaques massives et réellement ciblées sont un peu plus rares, mais elles peuvent arriver sur des pages bien positionnées dans les moteurs de recherche. J’ai subi l’une d’entre-elles durant les deux derniers jours : 2.316.822 commentaires ont été postés sur un seul et même article par 1013 hôtes différents.

Comme le sujet m’intéresse, j’ai effectué une analyse post mortem de l’attaque que je vous propose de découvrir ici avant d’aborder les différentes manières de vous protéger, en fonction de vos possibilités.

La cible

En dix ans de blogging, c’est la première fois que je subis à une attaque aussi violente et ciblée sur un de mes sites. Je ne m’en suis aperçu qu’à la suite de la publication de certains commentaires. Le site n’a connu aucun pic de charge, et je ne me suis rendu compte de rien durant l’attaque. Ceci était un message adressé à ceux qui pensent que Rails ne scale pas et que Typo est un bloatware. Ça s’est dit.

L’attaque n’a ciblé qu’un seul article du site, sur plus de 1000 publiés. Ironie du sort, il s’agit de La sécurité du Web passera-t-elle par vous ?, un article sur les développements Web sécurisés. L’article avait eu pas mal d’échos et avait été bien relayé, au point de disposer pendant assez longtemps d’un Page Rank 6 jusqu’à la dernière Google Dance.

Je n’utilise pas Wordpress, ni un des outils de blogging les plus répandus, ce qui implique un scan préalable de la page afin de trouver les champs – particulièrement évidents – du formulaire de commentaires.

Analyse technique

L’attaque a commencé la 2 mai 2012 à 02:15 du matin, pour s’achever le 3 mai à 23:00, quand j’ai fermé les commentaires sur l’article ciblé. Sur plus de deux millions de commentaires, seule une cinquantaine a réussi à passer Akismet. Si une telle attaque vous arrive, n’essayez pas d’accéder à la page des commentaires via l’interface de votre outil de blog : avec une telle quantité de données, tout ce que vous obtiendrez sera une page blanche pour timeout ou pour avoir atteint le memory limit.

Supprimez simplement les commentaires en SQL dans la base de données. Nettoyez d’ailleurs régulièrement le spam de votre blog, cela limitera le nombre d’enregistrements sur lequel votre outil de blog doit travailler. Vous gagnerez ainsi en performances.

Vous obtiendrez la plupart des informations sur l’attaque en analysant les logs de votre serveur Web. Pas besoin d’aller chercher midi à quatorze heures, les outils UNIX de base sont largement suffisants.

Une fois la tempête passée, isolez les logs de l’attaque. Pour cela, j’ai concaténé les logs des trois derniers jours et lancé :

grep "la-securite-du-web-passera-t-elle-par-vous.html" access.log > evil.log

Pour être encore plus précis, limitez-vous aux requêtes POST, qui correspondent à l’envoi effectif des commentaires :

grep POST evil.log > even-more-evil.log

Vous obtiendrez un fichier dont toutes les lignes ressemblent à :

123.30.183.119 - - [03/May/2012:07:07:27 +0200] "POST /comments?article_id=7446 HTTP/1.1" 302 139 "https://t37.net/la-securite-du-web-passera-t-elle-par-vous.html" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

Chaque ligne des logs est divisée en plusieurs parties qu’il est intéressant d’analyser.

123.30.183.119 : l’adresse de la machine depuis laquelle l’attaque est menée. Elle permet de récupérer des informations utiles : nombre de machines utilisées, localisation géographique…

[03/May/2012:07:07:27 +0200] : la date à laquelle la requête HTTP a été effectuée. Cela permet d’analyser le nombre de commentaires par minute, et l’évolution de l’intensité de l’attaque dans le temps. J’ai un peu la flemme de sortir les chiffres exacts et de faire un zouli graphique, mais le flux a été à peu près constant d’un bout à l’autre de l’attaque.

"POST /comments?article_id=7446 HTTP/1.1" : le type de requête HTTP, la page appelée et la version de HTTP utilisée.

302 : le statut HTTP obtenu. Après appel à l’URL de publication du commentaire, l’utilisateur est redirigé vers l’article sur lequel ce dernier a été publié.

https://t37.net/la-securite-du-web-passera-t-elle-par-vous.html : le referrer, c’est à dire la page dont vient le visiteur. Il nous apprend que la page a été systématiquement chargée avant de publier le commentaire. L’attaquant aurait simplement pu envoyer des requêtes POST avec les bonnes données, mais ce n’est pas le cas. Cela signifie probablement qu’il s’agissait d’une page parmi une liste d’autres, et pas d’une attaque spécifiquement contre mon site.

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)" : le user agent. Il s’agit d’une trace laissée par chaque navigateur permettant de savoir à qui on à affaire. Un tour sur Google permet de savoir qu’il s’agit du user agent d’un botnet. Rien de très surprenant.

Pour extraire les adresses IP utilisées, un petit : cat eve-more-evil.log | cut -f 1 -d ' ' | sort -u vous permettra d’en récupérer la liste exhaustive. Un petit coup de GéoIP ou autre base de données permet de savoir que les attaques proviennent de Chine, du Viet Nam, de Thaïlande et d’Indonésie. Cela vous permettra du même coup de savoir combien d’hôtes différents vous ont attaqué.

Il pourrait être intéressant de suivre de près le comportement de chacun des hôtes dans le temps, les variations des attaques etc… mais là, franchement j’ai la flemme. Tout ce que je peux dire, c’est que l’attaque était soutenue, mais que chaque hôte ne devait pas attaquer trop violemment puisque les commentaires sont passés au compte goutte d’un bout à l’autre de l’attaque. Il n’y a donc pas eu de blacklist de ces hôtes, ou alors pas assez.

The Internet is for porn

L’attaque concernait des sites pornographiques montrant des jeunes filles pas vraiment en age de pratiquer ce genre de métier, du moins pas sous nos latitudes. Contrairement à ce que j’ai pu voir ces dernières années, les commentaires ne visaient pas à faire ranker directement le money site, mais des sites satellites installés sur des fermes de blogs gratuites un peu partout dans le monde proposant des liens en dofollow. La plate-forme de blogs de Free fait partie de ces sites relais.

Chacun des sites relais ne comporte qu’un seul article, un lien d’une ligne dans un h1 vers le money site avec les mots clés qui vont bien (et sur lesquels je ne tiens pas particulièrement à me positionner).

La majorité des commentaires était en anglais, mais une partie d’entre eux était en indonésien, bien que les ancres des liens fussent en anglais. Toute la sémantique du thème abordé est utilisé dans du texte visiblement généré avec un outil de spinning.

Contenu des spams

On distingue à ce propos deux types de contenus :

  • Des contenus directement liés à la thématique abordée avec un certain sens, même si ce dernier se trouve alteré par le spinning.
  • Des contenus mélangés avec des extraits de spams plus classiques dans d’autres thématiques : emprunts, voyages, diplômes, banque… avec le vocabulaire qui va bien au milieu.

Comment se protéger

Avec une capote pas percée. Il existe différentes manières de se protéger d’une attaque, en fonction de vos compétences techniques, et des possibilités que vous laisse votre hébergeur. J’avoue avoir fait simple et efficace : il était tard et j’étais crevé, donc j’ai fermé les commentaires sur l’article visé.

La solution globale la plus simple consiste à utiliser un anti spam, installé localement comme Spam Karma, ou hébergé comme Akismet. Notez que ces outils ne sont pas infaillibles : il arrive qu’ils laissent passer des commentaires visiblement spammy, on parlera de faux négatifs, ou bloquent au contraire des commentaires tout à fait légitimes, et on parlera de faux positifs. Une vérification manuelle régulière est donc recommandée.

La solution la plus extrême consiste à bloquer les blocs IP des pays posant problème, en considérant nulle ou quasi nulle le fait qu’une personne de ce pays puisse être un visiteur légitime. Elle exige que vous ayez les droits d’administration sur votre machine, et je ne suis pas du tout fan de bloquer l’accès à un site à une partie du monde si aucune règle juridique ne l’exige.

Une bonne solution intermédiaire consiste à utiliser Fail2Ban. Fail2Ban bloque temporairement les indélicats en fonction d’un certain nombre de règles, à partir de l’analyse de vos fichiers de logs. En pratique, il peut être utilisé pour faire à peu près n’importe quoi dès que les conditions spécifiées sont réunies.

Il reste que, tout comme la lutte contre les virus, la lutte contre le spam est une course sans fin passée à courir derrière les spammeurs. Même s’il est possible de tentre de prévoir les comportements et les thématiques à venir, ils auront toujours une longueur d’avance sur les outils chargés de les contrer, et ils s’y connaissent pour innover.

Perry the Platypus wants you to subscribe now! Even if you don't visit my site on a regular basis, you can get the latest posts delivered to you for free via Email: