Protéger Prosody / Metronome avec fail2ban

You_shall_not_pass

Nous avons récemment installé ensemble le serveur XMPP Mêtronôme, fork de Prosody, afin de goûter aux joies des services de communication auto-hébergés.

Comme la sécurité et la confidentialité des données est un point très important en matière d’auto-hébergement, je vous propose aujourd’hui de paramétrer fail2ban pour qu’il bannisse automatiquement toute adresse IP ayant un comportement suspect sur votre serveur XMPP (entendez : poutrer tous les bots cherchant à se connecter à votre serveur).

Si vous connaissez un peu l’excellent fail2ban, vous n’êtes pas sans savoir que le fonctionnement de celui-ci repose sur la surveillance des logs d’un programme afin d’en définir des comportements suspects par rapport à une IP donnée. Or par souci de confidentialité, Mêtronôme (et Prosody), n’enregistrent pas ce genre d’information dans leurs logs, sauf s’ils sont en mode DEBUG. Voici un extrait de log classique :

Jul 22 11:52:05 c2s1ef97f0	info	Client connected
Jul 22 11:52:06 c2s1ef97f0	info	Authenticated as xxxxx@guillaume-leduc.fr
Jul 22 14:40:56 c2s1e77e30	info	Client connected
Jul 22 14:40:57 c2s1e77e30	info	Client disconnected: closed
Jul 22 14:41:44 c2s1e6a900	info	Client connected
Jul 22 14:41:45 c2s1e6a900	info	Client disconnected: closed

Difficilement exploitable… Heureusement pour nous, un module existe pour pallier à ce manque !

Enrichir les logs Mêtronôme

Installation du module mod_log_auth

Et ce module s’appelle sobrement « mod_log_auth ». Il est disponible sur le dépôt des modules non-officiels Prosody, hébergé par Google. La première étape consiste donc à récupérer le module :

sudo wget http://prosody-modules.googlecode.com/hg/mod_log_auth/mod_log_auth.lua -O /usr/local/lib/metronome/modules/mod_auth_log.lua

Configuration de Mêtronôme

L’activation du module se fait ensuite simplement en ajoutant la ligne suivante dans le fichier de configuration /usr/local/etc/metronome/metronome.cfg.lua :

modules_enabled = {
 
        -- Ici le reste de votre configuration
 
        "auth_log"      -- Logging d'IP en cas d'échec d'authentification
};

On enregistre, puis on redémarre le service :

sudo service metronome restart

Et si vous surveillez les logs et que vous tentez de vous connecter avec de mauvais identifiants, voici à quoi ressembleront les logs :

Jul 22 15:05:33 c2s218b690	info	Client connected
Jul 22 15:05:33 guillaume-leduc.fr:auth_log	info	Failed authentication attempt (not-authorized) from IP: XXX.XXX.XXX.XXX
Jul 22 15:05:33 c2s218b690	info	Client disconnected: closed

C’est déjà plus intéressant !

Configurer fail2ban

Vient ensuite la configuration de Fail2ban. Nous allons lui demander de surveiller les logs générés par Mêtronôme afin d’en détecter des comportements suspects. Je vous propose de créer le fichier /etc/fail2ban/filter.d/metronome-auth.conf :

# Fail2Ban configuration file for prosody authentication
[Definition]
failregex = Failed authentication attempt \(not-authorized\) from IP: <HOST>
ignoreregex =

Puis la déclaration du filtre, dans le fichier de configuration fail2ban (/etc/fail2ban/jail.local) :

[metronome-auth]
enabled  = true
port     = 5222
filter   = metronome-auth
logpath  = /var/log/metronome/*.log

Je vous laisse le soin de choisir maxretry, findtime ainsi que bantime

Histoire de faire les choses bien, nous pouvons tester notre nouvelle règle :

sudo fail2ban-regex /var/log/metronome/metronome.log /etc/fail2ban/filter.d/metronome-auth.conf 
 
Running tests
=============
 
Use   failregex file : /etc/fail2ban/filter.d/metronome-auth.conf
Use         log file : /var/log/metronome/metronome.log
 
 
Results
=======
 
Failregex: 1 total
|-  #) [# of hits] regular expression
|   1) [1] Failed authentication attempt \(not-authorized\) from IP: <HOST>
`-
 
Ignoreregex: 0 total
 
Date template hits:
|- [# of hits] date format
|  [35] MONTH Day Hour:Minute:Second
`-
 
Lines: 35 lines, 0 ignored, 1 matched, 34 missed
Missed line(s): too many to print.  Use --print-all-missed to print all 34 lines

Puis redémarrer fail2ban :

sudo service fail2ban restart

Avec ça, votre serveur est maintenant en mesure de se protéger d’attaque de type brute-force sur XMPP 🙂

Source de l’image : wallbase.cc

Cet article vous a plu ? Partagez-le sur les réseaux sociaux !

Twitter Facebook Google Plus email