Optimiser protéger son serveur Fail2ban

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