1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
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 !
|
