La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
alwaysdata => Discussion démarrée par: F6FLT le 27 juin 2024 à 11:16:50
-
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... (https://www.abuseipdb.com/check/2a03:2880:27ff:8::face:b00c), 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... (https://myip.ms/view/comp_ip6/4271653/2a03:2880:27ff:b::face:b00c) , 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 (http://www.facebook.com/externalhit_uatext.php) 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 ?
-
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 ?
Sachant que de toute facon tu ne peux rien y faire.
Le .htaccess ne fait que bloquer le traitement PHP de la requete (donc tu economises du cpu, de la bdd, etc.), mais la requete est quand meme arrivée sur le serveur et apache/nginx l'a gerée.
Je n'ai jamais utilisé de ce genre de services web managé mais j'imagine que ce qui compte pour eux c'est le nombre de requete web recues, quelque soit ce que tu en fait derriere...
-
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).
Si tu ne veux plus être emmerdé : passe ton site en privé (il est pour ton usage perso, donc ça devrait le faire).
Car tant qu'il reste public, tu auras le problème (p-ê plus de facebook, mais d'autres, ce sera sans fin)
Enfin, c'est pas très malin, mais tu viens de dévoiler publiquement que ton site est vulnérable au moindre frétillement de trafic.
-
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) les requêtes ne viennent pas de facebook
2) les requêtes ne contiennent aucune page valide
Et si tu lisais avant de répondre ?
1)
Il s'est avéré que l'essentiel du surplus de requêtes vient de plages d'adresses IPV6 : 2a03:2880:*:*::face:b00c .
Allez j'en remet encore :
$ 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 :) Toi aussi, relis bien mes propos avec moi :
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)
Bisous.
-
POURTANT JAY LU !!!
1)
Allez j'en remet encore :
$ 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.
-
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).
-
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).
-
...
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).
C'est un palliatif, pas une résolution.
...
(car moi je souhaite que mes contenus soient partagés).
tandis que moi, je souhaite qu'ils ne le soient pas ::)
Et moi qui espérait de l'intelligence pour la résolution de ce problème...
C'est en rien une attaque.
Il fallait t'en douter : ton site circule et est partagé sur Facebook.
Ben leur réussite, ce n'est pas flagrant, une seule association facebook/tvradiozap sur Google, et ce n'est pas chez facebook :
-
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.
-
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.
Tu n'aurais pas pris une offre Always-Data gratuite par hasard? Si c'est le cas, tu ne peux évidemment rien négocier avec eux.
Pour un site qui monte en popularité, tu as tout intérêt à migrer sur un hébergement de qualité. N'hésites pas à questionner Always-data pour leur demander si les offres payantes/plus chère acceptent un nombre de requêtes plus élevé.
Leon.
-
Ben leur réussite, ce n'est pas flagrant, une seule association facebook/tvradiozap sur Google, et ce n'est pas chez facebook :
Il est de notoriété publique que facebook a des mécanismes d'anti crawling qui ne rendent pas ce genre de recherche pertinente.
-
Ben leur réussite, ce n'est pas flagrant, une seule association facebook/tvradiozap sur Google, et ce n'est pas chez facebook :
Un mec qui cherche un contenu partagé sur Facebook... sur Google. ::)
Je remets ça ici :
Et moi qui espérait de l'intelligence pour la résolution de ce problème...
Il est de notoriété publique que facebook a des mécanismes d'anti crawling qui ne rendent pas ce genre de recherche pertinente.
+1
Autant chercher le contenu partagé sur facebook... sur facebook non ? Je sais pas, ça me parait logique. (à moins que je ne suis pas intelligent).
-
...
Autant chercher le contenu partagé sur facebook... sur facebook non ? Je sais pas, ça me parait logique.
On t'attend.
Perso, je n'ai pas de compte facebook.
(à moins que je ne suis pas intelligent)
L'intelligence manquait certainement dans ton sous-entendu "(car moi je souhaite que mes contenus soient partagés)". Mais je ne me permettrais pas de généraliser à la personne, chacun peut s'en faire une idée.
-
Tu n'aurais pas pris une offre Always-Data gratuite par hasard? Si c'est le cas, tu ne peux évidemment rien négocier avec eux.
Pour un site qui monte en popularité, tu as tout intérêt à migrer sur un hébergement de qualité. N'hésites pas à questionner Always-data pour leur demander si les offres payantes/plus chère acceptent un nombre de requêtes plus élevé.
Leon.
Bien sûr que je suis dans le cas du gratuit, comme l'est l'usage de mon site sans but lucratif, et donc j'accepte les clauses du contrat.
Je ne demande à personne d'offrir des hébergements gratuits, mais seulement à ceux qui le proposent (et s'ils le font, ce n'est pas innocent), d'assumer ensuite leurs engagements.
Un hébergeur aujourd'hui, comme l'a indiqué Vivien, semble être soumis à des tirs d'artillerie de requêtes venant de robots, ça semble être la normalité du contexte actuel.
Il est clair que si le problème de l'excès de requêtes ne vient pas du trop grand nombre d'utilisateurs du site, ni de défauts de conception, ni d'utilisation anormale d'outils PHP ou autres, mais de robots que tout site a à subir, la balle est dans le camp d'Alwaysdata. S'ils n'étaient pas en mesure de tenir la charge ou d'avoir des moyens de défense pour assumer l'hébergement normal de sites gratuits dans le contexte actuel, pourquoi le proposent-ils ?
L'idée qu'ils pourraient le faire pour amener des gens à s'installer chez eux, puis à leur forcer la main pour prendre un abonnement payant en prétextant qu'il y a trop de trafic, je la vois sous-jacente dans ce que tu viens de nous dire.
Si je devais prendre un abonnement payant dans ces conditions, ce ne serait pas chez eux : s'ils ne tenaient pas leurs engagements sur le gratuit dans le cadre qu'ils ont fixé, alors on ne peut pas leur faire confiance, même pour le payant, or la confiance est aujourd'hui la clé si on doit s'inféoder à un service, en tout cas pour moi.
Je n'ai maintenant aucun élément dans ce sens, l'avenir le dira peut-être, par exemple s'ils suspendent mon compte malgré les mesures prises et le peu de trafic réel du site.
-
Et moi qui espérait de l'intelligence pour la résolution de ce problème...
Le seul proboleme dans ce que tu decris c'est que tu heberges sur une offre gratuite et que evidement ils ne peuvent pas te laisser faire un trafic important...
-
Le seul proboleme dans ce que tu decris c'est que tu heberges sur une offre gratuite et que evidement ils ne peuvent pas te laisser faire un trafic important...
C'est ce que je dis : le trafic des utilisateurs n'est pas important, contrairement à celui créé par facebook, robots et assimilés, mais celui-là est général, pas spécifique de mon site, il fait partie d'un contexte normal d'utilisation de n'importe quel site.
Actuellement environ 95% des requêtes ne viennent pas d'utilisateurs et concernent des pages qui n'existent pas. Je pense que c'est anormal et temporaire, qu'il y a eu un déclencheur peut être lié aux trafic des adresses IPV6 citées. Je continue à bloquer tout ce qui semble venir de robots, exemple :
188.165.212.137 - /index.php/ty/tv/f/2/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv
Le trafic des derniers jours, je n'ai que ce tableau dans les stats. Ce n'est quand même pas l'overdose :
-
Actuellement environ 95% des requêtes ne viennent pas d'utilisateurs et concernent des pages qui n'existent pas. Je pense que c'est anormal et temporaire, qu'il y a eu un déclencheur peut être lié aux trafic des adresses IPV6 citées. Je continue à bloquer tout ce qui semble venir de robots, exemple :
188.165.212.137 - /index.php/ty/tv/f/2/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv
Tu n'as toujours pas compris (ou tu refuses de l'admettre) que ce problème ne fera que s'accentuer.
Comme je l'ai déjà dit, tu dis ici, en public, que ton site est vulnérable dès qu'il y a du trafic. Forcément, des malins vont amplifier le problème, et en plus, on voit que ça te fait réagir. Donc on sait que ça fait mouche dans la vie de françois, pourquoi pas en profiter pour le faire chier ? Tu comprends ?
1) soit tu poursuis ta méthode de traiter au cas par cas (mais tu perds plus de temps à faire ça qu'à développer ton site, en plus du temps de poster ici, c'est contre-productif)
2) soit tu bloques ton site avec login/pass pour ton utilisation perso, c'est radical. Mais vu que tu as déjà posté sur plein de forums, j'imagine que ce n'est pas la solution souhaitée
3) soit tu y vas franchement, tu crois en ton projet, lance-toi, tu te payes un hébergement payant qui tient la route
Car des ptits glands qui vont bourriner le site, tu en auras toujours. Moi aussi je me prends des douches. Vivien aussi.
-
L'hébergeur s'en fiche de savoir qui génère le trafic. Il regarde juste ce que tu consommes en ressources.
C'est la même chose pour les hébergements pas chers mutualisés chez OVH : Si ton site est un peu lourd (par exemple un forum), ils te font vite comprendre qu'il faut passer à l'offre supérieure.
Chez Online, dans le vieux temps (il y a 20 ans), il n'y avait vraiment pas de limite pour l'hébergement mutualisé (c'est une offre payant, mais trop cher), mais ils mettaient tous les clients qui consomment beaucoup de ressource sur un même serveur, comme, car ils ne dégradaient pas le service de 95% des autres clients. Les clients gros consommateur partaient donc d'eux-mêmes vu que leur site était extrêmement lent.
-
Il faudrait que tu prennes un CDN payant.
Genre Fastly ou CloudFlare.
Attention, si tu payes pas, CF te jettera.
-
Il faudrait que tu prennes un CDN payant.
Genre Fastly ou CloudFlare.
Attention, si tu payes pas, CF te jettera.
Oui, ça me semble les solutions d'avenir. J'aurais un site commercial, c'est ce que je ferais.
Mais tvradiozap est un hobby, j'en ai d'autres, et pas un site grand-public capable d'attirer les foules. Je prends le gratuit par rapport au besoin, et par gain de temps et conservation d'une certaine liberté, plus que par économie.
Je serais bien resté chez free.fr qui ne m'a jamais cassé les pieds pour des questions de nombre de requêtes, mais sans https aujourd'hui, il n'est plus dans les clous pour les pages perso.
-
L'hébergeur s'en fiche de savoir qui génère le trafic. Il regarde juste ce que tu consommes en ressources.
C'est la même chose pour les hébergements pas chers mutualisés chez OVH : Si ton site est un peu lourd (par exemple un forum), ils te font vite comprendre qu'il faut passer à l'offre supérieure.
Tout site sera forcément connu des robots tôt ou tard, donc s'ils ne savent pas fournir les "ressources" pour héberger un site gratuitement dans le contexte de l'Internet d'aujourd'hui, qu'ils ne proposent pas d'hébergement gratuit.
Encore une fois, je ne demande à personne de fournir du gratuit, seulement à ceux qui le fournissent d'assumer ensuite leurs engagements. Mon site est peu utilisé et tourne dans un contexte normal d'utilisation du réseau Internet. Ils ne peuvent pas dire qu'ils ignorent ce contexte, notamment des requêtes par robots, ils le connaissent, ou alors ce ne seraient plus des pros.
Si je suis restaurateur et que j'affiche "menu gratuit", attire le gogo pour quelques repas, pour ensuite dire "la nourriture à un coût alors vous vous barrez ou vous prenez mon menu payant", j'affirme qu'il y a un problème de principe. C'est tout simplement une arnaque.
Chez Online, dans le vieux temps (il y a 20 ans), il n'y avait vraiment pas de limite pour l'hébergement mutualisé (c'est une offre payant, mais trop cher), mais ils mettaient tous les clients qui consomment beaucoup de ressource sur un même serveur, comme, car ils ne dégradaient pas le service de 95% des autres clients. Les clients gros consommateur partaient donc d'eux-mêmes vu que leur site était extrêmement lent.
Faire de la gratuité avec limitation intelligente des ressources, c'est à dire en plafonnant les ressources des uns quand ils commencent à empiéter sur celles des autres, est tout à fait acceptable, si c'est annoncé au départ et fait honnêtement (c'est à dire pas avec un serveur tournant sur un i386 avec une connexion à 1 Mb/s).
-
Tout site sera forcément connu des robots tôt ou tard, donc s'ils ne savent pas fournir les "ressources" pour héberger un site gratuitement dans le contexte de l'Internet d'aujourd'hui, qu'ils ne proposent pas d'hébergement gratuit.
Encore une fois, je ne demande à personne de fournir du gratuit, seulement à ceux qui le fournissent d'assumer ensuite leurs engagements. Mon site est peu utilisé et tourne dans un contexte normal d'utilisation du réseau Internet. Ils ne peuvent pas dire qu'ils ignorent ce contexte, notamment des requêtes par robots, ils le connaissent, ou alors ce ne seraient plus des pros.
Si je suis restaurateur et que j'affiche "menu gratuit", attire le gogo pour quelques repas, pour ensuite dire "la nourriture à un coût alors vous vous barrez ou vous prenez mon menu payant", j'affirme qu'il y a un problème de principe. C'est tout simplement une arnaque.
Faire de la gratuité avec limitation intelligente des ressources, c'est à dire en plafonnant les ressources des uns quand ils commencent à empiéter sur celles des autres, est tout à fait acceptable, si c'est annoncé au départ et fait honnêtement (c'est à dire pas avec un serveur tournant sur un i386 avec une connexion à 1 Mb/s).
Juste, c'est quoi le modele économique de un hébergement gratuit ? :o
-
...
Comme je l'ai déjà dit, tu dis ici, en public, que ton site est vulnérable dès qu'il y a du trafic. Forcément, des malins vont amplifier le problème
...
Quels "malins" ? Facebook ? Amazon ? Parce que les seuls qui posent problème actuellement, ce sont eux.
Tu n'as encore rien lu de ce qui était écrit. Ou alors tu ne crois plus à facebook que tu nous disais être à l'origine du flooding en IPV6 ?!
Le surplus de trafic est celui appelant des adresses inexistantes formées comme dans l'encart plus haut, et uniquement celles-là.
Tout le surplus de trafic concerne uniquement ces requêtes, avec répétition de séquences, toutes les mêmes à de petites variations près.
On n'est absolument pas dans le cas de "malins" mais de robots bornés qui, pour une raison que j'ignore, utilisent ces adresses et tous, utilisent les mêmes comme s'ils relayaient une source initiale.
Pourquoi ces requêtes erronées ? Pourquoi toutes les mêmes quelque soit le serveur qui fait les requêtes, ce sont les questions intelligentes à se poser, par rapport à un problème précis
Et en attendant j'ai bien fait de bloquer une par une ces IP, car le trafic a été considérablement réduit. Un peu de pragmatisme ! Tes poncifs sur le sujet n'apportent rien.
-
Juste, c'est quoi le modele économique de un hébergement gratuit ? :o
De faire essayer et de vendre du payant ensuite.
-
as tu essayé de regarder du côté des instructions dans le robots.txt ? ça ne coûte pas grand chose de le tester au regard d'ajouter des IPs 1 par 1 dans le .htaccess.
En cherchant rapidement sur google, il y a des propositions..
https://developers.facebook.com/docs/sharing/bot/
Je te laisse chercher pour les autres robots ;)
-
Heureusement que je suis là pour donner des pistes ::)
https://datadome.co/fr/recherche-de-menace/comment-facebook-a-ete-exploite-comme-un-proxy-par-des-bots-de-scraping/
https://www.c2script.com/scripts/bloquer-les-faux-partages-facebook-venant-de-facebookexternalhit-s66.html
Juste avec "facebookexternalhit" dans Google :P
-
Juste, c'est quoi le modele économique de un hébergement gratuit ? :o
Il faut le demander à celui qui le propose.
Je lui fais confiance. S'il propose un hébergement gratuit, c'est qu'il y trouve son compte. Donc je suis content de répondre positivement à sa proposition :D.
Par contre si la réalité n'est pas à la hauteur de la promesse, possible qu'il m'entende, et ce sera à la hauteur de mon allergie aux margoulins.
-
@ buddy et XP25
Vos liens sont très instructifs, et expliqueraient le contexte des requêtes depuis les adresses IPV6, notamment celles avec les références à facebook. Les adresses IPV6 seraient bien manipulées par des indélicats...
Les questions qu'il me reste, c'est d'une part :
- l'étrangeté des requêtes, avec les séquences répétées, qui ne peuvent recevoir que la page d'accueil envoyée dans la plupart des cas d'adresse erronée, plutôt qu'une erreur 404.
- la reprise de ces mêmes requêtes par d'autres sites depuis des adresses IPV4, notamment Amazon (4 IP), OVH France et Québec (5 IP), semrush.com (3 IP), et quelques autres.
Pour compléter le dossier :
1) Au lien facebook fourni par les bots http://www.facebook.com/externalhit_uatext.php, il y a une adresse de contact legal@facebook.com que j'ai utilisée pour leur communiquer le problème. Aucune réponse à ce jour.
2) Hier j'ai communiqué à Alwaysdata un point sur l’origine du problème et les actions que j'ai effectuées pour le résoudre. Je viens de voir que ce matin j'ai reçu un "Merci" de Nicolas G, j'ose espérer que cela termine l'incident, auquel cas je les en remercie.
En tout cas ces bots m'agacent et je compte continuer à les bloquer. Si qqn était au courant d'une limitation du nombre d'IP dans la liste des deny du .htaccess, je suis preneur, merci. Pour le moment cette liste est encore loin d'avoir la taille de celles des TV et Radios de TVradioZap, donc je dois pouvoir gérer. :)
-
2) Hier j'ai communiqué à Alwaysdata un point sur l’origine du problème et les actions que j'ai effectuées pour le résoudre. Je viens de voir que ce matin j'ai reçu un "Merci" de Nicolas G, j'ose espérer que cela termine l'incident, auquel cas je les en remercie.
En tout cas ces bots m'agacent et je compte continuer à les bloquer. Si qqn était au courant d'une limitation du nombre d'IP dans la liste des deny du .htaccess, je suis preneur, merci. Pour le moment cette liste est encore loin d'avoir la taille de celles des TV et Radios de TVradioZap, donc je dois pouvoir gérer. :)
Je ne crois pas que tu aies une limite, par contre, ça va ralentir/ demander plus de ressources au fur et à mesure ...
Je te conseille vivement de créer le fichier robots.txt quand même ... limitant/bloquant les robots de facebook et autres.
(il a l'air vide)
http://tvradiozap.eu/robots.txt
Son impact ne sera visible qu'après plusieurs heures/jours, le temps que les robots le voit ..
-
Bon, l'histoire continue. J'ai testé le fichier robots.txt. Il n'est pas respecté par les principales adresses qui font du flooding, notamment facebook, semrush, et amazon. J'ai eu le malheur de vouloir le vérifier hier avec des adresses d'Amazon. Ca confirmerait que ces adresses sont détournées d'une façon ou d'une autre mais n'empêche, elles appartiennent bien à ces services.
J'étais rendu à 260 adresses facebook bloquées. Finalement j'ai bloqué toute la plage, un seule ligne suffit dans le .htaccess, ce sera moins lourd pour Apache et Alwaysdata.
Les adresses des ripoux ou utilisés par des ripoux sont les suivantes :
#facebook
deny from 2a03:2880::/32
#fbsv.net (Facebook IPV4, fwdproxy-cco-001.fbsv.net)
deny from 69.171.230
deny from 173.252.83
#Amazon
deny from 3.224.220.101
deny from 23.22.35.162
deny from 52.70.240.171
#semrush.com
deny from 85.208.96
deny from 185.191.171
deny from 185.170.167.18
On se demande comment c'est possible de nos jours. Prenons par exemple l'adresse 3.224.220.101 chez Amazon. Elle est répertoriée comme étant "100% abuse" : https://www.abuseipdb.com/check/3.224.220.101. Il y a 181 pages de listes de sites de webmasters qui ont remonté le problème, mais elle est toujours vivante ! Leurs deux autres adresses, pareil. Les 3 groupes d'adresses chez Semrush, pareil. Et à côté de ça tu as (avais) l'Hadopi sur le dos si tu avais le malheur de télécharger "Le Gorille" de Brassens, de 1952.
La protection sur Internet, c'est celle pour que les gros groupes soient à leur aise, et celle du citoyen, seulement pour lui éviter d'être perturbé quand il fait ses achats, ce ne serait pas bon pour le business des premiers.
-
Bon, l'histoire continue. J'ai testé le fichier robots.txt. Il n'est pas respecté par les principales adresses qui font du flooding, notamment facebook, semrush, et amazon.
Comme j'ai dit, il faut parfois plusieurs jours avant qu'ils ne voient et interpretent et respectent le robots.txt ... tu ne verras son potentiel effet qu'en milieu de semaine prochaine je pense. (bon après, il ne mange pas de pain... vaut mieux l'avoir que rien.)
-
Comme j'ai dit, il faut parfois plusieurs jours avant qu'ils ne voient et interpretent et respectent le robots.txt ... tu ne verras son potentiel effet qu'en milieu de semaine prochaine je pense. (bon après, il ne mange pas de pain... vaut mieux l'avoir que rien.)
Les robots scrawlent tout (en fait n'importe quoi car les adresses ne correspondent à rien d'existant sur le site) avant de charger le fichier robots.txt, plutôt que de le lire systématiquement avant d'engager leurs nuisances.
Là je suis coincé. Si je les débloque j'aurai des tonnes de requêtes sans garantie que le robots.txt sera respecté, et je risque la coupure du compte par Alwaysdata. Et si je continue à les bloquer, ils ne peuvent plus lire le robots.txt. Et je crains qu'un blocage sélectif suivant la requête soit lourd en traitement.
Il semble qu'Apache renvoie une erreur 403 quand l'IP est bloquée. Si je pouvais avoir 404, peut-être que le robot cesserait ses intrusions avec ces adresses inexistantes ?
-
ce que je voulais dire c'est qu'il ne lise pas le robots.txt à chaque fois, mais de temps en temps (1 fois par 24 voire beaucoup plus ...)
Si la dernière fois qu'ils l'ont chargé
-> inexistant
-> pas de lignes les concernant
ils vont continuer à crawler le site comme avant et tenterons quelques temps plus tard de voir si le fichier existe, puis de prendre en compte les instructions et etc ...
Laisse le au moins pour les autres robots ;)
Si ça se trouve, tu les as entièrement bloqué via l'ip avant qu'ils naient eu le temps de charger ton robots.txt (mais c'est une solution comme une autre hein, tu peux laisser le filtre par ip).
-
ce que je voulais dire c'est qu'il ne lise pas le robots.txt à chaque fois, mais de temps en temps (1 fois par 24 voire beaucoup plus ...)
Si la dernière fois qu'ils l'ont chargé
-> inexistant
-> pas de lignes les concernant
ils vont continuer à crawler le site comme avant et tenterons quelques temps plus tard de voir si le fichier existe, puis de prendre en compte les instructions et etc ...
Laisse le au moins pour les autres robots ;)
Si ça se trouve, tu les as entièrement bloqué via l'ip avant qu'ils naient eu le temps de charger ton robots.txt (mais c'est une solution comme une autre hein, tu peux laisser le filtre par ip).
Je n'ai laissé que les principaux robots de référencement. Je ne vois pas l'intérêt que j'aurais avec facebook, semrush ou amazon, d'autant plus que manifestement, ils ne cherchent pas les adresses valides. Pas une fois je n'ai vu d'eux la moindre tentative d'accéder à une bonne adresse.
Tu postes si vite que ta réponse et l'ajout de ma question sur l'erreur 403/404 dans mon post précédent se sont croisés. :)
-
@ F6FLT : es tu certain que l'augmentation du trafic sur ton site vient essentiellement des robots ? J'ai quand même un doute à ce sujet.
N'aurais tu pas subit une attaque ?
-
@ F6FLT : es tu certain que l'augmentation du trafic sur ton site vient essentiellement des robots ? J'ai quand même un doute à ce sujet.
N'aurais tu pas subit une attaque ?
Bah oui. Une attaque de robots ! 8)
-
Une attaque de robot ? je n'ai jamais entendu parler de cela.
Et en quoi consiste ces robots ?
-
Une attaque de robot ? je n'ai jamais entendu parler de cela.
Et en quoi consiste ces robots ?
Essaye de lire ce qui a déjà été posté stp...
Je me répète :
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).
Ca c'était pour FB
Pour le reste (le bot qui tente des URL dans le vent), justement... il tente. S'il trouve la ressource, jackpot.
Pareil, j'ai ce cas aussi (ils tentent de trouver ma page de login wordpress par ex).
-
Essaye de lire ce qui a déjà été posté stp...
Je ne poste pas sans lire le sujet auquel je réponds.
Je me répète :
Il est inutile de te répéter, je connais le post que tu as donné (https://lafibre.info/alwaysdata/enquete-sur-une-possible-attaque/msg1077493/#msg1077493).
Ce n'est pas pour autant que j'arrive à comprendre comment des robots peut provoquer une augmentation du trafic.
Est-ce un DDOS (Denial of Service attack) ?
Ca c'était pour FB
Tu voulais dire FaceBook. Mais en quoi facebook est responsable ? A moins que facebook a été piraté et que l'attaque part de là.
Si tu ne veux plus être emmerdé : passe ton site en privé (il est pour ton usage perso, donc ça devrait le faire).
Pourquoi référencer son site ? Il peut simplement y accéder par son adresse IP, si c'est pour un usage privé.
Car tant qu'il reste public, tu auras le problème (p-ê plus de facebook, mais d'autres, ce sera sans fin)
Au lieu d'installer son site chez AlwaysData, pourquoi ne pas l'héberger chez lui ? Il peut ainsi mieux contrôler par le pare-feu, ceux qui sont autorisés ou pas à utiliser son site. Dans mon cas, j'ai désactivé tous les robots :
User-Agent: *
Disallow: /
-
Je ne poste pas sans lire le sujet auquel je réponds.
Renseigne toi alors sur les domaines que tu ne comprends pas.
Ce n'est pas pour autant que j'arrive à comprendre comment des robots peut provoquer une augmentation du trafic.
Est-ce un DDOS (Denial of Service attack) ?
Non, du crawl intensif du site (pour simplifier)
Tu voulais dire FaceBook. Mais en quoi facebook est responsable ? A moins que facebook a été piraté et que l'attaque part de là.
Renseigne toi sur le rôle de robots de FaceBook
Pourquoi référencer son site ? Il peut simplement y accéder par son adresse IP, si c'est pour un usage privé.
Quel rapport entre référencement et IP ? Tu peux très bien avoir un nom de domaine et un site non référencé ...
Au lieu d'installer son site chez AlwaysData, pourquoi ne pas l'héberger chez lui ? Il peut ainsi mieux contrôler par le pare-feu, ceux qui sont autorisés ou pas à utiliser son site. Dans mon cas, j'ai désactivé tous les robots :
User-Agent: *
Disallow: /
Le fait d'avoir ton fichier robots.txt n'empêche pas les robots d'y accéder, seulement ceux qui le respectent
Il y a plein de bonnes raisons à vouloir héberger le site chez un professionnel plutôt que chez soi.
-
@F6FLT: Qu'en pense alwaysdata ? Pourquoi ne résolvent-ils pas eux-même le problème ?
-
Parce que les robots web (google, bing, facebook, amazon et etc ...) n'est pas un mal absolu à éradiquer à tout prix non plus.
Plein de personnes en ont besoin à un juste niveau de crawl.
Après que dans certains cas le crawl soit trop agressif c'est une chose, tout bloqué radicalement, s'en est une autre ..
Normalement le robots.txt suffit à les calmer. (encore faut il leur laisser le temps de le lire / interpréter)
Si demain un hébergeur bloque tous les robots et donc l'indexation, pas sur qu'ils aient encore bcp de clients.
-
@buddy:
Autoriser des robots à épuiser le quota de requêtes attribué au site et avoir peu de visiteurs effectifs doit sûrement réjouir @F6FLT. Sans compter que
c'est alwaysdata qui a relevé le problème. Donc, cela paraît plutôt anormal. On vous fournit une offre d'hébergement gratuite mais finalement, au vu de
la situation, on va quand même devoir revenir sur l'offre qui a été faite. En définitif, vous risquez effectivement la suspension de votre compte.
-
Là, j'ai peu de temps, mais je publierais cet été des statistiques sur les top 100 des robots qui indexent lafibre.info.
Vous pourrez voir que le problème, ce n'est pas Google ou Bing (leur activité est faible), mais d'autres.
-
@ F6FLT : es tu certain que l'augmentation du trafic sur ton site vient essentiellement des robots ? J'ai quand même un doute à ce sujet.
N'aurais tu pas subit une attaque ?
Absolument certain. Les fichiers log d'Alwaysdata ne laissent aucun doute à ce sujet. Les trois principaux pollueurs sont facebook, amazon et semrush.
Exemple de requêtes à répétition que nous envoient ces nuisibles :
tvradiozap.eu 2a03:2880:ff:28::face:b00c - - [01/Jul/2024:05:38:35 +0200] "GET /index.php/f/2/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u HTTP/2.0" 403 318 "-" "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)"
tvradiozap.eu 85.208.96.195 - - [01/Jul/2024:05:36:47 +0200] "GET /index.php/g/1/ty/tv/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u HTTP/1.1" 403 318 "-" "Mozilla/5.0 (compatible; SemrushBot/7~bl; +http://www.semrush.com/bot.html)"
-
@F6FLT: Qu'en pense alwaysdata ? Pourquoi ne résolvent-ils pas eux-même le problème ?
J'en étais enchanté avant cet incident, pour mes besoins c'est top à tout point de vue.
Je pense que ce n'est effectivement pas à moi de me protéger d'un trafic manifestement indésirable, par exemple des milliers de requêtes facebook pour toujours les mêmes adresses erronées, jusqu'à 1 toutes les 3 ou 4 secondes, mais à eux car c'est l'ensemble de leurs hébergés qu'ils ont à protéger.
Maintenant je ne suis pas trop exigeant vu que c'est gratuit, je leur ai montré ma bonne volonté, j'ai pris des mesures et communiqué ce que j'ai fait, qui est efficace en terme de charge de serveur.
La suspension du compte indiquerait une mauvaise volonté de leur part mais ce n'est pas le cas pour le moment, l'affaire semble en rester là.
-
...
Vous pourrez voir que le problème, ce n'est pas Google ou Bing (leur activité est faible), mais d'autres.
Je confirme en ce qui me concerne.
-
...
Je me répète :
C'est en rien une attaque.
Il fallait t'en douter : ton site circule et est partagé sur Facebook.
...
Tu te répètes sans prendre en compte ce qui a été montré ailleurs, à savoir par exemple le détournement des robots facebook par des API tiers.
Tu te répètes sans rien expliquer de points-clés essentiels, comme le fait que les adresses demandées soient systématiquement aberrantes, alors pour un "partage", tu repasseras.
Tu te répètes avec toujours des avis tranchés sur tous les sujets, à base de poncifs sans nuance ni argumentation circonstanciée en rapport avec les faits présentés ni preuve ni pertinence. Si tu pouvais prendre conscience de leur vacuité, tu gagnerais du temps et en ferais gagner aux autres en ne les produisant plus.
-
Hum, tu as une fonction "éditer" sur ton 1er message, ça évite d'en poster 50 et de remonter ton topic sans arrêt. Merci.
-
@ Buddy : je n'ai jamais entendu dire qu'une attaque pouvais être faite par des robots. ce n'est pas une attaque selon moi, mais une augmentation du trafic chez @F6FLT due à un bug dans son site.
Non, du crawl intensif du site (pour simplifier)
Merci pour l'information, mais cela reste un scan du site et ne doit pas provoquer un problème de trafic sur le site de @F6FLT, en principe.
Quel rapport entre référencement et IP ?
@F6FLT a un problème de référencement de son site, voilà tout. Il y a quelque chose de mal fait dans la hiérarchisation de ces liens url.
Si son site n'est pas référencé, le problème disparait de lui-même. Le mieux est de trouver ce qui ne va pas.
Il y a plein de bonnes raisons à vouloir héberger le site chez un professionnel plutôt que chez soi.
Je ne remets pas en cause l'hébergement vers l'excellent AlwaysData puisque je suis aussi chez eux avec une offre gratuite.
Absolument certain.
Merci :) pour ta réponse.
Si je regarde tes logs, on dirait qu'il boucle sur l'url qui est affiché. Pour visualiser cela dans mon Notepad++, j'ai coupé tes lignes sur "/tvrzperso", et je retrouve les mêmes séquences plusieurs fois et ce n'est pas normal. Aurais tu créer sans le vouloir une redirection ? D'où tes problèmes de référencements. Tu devrais te plonger dans les méandres du référencements et revoir ce que tu as déjà fait.
@F6FLT: Qu'en pense alwaysdata ? Pourquoi ne résolvent-ils pas eux-mêmes le problème ?
Parce que le référencement d'une site ne concerne pas AlwaysData mais bien @F6FLT.
La suspension du compte indiquerait une mauvaise volonté de leur part mais ce n'est pas le cas pour le moment, l'affaire semble en rester là.
Il n'y a pas de mauvaise volonté de la part d'AlwaysData car le problème ne les concerne pas. AlwaysData n'a fait que signaler le problème concernant l'hébergement d'un site gratuit qui n'a pas vocation à faire du gros trafic. Peu importe l'origine du problème, même si ton site à un énorme succès, tu dois réduire ce trafic, soit en résolvant le problème ou en passant à une offre payante.
En ce qui me concerne, ce n'est pas une attaque mais un problème de référencement dû à une mauvaise déclaration dans les fichiers ".html" ou ".php" du site de @F6FLT.
-
...
@F6FLT a un problème de référencement de son site, voilà tout. Il y a quelque chose de mal fait dans la hiérarchisation de ces liens url.
Ce n'est pas impossible. J'ai évoqué cette question dès mon 1er post :
"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 ?"
Le constat, c'est que ça ne pose pas de problèmes à Bing, ni à Duckduckgo, ni à Qwant. A Google et Yahoo, peut-être, car je ne vois pas de référence à des liens internes, seulement à la page d'accueil.
Comme je n'aime pas les liens avec "query" http://... .php?truc=machin j'ai fait le choix qu'ils soient de la forme http://... .php/truc/machin, sauf quand on utilise le formulaire.
C'est peut-être ça qui pose problème aux mauvais robots, mauvais puisqu'à l'usage depuis un navigateur, ces liens ne pose aucun problème.
Si je regarde tes logs, on dirait qu'il boucle sur l'url qui est affiché. Pour visualiser cela dans mon Notepad++, j'ai coupé tes lignes sur "/tvrzperso", et je retrouve les mêmes séquences plusieurs fois et ce n'est pas normal. Aurais tu créer sans le vouloir une redirection ? D'où tes problèmes de référencements. Tu devrais te plonger dans les méandres du référencements et revoir ce que tu as déjà fait.
Non, ce n'est pas normal, et c'est ce que j'ai déjà dit 3 ou 4 fois. Je fais des redirections parfois, qui ne posent de problème à personne sauf sans doute à facebook, amazon et semrush (et peut-être à Google et Yahoo mais ceux-là s'en sortent quand même), qui sont nécessaires et n'aboutissent jamais à ces répétitions dans une utilisation normale (humaine) du site.
...
En ce qui me concerne, ce n'est pas une attaque mais un problème de référencement dû à une mauvaise déclaration dans les fichiers ".html" ou ".php" du site de @F6FLT.
"mauvaise déclaration", tu intervertis les rôles. Si les "déclarations" étaient mauvaises le site ne fonctionnerait pas ou dysfonctionnerait de temps en temps, or à l'utilisation on ne voit jamais d'url comme ces robots les requêtent.
Alors s'il y a moyen de corriger le site pour pallier le défaut, je suis prêt à le faire, mais le défaut est bien chez ces quelques robots (encore de l'"IA" sans doute, qui est à l'"IA" ce que le MacDo est à la gastronomie... ).
Bon, je vais tester le site avec l'outil de validation du W3C. Ca fait des mois que je ne l'avais pas fait, possible que ça se soit dégradé, on va voir.
C'est fait. Pas mal d'erreurs bégnines corrigées, celles qui restent sont voulues et sans rapport avec les liens <a> qui étaient sans erreur. J'ai vérifié les liens des menus et des listes, ils sont écrits en dur, pas de problème. Pas de javascript à part pour la liste courante des chaînes cochées mais pour celle-là on n'utilise pas d'url, on enregistre directement la liste de la page. Le mystère reste entier. Je regarde maintenant du côté des redirections.
-
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)"
En 2 secondes, en plus, Optix te l'a gentiment dit....
Ton bloc IPv6 c'est Facebook.
Donc pas de DDoS... juste un robot Facebook.. Déstresses, t'es pas hacké ;D
-
Les gars découvrent Internet :)
-
@ F6FLT : il est fort possible que cela ne poser aucun problème aux autres robots, mais ceux de FaceBook n'apprécient pas du tout.
Il est inutile de répéter le nom du domaine dans les liens qui sont ceux de ton site. L'idée est que si tu viens à changer ton nom du domaine, tu ne modifies pas tous tes liens de ton site. Bien entendu, cela ne concerne pas les liens qui sont extérieurs à ton site.
Il ne faut pas mettre "https ://ton_nom_de domaine/index.php" mais "/index.php" car "index.php" se trouve dans le répertoire racine. C'est le "/" au début qui indique que c'est le répertoire racine.
Je te conseille de t'inscrire dans un forum spécialisé dans le référencement afin d'obtenir des conseilles sur comment les appliquer. Tu peux faire un tour chez Alsacréations (https://forum.alsacreations.com/forum.php). Ils sont spécialisés dans le développement des pages web, ainsi que chez Developpez (https://www.developpez.net/forums/f9/webmasters-developpement-web/).
"mauvaise déclaration", tu intervertis les rôles.
Je te parle du référencement, pas du fonctionnement d'une page web que tu développes en local sur ton ordinateur en utilisant un seul navigateur, comme Google Chrome. Ce sont, entre autres, des balises <meta> que l'on place dans la balise <head> de toutes tes pages WEB qui sont en "html" ou en "php.
Il faut tester ton site sur plusieurs navigateurs comme Mozilla Firefox, Opera, Microsoft Edge et corriger les bugs d'affichages. Il en existe d'autres comme Safari, Qwant ...
Tu n'es pas dans le bon forum pour parler référencement ainsi que développement WEB.
-
Je ne suis pas compétent mais ce genre d'attaque semble exister (https://community.cloudflare.com/t/404-attack-made-by-facebook/241035).
-
Je ne suis pas compétent mais ce genre d'attaque semble exister (https://community.cloudflare.com/t/404-attack-made-by-facebook/241035).
Tout à fait, et il semble que ce soit le cas.
Certains plus haut semblent débarquer, ils voient "facebook" dans les infos du fichier log que j'ai passées et en concluent donc que le robot de facebook fait juste un travail de référencement en balançant depuis des jours des url incorrectes jusqu'à toutes les 4 secondes ::). Ils font d'inutiles remarques de néophytes. Si je ne suis pas un professionnel du développement, je n'en suis quand même pas à devoir apprendre le B.A.BA, et si c'était aussi simple qu'ils le disent, j'aurais résolu le truc depuis longtemps sans rien voir demandé à personne.
Après ré-analyse complète de mon code, à aucun moment il ne peut y avoir génération d'url telles que celles demandées par facebook ou semrush.
Tous les liens de la page d'url internes sont absolus (relatifs à la racine du site). Les url sont écrites en dur, notamment par le PHP, dans le code HTML fourni. Je n'utilise aucun outil pour le générer ni aucune bibliothèque HTML ou javascript, tout le code est tapé dans un simple éditeur de texte, et dans le HTML final tout est transparent et très lisible dans les outils pour développeur des navigateurs.
Les liens anormaux sont soit le fait d'outils déconnant des robots (peu probable), soit d'origine malveillante par manipulation des robots de service comme facebook ou semrush, c'est la piste la plus probable.
Je viens de voir par exemple ce matin que semrush utilise des url de type /index.php/g/ or le "g" n'est jamais utilisé par le site. Quant aux répétitions de séquences, elles ne peuvent pas être générées non plus par le code JS puisque qu'aucun code ne crée d'url en dynamique.
Je verrais bien les répétitions de séquences comme des copier/coller générés par facilité pour créer au départ des liens incorrects, et ensuite déclencher une activité chez facebook ou ailleurs.
Pourquoi ces malveillances ? Mystère. Une vengeance ?! Evidemment je récupère des liens un peu partout, tout le monde fait ça, même les utilisateurs de Github chez qui je m'approvisionne en partie, je ne les vois donc pas du tout s'en offusquer d'autant plus que je rends la pareille avec mes listes (à part peut-être callofliberty qui ne porte pas son nom si bien que ça). J'ai fait un scan d'1 ou 2 sites de streaming africain mais pas intensivement, sans créer de charge, là encore je ne vois pas de mobile. Mais bon, des nuisibles il y en a partout et leurs motivations de malades sont parfois difficiles à cerner.
-
Est-ce tvrzperso.tv est à toi ?
Si c'est n'est pas le cas, j'ai une hypothèse un peu tordu mais bon ..., peut-être que ton ndd était déjà utilisé auparavant, et qu'il y a pleins de liens qui trainent sur facebook ? Vu la tronche de la cible on dirait que le bot tombe sur une sorte de boucle.
Sinon si tu n'utilise pas de php, renomme l'index en .html peut être ? Le bot comprendra peut être un jour qu'il y a plus rien à cette page
Et peut être tu devrais stocker les images en local également, tu te retrouves à ton tour à faire pleins de requête à des sites qui ont rien demandé, pour récupérer des images ;D
Sinon c'est quand même étonnant qu'un hébergeur gueule pour des robots... C'est la vie d'un site
-
Est-ce tvrzperso.tv est à toi ?
Si c'est n'est pas le cas, j'ai une hypothèse un peu tordu mais bon ..., peut-être que ton ndd était déjà utilisé auparavant, et qu'il y a pleins de liens qui trainent sur facebook ? Vu la tronche de la cible on dirait que le bot tombe sur une sorte de boucle.
Sinon si tu n'utilise pas de php, renomme l'index en .html peut être ? Le bot comprendra peut être un jour qu'il y a plus rien à cette page
tvrzperso.tv est bien dans les liens de la page d'accueil, mais pas au niveau d'arborescence délirant des requêtes. Et le ndd est bien nouveau.
Si le bot tombait sur une boucle, on aurait bien plus de régularité. D'autre part on a des requêtes d'url avec un /g/ au début, et le /g/ n'existe nulle part sur le site.
Je viens d'analyser le début du log de la nuit. Extrait ici, le premier bloc est de facebook, le second de semrush :
/index.php/ty/ra/d/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.tv
/index.php/f/2/s/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u
/index.php/f/2/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv
/index.php/ty/tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u
/index.php/ty/tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv
/index.php/ty/tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u
/index.php/ty/tv/f/2/d/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv
/index.php/ty/tv/f/2/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv
/index.php/ty/tv/f/2/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv
/index.php/f/0/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u
/index.php/ty/ra/f/2/s/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u
/index.php/j/permalinks_/f/0/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.tv
/index.php/j/permalinks_/f/0/s/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u
/index.php/j/permalinks_/f/0/s/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.m3u
/index.php//f/1/ty/tvtop/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.tv
/index.php/ty/ra/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u
/index.php/ty/ra/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u
/index.php/ty/ra/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u
/index.php/ty/ra/s/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv
/index.php/ty/ra/d/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.m3u
/index.php/ty/ra/d/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.tv
/index.php/ty/ra/d/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.m3u
/index.php/ty/tv/d/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.m3u
/index.php/ty/tv/s/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.tv
/index.php/ty/tv/s/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.m3u/s/tvrzperso.tv
/index.php/ty/tv/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u
/index.php/f/2/s/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.m3u/s/tvrzperso.tv/s/tvrzperso.m3u
/index.php/f/2/d/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u/s/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.m3u
/index.php/g/1/ty/ra/d/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.m3u
/index.php/g/3/ty/tv/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.tv/d/tvrzperso.tv/s/tvrzperso.m3u/d/tvrzperso.tv/d/tvrzperso.m3u
/index.php/j/permalinks_/f/0/s/tvrzperso.tv/s/tvrzperso.tv/s/tvrzperso.m3u/s/tvrzperso.tv/d/tvrzperso.tv/d/tvrzperso.m3u/d/tvrzperso.m3u
Si ces adresses à rallonge ont toutes un air de famille, étonnamment on n'a pas deux fois la même, ce qui est le signe d'une génération aléatoire qui ne me semble pas du tout naturelle et due au site, mais voulue. Et aucun autre robot ne demande ces adresses absurdes, ce qui rend peu vraisemblable un problème du site. A noter que si semrush demande parfois le fichier robots.txt, facebook jamais. Tout cela plaide pour une malveillance bien délibérée.
Et peut être tu devrais stocker les images en local également, tu te retrouves à ton tour à faire pleins de requête à des sites qui ont rien demandé, pour récupérer des images ;D
Surtout pas. C'est un choix que le site n'héberge aucun contenu. De plus les logos changent, je ne pourrais plus savoir quand un logo est périmé, tandis qu'avec le fichier image au bout d'un lien, soit l'image est automatiquement mise à jour, soit le lien est remplacé auquel cas on s'en aperçoit tout de suite, on n'a plus le logo.
Les "sites qui ont rien demandé" sont ceux qui l'acceptent, c'est la situation par défaut de tout hyperlien d'être accessible de n'importe où. Il suffit de renvoyer les "bons" headers quand on ne le souhaite pas, ce que font d'ailleurs pas mal de sites, aussi bien pour les images que pour les adresses de stream.
Pour info, le fastidieux téléchargement des logos de toutes les chaînes quand on charge la page est un problème dont j'avais bien conscience et que je comptais résoudre. J'ai découvert récemment la directive "loading=lazy" qui permet aux images dans les tags HTML de n'être chargées qu'au moment où elles ont à être visualisées dans le navigateur. Je l'ai mise en place aussitôt tant c'est facile. Le chargement d'une page de la liste complète des chaînes devrait être plus rapide pour ceux qui n'ont pas déjà les logos dans le cache du navigateur, et les sites hébergeant ces logos seront moins sollicités.
Sinon c'est quand même étonnant qu'un hébergeur gueule pour des robots... C'est la vie d'un site
Oui. En plus les mesures seraient faciles contre les excès, comme bloquer pendant un certain temps tout robot qui ferait d'intenses salves de requêtes erronées. Ca ne gênerait pas les sites qui souhaitent être scrawlés par ces robots, mais éviterait les surcharges.
-
Sinon c'est quand même étonnant qu'un hébergeur gueule pour des robots... C'est la vie d'un site
Oui. En plus les mesures seraient faciles contre les excès, comme bloquer pendant un certain temps tout robot qui ferait d'intenses salves de requêtes erronées. Ca ne gênerait pas les sites qui souhaitent être scrawlés par ces robots, mais éviterait les surcharges.
Euh... c'est une offre gratuite que tu as là.
Si tu en veux plus, change d'hébergeur. Pour quelques euros par mois, tu as des offres solides.
Leon.
-
...
Euh... c'est une offre gratuite que tu as là.
Si tu en veux plus, change d'hébergeur. Pour quelques euros par mois, tu as des offres solides.
Leon.
Pourquoi passerait-on à une offre payante chez un hébergeur qui fait des offres gratuites alors qu'il n'en assure pas un service correct dans un contexte normal d'utilisation ?
Un tel hébergeur ne peut pas être considéré comme fiable ou honnête.
D'autre part les offres gratuites sont évidemment payées par les offres payantes, principales sources de revenus des hébergeurs. A la limite pourquoi devrait-on payer une offre chez eux, sachant qu'une partie de ce qu'on paye sera utilisé par eux pour le fonctionnement des offres gratuites, donc pas affectés à 100% au type d'offre qu'on paye ?
On sait bien qu'une offre gratuite est faite pour attirer du monde soit parce qu'il y a une façon indirecte de faire du profit grâce aux comptes des utilisateurs du gratuit soit dans l'espoir qu'une partie passera tôt ou tard à l'offre payante. Mais ce ne sera jamais 100%, les hébergeurs doivent en prendre leur parti. Que ceux incapables de tenir leurs promesses et d'assumer, ne proposent pas d'offre gratuite, ou qu'ils disent clairement les différences et limites de ces offres par rapport aux offres payantes.
Concernant Alwaysdata, je n'ai aucun souci jusqu'à présent. L'offre gratuite est excellente, et sans ce qui ressemble de plus en plus clairement à une attaque ciblée par détournement de robots, je ne crois pas qu'ils auraient déclenché un incident avec menace de suspension du compte. Le fait qu'ils aient accepté mes explications et les mesures que j'ai mises en place (ce qui serait peut-être de leur ressort mais vu que c'est gratuit je suis quand même prêt à faire des concessions), va dans ce sens.
Pour en revenir à "l'attaque", son intensité a décru. Semrush demandant régulièrement le fichier robots.txt (contrairement à facebook), je viens de débloquer une de ses adresses IP pour voir s'il le respecte. L'inconvénient du blocage IP est en effet qu'un robot ne peut plus récupérer le fichier robots.txt et continue son harcèlement. Bloquer l'IP sauf pour le fichier robots.txt est sûrement possible, il faudrait que je me mette aux RewriteCond d'Apache, mais ça ne me passionne pas...
11:25 : ça y est, je viens de voir passer les premières requêtes Semrush sur son adresse débloquée, malheureusement pas encore pour le fichier robots.txt, je vais devoir attendre.
-
Pourquoi passerait-on à une offre payante chez un hébergeur qui fait des offres gratuites alors qu'il n'en assure pas un service correct dans un contexte normal d'utilisation ?
Un tel hébergeur ne peut pas être considéré comme fiable ou honnête.
C'est la raison pour laquelle il n'y a pas d'offres gratuites chez MilkyWan : Toujours des ingrats pour venir se plaindre que ce qu'on leur *offre* n'est pas assez bien pour eux, puis qui viennent ensuite te pourrir sur les forums en disant que tu n'es pas fiable et malhonnête.
Mentalité de pourri gâté.
-
C'est la raison pour laquelle il n'y a pas d'offres gratuites chez MilkyWan : Toujours des ingrats pour venir se plaindre que ce qu'on leur *offre* n'est pas assez bien pour eux, puis qui viennent ensuite te pourrir sur les forums en disant que tu n'es pas fiable et malhonnête.
Mentalité de pourri gâté.
+1 : c'est franchement pas fair-play de faire de la mauvaise pub à l'hébergeur, alors que c'est une offre gratuite.
Leon.
-
+1 : c'est franchement pas fair-play de faire de la mauvaise pub à l'hébergeur, alors que c'est une offre gratuite.
D'autant plus qu'Alwaysdata est un des meilleurs hébergeurs que je connaisse.
J'ai dit à F6FLT qu'il a un problème de référencement mais il continue de nier.
-
C'est la raison pour laquelle il n'y a pas d'offres gratuites chez MilkyWan : Toujours des ingrats pour venir se plaindre que ce qu'on leur *offre* n'est pas assez bien pour eux, puis qui viennent ensuite te pourrir sur les forums en disant que tu n'es pas fiable et malhonnête.
Mentalité de pourri gâté.
Donc je résume :
1) Il a un hébergement gratuit, ce qui en soit est une prouesse !
2) Il râle parce que les performances sont limitées, et que si il veut des performances améliorées, il faut sortir le chéquier (logique).
3) Vu qu'il ne veut pas payer, il ruine la réputation de l'hébergeur qui rappelons-le, lui, ne tire actuellement aucun bénéfice de sa présence sur ses serveurs (qui par contre, lui coûte de l'argent).
Certains devrait redescendre de leur mât d'antenne.... Il est complètement injuste de s'attaquer à l'hébergeur GRATUIT ! :o >:(
-
Un peu HS
Y-a-t-il une liste de services en ligne gratuits, quelque part sur Lafibreinfo?
Genre : monitoring, DNS, hébergement, VPS, VPN, etc...
-
Il est complètement injuste de s'attaquer à l'hébergeur GRATUIT !
C'est à l'hébergeur de clarifier les choses par rapport aux services proposés. Voyez un exemple ci-dessous.
Ce tutoriel a pour objectif de vous aider à sécuriser l'accès à vos sites du réseau extérieur, à prévenir ou corriger d'éventuelles intrusions ou tentatives d'attaques DDoS (attaques par déni de service).
Vous pouvez réaliser ceci grâce à un fichier « .htaccess », un fichier texte particulier, détecté par le serveur web (Apache), et qui permet de définir des règles spéciales sur un répertoire et l'ensemble
de ses sous-répertoires.
OVHcloud met à votre disposition des services dont la configuration, la gestion et la responsabilité vous incombent. Il vous revient de ce fait d'en assurer le bon fonctionnement.
Nous mettons à votre disposition ce guide afin de vous accompagner au mieux sur des tâches courantes. Néanmoins, nous vous recommandons de faire appel à un prestataire
spécialisé si vous éprouvez des difficultés. En effet, nous ne serons pas en mesure de vous fournir une assistance. Plus d'informations dans la section « Aller plus loin » de ce guide.
Source : Tutoriel - Comment bloquer l'accès à mon site pour certaines adresses IP via un fichier .htaccess ? (https://help.ovhcloud.com/csm/fr-web-hosting-htaccess-ip-restriction?id=kb_article_view&sysparm_article=KB0052848)
-
Un peu HS
Y-a-t-il une liste de services en ligne gratuits, quelque part sur Lafibreinfo?
Genre : monitoring, DNS, hébergement, VPS, VPN, etc...
Non, mais cela serait intéressant à faire.
Ne pas hésiter à créer un sujet, inciter les personnes à indiquer d'autres offres que la personne qui a créé le sujet rajoute sur son premier message.
Cela serait bien quand c'est connu d'indiquer les limites de la version gratuite ou la présence de publicités (il y a des hébergeurs gratuit qui rajoutent une pub en haut de chaque page).
-
Une préférence pour la section du forum?
-
C'est la raison pour laquelle il n'y a pas d'offres gratuites chez MilkyWan : Toujours des ingrats pour venir se plaindre que ce qu'on leur *offre* n'est pas assez bien pour eux, puis qui viennent ensuite te pourrir sur les forums en disant que tu n'es pas fiable et malhonnête.
Mentalité de pourri gâté.
Ton message est incompréhensible.
Si MilkyWan ne propose pas d'offre gratuite, c'est tout à fait respectable, c'est son choix et il l'affiche, il n'y a rien à redire.
Si Alwaysdata propose des offres gratuites et les assument, c'est tout à fait respectable, c'est son choix et il l'affiche, il n'y a rien à redire.
La seule malhonnêteté serait de proposer une offre gratuite uniquement dans le but de faire passer ceux qui la prennent, à l'offre payante, par des moyens contestables comme l'affirmation d'un trop grand trafic quand le trafic ne vient que de robots, trafic normal dans le contexte actuel. C'est là que serait la "mentalité de pourri", celle des dirigeants d'une telle société, et ce serait malhonnête non seulement vis à vis de leurs clients qui prennent l'offre, mais aussi vis à vis de leurs concurrents qui ne la proposent pas et qui perdront les clients potentiels qui se seront fait avoir avec ce genre d'offre gratuite.
Or je le redis, ce dernier point ne concerne pas Alwaysdata, et je le redis encore, j'en suis très satisfait. Donc je ne vois pas à qui/quoi fait référence ton allusion de "mentalité de pourri gâté". Personne n'exige du gratuit mais seulement qu'il soit effectif et conforme à l'annonce quand il a été proposé.
-
Ton message est incompréhensible.
Bizarrement, tout le monde l'a compris, sauf toi.
-
Dès le début, j'annonçais :
"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."
Pas plus tard qu'hier :
"Concernant Alwaysdata, je n'ai aucun souci jusqu'à présent. L'offre gratuite est excellente, et sans ce qui ressemble de plus en plus clairement à une attaque ciblée par détournement de robots, je ne crois pas qu'ils auraient déclenché un incident avec menace de suspension du compte. Le fait qu'ils aient accepté mes explications et les mesures que j'ai mises en place [] va dans ce sens."
Tout cela devient :
...
3) Vu qu'il ne veut pas payer, il ruine la réputation de l'hébergeur qui rappelons-le, lui, ne tire actuellement aucun bénéfice de sa présence sur ses serveurs (qui par contre, lui coûte de l'argent).
...
Touver l'erreur...
La seule question qui reste est : est-ce que ce propos diffamatoire est tenu par incompréhension ou par désir de nuire ?
Probablement les deux. Comme disait Jules Romains, "Les esprits d'élite discutent des idées, les esprits moyens discutent des événements, les esprits médiocres discutent des personnes", je suis très enclin à le croire. Attaquer ceux qui s'expriment plutôt qu'argumenter, c'est vraiment le niveau zéro.
Bizarrement, tout le monde l'a compris, sauf toi.
Tu es "tout le monde" ?! Un anonyme tout au plus, amha justifié ; aucun répondant.
Pour peu qu'un autre quidam pense comme lui, ils croient être "tout le monde".
Ca m'amuse ce petit monde qui prétend savoir qui a compris ou pas, rend son jugement inconsistant, inique et péremptoire sur les gens plutôt que des arguments sur le sujet, et le tient pour Vérité universelle.
-
...
J'ai dit à F6FLT qu'il a un problème de référencement mais il continue de nier.
A quel endroit je l'aurais "nié" ? J'ai toujours seulement émis des doutes sans jamais être définitif.
Et tu as peut-être raison.
Je me suis aperçu qu'à un certain moment, je renvoyais la page d'accueil sur une erreur 404 plutôt que de faire une redirection vers cette même page, ce qui dans mon esprit permettait un petit gain de temps.
Pour un utilisateur humain, c'est parfait, il n'avait pas d'erreur 404, se retrouvait sur la page d'accueil, et s'il cliquait un lien, il avait la bonne adresse.
Pour un robot, ça pourrait poser problème s'il a gardé son url d'appel comme adresse de base, auquel cas des liens relatifs pourraient être estimés par lui par rapport à son adresse fausse qui a donné l'erreur 404, et générer des liens à rallonge.
Hier soir j'ai fait une modif pour renvoyer une erreur 404 quand on est dans ce cas. Et depuis je regarde si les quelques IP débloquées, de robots qui ont désormais l'erreur 404, redemandent quand même les mêmes liens erronés.
Le site est fait pour les gens, pas pour les robots. C'est fou qu'il faille s'asservir à la bêtise des robots pour avoir la paix. En tout cas vois le titre du fil "Enquête sur une possible attaque" : l'enquête est en cours, en direct live, ne pas mettre la charrue avant les boeufs.
8/7/2024 10:28 Les choses semblent s'améliorer. Je n'ai pas eu 2 fois la même requête de semrush. Je viens de débloquer toutes ses adresses et il vient de demander le fichier robots.txt. On va donc enfin voir s'il le respecte. J'ai aussi débloqué une large plage de facebook. On va donc voir aussi de son côté si la réception d'une erreur 404 interrompt son harcèlement, contrairement à l'erreur 403 du blocage IP.
8/7/2024 23:17 Semrush semble respecter le fichier robots.txt, il n'est plus gênant. Facebook reste une infection, il doit demander le ficher robots.txt tous les 36 du mois.
9/7/2024 10:16 Confirmation, Semrush respecte le fichiers robots.txt, mais comme quelques autres robots dont MJ12bot ou Dotbot le robot de Moz, il le redemande sans arrêt (irrégulièrement, par exemple après 2h, ou après 4mn), et il utilise plusieurs robots différents. Je découvre aussi "awario", qui scrawle votre site seulement pour pouvoir dire à leurs clients quels sites font référence à leurs "marques" et il y en a d'autres dans le genre.
J'ai remarqué aussi une salve de 5 requêtes venant de 5 IP différentes de "f3netze.de" demandant les url "/?author=1 à 5 jamais utilisées dans tvradiozap, ça ressemble furieusement à une tentative d'intrusion, les professionnels se croient tout permis.
Mais la pire cochonnerie reste Facebook. Je ne les vois jamais demander le fichier robots.txt, et ils font 1000 à 1500 requêtes par jour vers des adresses inexistantes depuis des centaines d'adresses IP différentes. Bien sûr je n'ai jamais eu aucune réponse à ma plainte déposée sur leur adresse d'abuse.
10/7/2024 08:44 Toutes les adresses IP des robots sont désormais débloqués sauf Facebook. Il se confirme que les robots qui requêtaient sur les mêmes adresses erronées que Facebook, cessent de le faire. Ca a commencé avec Amazon, et ça s'est terminé par Semrush qui a fini par comprendre quand on lui a renvoyé l'erreur 404 au lieu de 403 liée à son blocage.
11/07/2024 cette nuit, dans le bruit de fond de facebook, 2 salves de dizaines de requêtes venant l'une d'un datacenter Microsoft à Dublin (IP=52.169.180.51), ciblant de multiples documents, scripts et répertoires généralement associés à Wordpress, et une autre d'un datacenter Microsoft US en Virginie (IP=20.190.242.102), faisant de même pour d'autres types de répertoires n'existant pas sur tvradiozap.eu. Extraits :
...
tvradiozap.eu 52.169.180.51 - - [11/Jul/2024:02:41:16 +0200] "GET /wp-admin/xmrlpc.php?p= HTTP/1.1" 404 1 "-" "-"
tvradiozap.eu 52.169.180.51 - - [11/Jul/2024:02:41:16 +0200] "GET /smaxx.php HTTP/1.1" 404 1 "-" "-"
tvradiozap.eu 52.169.180.51 - - [11/Jul/2024:02:41:16 +0200] "GET /wp-admin/smaxx.php HTTP/1.1" 404 1 "-" "-"
tvradiozap.eu 52.169.180.51 - - [11/Jul/2024:02:41:16 +0200] "GET /wp-content/plugins/WordPressCore/smaxx.php HTTP/1.1" 404 7732 "-" "-"
tvradiozap.eu 52.169.180.51 - - [11/Jul/2024:02:41:16 +0200] "GET /wp-includes/images/smaxx.php HTTP/1.1" 404 7732 "-" "-"
tvradiozap.eu 52.169.180.51 - - [11/Jul/2024:02:41:17 +0200] "GET /wp-content/plugins/core-plugin/smaxx.php HTTP/1.1" 404 7732 "-" "-"
tvradiozap.eu 52.169.180.51 - - [11/Jul/2024:02:41:17 +0200] "GET /wp-includes/smaxx.php HTTP/1.1" 404 1 "-" "-"
...
tvradiozap.eu 20.190.242.102 - - [11/Jul/2024:01:08:57 +0200] "GET /private/.env HTTP/1.1" 404 1 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36"
tvradiozap.eu 20.190.242.102 - - [11/Jul/2024:01:08:59 +0200] "GET /prod/.env HTTP/1.1" 404 1 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36"
tvradiozap.eu 20.190.242.102 - - [11/Jul/2024:01:09:00 +0200] "GET /profile/.env HTTP/1.1" 404 1 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36"
tvradiozap.eu 20.190.242.102 - - [11/Jul/2024:01:09:01 +0200] "GET /profiles/.env HTTP/1.1" 404 1 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.89 Safari/537.36"
...Aucun robot indiqué ni lecture du robots.txt. Clairement une tentative d'intrusion en profondeur dans le site, à partir de la supposition d'une architecture qui n'est pas la sienne.
12/07/2024 10:50 création d'une règle Apache pour renvoyer l'erreur 404 à toute IPV6 de facebook (plutôt que 403 quand ses IP sont bloquées), histoire de voir si comme les autres robots, cela le dissuaderait de recommencer. Fait par acquis de conscience car je n'y crois pas vraiment.
RewriteEngine on
RewriteCond expr "-R '2a03:2880::/32'"
RewriteRule ^ - [R=404]
13/07/2024 Encore une salve comme avant-hier d'environ 200 adresses de type worldpress venant d'une nouvelle IP d'un datacenter microsoft (4.227.17.42).
-
Conclusion de l'histoire.
Actuellement le trafic facebook est d'environ une requête toutes les 1mn 6s soit 1300 par jour.
Que ce serait le résultat d'un travail de référencement d'un robot facebook a été suggéré et même affirmé par certains ici, et j'ai aussi pensé que ce serait le cas ; cette explication est celle du rasoir d'Okkham donc la plus probable. Mais c'est faux. Pas à pas au fil des jours j'ai dû éliminer cette hypothèse pour plusieurs raisons convergentes.
- Les requêtes concernent des adresses inexistantes, et jamais les mêmes bien que toutes soient sur le même schéma : des "morceaux" d'adresses valides concaténées de façon aléatoire.
- Les requêtes ne concernent jamais la moindre adresse existante.
- Le fichier robots.txt n'est jamais demandé, contrairement à la pratique de tous les autres robots.
- Le trafic est stabilisé avec une grande régularité des requêtes qu'on ne voit nulle part ailleurs
- L'intensité du trafic est considérablement supérieure à celui de n'importe quel autre robot
- Facebook est aujourd'hui le seul robot à requêter vers des adresses erronées, signe que ce n'est pas dû à un dysfonctionnement du site, lequel ne fournit que des adresses absolues.
- Ce type d'attaques venant de facebook a déjà été rapporté de très nombreuses fois par les webmasters
L'attaque vient bien de facebook, mais certainement via une instrumentalisation qui en est faite. Des rapports déjà produits, c'est le genre "script qui clique ces liens erronés mis préalablement sur facebook", ce qui entraine une activité de facebook pour analyser sans contrainte ce qui se trouve à ces adresses.
L'usage éthique est en effet qu'un fichier robots.txt ne sert qu'à encadrer le travail de référencement à l'initiative des robots, lesquels tentent de référencer toutes les adresses internes du site. Mais il est admis dans le métier que des adresses déjà publiées ailleurs peuvent être lues indépendamment du fichier robots.txt.
Le début de l'attaque facebook s'était accompagné de requêtes vers ces mêmes liens erronés par d'autres robots, dont les plus actifs : Amazon et Semrush. Amazon a abandonné très vite dès que ses IP ont été bloquées. Pas Semrush. Le blocage IP a l'inconvénient d'empêcher le robot d'accéder au fichier robots.txt. Il répète alors bêtement ses requêtes. En débloquant progressivement des IP de Semrush, il a pu lire le fichier robots.txt, et comme il le respecte, il a cessé son trafic.
Actuellement les IP de tous les robots sont débloquées, ils ne requêtent plus avec les adresses erronées, seul Facebook continue, confirmation que le problème vient de lui dès le départ et avait déclenché un trafic similaire chez quelques autres robots qui avaient dû lire chez lui ses adresses erronées vers TVradioZap.
Sur le fond, le fait que facebook soit détourné par des nuisibles ne l'excuse pas, à eux de sécuriser leurs services, ils ont quand même les moyens, surtout que ce genre de fait est rapporté depuis des années. En plus ils ne répondent pas aux plaintes déposées sur leur adresse d'abuse fournie au lien accompagnant leurs requêtes pourries. On pouvait déjà leur faire pas mal de griefs, mais là c'est le pompon, quelle bande de margoulins !
Concernant les autres robots, aucun souci, ils respectent le fichier robots.txt. Seul Semrush et mj12bot.com sont limites, puisqu'ils redemandent 20 fois par jour le fichier, on ne peut donc pas considérer qu'on a affaire à des entreprises respectables. Moz est pas loin non plus.
A signaler en marge du problème facebook, quelques salves de requêtes erronées venant d'au moins 3 adresses IP de datacenters de Microsoft, encore une de plus de 200 requêtes aujourd'hui (instrumentalisées elles aussi ?), supposant que le site possède une architecture de type "worldpress" et d'un autre type non encore identifié. TVradioZap n'ayant pas ces architectures, il ne risque rien, erreurs 404, mais cela ressemble fort à une tentative d'intrusion. C'est fou ce qu'on voit passer dans les logs.
Enfin pour en revenir à Alwaysdata par la plainte duquel j'avais été informé que la surcharge des requêtes pouvait donner lieu à suspension du compte gratuit, mes explications et les mesures que j'ai prises ont été entendues. Le trafic de fond de facebook, lequel est rejeté au niveau d'Apache et ne donne lieu à aucune excécution de script PHP, ne peut plus constituer une charge importante. Je compte encore la faire baisser par une astuce que je ne révélerai pas ici publiquement où les vilains pourraient la lire.
Je confirme qu'Alwaysdata est un hébergeur solide comme je l'ai dit dès le premier post de ce fil, que tout est vraiment bien pensé sur son site, son service est top, je le conseille.