Il va y avoir du ban !

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 !

De retour chez OVH

Article du samedi soir qui devrait rester court, simplement pour informer qu’Unicoda est de retour chez OVH depuis quelques heures. Cette fois, le serveur s’éloigne de moi de plusieurs centaines de kilomètres, alors qu’il était longtemps à moins de 15 kilomètres de mon domicile. Bref, retour en France, après un court passage chez Hetzner à Falkenstein en Allemagne. Tout a l’air de bien fonctionner. Vérification demain matin que le processus de sauvegarde quotidien s’est exécuté comme prévu et avec succès.

Au passage, j’en ai profité pour ajouter une sauvegarde distante supplémentaire. Le site est donc à présent sauvegardé vers deux services de stockage différents: Backblaze B2 (déjà évoqué ici) et désormais également dans le Cloud IBM. Je suivrai les sauvegardes vers ce nouveau dépôt dans les prochains jours afin de valider définitivement son bon fonctionnement.

J’ai profité de cette nouvelle migration pour jeter un œil du côté des logs Apache, pour la journée du 19 mars, en utilisant GoAccess, découvert pour l’occasion, et qui permet d’avoir quelques données agrégées directement accessible dans le terminal. Je note au passage l’option --ignore-crawlers permettant de filtrer les robots et autres bots. Difficile par contre de se faire une idée précise du nombre de lecteurs quotidiens, mais le flux RSS semble être appelé régulièrement: tant mieux !

C’est vraiment un point que je souhaite améliorer, à savoir la surveillance du serveur, en termes d’utilisation de ressources et d’analyse du trafic. Loin de moi l’idée de mettre en place du Google Analytics, mais quelque chose basé sur l’analyse des logs Apache devrait suffire et permettre, par exemple sur une durée d’un mois, de distinguer le trafic « réel », du trafic des bots, crawlers et autres spammers automatisés, et de savoir comment se comporte le serveur.

Pour finir, quelques données en vrac concernant les proportions de chaque système d’exploitation et les navigateurs pour cette journée du 19 mars. Pour les systèmes d’exploitation, je note environ (arrondi à la valeur inférieure):

  • 36% Windows
  • 25% GNU/Linux
  • 18% Android
  • 11% Macintosh
  • 1% iOS

Pour les navigateurs:

  • 37% Chrome
  • 26% Firefox
  • 19% Safari
  • 2% MSIE

Sur ces quelques chiffres, amis lecteurs, bonne nuit !