[Admin-ml] AntiSpam

Lun 10 Déc 23:20:51 CET 2007

(je reposte, parce que visiblement ma réponse d'hier soir n'est pas  
passée)

Bonjour,

On 10 déc. 07, at 21:42, Gérard Sandoz wrote:

> j'ai un serveur (10.4.11) qui passe son temps à renvoyer les mails  
> en erreur suivre à la réception de spam en tout genre. Dans ma file  
> d'attente, jai des milliers de "MAILER_DAEMON" du genre , pas de  
> boite pour l'utilisateur zzz@ ou host erzeerzr not found et j'en  
> passe. Je supprime donc ses messages à la main pour le libérer un  
> peu de cette lourde tâche. Ne peut-on pas demander au serveur de ne  
> pas répondre en cas d'erreur. (oui, je sais, ce n'est pas postfix  
> friendly, un serveur doit répondre quand un message n'aboutit pas,  
> mais là, j'en arrive à ne plus pouvoir recevoir les mails légitimes).

la meilleur approche à mon avis c'est de passer en before queue  
filter pour l'antispam. Tu filtres le spam avant réception, donc tu  
peux le refuser sans avoir à émettre un quelconque message.

Si tu veux des pistes de réglages je peux t'en donner.

edit: maintenant que c'est le matin, je peux t'en donner. Dans tout  
ce qui suis, ne perd pas de vue que domaine.tld est TON domaine de  
mail. Quand il y a une adresse en @domaine.tld, tu ne peux pas mettre  
un domaine que ton serveur ne gère pas.

Dans mon master.cf j'ai ceci :

---------------------------------------------------------------------
# Before-filter SMTP server. Receive mail from the network and
# pass it to the content filter on localhost port 10025.
#
smtp      inet  n       -       n       -       250      smtpd
     -o smtpd_proxy_filter=127.0.0.1:10024
     -o smtpd_client_connection_count_limit=20
     -o smtpd_proxy_ehlo=amavis.at.domaine.tld
     -o inet_interfaces=mon.adr.esse.ip
     -o smtpd_timeout=150

#
# After-filter SMTP server. Receive mail from the content filter
# on localhost port 10025.
#
127.0.0.1:10025 inet n  -       n       -        -      smtpd
     -o smtpd_authorized_xforward_hosts=127.0.0.0/8
     -o smtpd_client_restrictions=
     -o smtpd_helo_restrictions=
     -o smtpd_sender_restrictions=
     -o smtpd_recipient_restrictions=permit_mynetworks,reject
     -o smtpd_data_restrictions=
     -o mynetworks=127.0.0.0/8
     -o receive_override_options=no_unknown_recipient_checks
---------------------------------------------------------------------

note bien que le 250 pour le nombre de smtp est très gros, du fait  
que notre serveur reçoit beaucoup de connexions. La technique du  
before queue content filter (bqcf) est très exigente en terme de  
performance et de ressources.

Le main.cf contient quant à lui quelque chose comme ça :

---------------------------------------------------------------------
# les domaines qui peuvent recevoir :
relay_domains =
     $mydomain
     autre-machine.domaine.tld

# les adresses qui peuvent recevoir :
relay_recipient_maps = hash:/etc/postfix/relay_recipient_maps

# on rejette les adresses de destinataires du type de la
# relay_recipient_maps mais qui ne sont pas dedans
# c'est activé par reject_unlisted_recipient plus bas dans
# la partie smtpd_recipient_restrictions pour bypasser les
# autres tests quand l'adresse de destinataire est bidon.
smtpd_reject_unlisted_recipient = yes

# comme au dessus, mais avec le parametre reject_unlisted_sender
# utilisé dans la section smtpd_sender_restrictions. cela permet
# de refuser les mails envoyés à partir d'un sender immitant une
# adresse de type relay_recipient_maps
smtpd_reject_unlisted_sender = yes

virtual_alias_maps = hash:/etc/postfix/virtual_alias

# pour plus de lisibilité, et SURTOUT, pour pouvoir jouer avec  
l'ordre des
# restrictions, on place les limites ordinaires dans  
smtpd_recipient_restrictions
# les autres smtpd_*_restrictions servent aux cas particuliers.
# On pourrait mettre check_client_access suivi de  
check_policy_service dans le
# bloc smtpd_client_restrictions. Malheureusement les  
client_restrictions sont
# traitées avant de connaître l'adresse du destinataires. On risque  
donc de
# faire exploser la DB greylist avec tous les destinataires invalides.
# En se plaçant dans smtpd_recipient_restrictions on bénéficie de  
tous les
# filtrages sur l'émetteur et le destinataire. On greyliste donc le  
minimum de
# triplets client-sender-recipient dans la DB : le greylisting est +  
efficace et
# reste plus léger au niveau ressources.
#
# check_client_access doit intervenir dans le même bloc que  
check_policy_service
# pour permettre de mettre les clients en whitelist avant la  
procédure de
# greylist
#
# smtpd_client_restrictions = permit

smtpd_sender_restrictions =
         reject_unlisted_sender,
         check_sender_access hash:/etc/postfix/sender_access
         reject_unknown_sender_domain,
         reject_non_fqdn_sender,
         permit

# on autorise mynetworks, on rejette unauth_destination,
# on filtre sur une blacklist d'IP et de CIDR puis on filtre sur une
# table de destinataires facultative (recipient_access).
# ensuite on teste que l'adresse de destinataires est autorisée
# via la relay_recipient_maps (reject_unlisted_recipient)
# si c'est bon, on check la whitelist pour ne pas greylister et  
sauter les RBL
# si c'est bon, on teste dans les RBL client
# si c'est bon, on teste dans les RBL sender
# si c'est pas bon, on greylist, si c'est bon, on "permit"
# après tout ça, on passe à l'antispam !
smtpd_recipient_restrictions =
         permit_mynetworks,
         reject_unauth_destination,
         check_client_access cidr:/etc/postfix/client_access_cidr,
         check_recipient_access hash:/etc/postfix/recipient_access,
         reject_unlisted_recipient,
         check_client_access hash:/etc/postfix/client_access,
#        reject_rbl_client zen.spamhaus.org,
         reject_rbl_client zen.dnsbl-local,
         check_policy_service unix:/var/run/postgrey.sock

---------------------------------------------------------------------

Tu noteras qu'on utilise aussi du greylisting, ce qui n'est pas  
obligatoire mais fortement conseillé pour du bqcf. Cela permet  
d'alléger énormément la charge sur amavisd, et donc tu as moins de  
chance de perdre des connexions en timeout.

Dans les différents fichiers j'ai ce genre de choses :

/etc/postfix/relay_recipient_maps (la liste de tous les destinataires  
légitimes : si tu n'es pas dans la liste tu ne peux pas recevoir de  
mail)
	...
	hotline-etu at domaine.tld       OK
	hygiene.proprete at domaine.tld  OK
	icar-dir at domaine.tld          OK
	icar-infos at domaine.tld        OK
	ids.licence3 at domaine.tld      OK
	@ext.domaine.tld              OK
	@listes.domaine.tld           OK
	...

/etc/postfix/sender_access  (généré via un script à partir d'une  
liste externe)
	...
	0001chicksx.com     REJECT BLACKLIST
	0007b.com           REJECT BLACKLIST
	00099f9u.com        REJECT BLACKLIST
	0009hotx.com        REJECT BLACKLIST
	...

/etc/postfix/client_access_cidr (pour les blacklist occasionnelles)
	...
	62.39.111.128/26        REJECT Et BOfH dit : tu liras ton abuse.
	195.114.114.0/23        REJECT Et BOfH dit : tu liras ton abuse.
	80.118.150.0/23         REJECT Et BOfH dit : tu liras ton abuse.
	...

/etc/postfix/recipient_access (pour les problèmes occasionnels :  
boucle de redirect entre deux comptes, ...)
	...
	jean.delafontaine at domaine.tld  REJECT user misconfiguration
	toto at domaine.tld             DISCARD
	...

/etc/postfix/client_access (une whilelist que j'ai compilée à partir  
de quelques Go de log de mail. Le but est de bypasser les greylists  
pour nos correspondants légitimes habituels.).
	# liste des IP a whitelister (24 premiers bits)
	#
	#        check_client_access hash:/etc/postfix/client_access,
	# doit se trouver juste avant le check_policy_service de postgrey  
pour eviter de
	# greylister les mails provenants des ip/24 en "permit", et sous  
tout le reste
	# pour que le "permit" ne bypasse d'autres filtres
	#
	193.30.227.216 permit
	12.130.136 permit
	17.72.133 permit
	...

Voilà. Avec un montage comme celui là, sur un XServe Intel en 10.4,  
8Go de RAM, 2 Xeon 3GHz, on rejette environ 2 millions de mails par  
semaine, et on en laisse passer environ 180000.
On a installé notre propre clamav (via macport), notre propre amavisd  
(à la main), et notre propre spamassassin (à la main). Cela nous  
permet de réagir bien plus vite qu'apple sur les mises à jour de  
sécurité.
Le gestionnaire de greylist installé est postgrey.
Sur cette machine, le moteur de greylist peut atteindre en moyenne à  
885.69 requêtes par seconde (pendant mes benches), ce qui est bien  
supérieur à ce qu'on constate dans la vraie vie, même avec notre  
serveur fortement sollicité. (notre pic de rejet pour la semaine  
passée est à 1900 mails/minute).

voilà, si t'as besoin de précisions...

Patrick Proniewski