En mai 2008, on note le pic (il dépasse 130 POST/jour) qui correspond à très peu de user agents différents (1 à 2, suivant le jour). Alors que dans le reste de la période la courbe du nombre de POST est très proche de la courbe du nombre d'UA différents.
À noter que, plutôt que de me limiter au seul User Agent, j'ai fait ma petite analyse sur la concaténation des variables HTTP_USER_AGENT, HTTP_ACCEPT, HTTP_ACCEPT_LANGUAGE, et HTTP_ACCEPT_ENCODING. On obtient ainsi une meilleure discrimination entre les différents attaquants.

Voici un exemple abrégé de capture :

REQUEST_TIME : 2008-12-09 19:51:33
HTTP_HOST : www.patpro.net
REMOTE_ADDR : 88.198.53.43
HTTP_USER_AGENT : Mozilla/5.0 (Windows; U; Windows NT 5.0; ru; rv:1.8.1.6)
                  Gecko/20070725 Firefox/2.0.0.6
HTTP_ACCEPT : text/xml, application/xml, application/xhtml+xml,
              text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
HTTP_ACCEPT_LANGUAGE : ru
HTTP_ACCEPT_ENCODING : deflate

Si on s'intéresse particulièrement aux variables HTTP_ACCEPT* on voit qu'elles sont utilisées de manières très inégales en fonction du robot :

On peut supposer que ces caractéristiques permettent de différencier les différents botnets, et versions des scripts. Les spammers poussent donc le raffinement assez loin, dans le but, bien sûr, de passer au travers des protections antispam. Dans certaines tentatives que j'ai enregistrées, le client fourni même un cookie de session.

Je rappelle à toutes fins utiles que, si le cœur vous en dit, vous pouvez télécharger le "plug-in" signal-spam pour Mail, qui permet de déclarer votre spam à l'organisme paresseux nommé Signal Spam (c'est pas bien de se moquer, méchant patpro).

Pour plus de simplicité, je laisse periodic lancer le script chaque nuit vers 3h15. Je crée donc un fichier /usr/local/etc/periodic/daily/310.spamhaus_dropall exécutable, et en lecture uniquement (sauf pour root).

Je dois aussi créer une table spamhaus_dropall dans la configuration de PF en ajoutant les lignes suivantes à mon /etc/pf.conf :

Dans les définitions de tables :

table <spamhaus_dropall> persist { }

Dans les règles proprement dites :

block in log quick proto tcp from <spamhaus_dropall> to any

Cette table, vide par défaut, va stocker le contenu filtré de la liste DROP, et sera mise à jour toutes les nuits.
Ensuite je force pf à relire la configuration par la commande pfctl -vf pf.conf.

Voici le code du script, à écrire dans /usr/local/etc/periodic/daily/310.spamhaus_dropall :

#!/usr/local/bin/bash
echo  downloading/cleaning blacklist drop.lasso
TMPFILE=`mktemp /tmp/drop.XXXXXX` || exit 1

/usr/local/bin/curl -s http://www.spamhaus.org/drop/drop.lasso | \
    sed 's, ;.*,,' | \
    egrep '^([0-9]{1,3}\.){3}[0-9]{1,3}/[0-9]{1,2}*$' > \
    ${TMPFILE}

echo  flushing the spamhaus_dropall table
egrep -v '^127|^WHITELIST' ${TMPFILE} | \
    pfctl -t spamhaus_dropall -vT replace -f -

La première étape consiste à télécharger la liste. Dans la foulée, les commandes sed et egrep me permettent de nettoyer et filtrer le contenu du fichier envoyé par Spamhaus.
Le fichier original ressemble à ceci :

; Spamhaus DROP List 11/24/08 - (c) 2008 The Spamhaus Project
116.199.128.0/19 ; SBL56563
116.50.8.0/21 ; SBL54501
128.199.0.0/16 ; SBL62478

Le fichier filtré et nettoyé, dont le contenu est écrit dans le fichier temporaire TMPFILE ressemble à cela :

116.199.128.0/19
116.50.8.0/21
128.199.0.0/16

L'étape suivante consiste à injecter les nouveaux blocs d'IP dans la table pour les faire prendre en compte par le firewall. Par mesure de précaution, j'ai choisi de filtrer ici les IP de la classe 127.0.0.0/8 ainsi que toutes les IP dont je ne veux absolument pas qu'elles figurent dans la blacklist. On n'est jamais à l'abri d'un dysfonctionnement de Spamhaus, ou du script, ou d'une malveillance locale sur la machine. Je remplace donc ^WHITELIST par tous les préfixes d'IP que je juge nécessaire (par exemple ^83.225. si mon IP résidentielle commence par "83.225"), et je les sépare par un |.
La commande egrep -v me permet donc d'exclure toutes les lignes que je veux sortir de la liste, et envoie le reste à pfctl pour remplacer le contenu de la table spamhaus_dropall par les nouvelles IP.

Voici un exemple de sortie, telle qu'elle apparaît dans le mail de daily :

downloading/cleaning blacklist drop.lasso
flushing the spamhaus_dropall table
8 addresses added.
1 addresses deleted.
A  192.43.153.0/24
A  192.43.154.0/23
A  192.43.156.0/22
A  192.43.160.0/24
A  192.86.85.0/24
A  78.157.128.0/19
A  91.209.14.0/24
A  94.176.96.0/20
D  94.176.96.0/21

Le script est bien sûr perfectible. Mais c'est une base de travail qui fonctionne.

Ce qui porte à sourire dans tout ce gourbi c'est l'acharnement des spammers à cibler les articles qui parlent justement de spam. Sur le total de spam bloqué, 25% des tentatives sont faites sur l'article le spam sur les blogs et les forums, et 20% visent l'article plug-in signal spam pour mail

J'ai donc eu envie de fabriquer un petit "plug-in" pour mon client de messagerie : Apple Mail. J'ai utilisé comme base de travail le script shell de Stéphane Bortzmeyer qui présente l'avantage énorme de partir d'Openssl et de cUrl, tous deux fournis dans Mac OS X. J'ai conçu, autour de cette base, un script AppleScript qui permet l'interaction avec Mail.

Téléchargement

Vous trouverez toujours la dernière version du script à cet endroit. Pour plus de simplicité, je ne donne pas de numéro de distribution, mais uniquement le numéro de version svn du fichier (plus récent en haut) :

version 116 de signal-spam.scpt | sources au format txt | changelog cf. commentaires
version 66 de signal-spam.scpt | sources au format txt | changelog cf. commentaires
version 65 de signal-spam.scpt | sources au format txt | changelog cf. commentaires - mise à jour de sécurité
version 64 de signal-spam.scpt | sources au format txt | changelog cf. commentaires
version 63 de signal-spam.scpt | sources au format txt | changelog cf. commentaires
version 61 de signal-spam.scpt | sources au format txt

Installation et utilisation

Avant d'utiliser ce script, vous devez disposer d'un compte utilisateur sur le site signal-spam.fr. Une fois cette formalité accomplie, copiez ce script dans votre dossier "Library/Scripts/Mail Scripts/" (en français "Bibliotheque/Scripts/Mail Scripts/"). Ensuite, ouvrez ce script par un double-click. Le script vous demande alors votre identifiant puis votre mot de passe signal-spam. Saisissez ces paramètres, puis enregistrez le script. Ainsi, vos identifiants de connexion sont enregistrés dans le script qui pourra fonctionner sans que vous ayez à les ressaisir à chaque utilisation. Si vous désirer modifier le login et/ou le mot de passe il vous suffit de rouvrir le script, et de saisir les nouveaux paramètres. N'oubliez pas d'enregistrer à nouveau le script.
Pour que ce script soit utilisable dans Mail, il vous faut activer le "script menu" (). Vous pouvez activer ce menu grace à l'utilitaire "AppleScript Utility.app" qui se trouve dans le dossier "/Applications/AppleScript/". Ensuite, dans Mail, sélectionnez les messages que vous souhaitez signaler, puis dans le "script menu" choisissez "signal-spam". Voilà !

Le script est conçu pour retourner les codes d'erreurs HTTP que le serveur signal-spam.fr lui renvoie. L'erreur probablement la plus courante est la "400". Un code d'erreur "400" signifie que "quelque chose" ne s'est pas bien déroulé. C'est en général du à une erreur de login ou de mot de passe.

Nouveauté de la version 64 : Si vous êtes un utilisateur de Growl, vous pouvez installer l'Extra growlnotify qui est fourni dans l'image disque de Growl. Cet utilitaire permet de piloter Growl en ligne de commande, et c'est le mode de notification qui a été choisi pour le script signal-spam. Le script détecte automatiquement la présence de growlnotify dans le répertoire /usr/local/bin, et poste une notification visuelle si ce dernier est présent.

Licence

Ce script est fourni sans garantie, et sous licence BSD. Ce qui signifie très grossièrement que vous pouvez en faire ce que vous voulez à condition de mentionner les auteurs, y compris en faire un produit commercial.

N'hésitez pas à me laisser un petit mot si vous utilisez ce script, ou si vous rencontrer des problèmes avec lui.

121.134.43.80		208.101.5.141		64.72.127.155
125.18.15.102		209.67.219.74		66.7.192.34
125.189.49.45		210.64.156.40		66.79.164.130
163.28.33.226		210.87.251.107		67.128.2.9
165.228.130.12		212.138.64.171		67.172.170.196
165.228.133.11		212.138.64.176		67.185.5.14
193.69.180.120		212.150.97.114		68.178.206.47
193.85.227.42		213.115.205.82		68.85.25.214
200.179.190.126		213.173.239.33		69.57.190.138
200.201.183.18		217.158.155.13		69.61.55.202
200.209.172.246		218.41.52.250		72.29.95.61
200.88.125.9		218.72.250.54		74.118.183.154
200.88.223.98		220.226.63.254		74.134.113.31
201.17.253.65		24.226.153.18		74.52.44.34
201.39.75.130		4.78.211.221		80.227.0.156
201.6.84.126		59.144.155.17		81.211.102.38
201.80.4.156		59.94.244.169		82.179.244.68
203.121.69.154		59.95.5.57		82.234.90.177
203.144.160.250		61.205.234.121		83.206.200.105
205.234.106.105		61.240.111.196		84.54.132.26
207.36.196.10		61.6.54.241		85.105.85.189
208.101.5.140		62.212.81.166		89.178.64.57

Et pour rire, le top 5 des URL sur lesquelles ils se sont acharnés :

40 …/index.php/2006/11/26/67-le-spam-sur-les-blogs-et-les-forums
11 …/index.php/2006/11/26/67-le-spam-sur-les-blogs-et-les-forums/register.php
 9 …/tb.php?id=60
 9 …/tb.php?id=49
 5 …/tb.php?id=30

Fin novembre je proposais quelques trucs pour esquiver une partie du spam de blogs robotisé. Je précisais que les scripts du moment faisaient des erreurs faciles à déceler, et donc à exploiter pour se protéger contre ces invasions barbares numériques.
Il aura fallu environ 20 jours pour que les spammers corrigent leurs moulinettes de tous les défauts que j'avais relevés. Pour le coup, je me sens presque coupable. Maintenant ils font un GET avant le POST, et non plus après. Ils envoient aussi des informations cohérentes à propos du navigateur prétendument utilisé, et font l'effort de simuler un "referer" qui pourrait être valide (même si il est évident pour l'oeil humain que le referer est bidonné).

Il est amusant de noter que depuis la mi-décembre, ces spammers qui ont adapté leurs attaques s'acharnent sur l'article dans lequel je parle du spam de blogs. Je compte 18 tentatives de spam contre cet article, sur un total de 21 tentatives "nouvelle formule".
Bref, tout cela n'est pas si drôle finalement et il va bien falloir trouver une parade. Comme je veux absolument éviter les méthodes invasives (celles qui touchent au code de l'application, ou qui dépendent de l'interpréteur de ce code), ça me donne un maximum de fil à retordre. Pour moi, l'idéal serait une méthode impliquant un module Apache, du style mod_access, mod_access_rbl, mod_usertrack, ... Il y a peu, je me prenais même à rêver de l'existence d'un mod_p0f, mais réfléxion faite, c'est pratiquement inutilisable.
Toutes les idées sont les bienvenues d'ailleurs.

La première chose à comprendre c'est qu'aucune méthode automatique n'est infaillible. Seule une modération manuelle, par un humain en pleine possession de ses moyens, peut bloquer tout le spam qui serait posté à destination d'un forum ou d'un blog. Ceci posé, voilà quelques conseils pour filtrer un peu la crasse du monde.

Dans 99% des cas, le spammer utilise un outil automatisé pour poster la prose de son client. Ces outils sont de plus en plus perfectionnés et parviennent même à contourner des protections comme les "captcha", ces images représentant des lettres et des chiffres tordus et brouillés que l'utilisateur doit déchiffrer et recopier au clavier dans un champ du formulaire. De nombreux systèmes de "captcha" étaient, ou sont encore, vulnérables à une attaque toute bête : le spammer se connecte une fois manuellement en reconnaissant les chiffres et les lettres lui-même. Il remplit le formulaire, et le valide. Il obtient alors un identifiant de session qu'il va coller dans son script de spam. Le script peut ensuite poster autant de message qu'il veut, sans avoir à valider le test de la captcha. C'est un exemple parfait de porte blindée sur un mur en carton. Moralité, il ne faut pas non plus faire confiance aux systèmes de protection, surtout si on ne sait pas comment ils fonctionnent. Pire, le système de "captcha" est contraignant et même très problématique en terme d'accessibilité. Que devient l'utilisateur malvoyant face à ce blocage ?
Fort heureusement, on voit fleurir quelques systèmes comparables qui ont au moins le soucis de la lisibilité. Certains formulaires, par exemple, sont protégés par des opérations mathématiques du style "combien font deux fois trois en chiffres". L'utilisateur, même si il utilise un terminal braille ou un logiciel de lecture d'écran est à même de répondre à cette question, et donc de poster un message sur le forum ou le blog protégé.

Heureusement, pour le moment, les outils de spam automatiques ont des défauts. Cela ne va pas durer, mais il est encore possible d'utiliser ces faiblesses pour les contrecarrer. Ainsi, l'administrateur attentif, verra dans les logs de son site web des choses intéressantes comme ça :

209.160.72.10 ../.. "POST /blog/tb.php?id=37 HTTP/1.1" 403 112 "-" "-"
209.160.72.10 ../.. "GET /blog/index.php../.. HTTP/1.1" 200 11211 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ../..) ../.. Firefox/1.5.0.4"
209.160.72.10 ../.. "POST /blog/tb.php?id=45 HTTP/1.1" 403 112 "-" "-"
209.160.72.10 ../.. "GET /blog/index.php../.. HTTP/1.1" 200 10770 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; ../..) ../.. Firefox/1.5.0.4

C'est un parfait exemple de script de spam codé par un débile. Ce qu'on note immédiatement, c'est le code 403 de retour pour la méthode POST, et le code 200 pour le GET suivant. Je reviendrais la dessus par la suite. On note aussi que le POST est fait avec un "browser" et un "referer" tous deux nuls ("-" "-"), alors que le GET est fait avec un "browser" réglé sur Firefox 1.5.x Windows, première erreur. Seconde erreur, le GET est fait après le POST, quelle idée farfelue : normalement, l'utilisateur charge une page dans son navigateur, puis poste un commentaire sur la page en question, pas l'inverse. Troisième erreur, le navigateur simulé est un Firefox Windows. Or, c'est en contradiction avec le pédigrée de la machine :

$ ssh -v 209.160.72.10
../..
debug1: Connecting to 209.160.72.10 [209.160.72.10] port 22.
debug1: Connection established.
../..
debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 FreeBSD-20040419
debug1: match: OpenSSH_3.8.1p1 FreeBSD-20040419 pat OpenSSH_3.*
../..

Un vieux FreeBSD, avec un vieux OpenSSH. Sûrement une machine mal patchée chez un hébergeur peu scrupuleux. C'est rapidement confirmé par un whois. La machine fait partie d'une ferme de serveurs d'hébergement de sites web. Donc en réalité, cette machine ne devrait jamais se connecter à un forum ou un blog pour y poster des commentaires. Quatrième erreur, le script simule un navigateur, mais il ne télécharge pas les images, les scripts javascript, ni les feuilles de styles de la page. C'est peu crédible. Pour finir avec ce cas d'école, le script essaye de poster du spam vers sa cible environ une fois par heure, 24h sur 24, ce n'est pas très réaliste et ça écarte du même coup toute présomption de spam manuel.
Revenons rapidement sur les codes 403 et 200 relevés plus haut. Le code 403 signifie que la requête (POST) à été interdite par le serveur, donc le script n'a pas pu poster son spam. Le code 200 accompagne une réponse favorable à une requête (ici, le GET). Donc le script peut lire la page mais pas poster de commentaires ou de trackback. Pour obtenir ce résultat, il faut bricoler un peu la configuration Apache, soit dans la configuration du serveur, soit via un fichier .htaccess.
Voilà un exemple :

01       ErrorDocument 403 "Due to an heavy spamming problem, you are not allowed to post any data on this blog."
02       # si browser OU referer sont nuls, on trash
03       BrowserMatch ^$ GoAway=1
04       SetEnvIf Referer ^$ GoAway=1
05       # si browser est une escroquerie, on trash
06       BrowserMatch ^PussyCat GoAway=1
07       BrowserMatch ^Opera/8.0$ GoAway=1
08       <LimitExcept GET>
09          Deny from env=GoAway
10       </LimitExcept>

La ligne 1 donne un message personnalisé pour l'erreur 403, au cas où un lecteur légitime se retrouverait bloqué par le système au moment d'envoyer un message ou un commentaire. Les lignes 3 et 4 règlent la variable d'environnement "GoAway" à "1" si le navigateur est nul ou si le "referer" est nul. Les lignes 6 et 7 reprennent deux signatures de navigateurs qui sont bidons et qui sont utilisées par des scripts de spam. De même, si cette signature est trouvée, alors la variable "GoAway" passe à "1".
Le bloc 8-9-10 interdit aux clients dont la variable "GoAway" est définie de faire autre chose que des GET. Donc pour tous les clients qui ont une variable "GoAway" définie, le GET est autorisé, et le POST est interdit (ainsi que le HEAD et les autres méthodes).
Notre client de tout à l'heure, 209.160.72.10, arrive sans "browser" ni "referer", donc le serveur lui attribue une variable "GoAway" à "1". Il ne peut pas faire de POST (erreur 403), mais il peut faire du GET (code 200).

Ceux qui veulent aller moins loin que cela, en interdisant le POST uniquement aux clients qui présentent simultanément un navigateur nul et un "referer" vide, peuvent utiliser ce genre de paramétrage à la place des lignes 2-3-4 ci-dessus :

       # si browser et referer sont nuls en meme temps, on trash
       SetEnvIf Request_URI .* GoAway=1
       BrowserMatch .+ !GoAway
       SetEnvIf Referer .+ !GoAway

Cependant, j'ai moi même renoncé à ce réglage trop permissif.

À ces règles, on peut aussi ajouter une exclusion des gros hébergeurs de serveurs, tels que theplanet.com ou dreamhost.com. Une part non négligeable du spam de blog vient de chez eux, et ils n'ont absolument aucune raison de poster des commentaires car ce sont des serveurs. On ajoute donc sous la ligne 9 tout ou partie de ces "deny" :

          Deny from theplanet.com
          Deny from dreamhost.com
          Deny from leaseweb.com
          Deny from godaddy.com
          Deny from layeredtech.com

Voilà de quoi être relativement tranquille.

Les plus chanceux disposent soit des droits d'administrations complets de leur serveur, soit d'un administrateur qui aura installé mod_geoip sur la machine. Ce module Apache permet de déterminer le pays de connexion pour chaque client. Grace à ce module, il est possible d'interdir l'accès (ou le POST) aux clients dont l'IP de connexion se trouve dans certains pays (Asie, ex-URSS, ...). C'est difficile à justifier pour un très gros forum, mais pour un blog francophone au lectorat assez restreint, c'est une très bonne méthode pour éviter une partie du spam. Voici un exemple d'implémentation :

       ErrorDocument 403 "Due to an heavy spamming problem from some foreign countries, you are not allowed to post any data on this blog."
       GeoIPEnable On
       GeoIPDBFile /usr/local/share/GeoIP/GeoIP.dat
       SetEnvIf GEOIP_COUNTRY_CODE CN BlockCountry
       SetEnvIf GEOIP_COUNTRY_CODE RU BlockCountry
       SetEnvIf GEOIP_COUNTRY_CODE KR BlockCountry
       # ... place more countries here
       <LimitExcept GET>
          Deny from env=BlockCountry
       </LimitExcept>

Dans cet exemple, les visiteurs de Chine, Russie et Corée peuvent lire le site web, mais pas poster de commentaires/messages/trackbacks.

Si on cumule tous ces filtres, on atteint finalement un niveau de protection respectable, qui permet de passer au travers des vagues de spam même sophistiquées. À titre d'exemple, le simple blocage du POST sur "referer" ou navigateur nul m'a permis d'éviter 100% des tentatives de spam de 209.160.72.10 (183 en 7 jours), alors que des blogs utilisant les "captcha" ont été largement pollués par cette même machine.

Quoi qu'il en soit, une observation attentive des logs de connexion http du site web à protéger offre toujours des informations intéressantes sur le mode opératoire des spammers, ainsi que des éléments pour affiner la configuration et la protection du site.

Je ne trouve pas cela très bon comme performance...