System-Linux

Aller au contenu | Aller au menu | Aller à la recherche

Installation Greylisting avec Postgrey pour Postfix

greylist jpg

Une technique parmi d'autre pour lutter contre les spams.

Le greylisting : inscription sur liste grise est une technique antispam/antipourriel très simple qui consiste à rejeter temporairement un message, par émission d’un code de refus temporaire au serveur smtp émetteur (MTA). Dans la majorité des cas, les serveurs émetteurs réexpédient le courriel après quelques minutes. La plupart des serveurs émettant des pourriels ne prendraient pas cette peine.

Alors bien-sur un spammeur un peu plus futé fera un deuxième envoie, et sera donc accepté, mais parait ils le font que très rarement.

Vous aurez un petit délai d'attente pour la réception des emails mais une fois une première quarantaine effectuée, au bout de 5 envois honnêtes plus de soucis. A moyen terme, donc, c'est un problème moins gênant.

Lorsqu'un même serveur envois 5 mails et qu'ils sont valide, il enregistre automatiquement son adresse ip en whitelist.

Installation :

Pour Debian et Ubuntu :

aptitude install postgrey

Pour Centos et Redhat :

yum install postgrey

Dans les deux cas vous aurez sûrement quelques dépendances qui s'installeront aussi (des modules perl par exemple).

Configuration :

Modifier dans la section smtpd_recipient_restrictions de votre fichier main.cf :

check_policy_service unix:postgrey/socket

ou

check_policy_service inet:127.0.0.1:60000

Selon votre installation et votre Os.

Si cette section n'existe pas créez la :

smtpd_recipient_restrictions =
        [...] 
        check_policy_service unix:postgrey/socket
        permit

Modification du délais pour postgrey :

Il est conseillé un peu partout de réduire le temps de 5 minutes par défaut (échéance à laquelle Postgrey rejettera les nouveaux messages) à 1 minutes et une fois une bonne whitelist bien remplit de repasser à 5 minutes :

Créez le fichier : /etc/sysconfig/postgrey et mettez y ceci :

OPTIONS="--unix=/var/spool/postfix/postgrey/socket --delay=60"

Démarrage de Postgrey :

Pensez d'abord a configurer le script d'init en cas de redémarrage de votre serveur :

chkconfig --levels 35 postgrey on 

Debian et Ubuntu :

invoke-rc.d postgrey start

Centos et Redhat :

service postgrey start

Vérifiez qu'il se soit bien lancé avec ps -ef | grep grey qui devrait vous donner quelque chose comme ça :

postgrey 23313  1 0 12:17 ?  00:00:00 /usr/sbin/postgrey -d --unix=/var/spool/postfix/postgrey/socket

Maintenant vous n'avez plus qu'a relancer Postfix et jeter un œil dans vos logs :

tail -f /var/log/maillog

Vous devriez y voir passer des choses comme :

Mar 30 13:16:37 galix postgrey[26143]: action=greylist, reason=new, client_name=vai-bmails.cirra.fr, client_address=83.145.72.120, sender=prvs=870501245c=sa
lson.umanis@monecam.com, recipient=gangan@zalteam.com
Mar 30 13:16:37 galix postfix/smtpd[26169]: NOQUEUE: reject: RCPT from vai-bmails.cirra.fr[83.145.72.120]: 450 4.2.0 <gangan@zalteam.com>: Recipient address
 rejected: Greylisted, see http://postgrey.schweikert.ch/help/zalteam.com.html; from=<prvs=870501245c=salson.umanis@monecam.com> to=<gangan@zalteam.com> pro
to=SMTP helo=<vai-bmails1.cirra.fr>

Si vous avez plusieurs serveurs mails :

Genre un mx secondaire par exemple pensez à faire ces quelques modifications :

  • Ajout dans main.cf section smtpd_recipient_restrictions : permit_mx_backup
  • Ajout dans postgrey_whitelist_clients.local le hostname ou l'ip de votre deuxième serveur (ceci pour tous les serveurs).

Ceci fait vos serveurs accepteront immédiatement les mails venant de l'un de leurs confrères sans passer par la greylist :)

Personnellement j'avais pas super confiance, je l'ai donc testé dans tous les sens sur un serveur mail secondaire (mx secondaire) et je n'ai eu aucun souci.

Si vous désirez sortir un utilisateur de ce fonctionnement :

Il vous suffira de mettre le début de son adresse dans le fichier : /etc/postfix/postgrey_whitelist_recipients

postmaster@
abuse@
administrateur@
jean-paul@

Pour les serveurs multi-domaines :

Pour ceux qui veulent aller plus loin voici l'url de la documentation Postfix à ce sujet : http://postfix.traduc.org/index.php/SMTPD_POLICY_README.html

Et le site http://www.greylisting.org

Par GanGan | le mercredi, mars 31 2010 07:00

Commentaires

1. michauko

mercredi, mars 31 2010 | 09:21

Salut,

2 remarques :
1) Je pense que le serveur expéditeur renvoie le mail quand il a envie, peu importe le timing que tu indiques à postgrey. Tout dépend du logiciel serveur en face, s'il écoute ce qu'on lui dit ou pas.
Pour preuve, par défaut on est sur 300 secondes, mais je vois une tonne de serveur exchange :) renvoyer la purée tout de suite, finir par se faire jeter par le surveillant (postfix/anvil) au motif de "max connection rate".
J'en donne un exemple là : http://michauko.org/blog/2009/08/27...

2) Concernant le MX secondaire. Qu'il y ait des liens de confiance entre le MX secondaire et le principal, oui. Mais il faut dire d'installer le greylisting sur le MX secondaire, sinon ce serveur ne fait pas de greylisting et le serveur principal dit amen.
Comme il y a fort à parier qu'il est de priorité plus faible et que les spammers et autres zombies prennent en priorité les serveurs MX de priorité plus faible, alors tout le processus est court-circuité...

Pour donner quelques chiffres et inciter les gens à faire du greylisting, voici un exemple de statistiques de réduction de spams en entrée d'un serveur d'une société de 150 personnes : http://michauko.org/blog/2008/03/05...

2. Julien

mercredi, mars 31 2010 | 10:50

Pourquoi faire revenir les messages du MX secondaires vers le MX principal ?
Le secondaire peux très bien envoyer ses emails directement au serveur IMAP via LMTP, plutôt que de repasser par le principal.

Et de fait, les deux serveurs MX réalisent leurs contrôles indépendamment.

3. GanGan

mercredi, mars 31 2010 | 13:55

Pour faire clair et rapide :)

pour michauko :

1) tu as raison c'est pour ça que je parle de rabaisser ce delais a 1 minutes.
2) Pour moi c'était logique mais peut être pas explicite dans le billet.

pour Julien :

Dans les configurations que j'ai vu jusque la durant ma petit expérience le mx secondaire ne récupérait les mails que lorsque le mx principal était injoignable et le serveur imap était sur le serveur mx principal.

Merci pour vos retours :)

4. Julien

jeudi, avril 1 2010 | 23:21

Yep, c'est egalement ce qui est mis en place sur linuxwall

http://wiki.linuxwall.info/doku.php...

Mais le MX secondaire a une file d'attente avec un TTL de 96H ce qui laisse le temps de remonter le serveur principal avant de bouncer les mails recus

5. GanGan

jeudi, avril 1 2010 | 23:49

c'est ou que tu spécifie les 96 heures dans la configuration de ton Postfix ? ça m'intéresse et ça peut en intéresser d'autres.

6. Julien

vendredi, avril 2 2010 | 16:47

maximal_queue_lifetime (default: 5d)

   The maximal time a message is queued before it is sent back as undeliverable.