Auteur Sujet: Le forum attaqué par des IP Free Pro le 19 octobre 2026 (Lu 5744 fois)

acut3 · « **Réponse #96 le:** **Hier** à 16:06:47 »

Citation de: alain_p le Hier à 15:59:02

Effectivement, l'IA Google dit que

C'est de la provoc c'est pas possible

alain_p · « **Réponse #97 le:** **Hier** à 16:34:33 »

Elle a interrogé le forum, c'est sûr

turold · « **Réponse #98 le:** **Hier** à 18:15:49 »

Même sans IA, c'est indiqué en français dans le forum communautaire FR de SMF:
https://www.smf-fr.com/discussion-generale/mise-a-jour-vers-la-version-2-1-8-de-smf/

Citer

Plusieurs corrections concernant les robots d'indexation basés sur l'IA.

Et dans le forum officiel de SMF:
https://www.simplemachines.org/community/index.php?topic=595147.0

Citer

Multiple fixes for AI crawlers

Mais il faut bien prendre la version 2.1.8 (ou plus récente selon la temporalité de la mise en prod ici).

Et le mode IA de Google Search, pour l'utiliser tout les jours, on peut lui demander la ou les sources.
Et quand ses sources ne disent pas ce qu'il dit, le lui faire remarquer.
On finit toujours par avoir les bonnes sources... Et rarement, l'IA lit mieux les sources que nous (bonjour les sites officiels de Microsoft qui ont l'air d'être rédigés par des avocats/juristes alors que ce sont juste des infos sur des fonctionnalités, sur Windows, ou sur un logiciel/framework de Microsoft).

alain_p · « **Réponse #99 le:** **Hier** à 19:05:36 »

Oui, l'IA Google fournit les sources, et donc on peut vérifier ce qu'elle dit. Mais comme tu dis, les sources sont souvent verbeuses, et l'IA Google en fait à mon avis une bonne synthèse et résumè, très bien rédigé. Je dois dire qu'elle me sert beaucoup. En espérant qu'elle ne devienne pas payante. Après, c'est pour éviter que nous allions plutôt sur ChatGPT ou consorts...

vivien · « **Réponse #100 le:** **Hier** à 21:27:24 »

Dans le top des user-agent, on a des user agent de vrais navigateurs Google Chrome, mais avec 0% d'IPv6.

Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/150.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 18_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/147.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 18_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/151.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 18_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/148.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (iPhone; CPU iPhone OS 18_2 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/149.0.0.0 Mobile/15E148 Safari/604.1
Mozilla/5.0 (Linux; Android 15; Pixel 9) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/151.0.0.0 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 15; CPH2653) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/149.0.0.0 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 15; SM-S938B) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/150.0.0.0 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 14; 23127PN0CC) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/147.0.0.0 Mobile Safari/537.36
Mozilla/5.0 (Linux; Android 14; Pixel 8 Pro) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/148.0.0.0 Mobile Safari/537.36

Citation de: vivien le Hier à 10:41:49

En filtrant sur ces user-agent, j'ai fait une analyse par IP avec à chaque fois l'AS associé et je tombe de haut.

On a des IPv4 qui sont presque toutes chez les 4 grands opérateurs français et quand je regarde les log sur une IP particulière, voici le trafic : 202610_log_ipv4_bouygues_etonante.txt

Ce sont des requêtes qui chargent des pages, presque toujours les mêmes, sans charger la moindre image et avec comme caractéristique le user-agent qui change à chaque requête.

Le user-agent change à chaque requête, avec un Chrome d'un iPhone ou d'un Android.
Quel est le but ? Les pages sont souvent les mêmes, donc ce n'est pas pour récupérer des données du site.

J'ai extrait une IPv4 en exemple, mais j'ai beaucoup d'IPv4 chez les 4 opérateurs qui ont ce comportement étrange qui semble typique de la volonté de faire du DDOS.

acut3 · « **Réponse #101 le:** **Hier** à 21:55:08 »

Citation de: vivien le Hier à 21:27:24

Ce sont des requêtes qui chargent des pages, presque toujours les mêmes, sans charger la moindre image et avec comme caractéristique le user-agent qui change à chaque requête.

Là encore une fois, on a toujours le problème des PHPSESSID insérés (incorrectement en plus) dans les URL : seulement 9 requêtes sans PHPSESSID, et 428 avec, avec à chaque fois un PHPSESSID différent (il n'y a pas une seule répétition).

Je pense qu'on a toujours le même problème : on des crawlers qui considèrent des URL identiques comme étant distinctes, parce qu'elles diffèrent par le PHPSESSID. Et même si c'est un bot "intelligent" qui cherche à ignorer le PHPSESSID, il ne peut pas le faire car il est ajouté de manière incorrect : on voit que dans chaque requête, il vient après un %3B au lieu d'un ? ou un &. Il n'est donc pas parsable comme un query parameter.

A mon avis c'est vraiment le problème n°1 du site concernant les bots.

kazyor · « **Réponse #102 le:** **Hier** à 22:16:22 »

- blacklist après analyse des logs
- whitelist pour IPv6 et les utilisateurs connectés (rule set dynamique)
- greylist avec rate limit pour le reste, par défaut, ou page de maintenance lorsque la charge >80%

Non ?

hwti · « **Réponse #103 le:** **Aujourd'hui** à 00:03:46 »

Le forum a été quasiment injoignable pendant plus d'une heure, et c'est revenu.
Un bot agressif s'est déclenché, et a fini par abandonner ?

EDIT: ça recommence

turold · « **Réponse #104 le:** **Aujourd'hui** à 00:09:08 »

Citation de: kazyor le Hier à 22:16:22

- blacklist après analyse des logs

C'est déjà le cas.

Citation de: kazyor le Hier à 22:16:22

- whitelist pour IPv6 et les utilisateurs connectés (rule set dynamique)

Des bots sont repérés en IPv6 dans ce forum.
Pour les utilisateurs connectés, même si Vivien ne m'a pas répondu quand j'avais remarqué publiquement une plus grande fluidité quand on est connecté, ben c'est encore le cas maintenant.. Entre 10k et 20k "visiteurs", beaucoup de lenteurs pour la moindre page en invité. Par contre, dès que je me suis connecté à mon compte, avec sensiblement le même nombre en "invités", c'est devenu très fluide pour moi.

Citation de: kazyor le Hier à 22:16:22

- greylist avec rate limit pour le reste, par défaut, ou page de maintenance lorsque la charge >80%

Il y a déjà une rate limit. Mais c'est par IP. Hors les bot et les DDoS utilisent beaucoup des centaines d'IP, voir beaucoup plus.
Et mettre une page de maintenance avant les 100%, c'est donner raison aux DDoS. On les ferait gagné à 80% de la charge, en interdisant à tout le monde l'accès... sic.

Leon · « **Réponse #105 le:** **Aujourd'hui** à 06:30:28 »

La situation devient critique, les temps de réponse se comptent en seconde (3, 4, 5 secondes).
Ca doit faire fuir les visiteurs humains, je pense.
On aimerait sauver notre forum. Tu as besoin d'aide Vivien?

Pourquoi ne pas prendre une solution temporaire de type CloudFlare, juste pendant 1 mois par exemple, le temps d'assainir le code du forum, d'upgrader le hardware, de faire la montée en version de SMF ?

Leon.

K-L · « **Réponse #106 le:** **Aujourd'hui** à 09:02:47 »

Pas de soucis ici, le site répond très rapidement à chaque fois que je le consulte.

vivien · « **Réponse #107 le:** **Aujourd'hui** à 09:09:08 »

Non, on a eu une très grosse charge de 22h à 9h (la charge a diminué suite à la mise en place de nouvelles règles de filtrage).

Aujourd'hui de nombreuses requêtes provenant d'IP très largement distribuées.

Les IPv4 (il y a aussi un peu d'IPv6) sont toutes hors de France.

Quelques AS concernées :
- AS63911   NetActuate, Inc   Royaume-Uni
- AS398781   OCULUS NETWORKS INC   États-Unis
- AS45102   Alibaba (US) Technology Co., Ltd.   Allemagne
- AS45102   Alibaba (US) Technology Co., Ltd.   États-Unis
- AS45102   Alibaba (US) Technology Co., Ltd.   Singapour
- AS45102   Alibaba (US) Technology Co., Ltd.   R.A.S. chinoise de Hong Kong
- AS45102   Alibaba (US) Technology Co., Ltd.   Japon
- AS45102   Alibaba (US) Technology Co., Ltd.   Malaisie
- AS42689   Glide Student & Residential Limited   Royaume-Uni
- AS11404   Wave Broadband   États-Unis
- AS37705   TOPNET   Tunisie

Citation de: acut3 le Hier à 21:55:08

Là encore une fois, on a toujours le problème des PHPSESSID insérés (incorrectement en plus) dans les URL : seulement 9 requêtes sans PHPSESSID, et 428 avec, avec à chaque fois un PHPSESSID différent (il n'y a pas une seule répétition).

Je pense qu'on a toujours le même problème : on des crawlers qui considèrent des URL identiques comme étant distinctes, parce qu'elles diffèrent par le PHPSESSID. Et même si c'est un bot "intelligent" qui cherche à ignorer le PHPSESSID, il ne peut pas le faire car il est ajouté de manière incorrect : on voit que dans chaque requête, il vient après un %3B au lieu d'un ? ou un &. Il n'est donc pas parsable comme un query parameter.

A mon avis c'est vraiment le problème n°1 du site concernant les bots.

Il faut voir que le problème des PHPSESSID insérés concent à 99,9% des robots. Le trafic des utilisateurs réel n'a presque jamais de problème de PHPSESSID.

J'ai hésite à filtrer automatiquement les IP avec un PHPSESSID dans la requete, mais il y a quelques cas où un utilisateur réel à un PHPSESSID (aprés avoir posté un message de mémoire).