poivron.org - passé/futur

LOGICIELS UTILISÉS

Pour filtrer les spams et virus, nous aurons recours à Postfix, Postgrey, une série de RBL, Amavisd-new, ClamAV, et SpamAssassin.

Postfix est un 'Mail Transport Agent' (MTA), plus communément appelé 'serveur SMTP', 'serveur de mail' ou 'serveur de courrier'. Sa fonction est de parler le langage SMTP ('Simple Mail Transfert Protocol'), protocole utilisé pour acheminer le courrier sur Internet. Postfix dialogue ainsi avec ses pairs, envoie/reçoit les courriers transitant de/vers la machine sur laquelle il est installé. Il ne revient pas à Postfix d'en analyser le contenu, de détecter et bloquer spams et virus, fonctions qui sont déléguées à d'autres programmes, avec lesquels Postfix interagit. Néanmoins, un certain nombre de paramètrages permet de couper l'herbe sous le pied de certains spams, directement via Postfix. On peut, par exemple, exiger l'authentification des serveurs de courrier avec lesquels Postfix va dialoguer (via la commande SMTP HELO), et rejeter les courriers provenants de serveurs sans FQDN ('Fully Qualified Domain Name', c'est à dire un nom de domaine authentique et complet). Bref, on peut faire des milliers de choses différentes, efficaces et passionnantes avec Postfix, mais l'objectif n'est pas de les lister ici. Toujours est-il que Postfix, en tant que centre de réception/émission du courrier, sera le passage obligé des spams et virus, et le premier à s'y confronter.

Postgrey est une implémentation du 'greylisting' pour Postfix. Le 'greylisting' se veut une technique intermédiaire entre le 'whitelisting' (serveurs ayant carte blanche) et le 'blacklisting' (principe de liste noire, interdisant l'accès aux serveurs réputés pour être des nids à spammeurs), qui consiste à considérer tout serveur comme un "méchant" potentiel, avant de changer d'avis. Plus précisémment, tout mail venant d'un serveur inconnu sera une première fois rejeté, puis accepté lorsque le serveur d'expédition le renverra, passé un petit délai. Si tout serveur correctement configuré effectue plusieurs tentatives de livraison avant d'abandonner le courrier, ce n'est généralement pas le cas des spammeurs, qui pratiquent l'envoi de masse vers des milliers d'adresses e-mail simultanément, ne s'encombrent pas de savoir si le courrier a bel et bien été livré, et font peu de cas des standards de communication SMTP. En conséquence, le 'greylisting' permet de se débarrasser en amont de nombre de spams en leur refusant l'entrée, ce qui se implique néanmoins que des courriers "légitimes" mettront parfois un peu plus de temps à arriver (puisqu'ils se verront rejetés une première fois, puis acceptés à la seconde tentative). Heureusement, il est possible d'établir des 'whitelists' de serveurs de confiance, non soumis à cette mesure de précaution.

Les RBL, ou "Realtime Black Lists", soit "listes noires dynamiques" sont des listes de serveurs notoirement (ou non!) connus pour constituer des relais pour les spammeurs, mises à jour dynamiquement, et évoluant donc au gré des vagues publicitaires. Il est ainsi possible de configurer son MTA pour qu'il consulte une ou plusieurs RBL, afin de vérifier que le serveur d'expédition n'y apparaisse pas, avant d'en accepter le message. Comme les spammeurs se font fort d'exploiter les vulnérabilités de serveurs de mail mal configurés (MTA en 'open-relay' en particulier, acceptant tout traffic en entrée et relayant ainsi gentilment n'importe quel courrier), et parce qu'un serveur tout entier peut être victime d'un utilisateur peu scrupuleux, il arrive que se trouvent abusivement inscrits aux RBL des serveurs dont la pratique n'a rien à voir avec le spam (c'est notamment le cas de altern.org, malheureusement 'blacklisté' sur plusieurs RBL, alors qu'il constitue l'un des rares services de courrier alternatif et gratuit, et que des milliers d'utilisateurs et d'utilisatrices en dépendent). Il s'agit alors de ne "faire confiance" (puisque c'est de cela qu'il s'agit) qu'à des RBL permettant le retrait d'adresses de leur base de données (ce qui est le cas de la plupart des RBL gratuits, qui disposent d'une procédure de retrait simple), et de rester vigilent-e-s face aux abus et erreurs possibles via ce système.

Amavisd-new est un logiciel qui sert d'interface entre un MTA (serveur de courrier) et divers autres logiciels d'analyse de contenus, comme un antivirus et un détecteur de spam. Amavisd-new passera les courriers parvenant au MTA aux logiciels d'analyse précités, et fera remonter l'information vers le MTA une fois les scans réalités.

ClamAV est un antivirus libre, dont la base de données, qu'il est possible d'actualiser automatiquement via Internet, détecte près de 20000 virus, vers et autres chevaux de troie. Clam antivirus isole les diverses parties de chaque message, décompresse ses pièces jointes et autres fichiers archivés à la volée, scanne le tout, et autorise ou non leur passage en fonction.

SpamAssassin, comme son nom l'indique, se charge des spams, en analysant l'en-tête et le contenu du message pour y repérer des motifs caractéristiques, et estimer la probabilité que le message soit un spam ou non. Pour ce faire, SpamAssassin établit un score, plus ou moins élevé selon les éléments reperés par l'analyse. Quant le score passe un certain seuil, SpamAssassin juge le message comme étant probablement du spam, et le marque en conséquence (par l'ajout de lignes 'X-Spam-Status' et 'X-Spam-Flag' dans l'en-tête), laissant le soin à l'utilisateur de le purger ou non (ce qui est très facile à automatiser, dès lors qu'un élément distinctif est introduit dans l'en-tête du message). Un autre seuil, plus élevé, établit avec certitude la nature de 'spam' du message, qui est alors pulvérisé. À noter que SpamAssassin est aussi capable d'apprendre de ses erreurs! Pour améliorer son appréciation des spams, il suffit de lui donner à manger les spams qu'il a laissé passer.

INTERACTION

Suivons le cheminement d'un courrier envoyé depuis le serveur 'truc.org' vers 'poivron.org':

• 'truc.org' va se connecter à 'poivron.org' sur le port 25. C'est donc le MTA Postfix qui va décrocher, et prendre en charge la communication. Postfix va attendre que truc.org s'authentifie (HELO) et va vérifier que le domaine truc.org existe bien et soit valide (FQDN). Si l'une de ces conditions n'est pas remplie, Postfix coupe la connexion. Dans le cas contraire...
• Postfix fait appel à postgrey, qui, à moins que 'truc.org' ne se trouve dans la 'whitelist' des serveurs de confiance, va rejeter la connexion, pour une durée de 300 secondes. Passé ce délai, truc.org se connecte à nouveau pour envoyer son message. Postgrey, cette fois, l'autorise. Un spammeur n'aurait probablement pas ré-essayé.
• Postfix consulte alors une série de RBL (listes noires), pour vérifier que 'truc.org' n'y figure pas. Si 'truc.org' apparait dans quelque RBL, le message est bloqué et la connexion coupée, avec un message explicatif. Dans le cas contraire...
• Postfix fait alors appel à Amavisd-new, lequel va déléguer les tâches de scan antivirus et d'analyse antispam aux logiciels spécialisés que sont ClamAV et SpamAssassin.
• ClamAV est appelé par Amavisd-new, et entreprend de scanner les diverses parties du message proposé par 'truc.org'. Chaque pièce jointe est scannée, et s'il s'agit d'une archive compressée, décompactée pour en vérifier le contenu. Si un virus est détecté, le message est refusé, le virus mis en quarantaine. Sinon...
• SpamAssassin est invoqué par Amavisd-new, et analyse la structure du message, son contenu, divers éléments de son en-tête, de manière à lui assigner un "Spam-Level", soit un niveau de probabilité que le message soit un spam. Si le Spam-Level atteint 4.0, alors le message se voit estampillé "spam" et livré à l'utilisateur. Si le Spam-Level atteint ou dépasse 10.0, il est rejeté sans autre forme de procès. S'il demeure inférieur à 4.0, le message continue son chemin vers...
• Postfix, à qui Amavisd-new a livré les résultats précédents. Le message ayant passé ces différents tests, il ne reste plus qu'à Postfix de le livrer à son destinataire.

Le tout aura probablement duré quelques secondes à peine. Voici un schéma récapitulatif:

            e-mail
              |
        Postfix (réception, vérifications)
              |
        postgrey (greylisting)
              |
        RBL (Realtime Black List)
              |
        Amavisd-new (interface)
              |
              `--> Clam Antivirus (scan antivirus)
              `--> SpamAssassin (analyse antispam)
                        |
                Postfix (livraison)

INSTALLER ET CONFIGURER

Suivent donc quelques notes décrivant sommairement la mise en place d'un système de filtrage des spams et autres virus à base de logiciels libres sur poivron.org, soit sur un système Debian GNU/Linux, arôme 'sarge', équipé du MTA Postfix préalablement configuré. Ce document n'a aucunement prétention de constituer une véritable documentation, et ne saurait se substituer à la lecture des README et autres documents accompagnant les divers logiciels libres utilisés, lecture nécessaire pour *comprendre* le fonctionnement et l'interaction de ses composants.

Clam Antivirus

Commençons par installer ClamAV:

        $ sudo apt-get install clamav-daemon clamav-freshclam

La configuration par défaut étant parfaitement fonctionnelle, nous ne la toucherons pas.

Afin que ClamAV puisse décompresser les pièces jointes des messages analysés, installons une série d'outils aptes à gérer les différents formats:

        $ sudo apt-get install gzip bzip2 unzip unrar unzoo arj

SpamAssassin

Il est possible d'utiliser SpamAssassin de plusieurs manières:

• en l'invoquant au besoin via la ligne de commande
• en le faisant tourner en arrière-plan, via le démon spamd

Dans le cas d'un serveur devant traîter de larges volumes de mails, la première solution s'avèrerait suicidaire en terme de consommation de ressources (une nouvelle instance de Perl à chaque courrier, ouais!), tandis qu'un particulier ne traitant qu'occasionnellement quelques mails la préfèrera probablement.

En ce qui nous concerne, nous opterons donc sans hésiter pour spamd, qui s'avère, de plus, incommensurablement plus performant que le seul SpamAssassin.

Le paquetage Debian 'spamassassin' contenant spamd, et dépendant de spamc, nous nous contenterons, pour l'installation, d'un habituel:

        $ apt-get install spamassassin

Spamd n'est néanmoins pas activé par défaut. Aussi faut-il éditer le fichier '/etc/default/spamassassin', et passer la variable 'ENABLED' à '1'. Pendant que nous y sommes, changeons quelques paramètres de configuration. Sauf besoin spécifique (possibilité pour chaque utilisateur/utilisatrice de définir ses préférences de filtrage spam - ce qui, dans le cas de poivron.org ayant des utilisateurs virtuels, n'est de toutes façons pas réalisable), il n'est point besoin d'exécuter SA en tant que root! Passons donc dans les 'OPTIONS' le paramètre '-u mail' qui aura pour effet d'exécuter SA sous l'utilisateur 'mail'. L'option '-c' (création d'un fichier de préférence par utilisateur) n'ayant plus court, enlevons là par la même occasion. La ligne d'options doit donc ressembler à ceci: 'OPTIONS="-u mail -m 10 -a -H"'

Il s'agit alors de (re)lancer SA pour que soient prises en considération les modifications (et que spamd démarre):

        $ sudo /etc/init.d/spamassassin restart

Amavisd-new

ClamAV et SpamAssassin étant installés, c'est sur Amavisd-new qu'il va surtout falloir se pencher, puisqu'il s'agit du composant assurant la communication des programmes précités avec Postfix.

L'installation se fait à la sauce Debian:

   
        $ sudo apt-get install amavisd-new

Il s'agit, cette fois, d'éditer le fichier de configuration touffu /etc/amavis/amavisd.conf. Renseigner, tout d'abord, les champs '$mydomain' et '$myhostname' avec le nom du serveur. Passer ensuite le '$log_level' à '5' pour s'assurer une compréhension maximale des éventuels problèmes. Conclure les modifications par un:

        $ sudo /etc/init.d/amavis restart

Et s'attaquer à la lecture de l'excellent HOWTO sur l'interfaçage avec Postfix:

        $ zless /usr/share/doc/amavisd-new/README.postfix.gz

En suivant les intructions qu'il contient, éditer la configuration de Postfix dans '/etc/postfix/master.cf', et ajouter les sections 'smtp-amavis unix' et '127.0.0.1:10025', sans omettre de remplacer le 'y/n' par l'une ou autre option, selon que votre installation Postfix est chrootée ou non (par prudence, vous pouvez commencer par tester l'installation en mettant 'n', et basculer vers le chroot plus tard). Rechargez la configuration de Postfix:

        $ sudo /etc/init.d/postfix reload

Il s'agit alors de tester l'interfaçage de ClamAV avec Amavisd-new, et de Amavisd-new avec Postfix. Or, comme pour SpamAssassin, ClamAV peut tourner en mode démon, ou être invoqué depuis la ligne de commande. Pour les raisons précitées, nous tenons absolument à tirer parti du démon clamd. Mais se pose alors un problème de permissions, pour que ClamAV et Amavisd-new puissent partager des données. Alors que certaines documentations indiquent que les deux programmes doivent tourner sous le même UID (utilisateur), la bidouille suivant suffit amplement à les satisfaire (ajout de l'utilisateur 'clamav' au groupe groupe 'amavis'):

        $ sudo adduser clamav amavis

Ceci fait:

        $ sudo /etc/init.d/clamav-daemon restart
        $ sudo /etc/init.d/amavis restart

Nous pouvons commencer les tests. Il s'agira de se connecter au démon 'amavisd' via telnet, et de lui envoyer des messages manuellement pour voir si l'interfaçage avec Postfix fonctionne, tout en inspectant les logs pour voir si les informations sont bel et bien passées à ClamAV. Aussi s'agit-il de garder sous les yeux une console dans laquelle sera exécuté:

        $ sudo tail -f /var/log/syslog

Lançons le test:

   
        $ telnet localhost 10024

Et envoyons les séquences SMTP 'MAIL FROM:', 'RCPT TO:', 'DATA', quelques caractères, puis '.'. Si le mail est accepté dans la file de Postfix, et si le mail reçu par 'root@localhost' contient une ligne 'X-Virus-Scanned: by amavisd-new', tout fonctionne à priori. Il s'agit néanmoins de vérifier, en observant les logs, si Amavisd et Clamd parviennent bel et bien à communiquer, ou si Amavisd en est réduit à invoquer ClamAV pour chaque courrier traité. Pour parfaire le test, envoyons un autre mail, contenant cette fois la signature d'un virus (une chaîne de caractères prête à l'emploi se trouve dans /usr/share/doc/amavisd-new/README.postfix.gz). Si le message est rejeté, alors le système fonctionne.

Passons au filtrage des spams avec SpamAssassin. Par défaut, celui-ci est désactivé dans '/etc/amavis/amavisd.conf'. Pour le mettre en marche, il suffit de commenter la ligne '@bypass_spam_checks_acl = qw( . );' (en ajoutant un simple '#' devant), puis de:

        $ sudo /etc/init.d/amavis restart

Vérifions que spamd tourne:

        $ ps aux | grep spamd

Si non, vérifions la configuration dans /etc/default/spamassassin, et relancer le service via /etc/init.d/spamassassin. Nous pouvons procéder aux mêmes tests que pour ClamAV, en épiant les logs pour voir si le passage par SpamAssassin est efficace. Attention néanmoins: si les mails reçus ne comportent pas de mention 'X-Spam-Flag' et/ou 'X-Spam-Level', point besoin de s'alarmer. Cela ne signifie pas que SA ne marche pas, car dans la configuration par défaut, seuls les courriers ayant un score de 4.0+ voient leur en-tête modifiée. Pour parfaire le test de SA, envoyons nous une chaîne détectée comme étant du spam, que nous trouverons dans '/usr/share/doc/spamc/sample-spam.txt'. Si le message est rejeté, là encore, nous avons gagné :)

Postfix

Il reste à configurer Postfix pour que tous les courriers transitent par Amavisd-new, et bénéficient ainsi du filtrage de spam et de virus. Éditons '/etc/postfix/main.cf', pour y ajouter la ligne 'content_filter=smtp-amavis:[127.0.0.1]:10024' (sans oublier le classique 'sudo /etc/init.d/postfix reload').

Dans la foulée, configurons Postfix pour qu'il exige une chaîne HELO. Il suffit d'ajouter 'smtpd_helo_required = yes' à '/etc/postfix/main.cf'. Pour qu'il rejette le courrier provenant de domaines non-qualifiés (FQDN), il suffit d'ajouter une ligne 'smtpd_helo_restrictions = reject_non_fqdn_hostname'.

Pour qu'il fasse appel aux RBL, il suffit d'ajouter à la variable 'smtpd_recipient_restrictions' un ou plusieurs paramètres 'reject_rbl_client url', ou 'url' n'est autre que l'adresse d'une RBL. En voici quelques unes: relays.ordb.org, cbl.abuseat.org, sbl.spamhaus.org, opm.blitzed.org, dnsbl.njabl.org, list.dsbl.org.

Postgrey

Enfin, pour intégrer le support du graylisting:

        $ sudo apt-get install postgrey

Ajoutons 'check_policy_service inet:127.0.0.1:60000' à 'smtpd_recipient_restrictions' et rechargeons la configuration de Postfix. Le greylisting devrait désormais fonctionner (il suffit d'un regard sur les logs pour le confirmer). À noter qu'il est conseillé de créer une 'whitelist' locale, contenant des serveurs de confiance n'étant pas soumis au graylisting, via un simple fichier '/etc/postgrey/whitelist_clients.local' (sans oublier de recharger postgrey via /etc/init.d/postgrey restart).

Et voilà! En quelques commandes, notre système de mail aura perdu beaucoup de sa perméabilité aux spams et autres virus, même si le système reste à compléter!