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 !

Déterminer la version d’Apache

Suite à l’annonce récente de multiples vulnérabilités dans Apache server (CERTFR-2020-AVI-490), je souhaitais vérifier la version d’Apache installée. Vu que j’essaye à chaque fois un --version sans succès, voici pour référence, les deux commandes possibles (2e non testée).

 apachectl -v

Ou encore :

httpd -v

Apache, WordPress et redirections

Pour bien commencer l’année 2017, j’ai décidé de remettre le nez dans la configuration Apache du site. Lorsque j’avais installé WordPress pour créer Unicoda en 2012, j’avais renseigné les deux paramètres « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » dans les réglages généraux avec « http://www.unicoda.com ». Du côté de la conf Apache, j’avais indiqué que le serveur répondrai avec le contenu du WordPress pour unicoda.com et www.unicoda.com bien entendu.

Un beau jour, j’ai fini par remarquer qu’en tentant d’accéder au site via unicoda.com, j’étais redirigé vers www.unicoda.com. Cette redirection étant effectuée par WordPress lorsque celui-ci constate que l’url ne correspond pas à l’adresse configurée. Autant vous dire que celle-ci n’était pas des plus rapides. J’ai donc décidé en ce début d’année d’améliorer le processus de redirection en l’effectuant directement au niveau d’Apache.

En modifiant mes fichiers de configuration, j’ai donc ajouté une redirection de unicoda.com vers www.unicoda.com sur les deux protocoles http et https. Désormais, j’ai donc un virtualhost spécifique pour unicoda.com, en lieu et place d’une déclaration comme « ServerAlias » de www.unicoda.com dans un seul fichier de configuration. Le résultat est sans appel puisque la redirection prend désormais 100 ms environ alors qu’elle était de l’ordre de la seconde avant. Si je me base sur un test effectué via gtmetrix, on passe de 2,57 s à 325 ms, presque un facteur 8 (7,9) ! Le gain en rapidité n’est donc pas négligeable.

Pour ce qui est de la redirection http, la configuration est relativement simple :

<VirtualHost *:80>
    ServerName unicoda.com
    Redirect permanent / http://www.unicoda.com
</VirtualHost>

Et enfin, cerise sur le gâteau, l’opération s’est déroulé sans accro après rechargement de la nouvelle configuration par le processus Apache. En  somme, c’est donc une année 2017 qui commence plutôt bien.

[Apache] Redirection vers https

Exemple de redirection générale de http vers https avec Apache et mod_rewrite:

<VirtualHost *:80>
  RewriteEngine On
  RewriteCond %{SERVER_PORT} ^80$
  RewriteRule .* https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
</VirtualHost>
<VirtualHost *:443>
  # Configuration!
</VirtualHost>

Cette manière de rediriger me semble particulièrement intéressante dans le cas où l’on a besoin de déployer simplement une configuration Apache valable pour différents environnements ayant des noms de domaine différents. On évite ainsi d’avoir à définir explicitement l’url vers laquelle on redirige avec :

RedirectPermanent / https://demo.monprojet.org/

Avec la redirection par réécriture d’url, nous allons pouvoir déployer indifféremment le même fichier de configuration Apache sur les machines de pré-production, démo et test par exemple.

Le seul point qui pourrait poser problème concerne le certificat. Soit nous disposons d’un certificat wildcard valable sur tous les sous-domaines et dans ce cas là, cela devrait rester relativement simple. Dans le cas contraire, nous pourrions envisager de stocker les fichiers de certificats au même endroit et avec le même nom sur chaque machine.

  SSLEngine On
  SSLCertificateKeyFile /path/to/projet.key
  SSLCertificateFile /path/to/projet-cert.pem