Installer et paramétrer Fail2Ban

Fail2Ban, en deux mots, c’est un petit utilitaire qui permet de configurer le parefeu iptables de Linux à la volée. Vous lui donnez une liste de règles, lesquelles lui permettent de détecter si quelqu’un tente de bruteforcer votre SSH, de vous faire un DoS sur Apache etc, et à la volée, Fail2Ban prend les mesures qui s’imposent pour vous prémunir de ces attaques. Plutôt pratique !

Installation

Pour l’installer, c’est très simple :

apt install fail2ban

Passons maintenant au plus important, la configuration de l’engin ! Il y a trois endroits où vous allez devoir fouiller.

Les réglages

Le fichier de configuration global /etc/fail2ban/fail2ban.conf ne contient pas grand chose à modifier. Vous pourrez paramétrer l’endroit où fail2ban doit enregistrer ses logs, la verbosité de ces derniers et modifier les réglages du socket unix. En ce qui me concerne, je ne touche à rien.

/etc/fail2ban/jail.conf contient les jails par défaut. Comme il est indiqué en haut du fichier, ce dernier n’est pas à modifier directement. On activera les jails dans /etc/fail2ban/jail.d/defaults-debian.conf (ça c’est sur Debian & Ubuntu), le nom du fichier est certainement différent sur d’autres distribs mais vous avez le chemin du répertoire. Vous devriez donc vous y retrouver sans problème.

Dans sa configuration la plus simple, on se contente d’activer les jails proposées par défaut. Voici par exemple une configuration minimaliste mais fonctionnelle.

# /etc/fail2ban/jail.d/defaults-debian.conf
[DEFAULT]
destemail = mon-email@mail.fr
sender = root@domaine.fr

[sshd]
enabled = true

[sshd-ddos]
enabled = true

[recidive]
enabled = true

On peut néanmoins y ajouer encore quelques détails. De plus sachez que pour chaque jail ainsi que pour [DEFAULT], vous pouvez préciser ignoreip, qui permet, comme son nom l’indique, de ne pas considérer certaines ip ou blocs d’ip. Pratique pour ne pas se retrouver à la porte de son propre serveur.

# mettez ici votre adresse ip histoire de ne pas vous blacklister tout seul
# il est possible de mettre plusieurs adresses, il suffit pour cela de les séparer par un espace
[DEFAULT]
destemail = mon-email@mail.fr
sender = root@domaine.fr
ignoreip = 127.0.0.1/8
 
[sshd]
enabled = true

# si on possède un serveur apache
[apache]
enabled = true

Vous voyez par exemple que j’ai ici aussi ajouté apache. Si vous avez un serveur Apache, cela peut s’avérer utile. Pensez bien à parcourir le jail.conf ainsi que les filtres prédéfinis dans filter.d afin de voir ce qui existe par défaut et activez ou non des jails selon vos besoins.

Ce n’est pas tout, d’autres otpions courantes sont à connaître :

  • port permet de préciser les ports à bloquer
  • logpath indique le fichier de log à analyser
  • maxretry le nombre d’occurences dans le fichier de log avant que l’action ne soit déclenchés
  • findtime permet de spécifier le laps de temps pendant lequel on considère les occurences (au dela de findtime, on repart à zéro)
  • bantime définit le temps que l’ip restera bloquée via fail2ban
# on reprend notre exemple précédent pour illustrer ces options
[…]

# 10 requêtes en 2 min -> Ban pour 20 minutes
[sshd]
enabled = true
maxretry = 10
findtime = 120
bantime = 1200

Si vous parcourez /etc/fail2ban/jail.conf, vous pourrez voir les autres options qui s’appliquent par défaut si vous ne les redéfinissez pas.

Ajout de nouveaux filtres

Ce qui est génial avec fail2ban, c’est qu’il est possible d’ajouter autant de jails que l’on veut. Si vous savez utiliser les REGEX, vous savez écrire une jail !

Nous commencer par créer un filtre afin de détecter les tentatives de connexion infructueuses. Dans un tel cas, notre applicatif devrait renvoyer une erreur 401. Voici un exemple de log que nous allons matcher :

80.214.431.42 - - [14/Oct/2018:21:27:32 +0200] "POST /users/login HTTP/2.0" 401 30 "https://app.buzeo.me/" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:63.0) Gecko/20100101 Firefox/63.0" "-"

Voici à quoi ressemble notre filtre (/etc/fail2ban/filter.d/nginx-unauthorized).

# Fail2Ban filter for WordPress
#

[Definition]
failregex =  - - \[.*\] ".*" 401
ignoreregex = 

C’est aussi simple que ça ! <HOST>, vous l’aurez deviné, permet à fail2ban de matcher une ip ou un nom d’hôte et de capturer cette adresse afin de la bloquer dans iptables. Le reste est assez classique. La failregex peut contenir plusieurs lignes, dans ce cas, chacune sera matchée de manière indépendante. Quant à l’ignoreregex son nom est assez explicite et elle permet de ne pas tenir compte d’un pattern donné.

Modifions maintenant notre configuration dans /etc/fail2ban/jail.d/defaults-debian.conf pour activer notre nouveau filtre.

[…]

# on bloque l'utilisateur pour 5mn après 5 tentatives en 2mn
[nginx-unauthorized]
enabled = true
# si le filtre possède la même nom que la règle, il n'est pas nécessaire de le renseigner
filter = nginx-unauthorized
port = 80,443 # tous les ports par défaut
logpath = /var/log/nginx/access.log
maxretry = 5
findtime = 120
bantime = 300

fail2ban cli

Fail2ban possède plusieurs clients fort pratiques. fail2ban-regex permet de valider vos filtres. Voici comment l’utiliser.

fail2ban-regex <fichier-de-log | string-représentant-une-ligne-de-log> <chemin-du-filtre | string-regex> [<chemin-du-filtre | string-ignoregex]

fail2ban-regex /var/log/nginx/access.log /etc/fail2ban/filter.d/nginx-unauthorized.conf

Ce n’est pas un bug, si vous voulez tester une ignoreregex depuis un fichier de filtre, il faut renseigner le chemin deux fois.

En outre, fail2ban nous propose fail2ban-client. Ce dernier outil permet de vérifier l’état de fail2ban comme les jails activées, le nombres d’ip bloquées etc. Voyons les fonctions les plus utiles.

# info générale sur fail2ban et les jails
fail2ban-client status
Status
|- Number of jail:	4
`- Jail list:		ssh-ddos, nginx-errors, recidive, ssh

# plus d'infos sur une jail en particulier
fail2ban-client status ssh
Status for the jail: ssh
|- filter
|  |- File list:	/var/log/auth.log 
|  |- Currently failed:	0
|  `- Total failed:	4499
`- action
   |- Currently banned:	6
   |  `- IP list:	
   `- Total banned:	274

# il est également possible de débanir une ip
fail2ban-client set ssh unbanip 192.168.0.12

# ou d'en bannir une 
fail2ban-client set ssh banip 192.168.0.12

Nous avons ici exploré les usages les plus courants de fail2ban. Vous êtes maintenant aptes à créer vos propres rèles afin d’adapter le comportement du logiciel pour la plupart de vos besoins. Sachez cependant que fail2ban a encore d’autres tours dans son sac. En cas de match, il peut accomplir n’importe quel comportement (envoyer un email, rediriger vers une autre ip…). Pour en savoir plus je vous invite à lire la partie concernant les actions de cet article et celui-ci en anglais.

Déjà 9 réponses, rejoignez la discussion !

  • MagiCrazy

    dit :

    Très très bon tuto, encore ^^
    A savoir, j’ai déjà vu d’autres attaques w00tw00t avec des variantes sur le « SANS\.DFind », donc j’ai préféré filtrer sur w00tw00t tout simplement, même si c’est un peu violent…

    Suivant les besoins, il est possible d’ajouter une règle fail2ban sur les logs fail2ban d’ailleurs :
    Dans le cas où tu filtres les BF ssh par exemple, et que tu ban l’IP pendant 1h disons, bah si tu trouves plusieurs bans de la même IP sur une journée, tu peux mettre un ban de 7 jours, ou infini…

    Personnellement, j’ai remis le nez dans fail2ban récemment, pour qmail (un serveur/relai de mails), mais les logs de qmail ne sont pas assez fournis pour être utilisés correctement, c’est très chiant…

    • Buzut

      dit :

      Ça fait plaisir que tu apprécies !

      en effet pour w00tW00t :
      [Wed Nov 21 12:30:08 2012] [error] [client 50.63.56.58] client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23): /w00tw00t.at.ISC.SANS.test0:)

      Bon, tant pis pour la violence, je vais faire comme toi.

      failregex = ^ -.* »GET \/w00tw00t.* ».*

      ça ça devrait convenir non ?

      En effet j’avais pas pensé à parser les logs fail2ban. Enfin je ne pense pas en avoir l’utilité, puisque le password login est désactivé, ils peuvent BF longtemps :)

      Après niveau sécu, je me pose la question de l’utilité de tous les outils styles rkhunter, unhide, les tripwire, ossec & co. Est-ce que c’est vraiment la peine ou est-ce que c’est plus emmerdant à générer des faux positifs toutes les 3 secondes… T’as une opinion sur le sujet ? :)

      • MagiCrazy

        dit :

        C’est violent certes, mais après faut faire attention à ne jamais avoir w00tw00t dans tes titres/entêtes d’articles de blogs quoi ^^

        pour les outils de sécu, je connais pas tout ce que tu cites, mais pour moi, la sécurité est une question de dosage… ça ne sert à rien de surprotéger un serveur qui gère 5 sites web… On n’est pas le pentagone non plus ^^

        • Buzut

          dit :

          C’est sur que ça ne sert à rien de trop en faire. Mais mieux vaut être un peu parano qu’un peu trop laxiste.

          Après c’est certain qu’avec un firewall bien réglé, des softs avec les dernières MAJ et en gardant un œil sur les logs (logwatch ?), on est quand même déjà bien à l’abri ;)

  • Nicolas Richard

    dit :

    Merci beaucoup pour ce petit tuto bien détaillé et très propre x)
    Il en faudrait plus ds gens comme toi en France ;)
    Par contre malgré mes efforts, après avoir suivi ton tuto à la lettre, je n’arrive pas à arrêter mon script python tout bête :

    from socket import *

    for i in range(100000):
    print(i)
    socket().connect((‘IP’, 80))

    Pourquoi ?

  • Ariden

    dit :

    Hello,

    Merci pour ce tuto, clair et simple.

    1. Sur la page suivante http://buzut.fr/2013/01/29/anti-hotlinking-pour-video-avec-nginx/#comment-1909 tu fais un tuto pour nginx,

    cependant, dans ce tuto, tu ne donnes pas toutes les équivalences des scripts apache pour nginx, c’est dommage.

    Ex: Se protéger des DDoS de Loic (spécial Apache)

    2. Dans la rubrique « Ajout de nouveaux filtres »

    # si vous utilisez nginx, il faut mettre le fichier de log adéquat
    logpath = /var/log/varnish/access.log

    > tu parles de Varnish là, et pas nginx

    • Buzut

      dit :

      Tout à fait, j’ai fait une erreur. Mais les logs de nginx sont bien à /var/log/nginx/access.log (je corrige ça tout de suite) !

      Donc pour le ddos et w00tw00t, les filtres apache fonctionnent avec nginx, il suffit donc de substituer l’adresse du fichier de logs.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *