Pétard, je suis le seul aujourd’hui à être assailli de spams?
Mon serveur est presque à genou (load average à 9!!)
Conjonction d’un crétin d’italien (62.10.119.20) qui a innondé le monde de spam (sur des adresses fabriquées) semblant venir d’un domaine dont je m’occupe et je récupère les messages destinataires inexistants de partout, et par ailleurs un serveur summiteducation.com (207.142.21.119) qui a envoyé plusieurs milleirs de spams sur le domaine. Tout est filtré mais mon serveur a du mal . J’ai droppé le gars et mis une purge des messages de réponses «frozen» d’exim tous les 1/4 d’heures mais c’est quand même limite (en gros 10 à 20 messages par minute en flux permanent depuis 2 jours…) Pour un Pentium 166, c’est dur
Je ne sais pas trop. J’ai dû faire du nettoyage sur mon mailhub ce matin parceque son disque 10Go était saturé, donc comme j’archive aussi dessus tous le traffic entrant (une dizaine de boites seulement) avant transmission à l’exchange interne ainsi que le traffic sortant (60 tilisateurs), et que je ne fais que du marquage des spams, pas une suppression, ça vient p.e. de là, mais comment tu ferais, toi pour le vérifier (à part éplucher les mails à la main) ?
Ceci étant dit, ce genre de saturation m’arrive trés régulièrement et je jongle en permanence à la limite de saturation. Il va falloir que je filtre ce que j’archive, si on me laisse un peu de temps pour faire ça entre deux changement de piles de clavier que mes utilisateurs ne savent pas faire eux même, et un déplacement inopiné de machine d’un bureau à l’autre décidé par le boss et annulé 2 jours aprés.
En fait je me suis replongé dans le paramétrage d’exim, les mails faisaient en gros
exiscan -> spamassassin -> routage exim -> …
donc un mail à un gars qui n’existait pas était traité par spamassassin avant que le message d’erreur soit envoyé. J’ai donc fait la modification suivant à exim:
[code]# Spam Assassin
spamcheck_director:
do not use this director when verifying a local-part at SMTP-time
no_verify
When to scan a message :
- it isn’t already flagged as spam
- it isn’t already scanned
- it didn’t originate locally (as long as I don’t harbor spammers :-))
require_files = /var/filtre/$local_part
driver = smartuser
transport = spamcheck
Fin de SpamAssassin
[/code]
et j’ai crée un repertoire /var/filtre dans lequel j’ai fait un fichier vide pour chaque utilisateur et alias. Désormais, spamassassin ne fait un filtrage que pour les mails destinés à un utilisateur existant.
Au final hier, j’ai eu près de 20000 SMTP différents qui se sont connectés, 10000 avant hier contre en gros un millier les jours normaux…
La vérification est facile chez moi du fait de mon petit script «liste grise» smtpwrap, j’ai un floppée de lignes type
[quote]Jan 26 06:35:49 cerbere smtpwrap[8016]: ip=<24.249.105.34> net=<24.249.105> now=<1201325749> allow=<1201325926>
[/quote]
ce qui me permet de trouver le SMTP source et de voir le biais. Par ailleurs, les messages d’erreurs finissent souvent en Frozen , le nombre de ceux ci est passé de quelques dizaines à plus de 5000 par jour.
Ce matin ça c’est calmé d’un coup, je m’offre même le luxe de «dédropper» summiteducation.com qui va pouvoir m’inonder de nouveau. Je pense que c’est un coup de chaud uniquement du à ce crétin d’Italien qui a du inondé le monde de spams de ma part.
[edit: ah ben non, c’est reparti de plus belle, mais avec la modif le load average reste en dessous de 1 malgré de nouveau un flux de 10-20 messages par minute]
Chez nous, nous utilisons PureMessage (+ sendmail) sur 4 machines SUN Solaris.
IL nous arrive parfois d’avoir des attaques SPAM qui font chuter un peu les perfs sur le traitement de messages.
Lorsque nous avons des attaques en provenance d’une IP bien ciblée et que celle-ci semble être une IP “exotique”, nous faisons directement un drop dessus afin que les messages ne soient pas traités par notre moteur anti-spam (donc pour éviter les baisses de perfs).
Désolé si ça sert à rien mais il n’existerais pas une technique plus bas niveau genre pf + spamd (de chez OpenBSD), c’est réputé pour être moins consomateur en resources.
Si c’est juste les log qui posent problème pourquoi ne pas désactiver les log quand ça proviens de lui ?
Désolé si je dis des conneries, j’ai pas le temps de tout lire ma copine est là (^^ “Jel’aime!!!”).
Dans Exim on peut pas faire un drop d’une adresse IP directement en modifiant les fichiers de config ? Ca permettrait de couper net la connexion SMTP pendant le dialogue entre les deux hôtes : ça déchargerait complètement le moteur de SPAM.
En fait, j’ai fait deux choses, la config ci dessus décharge spamassassin lorsque le mail va conduire à un rejet. Par contre, j’ai écrit un wrapper pour clamav qui permet de limiter l’antivirus aux mails entrants sans erreurs. Pour cela faire comme suit:
Modification d’exiscan:
[code]— exiscan.conf Sat Jan 26 16:01:46 2008
+++ exiscan.conf~ Sat Jan 26 15:07:47 2008
@@ -100,7 +100,7 @@
If you use a “daemon” type scanner, this is the path and filename
of the UNIX socket used to communicate with the daemon.
$scannerex="/usr/local/bin/clamwrapper";
$scannerex="/usr/bin/clamscan";
Scanner command line flags
@@ -116,7 +116,7 @@
with the directory location the scanner should recursively sweep.
#!/bin/sh
FLAGS=" --unzip --unrar --arj --no-summary "
CLAM=/usr/bin/clamscan
DIR=$1
FICHIER=`echo $DIR | sed -e 's/-tmp$/-complete/'`
EXISTE=0
grep -E "for.*@" $FICHIER | head -n 1 >> /var/log/clamlog
DEST=`grep -E "for.*@" $FICHIER | head -n 1 | sed -e 's/^.*for[ <]*\([^@]*\)@.*$/\1/'`
echo -n $DEST >> /var/log/clamlog
FINAL=`echo $DEST | sed -e 's/^\([^@]*\)@.*$/\1/'`
if [ -f /var/filtre/$FINAL ] ; then
EXISTE=$[$EXISTE+1]
fi
DEST=`grep To: $FICHIER | head -n 1 | sed -e 's/To: //'`
echo -n " - "$DEST" " >> /var/log/clamlog
while `echo $DEST | grep -q ','` ; do
DESTS=`echo $DEST | sed -e 's/^[^,]*, *\(.*\)$/\1/'`
DESTD=`echo $DEST | sed -e 's/^\([^,]*\), *.*$/\1/'`
DESTV=`echo $DESTD | sed -e 's/^.*<\([^>]*\)>.*/\1/'`
FINAL=`echo $DESTV | sed -e 's/^\([^@]*\)@.*$/\1/'`
echo -n " "$FINAL >> /var/log/clamlog
if [ -f /var/filtre/$FINAL ] ; then
EXISTE=$[$EXISTE+1]
fi
DEST=$DESTS
done
DESTV=`echo $DEST | sed -e 's/^.*<\([^>]*\)>.*/\1/'`
FINAL=`echo $DESTV | sed -e 's/^\([^@]*\)@.*$/\1/'`
echo -n " "$FINAL >> /var/log/clamlog
if [ -f /var/filtre/$FINAL ] ; then
EXISTE=$[$EXISTE+1]
fi
if [ ! 0 -eq $EXISTE ] ; then
echo " : YES" >> /var/log/clamlog
$CLAM $FLAGS $DIR
else
echo " : NO" >> /var/log/clamlog
fi
avec ça, seul les mails entrant destinés à un compte nommé dans /var/filtre est passé par clamscan.
Cela permet de faire face à un assaut de mails d’erreurs sans problème.
Au risque d’être inutile dans cette discution, j’aimerai quand même soumettre l’idée du greylisting.
En effet, je l’utilise par le biais de postgrey, et je dois dire que je ne suis pas déçu.
Pour rejoindre ton problème de ressource, postgrey stock les mails sur 4 jours si le serveur d’en face ne répond pas. Du coup avec tes 86000/4j mails, ton p166 serai aussi dans les choux
Néanmoins, couplé à des checks sur des blacklists avant l’intervention de postgrey, la charge devient moins importante pour ce dernier
Je suis hostile au principe des listes noires et ne les utilise pas par principe. Pour la liste grise, j’utilise un wrapper que j’ai fait pour exim qui marche très bien pour la réception (et pas postgrey donc). Il s’intercale donc cela est transparent et très léger. À l’emission, cela ne dérange pas: lorsque le mail est envoyé, si il faut le garder 4 jours, ça ne fait que de l’encombrement de disque et peu de charge CPU.
. J’ai droppé le gars et mis une purge des messages de réponses «frozen» d’exim tous les 1/4 d’heures mais c’est quand même limite (en gros 10 à 20 messages par minute en flux permanent depuis 2 jours…) Pour un Pentium 166, c’est dur 
