phpBB Lab

phpBB envahi par des milliers de robots : réduire la charge sans bloquer Google ni les vrais visiteurs

Votre forum phpBB affiche soudainement des centaines ou des milliers de visiteurs « invités » ?

Le serveur devient lent, MariaDB ou MySQL consomme beaucoup de ressources, la table des sessions grossit rapidement et certains utilisateurs commencent à rencontrer des erreurs 503, 504 ou des pages qui ne répondent plus ?

Vous consultez les statistiques de votre hébergeur et découvrez plusieurs millions de requêtes alors que votre communauté ne compte que quelques dizaines ou centaines de membres réellement actifs ?

Depuis quelques années, ce problème est devenu particulièrement fréquent avec :

• []les moteurs de recherche classiques ;
  []les crawlers SEO ;
  []les scrapers de contenu ;
  []les crawlers utilisés pour les moteurs d’intelligence artificielle ;
  []les outils d’archivage ;
  []les scanners automatisés ;
  []les robots ne respectant pas

  Code : Tout sélectionner

  robots.txt

  ;
  []les botnets utilisant des milliers d’adresses IP ;

• les robots qui se font passer pour Chrome, Safari ou Firefox.

Tous ces robots ne doivent pas être traités de la même manière.

Googlebot n’est pas équivalent à un scraper agressif.

Un crawler clairement identifiable n’est pas équivalent à un botnet utilisant de faux User-Agent.

Et surtout :

voir 3 000 invités dans « Qui est en ligne » ne signifie pas que 3 000 personnes lisent réellement votre forum.

L’objectif de ce guide est de comprendre ce qui se passe, identifier les robots responsables et réduire leur impact sans détruire votre référencement ni bloquer les utilisateurs légitimes.

1. Commencez par confirmer qu’il s’agit réellement de robots

Un nombre élevé d’invités peut être parfaitement légitime après :

• []la publication d’un lien très populaire ;
  []un passage dans les médias ;
  []une publication devenue virale ;
  []une forte actualité concernant votre communauté.

Il faut donc observer avant de bloquer.

Dans phpBB, ouvrez la page :

Qui est en ligne

puis affichez les invités lorsque cette possibilité est proposée.

Observez :

• []le nombre d’invités ;
  []les pages consultées ;
  []la répétition de certaines actions ;
  []les robots déjà reconnus par phpBB.

Si votre hébergement propose AWStats, Webalizer ou un autre analyseur de journaux, consultez-le également.

Sur un VPS, les logs du serveur Web constituent généralement la source la plus précise.

2. Le nombre d’invités peut être très trompeur

Imaginez un forum comptant normalement :

20 membres connectés
80 invités

Puis, sans événement particulier :

20 membres connectés
4 500 invités

et simultanément :

CPU : très élevé
MariaDB : très élevée
Forum : lent

Il est raisonnable de soupçonner une activité automatisée.

Mais le nombre affiché ne permet pas encore de savoir :

• []quel robot est responsable ;
  []s’il s’agit d’un robot légitime ;
  []s’il respecte

  Code : Tout sélectionner

  robots.txt

  ;
  []s’il accepte les cookies ;
  []s’il utilise un User-Agent identifiable ;
  []s’il change constamment d’adresse IP.

Il faut aller plus loin.

3. Comprendre la différence entre robot reconnu et invité

phpBB possède son propre système de gestion des robots.

Un robot correctement identifié peut être associé à un compte robot géré par phpBB.

Cela permet notamment à phpBB d’adapter son comportement.

Un robot reconnu peut bénéficier :

• []des permissions du groupe Robots ;
  []d’une navigation mieux adaptée à l’indexation ;
  []de liens inutiles retirés de certaines pages ;
  []d’une gestion des sessions différente d’un invité ordinaire.

Le problème devient plus important lorsqu’un crawler n’est pas reconnu.

phpBB peut alors le considérer comme un simple invité.

4. Pourquoi un robot non reconnu peut créer énormément de sessions

Un navigateur humain accepte généralement le cookie de session.

Il peut alors consulter :

Page 1
Page 2
Page 3
Page 4

avec la même session.

Certains crawlers ne conservent pas ce cookie correctement.

Le comportement peut alors ressembler à :

Requête 1 → nouvelle session
Requête 2 → nouvelle session
Requête 3 → nouvelle session
Requête 4 → nouvelle session
Requête 5 → nouvelle session

Imaginez maintenant :

100 requêtes par seconde

ou davantage.

La table des sessions peut grossir très rapidement.

Le problème n’est donc pas uniquement le nombre de pages téléchargées.

Le comportement du robot peut également provoquer beaucoup plus de travail côté PHP et base de données.

5. Vérifiez la table des sessions sans rien supprimer

Si vous avez accès à MariaDB ou MySQL, vous pouvez commencer par une simple lecture.

Avec le préfixe standard :

SELECT COUNT(*) FROM phpbb_sessions;

Cette requête ne supprime rien.

Notez le résultat.

Par exemple :

10h00 : 2 800 sessions
10h30 : 8 500 sessions
11h00 : 27 000 sessions
11h30 : 81 000 sessions

Une croissance aussi rapide sur un forum normalement calme mérite clairement une investigation.

Attention :

il n’existe pas un nombre universel de sessions considéré comme anormal.

Un très gros forum public peut naturellement avoir beaucoup plus de sessions qu’un forum privé de cinquante membres.

Ce qui compte surtout est :

• []l’activité habituelle ;
  []la vitesse de croissance ;
  []la charge générée ;
  []et le comportement observé dans les logs.

6. Ne videz pas phpbb_sessions comme solution permanente

Face à une table énorme, vous pourriez être tenté de la vider.

Même si un nettoyage ponctuel peut parfois faire disparaître temporairement un symptôme, cela ne bloque absolument pas les robots responsables.

Le scénario devient alors :

Table nettoyée
↓ Forum redevient rapide
↓
Bots continuent
↓
Table grossit à nouveau
↓
Forum ralentit à nouveau

Vous n’avez pas corrigé le problème.

Vous avez seulement remis le compteur à zéro.

La vraie question est : pourquoi autant de sessions sont-elles créées ?

7. Vérifiez également le cron

Une table de sessions qui augmente sans jamais redescendre peut avoir plusieurs causes.

Les robots peuvent être responsables de la création massive des sessions.

Mais leur nettoyage dépend également du fonctionnement normal des tâches périodiques de phpBB.

Vérifiez donc que vous n’avez pas activé l’exécution des tâches périodiques par le cron du système sans avoir réellement configuré ce cron sur le serveur.

Si vous disposez de SSH, vous pouvez effectuer un test manuel depuis la racine phpBB :

php bin/phpbbcli.php cron:run

Si le nombre de sessions chute fortement après cette exécution, vous avez peut-être deux problèmes simultanés :

• []une activité robotisée importante ;
  []et un nettoyage périodique qui ne s’exécutait plus correctement.

Ne confondez pas les deux.

8. Première action dans phpBB : identifier correctement les robots connus

Dans le PCA, phpBB possède une page consacrée aux robots et spiders.

Le libellé exact peut varier selon le pack de langue.

Vous y trouverez déjà plusieurs moteurs connus.

Un robot déclaré possède notamment :

• []un nom ;
  []une correspondance de User-Agent ;
  []éventuellement une correspondance IP ;
  []un compte associé.

Si vous identifiez un crawler légitime qui n’est pas présent dans votre installation, vous pouvez envisager de l’ajouter.

Cela ne bloque pas le robot.

Cela permet à phpBB de le reconnaître et de le traiter comme un robot plutôt que comme un invité ordinaire.

9. Comment fonctionne la correspondance du User-Agent ?

Le navigateur ou robot envoie généralement une chaîne appelée :

 User-Agent

Elle peut ressembler à :

Mozilla/5.0 …

ou contenir clairement le nom d’un crawler.

Dans la gestion des robots phpBB, la correspondance peut utiliser une partie caractéristique du User-Agent.

Il n’est donc généralement pas nécessaire de recopier une chaîne gigantesque lorsqu’une portion suffisamment distinctive permet d’identifier le robot.

Exemple conceptuel :

User-Agent complet :
Mozilla/… ExampleCrawler/2.1 …

Correspondance :
ExampleCrawler

Utilisez une valeur suffisamment précise.

Ne créez surtout pas une correspondance comme :

Mozilla

car vous risqueriez d’identifier comme robots une quantité énorme de navigateurs humains.

10. N’inventez pas les User-Agent des crawlers

Les noms et User-Agent évoluent.

Pour identifier correctement un moteur ou crawler connu, utilisez de préférence :

• []la documentation officielle du fournisseur ;
  []vos propres logs serveur ;

• une source technique fiable et récente.

Évitez les listes copiées depuis un vieux billet de blog publié dix ans plus tôt.

Un robot inexistant ne vous aide pas.

Et une correspondance trop large peut provoquer des effets indésirables.

11. Reconnaître un robot dans phpBB n’est pas le bloquer

C’est une distinction fondamentale.

Ajouter :

ExampleBot

dans la gestion des robots phpBB signifie essentiellement :

Lorsque ce User-Agent apparaît, phpBB doit reconnaître cette visite comme celle de ce robot.

Cela ne signifie pas :

Le serveur doit refuser sa connexion.

Vous pouvez ensuite utiliser les permissions du groupe Robots pour limiter ce qu’ils peuvent consulter.

Mais la requête atteint toujours votre serveur.

12. Utilisez les permissions des robots intelligemment

Tous les contenus publics n’ont pas nécessairement besoin d’être explorés par les moteurs.

Vous pouvez par exemple avoir :

• []des archives utiles pour Google ;
  []un forum général que vous souhaitez indexer ;
  []une section de discussions éphémères sans intérêt SEO ;
  []des pages techniques inutiles pour les moteurs.

Le groupe Robots peut recevoir des permissions différentes des simples invités.

Cela permet de réduire une partie du crawl inutile.

Mais souvenez-vous :

les permissions phpBB sont appliquées après que la requête a atteint phpBB.

Ce n’est donc pas la meilleure couche pour arrêter des millions de requêtes hostiles.

13. robots.txt : utile, mais ce n’est pas un pare-feu

Le fichier :

robots.txt

permet de donner des instructions aux crawlers qui acceptent de les respecter.

Il doit se trouver à la racine du domaine.

Par exemple :

https://example.com/robots.txt

Si votre forum est installé dans :

https://example.com/forum/

le fichier reste normalement :

https://example.com/robots.txt

et non :

https://example.com/forum/robots.txt

14. Exemple de robots.txt adapté à un forum installé dans /forum/

Voici une base qui peut éviter aux crawlers coopératifs de gaspiller des ressources sur plusieurs pages techniques.

User-agent: *

Disallow: /forum/adm/
Disallow: /forum/cron.php
Disallow: /forum/mcp.php
Disallow: /forum/memberlist.php
Disallow: /forum/posting.php
Disallow: /forum/report.php
Disallow: /forum/search.php
Disallow: /forum/ucp.php
Disallow: /forum/viewonline.php

Ne copiez pas aveuglément cet exemple.

Si votre forum est installé directement à la racine :

https://example.com/

les chemins deviennent différents.

Par exemple :

Disallow: /search.php

au lieu de :

Disallow: /forum/search.php

Adaptez toujours le fichier à votre propre installation.

15. Pourquoi empêcher le crawl de certaines pages techniques ?

Un moteur de recherche n’a généralement pas besoin d’indexer des milliers de variantes de :

posting.php
ucp.php
mcp.php
search.php
viewonline.php

Ces pages peuvent :

• []consommer des ressources ;
  []produire des URL sans intérêt pour le référencement ;

• augmenter inutilement le nombre de requêtes.

L’objectif n’est pas d’empêcher Google d’indexer vos sujets.

L’objectif est au contraire de concentrer son crawl sur les pages réellement utiles.

16. robots.txt n’arrête pas un robot malveillant

Un robot peut parfaitement faire :

GET /robots.txt

puis ignorer complètement son contenu.

Ou ne jamais consulter ce fichier.

Un botnet malveillant utilisant de faux User-Agent peut donc continuer à charger :

viewtopic.php
search.php
memberlist.php
ucp.php

des milliers de fois.

Retenez :

robots.txt = consignes
pare-feu / proxy / serveur = blocage réel

17. Évitez les énormes listes de bannissement IP dans phpBB

phpBB permet de bannir des adresses IP.

Cette fonction peut être utile pour un utilisateur problématique ou un nombre limité d’adresses.

Elle devient beaucoup moins adaptée à un botnet utilisant :

10 000 IP
50 000 IP
100 000 IP

Pourquoi ?

• []les adresses peuvent changer constamment ;
  []une adresse peut ensuite appartenir à un utilisateur innocent ;
  []une IP peut représenter de nombreux utilisateurs légitimes ;
  []phpBB doit quand même commencer à traiter la requête ;

• une liste gigantesque devient elle-même difficile à gérer.

Pour du trafic réellement hostile à grande échelle, bloquez plus haut dans la chaîne.

18. Bloquer le plus tôt possible

Imaginez cette chaîne :

Internet
↓
CDN / proxy éventuel
↓
Pare-feu
↓
Serveur Web
↓
PHP
↓
phpBB
↓
MariaDB / MySQL

Plus vous bloquez tard, plus le serveur a déjà effectué de travail.

Bloquer dans phpBB signifie généralement que :

serveur Web
PHP
phpBB

ont déjà été sollicités.

Bloquer au niveau du proxy ou du serveur Web permet d’éviter davantage de traitement.

19. Sur un hébergement mutualisé

Vous ne contrôlez probablement pas :

• []le pare-feu du serveur ;
  []Nginx ;
  []les règles réseau ;
  []fail2ban ;

• les limitations globales.

Vos possibilités peuvent alors être :

• []la gestion native des robots phpBB ;
  []

  Code : Tout sélectionner

  robots.txt

  ;
  []les fonctions proposées par l’hébergeur ;
  []certaines règles

  Code : Tout sélectionner

  .htaccess

  si Apache les autorise ;
  []un service proxy/CDN comme Cloudflare ;
  []une demande au support de l’hébergeur.

Si votre serveur mutualisé est réellement saturé par un botnet, contactez également l’hébergeur.

Il dispose de données et de moyens de filtrage auxquels votre compte n’a pas forcément accès.

20. Sur un VPS ou serveur dédié

Vous disposez de davantage de possibilités.

Vous pouvez agir au niveau :

• []du serveur Web ;
  []du pare-feu ;
  []du reverse proxy ;
  []du rate limiting ;
  []des journaux ;
  []de systèmes comme fail2ban ;

• d’un CDN ou proxy externe.

Mais ne commencez pas par bloquer des continents entiers parce que trois IP vous posent problème.

Analysez les logs avant de créer des règles importantes.

21. Trouver les IP qui génèrent le plus de requêtes

Sur un serveur utilisant un format de log classique, une commande de ce type peut donner une première indication :

awk ‘{print $1}’ access.log | sort | uniq -c | sort -nr | head -30

Le résultat peut ressembler à :

18500 192.0.2.10
12100 198.51.100.20
8300 203.0.113.30

Cela signifie simplement que ces adresses apparaissent énormément dans le fichier analysé.

Attention :

• []le format exact des logs peut varier ;
  []un reverse proxy peut masquer les véritables IP ;

• une IP très active n’est pas automatiquement malveillante.

22. Trouver les User-Agent les plus fréquents

Avec un format de log Apache « combined » classique, vous pouvez essayer :

awk -F’”’ ‘{print $6}’ access.log | sort | uniq -c | sort -nr | head -30

Vous pourrez éventuellement voir :

Googlebot
Applebot
ExampleCrawler
Mozilla/5.0 …

Les robots honnêtes s’identifient souvent clairement.

Les robots plus problématiques peuvent utiliser :

Mozilla/5.0
Chrome/…
Safari/…

comme s’ils étaient des utilisateurs humains.

23. Un User-Agent de navigateur ne prouve pas qu’il s’agit d’un humain

C’est devenu un point essentiel.

Un bot peut annoncer :

Mozilla/5.0 … Chrome/…

exactement comme un navigateur.

Vous ne pouvez donc pas décider :

Il indique Chrome, donc c’est forcément un humain.

Il faut corréler plusieurs éléments :

• []adresse IP ;
  []nombre de requêtes ;
  []fréquence ;
  []pages demandées ;
  []absence de cookies ;
  []comportement ;

• User-Agent.

24. Regardez les URL demandées

Un bot agressif révèle parfois son comportement par les URL parcourues.

Par exemple :

viewtopic.php?t=1
viewtopic.php?t=2
viewtopic.php?t=3
viewtopic.php?t=4
viewtopic.php?t=5

à un rythme très élevé.

Ou :

memberlist.php
search.php
ucp.php
posting.php
download/file.php

répétés des milliers de fois.

Un utilisateur humain ne consulte généralement pas plusieurs centaines de pages par seconde.

25. Les crawlers IA ne sont pas tous identiques

Le terme :

robot IA

recouvre des comportements différents.

Certains crawlers :

• []s’identifient ;
  []documentent leur User-Agent ;

• respectent les directives de crawl.

D’autres outils peuvent :

• []scraper sans identité claire ;
  []changer d’IP ;
  []utiliser un User-Agent de navigateur ;
  []ignorer

  Code : Tout sélectionner

  robots.txt

  .

Ne créez donc pas une règle disant :

Tout ce qui concerne l’intelligence artificielle doit être bloqué de la même manière.

Traitez le comportement réel.

26. Pensez au SEO avant de bloquer

Votre forum contient peut-être des années de discussions utiles.

Empêcher Google et les autres moteurs légitimes de consulter vos sujets peut faire disparaître progressivement une partie de votre trafic issu des recherches.

Évitez donc une réaction extrême comme :

User-agent: *
Disallow: /

si votre objectif est de conserver un forum public indexé.

Cette règle demande aux crawlers coopératifs de ne plus parcourir l’ensemble du site.

Elle peut être adaptée à un site que vous souhaitez réellement retirer des moteurs.

Elle ne constitue pas une solution normale contre un botnet malveillant.

27. Cloudflare peut aider, mais ce n’est pas une solution magique

Un proxy comme Cloudflare peut absorber ou filtrer une partie du trafic avant qu’il n’atteigne votre serveur.

Selon l’offre et les fonctionnalités disponibles, il peut proposer :

• []gestion des bots ;
  []règles personnalisées ;
  []challenges ;
  []rate limiting ;
  []protection contre certains trafics automatisés ;
  []mode d’urgence en cas d’attaque importante.

Cela peut être extrêmement efficace.

Mais une mauvaise configuration peut également provoquer :

• []des challenges excessifs ;
  []des difficultés de connexion ;
  []des utilisateurs légitimes bloqués ;
  []des problèmes de session ;
  []des erreurs de formulaire ;
  []des difficultés pour certains robots légitimes.

Procédez progressivement.

28. Le mode « Under Attack » doit rester une mesure d’urgence

Lors d’une attaque importante, un mode de protection renforcée peut être très utile pour rendre le site à nouveau accessible.

Mais si chaque visiteur doit résoudre un challenge régulièrement, l’expérience utilisateur se dégrade.

Le bon objectif est :

 Urgence
↓
Réduire immédiatement l’attaque
↓
Analyser le trafic
↓
Créer des règles plus précises
↓
Revenir à une protection normale

et non :

Under Attack activé pour toujours

29. Attention aux adresses IP derrière un proxy

Lorsque vous placez Cloudflare ou un autre reverse proxy devant phpBB, le serveur d’origine peut voir l’adresse IP du proxy au lieu de celle du visiteur.

Si cette situation n’est pas correctement gérée, plusieurs utilisateurs peuvent sembler provenir de la même adresse.

Cela peut perturber :

• []les journaux ;
  []les bannissements ;
  []les protections anti-abus ;
  []les validations de session ;
  []certains formulaires ;
  []les diagnostics.

Vérifiez donc, après l’installation d’un proxy, que phpBB et votre serveur disposent toujours correctement de l’IP réelle du visiteur.

30. Sur Apache et Nginx, restaurez l’IP réelle au bon niveau

Sur un serveur que vous administrez, la meilleure approche consiste généralement à restaurer l’adresse réelle au niveau du serveur Web.

Apache peut par exemple utiliser un mécanisme comme :

mod_remoteip

Nginx possède également des mécanismes permettant de traiter les en-têtes d’IP réelle.

Attention :

Ne faites jamais confiance aveuglément à un en-tête envoyé par n’importe quel visiteur.

Le serveur doit accepter l’information d’IP réelle uniquement lorsqu’elle provient réellement de vos proxies de confiance.

Sinon, un attaquant pourrait simplement falsifier cet en-tête.

31. Vérifiez phpBB après l’activation d’un proxy

Testez au minimum :

• []connexion ;
  []déconnexion ;
  []« Se souvenir de moi » ;
  []publication d’un message ;
  []formulaire du PCA ;
  []message privé ;

• formulaires utilisant un token.

Si les utilisateurs commencent immédiatement à rencontrer :

Le formulaire envoyé n’est pas valide

ou des déconnexions après l’installation du proxy, examinez la gestion des IP et des sessions avant de modifier phpBB au hasard.

32. Rate limiting : ralentir un comportement anormal

Un rate limiting permet de limiter le nombre de requêtes autorisées pendant une période donnée.

Exemple conceptuel :

Utilisateur normal :
1 à 5 requêtes par seconde

Bot agressif :
100 requêtes par seconde

Une règle peut alors intervenir sur le deuxième comportement.

Mais évitez une limite universelle extrêmement basse.

Un utilisateur peut légitimement déclencher plusieurs ressources lors du chargement d’une page.

Et une IP peut représenter plusieurs utilisateurs derrière :

• []un réseau d’entreprise ;
  []une école ;
  []un opérateur mobile ;
  []un NAT ;

• un VPN.

Testez les règles avant de les rendre trop strictes.

33. La fonction « Limiter les sessions » de phpBB

phpBB possède également un réglage permettant de définir une limite de création de sessions.

Lorsque le seuil prévu est dépassé, le forum peut devenir temporairement indisponible.

Cette fonction peut servir de filet de sécurité lorsque des robots provoquent énormément de nouvelles sessions.

Mais elle ne doit pas être confondue avec un système anti-bot.

Elle ne bloque pas réellement l’attaquant à la périphérie.

Elle peut simplement empêcher phpBB de continuer à absorber une charge excessive.

34. Ne choisissez pas une valeur de limite copiée sur un autre forum

Il n’existe pas une valeur universelle comme :

100
200
500

qui conviendrait à tous les forums.

Un petit forum recevant dix visiteurs simultanés n’a pas les mêmes besoins qu’une communauté accueillant des milliers de personnes.

Mesurez votre activité habituelle avant de modifier ce réglage.

Une limite trop basse peut rendre votre forum temporairement indisponible pour des visiteurs légitimes.

35. Surveillez également MariaDB ou MySQL

Lors d’une vague de robots, le problème n’est pas nécessairement le réseau.

Chaque page dynamique peut provoquer plusieurs requêtes SQL.

Vous pouvez donc observer :

Trafic HTTP élevé
↓
PHP très sollicité
↓
Requêtes SQL très nombreuses
↓
MariaDB/MySQL monte en CPU
↓
Forum ralentit

Le symptôme visible peut être :

MySQL utilise tout mon CPU.

alors que la cause initiale est :

Des milliers de robots chargent continuellement des pages phpBB.

36. Ne modifiez pas le cœur de phpBB pour réduire la charge

Lorsqu’un administrateur identifie une requête SQL exécutée fréquemment, il peut être tenté de modifier :

phpbb/session.php

ou un autre fichier du cœur.

Évitez cette méthode.

Une modification du cœur :

• []complique les mises à jour ;
  []peut introduire une régression ;
  []peut casser la gestion normale des utilisateurs ;
  []traite souvent le symptôme plutôt que la cause.

Commencez par :

• []identifier correctement les robots ;
  []réduire le crawl inutile ;

• filtrer le trafic abusif plus haut dans la chaîne.

37. Ne bloquez pas des pays entiers sans analyse

Un botnet peut utiliser des adresses provenant de nombreux pays.

Bloquer successivement :

Pays A
Pays B
Pays C
Pays D

peut finir par réduire énormément l’accessibilité de votre site sans arrêter le problème.

Les attaques modernes peuvent changer de réseau très rapidement.

Utilisez plutôt, lorsque c’est possible :

• []le comportement ;
  []la fréquence ;
  []le User-Agent lorsqu’il est fiable ;
  []la réputation du trafic ;

• des règles spécifiques.

38. N’oubliez pas les vrais moteurs de recherche

Googlebot, Bingbot et d’autres moteurs légitimes peuvent eux aussi effectuer beaucoup de requêtes.

Un moteur légitime peut momentanément crawler intensivement un forum très volumineux.

Avant de le bloquer, demandez-vous :

• []est-il correctement identifié dans phpBB ?
  []respecte-t-il mon

  Code : Tout sélectionner

  robots.txt

  ?
  []explore-t-il principalement des pages utiles ?
  []mon forum génère-t-il énormément d’URL inutiles ?

Optimiser le crawl peut être préférable à supprimer complètement l’indexation.

39. Pensez aux anciennes URL et aux espaces infinis de crawl

Un forum ancien peut avoir accumulé :

• []anciennes URL ;
  []paramètres ;
  []redirections ;
  []pages de recherche ;
  []variantes de session ;
  []liens vers des fonctions techniques.

Un crawler peut alors découvrir énormément d’URL différentes menant à des contenus très proches.

Cela gaspille :

• []votre bande passante ;
  []votre CPU ;

• le budget de crawl des moteurs.

Une bonne gestion des robots ne consiste donc pas seulement à bloquer.

Elle consiste également à leur présenter une structure propre.

40. Diagnostic type : 5 000 invités apparaissent soudainement

Imaginons :

Habituellement :
100 invités

Aujourd’hui :
5 000 invités

CPU :
95 %

phpBB_sessions :
augmentation très rapide

Procédez ainsi.

Étape 1

Consultez les invités et les logs.

Étape 2

Identifiez les User-Agent clairement déclarés.

Étape 3

Ajoutez dans phpBB les robots légitimes non reconnus.

Étape 4

Ajoutez des directives raisonnables dans

robots.txt

pour éviter les pages sans intérêt.

Étape 5

Cherchez les requêtes extrêmement fréquentes provenant de robots qui ignorent ces directives.

Étape 6

Filtrez ces comportements au niveau du serveur, de l’hébergeur ou du proxy.

Étape 7

Surveillez :

CPU
RAM
sessions
requêtes
bande passante
erreurs HTTP

et comparez.

41. Comment savoir si votre correction fonctionne ?

Ne vous contentez pas de :

Le forum me semble plus rapide.

Mesurez.

Avant :

Invités : 4 800
Sessions : 70 000
CPU : 90 % Requêtes : très élevées
Pages : lentes

Après :

Invités : 300
Sessions : 4 000
CPU : 25 %
Requêtes : normales
Pages : rapides

Ces mesures permettent de vérifier que votre action produit réellement un effet.

42. Attention aux faux positifs

Une règle trop agressive peut sembler excellente :

Trafic réduit de 95 %

mais avoir simultanément :

Googlebot bloqué
Membres derrière VPN bloqués
RSS bloqué
Applications mobiles bloquées

Ce n’est pas une réussite.

Après chaque nouvelle protection, vérifiez :

• []les utilisateurs normaux ;
  []les moteurs de recherche importants ;
  []les flux RSS si vous les utilisez ;
  []les connexions ;
  []les formulaires ;
  []les téléchargements ;

• le référencement.

43. Ce qu’il ne faut pas faire

Évitez notamment :

• []vider les sessions tous les jours comme unique solution ;
  []modifier le cœur de phpBB ;
  []ajouter des dizaines de milliers d’IP dans les bannissements phpBB ;
  []bloquer Google sans raison ;
  []mettre

  Code : Tout sélectionner

  Disallow: /

  sans comprendre son impact SEO ;
  []bloquer des continents entiers comme première réaction ;
  []faire confiance à n’importe quel en-tête d’IP réelle ;
  []activer un challenge sur chaque requête indéfiniment ;
  []changer quinze réglages simultanément ;
  []confondre robot reconnu et robot bloqué.

44. Informations à fournir lorsque vous demandez de l’aide

Indiquez :

Version phpBB :
Version PHP :
MariaDB/MySQL :
Mutualisé / VPS / dédié :
Apache / Nginx / autre :
Cloudflare ou autre proxy : oui/non

Précisez ensuite :

Nombre habituel d’invités :
Nombre actuel d’invités :
Nombre approximatif de sessions :
Charge CPU :
Début du problème :

Si possible, fournissez également :

• []les principaux User-Agent observés ;
  []les principales URL demandées ;
  []le nombre de requêtes ;
  []la bande passante ;
  []les erreurs HTTP observées ; []les changements récents de configuration.

Vous pouvez montrer quelques extraits de logs.

Mais ne publiez jamais :

• []mots de passe ;
  []cookies de session ;
  []clés privées ;
  []jetons API ;
  []identifiants SQL ;
  []informations secrètes de votre proxy.

45. Checklist de diagnostic

• []J’ai vérifié que le pic d’invités ne correspond pas à une vraie hausse de fréquentation.
  []J’ai consulté « Qui est en ligne ».
  []J’ai consulté les logs ou statistiques de l’hébergeur.
  []J’ai identifié les principaux User-Agent.
  []J’ai vérifié les robots déjà connus par phpBB.
  []J’ai ajouté les crawlers légitimes manquants lorsque nécessaire.
  []J’ai vérifié la croissance de

  Code : Tout sélectionner

  phpbb_sessions

  .
  []J’ai vérifié le fonctionnement du cron si les sessions ne sont jamais nettoyées.
  []J’ai examiné mon

  Code : Tout sélectionner

  robots.txt

  .
  []Je n’utilise pas

  Code : Tout sélectionner

  robots.txt

  comme s’il s’agissait d’un pare-feu.
  []Je n’ai pas rempli phpBB de milliers de bannissements IP.
  []J’ai identifié les URL les plus sollicitées.
  []J’ai vérifié CPU, base de données et bande passante.
  []J’ai privilégié un blocage en amont pour le trafic réellement hostile.
  []J’ai vérifié les vrais utilisateurs après chaque nouvelle règle.
  []J’ai vérifié les moteurs de recherche importants.
  []J’ai vérifié les connexions et formulaires après l’installation d’un proxy.
  []J’ai vérifié que l’adresse IP réelle est correctement restaurée derrière le proxy.

• Je n’ai pas modifié le cœur de phpBB.

À retenir

Des milliers d’« invités » sur phpBB ne correspondent pas nécessairement à des milliers de visiteurs humains.

Le problème peut provenir de crawlers qui :

chargent énormément de pages
↓
ne conservent pas les cookies
↓
créent énormément de sessions
↓
sollicitent PHP
↓
sollicitent MariaDB/MySQL
↓
saturent le serveur

La bonne stratégie consiste à agir par couches.

Identifier le trafic
↓
Reconnaître correctement les robots légitimes dans phpBB
↓
Réduire le crawl inutile avec robots.txt
↓
Utiliser les permissions lorsque pertinent
↓
Identifier les robots qui ignorent les consignes
↓
Bloquer ou limiter le trafic hostile plus haut dans la chaîne
↓
Mesurer le résultat

Retenez surtout :

robots.txt donne des consignes, il ne bloque pas un attaquant ;

la gestion des robots de phpBB permet de les reconnaître, elle ne constitue pas un pare-feu ;

vider la table des sessions ne règle pas la cause d’une invasion de bots ;

des milliers de bannissements IP dans phpBB ne constituent pas une stratégie adaptée à un botnet ;

et protéger votre serveur ne doit pas signifier détruire votre référencement ou empêcher vos membres de se connecter.

Le meilleur système n’est pas celui qui bloque le plus de monde.

C’est celui qui laisse passer les visiteurs et moteurs légitimes tout en empêchant le trafic automatisé abusif de monopoliser les ressources de votre forum.