Sécuriser l’accès à son serveur avec Fail2Ban

Toutes machines exposées à Internet sont sujettes à des tentatives d’intrusion.
Ces tentatives de connexion frauduleuses sont enregistrés dans les logs systèmes. A l’aide de ces derniers, le service Fail2Ban peut adresser ce problème en bloquant les tentatives d’accès illicites.
Le serveur pourra répondre de manière appropriée aux tentatives reppétées d’accès sans aucune intervention humaine.

Comment fonctionne Fail2Ban?

Fail2Ban permet d’analyser les fichiers de log et de déclencher les actions adéquates en fonction de ce qui est détecté.
Grâce à sa modularité, aussi bien au niveau des mécanismes de détection que sur les actions à mener, Fail2Ban peut mettre en œuvre des actions de mise en quarantaine qu’il est possible de définir, d’activer ou de désactiver à l’aide d’un simple fichier (/etc/fail2ban/jail.conf).
Une mise en « quarantaine » repose sur les éléments suivants :

  • Le nom du fichier de log à analyser.
  • Le filtre à appliquer sur le fichier de log.
  • Les paramètres permettant de définir une action.
  • L’action à mener.

Installation de fail2ban

L’installation de Fail2Ban est relativement simple à réaliser via la commande suivante :

sudo apt-get install fail2ban
Fail2ban peut ne pas être disponible dans les dépots, par contre, il est possible de télécharger le dépot EPEL :
sudo rpm -Uvh http://dl.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-8.noarche.rpm
Puis lancer l’installation de fail2ban :
sudo yum install fail2ban

Les fichiers de configuration de Fail2Ban

Maintenant que Fail2Ban est installé, on peut consulter les fichiers de configuration, fail2ban.conf et jail.conf, dans le dossier /etc/fail2ban.

Le fichier « fail2ban.conf », se présente ainsi (certaines déclarations pouront varier en fonction de l’OS) :

  • loglevel : Niveau d’avertissement des log (valeur par défaut : 3 – sur une echelle de 1 à 4)
  • logtarget : Chemin vers le fichier de log cible (chemin par défaut : /var/log/fail2ban.log sur Ubuntu et SYSLOG sur CentOS)
  • socket : Chemin vers le socket de fail2ban (chemin par défaut : /var/run/fail2ban/fail2ban.sock)
  • pidfile : Chemin vers le pidfile (le Process ID) du serveur Fail2Ban (chemin par défaut : /var/run/fail2ban/fail2ban.pid)

Les valeurs ci-dessus sont modifiables afin que Fail2Ban soit plus verbeux, mais cela peut intraîner un impact négatif sur les performances d’un environnement de production. Dans ce contexte, il est préférable de laisser les valeurs par défaut.

Dans le fichier « jail.conf », qui définit les « quarantaines » sécurisant le serveur, nous pouvons observer ce qui suit :

  • enabled : Activée ou non (true / false).
  • port : Le port peut être abregé par le nom du protocole. Si le port n’est pas celui par défaut, il doit être précisé explicitement.
  • filter : Le filtre à appliquer (en rapport avec le contenu du dossier /etc/fail2ban/filter.d).
  • logpath : Le chemin vers le fichier de log à analyser.
  • maxretry : Le nombre de tentatives avant exécution de l’action.
  • bantime : La durée du bannissement de l’adresse IP, ici exprimée en secondes. Dans le cas d’un bannissement définitif, il faudra indiquer « -1 ».
  • ignoreip : Liste des adresses IP de confiance à ignorer par Fail2ban (paramètre optionnel)
  • destmail : Adresse e-mail destinataire des notifications (paramètre optionnel)
  • action : Action à entreprendre en cas de détection possible

Ce qui vient d’être passé en revenue n’est qu’un exemple, mais ce même fichier contient aussi d’autres sections de « quarantaines » que l’on peut activer ou désactiver (en modifiant la valeur de « enabled ») en fonction des services présent sur le serveur : Apache, Postfix, Sasl, etc…

De son côté, le dossier « /etc/fail2ban/filter.d » contient un ensemble de règles que Fail2ban va utiliser lors de la lecture des différents fichiers de logs.

3proxy.conf
exim.conf
perdition.conf
vsftd.conf
apache-auth.conf
exim-spam.conf
php-url.conf
webmin-auth.conf
apache-noscript.conf
freeswitch.conf
postfix.conf
wuftpd.conf
apache-common.conf
groupoffice.conf
postfix-sasl.conf
xinetd-fail.conf
apache-nohome.conf
gssftpd.conf
proftd.conf
apache-overflows.conf
horde.conf
pure-ftpd.conf
assp.conf
lighttpd.conf
qmail.conf
asterisk.conf
mysqld.conf
recidive.conf
common.conf
nagios.conf
roundcube.conf
courrierlogin.conf
named-refused.conf
sasl.conf
couriersmtp.conf
nginx-htp-auth.conf
sieve.conf
cyrusimap.conf
nsd.conf
sogo-auth.conf
dropbear.conf
openwebmail.conf
sshd.conf
exim-common.conf
pam-generix.conf
ssh-ddos.conf

Les fichiers listés ci-dessus contiennent les définitions des actions à mener en cas de correspondances entre les motifs de recherche (fournis par jail.conf) et les fichiers de logs analysés.

Une fois qu’un comportement anormal est détecté, l’action adéquate sera enclenchée afin de le contrer ou, éventuellement, d’avertir l’administrateur. L’action par défaut est d’utiliser Iptables afin d’ajouter une règle de pare-feu interdisant momentanément (ou défintivement) la communication depuis la machine distante malveillante détectée.
Les actions proposées sont listées dans le dossier « /etc/fail2ban/actions.d »

  • bsd-ipfw.conf : Utilise Packet Filter au lieu d’iptables sur les distributions BSD.
  • complain.conf : Envoie un message d’avertissement à l’utilisateur/administrateur de la machine distante
  • dshield.conf : Reporting d’attaques subies à www.dshield.org
  • dummy.conf : Ne fait rien, pour test
  • hostsdeny.conf : Utilise host.denypour faire du ban/unban
  • ipfilter.conf : Utilise ipfilter au lieu d’iptables
  • ipfw.conf : Utilise ipfw au lieu d’iptables
  • iptables.conf : Crée les règles pare-feu via iptables.
  • mail.conf : Permet d’envoyer un message électronique à l’administrateur du serveur. Nécessite un serveur mail installé et actif.
  • mynetwatchman.conf : Reporting d’attaques vers www.mynetwatchman.com
  • pf.conf : Utilise Packet Filter au lieu d’iptables
  • route.conf : Utilise la table de routage et non iptables pour bloquer la communication vers la machine distante.
  • sendmail.conf : Permet d’envoyer un message électronique à l’administrateur du serveur cible. sendmail-whois et sendmail-whois-lines donnent plus d’information sur l’auteur de l’attaque. sendmail-buffered ouvre la « quarantaine » dès le début de l’attaque mais ne met en quarantaine qu’au bout d’un nombre de tentative prédéfini. Nécessite un serveur mail installé et actif.
  • shorewall.conf : Création de règles pour shorewall via fail2ban
  • apf.conf : « Advanced Policy Firewall » : Peut être utilisé à la place de l’action « iptables »
  • badips.conf : Ne peut être utilisé seul car ne banni pas le traffic, il ne sert qu’au reporting
  • blocklist_de.conf : Reporting d’adresses IP à www.blocklist.de (enregistrement obligatoire)
  • firewallcmd-new.conf : Création de règles de pare-feu pour nftables – ipv4 via fail2ban
  • firewalcmd-ipset.conf : Création de règles de pare-feu pour nftables – ipv6 via fail2ban
  • iptables-ipset-proto6-allports.conf : Création de règles de pare-feu pour iptables – ipv6 via fail2ban
  • osx-afctl.conf : Création de règles pour « Adaptative Firewall » sur Mac OSX Server via fail2ban
  • osx-ipfw.conf : Création de règles pour « IPFW » (le pare-feu de base) sur Mac OSX Server via fail2ban
  • ufw.conf : Création de règles pour « Uncomplicated Firewall » (une alternative à l’outil iptables) via fail2ban

Fail2Ban étant un logiciel très flexible, il est tout à fait possible d’ajouter soi-même de nouvelles « quarantaines », et de définir ses propres règles et actions.

Exemple de configuration de Fail2Ban

Protection contre les attaques « Brute Force » SSH

SSH (et le port 22) est l’un des services le plus souvent visé par des tentatives d’intrusion.
En protégeant ce port contre des tentatives de connexion illicites via SSH à l’aide de Fail2Ban, la machine étant détectée comme attaquante (suite à de multiples echecs d’authentification) ne pourra plus accéder au serveur pendant un laps de temps prédéfini.
Pour aboutir à ce résultat, Fail2Ban va analyser le fichier « /var/log/auth.log » en lui appliquant le filtre « /etc/fail2ban/filter.d/sshd.conf », puis l’action « /etc/fail2ban/action.d/iptables.conf » (si nécessaire).

Voici le contenu du fichier « /etc/fail2ban/jail.conf » relatif à ce cas :

[ssh]
enabled = true
port = ssh
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 6
bantime = 900

Pour information, suite à toute modification du fichier « jail.conf » modifié, il faudra redémarrer Fail2Ban avec la commande suivante :

sudo service fail2ban restart

Dès que fail2ban a redémarré, il est possible d’observer les résultats. Pour cela, il faut ouvrir le fichier de log et y repérer les lignes « fail2ban.filter » :
Exemple :

fail2ban.filter : DEBUG     Got event: 1 for /var/log/auth.log
fail2ban.filter : DEBUG     File changed: /var/log/auth.log
fail2ban.filter : DEBUG     processing lines with time:1376383522.0 and ip 192.168.0.10
fail2ban.filter : DEBUG     found 192.168.0.10
fail2ban.filter : DEBUG     Currently have failures from 1 IP's: ['192.168.0.10']
fail2ban.filter.datedetector : DEBUG    Sorting the template list

Au bout de 6 tentatives, le fichier de log affichera :

fail2ban.actions:                              WARNING [ssh] ban 192.168.0.10
fail2ban.actions.actions: DEBUG        iptables -n -L INPUT | grep -q fail2ban-ssh
fail2ban.actions.actions: DEBUG        iptables -n -L INPUT | grep -q fail2ban-ssh returned successfully
fail2ban.actions.actions: DEBUG        iptables -I fail2ban-ssh 1 -s 192.168.0.10 -J DROP
fail2ban.actions.actions: DEBUG        iptables -I fail2ban-ssh 1 -s 192.168.0.10 -J DROP returned successfully

Il est possible que, selon les distributions et les versions de Fail2Ban, le contenu des fichiers de log diffère de ce qui est décrit dans ce document.
Dans ce cas, nous vous recommandons de vérifier le contenu des fichiers de log à l’aide de la commande suivante :

grep -i fail2ban [chemin du fichier de log]/[fichier de log]

Dans cet exemple, nous pouvons voir que Fail2Ban a banni l’adresse IP 192.168.0.10 en mettant à jour les règles iptables du serveur (pour afficher les règles, taper sudo iptables -L).
La prochaine tentative de connexion depuis l’adresse IP 192.168.0.10 sera bloquée et aura pour résultat “Timed-out”.

Conclusion

Dans ce document, nous avons pu aborder le fonctionnement de Fail2Ban, l’installation de ce logiciel ainsi qu’exposer un exemple simple de configuration et les interactions entre Fail2Ban et iptables.
Néanmoins, d’autres services peuvent être sécurisés à l’aide de Fail2Ban tels que : FTP, Sendmail, Apache, MySQL, PHP, etc…

Liens utiles

Retrouvez l’intégralité de cet article et bien plus encore sur notre base de connaissances.

Laisser un commentaire

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

Copyright © 2014 Aruba.