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 deparser (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
- 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 :
Puis nous allons l'installer depuis les sources :
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) :
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 :
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 queFail2ban 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 :
Quelques filtres par défaut fournis par Fail2ban
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 :
Composants d'un filtre Fail2ban
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 :
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) :
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” :
Exemple d'action Fail2ban
On peut enfin voir les prisons qui sont actuellement opérationnelles avec la commande suivante :
Nous aurons alors un résultat comme suivant
Voir le status de Fail2ban
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 :
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 SSHen 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 :
Logs mode DEBUG lors d’échec de connexions SSH
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 :
Action lancée pour bloquer l'IP suspecte
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é :
Règle Iptables par Fail2ban
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” :
Blocage d'une connexion SSH par Fail2ban
On peut ensuite vérifier directement par Fail2ban les IP bloquées avec la commande suivante (pour le SSH par exemple) :
Nous aurons alors le résultat suivant :
Liste des IP bloquées par Fail2ban
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
Pour des informations supplémentaires, vous pouvez consultez directement le site de Fail2ban : http://www.fail2ban.org
Aucun commentaire :
Enregistrer un commentaire