New article on server hacking

1 files changed, 117 insertions, 0 deletions

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 !
+