Fail2Ban est un framework de prévention des intrusions écrit dans le langage de programmation Python. Il est capable de tourner sur les systèmes POSIX, c’est une interface à un système de contrôle de paquet ou de pare-feu installé localement (par exemple, iptables ou TCP Wrapper).
Fail2ban
Fail2ban est un script surveillant les accès réseau grâce aux logs des serveurs. Lorsqu’il détecte des erreurs d’authentification répétées, il prend des contre-mesures en bannissant l’adresse IP grâce à iptables. Cela permet d’éviter nombre d’attaques bruteforce et/ou par dictionnaire.
L’attaque par force brute est une méthode utilisée en cryptanalyse pour trouver un mot de passe ou une clé. Il s’agit de tester, une à une, toutes les combinaisons possibles. Cette méthode de recherche exhaustive ne réussit que dans les cas où le mot de passe cherché est constitué de peu de caractères.
Cette méthode est souvent combinée avec l’attaque par dictionnaire et par table arc-en-ciel pour obtenir de meilleurs résultats.
IPtable est installé par défaut sur les serveurs OVH mais pas Fail2ban. Voici comment l’installer :
dans putty sous root
Sous Debian : apt-get update && apt-get install fail2ban
Sous Gentoo/Release2 : # emerge fail2ban
puis installer whois
# emerge whois
Configuration # Fail2Ban configuration file
Fail2ban se configure grâce au fichier : /etc/fail2ban/jail.conf. On va donc éditer ce fichier, nous allons prendre l’exemple avec nano.
nano /etc/fail2ban/jail.conf
Ce fichier de configuration est composé de plusieurs parties, une définissant les paramètres communs (par défaut) et les autres concernant différentes composants de système.
Dans chaque partie du fichier, n’oubliez pas de modifier les adresses mail auxquelles vous souhaitez recevoir les alertes : dest=yourmail@mail.com ou dest=you@mail.com
et sender=fail2ban@mail.com
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=you@mail.com, sender=fail2ban@mail.com]
La partie [DEFAULT] définit donc les paramètres communs par défaut, ils peuvent donc être surchargés (re-définies) dans chaque partie spécifique. Les valeurs indiquées ici sont celles définies par défaut lors de l’installation.
Ignore les adresses IP suivantes des règles (les adresses sont séparées par des espaces)
ignoreip = 127.0.0.1
La durée du bannissement (en secondes)
bantime = 600
La durée pendant laquelle les tentatives de connexions ont lieu (en secondes)
findtime = 600
Le nombre de tentatives de connexions pendant la durée « findtime »
maxretry = 3
Chaque section se paramètre indépendamment, Vous pouvez activer chaque section au choix.
Les paramètres que vous allez retrouver sont :
Sert à activer (true) ou à désactiver (false) la section
enabled = false
Indique le type de filtrage à effectuer (ne pas toucher)
filter = sshd
Indique les actions à effectuer pour le section (ne pas toucher sauf expérimenté à l’exception du dest= et sender= )
action = …
Indique le fichier où doivent être placé les logs de la section. Si vous utilisez syslog-ng (par défaut sur une release 2 OVH) le chemin doit être celui dans le fichier de configuration /etc/syslog-ng/syslog-ng.conf : « »
logpath = /var/log/….
Prenons l’exemple du serveur ssh.
SSH
[ssh-iptables]
enabled = true
filter = sshd
action = iptables[name=SSH, port=ssh, protocol=tcp]
sendmail-whois[name=SSH, dest=yourmail@mail.com]
logpath = /var/log/ssh.log
maxretry = 3
# durée du banissement
bantime = 600
Là par exemple je bannis au bout de 3 tentatives et pendant 10 minutes toute personne essayant de se connecter 3 fois sans y parvenir.
* enabled = true ==> On active cette fonctionnalité. (false à la place de true et cette fonctionnalité est désactivée).
* maxretry = 3 ==> Nombre de tentatives maximum avant d’être banni.
* bantime = 600 ==> Durée du ban en secondes (soit 10 minutes).
Il existe une duplication des logs ssh dans la release 2 OVH entre /home/log/ssh.log et /home/log/auth.log.
Vous pouvez alléger et spécifier ces logs en suivant le howto suivant : OVH 2:Syslog-ng ssh
Un autre exemple le serveur ftp :
FTP
Tout d’abord dire à notre serveur ftp (proftpd par défaut dans une gentoo release 2 ovh) de loguer les informations de connexion dans /var/log/auth.log
nano /etc/proftpd/proftpd.conf
Ajoutez à la fin du fichier :
SystemLog /var/log/auth.log
Redémarrez proftpd pour prendre en compte la modification :
/etc/init.d/proftpd restart
Puis activez la règle de la section proftpd de notre jail.conf :
nano /etc/fail2ban/jail.conf
Modifiez comme suit (vous pouvez adapter selon les explication ci-dessus) :
[proftpd-iptables]
enabled = true
filter = proftpd
action = iptables[name=ProFTPD, port=ftp, protocol=tcp]
sendmail-whois[name=ProFTPD, dest=yourmail@mail.com]
logpath = /var/log/auth.log
maxretry = 6
Courier Pop3
Vous pouvez ajouter cette section qui n’existe pas dans la configuration de base de Fail2ban (0.8.2) mais qui est implémenté.
Elle vous permettra de vous protéger également contre les tentatives de connexion sur les boites email via le prorocole Pop3.
Pour le paramètre logpath = /var/log/maillog
[courierpop3-iptables]
enabled = true
filter = courierlogin
backend = polling
action = iptables[name=courierpop3, port=pop3, protocol=tcp]
sendmail-whois[name=courierpop3, dest=yourmail@mail.com, sender=fail2ban@mail.com]
logpath = /var/log/mail.log
bantime = 600
findtime = 60
maxretry = 5
Remarques : sur une release2 installé le 08/01/2009, remplacer sendmail-whois par mail-whois sinon fail2ban ne démarrera pas.
action = iptables[name=courierpop3, port=pop3, protocol=tcp]
mail-whois[name=courierpop3, dest=yourmail@mail.com, sender=fail2ban@mail.com]
Courier Imap
Vous pouvez ajouter cette section qui n’existe pas dans la configuration de base de Fail2ban (0.8.2), son implémentation n’est pas encore stabilisé.
Elle vous permettra de vous protéger également contre les tentatives de connexion sur les boites emails via le protocole imap.
[courierimap-iptables]
enabled = true
filter = courierlogin
backend = polling
action = iptables[name=courierimap, port=imap, protocol=tcp]
sendmail-whois[name=courierpop3, dest=yourmail@mail.com, sender=fail2ban@mail.com]
logpath = /var/log/mail.log
bantime = 600
findtime = 60
maxretry = 5
Remarques : sur une release2 installé le 08/01/2009, remplacer sendmail-whois par mail-whois sinon fail2ban ne démarrera pas.
action = iptables[name=courierpop3, port=pop3, protocol=tcp]
mail-whois[name=courierpop3, dest=yourmail@mail.com, sender=fail2ban@mail.com]
Logrotate
Enfin pour éviter que le fichier de log de fail2ban « gonfle trop » vous pouvez faire tourner ces logs avec logrotate fourni sur votre distribution :
nano /etc/logrotate.d/fail2ban
Ajoutez :
/var/log/fail2ban.log {
weekly
rotate 7
missingok
compress
postrotate
/usr/bin/fail2ban-client reload 1>/dev/null || true
endscript
}
Ce qui fera que les fichiers de log de fail2ban seront permutés et compressés toutes les semaines et que seuls les 7 derniers fichiers journaux de fail2ban seront gardés.
Démarrage
Après toutes modifications sur le fichier de configuration, n’oubliez pas de redémarrer Fail2Ban pour les prendre en compte :
/etc/init.d/fail2ban restart
Pour démarrer automatiquement fail2ban avec le serveur (utile pour qu’il se lance au reboot par exempe) faites :
rc-update add fail2ban default
Quelques jours plus tard, vous aurez peut-être envie de voir le log de fail2ban pour essayer de voir si beaucoup d’IPs ont été bannies. Le log de fail2ban se trouve à cet endroit : /var/log/fail2ban.log
Si vous avez envie de le lire avec nano :
nano /var/log/fail2ban.log
*** Attention au reboot
Fail2ban risque de ne pas se lancer au reboot car le fichier /tmp/fail2ban.sock existe. Il suffit de l’effacer et de relancer fali2ban
référence : http://www.fail2ban.org/wiki/index.php/Main_Page