Premiers pas avec Fail2ban

I. Présentation

Dans ce tutoriel, nous allons voir l'installation, le fonctionnement global et la configuration de l'outil Fail2ban qui est un outil de sécurité intéressant et reconnu. Fail2ban permet en effet de sécuriser les serveurs par l'automatisation de la détection de comportements suspects et leur blocage ou l'envoi d'alertes. Pour information, ce tutoriel s'effectue sur une machine Debian 7 sur une machine virtuelle VirtualBox.

II. Fail2ban

Fail2ban est donc un outil que l'on peut installer sur une machine UNIX, il va se charger de parser (lire, parcourir) les logs de différentes applications pour vérifier et détecter des comportements dis "suspects". Il va par exemple savoir détecter un nombre X de tentatives d'authentification infructueuses  sur une service FTP ou SSH ou détecter des requêtes anormales sur un services web tel qu'Apache2. Par défaut, l'outil est donc fournis avec un ensemble de règles que nous étudierons brièvement et que nous pouvons modifier à notre guise.

Le fonctionnement de Fail2ban se fait avec des prisons. Globalement, une prison est un ou plusieurs services ou ports sur lesquels vont s'appliquer des règles et dans laquelle  des IP ne respectant pas ces règles vont être mises. Une fois le comportement d'une IP détectée comme suspecte, une action est effectuée pour contrer cette IP. Par défaut il s'agit de bloquer l'IP en l'interdisant de communiquer avec le serveur pendant 600 secondes via des règles Iptables (pare-feu par défaut de beaucoup de distributions UNIX).

Comme déjà dit, par défaut, des règles sont déjà écrites et permettent de couvrir différents services comme :

• SSH

• Apache

• VSFtpd

• qmail

• courrier

• exim

• webmin

• ...

III. Installation

Nous allons maintenant nous pencher sur l'installation de Fail2ban, c'est relativement simple. Nous allons d'abord mettre à jour nos sources pour être sur d'avoir la dernière version de Fail2ban :

apt-get update

Puis nous allons l'installer depuis les sources :

apt-get install fail2ban

IV. Étude de la configuration et du fonctionnement

Maintenant que Fail2ban est installé, nous pouvons voir que sa configuration se situe dans "/etc/fail2ban" :

On voit donc bien deux fichiers de configurations : "fail2ban.conf" et "jail.conf" ainsi que deux dossiers "action.d" et "filter.d". Dans "fail2ban.conf" se situent quelques informations importantes, voici son contenu (sans les commentaires) :

[Definition]
loglevel = 3
logtarget = /var/log/fail2ban.log
socket = /var/run/fail2ban/fail2ban.sock

On a donc la définition du loglevel (niveau d'avertissement des journaux), le chemin vers le fichier de log où seront (entre autre) écrites les différentes alertes et le chemin vers le socket de fail2ban.

Un autre fichier, plus intéressant cette fois-ci est le "jail.conf". C'est dans ce fichier que seront définies les prisons qui sécuriserons votre serveur. Voici un exemple de ces prisons :

[ssh]
enabled  = true
port     = ssh
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 6

Nous avons donc son nom "[ssh], si elle est active ou non ("true" = activée), le port qui peut être abrégé par le nom du protocole (ssh, http, ftp).

Note: Si le port (par exemple SSH) n'est pas celui par défaut, il peut être précisé directement en étant précédé d'une virgule (ex: "port =ssh, http, 2569,...")

On trouve ensuite le nom du filtre à utiliser puis le chemin vers le fichier de log que Fail2ban doit parser (analyser) ainsi que le nombre de requêtes infructueuses à partir desquelles une IP sera bloquée. Cette dernière option nous oblige à nous demander comment une requête peut être détectée, mais aussi bloquée. C'est ce que nous allons voir maintenant.

Le dossier "/etc/fail2ban/filter.d" contient un ensemble de règles que Fail2ban va utiliser lors du parsing (de la lecture) des différents fichier de logs, voici quelques un des filtres en question :

On voit donc qu'un filtre doit avoir l'extension ".conf" et qu'il est sinon identifié par son nom (nous pointons vers le filtre "sshd" dans notre jail qui se réfère à "sshd.conf"). Voyons maintenant son contenu :

Nous voyons donc un ensemble de lignes que Fail2ban va simplement essayer de retrouver dans le fichier de logs indiqué (ici "/var/log/auth.log" où sont écrites les tentatives de connexion SSH) pour ensuite appliquer une action en cas de match (correspondance). On voit également la définition du nom du filtre :

[Definition]
_daemon = sshd

Ainsi que l'inclusion d'un précédent filtre (qui en l’occurrence comprend un ensemble de valeur par défaut pour les logs) :

[INCLUDES]
before = common.conf

Comme dit précédemment, une fois qu'un comportement anormal est détecté, une action va être menée afin de contrer ce comportement anormal ou au moins d'avertir l'administrateur. L'action par défaut est d'interdire à l'IP en question de communiquer avec le serveur via les règles Iptables. On peut voir l'ensemble des actions proposées dans le dossier "action.d" :

On peut enfin voir les prisons qui sont actuellement opérationnelles avec la commande suivante :

fail2ban-client status

Nous aurons alors un résultat comme suivant

On voit donc ici qu'une seule prison est active et que c'est la prison "ssh". Pour activer une autre prison, il faut s'assurer que celle si soit définie et mise en "true" puis de redémarrer Fail2ban avec la commande suivante :

fail2ban-client reload

 Dans le fichier "jail.conf" sont aussi indiquées des valeurs par défaut (s'appliquant à toutes les prisons si une valeur ne vient pas les remplacer). On trouve par exemple le temps de bannissement standard qui est de 600 secondes ("bantime  = 600"), le nombre de tentatives max par défaut ("maxretry=3"), le destinataire d'éventuels mail à envoyer ("destemail=root@localhost"), etc.

V. Test du filtre SSH

Nous allons maintenant tester un peut notre Fail2ban et plus précisément notre prison SSH en simulant une tentative infructueuse de connexion pouvant engendrer un blocage par notre Fail2ban. Selon ce qui a été décrit plus haut, il faudra donc que je tente 6 authentifications SSH incorrectes pour être bloqué. C'est parti !

Une fois les six authentifications faites, on peut aller dans le fichier de log du serveur pour constater les lignes suivantes :

Avec les logs en mode DEBUG, on voit la détection de l’événement dans le fichier de logs "/var/log/auth.log", il détecte un changement dans le fichier puis va voir de quoi il s'agit. Il détecte ensuite un échec de connexion depuis l'IP "192.168.1.18". Au bout de 6 tentatives, nous pourront voir ce message dans le fichier de log :

On voit donc que Fail2ban prend la décision de bannir l'IP  "192.168.1.18" en mettant à jour les règles Iptables du serveur, on verra d'ailleurs en vérifiant ces règles que notre poste client ("192.168.1.18") est effectivement bloqué :

iptables -L

On voit donc bien la "Chain fail2ban-ssh" qui contient un "DROP" pour les requêtes venant de "mark-VI.home" qui est le poste ayant l'IP 192 .168.1.18. On voit d'ailleurs que la prochaine tentative de connexion depuis ce poste sera bloquée et aura pour résultat "Timed-out" :

On peut ensuite vérifier directement par Fail2ban les IP bloquées avec la commande suivante (pour le SSH par exemple) :

fail2ban-client status ssh

Nous aurons alors le résultat suivant :

On voit donc bien que l'IP 192.168.1.18 est actuellement bloquée.  Pour remettre à neuf la prison, il suffit de la redémarrer

fail2ban-client reload ssh

Pour des informations supplémentaires, vous pouvez consultez directement le site de Fail2ban : http://www.fail2ban.org