Blog Haypo

Dans le plus pur respect du syndrôme NIH, j'ai écrit mon outil de détection de spam pour les commentaires Dotclear : antispam. Je sens que rien que le nom vous fait déjà trépigner d'impatience.

Système de notation

Je me suis inspiré de mon travail sur la notation dans le projet Fusil pour noter les commentaires, ce qui n'a rien de révolutionnaire en soit (SpamAssassin le fait déjà). J'ai écrit des règles empiriques selon mes observations sur les spams. L'idée est de rechercher les caractéristiques typiques des spams puis de les transformer en règles.

Voici les règles utilisées actuellement :

• Adresse de courriel : liste blanche/noire pour les domaines, voir conf/email_domains.txt (liste noire par défaut)
• Mots clés : recherche de mots clés à partir d'une liste blanche/noire, voir conf/words.txt (liste noire par défaut)
• Ratio des lettres latines majuscules et du nombre total de lettres latines : s'il y a plus de 35% de majuscules, le message gagne 5 points
• Longueur du texte : si le texte hors liens externes contient moins de 30 lettres latines, le message gagne 2 points
• Ratio d'url par domaine : s'il y a plus de 3 liens vers le même domaine (en moyenne), le message gagne 5 points
• Pour chaque url, une liste blanche/noire (plutôt liste blanche) permet d'attribuer un score selon le domaine. Si l'url ne correspond à aucun domaine, elle obtient une note de +1 point

Finalement, j'utilise peu de règles pour éviter les faux-positifs (message légitime détecté comme spam). Ce n'est pas nécessaire car je n'ai pas encore vu passer de faux-positif.

Résultat sur les commentaires de ce blog

En utilisant un score initial de -3, les commentaires légitimes ont une note négative entre -3 et -2. Pour les spams, j'ai observé trois types selon la note moyenne :

• (A) note de 0,5 à 2 : un ou deux liens, message court, texte crédible en anglais
• (B) note de 15 à 25 : une dizaine de liens vers le même serveur avec quelques mots anglais aléatoires
• (C) note de 150 à 200 : grosse collection de liens et liste presque exhaustive des mots clés que j'ai mis en liste noire (ex: une vingtaine de variantes de « buy cheap viagra » dans le même message)

Les spams de type (B) et (C) sont triviaux à détecter. Les plus pénibles étant les spams de type (A).

Exemple de spam pénible

Commentaire reçu aujourd'hui, j'ai remplacé les urls par xxx :

Author: brazilian <thongwaxingbrazilian@mail.com>
Website: http://xxxxxxxxx.nl/35424
IP: 218.16.224.243

- she reached for her clit. madam, i ve got arthritis,
<a href=  http://xxxxxxx.com/phpbb/barthololauries.html >waxing thong brazilian</a> and.

Le message contenait aussi deux caractères Unicode invalides (U+0092 et U+0093). Analyse avec la configuration actuelle d'antispam pour ce blog :

Match URL (+1.0): http://...
Match URL (+1.0): http://...
Match email domain (+1.0): mail.com
-stdin- score: +0.00

Le message n'est pas détecté comme spam. J'ai donc ajouté les mots clit, brazilian, thong et waxing en liste noire pour gonfler la note jusqu'à +7.

Fiabilité de l'antispam

Après une semaine de développement sur antispam, je suis plutôt content du résultat. Bien que cet outil demande beaucoup de configuration manuelle, il supprime déjà environ 90% du spam de ce blog. Sachez que je reçois à peu près 100 spams par jour sur ce blog.

L'ancien moteur de spam était fiable à 100% : il bloquait simplement tout message contenant un lien externe. J'essaye de le rendre un peu plus laxiste pour autoriser les liens externes.

Amélirations possibles

Idée pour améliorer antispam :

• Réutiliser du code (au moins des idées) des antispams existants (ex: Spam Karma)
• Utiliser un filtre bayésien
• Utiliser des listes noires (URL / IP / email) dynamiques
• Filtrage horaire et/ou selon le jour de la semaine (je pense qu'il y a peu de commentaires légitimes entre 2h et 7h)
• Utiliser des listes blanches ou d'autres règles pour diminuer la note

Contactez moi directement si vous voulez tester antispam sur votre forum ou votre blog. L'intégration étant pénible à automatiser. Antispam est écrit en Python et distribué sous licence GNU GPL.

Après de dizaines de projets d'articles avortés (mort-nés), j'ai enfin réussi à en finir un ! C'est l'article « Comment réaliser un fuzzer ? » qui est publié dans le magazine de sécurité informatique MISC numéro 36 (mars/avril 2008). J'explique quels sont les points critiques lorsqu'on écrit un fuzzer : génération des données, surveiller la cible, auto-configuration du fuzzer, etc. Image de la première des six pages de l'article :

L'article parle indirectement de mon travail sur le projet Fusil. Un deuxième article plus pratique et dédié à Fusil devrait suivre dans le prochain MISC (reste à l'écrire...).

Je regrette d'avoir oublié la section remerciements à la fin de l'article. Alors je profite de ce blog pour remercier Sebastien Tricaud, Feth Arezki, Stéphane Marchesin et ceux que j'ai oublié pour leurs relectures attentives et leurs conseils avisés. Merci aussi à Anthony Carré pour m'avoir encouragé à écrire pour des magazines papiers :-)

Au passage, si vous êtes amateur de sécurité informatique mais que vous ne connaissez pas encore MISC, je vous en conseille la lecture. Le prix élevé de 8€ est à diviser par deux car c'est un bimensuel : ce qui donne 4€/mois. D'ailleurs, il faut deux bons mois pour digérer les articles souvent complexes ;-)

Le spam désigne un « message non sollicité ». Avant limité à la messagerie électronique, le spam inonde aujourd'hui Internet en utilisant n'importe quel moyen de publier du texte avec des liens externes. Les plus touchés sont les forums (ex: phpbb) et les blogs (ex: dotclear). Plus généralement, plus la cible est populaire, plus elle a de chances d'être spammée. Dès lors, n'importe quel formulaire public devient est cible potentielle.

Filtrage par test de turing

Pour limiter le spam, l'inscription aux forums est devenue pénible : besoin de confirmer l'inscription par courriel par exemple. De même, déposer un commentaire sur un blog demande souvent des talents en décodage de hiéroglyphe (captchas). Le spam doit vraiment être lucratif car qu'importe le niveau de complexité de la protection, elle est déjouée un jour ou l'autre. La meilleure parade aux captchas étant de demander à des humains de les décoder à votre place. Cette faille déjoue l'ensemble des tests de turing !

Filtrage de l'enveloppe

On pourrait alors penser à filtrer l' « enveloppe » : les informations obtenues sur l'expéditeur du message. Le nom de l'expéditeur est généré aléatoirement et pourtant crédible, on ne peut pas en faire grand chose. Son adresse de courriel est souvent crée pour l'occasion sur un serveur offrant des adresses gratuites (ex: gmail). L'adresse IP semble une bonne piste pour bloquer un spammeur. Sauf que les spammeurs ont aussi trouvé une parade : ils louent des serveurs à moindre coût pour émettre anonymement du spam. Ces serveurs peuvent faire parti d'un botnet : ordinateurs verrolés à l'insu d'internautes légitimes. Bloquer une IP empêcherait un internaute légitime de poster un commentaire. De toute manière, les spammeurs changent régulièrement de serveurs (et donc d'adresse).

Filtrage du contenu

Si l'enveloppe n'est pas une information fiable, on peut se concentrer sur le contenu du message. Bien que chaque spam soit différent, on peut tout de même reconnaître certaines caractéristiques générales :

• un spam comporte au moins un lien externe (parfois une dizaine ou plus)
• on retrouve les même mots tels que « porn », « download » ou encore « viagra »

Une fois de plus, ces caractéristiques ne sont pas fiables à 100%. Certains spammeurs contournent le blocage par mots-clés en modifiant légèrement le terme : « viagra » devient « v1agra » par exemple. Concernant les liens externes, on commence à trouver des liens pointant sur google.com (ex: sur groups.google.com et pages.google.com) : bloquer un domaine est donc plutôt hasardeux. Bien que les spams ne comportant aucun lien externe soient rares, bloquer tout message comportant un lien externe est très contraignant pour l'internate légitime.

Filtrage par l'obscurité

Pour déjouer les plans des robots, certains se protègent en modifiant les formulaires de leur application. Une bidouille est d'ajouter un champ au formulaire. Ce champ contient un valeur spéciale ou est laissée vide : si le bot le modifie, le message est considéré comme un spam. Ce champ peut être caché (type HTML hidden ou caché par la mise en forme CSS) ou visible, auquel cas une mention avertira l'internaute de ne pas y toucher. Malheureusement, de telles pratiques relèvent de la sécurité par l'obscurité et ne peut être utilisé à grande échelle. Une fois l'astuce connue, des robots vont la déjouer facilement.

Filtrage par pot de miel

Il existe des services mettant en place des pots de miel : forums, blogs et autres dédiés à la récolte de spam. Cette collecte permet de créer une liste noire d'URL et/ou d'IP, exemples : surbl.org et projecthoneypot.org. La technique du pot de miel ne sert qu'à limiter la diffusion d'un spam.

Aucun espoir ?

C'est en écrivant mon propre antispam pour ce blog que j'ai réalisé l'ampleur du problème. Bien qu'aucune protection citée n'est fiable à 100%, cumuler plusieurs solutions permet de bloquer l'essentiel du spam, allégeant considérablement la charge du modérateur.

Malheureusement, plus un moyen de protection est efficace, plus il est utilisé, plus les spammeurs vont se concentrer dessus pour le déjouer. La sécurité par l'obscurité semble donc conseillée voir nécessaire. Des services comme Akismet reposent justement sur ce principe. Pourtant, je m'y oppose car c'est contraire à l'esprit de partage du logiciel libre !

Comme je n'ai pas pu aller au 24th Chaos Communication Congress (fin décembre 2007), je me suis rabattu sur les vidéos publiées quelques temps après. J'ai beaucoup apprécié les vidéos « (2279) Deconstructing Xbox 360 security » et « (2131) Port scanning improved ». Je voudrais parler plus particulièrement de PortBunny, un nouveau scanneur de port qui a pour logo un lapin rose. Le diaporama de la présentation est disponible en ligne.

Lire la suite

Le chercheur en sécurité Wojciech Purczynski, employé par COSEINC et membre de l'association iSEC Security Research, a trouvé divers bugs dans l'appel système vmsplice() du noyau Linux. Cette fonction, introduite avec Linux 2.6.17, sert à envoyer des données de l'espace utilisateur vers l'espace noyau pour alimenter un pipe. Lire mon précédent billet sur l'évolution des entrées/sorties dans Linux pour les détails. Les développeurs noyau sont prévenus dès le 1er février. Cet article relate la publication, l'exploitation, puis la correction de ces failles.

Lire la suite

En juin 1998, Larry McVoy propose une nouvelle API pour les entrées/sorties dans le noyau Linux : The splice I/O model. Il propose une interface d'entrée/sortie vectorielle (scatter/gather), asynchrone et sans copie (zero copy). Le but est de maximiser les performances en évitant de recopier inutilement des zones mémoires. Les travaux pour concrétiser ses idées prendront presque une dizaine d'années.

Lire la suite