TVradioZap.eu est hébergé par Alwaysdata.
Leur service répond parfaitement à mes attentes (et même au-delà) : environnement extrêmement complet, dernières versions de tout (php, mysql...), interface d'administration très claire, fiabilité et rapidité des accès... il ne m'avait fallu que quelques minutes pour la mise en place du site que je transférais depuis free.fr.

Alwaysdata m'a alerté le 20 juin que mon compte faisait trop de requêtes pour l’offre gratuite et que je risquais la suspension. Je n'ai vu leur message qu'avant-hier, et vu la faible notoriété du site ça m'a bien sûr très étonné. Comme je ne voudrais surtout pas avoir à changer d'hébergeur vu ma satisfaction de leurs services, je leur ai répondu que je ferai tout mon possible pour y remédier, et ils m'ont pointé vers les fichiers logs que leur service génère automatiquement.

Il s'est avéré que l'essentiel du surplus de requêtes vient de plages d'adresses IPV6 :  2a03:2880:*:*::face:b00c . Ces adresses appellent une page qui n'existe pas, elles contiennent une dizaine de répétitions d'une séquence de page valide.

J'ai aussitôt entrepris de bloquer ces adresses une par une dans le .htaccess à la racine du site. On frise actuellement les 200, mais ce palliatif aura été efficace.

Ce qui m'intéresse maintenant, c'est de savoir ce qu'on doit faire dans ce genre de cas. J'ai commencé l'enquête. D'abord, j'ai trouvé qu'au moins un autre webmaster a eu les mêmes déboires avec exactement les mêmes adresses IP et s'est renseigné sur la façon de les bloquer : https://webmasters.stackexchange.com/questions/144931/apache2-how-to-block-a-range-of-ipv6-addresses-in-htaccess

Ensuite si j'en crois ce site : abuseipdb.com..., ces plages d'adresses appartiendraient au domaine ldc.fr. Je ne vois pas pourquoi la profession de la volaille m'en voudrait, je n'ai rien contre les gallinacés. Leurs adresses seraient-elles détournées ?
Et si j'en crois celui-ci : myip.ms... ,  l'IP serait en Irlande. Ce site nous indique aussi une info intéressante, le "Browser Agent on this IPv6" : facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php). Dans mes fichers log, j'ai aussi retrouvé beaucoup de ces références à ce lien de facebook titré "Pourquoi Facebook apparaît-il dans les journaux de mon serveur  ?".

Toutefois si ces IP génèrent des actions malveillantes, elles peuvent très bien chercher à nous tromper par la référence à ce lien. Comme les requêtes ne viennent pas d'adresses chez facebook, tout cela reste en effet très suspect.
Exemple typique d'une telle requête extraite du fichier log d'Alwaysdata :

tvradiozap.eu 2a03:2880:13ff:3::face:b00c - - [26/Jun/2024:04:05:09 +0200] "GET /index.php/j/permalinks_/f/0/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u HTTP/2.0" 200 96136 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
A noter que quelques adresses IPV4 cherchent aussi à accéder à de tels liens à rallonge, mais sans référence à Facebook, et de façon non récurrente.
Donc ma question aux webmasters et aux férus des réseaux, est-ce que ces floppées de requêtes aberrantes peuvent avoir pour origine un dysfonctionnement, un paramétrage fait par un incompétent quelque part en lien avec Facebook ou pas, y compris moi dans la config du site, ou sont plus vraisemblablement le résultat d'une action malveillante ?

J'ai bien conscience de ça, mais le fichier log par lequel Alwaysdata me démontre la taille du trafic, n'inclut que les requêtes non bloquées par le htaccess. Je suis persuadé que la charge est considérablement diminuée après ce blocage, même si les requêtes arrivent toujours. La charge est surtout liée à l'exécution du php et au transfert des données, et là il n'y a plus rien. Je pense que c'est ce qui compte surtout pour Alwaysdata.

Mais bien sûr je leur ai fait la réponse que le blocage par htaccess n'était sans doute pas l'idéal et suggéré qu'ils ont peut-être de meilleurs outils à mettre en place.

C'est en rien une attaque.
Il fallait t'en douter : ton site circule et est partagé sur Facebook.

Ce dernier va sur ton site pour y récupérer des données (c'est comme ça qu'il intègre des apercus pour les liens).
Donc oui ça génère pas mal de lignes dans les access_log (j'ai aussi le cas dès que je poste une news par ex).
...

1) les requêtes ne viennent pas de facebook
2) les requêtes ne demandent aucune page valide

Et si tu lisais avant de répondre à tort et à travers ?

POURTANT JAY LU !!!


1)
Allez j'en remet encore :

Code: [Sélectionner]

$ whois 2a03:2880::
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://apps.db.ripe.net/docs/HTML-Terms-And-Conditions

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '2a03:2880::/40'

% Abuse contact for '2a03:2880::/40' is 'domain@fb.com'

inet6num:       2a03:2880::/40
netname:        PRN
country:        US
admin-c:        RD4299-RIPE
tech-c:         RD4299-RIPE
status:         ASSIGNED
mnt-by:         fb-neteng
mnt-by:         facebook-neteng
created:        2020-03-11T00:33:38Z
last-modified:  2020-03-11T00:33:38Z
source:         RIPE

role:           RIPE DBM
address:        1601 Willow Rd.
address:        Menlo Park, CA, 94025
admin-c:        NE1880-RIPE
tech-c:         NE1880-RIPE
nic-hdl:        RD4299-RIPE
mnt-by:         fb-neteng
created:        2011-04-11T18:49:50Z
last-modified:  2022-05-20T13:08:26Z
source:         RIPE # Filtered
abuse-mailbox:  domain@fb.com

% This query was served by the RIPE Database Query Service version 1.112.1 (SHETLAND)


2) Oui, j'ai aussi le cas

Bisous.

Alors comment expliques-tu ceci : https://www.abuseipdb.com/check/2a03:2880:27ff:8::face:b00c  (adresse chez ldc.fr)

et comment facebook pourrait récupérer des données à partir de requêtes pour des pages inexistantes ?

Tu ne réponds pas aux interrogations que j'ai présentées.

Si tu as eu le cas, tu serais plus constructif à nous dire comment tu l'as résolu.

Alors comment expliques-tu ceci :
https://www.abuseipdb.com/check/2a03:2880:27ff:8::face:b00c  (adresse chez ldc.fr)

Relis mon post, je t'ai mis un WHO-IS sur l'IP : elle est bien chez Facebook
Et la source est fiable.

P-ê qu'à un moment, LDC.fr a voulu faire confirmer son domaine chez Facebook (pour faire des trucs supplémentaires, genre achat de pub), leur serveur a vu les IP, les a reporté à AbuseIPDB, et ce dernier a retenu cette information depuis toujours, possible aussi.

Si tu as eu le cas, tu serais plus constructif à nous dire comment tu l'as résolu.

Oui volontiers

Je l'ai résolu grâce à un hébergeur qui n'a pas de ratelimit : Facebook peut taper dedans autant qu'il veut (car moi je souhaite que mes contenus soient partagés).

Sur LaFibre.info, j'ai malheureusement beaucoup de requêtes qui sont liés à des robots et qui se présentent comme étant des robots. C'est systématiquement la majorité du trafic (trafic en termes de requête, pas en Mb/s).

Si on rajoute les robots qui se présentent comme un navigateur web, on voit que le gros du trafic n'est pas généré par un humain.

Je n'ai pas cherché de solution spécifique, je ne bloque que quand le volume est trop important (déni de service).

Voici le nombre de requêtes par seconde sur LaFibre.info : (pas d'inquiète sur la baisse ces derniers jours, j'imagine que c'est le robot d'indexation de TikTok qui réduit ses demandes - il a la particularité de demander chaque élément, même les images, plusieurs fois, générant un nombre de hits fou, de plusieurs dizaines de requêtes par seconde et ce 24h/24).

Impressionnant. On se demande comment c'est possible que le système soit ainsi fait qu'il autorise des sociétés à le pourrir. L'impact écologique doit sûrement être énorme, en plus des nuisances aux utilisateurs par le ralentissement qu'induisent ces requêtes sur les réseaux et les serveurs.

Je n'ai identifié que 2 robots requêtant sur mon site, utilisés par semrush.com, que j'ai bloqué.

Par contre j'ai des requêtes depuis des adresses IPV4, qui sont tout à fait similaires à celles venant des plages IPV6 que j'ai citées, avec des liens vers page inexistante constitués des mêmes répétions. Par ex. depuis 37.57.218.243, 194.247.173.99, 65.108.110.26...
Je me demande si celles-là ne seraient pas une conséquence des autres.