Catégories
Blog Open-source Planet-libre Reseau

Bannir les bannis avec Fail2Ban

Depuis la mise en place de Fail2Ban sur mon serveur perso pour bloquer les attaques DOS.  La règle mise en place est un bannissement de 10 minutes pour une machine générant plus de 360 requêtes en moins de 2 minutes. Malgré cela, il arrive certaines machines insistent  lourdement en recommencent leurs attaques toutes les 10 minutes…

J’ai donc décidé de mettre en place une règle un peu plus évoluée qui va bannir pendant 1 heures les machines bannies 3 fois en moins d’une heure puis 24 heures pour les gros lourds qui se font bannir 3 fois de suite de cette manière. En bonus, nous allons également voir comment pourrir la bande passante de la machine effectuant l’attaque en utilisant la règle de drop de type « tarpitting » de IpTable.

Avant de commencer

Je pars sur le principe ou vous disposez d’un Fail2ban fonctionnel (suivre mon premier billet pour avoir la procédure d’installation).

Le principe est le suivant: nous allons surveiller le fichier /var/log/fail2ban.log pour y analyser les logs de type ban et multi-ban et y associer les actions appropriés.

Pour cela on commence par créer les filtres.

Filtre ban.conf et multiban.conf

On édite le filtre ban.conf dans le répertoire /etc/fail2ban/filter.d:

[crayon url= »https://raw.github.com/nicolargo/fail2banarena/master/filter.d/ban.conf » /]

Rien de bien compliqué: on récupère dans la variable HOST l’adresse IP de la machine bannie.

Le second filtre multiban.conf (également dans le répertoire /etc/fail2ban/filter.d)

[crayon url= »https://raw.github.com/nicolargo/fail2banarena/master/filter.d/multiban.conf » /]

On actionne ensuite les filtre et les actions correspondantes dans la prison de Fail2ban.

Configuration de la prison Fail2ban

Le fichier prison (jail) par défaut se trouve dans /etc/fail2ban/jail.conf, il faut ajouter les sections suivantes (à adapter à vos besoins):

[crayon url= »https://raw.github.com/nicolargo/fail2banarena/master/jail.conf » /]

L’action choisie pour bannir ces attaques multiples est plutôt radicale: bloquer toutes les requêtes TCP (avec l’action iptables-allports) et envoyer un mail à l’administrateur (lors d’un bannissement de 24h). Il est bien sûr possible de modifier ces actions et les paramètres associés.

Le résultat

En surveillant le fichier fail2ban.log, on peut voir que la nouvelle prison fonctionne bien:

Après trois attaque HTTP DOS, le filtre MULTI BAN prend le relais et banni l’adresse IP pour 24 heures.

En bonus: la contre-attaque !

Le firewall IpTable qui protège mon serveur dispose d’une règle nommé TARPIT que l’on peut coupler avec un DROP pour saturer la liaison de la machine qui fait ce genre d’attaque (pour plus de précision, je vous conseille la lecture de ce très bon billet sur WikiGento).

Pour supporter la directive TARPIT, il faut charger le module IpTable de la manière suivante (procédure validée sous Debian Squeeze):

[crayon]

sudo apt-get install xtables-addons-common xtables-addons-source

sudo module-assistant auto-install xtables-addons-source

[/crayon]

Pour Fail2Ban, on commence donc par créer un nouveau fichier d’action que l’on va nommer iptables-tarpit.conf (dans le répertoire /etc/fail2ban/action.d).

Note: je suis bêtement reparti du fichier iptables-allports.conf auquel j’ai ajouté la ligne de commande iptables avec -j TARPIT

[crayon url= »https://raw.github.com/nicolargo/fail2banarena/master/action.d/iptables-tarpit.conf » /]

Pour activer cette nouvelle action dans notre jail, il suffit de remplacer les lignes:

action = iptables-allports[name=ALL]

par:

action = iptables-tarpit[name=ALL]

dans notre fichier jail.conf.

Conclusion

Il est difficile (voir même impossible) de se défendre contre les attaques DOS sans engager de gros moyens (financier et en temps). La solution proposée dans cet article n’est pas parfaite mais suffira largement contre les Bots ou les scripts kiddies.

Subissez-vous des attaques DOS sur vos serveurs ?

Si oui, quels sont les solutions techniques que vous mettez en place pour les contrer ?

Catégories
Open-source Planet-libre Reseau Systeme Web

Protéger son serveur en utilisant Fail2Ban

Comme toutes les machines exposées au réseau Internet, mon serveur Web est continuellement la cible de tentatives d’attaques basiques de type brute force et DOS. J’avais déjà abordé le sujet sous la forme de billets tel que « Sécuriser son blog WordPress » ou « Détection des attaques DOS/DDOS avec Nagios« . Nous allons aujourd’hui parler d’une solution de protection active se déclenchant automatiquement lors d’une de ces attaques: Fail2Ban.

Comment marche Fail2Ban ?

Développé en langage Python, Fail2Ban est un logiciel libre permettant d’analyser des fichiers de logs et de déclencher des actions si certaines choses suspectes sont détectées. La grande force de Fail2Ban est sa grande modularité que cela soit au niveau des mécanismes de détections basées sur les expressions régulières ou sur les actions à mener qui peuvent aller de l’expédition d’un mail à la mise en place de règles de Firewall.

Fail2Ban se base sur un système de prisons (jails) que l’on peut définir, activer ou désactiver dans un simple fichier de configuration (/etc/fail2ban/jail.conf).

Une prison (jail) est composée, entre autres, des éléments suivants:

  • Nom du fichier de log à analyser.
  • Filtre à appliquer sur ce fichier de log (la liste des filtres disponibles se trouve dans le répertoire /etc/fail2ban/filter.d). Il est bien sûr possible de créer ses propres filtres.
  • Paramètres permettant de définir si une action doit être déclenchée quand le filtre correspond (« match »): Nombre de « matchs » (maxretry), intervalle de temps correspondant (findtime)…
  • Action à mener si nécessaire. La liste des actions se trouve dans le répertoire /etc/fail2ban/action.d. Il est également possible de créer ses propres actions.

Installation de Fail2Ban

On commence par installer Fail2Ban sur son système. Il se trouve dans la grande majorité des distributions GNU/Linux et BSD. par exemple pour l’installer sur une machine Debian 6, il suffit de saisir la commande suivante (en root ou bien précédée d’un sudo):

apt-get install fail2ban

Protection contre les attaques « brute force » SSH

Un exemple étant toujours plus parlant, nous allons configurer notre Fail2Ban pour bloquer automatiquement les adresses IP des machines essayant des attaques de type « brute force » sur notre port SSH (cette attaque est à la portée de n’importe quel « neuneu ». On trouve de très bon tutoriaux sur le sujet sur le net).

Si une machine cliente échoue 3 fois de suite lors de la saisie du couple login/password sur le serveur SSH alors on bloque l’accès au port TCP/SSH pendant 15 minutes. On analyse pour cela le fichier de log /var/log/auth.log en lui appliquant le filtre /etc/fail2ban/filter.d/sshd.conf puis, si nécessaire, l’action /etc/fail2ban/action.d/iptables.conf. La définition de cette prison (jail) est à faire dans le fichier /etc/fail2ban/jail.conf:

# SSH
# 3 retry ? > Ban for 15 minutes

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

Un fois le filtre activé en relançant Fail2Ban avec la commande (en root):

service fail2ban restart

On peut rapidement voir son efficacité en regardant le fichier de log (par défaut sous /var/log/fail2ban.log):

Protection contre les attaques DOS (HTTP/GET)

Dans ce deuxième exemple nous allons voir comment lutter efficacement contre les attaques de type DOS ciblant vos serveurs Web. Ces attaques se caractérisent par un nombre inhabituel de requêtes HTTP venant d’un même client (du moins d’une même adresse IP source).

Le plus difficile est de trouver les bons paramètres correspondants à un comportement « inhabituel ». Dans l’exemple suivant, je considère comme « inhabituel » le fait qu’un client effectue plus de 360 requêtes en 2 minutes (soit une moyenne de supérieurement à 3 req/sec) sur mon serveur Web. Dans ce cas, je bloque l’accès au port HTTP pendant une durée de 10 minutes.

La prison (jail) correspondante est la suivante (à ajouter dans votre fichier /etc/fail2ban/jail.conf):

# Protect against DOS attack
# 360 requests in 2 min > Ban for 10 minutes

[http-get-dos]
enabled = true
port = http,https
filter = http-get-dos
logpath = /var/log/varnish/varnishncsa.log
maxretry = 360
findtime = 120
action = iptables[name=HTTP, port=http, protocol=tcp]
mail-whois-lines[name=%(__name__)s, dest=%(destemail)s, logpath=%(logpath)s]
bantime = 600

En regardant de plus près cette prison, on remarque qu’elle utilise en entrée le fichier de log au format NCSA généré par le système de cache Varnish que j’utilise en frontal sur mes serveurs Web (/var/log/varnish/varnishncsa.log). Il est bien sûr possible d’utiliser directement le log de votre serveur Apache ou Nginx. Le filtre http-get-dos n’est pas fourni par défaut. Il faut donc éditer le fichier /etc/fail2ban/filter.d/http-get-dos.conf avec le contenu suivant:

# Fail2Ban configuration file

#

# Author: http://www.go2linux.org

#

[Definition]

# Option: failregex

# Note: This regex will match any GET entry in your logs, so basically all valid and not valid entries are a match.

# You should set up in the jail.conf file, the maxretry and findtime carefully in order to avoid false positives.

failregex = ^<HOST>.*\"GET

# Option: ignoreregex

# Notes.: regex to ignore. If this regex matches, the line is ignored.

# Values: TEXT

#

ignoreregex =

Enfin, en cas de « match », on applique deux actions:

  1. blocage du port HTTP avec l’action iptables définie dans /etc/fail2ban/action.d/iptables.conf
  2. envoie d’un mail signalant le blocage avec l’action mail-whois-lines. L’adresse du mail est défini dans la variable destemail à modifier dans le fichier jail.conf.

Un fois le filtre activé:

service fail2ban restart

On peut regarder le fichier de log (/var/log/fail2ban.log)…:

$ tail -f /var/log/fail2ban.log

2012-02-22 11:36:59,134 fail2ban.actions: WARNING [http-get-dos] Ban 107.---.---.---

… et/ou attendre la réception des mails:

Conclusion

Ce billet est une simple introduction à l’utilisation de Fail2Ban qui peut être configuré de manière beaucoup plus personnalisé et en fonction de vous besoins. Si vous avez d’autres exemples d’utilisation, les commentaires ci-dessous sont fait pour cela !