Hey,

Aujourd’hui je vais vous raconter comment je suis arrivé à désengorger l’hébergement d’un site internet grâce à la fonction pare-feu de Cloudflare.

Contexte :

Un de mes amis possède un serveur Minecraft ainsi qu’un site internet pour sa communauté, mais ce dernier soufrait depuis déjà plusieurs semaines de gros ralentissements. C’est ainsi qu’il m’a demandé de l’aide dans un premier temps diagnostiquée les soucis de performances du site puis mis en placer les mesures adaptées afin que le site soi de nouveau fluide.

L’enquête :

Pour commencer, je suis allé faire un tour du côté de l’hébergement.

Le site internet est hébergé chez webstrator, un petit hébergeur français, et le nom de domaine est enregistré chez OVH. Suivant les fréquentations du site en question avec mon instance Matomo, (entre 100 et 300 visiteurs uniques) j’ai trouvé l’offre souscrite en adéquation avec le trafic, j’ai exclu la capacité de l’hébergeur en lui-même.

Ensuite, j’ai continué mon investigation en vérifiant les quelques paramètres modifiables sur le panel de l’hébergeur, rien d’anormal. La version de php était récente (7.3.8), l’hébergement en mode FPM. Puis je suis allé voir dans les logs ce qui se passait. Et là j’ai vite compris le problème.

Le CMS (CraftMyWebsite) utilisé sur le site possédait des fonctions pour recevoir les alertes de tickets ainsi que les sujets suivis sur le forum en temps réel. Le souci étant que chaque joueur avec un onglet ouvert sur le site envoyait deux requêtes toutes les cinq secondes pour garder ces indicateurs à jour.

Le site internet est surtout utilisé pour son système de vote permettant de gagner des récompenses toutes les heures. Les visiteurs ont pris pour habitude de garder la page ouverte en arrière-plan pour ne pas rater les récompenses.

Bilan, le site internet recevait des dizaines de requêtes non vitales à traiter par seconde ce qui le mettait régulièrement hors d’usage.

Résolution :

Et la suite me diriez-vous, déjà le gérant du site ne souhaite surtout pas quitter ce CMS, car trop d’informations à déplacer, recopier, etc… En réfléchissant un peu, j’ai eu deux idées.

Premièrement contacter un développeur du CMS pour lui demander de régler ce souci en réduisant le rythme de rafraîchissement des indicateurs puis le mis à jour une fois le patch disponible. Ou bien de trouver un moyen de bloquer ces requêtes avant qu’elles n’arrivent au serveur web.

Et c’est finalement cette solution que j’ai finie par adopter. Dans un premier temps j’ai faits passer les DNS du domaine par Cloudflare. Cette solution en ligne offrant une version gratuite particulièrement attrayante permet de se protéger des attaques par dénis de service, peut servir de pare-feu, sert de CDN, et bien d’autres fonctionnalités.

J’ai donc entrepris d’utiliser leur pare-feu applicatif pour bloquer ces requêtes. Elles prenaient la forme suivante :

POST /?&action=get_alerts HTTP/1.1 
POST /?&action=new_alert HTTP/1.1  
POST /?&action=get_signalement HTTP/1.1  

J’ai donc créé trois masques sur mesure afin de les identifiers puis choisit de les bloquer.

Masque pour identifier les requêtes inutiles

Et en version brute ça donne :

(http.request.uri.query contains "action=get_alerts" and  http.request.method eq "POST") or (http.request.uri.query contains  "action=get_signalement" and http.request.method eq "POST") or  (http.request.uri.query contains "action=new_alert" and  http.request.method eq "POST")

Une fois la règle activée, très rapidement le pare-feu de cloudflare a fini par encaisser ce trafic nuisible. Cela c’est vite vu en consultant les logs :

Logs du pare-feu de Cloudflare

En 24h, le pare-feu en encaisser plus de 73000 requêtes. Tu m’étonnes que le serveur web fût surchargé 😇.

Le complément :

Après que le serveur ne soit plus surchargé de demandes, j’en ai profité pour activer quelques modules de sécurité ainsi que quelques modules optimisations.

Concernant la sécurité j’ai activé la politique l’HSTS, les redirections vers le protocole HTTPS, et monté la version minimum de TLS à 1.2.

Pour la partie purement optimisation, j’ai commencé par activer les modules de minification, puis le module rocket loader.

Pour parfaire la configuration, j’ai créé deux règles. la première permet de demander au serveur de mettre en cache la plupart du site. La deuxième quant à elle augmente le niveau de sécurité sur la partie back-office et désactiver le cache.

Règles spécifique du site

Bilan :

Déjà, la solution que j’ai mise en place est une rustine. Elle fonctionne du côté serveur, mais les visiteurs envoient quand même des requêtes même si ces dernières sont bloquées par cloudflare, car cela génère du trafic inutile chez eux.

La vraie solution est bien évidemment que les développeurs règlent le souci, car ce n’est pas normal d’envoyer autant de requêtes. Donc non, à tous les collègues qui font du développement, envoyer des requêtes comme ça, ce n’est pas bien 😜.

Coder ce n’est pas si compliqué, par contre coder proprement et faire des programmes / scripts efficaces c’est nettement plus difficile. Donc codons bien pour le bien de tous.

J’ai eu l’occasion à travers cette expérience d’apprendre à manipuler le pare-feu de cloudflare. Il m’a fallu quelques heures histoire d’arriver à avoir un résultat convaincant mais ça en a valu la peine.

0 commentaires