Installez le paquet fail2ban disponible dans les dépôts Universe.

Lancer ensuite la commande

sudo fail2ban-client -x start

Dans ce tutoriel, il est souvent mentionné de modifier /etc/fail2ban/jail.conf, il est en fait préférable de copier ce fichier dans /etc/fail2ban/jail.local, et de modifier dans ce dernier les configurations de base avec les paramètres spécifiques. Ce fichier jail.local sera automatiquement lu lors de l'initialisation de fail2ban.

Le but de fail2ban est d'empêcher une attaque qui, par force brute, trouve un identifiant/mot de passe permettant l'accès à un service. Les postes serveurs ne dormant jamais, ils sont la cible d'attaques automatiques en provenance de partout. Et sans un tel outil, qui sanctionne les tentatives, plus un serveur est rapide à répondre, plus il est menacé. Le paramétrage par défaut de la sanction est de 10mn, alors faisons un petit calcul : si un attaquant du service SSH fait 5 tentatives toutes les 10mn (il ne se fait sanctionner qu'à 6 erreurs), alors sans jamais se faire bloquer, il pourra effectuer 5×(60/10)×24×365=262800 tentatives par an, soit plus d'un quart de million. Alors supposons qu'un individu dispose de 10 postes (10 IP) d'où lancer une attaque, il aura effectué au bout d'un an 2.6 millions d'essais, et avec 100 ou 1000 postes, 26 millions ou 260 millions. On voit donc bien que 10 minutes n'est pas une sanction suffisante. Paramétrage par défaut

Par rapport au blocage par défaut (600s), un blocage de 1h est bien plus réaliste (3600s), ou même 1 journée (86400s), ou pourquoi pas 1 semaine (604800s). Mais attention que changer le 'bantime' n'agit pas sur le 'findtime' qu'il faut également ajuster, car sinon le 'findtime' par défaut (10mn) est utilisé, ce qui permet à nouveau l'attaque expliqué au point précédent. L'inconvénient d'un (très ?) grand 'findtime' est qu'il pousse fail2ban à analyser de plus longs fichiers de log, et que ça peut être pénalisant du point de vue des performances, alors c'est à vous de voir. La solution est alors de choisir un grand 'findtime' et un très grand 'bantime' : 3600 et 86400, ou encore 86400 et 604800.

Mais maintenant que vous avez mis en place une punition importante, il faut bien veiller à ajouter en liste blanche vos adresses IPs les plus communes, car l'erreur est humaine, donc il ne faudrait pas vous bloquer vous-même de l'accès à votre serveur. La liste 'ignoreip' est séparée d'espaces, donc si votre IP est 8.8.8.8, éditez le fichier /etc/fail2ban/jail.conf :

[DEFAULT]
ignoreip = 127.0.0.1 8.8.8.8
findtime = 3600
bantime = 86400

Modifier la configuration pour l'adapter à vos besoins

Pour spécifier à fail2ban quels services il doit surveiller, éditez le fichier /etc/fail2ban/jail.conf

Dans la partie jail vous trouverez des blocs du type :

 [ssh]
  
  enabled = true
  port    = ssh,sftp
  filter  = sshd
  logpath  = /var/log/auth.log
  maxretry = 6
  action   = iptables[name=SSH, port=ssh, protocol=tcp]
  
  
  [vsftpd]
  
  enabled = true
  port    = ftp,ftp-data,ftps,ftps-data
  filter  = vsftpd
  logpath  = /var/log/auth.log
  maxretry = 6
  action   = iptables[name=VSFTPD, port=21, protocol=tcp]
 
~                                                                

Il indique, par ordre, l'activation, les ports à bloquer avec les règles iptables, le nom du filtre (expression régulière) associé, le fichier de log à lire, le nombre maximal de tentatives.

Un certain nombre de services disposent de tels blocs de configuration, vous pouvez les activer en passant si besoin false à true.

Attention, sur la ligne “port”, “ssh” n'est qu'un alias pour le port standard, i.e. 22; si vous avez changé le port ssh dans la configuration de OpenSSH, il faut le préciser à fail2ban ! Dans la configuration ci-dessus, ajoutez à la ligne “port”, votre port SSH, par exemple port =ssh,sftp,2276 si votre nouveau port ssh est 2276, sans quoi fail2ban ne surveillera que le port 22.

D'une manière générale, il est important d'effectuer des tests pour vérifier le bon fonctionnement de fail2ban ! Voir ci-dessous comment procéder.

Relancez la configuration avec

sudo fail2ban-client reload

Vous pouvez alors vérifier si les prisons ont été correctement lancées avec :

sudo fail2ban-client status
Status
|- Number of jail:      3
`- Jail list:           apache, vsftpd, ssh

Les prisons peuvent être contrôlées séparément avec les mots clés start,stop,status Par exemple :

sudo fail2ban-client stop ssh
Jail stopped

Pour plus d'informations, référez-vous aux pages de man. Verifier le bon fonctionnement de votre configuration Fail2Ban

Pour vérifier le bon fonctionnement de fail2ban : essayez de vous identifier plusieurs fois en saisissant un mauvais mot de passe. Si Fail2ban fonctionne, vous devriez être interdit d'accès au serveur au bout d'un certain nombre d'essais (précisés dans la configuration à la ligne maxretry).

Côté serveur vous pouvez également surveiller ce qu'il se passe avec la commande

sudo fail2ban-client status ssh

qui dans ce cas vous retournera le statut de la prison 'ssh' (avec le nombre de tentative échouée et la liste des IP banni)

Attention, si votre IP de test apparaît comme banni mais que vous pouvez tout de même vous loguer, il se peut que vous ayez un problème de configuration des ports pour fail2ban (voir l'avertissement dans “configuration” ci-dessus) une variante de fail2ban-client statut, qui permet un checklist des ip bannies sur toutes les jails

sudo nano checklist_ban
#!/bin/bash
#lancer le script en sudo 
JAILS=$(fail2ban-client status | grep " Jail list:" | sed 's/`- Jail list:\t\t//g' | sed 's/,//g')
for j in $JAILS
do
echo "$j $(fail2ban-client status $j | grep " Currently banned:" | sed 's/   |- Currently banned:\t//g')"
done

À chaque service est associé un fichier de configuration dans le dossier /etc/fail2ban/filter.d

Une expression rationnelle définit les lignes du log qui signalent une erreur d'authentification. Il est possible de spécifier via une regex des exceptions, ie des lignes à ignorer. Cela peut être utile par exemple pour ne pas bannir les IP provenant de votre réseau local. Exemple avec la règle anti-w00tw00t

Voici un exemple, pour bannir les désormais célèbres requêtes DFind w00tw00t. Dans le fichier /etc/fail2ban/jail.conf on ajoute :

[apache-w00tw00t]
enabled = true
filter = apache-w00tw00t
action = iptables[name=Apache-w00tw00t,port=80,protocol=tcp]
logpath = /var/log/apache*/*access.log
maxretry = 1

On notera que contrairement aux autres règles, celle-ci s'attaque au fichier de log des accès (/var/log/apache2/access*.log).

Voici le fichier de règles /etc/fail2ban/filter.d/apache-w00tw00t.conf

[Definition]

failregex = ^<HOST> -.*"GET \/w00tw00t\.at\.ISC\.SANS\.DFind\:\).*".*

ignoreregex =

On teste maintenant si la règle s'applique bien en faisant :

fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/apache-w00tw00t.conf

Si vous subissez ce genre d'attaque, on peut voir en sortie de ce programme les adresses des spammeurs. Les règles iptables sont automatiquement crées en conséquence.

Pour qu'il accepte de se lancer au démarrage, j'ai dû changer la ligne “socket = /var/run/fail2ban/fail2ban.sock” en “socket = /var/run/fail2ban.sock” dans le fichier /etc/fail2ban/fail2ban.conf

Alertes e-mail après un bannissement

Il est possible de recevoir un e-mail après chaque bannissement d'une adresse IP en utilisant la syntaxe suivante dans la section [DEFAULT] du fichier /etc/fail2ban/jail.local :

destemail = votrelogin@votrelogin-desktop

Voire même toute autre adresse mail si le système est correctement configuré pour l'envoi de mail, par exemple avec smtp.

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 des email particulier dans une prison donnée.

Pour voir les messages locaux (si vous avez laissé une adresse e-mail du type @localhost), il vous faudra ouvrir un terminal et taper la commande “mail” ou, plus simplement encore, consulter le fichier /var/mail/votrelogin.

Pour activer l'envoi de mail, modifier la ligne dans le fichier /etc/fail2ban/jail.conf

action = %(action_)s 

Vers : (pour envoyer un mail avec le whois)

action = %(action_mw)s 

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

action = %(action_mwl)s 

Si les dates d'envoi des messages ne correspondent pas à la date réelle, il faut alors ajouter à la fin du fichier /etc/default/fail2ban :

LC_ALL=C
LANG=C

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

sudo service fail2ban restart

Des informations complémentaires sont disponibles sur le site officiel de Fail2ban : FAQ Fail2ban Modification du filtre SASL

Pour activer le filtre SASL permettant le bannissement en cas d'attaque par force brute il faut modifier l'expression régulière du filtre dans le fichier /etc/fail2ban/filter.d/sasl.conf

Remplacer la ligne:

failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(: [A-Za-z0-9+/]*={0,2})?$

Par:

failregex = (?i): warning: [-._\w]+\[<HOST>\]: SASL (?:LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed: \w

On teste maintenant si la règle s'applique bien en faisant :

fail2ban-regex /var/log/mail.log /etc/fail2ban/filter.d/sasl.conf

Une erreur qui semble toucher les versions inférieures à 0.8.5-2 (fail2ban-client –version). Si dans votre /var/log/fail2ban.log, vous avez ce genre d'erreurs “fail2ban.actions.action: ERROR iptables …” et qu'il manque curieusement des règles fail2ban dans iptables (sudo iptables -L -n -v), veuillez modifier le fichier /usr/bin/fail2ban-client :

    sudo nano /usr/bin/fail2ban-client

et ajouter time.sleep(0.1) ou time.sleep(0.2)

	def __processCmd(self, cmd, showRet = True):
		beautifier = Beautifier()
		for c in cmd:
			time.sleep(0.1)
			beautifier.setInputCmd(c)
			try:
				client = CSocket(self.__conf["socket"])
				ret = client.send(c)

sudo fail2ban-client reload

sudo tail -n 300 /var/log/fail2ban.log

Retour...