Salut à tous, je vous propose un nouveau TP sur fail2ban, xmlrpc & nginx. Ceux qui n’ont pas suivi ou qui débutent avec fail2ban sur WordPress devraient commencer par lire cet article qui fait parfaitement le boulot contre 99% des attaques. Néanmoins, ma supervision Splunk m’a permis de repérer une IP qui arrivait à contourner mes protections en créant des codes d’erreurs 499 sur le serveur web via des requêtes foireuses.
Vu que la fonctionnalité XMLRPC est désactivée sur le site, il y a peu de chance que celui-ci arrive à faire quoi que ce soit. Ce n’est pas une raison pour le laisser faire en saturant le serveur de requêtes inutiles…
Pour ceux qui ont lu mon article sur Splunk et Nginx, la requête Splunk qui m’a permis de générer le graphique pour cet article est la suivante :
index=nginx xmlrpc | timechart count by src
Fail2ban, xmlrpc et nginx
Pour votre culture, les protections en place ne fonctionnaient pas puisque la requête HTTP en code 499 n’arrivait jamais jusqu’à WordPress qui n’avait donc pas la chance d’écrire une ligne de log sur le sujet. Seul le serveur Web traitait la requête, pour rien donc.
Alors j’aurai pu bannir l’IP de l’attaquant « en dur » dans le firewall. Mais ce n’est ni élégant, ni efficace, car il suffit alors d’un changement d’IP source pour que l’attaque soit de nouveau efficace. Je me suis dit que c’était l’occasion de vous faire un TP sur l’écriture de règle fail2ban « sur mesure ».
Repérer les logs qui posent problème
La première étape, c’est bien de se rendre compte qu’il y a un problème, et pour ça Splunk : « il dépote sa mère » ! Comme vous le voyez sur le graphique qui illustre l’article. Pour les autres, vous pouvez toujours faire des greps dans vos /var/log/nginx, si ça vous amuse…
site="geekeries.org" server="51.15.9.16" dest_port="80" dest_ip="51.15.9.16" src="IPAttaquant" src_ip="IPAttaquant" user="-" time_local="12/Feb/2019:10:06:18 +0100" protocol="HTTP/1.0" status="499" bytes_out="0" bytes_in="0" http_referer="-" http_user_agent="Mozilla/4.0 (compatible: MSIE 7.0; Windows NT 6.0)" nginx_version="1.14.2" http_x_forwarded_for="-" http_x_header="-" uri_query="-" uri_path="/xmlrpc.php" http_method="POST" response_time="-" cookie="-" request_time="0.000"
Notez que le format de mes logs n’est pas celui classique de nginx mais bien celui que j’ai configuré dans nginx pour Splunk. Dans ce log, je vous ai mis en gras les éléments qui distinguent le comportement anormal.
Créer un filtre pour ces logs
Étape deux, préparer un filtre fail2ban, c’est-à-dire une expression régulière pour détecter ces logs. L’expression régulière exacte est la suivante (et je vous invite à aller faire un tour sur regex101 si vous avez un doute) :
^.src="(?[^\"])".uri_path="\/xmlrpc.php".$
On a plus qu’a l’intégrer dans un nouveau filtre pour fail2ban, en créant un fichier /etc/fail2ban/filter.d/nginx-xmlrpc.conf avec le contenu suivant :
# Fail2ban filter xmlrpc for nginx
[Definition]
failregex = ^.src="<HOST>".uri_path="\/xmlrpc.php".*$
ignoreregex =
Les plus attentifs auront remarqués que je ne filtre que sur les accès à xmlrpc.php, mais pas les status=499. Car le comportement anormal c’est bien les accès répétés à ce fichier, pas les codes d’erreurs HTTP.
Créer un jail pour ce filtre :
Il faut ensuite créer un jail dédié pour ce filtre. Pour cela, il suffit de créer un nouveau fichier nginx-xmlrpc.conf dans /etc/fail2ban/jail.d/ avec le contenu suivant.
[wordpress-nginx-xmlrpc]
enabled = true
filter = nginx-xmlrpc
logpath = /var/log/nginx/access.log
bantime = 2592000
maxretry = 6
port = http,https
La lecture de ce fichier de conf est assez limpide. Notez simplement que j’écrase les valeurs par défaut du bantime et du maxretry pour cette protection.
Activer la nouvelle règle
Enfin, un petit restart de fail2ban pour prendre en compte la nouvelle règle.
service fail2ban restart
Test
Après toute mise en production d’une nouvelle règle fail2ban, Je vous recommande vivement de :
- Tester son bon fonctionnement. Ici c’était plutôt facile, il suffisait de demander à une copain d’accéder 6 fois à l’url https://geekeries.org/ xmlrpc.php (merci Grégoire) et de « l’uban » après.
- Surveiller dans les jours qui suivent qu’elle ne génère pas de faux positifs et donc bannir des clients légitimes.
Et voilà, c’est tout pour aujourd’hui ,j’espère que vous avez compris la démarche générale pour créer vos propre règles fail2ban. Je trouve que cela illustre aussi l’importance d’une supervision que ce soit sur vos serveurs perso ou au boulot. Sans mes dashboards Splunk, je n’aurais probablement jamais repérée cette attaque que je pensais avoir déjà traitée.
Merci Splunk, vous m’offrez une licence entreprise sur le serveur pour la peine ? non ? tant pis…
