Postfix et lutte contre le SPAM

elekaj34 · Le 20/02/2008, à 13:51

Bonjour,

Sur un serveur dédié, j'ai un install de Postfix, avec SpamAssassin.

SpamAssassin me traite le mails et place l'entete " ***** SPAM *****" si c'est positif (le lecture de mail faisant le tri).

Sur la totalité des "vrais positifs", Spamassassin detecte environ 25% en SPAM.
Par contre, pour les autres mails, le score est très faible (cf le quote ci-dessous de 9 mails étant du spam, et 2 détectés positifs)

X-Spam-Status: Yes, score=6.3 required=5.0 tests=DATE_IN_PAST_06_12,
FORGED_MUA_OUTLOOK,INVALID_MSGID,PRICES_ARE_AFFORDABLE autolearn=no
version=3.1.7-deb
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=ham
version=3.1.7-deb
X-Spam-Status: No, score=3.9 required=5.0 tests=BODY_ENHANCEMENT2,
HELO_DYNAMIC_HCC,HTML_MESSAGE autolearn=no version=3.1.7-deb
X-Spam-Status: No, score=0.6 required=5.0 tests=SUBJECT_DIET autolearn=no
version=3.1.7-deb
X-Spam-Status: No, score=0.0 required=5.0 tests=HTML_MESSAGE autolearn=ham
version=3.1.7-deb
X-Spam-Status: No, score=0.2 required=5.0 tests=HTML_MESSAGE,
MIME_BOUND_NEXTPART autolearn=no version=3.1.7-deb
X-Spam-Status: No, score=0.8 required=5.0 tests=INFO_TLD autolearn=no
version=3.1.7-deb
X-Spam-Status: No, score=0.4 required=5.0 tests=DRUGS_ERECTILE,HTML_MESSAGE,
HTML_SHOUTING5,HTML_TAG_EXIST_TBODY autolearn=no version=3.1.7-deb
X-Spam-Status: Yes, score=6.1 required=5.0 tests=DATE_IN_FUTURE_12_24,
DRUGS_ERECTILE,FORGED_MUA_OUTLOOK,HTML_MESSAGE,SUBJ_YOUR_FAMILY
autolearn=no version=3.1.7-deb

J'ai essayé de baisser le "required_score" de SpamAssassin à 3. Mais reste que sur le 9, 6 reste encore "faux négatifs" (du fait de leur score < 1)
Dans ma boite, après analyse, beaucoup de mails négatifs ont un score entre 0 et 2 en général.
Du coup, je ne peux pas agir sur le "required_score".

Y a til des ajustements à faire sur les filtres (dans une autre boite, j'avais installé un Postfix + SpamAssassin, avec un score à 3, et aucuns soucis, j'avais trés peu de faux positifs, et quasiment pas de faux négatifs) ?

Je pensais aussi renforcer la config de Postfix avec l'ajout de RBL. Qu'en pensez vous, sera til efficace ?

A titre d'infos, voici la config Postfix :

alias_database = hash:/etc/postfix/aliases
alias_maps = hash:/etc/postfix/aliases
append_dot_mydomain = no
biff = no
config_directory = /etc/postfix
disable_vrfy_command = yes
inet_interfaces = all
mydestination = ks353656, localhost, localhost.localdomain
mydomain = jupinfo.fr
myhostname = ks353656.kimsufi.com
mynetworks = 127.0.0.1
smtpd_helo_required = yes
smtpd_sender_restrictions = permit_mynetworks
virtual_alias_maps = mysql:/etc/postfix/mysql-virtual_aliases.cf, mysql:/etc/postfix/mysql-virtual_aliases_mailboxes.cf
virtual_gid_maps = static:5000
virtual_mailbox_base = /var/spool/vmail/
virtual_mailbox_domains = mysql:/etc/postfix/mysql-virtual_domains.cf
virtual_mailbox_maps = mysql:/etc/postfix/mysql-virtual_mailboxes.cf
virtual_uid_maps = static:5000

Que puis je faire pour lutter (efficacement) contre le Spam ?

Cordialement,

Uggy · Le 20/02/2008, à 15:05

Je ne pense pas qu'il soit conseillé de baisser le score de spamAssassin en dessous de 5 (risque de false positive).

Pour améliorer le bloquage, tu peux effectivement mettre en place des RBLs (attention tout de meme a celles que tu choisis) ...
Une autre solution peut etre de faire du greylisting.. (Postgrey par exemple)

elekaj34 · Le 20/02/2008, à 15:30

Uggy a écrit :

Je ne pense pas qu'il soit conseillé de baisser le score de spamAssassin en dessous de 5 (risque de false positive).
Pour améliorer le bloquage, tu peux effectivement mettre en place des RBLs (attention tout de meme a celles que tu choisis) ...
Une autre solution peut etre de faire du greylisting.. (Postgrey par exemple)

OK merci pour l'information.

Des listes RBLs a conseiller ?

Je vais tenter aussi le grey listing

Uggy · Le 20/02/2008, à 15:36

elekaj34 a écrit :

Des listes RBLs a conseiller ?

reject_rbl_client bl.spamcop.net
reject_rbl_client sbl.spamhaus.org
reject_rbl_client xbl.spamhaus.org
reject_rbl_client cbl.abuseat.org

elekaj34 a écrit :

Je vais tenter aussi le grey listing

http://postgrey.schweikert.ch/
Attention sous Gutsy, de base il se coupe al"atoirement.. non pas un pb de l'appli mais une lib d'un autre truc buggé...Une fois la lib en question upgradé..plus de pb. (je ne me rapelle plus de la lib)

toniotonio · Le 20/02/2008, à 15:53

fais egalement des verifs de base dans postfix

regarde mon tuto sur la partie antispam, au debut ca parle des verifs postfix

c'est la base a mettre en place, tu n'en as aucune actuellment

elekaj34 · Le 20/02/2008, à 18:39

Merci pour le réponse.

J'avais paramétrer le smtpd_recipient_restrictions un temps, mais cela posait des problèmes. C'est vrai que finalement cela ne résoud pas grand chose.

Maintenant, j'ai opté pour les restrictions suivantes :

smtpd_sender_restrictions = permit_mynetworks

smtpd_recipient_restrictions =
            check_policy_service inet:127.0.0.1:60000,
            reject_non_fqdn_recipient,
            reject_unknown_sender_domain,
            reject_non_fqdn_sender,
            reject_unknown_recipient_domain,
            reject_invalid_helo_hostname,
            reject_unlisted_recipient,
            reject_unlisted_sender,
            permit_mynetworks,
            permit_sasl_authenticated,
            reject_non_fqdn_helo_hostname,
            reject_unauth_destination,
            reject_rbl_client       bl.spamcop.net
            reject_rbl_client       sbl.spamhaus.org                       
            reject_rbl_client       xbl.spamhaus.org
            reject_rbl_client       cbl.abuseat.org       
            permit

Après avoir lu la doc de Postfix (pour comprendre les différents paramètres), je pense que cela est suffisant. Entre les vérifs, le greylistings et SpamAssassin je pense que je vais m'en sortir !

A propos, rien qu'avec le Greylisting, le nombre de spam/h a été divisé par 4 (bon faut vérifier dans le temps, mais j'ai beaucoup de spam).

Cordialement,

toniotonio · Le 20/02/2008, à 20:24

ton smtpd_sender_restrictions = permit_mynetworks ne sert pas a grand chose, tu pourrais l'enlever

en revanche evite de mettre
check_policy_service inet:127.0.0.1:60000,

avant le reject_unauth_destination

en cas de pb avec ton policy service, tu deviendrais un relais ouvert.
l

pef · Le 20/02/2008, à 20:32

Attention au greylisting, c'est redoutable mais tu peux aussi y perdre des plumes si tu n'est pas très vigilant.

Il se base sur le fait que les serveurs SMTP des spammeurs ne respectent pas les RFC et ne retenteront pas de ré-émettre en cas de refus lors de la 1ere connexion, alors que les serveurs SMTP "légitimes" le feront.

C'est cependant là que ça peut coincer, car si ces derniers sont mal configurés (ou qu'un pool de serveurs smtp est utilisé), les mails risquent d'être perdus, et l'expéditeur se mangera un message d'erreur.

Ce n'est pas pour rien que postgrey contient par défaut une assez grosse white-liste de serveurs SMTP !

J'ai utilisé durant plusieurs mois le greylisting, rien à dire, plus de 60% du spam à disparu, jusqu'au jour oà¹ j'ai loupé des mails très importants (emploi) car les serveurs SMTP de la société retentaient uniquement l'envoi 1 minute après le premier échec, donc contraire aux RFC, donc ils ne sont pas passés au travers.

à‰videmment c'est de leur faute, leur serveur est mal configuré et ne respecte pas les RFC, mais dans la pratique la perte de certains mails peut être grave.

Surveille donc bien tes logs, et configure bien ton postgrey

Dernière modification par pef (Le 20/02/2008, à 20:33)

Uggy · Le 20/02/2008, à 20:48

elekaj34 a écrit :

Maintenant, j'ai opté pour les restrictions suivantes :

- fait gaffe aux restrictions de HELO -> trop de false positive (trop de serveurs légitimes mal configurés)
- Comme la dit tonio, ne met rien avant reject_unauth_destination qui est suceptible de répondre un "ok"
- Je n'aime pas les "reject_unlisted*" car de mémoire ca fait un test sur le serveur en face ce qui est pas top top.
- Tu peux aussi mettre des "check_client_access" "check_recipient_access" "check_helo_access" "check_sender_access" "check_sender_mx_access"
- met le 127.0.0.1 entre cochets.. c'est plsu propre -> inet:[127.0.0.1]:60000
- Les virgules en fin de lignes ne genent pas mais ne sont pas nécessaires vu que tu as un espace.
- La ligne "smtpd_sender_restrictions = permit_mynetworks" n'est pas nécessaire vu que tu as l'as mis plus bas

Dernière modification par Uggy (Le 20/02/2008, à 20:50)

toniotonio · Le 20/02/2008, à 22:23

reject_unlisted_recipient et reject_unlisted_sender ne font pas de test sur le serveur en face.

c'est basé uniquement sur les comptes locaux

reject_unlisted_recipient est activé par defaut par le parametre global smtpd_reject_unlisted_recipient
le fait de le specifier dans le stage smtpd_restrictions permet de controler le moment ou va intervenir le controle

reject_unlisted_sender lui n'est pas activé par defaut dans le parametre smtpd_reject_unlisted_sender mais il s'avere capital pour lutter contre les mails qui specifie un peu n'importe quoi en mailfrom (mais dans un domaine que l'on gere)

pour les HELO le parametre bloquant ici est reject_invalid_helo_hostname, qui peut effectivment générer des FP sur des serveurs configurés avec les pieds, mais c'est plutot rare.
en revanche en terme d'elimination du spam c'est particulierement efficace, pour un cout en ressource nul.
idem pour reject_non_fqdn_helo_hostname

Uggy · Le 21/02/2008, à 00:26

toniotonio a écrit :

reject_unlisted_recipient et reject_unlisted_sender ne font pas de test sur le serveur en face.

Au temps pour moi.. J'aurais du faire gaffe et prendre le temps de vérifier au lieu de préciser que c'était "de mémoire" (surtout que je l'ai aussi dans ma conf et que l'autre est effectivement par défaut )
J'ai confondu avec les reject_unverified* (même si je n'ai pas testé)

toniotonio a écrit :

pour les HELO le parametre bloquant ici est reject_invalid_helo_hostname, qui peut effectivment générer des FP sur des serveurs configurés avec les pieds, mais c'est plutot rare.
idem pour reject_non_fqdn_helo_hostname

Trop de false positive pour moi avec ces paramètres..obligés de passer en warn_if_reject... (sinon trop de temps perdu par rapport au gain)
warn_if_reject reject_invalid_helo_hostname
warn_if_reject reject_non_fqdn_helo_hostname
warn_if_reject reject_unknown_helo_hostname
warn_if_reject reject_unknown_client

Par contre au niveau HELO, j'ai un check_helo_access qui contient mes domaines et IPs et la ca rejette pas mal sans jamais avoir le moindre FP.

Dernière modification par Uggy (Le 21/02/2008, à 00:52)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 20/02/2008, à 13:51

Postfix et lutte contre le SPAM

#2 Le 20/02/2008, à 15:05

Re : Postfix et lutte contre le SPAM

#3 Le 20/02/2008, à 15:30

Re : Postfix et lutte contre le SPAM

#4 Le 20/02/2008, à 15:36

Re : Postfix et lutte contre le SPAM

#5 Le 20/02/2008, à 15:53

Re : Postfix et lutte contre le SPAM

#6 Le 20/02/2008, à 18:39

Re : Postfix et lutte contre le SPAM

#7 Le 20/02/2008, à 20:24

Re : Postfix et lutte contre le SPAM

#8 Le 20/02/2008, à 20:32

Re : Postfix et lutte contre le SPAM

#9 Le 20/02/2008, à 20:48

Re : Postfix et lutte contre le SPAM

#10 Le 20/02/2008, à 22:23

Re : Postfix et lutte contre le SPAM

#11 Le 21/02/2008, à 00:26

Re : Postfix et lutte contre le SPAM

Pied de page des forums