SysAdmin Tips

Il est parfois utile de passer un mail à spamassassin manuellement pour voir le détail des tests entrepris et surtout la conclusion à la fin du traitement.

Copiez-collez le mail entier (headers + corps) dans un fichier texte et tapez la commande suivante:

spamassassin -D -t < mail.txt 2>&1

S’affichera alors le détails des actions entreprises. Vous pouvez faire un grep sur les mots clés qui vous intéressent (par exemple pour voir le résultat de l’examen SPF).

Courrier électronique spam

Lors d’une configuration typique d’un domaine ayant un serveur MX principal et un ou plusieurs secondaires, un problème généralement rencontré est que les spammeurs envoient le courrier au serveur MX secondaire, espérant ainsi trouver un serveur moins bien protégé contre le spam.

Une parade existe à cela. Prenons l’exemple du domaine example.org, ayant deux serveurs MX définis:

• le premier, mx1.example.org, serveur principal, défini avec une priorité de 1;
• le deuxième, mx.backupserver.tld, défini avec une priorité de 10;

Le principe, lors de l’envoi d’un mail, est de d’abord essayer le serveur ayant la priorité la plus importante (plus petit nombre). En cas de non réponse du premier serveur, on passe au suivant, et ainsi de suite. Si aucun d’entre-eux ne répond on garde le mail en queue et on attend un peu avant de recommencer.

Les spammeurs, eux, commencent parfois dans l’ordre inverse (à partir de la plus faible priorité), surchargeant ainsi le serveur de backup. La solution est donc de rajouter une troisième entrée MX dans la zone du domaine, ayant la priorité la plus faible mais pointant vers le même serveur que le MX principal. Au final, la configuration de la zone du domaine example.org deviendrait:

• mx1.example.org, priorité 1
• mx.backupserver.tld, priorité 10
• mx1.example.org, priorité 100

On peut utiliser pour la troisième entrée un hostname différent pointant vers la même ip pour brouiller les pistes.

Avec cette configuration DNS, l’activité du serveur de backup sera considérablement réduite, les spammeurs utilisant cette technique tomberont bien sur le serveur principal.

Il est évident que ceci n’est qu’une réponse à une technique précise des spammeurs, ils en utilisent malheureusement bien d’autres.

Général dns, mx, spam

Fail2ban est un démon qui lit les fichiers de logs au fur et à mesure de leur écriture afin de bloquer les ip indésirables pendant un temps donné. Le but est simplement d’éviter de surcharger votre serveur avec des dizaines de requêtes par seconde dont le seul but est d’essayer de trouver un couple utilisateur/mot de passe valide afin de tenter de hacker votre machine ou de s’en servir comme relais pour l’envoi de courrier électronique indésirable.

Fail2ban intègre par défaut le contrôle des scans SSH, en lisant votre fichier /var/log/auth.log. Il n’y a donc pas de configuration particulière à faire pour ssh.

Il est possible de le configurer pour qu’il lise aussi votre /var/log/mail.log afin de bloquer les adresses ip qui floodent votre serveur de courrier avec des couples login/mots de passe invalides. L’espoir des hackeurs est de tomber sur un serveur qui pratique le pop-before-smtp, c’est à dire la technique qui consiste à d’abord lire son courrier puis d’utiliser le serveur smtp. Le fait de s’authentifier avec succès sur le serveur pop implique que votre adresse ip est autorisée à envoyer du courrier pendant un certain temps, vers toutes les destinations. Les hackeurs peuvent alors se servir de votre serveur pour envoyer leur spam à la terre entière.

La première étape est de demander à dovecot de transcrire dans les logs les tentatives de connexion échouées. Cela se fait en éditant son fichier de configuration /etc/dovecot/dovecot.conf et en positionnant la directive auth_verbose à true.

Ensuite, il faut éditer le fichier /etc/fail2ban/jail.local et y rajouter

[dovecot-auth]
enabled  = true
port     = imap,imaps,pop3,pop3
sfilter   = dovecot-auth
logpath  = /var/log/mail.log

Vous pouvez rajouter d’autres directives: maxretry (nombre de tentatives après blacklistage), ignoreip (liste d’ip qui ne seront pas blacklistées séparées par des espaces) et bantime (temps de blacklistage en secondes). Attention, ne pas oublier de mettre 127.0.0.1 dans la liste des ip à ignorer, sans quoi des tentatives infructueuses via un webmail conduiraient à un auto-blacklistage, ce qui aurait un impact sur toutes les applications (postfix ne saurait plus se connecter à MySQL, par exemple). En haut du fichier, ces 3 directives sont présentes de manière globale, le fait de les repréciser dans une règle leur fait prendre le dessus pour la règle en cours.

Ensuite, créer un fichier /etc/fail2ban/filter.d/dovecot-auth.conf et y mettre

[Definition]
failregex = auth-worker(.*): sql(.*,<HOST>): unknown user

Il est évident qu’il peut être nécessaire d’adapter la regexp à votre situtation, l’ip à blacklister étant représentée par <HOST>. Dans ce cas-ci, on ne bloquera que les utilisateurs inexistants, la regexp peut par exemple être adaptée pour prendre en compte les vrais utilisateurs qui se trompent de mot de passe.

Redémarrer fail2ban et dovecot pour les faire prendre en compte leur nouvelle configuration.

Fail2ban consigne ses actions dans le fichier /var/log/fail2ban.log.

Système dovecot, hacker, imap, pop, scan, spam, ssh