Portail / Linux(Sommaire)

Lutte contre les attaques de force brute : fail2ban.

Mise à jour du 21/12/2021.

La première partie de cet article est uen traduction des principaux paragraphes de la documentation.

Les tentatives d'effraction par force brute sont assez fréquentes contre un serveur SSH et d'autres services Internet protégés par mot de passe (tels que ftp, pop, etc.). Les scripts automatisés d'attaque essaient plusieurs combinaisons de nom d'utilisateur/mot de passe (force brute, attaque par dictionnaire). Une bonne pratique consiste à changer les numéros de port d'écoute de ces services mais cela n'est pas toujours possible. De plus, ces attaques accroissent la taille de vos fichiers journaux et leur nettoyage prend non seulement du temps, mais peut également être difficile.

Fail2ban tente d'atténuer ces problèmes en fournissant un moyen automatisé non seulement d'identifier les tentatives d'effraction possibles, mais aussi d'agir rapidement et facilement d'une manière paramétrable par l'utilisateur.

La plupart des services traces les interactions dans des fichiers journaux. Ces fichiers contiennent des informations intéressantes, en particulier sur les échecs de connexion. Ces informations peuvent être utilisées pour bannir un hôte malveillant. C'est exactement ce que fait Fail2ban. Il analyse les fichiers journaux et détecte les modèles qui correspondent à d'éventuelles tentatives d'effraction, puis effectue des actions. La plupart du temps, il s'agit d'ajouter une nouvelle règle dans une chaîne de pare-feu et d'envoyer une notification par courriel à l'administrateur système.

Installation

Fail2ban est entièrement écrit en Python et devrait donc fonctionner sur la plupart des systèmes *nix. La version de Python doit être supérieure ou égale à 2.4. Attention : Python 2.4 ne rouvre pas le socket syslog lorsqu'il rencontre un échec. Il s'agit d'un bogue Python. Si vous souhaitez utiliser logtarget = SYSLOG", veuillez utiliser une version plus récente de Python comme 2.5. Les logiciles suivants sont recommandés :

• iptables ;
• shorewall (paramétrage netfilter ; peut faire doublon à iptables) ;
• tcp-wrappers ;
• mailutils ;
• Gamin.

Sous Debian, l'installation se fait via la commande apt-get installer fail2ban

Utilisation.

Fail2ban est constitué de deux programmes : un serveur (fail2ban-server) et un client (fail2ban-client). 3 termes font partie du vocabulaire de cette documentation :

1. filter (filtre) : un filtre est définit une expression régulière qui doit correspondre à un motif correspondant à un échec de connexion ou à toute autre expression ;
2. action (action) : une action définit plusieurs commandes qui sont exécutées à des moments différents ;
3. jail (prison) : une prison est une combinaison d'un filtre et d'une ou plusieurs actions. Fail2ban peut gérer plusieurs prisons en même temps ;

Serveur.

Le serveur est multi-thread et écoute les commandes sur un socket Unix. Le serveur lui-même ne sait rien des fichiers de configuration. Ainsi, au démarrage, le serveur est dans un état "par défaut" dans lequel aucune prison n'est définie. Les options suivantes sont disponibles pour fail2ban-server :

-b démarrer en arrière-plan
-f commencer au premier plan
-s {FICHIER} chemin de socket
-x force l'exécution du serveur
-h, --help affiche ce message d'aide
-V, --version imprime la version

fail2ban-server ne doit pas être utilisé directement, sauf en cas de débogage. L'option -s {FICHIER}> est probablement la plus importante et est utilisée pour définir le chemin du socket. Ainsi, il est possible d'exécuter plusieurs instances de Fail2ban sur des sockets différents. Cependant, cela ne devrait pas être nécessaire car Fail2ban peut maintenir plusieurs prisons simultanément.

Si fail2ban-server plante, il est possible que le fichier socket n'ait pas été supprimé correctement. L'option -x indique au serveur de supprimer le fichier socket avant le démarrage. Si le fichier socket d'un serveur en cours d'exécution est supprimé, il n'est plus possible de communiquer avec ce serveur.

Le serveur gère les signaux SIGTERM et SIGINT. Lors de la réception de l'un de ces signaux, fail2ban-server se fermera correctement .

Client.

fail2ban-client est l'interface de Fail2ban. Il se connecte au fichier socket du serveur et envoie des commandes afin de configurer et d'exploiter le serveur. Le client peut lire les fichiers de configuration ou peut simplement être utilisé pour envoyer une seule commande au serveur en utilisant soit la ligne de commande, soit le mode interactif (qui s'active avec l' option -i). fail2ban-client peut également démarrer le serveur. Les options suivantes sont disponibles pour fail2ban-client :

-c {REPERTOIRE} répertoire de configuration
-s {FICHIER} chemin de socket
-d vidage de la configuration (pour le débogage)
-i mode interactif
-v augmente la verbosité
-q diminue la verbosité
-x force l'exécution du serveur
-h, --help affiche ce message d'aide
-V, --version imprime la version

Comme pour fail2ban-server, l'option -s {FICHIER}> peut être utilisée pour définir le chemin du socket. Notez que cette option de ligne de commande remplace l'option socket définie dans fail2ban.conf. Le répertoire de configuration par défaut est /etc/fail2ban mais peut être remplacé avec l'option -c {REPERTOIRE}>. L' option -x est simplement transmise à fail2ban-server lors du démarrage du serveur.

Une option utile pour le débogage est -d. Cela affiche la configuration analysée par fail2ban-client. La sortie correspond au flux envoyé au serveur. Si la sortie de -d affiche :

['set', 'loglevel', 1]
['set', 'logtarget', 'STDERR']

Il est possible d'obtenir la même chose avec :

$ fail2ban-client set loglevel 1
$ fail2ban-client set logtarget STDERR

Tout ce qui est défini dans les fichiers de configuration peut être configuré manuellement. La configuration n'est qu'un moyen simple et efficace de configurer le serveur. fail2ban-client traduit uniquement la configuration en une suite de commandes. Cependant, fail2ban-client dispose de 2 commandes supplémentaires pour son usage interne. La première est le démarrage. Lors de la saisie :

$ fail2ban-client start

le client essaiera d'abord de dupliquer (fork) une instance de serveur. Le client attend alors le démarrage du serveur en lui envoyant des requêtes ping. Une fois que le serveur a répondu à ces requêtes, fail2ban-client analyse la configuration et envoie les commandes correspondantes au serveur. La seconde est le rechargement. Lors de la saisie :

$ fail2ban-client reload

le client dira au serveur d'arrêter toutes les prisons, analysera à nouveau les fichiers de configuration et enverra les commandes au serveur. Ceci est utile lorsqu'une nouvelle configuration doit être chargée sans arrêter le serveur. Ceci est également très utile lors du débogage du serveur. Il est possible de démarrer le serveur avec fail2ban-server -f dans un terminal et de charger la configuration en tapant fail2ban-client reload dans un autre. Ainsi, les sorties client et serveur ne seront pas mélangées.

Toutes les autres commandes sont simplement envoyées au serveur sans aucun traitement spécifique. Cependant, la plupart du temps, seules les 2 commandes ci-dessus et stop seront utilisées.

Il y a probablement une dernière commande utile : status [jail]. Sans nom de prison, l'état global du serveur est renvoyé. Si la prison correspond à une prison existante, le statut de cette prison est affiché. Voici la liste exhaustive des commandes.

Configuration.

Chaque fichier .conf peut être remplacé par un fichier nommé .local. Le fichier .conf est lu en premier, puis .local, les paramètres ultérieurs remplaçant les précédents. Ainsi, un fichier .local n'a pas à tout inclure dans le fichier .conf correspondant, seulement les paramètres que vous souhaitez remplacer.

Il est possible d'utiliser des variables symboliques comme %(sshd_log)s (ficher de log SSH par défaut) ou %(sshd_backend)s (moteur de surveillance des logs). Ces variables sont définies dans d'autres fichiers de configuration : paths_common.conf et paths_debian.conf notamment.

Les modifications doivent avoir lieu dans le .local et non dans le .conf. Cela évite les problèmes de fusion lors de la mise à niveau. Ces fichiers sont bien documentés et des informations détaillées devraient y être disponibles.

Le fichier fail2ban.conf contient les paramètres généraux du démon fail2ban-server, tels que le niveau de journalisation et la cible. Vous pouvez également spécifier ici le chemin de socket utilisé pour la communication entre le client et le serveur.

Les prisons.

Le fichier le plus important est probablement jail.conf, qui contient la déclaration de vos prisons. Par défaut, certaines sections sont insérées en tant que modèles. Vous devez activer les sections qui vous intéressent et vous adapter à votre configuration locale. Voici un exemple de la section ssh-iptables :

[ssh-iptables]
#enabled  = false
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
#          mail-whois[name=SSH, dest=yourmail@mail.com]
#logpath  = /var/log/sshd.log
logpath  = /var/log/auth.log
maxretry = 5

Avec l'activation de cette prison, c'est le filtre ssd.conf sous filter.d qui sera exécuté.

Filtre et actions sont combinés pour créer des prisons. Un seul filtre est autorisé par prison, mais il est possible de spécifier plusieurs actions, sur des lignes distinctes. Par exemple, vous pouvez réagir à une tentative d'effraction SSH en ajoutant d'abord une nouvelle règle de pare-feu, puis en récupérant des informations sur l'hôte incriminé à l'aide de whois et enfin en envoyant une notification par courriel. Peut-être souhaitez-vous simplement recevoir une notification sur votre compte Jabber lorsque quelqu'un accède à la page /donotaccess.html sur votre serveur Web.

Fail2ban n'est pas limité à SSH. Il contient des filtres et des actions par défaut pour de nombreux démons et services. Vous pouvez facilement les modifier ou en créer de nouveaux. Si vous jetez un oeil dans le filter.d, vous remarquerez quelques filtres par défaut qui ne sont pas traités dans le jail.conf standard fourni avec les sources. Dans cet exemple, nous prenons l'exemple de la prison sshd-ddos.conf. Pour intégrer son filtre dans Fail2ban ajoutez à votre jail.conf :

[ssh-ddos]
    
enabled = true
port = ssh,sftp
filter = sshd-ddos
logpath = /var/log/messages
maxretry = 2

N'oubliez jamais d'ajuster $logpath à votre fichier journal comme mentionné ci-dessus.

Options des prisons.

[DEFAULT]
ignoreip = 127.0.0.1 124.32.5.48
findtime = 10m
bantime = 24h
maxretry = 3
destemail = adresse@example.com

Les filtres.

Le répertoire filter.d contient principalement des expressions régulières qui sont utilisées pour détecter les tentatives d'effraction, les échecs de mot de passe, etc. Voici un exemple pour filter.d/sshd.conf avec 3 expressions régulières possibles pour correspondre aux lignes du fichier journal :

failregex = Authentication failure for .* from <HOST>
            Failed [-/\w]+ for .* from <HOST>
            ROOT LOGIN REFUSED .* FROM <HOST>
            [iI](?:llegal|nvalid) user .* from <HOST>

Dans l'exemple ci-dessus, l'expression régulière par défaut a été modifiée pour permettre l'absence d' utilisateur dans une ligne telle que :

Jan 10 07:02:37 homebrou sshd[18419]: Failed password for root from 222.76.213.151 port 55236 ssh2

Si vous créez vos propres expressions failregex, voici certaines choses que vous devez savoir :

• Un failregex peut avoir plusieurs lignes, chacune pouvant correspondre à une ligne du fichier journal.
• Dans chaque ligne de failregex, la partie qui correspond au nom d'hôte ou à l'adresse IP doit être enveloppée dans un sandwich (?P<host> ... ). Il s'agit d'une extension regex spécifique à Python qui attribue le contenu de la correspondance au nom <hôte>. La balise <host> est la façon dont vous indiquez à fail2ban quel hôte se connectait, elle doit donc être présente dans chaque ligne de failregex. Si ce n'est pas le cas, fail2ban émettra un message d'erreur sur "Pas de groupe 'hôte'".
• Pour plus de commodité, vous pouvez utiliser l'entité prédéfinie <HOST>dans vos expressions régulières. <HOST> est un alias pour (?:::f{4,6}:)?(?P<host>\S+), qui correspond soit à un nom d'hôte, soit à une adresse IPv4 (éventuellement intégrée dans une adresse IPv6).
• Dans les scripts d'action, la balise <ip> sera remplacée par l'adresse IP de l'hôte qui a été mise en correspondance dans la <host> balise.
• Pour qu'une ligne de journal corresponde à votre failregex, elle doit en fait correspondre en deux parties : le début de la ligne doit correspondre à un modèle d'horodatage ou à une regex et le reste de la ligne doit correspondre à votre failregex. Si le failregex est ancré avec un premier ^, alors l'ancre fait référence au début du reste de la ligne, après l'horodatage et l'espace blanc intermédiaire.
• Le modèle ou l'expression régulière correspondant à l'horodatage n'est actuellement pas documenté et n'est pas disponible pour les utilisateurs à lire ou à définir. Voir bogue Debian #491253. C'est un problème si votre journal a un format d'horodatage auquel fail2ban ne s'attend pas, car il ne correspondra alors à aucune ligne. Pour cette raison, vous devez tester tout nouveau failregex par rapport à un exemple de ligne de journal, comme dans les exemples ci-dessous, pour être sûr qu'il correspondra. Si fail2ban ne reconnaît pas l'horodatage de votre journal, vous avez alors deux options : soit reconfigurer votre démon pour qu'il se connecte avec un horodatage dans un format plus courant, comme dans l'exemple de ligne de journal ci-dessus ; ou déposez un rapport de bogue demandant d'inclure votre format d'horodatage.

Si vous avez créé vos propres filtres, modifié des filtres existants, ou si vous voulez simplement tester un filtre sur un fichier de log particulier, l'outil fail2ban-regex est fait pour cela.

À titre d'exemple sur les problèmes d'horodatage ci-dessus, exécutez les commandes suivantes dans votre console et comparez les résultats :

fail2ban-regex 'Jul 18 12:13:01 [1.2.3.4] authentication failed'     'authentication failed'
fail2ban-regex 'Jul 18 12:13:01 [1.2.3.4] authentication failed'     '\[<HOST>\] authentication failed'
fail2ban-regex '18-07-2008 12:13:01 [1.2.3.4] authentication failed' '\[<HOST>\] authentication failed'
fail2ban-regex '18-7-2008 12:13:01 [1.2.3.4] authentication failed'  '\[<HOST>\] authentication failed'

La 1ère commande échoue, avec un message d'erreur "Pas de groupe 'hôte'". La 2ème commande réussit et trouve l'adresse hôte 1.2.3.4. La 3ème commande réussit et trouve l'adresse hôte 1.2.3.4 (au moins avec la v0.8.4). La 4ème commande échoue. Il vous dit pourquoi --- il dit "... aucune date/heure valide trouvée pour..." --- et il est clair qu'il n'est pas en mesure de correspondre au format d'horodatage inhabituel --- qui ne fait pas partie de votre failregex.

Les actions.

Le répertoire action.d contient différents scripts définissant des actions. Les actions sont exécutées à des moments bien définis lors de l'exécution de Fail2ban : lors du démarrage/arrêt d'une prison, bannissement/dé-bannissement d'un hôte, etc.

Les actions exécutées par Fail2ban lorsqu'une correspondance est trouvée entre un filtre et une entrée de log sont définies par la directive action. Pour plus d'information consultez la partie ACTIONS du fichier /etc/fail2ban/jail.conf. L'action par défaut est un simple bannissement par ajout d'une règle iptables.

Les actions peuvent être définis globalement dans la section [DEFAULT] ou par jails dans leur propre section. La valeur par défaut est root@localhost dans la section [DEFAULT] de etc/fail2ban/jail.conf/ et concerne donc toutes les prisons. Il reste cependant possible de spécifier un destemail particulier dans une prison donnée.

Il est possible de recevoir un courriel après chaque bannissement d'une adresse IP. Pour cela vous pouvez définir globalement l'adresse du destinataire dans la section [DEFAULT] du fichier /etc/fail2ban/jail.d/custom.conf. Il faut que le système soit correctement configuré pour l'envoi de courriels. Pour activer l'envoi de courriels, ajoutez la ligne dans la section [DEFAULT] du fichier /etc/fail2ban/jail.d/custom.conf :

action = %(action_mw)s

ou (pour envoyer un mail avec le whois ainsi que les logs)  :

action = %(action_mwl)s

Pensez à redémarrer fail2ban pour que cette modification soit prise en compte.

Temps de réaction.

Tout d'abord, rappelez-vous que Fail2ban est un analyseur de journaux. Il ne peut rien faire avant que quelque chose ne soit écrit dans les fichiers journaux. Beaucoup de démons syslog mettent leurs sorties en mémoire tampon. Cela peut avoir un impact sur les performances de Fail2ban. Ainsi, il pourrait être bon de désactiver la mise en mémoire tampon de votre démon syslog.

Il est assez difficile d'évaluer le temps de réaction. Fail2ban attend 1 seconde avant de vérifier les nouveaux journaux à analyser. Cela devrait être bien dans la plupart des cas. Cependant, il est possible d'obtenir plus d'échecs de connexion que spécifié par maxretry .

Commandes utiles.