Nat 1 – Spam 0

Je viens de subir ma première attaque de spam, arrêtée avec une facilité presque décevante.

Attention : des détails techniques hautement geek se trouvent dans la suite.

Partie 1 : l'approche

Le lundi 25 juin, à 23h51 heure locale, j'ai eu une visite un peu curieuse, très probablement d'un spammeur.

Déjà, quelqu'un qui débarque sur http://vibrissae.org/fr/dessine-moi-un-mouton, c'est louche, parce que vibrissae.org n'existe pas comme domaine, il y a seulement www.vibrissae.org.

Ça n'a l'air de rien, mais c'est important, parce que je ne vais pas maintenir deux domaines parallèles, même si c'est pour mettre la même chose dessus. Donc je n'ai qu'un seul site, www.vibrissae.org, et informatiquement c'est celui-là qui existe partout.

Évidemment, comme les humains sont faillibles, il peut arriver qu'ils essayent à la place d'aller sur vibrissae.org, c'est pour ça que ça marche aussi. Techniquement, je fais une redirection permanente (301) de toutes les pages valides vers leur homonyme sur www.vibrissae.org, les autres génèrent un 404 normal de base.

Donc pour tomber sur http://vibrissae.org/fr/dessine-moi-un-mouton, il faut soit l'entrer à la main ; soit avoir suivi un lien d'une page 404, mais comme aucun 404 n'a été servi sur vibrissae.org, ce n'est pas possible. Par contre j'aimerais bien savoir comment il a obtenu cette adresse à la base.

Ensuite, deuxième chose étrange, il prétend utiliser un Opera 7.54 en russe, mais il ne charge pas le CSS. Je suis consciente qu'il existe des utilisateurs légitime qui ne supportent pas le CSS, j'en fais moi-même partie quand je sors links, un navigateur en mode texte. D'ailleurs ce site est prévu pour rester utilisable sans CSS. Mais cela ne change rien au fait que quelqu'un qui débarque sans charger le CSS, c'est louche.

Enfin, ce moteur répond toujours un See other (302, pour être compatible avec les vieux navigateurs, en théorie il faudrait utiliser 303) à une requête POST qui n'a pas causé d'erreur. La troisième chose étrange de cette visite est que le GET normalement causé par le 302 ne vient pas de la même adresse IP que le POST. Là encore, ça peut être légitime, par exemple pour quelqu'un qui utilise un réseau de proxies. Mais quand même, ça commence à faire beaucoup.

Ce qui a vraiment fait passer ce visiteur de spammeur présumé à spammeur avéré, c'est le contenu du commentaire laissé, bourré de viagra, de Cialis, de toutes les formes possible de lien dans les moteurs usuel, et même de l'insertion d'un redirect javascript. D'ailleurs une question qui me travaille depuis que je suis confrontée au spam, je suis censée faire quoi avec du viagra ?

Et malheureusement pour lui, le nombre de visiteurs démentiels sur ce site a fait que personne n'a vu son commentaire, en dehors de moi, qui n'en ai vu que le source (je manipule directement la base de données).

Partie 2 : Nat réagit

Tous les liens sur ce site sont des chemins absolus, et comme la page servie sur vibrissae.org est la page 404, qui n'a pas de formulaire, je ne devrais recevoir des requêtes POST que sur www.vibrissae.org.

Dans ce moteur, au niveau de la gestion des requêtes pour les pages existentes, il y a trois blocs de code : d'abord si la requête est POST, qui ajoute le commentaire et renvoit un 302 ; ensuite si la requête n'est pas pour www.vibrissae.org, renvoyer un 301 vers le même chemin sur www.vibrissae.org ; enfin si tous ces tests sont négatifs, afficher normalement la page.

Vu qu'il n'est pas censé y avoir de POST sur vibrissae.org, les deux premiers blocs de code devraient pouvoir être échangés sans que ça change quoi que ce soit. Mais dans le cas particulier de notre spammeur, ça change que dans l'ordre ci-dessus, sont POST conduit à l'ajout d'un commentaire, alors que si j'échange les deux il se prend juste une redicrection permanente 301, sans toucher à la base de données.

Je ne sais pas si le protocle a une recommendation pour cette situation, mais je considère que le 301 est là pour remettre les gens dans le droit chemin, et il n'y a pas de raison qu'une requête sur vibrissae.org modifie la base de données de www.vibrissae.org.

Accessoirement, en plus de faire le test du 301 avant celui du POST, j'ai codé un p'tit antispam de base, mais comme il n'a jamais servi je ne vais pas en reparler.

Partie 3 : Début des hostilités

Le 27 juin à 6h07, je reçois le premier d'une longue série de spam présumés. Je ne peux que présumer, parce que le contenu du commentaire qui aurait été ajouté n'est pas sauvegardé.

Pendant les vingt-quatre heures qui vont de ce premier post au lendemain à la même heure, j'ai reçu 41 requêtes POST sur vibrissae.org, toujours sur la même page, toujours depuis des IP résidentielles à l'étranger, toujours par Opera 7.54 en russe, sans jamais de GET avant (ça c'est quand même fort) et sans jamais suivre la redirection donnée en réponse.

Conclusion

Il aura fallu vingt-trois jours pour qu'un spammeur trouve le présent blog. Il m'a fallu une vingtaine de secondes pour supprimer son post de test, et quatre secondes pour coder une parade que l'on peut estimer parfaite (100% de réussite et aucun faux-positif).

Au suivant !

Publié le jeudi 28 juin 2007 à 10:08.

Catégorie(s) : Geek Site

Commentaires

1. Le lundi 2 juillet 2007 à 0:49, par ralphy :

Il est rarrissime que l'on s'attaque à mon site en le spammant. En fait, autant que possible, j'évite de faire référence aux technologies de publication en ligne que je publie sur ce blog, enfin plutôt que les encode en JavaScript, de sorte à éviter que les moteurs de recherche indexent cette partie du code, car les moteurs de recherche sont les principales sources de pages à spammer pour les spammeurs. Ils recherchent des "Powered by [technologie de blogging]" qui apparaissent souvent au bas des pages, et autres "inurl:post.php" qui leur indiquent les formulaires à spammer en priorité. Mais ton blog non plus ne fait pas apparaître ces mots-clés typiques des blogs. Aussi, je suis étonné.

Mais le coup du JavaScript de redirection, j'avoue, je n'avais encore jamais connu ! Il faut dire que les formulaires de commentaires de mes blogs sont normalement filtrés avant publication, de sorte que les commentaires comportant du JavaScript ne passent même pas dans l'interface d'administration : ils sont tout bonnement refusés.

Cela étant, note que les spammeurs humains sont rares, et quand ils spamment, ce sont des millions de pages web par campagne de spam, que ce soit en nombre de tentatives de publications de commentaires sur les blogs ou en emails envoyés... Je crains que des réponses manuelles ne soient que veines, les spammeurs tentent d'automatiser autant que possible leurs campagnes, et de préférence les mener via un réseau d'ordinateurs zombies dirigés via des serveurs IRC qui obtiennent des ordres via plusieurs niveaux de proxies anonymes, protégés eux-mêmes soit par des réseaux de type TOR, soit par une ribambelle d'autres ordinateurs zombies... :-(

2. Le lundi 2 juillet 2007 à 10:31, par Natacha :

Je ne sais pas trop comment les spammeurs trouvent leurs cibles, et il probable qu'à ce niveau il y ait plusieurs sortes de spammeurs. Il me semble cependant raisonnable de penser qu'au moins une partie d'entre eux ont leur propres crawlers qui parcourent le web à la recherche de forms. J'aimerais quand même bien savoir d'où sortent les liens sur vibrissae.org, parce que le YahooBot m'a aussi demandé http://vibrissae.org/fr/dessine-moi-un-mouton.

C'est vrai que dans cet article j'ai peut-être trop considéré « le spammeur » comme un être humain. Lorsqu'on dispose d'une armée de zombis (avec quelques dédiés compromis) je pense qu'on peut se permettre d'en faire des crawlers, qui à chaque form trouvée essayent de poster quelque chose, puis enchaînent avec un GET du résultat, et s'ils retrouvent dans le résultat quelque chose qui ressemble à ce qu'ils ont posté, ils considèrent l'adresse comme spammable et l'ajoutent à une base de donnée centralisée. Ce modèle colle à mes observations, et il me semble assez simple pour plaire à Occam, tout en ne nécessitant absolument aucune intervention humaine.

La force du moteur Lithium Blog est qu'il représente une part de marché tellement faible qu'aucun spammeur ne s'attaquera spécifiquement à lui, donc leur seule chance est de devenir indiscernable du posteur légitime. J'ai encore une bonne palette de mesures que je garde dans ma manche, que j'implémenterai quand j'en ressentirai le besoin. En vrac, j'ai au moins l'ajout d'un timestamp en champ caché, vérifier que l'IP qui poste a déjà chargé d'autres pages, ou certaines pages spécifiques (par exemple la feuille de style), le changement du nom des champs du formulaire, le scan de certaines séquences dans le contenu (comme <script ou [url) ; le tout sans avoir peur des faux-positifs vu que tout est archivé dans un format facile à réinsérer dans la base de données. Et si tout le reste devait échouer, ce qui me surprendrait quand même, il reste des mesures drastiques comme la modération systématique ou la création du form par JavaScript.

Copyright © 2007-2008 Natacha Kerensikova