L’histoire

Depuis mes premières aventures en auto-hébergement (et des habitudes prises du temps ou je servais de relais de sortie pour TOR), j’essaie de faire attention à la sécurité de mon serveur, et ne pas laisser de service ouvert.

Un bloqueur d’intrusion (fail2ban) est installé sur la machine, et est configuré pour bloquer les utilisateurs qui tentent les mots de passes en série, le service ssh est paramétré pour ne pas autoriser les mots de passes, les mots de passe mail ne correspondent pas à ceux des comptes utilisateurs, bref, le système est fermé, protégé, et je n’ai jamais rencontré de problème de sécurité.

Partant de là, j’ai commencé à créer de nouveaux utilisateurs sur le serveur, principalement pour qu’ils puissent échanger des fichiers via sftp, il n’était pas prévu qu’ils utilisent d’autres services. Comme le mot de passe du compte utilisateur n’était pas censé servir (l’authentification par ssh n’est autorisée que par clef publique) je leur ai mis un mot de passe sans intérêt : l’utilisateur user a reçu le mot de passe très original user¹.

Le constat

L’année passée, en me connectant sur la machine, j’ai constaté une charge importante, bien plus que d’habitude. Une vérification m’a montré qu’il s’agissait de spamassassin, qui tournait à 100 % en continu. En consultant les logs, je me suis rendu compte que l’un des utilisateurs du serveur, connecté depuis une ip située à l’étranger était en train d’envoyer des dizaines de milliers de pourriels depuis le milieu de la nuit.

• Première réaction, couper le serveur de mail. Cela permet de couper l’émission, et de soulager la machine.
• Seconde réaction, bannir cette ip.
• Troisième réaction, analyser les logs et comprendre ce qui se passe.

Analyse

Avec le temps d’autres services se sont vu ajoutés sur le serveur, et le mot de passe système a été utilisé entre autre par postfix pour authentifier les utilisateurs au moment de l’émission d’un courriel. Comme le compte smtp s’est fait pirater, l’ensemble des mails émis ont été considéré comme émis par un utilisateur légitime et mon serveur les a relayé sans se poser de question à leurs destinataires.

Le mot de passe smtp étant différent de celui-du compte imap, aucune donnée n’a pu être récupérée, seul un grand trou béant a permis de transférer les courriels dans la nature…

L’ip a été bannie, donc aucun nouveau spam n’est émis. Il reste par contre la file des mails en cours d’emission à nettoyer. De plus certains mails sont déjà partis… Comme mon serveur mail est paramétré pour relayer ses courriels vers le service smtp de mon fournisseur, celui-ci a bloqué mes emissions comme il se doit. Par contre l’utilisateur dont le compte s’est fait piraté a reçu des mails d’erreurs indiquant la non-distribution des courriers et s’est vu saturé sa boîte aux lettres.

J’ai écrit un script pour purger les mails en attente, et ai laissé le script tourner pendant quelques heures pour vider la file.

Aujourd’hui

Fournir un service comme un compte courriel ne s’improvise pas, c’est une évidence. Pour autant, il n’est pas possible de débuter sans faire d’erreurs et la question est donc de prévenir ces erreurs et faire en sorte que l’impact soit le plus faible possible.

J’ai commencé par écrire une documentation complète du serveur, qui contient les différentes applications utilisées ainsi que leur configuration. Cela m’a permis de faire le point sur la sécurité de chaque point d’entrée, et modifier certains paramétrages qui n’avait été sécurisés.

J’ai écrit des tests automatisés dans le but de vérifier les règles de blocage des différents fichiers surveillés par fail2ban et prévenir les regressions en cas de mise à jour.

Je ne pense pas être à l’abri à nouveau d’une utilisation non voulue de mon serveur, mais je suis maintenant préparé à ce que cela arrive, et ne part pas avec un sentiment de fausse sécurité…