Protéger un projet Symfony2 contre les bruteforce

4 gravatar Par Grégoire Marchal - 29/08/2012

Pour protéger mon tout nouveau blog des attaques par bruteforce, je pensais créer un bundle comme je l'avais fait pour symfony1 avec le sfAntiBruteForcePlugin. Puis, en montant mon serveur, je suis tombé sur un tutoriel qui utilise Fail2ban pour protéger notamment l'accès SSH des attaques par bruteforce. Pour information, le principe Fail2ban est d'observer des fichiers de log afin de détecter des activités anormales. Dans ce cas, par défaut, il bannit l'IP de la machine source pendant 10 minutes grâce à iptables et vous prévient par e-mail.

Il est possible d'ajouter des filtres personnalisés à Fail2ban, c'est ce que j'ai fait pour protéger la page de login de la zone d'administration de mon blog. Je vais vous expliquer comment.

Tout d'abord, il faut savoir où sont les logs d'accès à votre serveur web. J'utilise nginx, donc ils sont là : /var/log/nginx*/*access*.log.

Ensuite, il faut identifier ce qui se passe quand une tentative de login est effectuée. J'utilise le FOSUserBundle, donc il y a un POST qui est fait sur l'URL /login_check. Il est visible dans les logs sous la forme suivante :
1.2.3.4 - - [29/Aug/2012:11:36:30 +0200] "POST /login_check HTTP/1.1" 302 ...

Pas besoin de savoir si l'authentification a réussi ou non, on considère que si on atteint cette page X fois en moins de 10 minutes, c'est une attaque. On a donc toutes les informations nécessaires pour écrire notre filtre. Pour cela, il faut créer le fichier suivant : /etc/fail2ban/filter.d/nginx-login.conf.

# Blocks IPs that access to authenticate using web application's login page
# Scan access log for POST /login_check
[Definition]
failregex = <HOST> -.*POST /login_check
ignoreregex =

On voit donc bien qu'on surveille tous les POST effectués sur une URL commençant par "/login_check". Il ne reste plus qu'à modifier la configuration de Fail2ban pour utiliser ce filtre. Ajoutez ceci à la fin du fichier /etc/fail2ban/jail.conf :

[nginx-login]

enabled  = true
filter   = nginx-login
port     = http,https
logpath  = /var/log/nginx*/*access*.log
maxretry = 5

On indique donc les logs à surveiller, le filtre à utiliser et le nombre d'essais autorisés.

N'oubliez pas de recharger le service pour prendre en compte la nouvelle configuration : sudo service fail2ban force-reload. Vérifiez dans les logs que tout s'est bien passé : /var/log/fail2ban.log (il peut notamment vous dire que votre expression régulière est invalide). Testez ensuite de bruteforcer votre site (attention, vous allez être banni 10 minutes si ça se passe bien !).

Voilà, vous avez maintenant l'esprit tranquille !

Retour à l'accueil

Commentaires (4)

gravatar Par Antoine Descamps, le 29/08/2012 à 16:59
Brillant, GG.
gravatar Par Grégoire Marchal, le 29/08/2012 à 17:03
Merci :)
gravatar Par Christophe, le 30/08/2012 à 08:46
Intéressant, merci !
Et ça marche ? Je veux dire, tu vois dans les logs que tu as régulièrement des attaques par bruteforce ?
gravatar Par Grégoire Marchal, le 30/08/2012 à 09:12
Pour le blog, la seule attaque que j'ai eue depuis la mise en place (hier), c'était mon test.
Par contre en SSH j'en ai déjà eu 3 ou 4 en une semaine.

Commenter