Finesses pour les administrateurs système - Debian 6.0 Squeeze
Rédigé par Marc GUILLAUME | Aucun commentaireQuelques techniques supplémentaires et utiles à l'administrateur.
Logrotate
Sur un serveur de mail actif votre fichier /var/log/mail.log va grossir rapidement. Ce fichier ne grossit pas indéfiniment grâce au programme logrotate qui est installé par défaut. Chaque jour (contrôlé par cron - voir le fichier /etc/cron.daily/logrotate file) les fichiers de log subissent une rotation. C'est à dire que l'ancien fichier mail.log est renommé en mail.log.1 et le démon Syslog est relancé de façon à ouvrir un nouveau fichier mail.log vide. Au cycle suivant le fichier mail.log.1 devient mail.log.2 qui est compressé au format GZip et pour donner un fichier beaucoup moins volumineux mail.log.2.gz.
Ce comportement est contrôlé par le fichier /etc/logrotate.d/rsyslog. Par défaut les cycles de rotations sont définis avec les options weekly (par semaine) et rotate 4 (rotation sur quatre fichiers). Avec cette configuration la rotation de fichier se fait un fois par semaine et après quatre rotations le fichier le plus ancien est effacé. Les serveurs de courrier très sollicités peuvent avoir besoin de rotations quotidienne. Il faut alors remplacer weekly par daily (par jour). Du coup les 4 rotations de fichier par défaut ne représentent plus que quatre jours et plus quatre semaine. Il faut donc augmenter le chiffre de rotations de façon significative. Par exemple rotate 90 gardera les logs des 90 derniers jours.
File d'attente et identifiants de file d'attente (queue IDs)
Comprendre le fonctionnement de la file d'attente de Postfix est très utile. Postfix va mettre tous les mails acceptés en file d'attente avant qu'un autre processus Postfix ne les récupère pour essayer de les distribuer. Vous pouvez voir quels mails sont actuellement en file d'attente en lançant dans le shell la commande :
mailq
Sur un serveur très actif vous pouvez avoir des centaines de mails en attente pour diverses raisons. Peut-être un FAI étrangle-t-il votre serveur car il envoit des quantités inhabituelles d'emails (ce qui peut facilement survenir quand vous envoyer une lettre d'information) ou bien le serveur de destination des mails est actuellement inaccessible. Un exemple des entrées qui peuvent figurer dans la file d'attente pourrait ressembler à ceci :
04D8CA8C442 2399 Tue May 31 09:49:11 MAILER-DAEMON
(connect to mx.example.com[146.44.5.213]:25: Connection timed out)
info@example.com
La chaîne de caractères 04D8CA8C442 est l'identifiant de file d'attente (queue ID). Pour voir ce qui s'est passé avec ce mail vous pouvez lancer la commande grep sur le fichier /var/log/mail.log :
grep 04D8CA8C442 /var/log/mail.log
La sortie pourrait être :
May 31 09:49:11 mx1 postfix/smtpd[4428]: 04D8CA8C442: client=web.localnet[10.10.41.3] May 31 09:49:11 mx1 postfix/cleanup[4473]: 04D8CA8C442: message-id=<20110531094911.0A73631F59D@newsletter.example.net> May 31 09:49:11 mx1 postfix/qmgr[25512]: 04D8CA8C442: from=<>, size=2399, nrcpt=1 (queue active) May 31 09:49:41 mx1 postfix/smtp[4945]: 04D8CA8C442: to=<info@example.com>, relay=none, delay=30, delays=0.05/0.06/30/0, dsn=4.4.1, status=deferred (connect to mx.example.com[146.44.5.213]:25: Connection timed out)
Les différents processus Postfix qui ont pris en charge le mail sont notés après postfix/.... Le processus smtpd a reçu le mail depuis le serveur web.localnet. Alors le processus cleanup a placé le mail dans la file d'attente. Ensuite le processus qmgr a déplacé le mail dans la file d'attente active et smtp a essayé de l'envoyer. Comme le serveur de destination mx.example.com ne pouvait être contacté, Postfix a laissé le mail dans la file d'attente. Le code DSN (delivry status notfication ou notification de statut de distribution) étant 4.4.1. Tous les codes commençant par 4 correpondent à des erreurs temporaires, Postfix essayera encore d'envoyer le mail. Les codes commençant par 5 correspondent à des erreurs permanentes et Postfix instantanément rejette le mail et informe l'expéditeur de l'erreur de distribution. Les codes commençant par 2 correspondent à des envois réussis.
Si l'envoi a réussi, alors la ligne postfix/smtp ressemblera à ça :
Jun 5 12:41:10 mail postfix/smtp[12044]: 2171CA860E0: to=<jonathan@example.com>, relay=mx.example.com[191.13.14.2]:25, delay=0.32, delays=0.04/0/0.17/0.1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B0BAC736372)
La dernière partie du message contient une châine de caractères que le serveur distant retourne si la distribution a réussi. Ainsi si vous voyer qu'un email s'est perdu entre votre serveur et le serveur de destination (mx.example.com) cette ligne des logs vous aidera beaucoup. Vous voyez que votre mail a été mis dans votre file d'attente sous l'identifiant 2171CA860E0 et envoyé à mx.example.com qui l'a placé dans sa propre file d'attente avec l'identifiant B0BAC736372. Vous pouvez ainsi interroger l'administrateur du serveur distant pour lui demander ce qui est arrivé à ce mail.
Avoir des statistiques
La lecture de votre fichier de log peut difficilement vous donner des informations d'ensemble. Surtout sur un serveur très actif, vous aurez difficilement une idée de ce qui se passe, sauf à compter les lignes de votre fichier de log. Je préfère traiter mes logs de courrier avec pflogsum (Postfix Log Summare c'est à dire Résumé des Logs Postfix). Ce programme est facile à installer :
aptitude install pflogsumm
Traitez alors votre fichier de log avec ce programme :
pflogsumm /var/log/mail.log
Vous obtenez généralement des comptes de ce genre :
messages 129 received 331 delivered 1 forwarded 8 deferred (59 deferrals) 3 bounced 586 rejected (63%) 0 reject warnings 0 held 0 discarded (0%) 3108k bytes received 3967k bytes delivered 36 senders 28 sending hosts/domains 229 recipients 147 recipient hosts/domains
Vous obtenez également un résumé du traffic heure par heure (combien de mails ont été envoyés et reçus et à quelle heure). Vous obtiendrez également un liste triée des domaines d'expéditon et de destination. A côté de ces statistiques générales pflogsumm extrait également les erreurs et les avertissements de telle sorte que vous avez une rapide vue d'ensemble des raisons pour lesquelles un mail a été mis en attente ou rejeté/renvoyé à l'envoyeur et une idée de l'efficacité des RBLs (real-time blacklists) que vous utilisez.
Regardez les exemples de paramètrage de tâches cron dans /usr/share/doc/pflogsumm/examples sur votre système. Ils vous aideront à obtenir un rapport automatique quotidien et hebdomadaire.
Bloquer les script Kiddies avec fail2ban
Vous êtes certainement au courant qu'Internet n'est plus l'endroit amical qu'il était jadis. Heureusement la plupart des attaquants que vous rencontrerez sur votre serveur de mail sont de stupides et aventureux script kiddies (voir la définition wikipedia de ce terme). Ils vont utiliser des scripts grossiers pour essayer quelques combinaisons de noms d'utilisateurs et de mots de passe pour essayer d'accéder à vos boîtes mail. Dans votre fichier /var/log/mail.log cela va ressembler à ça :
dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104 dovecot: pop3-login: Disconnected (auth failed, 1 attempts): user=, method=PLAIN, rip=61.144.24.114, lip=87.152.157.104
Nous n'utilisons pas de noms d'utilisateur de type « oscar » mais plutôt « oscar@example.com » donc ces ennuyeuses tentatives ne peuvent réussir. Mais pourquoi prendre un risque ? Nous pouvons alors utiliser le programme fail2ban (NdT : que l'on pourrait traduire par de l'erreur au bannissement) pour bloquer facilement ces attaques en force brute. Commençons par installer fail2ban sur notre serveur :
aptitude install fail2ban
Fai2ban lance un processus démon qui peut examiner divers fichiers de log, rechercher certains types de lignes correspondant à des tentatives d'attaque dans ces fichiers (en utilisant un filtrage par des expressions régulières) et agir en conséquence. Il est ainsi possible d'apprendre à fail2ban à rechercher des lignes de log rapportant des erreurs d'authentification comme celles de l'exemple plus haut et ajouter une règle de pare-feu (en utilisant iptables par défaut) pour bloquer les accès depuis l'IP du script kiddie. Par défaut fail2ban lance une action de blocage si il trouve trois tentatives d'attaque dans une période de 10 minutes. Il bloque l'accès au serveur par cette IP pendant 10 minutes. Ces valeurs sont configurables.
Ajoutez un fichier /etc/fail2ban/filter.d/dovecot-pop3imap.conf contenant :
[Definitio failregex = (?: pop3-login|imap-login): .*(?:Authentication failure|Aborted login \(auth failed|Aborted login \(tried to use disabled|Disconnected \(auth failed).*rip=(?P\S*),.* ignoreregex =
Ceci ajoute une expression régulière qui indique à fail2ban à quoi ressemble une ligne de log correspondant à une tentative d'attaque. La chaîne P comme valeur de rip (remote IP c'est à dire IP distante) contiendra l'adresse IP de l'attaquant, Fail2ban utilise cette variable pour créer la règle de bannissement de l'adresse IP.
Éditez ensuite le fichier /etc/fail2ban/jail.conf. Commencez par activer le filtre postfix qui est désactivé par défaut :
[postfix] enabled = true port = smtp,ssmtp filter = postfix logpath = /var/log/mail.log
Rajoutez ensuite une section pour le filtrage dovecot que l'on vient de créer ci-dessus :
[dovecot-pop3ima enabled = true port = pop3,pop3s,imap,imaps filter = dovecot-pop3imap logpath = /var/log/mail.log
NOTE DU TRADUCTEUR : Christoph Haas modifie directement le fichier jail.conf, mais je vous conseille de suivre les indications donnés par le mainteneur du paquet Debian qui conseille dans l'installation Debian de rajouter vos popres modifications dans un fichier /etc/fail2ban/jail.local. La raison en est que lors d'une mise à jour du paquet fail2ban vos modifications ne risqueront pas d'être écrasées par le configuration par défaut. Voici la mention qui figure en tête du fichier /etc/fail2ban/jail.conf :
# # This file was composed for Debian systems from the original one # provided now under /usr/share/doc/fail2ban/examples/jail.conf # for additional examples. # # To avoid merges during upgrades DO NOT MODIFY THIS FILE # and rather provide your changes in /etc/fail2ban/jail.local # # Author: Yaroslav O. Halchenko <debian@onerussian.com> # # $Revision: 281 $ #
Redémarrez fail2ban :
/etc/init.d/fail2ban restart
Maintenant vous pouvez attendre que les scripts kiddies tentent leur chance. Mais pour vérifier que tout fonctionne vous pouvez aussi simuler une attaque en envoyant manuellement des lignes dans vos logs.
logger -p mail.info -t dovecot "imap-login: Aborted login (auth failed, 2 attempts): user=, method=PLAIN, rip=10.20.30.40, lip=1.2.3.4, TLS"
Lancez cette commande trois fois coup sur coup pour déclencher le blocage par fail2ban. Si tout fonctionne comme cela devrait vous devriez lire dans votre fichier /var/log/fail2ban.log :
fail2ban.actions: WARNING [dovecot-pop3ima Ban 10.20.30.40
Maintenant les attaquants ne peuvent lancer plus de trois attaques toutes les dix minutes. C'est chouette non ?
