7 files changed, 136 insertions, 17 deletions
diff --git a/content/Informatique/2008-09-15-fail2ban.rst b/content/Informatique/2008-09-15-fail2ban.rst
index cee3534..4a17ce3 100644
--- a/content/Informatique/2008-09-15-fail2ban.rst
+++ b/content/Informatique/2008-09-15-fail2ban.rst
@@ -48,7 +48,7 @@ Dans le fichier de configuration de fail2ban (/etc/fail2ban/jail.conf),
 nous allons demander la lecture de ce fichier en indiquant quelques
 paramètres supplémentaires :
 
-::
+.. code-block:: ini
 
     [apache-block]
     enabled = true #Oui on active
@@ -59,7 +59,7 @@ paramètres supplémentaires :
     maxretry = 1 #Nombre de tentatives
     banaction = iptables-redirect # L'action à appliquer sur l'IP
     bantime = 3600 # Le temps pendant lequel l'ip sera bannie.
-    
+
 
 Créer de nouvelles actions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -107,12 +107,12 @@ présentera comme suit :
     actionban =     echo +<ip> > /proc/net/xt_recent/fail2ban-<name>
 
     # On ne retire pas de l'unban, cela se fera tout seul une fois que l'attaquant aura terminé de se connecter
-    actionunban = 
+    actionunban =
 
 Il nous suffit de l'enregister dans le fichier `/etc/fail2ban/action.d/iptables-recent.conf`
 
 Si l'on veut bloquer une ip manuellement, il suffit d'éxécuter la dernière
-ligne, à savoir 
+ligne, à savoir
 
 .. code-block:: console
 
diff --git a/content/Informatique/2010-02-17-invisible.rst b/content/Informatique/2010-02-17-invisible.rst
index dcee14b..172194d 100644
--- a/content/Informatique/2010-02-17-invisible.rst
+++ b/content/Informatique/2010-02-17-invisible.rst
@@ -21,7 +21,7 @@ l'ensemble des participants au monde du libre.
     oublient le fait que plusieurs utilisateurs puissent être enregistrés sur
     le PC, et que tous ne soient pas forcément des administrateurs ( ceux qui
     peuvent avoir des droits root sur la machine). Pourquoi donc ?  Est-ce que
-    cela signifie que la plupart des linuxiens sont les seuls à utiliser le PC ? 
+    cela signifie que la plupart des linuxiens sont les seuls à utiliser le PC ?
     C'est possible, mais là n'est pas mon sujet. Je pense que le problème est
     que les utilisateurs sont pour l'instant invisible de la littérature sur
     Linux que l'on peut trouver sur le net. À la fois invisible du côté des
@@ -98,6 +98,9 @@ généralisation sur l'avenir de Linux et une remise en cause nécessaire. Je po
 juste ici un constat sur une situation qui est pour moi, encore trop souvent
 invisible.
 
+.. admonition:: notes :
 
-.. [1] `Artisan Numérique » Se prémunir des "SpyWebs" avec Privoxy <http://artisan.karma-lab.net/node/1204>`_ 
-.. [2] `http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557340 <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557340>`_
+
+    .. [1] `Artisan Numérique » Se prémunir des "SpyWebs" avec Privoxy <http://artisan.karma-lab.net/node/1204>`_
+
+    .. [2] `http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557340 <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=557340>`_
diff --git a/content/Informatique/2013-04-26-insecable.rst b/content/Informatique/2013-04-26-insecable.rst
index dd7734c..609e4d6 100644
--- a/content/Informatique/2013-04-26-insecable.rst
+++ b/content/Informatique/2013-04-26-insecable.rst
@@ -5,7 +5,7 @@ L'espace fine insécable en HTML
 ===============================
 
 :date: 2013-04-26
-:tags: Hébergement, Python, reStructuredText
+:tags: Python, reStructuredText
 
 La typographie est bien souvent malmenée dès que l'on utilise le web comme
 support. Pourtant, `les règles sont simples`_, et il est facile de les
@@ -42,7 +42,7 @@ Par contre, le plugin ne gère pas la langue française, dans le sens où il
 n'insère pas d'`espace fine insécable`_ quand c'est nécessaire :
 
 * après les signe de ponctuation double (« |nbsp| ; |nbsp| : |nbsp| ? |nbsp| !
-  |nbsp| ») 
+  |nbsp| »)
 * entre les guillemets et le texte qu'ils contiennent
 * séparateur de chiffre lors des numéros de téléphones…
 
@@ -58,7 +58,7 @@ police contient ce caractère dans sa table. Si ça n'est pas le cas, vous
 risquez d'avoir des problèmes d'affichage. À noter que les versions d'IE8 et
 les précedentes, qui ne gèrent pas correctement ce caractère, `sont encore
 utilisées`_ par 6 % des utiliseurs, encore quelque temps et le problème ne
-devrait plus se poser. 
+devrait plus se poser.
 
 .. _espace fine insécable: http://fr.wikipedia.org/wiki/Espace_fine_ins%C3%A9cable
 .. _NNBSP: http://www.fileformat.info/info/unicode/char/202f/index.htm
@@ -109,7 +109,7 @@ Le correctif
 ------------
 
 J'ai retenu la seconde solution, et ai créé une branche github_ pour cette
-version, que j'utilise actuellement pour le blog. 
+version, que j'utilise actuellement pour le blog.
 
 Tout d'abord, le texte n'est substitué qu'à l'intérieur d'une balise HTML, les
 attributs ne sont pas pris en compte, ça évite de casser l'affichage en allant
@@ -134,6 +134,6 @@ On n'arrive pas à la cheville d'un pdf généré avec latex — il ne s'agit qu
 d'un blog — mais ça permet d'avoir déjà amélioré la présentation de son texte,
 et de s'être un peu penché sur les problèmes de typographie…
 
-.. |nbsp| unicode:: 0xA0 
+.. |nbsp| unicode:: 0xA0
    :trim:
 
diff --git a/content/Informatique/2013-05-09-fcron2cron.rst b/content/Informatique/2013-05-09-fcron2cron.rst
index f48821a..87db268 100644
--- a/content/Informatique/2013-05-09-fcron2cron.rst
+++ b/content/Informatique/2013-05-09-fcron2cron.rst
@@ -102,7 +102,7 @@ L'édition
 Le programme ne fait pas l'insertion de la crontab dans le système, ainsi, dans
 le cas ou une telle crontab existe déjà, elle ne sera pas écrasée. C'est à
 l'adminstrateur de mettre le paramétrage à jour. Une fois le script lancé, des
-fichiers `UTILISATEUR.crontab` vont être générés. 
+fichiers `UTILISATEUR.crontab` vont être générés.
 
 Si l'utilisateur n'a pas de crontab correspondante, il est possible de le
 charger directement avec la commande suivante :
@@ -116,8 +116,7 @@ le faire correspondre. Maintenant qu'il ne reste plus que ça à faire, il est
 temps de se remonter les manches et y aller à la main ! Une fois que les
 modifications sont faites, vous pouvez désinstaller fcron de votre système.
 
-Notes
-=====
+.. admonition:: notes :
 
-.. [#] Y compris les options en début de commande (ligne débutant par `&`)
-.. [#] `nightly` est traité de la même manière
+    .. [#] Y compris les options en début de commande (ligne débutant par `&`)
+    .. [#] `nightly` est traité de la même manière
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 !
+
diff --git a/content/images/hacking/hacking_150.jpg b/content/images/hacking/hacking_150.jpg
new file mode 100644
index 0000000..07037cd
--- /dev/null
+++ b/content/images/hacking/hacking_150.jpg
diff --git a/content/images/hacking/hacking_75.jpg b/content/images/hacking/hacking_75.jpg
new file mode 100644
index 0000000..6ee9e90
--- /dev/null
+++ b/content/images/hacking/hacking_75.jpg