From d6eb187e0b4d6c558d9069c64c77699fd8b5043d Mon Sep 17 00:00:00 2001 From: Sébastien Dailly Date: Sun, 11 Aug 2013 19:17:28 +0200 Subject: New article on server hacking --- content/Perso/2014-05-12-hacking.rst | 117 +++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 content/Perso/2014-05-12-hacking.rst (limited to 'content/Perso/2014-05-12-hacking.rst') diff --git a/content/Perso/2014-05-12-hacking.rst b/content/Perso/2014-05-12-hacking.rst new file mode 100644 index 0000000..9689de9 --- /dev/null +++ b/content/Perso/2014-05-12-hacking.rst @@ -0,0 +1,117 @@ +.. -*- mode: rst -*- +.. -*- coding: utf-8 -*- + +================== +Faille de sécurité +================== + +:date: 2014-05-12 +:tags: Hébergement +:summary: Malgré mes tentatives de protéger mon serveur, je me suis fait + bêtement avoir ; mon serveur mail a tenté d'émettre 12 000 pourriels + par heure pendant une demi-journée… +:logo: images/hacking/hacking_75.jpg +:lang: fr + +.. figure:: {filename}/images/hacking/hacking_150.jpg + :figwidth: 150 + :figclass: floatright + :alt: Mail hacking + + Image : `Photogestion`_ (creativecommons_) + +.. _Photogestion: http://www.flickr.com/photos/photogestion/3541833890/ +.. _creativecommons: http://creativecommons.org/licenses/by-nc-nd/2.0/ + +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é. + +.. _fail2ban: /2008/09/une-gestion-avancee-de-fail2ban/ + +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é… + +.. admonition:: notes : + + .. [#] Il va sans dire qu'il s'agit d'une erreur que je ne referai plus. Si un + mot de passe ne doit pas être utilisé, le mieux est de ne pas en + assigner du tout ! + -- cgit v1.2.3