Je disais il y de cela deux semaines, que j’avais profité du retour d’Unicoda chez OVH pour faire un tour du côté des logs du serveur. En continuant de creuser et d’analyser, l’intérêt de mettre en place un outil automatique, ou un processus d’analyse périodique, se fait clairement sentir.
En effet, en étudiant les résultats de l’agrégation des logs sur une dizaine de jours, je constate avec étonnement que l’url la plus demandée est xmlrpc.php. Pas de problème, la chose est connue, un ou plusieurs bots doivent encore être en train de s’amuser à essayer d’infiltrer la plateforme. En revanche, ce qui m’intrigue au plus haut point, c’est que le nombre d’appels soit si élevé, étant donné que je déploie systématiquement une configuration très agressive contre ceux qui spam les appels à cette page, à savoir ban IP d’une journée via fail2ban.
En allant regarder les logs de fail2ban, je constate que celui-ci se plaint de ne pas arriver à déterminer la date correcte d’un événement. Aie ! Les filtres fonctionnent correctement, mais la configuration n’est plus suffisante pour que le timestamp Apache du log soit bien compris par fail2ban. Après plusieurs essais, je décide d’en profiter pour mettre à jour fail2ban vers une version plus récente que celle fournie de base dans Debian 10, en suivant la procédure décrite sur cette page. Cela ne suffisant pas à résoudre le problème, je passe donc à la modification de mes filtres.
Pour protéger la page xmlrpc.php, j’obtiens finalement la configuration suivante:
[INCLUDES]
before = apache-common.conf
[Definition]
failregex = ^<HOST> -.* "(GET|POST|HEAD) /xmlrpc.php HTTP.*"
ignoreregex =
datepattern = ^[^[]*[({DATE})
{^LN-BEG}
En ce qui concerne la page de login, la mise à jour de la configuration nous donne le filtre ci-dessous.
[INCLUDES]
before = apache-common.conf
[Definition]
failregex = ^<HOST> -.* "(GET|POST|HEAD) /wp-login.php HTTP.*"
ignoreregex =
datepattern = ^[^\[]*\[({DATE})
{^LN-BEG}
Enfin, j’ai remarqué dans les logs qu’un bot testait des urls au pif, afin d’essayer de récupérer des éventuels fichiers de sauvegarde ou de configuration, à l’aide de requêtes HEAD qui terminent donc toutes en erreurs 404. J’en profite donc pour ajouter un nouveau filtre afin de traiter ce cas précis.
[INCLUDES]
before = apache-common.conf
[Definition]
failregex = ^<HOST> -.* "HEAD /.* HTTP.*" 404
ignoreregex =
datepattern = ^[^\[]*\[({DATE})
{^LN-BEG}
Après ces quelques modifications, mon fail2ban fonctionne à nouveau correctement et il est vraiment satisfaisant de voir les bots se faire bannir automatiquement en temps réel. Cela devrait également permettre de soulager un peu le serveur, en évitant qu’il traite du trafic non désiré.
Depuis combien de temps fail2ban ne fonctionnait plus correctement ? Aucune idée… Et c’est là que le manque de monitoring se fait doucement sentir. Rien qu’avec une agrégation des logs, j’aurais été en mesure de détecter l’augmentation du nombre d’appel tentant de trouver une faille. A une époque, je recevais un mail quotidien de fail2ban résumant le nombre d’IPs bloquées et d’autres métriques similaires, malheureusement, lorsque j’avais tenté de réactiver l’envoi, le mail se faisait systématiquement attraper par les filtres de l’hébergeur, car contenant ce qui était identifié comme des liens vers du contenu malfaisant (spam, piratages, etc).
L’année 2021 s’oriente donc vers la question du monitoring, longtemps laissée de côté, faute de temps, ou pour des questions de priorité. Affaire à suivre. Les mécanismes de blocage automatique des attaquants sont donc à nouveau en place sur Unicoda et en totalité depuis le week-end dernier. Une bonne chose de faite, et qui ne devrait en aucun cas impacter les lecteurs !