Ce type d’installation peut tout à fait convenir pour des petites et moyennes entreprises (quelques centaines de personnes), sur un serveur moyennement puissant. Pour faire simple.

Encore une doc sur ce sujet ?

Oui on s’excuse, mais comme d’habitude avec Debian, tout est déjà prêt à fonctionner et pourtant, on trouve généralement des docs de personnes mettant en place l’outil en recompilant les sources, en prenant des fichiers de conf à droite à gauche, en démolissant le beau travail déjà accompli par les packageurs Debian.
Mon approche reste la même : Debian a fait le boulot pour moi, j’en profite.
Au final, cet article est simplement brodée autour du README.Debian de chaque paquet qu’on va installer (surtout amavisd-new) et de quelques autres docs glanées sur le web expliquant tel ou tel paramètre, un peu plus que la doc officielle.
Mais comme rares sont les gens qui lisent les README, mon article devrait quand même intéresser quelques lecteurs, je l’espère.

Ce dont je ne parle pas

Je ne parle pas de l’aspect lecture des mails (en POP, en IMAP, renvoi vers un autre backend (Exchange ?)), mais juste au nettoyage et au blocage amont des spams et virus.
Je pars d’ailleurs d’une machine avec un postfix minimaliste sachant envoyer et recevoir des mails.
Vous pouvez vous reporter à ma doc Debian pour ce cas là, elle décrit en plus de postfix :
- la mise en place de postgrey (voyez l’intérêt ici)
- la mise en place de quelques blocages par blacklists (RBL & co)
- procmail
Je ne parle pas non plus du montage d’un backup MX. Probablement lors d’un prochain article.

Enfin, je colle tous les éléments de ce serveur sur une unique machine physique. Vous pourriez séparer les éléments. A ce moment-là, un peu de raisonnement et une lecture des documentations officielles que je cite me paraît judicieux. Cet article se limiterait alors,pour vous, à comprendre le rôle de chaque morceau, à appréhender la configuration de base et à partir du coup dans la bonne direction.

Comme à mon habitude, je décris aussi quelques bêtises et oublis que j’ai pû rencontrer, ça aidera à débugger et ça explique des choses.

Pré-requis

Etre sur une Debian stable (Lenny) avec le dépôt Debian « volatile » opérationnel (pour les mises à jour de clamav).
Le dépôt « volatile », c’est ça :

moi@srv:~$ cat /etc/apt/sources.list | grep vola
deb http://volatile.debian.org/debian-volatile lenny/volatile main contrib non-free

C’est un dépôt créé pour palier aux problèmes des applications mises à jour constamment (les bases anti-virus par exemple, tout autant que des outils de mssageries instantanées qui voient les protocoles sous-jascents évoluer régulièrement). Si on restait sur le rythme Debian (tous les 2 ans ; bientôt 6 mois), on aurait des applications inutiles.

Rôle de chaque élément

D’abord le schéma qui va bien :

Cheminement du mail

1. Postfix reçoit donc la connexion d’un serveur voulant envoyer un mail.
2. Grâce à postgrey, il va filtrer déjà un bon paquet de spams qui n’atteindra pas la suite des composants (et donc pas de charge réseau/cpu inutile).
3. Donc au besoin, le mail revient plus tard, suite à greylisting.
4. Postfix passe le relai à amavisd-new qui orchestre les appels à :
5. ClamAV qui fait ce qu’il a à faire
6. et à spamassassin, lui-même gérant pyzor/razor
7. Retour du mail nettoyé (disons, avec les en-têtes qui vont bien) vesr postfix
8. Postfix livre le mail (dans la boîte de l’utilisateur, au backend, à je ne sais quel autre élément en aval.

Doc officielle, doc complémentaire

Lire /usr/share/doc/amavisd-new/README.postfix.gz est un passage obligé, je trouve. Je me base dessus et je fais certains choix qui pourraient ne pas être les votres. Je n’invente pas grand chose, tout est quasiment dedans.
Si vous êtes sur une installation déjà en production, vous pourriez être intéressés par le paramètre soft_bounce, voyez ici via un :
postfix -e "soft_bounce = yes"

Autre doc intéressante : http://www200.pair.com/mecham/spam/spamfilter20090215.html. A noter : l’auteur n’utilise pas trop le boulot de Debian, donc beaucoup de choses à reparamétrer dans son cas, sans compter les manips à la main : récupérer le fichier de conf X, prendre tel binaire postfix plutôt que celui de la distrib. Bref, pas très Debian-style à mon goût.
Mais au moins il donne une bonne explication de certains paramètres, à vous de voir.
Enfin, cette doc décrit le montage complet d’une Debian, installation, serveur DNS etc. On s’en fout pas mal dans le cas présent. Commencez donc à lire cette doc à partir du mot « postfix anti-spam settings: ». A peu près au milieu.
Vous verrez passer dans les chapitres qui suivent cet endroit quelques paramètres importants sur le comportement des différents outils, les destinataires des notifications de mails vérolés etc, quelques optimisations sur les niveaux de spam acceptables etc. Mon article reprend certaines de ces suggestions et de ma propre expérience.
Cette doc va aussi plus loin : installation de DCC (Distributed Checksum Clearinghouses) et des outils de statistiques. Je n’en parle pas (pour l’instant), on verra avec des articles ultérieurs.

Bon, allez, on installe tout ça.

Installation des logiciels

aptitude install clamav clamav-daemon clamav-freshclam
aptitude install amavisd-new
aptitude install lha arj rar unrar nomarch lzop cabextract razor pyzor p7zip-full pax zip unzip lha zoo

Certains des paquets ici sont discutables, pour les pros du ça-pue-c-est-pas-libre-(tm). Moi je veux simplement analyser un maximum de contenu de mails, pièces jointes en format moins courants y compris.
Les outils type « décompression » serviront à ClamAV pour analyser les contenus de pièces jointes.

Les parties postfix, postgrey, spamassassin et les Maildir sont déjà expliqués dans mes docs/blog à différents endroits.
Deux nuances tout de même :
Je suppose enfin que votre spamassassin est en mode daemon (donc « spamd » tourne) car vous avez mis à 1 le paramètre ENABLED dans /etc/default/spamassassin.
Par rapport à ce que j’explique sur procmail, j’ai opté pour une conf standard pour tous dans /etc/procmailrc plutôt que dans chaque ~/.procmailrc.

Paramétrage de base

Configuration postfix <=> amavis

D’abord, on configure un canal de communication postfix => amavis en mode SMTP et pas LMTP (voir le /usr/share/doc/amavisd-new/README.postfix.gz). J’ajoute à la fin de /etc/postfix/master.cf des lignes suivantes :

amavisfeed unix    -       -       n       -       2     smtp
     -o smtp_data_done_timeout=1200
     -o smtp_send_xforward_command=yes
     -o smtp_tls_note_starttls_offer=no

Le nom « amavisfeed » est libre. Mais c’est le nom du tuyau que vous venez de créer. Il faudra utiliser ce nom plus bas (dans main.cf)

Puis le canal retour (message reinjection), toujours à la fin de /etc/postfix/master.cf :

127.0.0.1:10025 inet n    -       n       -       -     smtpd
     -o content_filter=
     -o smtpd_delay_reject=no
     -o smtpd_client_restrictions=permit_mynetworks,reject
     -o smtpd_helo_restrictions=
     -o smtpd_sender_restrictions=
     -o smtpd_recipient_restrictions=permit_mynetworks,reject
     -o smtpd_data_restrictions=reject_unauth_pipelining
     -o smtpd_end_of_data_restrictions=
     -o smtpd_restriction_classes=
     -o mynetworks=127.0.0.0/8
     -o smtpd_error_sleep_time=0
     -o smtpd_soft_error_limit=1001
     -o smtpd_hard_error_limit=1000
     -o smtpd_client_connection_count_limit=0
     -o smtpd_client_connection_rate_limit=0
     -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters
     -o local_header_rewrite_clients=
     -o smtpd_milters=
     -o local_recipient_maps=
     -o relay_recipient_maps=

Enfin, on active le tuyau postfix => amavisd-new pour permettre l’analyse : (pas de tri, on balance tout ; on pourrait restreindre par domaine, adresse émettrice etc). C’est dans /etc/postfix/main.cf :

content_filter=amavisfeed:[127.0.0.1]:10024

Dans cette configuration par défaut, il faut que les ports 10024 et 10025 (localement) soient libres. Les paramètres sont décrits dans la doc en .gz mentionnée ci-dessus. L’idée, en gros, est de créer un autre serveur SMTP, local uniquement sur le port 10024, avec une conf postfix indépendante et vierge – en gros – car on sait que les messages arrivant là seront passés par amavis, donc ils seront propres/nettoyés. Cette seconde instance postfix sera la porte d’entrée pour les retours d’amavisd-new.

Tests des briques de la communication postfix <=> amavisd-new

Là, on peut tenter un /etc/init.d/postfix reload.

Ecoute de amavis

Le 10024 répondait déjà (car c’est le port d’écoute de amavis, lancé depuis qu’on l’a installé) :

# telnet localhost 10024
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 [127.0.0.1] ESMTP amavisd-new service ready

Ecoute du 2è postfix (la voie de retour d’amavis)

Le port 10025 ne fonctionne qu’après la conf dans master.cf et un postfix reload :

# telnet localhost 10025
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 srv.net ESMTP Postfix (Debian/GNU)

Tests des décodeurs de pièces jointes

On peut voir les « décodeurs » qu’il manque dans /var/log/mail.log.

/var/log/mail.log:Aug 25 17:18:21 srv amavis[28164]: No decoder for       .lha

Dans le cas ci-dessus, on peut conclure que le paquet lha n’est pas installé.
Attention, la doc dit quelque part de se méfier des décodeurs pour analyse des TNEF. Vous risquez de perdre les mails écrits en RTF par Outlook-le-casse-couipied.

Test du retour de mails

On teste un envoi de mail à amavis, et donc le retour :

# telnet localhost 10024
Trying 127.0.0.1...
Connected to localhost.localdomain.
Escape character is '^]'.
220 [127.0.0.1] ESMTP amavisd-new service ready
helo localhost
250 [127.0.0.1]
mail from: <>
250 2.1.0 Sender <> OK
rcpt to:

250 2.1.5 Recipient
 OK
data
354 End data with .
From: virus-tester
To: undisclosed-recipients:;
Subject: amavisd test - simple - no spam test pattern

 This is a simple test message from the amavisd-new test-messages.
.
250 2.0.0 Ok, id=28165-03, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as 5FD7D9C4057
quit
221 2.0.0 [127.0.0.1] amavisd-new closing transmission channel
Connection closed by foreign host.

Résultats dans /var/log/mail.log (le retour à postfix prend quelques secondes) :

# tail /var/log/mail.log
Aug 27 11:37:43 srv postfix/smtpd[681]: connect from localhost.localdomain[127.0.0.1]
Aug 27 11:37:43 srv postfix/smtpd[681]: 5FD7D9C4057: client=localhost.localdomain[127.0.0.1]
Aug 27 11:37:43 srv postfix/cleanup[683]: 5FD7D9C4057: message-id=<20090827093743.5FD7D9C4057@srv.net>
Aug 27 11:37:43 srv postfix/qmgr[30259]: 5FD7D9C4057: from=<>, size=724, nrcpt=1 (queue active)
Aug 27 11:37:43 srv amavis[28165]: (28165-03) Passed BAD-HEADER, <> ->
, quarantine: 5/badh-5kHJ7I-xUr2T, mail_id: 5kHJ7I-xUr2T, Hits: -, size: 175, queued_as: 5FD7D9C4057, 81992 ms
Aug 27 11:38:39 srv postfix/local[684]: 5FD7D9C4057: to=, orig_to=
, relay=local, delay=56, delays=0.14/0/0/56, dsn=2.0.0, status=sent (delivered to command: /usr/bin/procmail -a "$EXTENSION")
Aug 27 11:38:39 srv postfix/qmgr[30259]: 5FD7D9C4057: removed

Activation de l’appel amavisd-new <=> ClamAV+Spamassassin

Enlevez les commentaires, c’est tout

C’est expliqué ici : /usr/share/doc/amavisd-new/README.Debian.
Comme d’hab, les fichiers de conf pré-machés par Debian sont très bien et attention à ne pas tenir trop compte de documentation de bidouilleurs qui paramètrent tout ça à la sauce pas-très-Debian.
D’après le README cité ci-dessus, la conf s’active dans /etc/amavis/conf.d/15-content_filter_mode. Il suffit de décommenter les 4 lignes suivantes dans /etc/amavis/conf.d/15-content_filter_mode : (2 pour ClamAV, 2 pour spamassassin)

@bypass_virus_checks_maps = (
   \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re);
@bypass_spam_checks_maps = (
   \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re);

En faisant celà, on active la conf définie dans les autres fichiers de /etc/amavis/conf.d/, exemple 15-av_scanners pour les anti-virus. Il s’agit là aussi de modèle de configuration standard de tout un tas d’outils connus (une bonne 15aine d’anti-virus dont NOD32, F-Prot, Grisoft, KAV, du symantec etc). Amavisd-new va donc charger les AV qu’il trouve. De même pour spamassassin.

Petit oubli pour ClamAV

On se paye une erreur :

Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)run_av (ClamAV-clamd) FAILED - unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n"
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)ClamAV-clamd av-scanner FAILED: CODE(0x90a9148) unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n" at (eval 86) line 527.
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)WARN: all primary virus scanners failed, considering backups

L’utilisateur clamav doit être dans le groupe amavis, on fait ce qui est dit dans le README.Debian de amavisd-new :

# adduser clamav amavis
Ajout de l'utilisateur « clamav » au groupe « amavis »...
Ajout de l'utilisateur clamav au groupe amavis
Terminé.

Et on contrôle le paramètre suivant dans la conf ClamAV : AllowSupplementaryGroups true. C’est déjà positionné dans le /etc/clamav/clamd.conf fraîchement dépaqueté. Vérifiez tout de même.
Et on redémarre ClamAV évidemment.

On peaufine certains paramètres

Destinataires des alertes

Pensez à bien ajuster les destinataires de « abuse », « postmaster » et « root » de votre serveur. Soit en modifiant les variables comme :

$virus_admin
$banned_admin
$mailfrom_notify_admin OU recip OU spamadmin
$hdrfrom_notify_sender

Soit en étant sûr que ces comptes par défaut (et obligatoires, surtout postmaster) font bien suivre les mails vers une adresse que vous lisez/survolez.

Voyez la doc mentionnée plus haut pour des suggestions à propos des variables $virus_admin & co.

Resctrictions de base de postfix

Je n’en parle pas trop, mais pensez à la conf de base de postfix, notamment votre paramètre smtpd_sender_restrictions dans /etc/postfix/main.cf.
Utilisez un service web quelconque sur Google pour valider que votre serveur n’est pas un open-relay.

Pièces jointes

Dans /etc/amavis/conf.d/20-debian_defaults, je suggère d’élargir la liste des pièces jointes interdites (par extension). Plus besoin de sanitizer, c’est intégré dans amavisd-new. Exemple :

### JACQUES
#  qr'.\.(exe|vbs|pif|scr|bat|cmd|com|cpl)$'i, # banned extension - basic
 qr'.\.(ade|adp|app|bas|bat|chm|cmd|com|cpl|crt|emf|exe|fxp|grp|hlp|hta|
        inf|ins|isp|js|jse|lnk|mda|mdb|mde|mdw|mdt|mdz|msc|msi|msp|mst|
        ops|pcd|pif|prg|reg|scr|sct|shb|shs|vb|vbe|vbs|
        wmf|wsc|wsf|wsh)$'ix,  # banned ext - long
###

# qr'.\.(mim|b64|bhx|hqx|xxe|uu|uue)$'i,  # banned extension - WinZip vulnerab.

  qr'^\.(exe-ms)$',                       # banned file(1) types
# qr'^\.(exe|lha|tnef|cab|dll)$',         # banned file(1) types
### JACQUES
  qr'^\.(exe|lha|cab|dll)$', # OK pour TNEF, merci outlook
###

Comportement lors de détection de spam

EDIT 08/10/2009. Quelques variables importantes à positionner (écraser par rapport à la conf par défaut) :

[...]
serveur:/etc/amavis/conf.d# cat 50-user
$final_spam_destiny = D_DISCARD; # pour eviter de renvoyer des notifications inutiles a des zombies
$sa_tag_level_deflt  = undef; # pour toujours avoir le tag dans les headers, même si c'est pas du spam
$sa_tag2_level_deflt = 5.0; # d'habitude je mets 5, na !
$sa_kill_level_deflt = 12.0; # d'experience, a 10 on est deja bien bien sur que c'est du spam
[...]

Enfin, j’avais oublié un point important, la variable « @local_domains_acl ». Elle défini la liste des domaines sur lesquels spamassassin va intervenir. Les domaines non listés ici ne sont tout simplement pas pris en compte, donc pas analysés, donc pas « flaggés »…
Je ne l’avais pas vu au début car avec un seul domaine qui est le nom de la machine etc, tout va bien avec le choix par défaut de Debian dans 05-domain_id:@local_domains_acl = ( ".$mydomain" );.
Là où ça se complique, c’est quand vous gérez plusieurs domaines, suivant comment votre bousin est défini. Par exemple avec des domaines virtuels, gérés en base de données, c’est mort (prochain article à venir sur la gestion de domaines et d’utilisateurs virtuels).
J’ai donc forcé cette variable dans le fichier /etc/amavis/conf.d/50-user :

@local_domains_acl = ( ".maboite.fr", "un.autre.alias.net" );

A noter que là, je prends en charge les éventuels sous-domaines « toto.maboite.fr » (c’est voulu, grâce au point devant « maboite ») et uniquement « un.autre.alias.net », mais pas un domaine de mails qui s’appellerait « encore.un.autre.alias.net ». Pigé ?

Quarantaine

Où doivent aller les mails vérolés ? Par défaut, je suggère de ne rien toucher au paramètre $virus_quarantine_to, ainsi les mails vérolés vont dans une arborescence de /var/lib/amavis/virusmails. Jetez-y un oeil une fois des tests de détection effectués (voir ci-dessous, dernier chapitre).
Et documentez vous sur amavisd-release.

Décodeurs, suite et fin

Dans /etc/amavis/conf.d/01-debian, jouez avec les variables $unrar et autres qui vous intéressent (oui oui, unrar c’est pas libre, tout ça, installez le paquet vrms). Il vous faut les applications correspondantes. Voyez le log /var/log/mail.log pour savoir ce qu’il manque par rapport à votre conf.

spamassassin

If you use spamassassin with the Bayes database system, you should make sure
that the spamassassin configuration option « bayes_auto_expire 0″ is set in
spamassassin configure files. This disables the automatic expiration of tokens
which causes problems for amavisd-new when activated. The amavisd-new package
includes cron jobs that take care of syncing and expiring the token database
frequently.

Je ne mesure pas trop l’impact, à vrai dire, mais je suppose qu’il vaut mieux le faire, donc ajoutez bayes_auto_expire 0 dans la conf /etc/spamassassin/local.cf.

Mise à jour de l’anti-virus

Le programme freshclam est planifié automatiquement lors de l’installation de ClamAV. Vous pouvez contrôler sa bonne exécution (il tourne une fois par heure) dans :

srv:/etc# tail /var/log/clamav/freshclam.log
Received signal: wake up
ClamAV update process started at Thu Sep 10 15:25:18 2009
main.cvd is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven)
daily.cld is up to date (version: 9791, sigs: 77548, f-level: 43, builder: guitar)
--------------------------------------
Received signal: wake up
ClamAV update process started at Thu Sep 10 16:25:18 2009
main.cvd is up to date (version: 51, sigs: 545035, f-level: 42, builder: sven)
daily.cld is up to date (version: 9791, sigs: 77548, f-level: 43, builder: guitar)
--------------------------------------

Testez avec EICAR

EICAR est un virus inoffensif. Essayez de vous envoyer des mails avec différentes pièces jointes fournies ici : http://securite-informatique.info/virus/eicar/. Vous validerez ainsi la réaction de votre serveur.
J’ai eu une erreur dans le mail.info lors de la détection du virus. Le serveur tente d’informer l’admin des virus, mais avec une légère erreur de syntaxe sur l’expéditeur :

Sep 21 15:33:37 ns305192 postfix/smtpd[20381]: warning: Illegal address syntax from localhost.localdomain[127.0.0.1] in MAIL command:

J’ai alors modifié la liste des expéditeurs de mails d’alertes. Dans le fichier /etc/amavis/conf.d/50-user :

$mailfrom_notify_admin='postmaster@chezmoi.fr';
$mailfrom_notify_recip='postmaster@chezmoi.fr';
$mailfrom_notify_spamadmin='postmaster@chezmoi.fr';
$mailfrom_to_quarantine='postmaster@chezmoi.fr';

J’ai trouvé la liste de toutes les adresses émettrices d’alertes sur ce site : http://www.radical-spam.org/documentations/amavisd-new.html. Il y a de belles explications sur les modèles de mails et d’autres trucs. Bref, à survoler.
Je n’ai pas trouvé comme pour postfix une commande permettant de voir les variables en mémoire d’amavisd-new. Si ça existe, je suis preneur.

Pour ceux qui n’utiliseraient pas encore de greylisting pour limiter le nombre de spams en entrée de ses serveurs de mails, j’explique comment mettre en place dans ma doc Debian et dans plusieurs articles sur ce blog.

Voici donc une capture d’un échange dans /var/log/mail.[info|log] d’un serveur envoyant un mail à cette architecture postfix/postgrey. Vous pouvez l’imprimer et l’afficher au-dessus de votre lit, c’est joli.

Rappel de la théorie

Le greylisting demande à l’émetteur de renvoyer le mail plus tard, disons 5 minutes. C’est un comportement normal et possible d’un serveur SMTP. Si l’expéditeur est complètement bidon (un zombie par exemple), cette réponse n’arrive jamais. Le mail – qui est un spam ou venant d’un serveur configuré avec les pieds – ne reviendra jamais et n’ira donc pas plus loin que la porte d’entrée du serveur. Pas de traitement anti-spam, rien. Economie de charge CPU etc.
Au bout de quelques mails effectivement reçus de la part de tel serveur, alors on le whiteliste car il semble au moins digne de confiance (je n’ai pas dit qu’il n’envoyait pas du spam). Attention au délai de réception pendant une journée ou 2.

Let’s go

Prise de contact

Aug 27 15:51:05 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:51:06 mon_srv postgrey[12790]: action=greylist, reason=new, client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:51:06 mon_srv postgrey[12790]: cleaning up old logs...
Aug 27 15:51:06 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:51:06 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

On voit l’action de postgrey (action=greylist) au motif que ce serveur n’a pas encore été whitelisté (reason=new)
Avant dernière ligne : on informe le serveur expéditeur qu’il est greylisté, on en profite pour expliquer à l’admin d’en face qui (peut-être) lit les logs ce qu’est le greylisting.
Sous-entendu, on lui dit via le code retour 450 que la boite a un problème temporaire, sous-entendu, retente plus tard. Attention, on ne dit pas code 550 qui signifierait « la boite est morte définitivement ».

Maintenant on attend de voir s’il nous recontacte

Il revient, mais trop tôt

Une minute plus tard, on a :

Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:52:06 mon_srv postgrey[12790]: action=greylist, reason=early-retry (239s missing), client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:52:06 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

L’action est de le greylister à nouveau au motif qu’il est trop tôt (reason=early-retry (239s missing)). Le temps doit être donné dans la réponse d’indisponibilité temporaire mais ça ne se voit pas au niveau des logs).
Et on le renvoit dans ses pénates.
Le revoilà, mais encore trop tôt.< méchanceté gratuite>C’est un serveur Exchange, il ne doit rien comprendre à ce qu’on dit< /méchanceté gratuite>.

Aug 27 15:53:06 mon_srv postfix/smtpd[17150]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 15:53:08 mon_srv postgrey[12790]: action=greylist, reason=early-retry (177s missing), client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr
Aug 27 15:53:08 mon_srv postfix/smtpd[17150]: NOQUEUE: reject: RCPT from le.nouvel.expediteur.fr[10.20.30.40]: 450 4.2.0 : Sender address rejected: Greylisted, see http://postgrey.schweikert.ch/help/mon_srv.ovh.net.html; from= to= proto=ESMTP helo=
Aug 27 15:53:08 mon_srv postfix/smtpd[17150]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

̉Trop c’est trop : anvil

Maintenant, c’est simplement le processus « anvil » de postfix, le « contrôleur de nombre de sessions et taux de bourrinage » qui détecte que le serveur en face est un peu trop insistant (il vient trop souvent) :

Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max connection rate 1/60s for (smtp:10.20.30.40) at Aug 27 15:51:05
Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max connection count 1 for (smtp:10.20.30.40) at Aug 27 15:51:05
Aug 27 15:56:28 mon_srv postfix/anvil[17153]: statistics: max cache size 1 at Aug 27 15:51:05

On ferme carrément la connexion. Reviens plus tard on te dit.

Là il est calmé

Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: connect from le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 16:03:09 mon_srv postgrey[12790]: action=pass, reason=triplet found, delay=724, client_name=le.nouvel.expediteur.fr, client_address=10.20.30.40, sender=exped@iteur.fr, recipient=destin@mon_srv.fr

J’accepte son mail comme on voit ci-dessous (action=pass) au motif qu’on l’a déjà bien embêté (reason=triplet found). Au final, il y a aura eu pour ce mail 724 secondes de délai. Rappelez-vous que ça peut être gênant lors d’une mise en place sur un serveur déjà en prod.

La suite est l’enchaînement logique postfix :

Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: 1E6B29C4057: client=le.nouvel.expediteur.fr[10.20.30.40]
Aug 27 16:03:09 mon_srv postfix/cleanup[17164]: 1E6B29C4057: message-id=<8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>
Aug 27 16:03:09 mon_srv postfix/qmgr[15006]: 1E6B29C4057: from=, size=6905, nrcpt=1 (queue active)
Aug 27 16:03:09 mon_srv postfix/smtpd[17159]: disconnect from le.nouvel.expediteur.fr[10.20.30.40]

On arrive dans amavisd-new :

Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)run_av (ClamAV-clamd) FAILED - unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n"
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)ClamAV-clamd av-scanner FAILED: CODE(0x90a9148) unexpected , output="/var/lib/amavis/tmp/amavis-20090827T160309-17143/parts: lstat() failed: Permission denied. ERROR\n" at (eval 86) line 527.
Aug 27 16:03:09 mon_srv amavis[17143]: (17143-01) (!!)WARN: all primary virus scanners failed, considering backups

Aaaaah, ça foire (normal j’ai juste installé clamav, il est détecté par amavis, mais je n’ai rien configuré. Je dois avoir un problème de droits/groupes, ce genre-là. On verra dans mon prochain article qui décrira toute la mise en place.

Aug 27 16:03:10 mon_srv postfix/smtpd[17169]: connect from localhost.localdomain[127.0.0.1]
Aug 27 16:03:10 mon_srv postfix/smtpd[17169]: C2A8D9C405B: client=localhost.localdomain[127.0.0.1]
Aug 27 16:03:10 mon_srv postfix/cleanup[17164]: C2A8D9C405B: message-id=<8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>
Aug 27 16:03:10 mon_srv postfix/qmgr[15006]: C2A8D9C405B: from=, size=7349, nrcpt=1 (queue active)
Aug 27 16:03:10 mon_srv amavis[17143]: (17143-01) Passed CLEAN, [10.20.30.40] [10.20.30.40]  -> , Message-ID: <8DDA8A0D37FFCE449E93D51188CDBE5BEDA572@intern.srv.fr>, mail_id: xmX0C24kDlYt, Hits: -, size: 6905, queued_as: C2A8D9C405B, 1764 ms
Aug 27 16:03:10 mon_srv postfix/smtp[17165]: 1E6B29C4057: to=, orig_to=, relay=127.0.0.1[127.0.0.1]:10024, delay=1.9, delays=0.11/0/0/1.8, dsn=2.0.0, status=sent (250 2.0.0 Ok, id=17143-01, from MTA([127.0.0.1]:10025): 250 2.0.0 Ok: queued as C2A8D9C405B)
Aug 27 16:03:10 mon_srv postfix/qmgr[15006]: 1E6B29C4057: removed

Ci-dessus on a le baratin standard d’un amavis sans clamav (avec son anti-virus interne) qui finit par accepter le mail et le délivrer.

Voilà, c’est beau, on dirait du Rimbaud.

Informations en préambule

Les impacts pour l’utilisateur sont minimes : délai d’environ 30 minutes (en théorie 5 minutes) lors des x (x = 5 par défaut) premiers échanges entrants avec un serveur donné. L’article anglais sur wikipedia se veut un peu plus méfiant que sa traduction minimaliste en français. A vous de voir. L’autre risque serait de se retrouver face à un vieux serveur de mails tout pourri qui implémente mal le protocole… boarf, je doute que ça arrive dans la pratique. Au pire l’utilisateur verra le problème et il sera temps de whitelister ledit serveur.

Principe

Le principe – je vous renvois à l’article wikipedia pour plus de détails – est d’utiliser une fonction standard du procotole SMTP pour redemander l’envoi d’un mail lorsqu’on le reçoit. On indique au serveur de renvoyer le message dans 5 minutes. Deux options : le serveur en face le fait, ou non. Au bout de x fois – si le serveur s’est bien comporté – on le « whiteliste » pour de bon et il n’y aura plus de délai pour celui-ci.

Quel lien avec les spammeurs ?

Imaginez une armée de PC (windows) zombies envoyant des mails à tout va (à l’insu de l’utilisateur, forcément). Le zombie utilise un programme le plus simple possible qui se contente d’envoyer la purée. De toute manière, un PC zombie comme de ce type n’a en général pas de lien retour possible vers lui même sur le port 25 (pensez à votre PC derrière un routeur genre freebox). Donc il ne recevra jamais votre demande standard de renvoi de mails. Et donc vous n’aurez jamais le mail, qui était un spam à coup sûr. CQFD.
Lisez plus bas dans l’article quelques extraits d’adresses « greylistées », vous comprendrez que des zombies, il y en a des millions sur la planète… que fait Buffy ???
Reste ensuite les *vrais* spammeurs. Je ne sais pas dire si beaucoup d’entre eux utilisent des serveurs standard de mails. Ceux qui n’ont pas prévu le coup en tout cas, ils passent aussi à la benne. Les autres, je ne sais pas s’ils perdent du temps à renvoyer la purée alors que des gens mal protégés, il y en a tant d’autres…
Alors, en attendant que les zombies prennent en charge correctement le protocole et fasse des contournements réseaux compliqués (impossible ?), le greylisting peut vous aider.

Léger pré-requis sur les backups MX

Dernière petite remarque en préambule : il faut que tous vos serveurs frontaux (donc les backups MX) implémentent le greylisting !!! Donc oubliez les backups gracieusement offerts par votre fournisseur/hébergeur etc. En général ils ne le font pas. Si vous avez un tel backup MX – par pseudo-sécurité – il est en général déclaré de faible priorité et c’est justement celui qui est d’abord visé par les envois de spammeurs car on n’a moins souvent la main dessus. S’il ne greyliste pas, alors il enverra tout à votre MX principal qui acceptera sans broncher. Le greylisting ne servira pas à grand chose dans ce cas.
(Tiens, ça me fait penser à une technique qui consiste à utiliser un serveur inexistant comme MX de plus faible priorité. Faudra que je teste ça un jour. Si quelqu’un a un retour, je suis preneur)

Graphiques après plusieurs semaines d’utilisation

Plutôt qu’un long discours, quelques dessins. Je vous laisse deviner la date de mise en place…

Sur le frontal (MX primaire) :

Et sur le backend (qui identifie les spams une fois le mail accepté) :

En chiffres

Avec quelques chiffres moyens pris avant et après le greylisting (ceux sur le graphe sont pris « pendant » la mise en place, donc une moyenne d’avant/après, pas terrible), ça donne ça :
- Sur le frontal, avant, on recevait environ 9,5 msg/min et on rejetait 1/3 (tentatives d’openrelay, destinataires bidon etc). Maintenant, on en reçoit 3,2 par minute, toujours 1/3 de rejet pour les mêmes motifs.
- Sur le backend du coup, il y a une sacrée chute d’occupation CPU par « spamd » et on identifie 0,6 msg/min contre 6 par minute avant (même taux de faux-positifs ou d’oubli, à savoir presque nul).
- En une semaine, ce ne sont pas moins de 137000 « serveurs » (zombies) qui ont été greylistés, avec des charmants noms comme :

         0x50a1511f.hknxx3.adsl-dhcp.tele.dk[80.161.81.31] 2 Time(s)
         0x50a403bf.abnxx10.adsl-dhcp.tele.dk[80.164.3.191] 2 Time(s)
         103.95.119-80.rev.gaoland.net[80.119.95.103] 4 Time(s)
         12-208-209-2.client.mchsi.com[12.208.209.2] 2 Time(s)
         12-219-39-94.client.mchsi.com[12.219.39.94] 2 Time(s)
         124-171-184-145.dyn.iinet.net.au[124.171.184.145] 2 Time(s)
         129-28-235-201.fibertel.com.ar[201.235.28.129] 2 Time(s)
         131.201.218.87.dynamic.jazztel.es[87.218.201.131] 2 Time(s)
         131.206.50.60.cbj04-home.tm.net.my[60.50.206.131] 2 Time(s)
         1434933186.ip2long.net[85.135.87.194] 2 Time(s)
         149.pool85-49-8.dynamic.orange.es[85.49.8.149] 2 Time(s)
         1503021874.dhcp.dbnet.dk[89.150.75.50] 4 Time(s)
         152-60.go.evo.bg[85.217.152.60] 2 Time(s)
         156-90-99-58-T-tdtv.tinp.net.tw[58.99.90.156] 2 Time(s)
         167-68-246-201.adsl.terra.cl[201.246.68.167] 2 Time(s)
         168-226-244-166.mrse.com.ar[168.226.244.166] 2 Time(s)
...
         adsl-67-114-84-118.dsl.lsan03.pacbell.net[67.114.84.118] 2 Time(s)
         adsl-68-23-4-190.dsl.ipltin.ameritech.net[68.23.4.190] 2 Time(s)
         adsl-69-209-147-42.dsl.sfldmi.ameritech.net[69.209.147.42] 2 Time(s)
         adsl-69-209-154-96.dsl.sfldmi.ameritech.net[69.209.154.96] 2 Time(s)
...
         host234-234-static.116-81-b.business.telecomitalia.it[81.116.234.234] 2 Time(s)
         host241-167-dynamic.19-79-r.retail.telecomitalia.it[79.19.167.241] 2 Time(s)
         host246-209-dynamic.15-87-r.retail.telecomitalia.it[87.15.209.246] 2 Time(s)
         host248-13-dynamic.1-87-r.retail.telecomitalia.it[87.1.13.248] 2 Time(s)
...
         pool-71-241-246-243.washdc.fios.verizon.net[71.241.246.243] 2 Time(s)
         pool-71-244-163-181.chi01.dsl-w.verizon.net[71.244.163.181] 2 Time(s)
         pool-71-246-128-243.aubnin.fios.verizon.net[71.246.128.243] 2 Time(s)
         pool-71-251-115-130.tampfl.fios.verizon.net[71.251.115.130] 2 Time(s)
         pool-71-251-140-235.cmdnnj.east.verizon.net[71.251.140.235] 2 Time(s)
         pool-71-252-137-81.dllstx.fios.verizon.net[71.252.137.81] 2 Time(s)
         pool-71-99-87-26.tampfl.dsl-w.verizon.net[71.99.87.26] 6 Time(s)
...
         ppp83-237-30-117.pppoe.mtu-net.ru[83.237.30.117] 2 Time(s)
         ppp85-140-146-212.pppoe.mtu-net.ru[85.140.146.212] 2 Time(s)
         ppp85-140-21-109.pppoe.mtu-net.ru[85.140.21.109] 2 Time(s)
         ppp85-140-43-193.pppoe.mtu-net.ru[85.140.43.193] 2 Time(s)
         ppp85-141-174-160.pppoe.mtu-net.ru[85.141.174.160] 4 Time(s)
...
         unknown[116.22.163.196] 6 Time(s)
         unknown[116.45.106.170] 2 Time(s)
         unknown[117.12.65.40] 4 Time(s)
...

- 

Conclusion

N’hésitez pas, apt-get install postgrey, modif du fichier main.cf et reload de postfix. Ca prend 3 minutes et ça envoi du gros !