e-grisel.net

Serveur dédié – Un peu de sécurité supplémentaire avec Fail2ban

Bon, maintenant que notre firewall est en place nous devons aussi pensez à surveiller l’activité qui se passe sur les ports que nous avons laissé ouverts, et pour cela il existe un programme spécifique intitulé Fail2ban qui va analyser les logs de notre serveur et bloquer les indésirables (tentatives d’intrusion) pendant un temps défini.

Le principe de fail2ban est simple, nous allons lui configurer des filtres et des règles, et d’après cela il va analyser les logs de nos serveurs, et s’il décèle une tentative d’intrusion, il va ajouter une règle à Iptables pendant un certain temps afin de bloquer l’IP de l’indésirable

Analyse des logs

Avant de commencer l’installation et la configuration de fail2ban, attardons-nous un instant sur les logs de notre serveur.

Les logs se trouvent dans le répertoire /var/log/. La seule exception que je connaisse concerne les logs des sites web que nous allons installer plus tard et qui se trouvent dans leur dossier respectif, mais nous reviendrons plus tard quand nous configurerons nos VirtualHosts pour Apache. Les logs étant de simples fichiers texte, nous pouvons utiliser différentes commandes pour les afficher :
[root@serveur:~]# cat /var/log/auth.log va afficher la totalité du contenu de ce log. Une autre solution pour n’avoir que les 10 dernières lignes ajoutées est d’utiliser la commande suivante :
[root@serveur:~]# tail /var/log/auth.log Si vous désirez voir plus de lignes, par exemples les 20 dernières, nous ajoutons l’option -n suivie du nombre de lignes :
[root@serveur:~]# tail -n 20 /var/log/auth.log et la dernière option de la mort qui tue, l’option -f qui affiche les données au fur et à mesure:
[root@serveur:~]# tail -n 20 -f /var/log/auth.log vous pourrez peut-être ainsi visualiser une tentative d’intrusion en live.

Installation et configuration de Fail2ban

Bon, passons maintenant aux choses sérieuses. Tout d’abord l’installation :
[root@serveur:~]# apt-get install fail2ban Sur un serveur OVH, et si vous avez configuré le firewall comme expliqué dans mon article précédent, il faut d’abord modifier notre firewall pour accepter les connexions FTP en sortie. Pour ce faire, éditer le fichier /etc/init.d/firewall et dé-commenter (enlever le #) de la ligne correspondant au FTP Out.

Configuration

La configuration se passe dans le répertoire /etc/fail2ban/ ou vous trouverez 2 dossiers (action.d et filter.d) et deux fichiers (fail2ban.conf et jail.conf). Nous allons copier les deux fichiers et les renommer en fail2ban.local et jail.local.
[root@serveur:~]# cp /etc/fail2ban/fail2ban.conf /etc/fail2ban/fail2ban.local
[root@serveur:~]# cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local Cette opération n’est pas obligatoire, mais il se peut que les fichiers d’origine soient remplacés lors d’une mise à jour du programme, et si nous y effectuons des modifications elles seront supprimées, alors que les nouveaux fichiers (fail2ban.local et jail.local) ne seront jamais remplacés lors d’une mise à jour, ils sont lus par le programme après les fichiers en .conf et leurs instructions supplantent celles inscrites dans les fichiers en .conf.

La partie la plus importante de la configuration se passe dans le fichier nouvellement créé jail.local. Par défaut, quelques sections sont insérées comme templates. Nous devons activer les sections qui nous intéressent et les adapter à notre configuration. Voici un exemple de section :
[ssh-iptables]
enabled = true
filter = sshd
action = iptables [name=SSH, port=ssh, protocol=tcp]
logpath = /var/log/auth.log
maxretry = 5

Avec ces quelques réglages voici ce qui va se passer :

1. la section ssh-iptables est activée (enabled = true)
2. le filtre sshd.conf du sous-répertoire filter.d sera utilisé
3. les actions décrites dans iptables.conf (sous-répertoire action.d) seront exécutées si la sortie du filtre est positive.
4. le fichier de log analysé par le filtre est /var/log/auth.log

Nous allons effectuer quelques modifications que je commenterai (seules les modifications sont affichées).

• Section [DEFAULT]
  ignoreip = 127.0.0.1 (nous ignorons les tentatives de cette IP, nous n’allons quand même pas nous auto-bloquer )
  bantime = 600 (temps de bannissement en secondes)
  maxretry = 3 (nombre de tentatives possibles avant blocage)
  
  Toutes les options définies dans la section [DEFAULT] peuvent être outrepassées par chaque prison.
  
• Section [ssh] :
  enabled = true (nous activons la prison)
  maxretry = 3 (nombre de tentatives avant blocage)
• Section [ssh-ddos] :
  enabled = true (nous activons la prison)
  maxretry = 3 (nombre de tentatives avant blocage)
• Section [apache] :
  enabled = true (nous activons la prison)
  maxretry = 6 (nombre de tentatives avant blocage)
• Section [apache-noscript] :
  enabled = true (nous activons la prison)
  maxretry = 6 (nombre de tentatives avant blocage)
• Section [apache-overflows] :
  enabled = true (nous activons la prison)
  maxretry = 2 (nombre de tentatives avant blocage)

Et nous laissons le reste tel quel pour l’instant. Nous y reviendrons éventuellement plus tard lorsque nous installerons notre serveur mail.

Configurons maintenant les filtres pour les prisons que nous avons activées.

ssh
Le filtre de cette prison se trouve dans le fichier sshd.conf du sous-répertoire filter.d. Quelques expressions régulières sont déjà existantes, nous allons les compléter avec les nôtres :
failregex = ^%(__prefix_line)s(?:error: PAM: )?Authentication failure for .* from <HOST>\s*$
^%(__prefix_line)s(?:error: PAM: )?User not known to the underlying authentication module for .* from <HOST>\s*$
^%(__prefix_line)sFailed (?:password|publickey) for .* from <HOST>(?: port \d*)?(?: ssh\d*)?$
^%(__prefix_line)sROOT LOGIN REFUSED.* FROM <HOST>\s*$
^%(__prefix_line)s[iI](?:llegal|nvalid) user .* from <HOST>\s*$
^%(__prefix_line)sUser .+ from <HOST> not allowed because not listed in AllowUsers$
^%(__prefix_line)sUser .+ from <HOST> not allowed because none of user's groups are listed in AllowGroups\s*$
^%(__prefix_line)sauthentication failure; logname=\S* uid=\S* euid=\S* tty=\S* ruser=\S* rhost=<HOST>(?:\s+user=.*)?\s*$
^%(__prefix_line)srefused connect from \S+ \(<HOST>\)\s*$
^%(__prefix_line)sAddress <HOST> .* POSSIBLE BREAK-IN ATTEMPT\s*$
Authentication failure for .* from <HOST>
Failed [-/\w]+ for .* from <HOST>
ROOT LOGIN REFUSED .* FROM <HOST>
[iI](?:llegal|nvalid) user .* from <HOST> Les lignes que j’ai ajoutées sont indiquées en italique.

ssh-ddos
Fichier : /etc/fail2ban/filter.d/ssh-ddos.conf
Rien à modifier ici.

apache
Fichier : /etc/fail2ban/filter.d/apache-auth.conf
Rien à modifier ici.

apache-noscript
Fichier : /etc/fail2ban/filter.d/apache-noscript.conf
Rien à modifier ici.

apache-overflows
Fichier : /etc/fail2ban/filter.d/apache-overflows.conf
Rien à modifier ici.

Test de notre configuration

Si vous créez vos propres expressions régulières (regex), vous voudrez sans doute pouvoir tester leur exactitude et leur fonctionnement. Pour tester une seule expression régulière nous utiliserons la syntaxe suivante :
[root@serveur:~]# fail2ban-regex "ligne" "failregex" « ligne » étant un copier-coller d’une ligne complète d’un log posant quelques soucis et « failregex » représente votre expression régulière, il nous faut donc remplacer ces deux termes (ligne et failregex) par nos propres données. N’oubliez pas d’entourer la ligne ainsi que l’expression régulière par des guillemets doubles.

fail2ban-regex accepte aussi des fichiers. Il est ainsi plus facile de tester et débugger nos expressions régulières :
[root@serveur:~]# fail2ban-regex /var/log/auth.log /etc/fail2ban/filter.d/sshd.conf ou utiliser une combinaison des deux :
[root@serveur:~]# fail2ban-regex /var/log/auth.log "Failed [-/\w]+ for .* from <HOST>"

Limitations

C’est assez difficile d’évaluer le temps de réaction de Fail2ban. Il attend 1 seconde avant de vérifier s’il y a de nouveaux logs à scanner. Dans la plupart des cas ça ne pose aucun problème, mais parfois il est possible qu’il y ait plus de tentatives d’intrusions que spécifié par maxretry.

Conclusion

Il ne nous reste plus qu’à redémarrer fail2ban pour qu’il prenne en charge nos modifications :
[root@serveur:~]# /etc/init.d/fail2ban restart Et vous pourrez ensuite aller voir dans les logs (/var/log/fail2ban.log) que nos modifications sont bien prises en compte.

Prochaine étape : IP Failover, DNS et Reverse IP
Etape précédente : Mise en place du firewall

Pour plus d’informations sur la configuration de ce programme, n’hésitez pas à vous rendre sur le site officiel : www.fail2ban.org