Centre de Ressources Informatiques
  Mis à jour le Vendredi 21 Janvier 2005
Sommaire de la rubriqueContact eMailPage d'accueil

SPAM



    Sommaire

Définition SPAM
Contexte
Moyens de lutte en frontal
Moyens de lutte en profondeur
           Le SPAM est un courrier non sollicité qui prend de plus en plus de place dans l'existence des internautes. Il est proportionnel à l'activité internet de ceux-ci. Sa définition et les moyens de lutte posent problème. Nous proposons ici notre point de vue. A vous d'en faire ce que vous en voulez.


    Définition SPAM

           Notre définition est la suivante : courrier non sollicité reçu par un grand nombre d'utilisateurs. C'est la seule que nous utilisons.


    Contexte

           Le contexte d'exploitation est fondamental pour bien définir les moyens utilisables.

Le contexte politique/légal et réglementaire

           Notre contexte empêche d'utiliser des approches trop "restrictives" et nous oblige à préserver au maximum les mails. Les utilisateurs sont des habitués du droit, et cela joue beaucoup sur les réactions possibles. Nous prenons le parti de ne détruire les mails QUE si l'intégrité du réseau est en jeu. Cette approche, un brin hypocrite, nous préserve raisonnablement de toute contestation pour destruction de mail.

Le contexte technique

           Nous utilisons une structure à 2 niveaux pour le mail : un serveur frontal (en fait 2 MX dont l'un est en secours) de protection, et un serveur de réception des mails. Ces serveurs font tourner une version 2.1.x de Postfix http://www.postfix.org ce qui nous permet d'utiliser un grand nombre d'outils de lutte anti-spam. Des binaires pour PostFix sont disponibles ici http://postfix.wl0.org/en/.
          De plus, le serveur de réception utilise Cyrus IMAPD, ce qui nous permet d'utiliser les fonctionnalités telles que le filtrage sur le serveur.


    Moyens de lutte en frontal

           Nous utilisons une architecture à plusieurs niveaux pour tenter de limiter la casse.

L'anti-relaying

           Afin d'éviter l'utilisation par les spammeurs de nos serveurs, des techniques intégrées dans Postfix sont utilisées. On se doit de créer un fichier mynetwork qui contient les adresses IP des réseaux internes. Les protections sont ensuite vérifiées par un telnet relay-test.mail-abuse.org depuis le serveur smtp frontal.
          Le main.cf (pour la partie antispam) de postfix a alors la tête suivante

mynetworks = /etc/postfix/network_table
mynetworks_style = subnet

smtpd_recipient_restrictions =
        permit_mynetworks
        reject_unauth_destination
        permit

Le greylisting

           Le greylisting(http://www.greylisting.org est une méthode qui consiste à constituer un triplet (adresse IP de l'expéditeur, adresse email de l'expéditeur, adresse email du destinataire) à partir de tout mail qui arrive. Dans notre cas le triplet ne contient que l'adresse de réseau (sans le dernier octet) de la machine expéditrice.
           Mais quelques difficultés apparaissent
          Le main.cf (pour la partie antispam) de postfix a alors la tête suivante
mynetworks = /etc/postfix/network_table
mynetworks_style = subnet

smtpd_recipient_restrictions =
        permit_mynetworks
        reject_unauth_destination
	
	check_client_access  hash:/etc/postfix/whitelisted_domains
        check_policy_service unix:private/whitelist
        check_policy_service unix:private/greylist
	
        permit
          De plus pour les installer il faut les insérer dans master.cf

greylist	unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/greylist.pl
whitelist	unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/whitelist.pl

          Les outils qui permettent de mettre en place le greylisting sont présentés ici

Les blacklists

           Le blacklisting est une méthode efficace pour bloquer les spams. Plusieurs listes publiques sont disponibles et permettent de rejeter les mails qui proviennent d'expéditeurs spammeurs. Toujours dans notre optique de limitation des effets, nous avons mis en place un taggage des mails suivant le résultat des blacklists. Mais une simple modification du programme suffit à rendre le programme "énergique".
          Pour les installer il faut insérer dans master.cf

rbl       unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/rbl.pl

greylist	unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/greylist.pl
whitelist	unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/whitelist.pl
          Mais cela ne suffit pas, car nous souhaitons taguer tout message qui arrive. Pour cela nous créons une classe de restriction SMTP appelée OK_AND_PREPEND qui va nous permettrent d'accepter des messages, mais d'ajouter un renseignement complémentaires sur les résultats de divers tests. La liste des RBL utilisés est directement intégrées dans le script.
          Le main.cf (pour la partie antispam) de postfix a alors la tête suivante
mynetworks = /etc/postfix/network_table
mynetworks_style = subnet

smtpd_recipient_restrictions =
        permit_mynetworks
        reject_unauth_destination
        check_policy_service unix:private/whitelist
        check_policy_service unix:private/greylist
        permit
	
smtpd_restriction_classes = OK_AND_PREPEND

OK_AND_PREPEND =
        check_policy_service unix:private/rbl
	permit

Les tests d'expéditions

           Ils permettent de vérifier que la machine qui envoie le message est autorisée à le faire avec l'identité qu'elle prétend ( exemple seuls les serveurs hotmail.com sont autorisés à envoyer du @hotmail.com). Plusieurs dispositifs sont connus pour le faire. SPF et DomainsKey. Notre outil ne gère que SPF.
          Pour installer il faut insérer dans master.cf
spf       unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/spf.pl
rbl       unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/rbl.pl
greylist	unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/greylist.pl
whitelist	unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/whitelist.pl
          Nous complétons la classe OK_AND_PREPEND.
          Le main.cf (pour la partie antispam) de postfix a alors la tête suivante
mynetworks = /etc/postfix/network_table
mynetworks_style = subnet

smtpd_recipient_restrictions =
        permit_mynetworks
        reject_unauth_destination
        check_policy_service unix:private/whitelist
        check_policy_service unix:private/greylist
        permit
	
smtpd_restriction_classes = OK_AND_PREPEND

OK_AND_PREPEND =
        check_policy_service unix:private/spf
        check_policy_service unix:private/rbl
	permit

Les tests de connexion

          En plus de la protection anti-spam nous en avons profité pour tester la cadence d'émission des postes locaux à l'aide d'un autre script. Celui -ci va vérifier qu'un poste ne prend pas plus de 5 identités d'expéditeurs par 10 minutes)
          Pour installer il faut insérer dans master.cf
mynetwork       unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/mynetwork.pl
spf       unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/spf.pl
rbl       unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/rbl.pl
greylist	unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/greylist.pl
whitelist	unix  -       n       n       -       -       spawn user=nobody argv=/usr/bin/perl /usr/libexec/postfix/extra/whitelist.pl
          Nous ajoutons la classe MYNETWORK.
          Le main.cf (pour la partie antispam) de postfix a alors la tête suivante
mynetworks = /etc/postfix/network_table
mynetworks_style = subnet

smtpd_recipient_restrictions =
	check_client_access	hash:/etc/postfix/mynetwork
        permit_mynetworks
        reject_unauth_destination
        check_policy_service unix:private/whitelist
        check_policy_service unix:private/greylist
        permit
	
smtpd_restriction_classes = OK_AND_PREPEND,MYNETWORK

OK_AND_PREPEND =
        check_policy_service unix:private/spf
        check_policy_service unix:private/rbl
	permit

MYNETWORK =
        check_policy_service unix:private/mynetwork
	permit

Les test sur les annexes

           Les virus sont parfois trop rapides pour les procédés de détection : 4 heures pour la mise à disposition d'une signature (et parfois bien plus). C'est pour cela qu'il peut être intéressant de bloquer ou de retarder les annexes connues pour leur utilisation virales. Toujours selon notre politique, nous nous contentons de mettre en quarantaine les mails avec ce type d'annexes, puis nous les ressortons au bout de 6 heures.
           On commence par modifier le fichier /etc/postfix/header_checks en lui ajoutant les deux lignes suivantes.
/^content-(type|disposition):.*name[[:space:]]*=.*\.(com|cpl|scr|vbe|vbs|pif|hta|shs|vxd|wsh|lnk|shm|shb)/
HOLD Attachement Type Not Allowed. Annexe de type non autorise
           Il faut ensuite utiliser la possibilite de check de PostFix

header_checks = regexp:/etc/postfix/header_checks

           Le script release_hold_mail.sh tournant toutes les heures va vérifier les mails en quarantaine et les relancer au bout de 6 heures.


    Moyens de lutte en profondeur

           Une fois que le mail sort du frontal, on a enlevé une bonne part des mails ne respectant pas le code de la route SMTP. Il arrive doté d'un certain nombre d'indicateurs qui vont être utilisés par le procédé d'analyse bayésien. Notre procédure va donc se faire en 2 étapes : l'évaluation par le logiciel http://www.bogofilter.org, puis la décision qui va se faire par l'utilisateur. Celle-ci pouvant être appliquée dès le serveur (Filtre Sieve) ou sur le poste (Filtre local).

Bogofilter

           Bogofilter est un filtre bayésien très efficace qui évalue différemment les termes suivant leur position (headers, received, body). Une FAQ est diponible ici http://www.bogofilter.org/faq_fr.php.
          Les binaires peuvent être récupérés ici http://sourceforge.net/project/showfiles.php?group_id=62265
          Bogofilter positionne deux éléments :
          Bogofilter se lance par l'intermédiaire d'un script shell bogofilter.sh. Ceci n'est pas une méthode optimale, mais il n'existe pas encore de version "daemonisée" de Bogofilter. Pour l'activer, il faut modifier le fichier /etc/postfix/master.cf en lui ajoutant en début de fichier à la place de la ligne originelle
smtp    inet    n       -       y       -       -       smtpd   -o content_filter=filter:
           Puis en fin de fichier
filter  unix    -       n       n       -       -       pipe
 user=filter argv=/usr/sbin/bogofilter.sh -f ${sender} -- ${recipient}
          Les paramètres suivants correspondent à nos choix :
spam_header_name=X-Bogosity
spam_subject_tag=***SPAM***UT1***
block_on_subnets=yes
header_line_markup=yes
ham_cutoff = 0.15
spam_cutoff = 0.90
spamicity_tags = Yes, No, Unsure
spamicity_formats = %0.6f, %0.6f, %0.6f
           Nous utilisons la fonction de réapprentissage (paramètre -u), qui signifie qu'une fois qu'un mail est validé, nous le réapprenons, cela permet au système d'évoluer en même temps que les spammeurs.
           Chaque soir, une routine nettoie la base en enlevant les "tokens" obsolètes, ou trop rares pour être utile.
          ATTENTION il est important de modifier Postfix pour permettre à la base de données de Bogofilter de dépasser les 50 Mo (ce qui lui arrive très régulièrement). Il faut donc ajouter dans le fichier /etc/postfix/main.cf
mailbox_size_limit = 100000000

Décision d'élimination

          Nous ne faisons pas d'élimination de mails, hormis en cas de virus avérés. La décision d'élimination est du ressort de l'utilisateur. Légalement, cela nous couvre.
          Trois possibilités majeures existent
Le filtrage sur le serveur
          Il est effectué grâce à Sieve qui est un composant de cyrus-imapd doté de fonctionnalités très utiles telles que la redirection, le placement dans des classeurs, les vacations, le rejet. C'est l'équivalent d'un procmail.
          Sieve étant un protocole parfois compliqué, nous utilisons une interface web complémentaire, appelée SmartSieve qui nous permet de proposer une interface pour le filtrage des SPAMS, mais aussi l'utilisation des filtres classiques et des vacations.
          Une aide à l'utilisation de SmartSieve est disponible ici.
          L'avantage du filtrage serveur est de limiter le travail des webmails, et surtout de limiter la bande passante utilisée lors du rapatriement des mails, les SPAMS n'étant éliminés qu'après lecture complète des mails.
Le filtrage sur le client
          Cette méthode, très générale et souvent utilisée au début, est préférée tant que l'utilisateur ne fait pas confiance au système de filtrage. Cette méthode est recommandée par le service informatique, car elle permet de conserver les spams dans un classeur du lecteur de messagerie et de pouvoir ainsi vérifier les erreurs éventuelles.
          On remarque cependant que les victimes les plus touchées, ou se sentant comme telles, préfèrent majoritairement glisser vers le filtrage serveur.
          Pour ces personnes nous avons mis en place certaines pages d'explications ici, pages dont plusieurs graphiques sont directement tirées du manuel de popfile, un outil opensource de filtrage bayésien