Bonjour à tous,
 
Voila depuis quelques jours je suis victime de flood sur mon serveur de messagerie professionnelle. Je ne sais pas comment s'appelle cette attack mais (bombing ???) le principe est le suivant : envoi d'un mail identique pour le body mais pas pour le header. C'est à dire que le mx change tout le temps, l'expéditeur aussi, ce qui m'enpeche de bloquer par adresse ip du serveur ou par l'expediteur. J'utilise amavis avec spamassassin et je n'ai jamais eu aucun problème auparavant. Auriez - vous plus d'information a ce sujet et connaissez vous ce type d'attack , au mieux comment faire pour les bloquer.
 
Merci d'avance

essaye en ajoutant postgrey sur ton serveur. Ca n'arretera pas l'attaque, mais ça évitera que ton service antispam ne soit saturé. Le principe, le service enregistre le triplet expéditeur, ip du serveur, destinataire. Il rejette une première fois le message avec une erreur de type service indisponible, mais enregistre ces informations dans une db si l'expéditeur se représente (comme il le devrait cf rfc, il l'accepte). Ce système est d'une efficacité redoutable. Rien qu'avec ça, j'ai réduis le pourriel de plus de 60% dans ma boîte.  
 
http://postgrey.schweikert.ch/
 
EDIT, je me suis bien planté, mon explication ne vaut que  si tu utilises postfix. Or tu ne mentionnes pas le service mail utilisé.

Merci pour ta réponse, j'utilise bien postix avec amavis-new et spamassassin. Je viens de voir que l'installation n'est pas compliquée. Je test desuite mais cette attaque ne peux pas durée infiniment non ??? Qu'en pensez tu (vous) ?
 
 

je le souhaite pour toi. Tout dépend de la motivation et des moyens de l'attaquant.

Je viens d'installer postgrey et je vois dans les logs que déjà certains messages sont stoppés. J'attends l'enrichissement de la base de données postgrey et vous tiens au courant.
 
 
 

théoriquement, tu devrais voir plus que certains messages arrêtés. En fait la majorité devraient être rejeté la 1ère fois.
 
Attentions à l'odre des filtres dans ton fichier de config. Dès qu'une des conditions est remplie, le mail est accepté. J'avais fait l'erreur de mettre postgrey après le contrôle de la boîte de destination, du coup pour peu que l'adresse de destination soit correcte, le mail était accepté. En le mettant en début de ligne, il est beaucoup plus efficace.  

effectivement, ils sont tous en  NOQUEUE pour commence mais je suis de mettre de l'ordre dans mais logs (syslog-ng)... L'attack n'a pas arrêté (10000 mail depuis hier 16h00). Voila mon fichier de config :
 

 
Je vais le mettre en premier de la liste pour voir.
 
Merci
 
 
 

ne touche pas a l'ordre
 
si l'adresse de destination est correcte le mail passe quand meme par l'acl check_policy_service.
les filtres sont evalués en fin  de stage, et tant qu'aucun OK ou PERMIT explicites n'arrivent avant, le mail sera bloqué par postgrey.

Ce genre de SMTP foireux doit être listé dans les blacklists.
Du coup, j'éviterais le greylisting (c'est toujours chiant de delayé un mail urgent dont tu as besoin immédiatement....)
 

J'ai activer les rbl mais rien, c'est toujours pareil, 30000 mail environ depuis avant hier, c'est la moyenne.
 
Je me demande si la vérification du reverse marche bien. Dans les logs j'ai :

 
Est ce que le from localhost veut dire qu'il n'a pas réussi à faire le reverse ??? Si oui il devrait pas être dans la QUEUE et donc pas dans amavis.
De plus si je prends un mx au hasard parmi tous les mails identiques et je m'aperçois, pour freeproblem.com par exemple, qu'il n'y a pas de reverse et le mail est dans les dossiers temp de amavis .  
Pourtant :
smtpd_sender_restrictions = reject_unknown_sender_domain
 
 
 
 
 

fais voir les logs

Liste des mails du robot qui passe :

visblement tu as pas mal de messages en queue car tu bounce les spams dans amavisd
 
tres mauvaise chose, car c'est toi qui va te retrouver blacklisté.
verifie ce point et vide la queue de postfix
 
il faudrait voir les logs d'avant pour etre sur de cela.
 
 
ensuite dans les rbl enleve blackhole, car elle n'existe plus

Le localhost ca veut dire que le serveur en face se présente sous ce nom ("helo localhost" ou "ehlo localhost" )
C'est souvent un bon point de filtrage que de refuser ces machines :

Tu crées un fichier /etc/postfix/helo_acces :

Un coup de postmap dessus
Et dans le main.cf :

Pour rejeter les "(unknown [W.X.Y.Z])" (pas de résolution inverse)  ca se fait aussi dans smtpd_helo_restrictions (cf. ci-dessus la ligne
en commentaire "warn_if_reject reject_unknown_hostname" ).
Mais c'est déconseillé de faire ça, c'est assez violent
Si tu veux vraiment l'activer, commence par du warn_if_reject histoire de voir le comportement que
ça aurait dans les logs, sans réellement rejeter.

Ton reject_unknown_sender_domain, ca ne fait que rejeter les mails avec des expediteurs dont le domaine
n'existe pas

 
Après un certain temps calme, j'ai eu une recrudescence de spams. Après vérifications, je me suis aperçu que spamhaus avait rassemblé ses filtres en un seul zen.spamhaus.org (au lieu de 3), j'ai éliminé 90% de mes spams après ca (j'en recevais une vingtaine / jour, maintenant à peine 1 ou 2, mais ma boite perso n'est pas la plus spammée).

mouais spamhaus j'aime pas trop, si y a beaucoup de traffic sur ton serveur,  ca a tendance à lagguer pas mal niveau DNS (ils doivent limiter les flux pour forcer les gros utilisateurs à souscrire un abonnement payant, ce qui est compréhensible, mais super désagréable ).

M'en fous, le DNS est pas à moi

C'est pas le serveur DNS qui me pose problème, c'est le postfix qui rale derrière et me pourri mes logs

bon c'est toujours aussi le bordel, je recapitule en fonction de vos précieuses inforamtions :
 
1) j'ai modifié amavis pour REJET des spams et non BOUNCE :
 

 
Au fait tu vois ou dans mes précedents logs que je faisais bounce ?
 
2) Rajout du helo restrictions que je n'avais pas avant dans ma conf avec fichier helo_acces qui bloque les localhost, 127.0.0.1 et localhost.localdomain

 
Je vois ne plus de localhost dans les mails du repertoire temporaire de amavis donc ok
 
J'ai rajouter      #warn_if_reject reject_unknown_hostname, mais vraiment trop restrictif je pense (vu dans les logs)
 
 
 
3) le recipient restriction qui a toujours été efficace pour moi, je n'utilise jamais les rbl.
J'ai essayé dans ce cas précis mais ca n'y a rien changé

 
 
4) Voici le mail identique que je lis dans le dossier temporaire d'amavis avec à chaque fois un serveur et un destinataire différent
 

 
 
Je fais body_check aussi "/etc/postfix/maps/body_checks" sur Viagra par exemple mais en vain
ça n'y change rien.
 
Merci de me dire ce vous en pensez

refais voir les logs et ton postconf -n  apres cette modif

 
le helo_acces ne marche pas j'ai encore le temp de amavis :
 

 
le postconf -n :
 

 
 
quelques logs :
 

Oui mais la le mail qui passe, y a aucune raison qui soit bloqué avant amavis, c'est tout à fait normal.
 
Donc soit tu mets des blacklists, soit du greylisting (je conseille fortement), tu peux aussi installer pyzor si ce n'est pas déja fait (géré par spamassassin derrière).
Si c'est toujours le meme type de spam, mets en une dizaine de coté, et fais les apprendre par spamassassin.

pour le helo_access, pas de faute dans le nom du fichier ? t'as pensé à faire un postmap dessus ?

non pas de faute :
 
:~# ls /etc/postfix/maps/helo_acces
/etc/postfix/maps/helo_acces

t'as un pb avec ton install d'amavisd c'est la 1ere chose a regler  
 
fais voir ton master.cf

Et je ne peux que conseiller moi aussi l'utilisation du grey listing

voila mon master tonio :
 

 
J'utilise le greylisting ...

ok c'est bien ca
tu as un pb avec ton install
 
tes mails en retour d'amavisd passe au travers de ton header_check et sont refusés par postfix, d'ou l'erreur
 
modifie la partie amavisd de ton master.Cf comme ceci:
 
 

 
puis postfix reload
 
 
au passage fais voir aussi les body, headers et mime_headers_checks pour les verifier

Tu peux augmenter le nombre de process max aussi.
A faire dans le master.cf (nombre de process smtp-amavis) et la conf de amavis.
 
Parce que 2 c'est pas beaucoup et ton serveur devrait pouvoir encaisser beaucoup plus

j'ai modifier,si je comprends bien, nous avons mis amavis en chroot qui ne l'etait pas.  
Et tu me dis qu'une fois le mail traité par amavis il pas au travers du header_check, quelle ligne de conf te faire dire ca et le header-check ne doit - il pas être fait avant amavis ?
 
Voila mes fichiers :
 

c'est pas le chroot le pb  (je l'ai mis car j'ai l'habitude mais sinon tu peux l'enlever)
 
le point important c'est:
 

 
le no_header_body_checks  dit a postfix de NE PAS faire de verif des headers, body, mime sur le retour d'amavisd.
 
cette verif est  faite avant amavisd, comme déclaré dans le main.cf.
En retour c'est inutile et pire en cas de match sur la regle, cela genere une erreur dans amavisd.
C'etait exactement ce que montrait tes logs plus haut:
 
 

 
le pire c'est que cela générait un bounce vers le MAILFROM du message rejeté, le plus souvent un mailfrom falsifié et tu devenais alors une source de backscatter.
 
 

Re-bonjour a tous, j'y vois plus clair maintenant merci.
Par contre maintenant j'ai :
 

 
Etant donné que j'ai pas trop touché le main.cf, je pense que ca vient du master.cf mais il est identique à c que tu ma dis et au doc aussi  que j'ai trouvé sur le net.

ce log vient d'un mail en queue qui utilisait l'ancien transport
 
mailq pour verifier
 
apres soit tu l'effaces: postsuper -d queue_id , soit tu le remets en queue, il reprendra alors les bons parametres: postsuper -r queue_id

J'ai vidé la queue et j'ai toujours le même problème en faisant un mail en ligne de commande (telnet). Par contre cette fois ci le helo_acces marche bien puisque je pouvais pas faire un mail en ligne de commande. J'ai donc virer le 127.0.0.1 du helo_acess. Est ce que peut l'on restreindre la limitation uniquement de l'exterieur afin de pouvoir au moins se connecter en telnet
 
 

C'etait juste le nom du content-filter qui ne correspondait pas au master.cf.
Je continu ...

oui il fallait adapter le main.cf  
 
en revanche je n'ai pas compris ton histoire de helo_access