Un robot Facebook sans agent d’utilisateur spammant notre site contre une éventuelle attaque de type DoS
Les robots enregistrés sur Facebook (ipv6 se terminant par: face: b00c :: 1) claquaient notre site, voyant des dizaines de milliers de visites en seulement 20 minutes. Nous avons constaté qu’ils n’avaient pas d’agent utilisateur dans l’en-tête et nous avons mis en place une règle sur cloudflare pour nous protéger.
Il semble qu'ils aient corrigé le robot et ajouté un agent utilisateur "Externalhit/1.1" qui est un robot reconnu. Maintenant qu'ils contournent la règle, je vois 11 000 visites en 15 minutes. Souvent plusieurs fois sur la même page! Ceci paralyse notre base de données. C'est empêcher les clients d'utiliser légitimement le site.
Nous avons mis en place un vaste bloc sur toutes les adresses IP de Facebook afin de tenter d'y remédier, mais nous avons probablement déjà perdu des clients à cause de cela.
Ma question est la suivante: est-ce que quelqu'un a déjà vu cela auparavant? Une idée de ce qui le cause? Existe-t-il un canal pour obtenir une réponse de Facebook ou existe-t-il une voie légale à suivre?
Lien vers notre Tweet: https://Twitter.com/TicketSource/status/969148062290599937 Le groupe de développeurs FB et le représentant de Facebook ont essayé et ont été dirigés vers le support. A déposé un billet, pas de réponse.
Exemple de log:
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5394 2a03:2880:30:7fcf:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5362 2a03:2880:30:afd1:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5378 2a03:2880:30:7fcf:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5425 2a03:2880:30:2fea:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5394 2a03:2880:30:2fea:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5659 2a03:2880:30:2fd8:face:b00c:0:8000
2018-03-01 09:00:33 10.0.1.175 GET /dylanthomas - 443 - facebookexternalhit/1.1 - 200 0 0 5659 2a03:2880:11:dff3:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /whitedreamspremiere - 443 - facebookexternalhit/1.1 - 200 0 0 5048 2a03:2880:2020:bffb:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /helioscollective - 443 - facebookexternalhit/1.1 - 200 0 0 4633 2a03:2880:3020:1ffd:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /helioscollective - 443 - facebookexternalhit/1.1 - 200 0 0 4727 2a03:2880:3011:afc5:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /helioscollective - 443 - facebookexternalhit/1.1 - 200 0 0 4977 2a03:2880:3020:1ffd:face:b00c:0:8000
2018-03-01 09:00:36 10.0.1.175 GET /event/FDMEJD - 443 - facebookexternalhit/1.1 - 200 0 0 4868 2a03:2880:2111:1ff9:face:b00c:0:8000
Edit2: Ces adresses IP sont en train d’analyser car nous avons trouvé des URL dans notre processus de paiement. Ils ont donc suivi un lien et se sont retrouvés dans une URL de session uniquement.
Edit3: Facebook semble avoir confirmé le bogue et cherche une solution .
https://developers.facebook.com/bugs/1894024420610804
Selon la réponse de Facebook, toute page partagée sur Facebook devrait s’attendre à ce que si son contenu est partagé, les robots d'exploration de Facebook augmenteront le trafic de 10 à 20 fois ce nombre de partages.
Cela ressemble à du fait que Facebook gratte le contenu à chaque accès, avec peu ou pas de mise en cache.
Dans notre cas, bien que Facebook soit probablement bon pour la publicité dans son ensemble, il s’agit d’une contrainte énorme lorsque vous exécutez une page à base de données intensive qui est partagée. Nous devrons limiter le trafic de notre côté pour empêcher une attaque par déni de service. Une réponse gourmande en ressources au bot actif de Facebook.
Des sources affirment que Facebook/Externalhit ne respecte pas crawl-delay dans le fichier robots.txt, car Facebook n'utilise pas de robot d'exploration, il utilise un grattoir.
Chaque fois que l'une de vos pages est partagée sur Facebook, votre site, votre description et votre méta sont grattés.
Mon hypothèse est que si Facebook gratte votre site 11 000 fois en 15 minutes, je pense que le scénario le plus probable est que quelqu'un a découvert comment utiliser le racleur Facebook pour utiliser DDOS sur votre site.
Peut-être qu'ils exécutent un bot qui clique sur votre lien de partage à plusieurs reprises, et Facebook gratte votre page à chaque fois qu'il le fait.
De mémoire, la première chose que j’essayerais de faire est de mettre en cache les pages que Facebook frotte. Vous pouvez le faire dans htaccess. J'espère que cela dira à Facebook de ne pas charger votre page avec chaque partage jusqu'à l'expiration du cache.
En raison de votre problème, je définirais l'expiration HTML plus longtemps que d'habitude
En .htaccess:
<IfModule mod_expires.c>
ExpiresActive On
ExpiresDefault "access plus 60 seconds"
ExpiresByType text/html "access plus 900 seconds"
</IfModule>
Si vous définissez html pour qu'il expire à 900 secondes, nous espérons que Facebook ne pourra pas explorer une page à une fois toutes les 15 minutes.
Edit: J'ai effectué une recherche rapide et trouvé une page écrite il y a quelques années qui traite du problème même que vous rencontrez maintenant. Cette personne a découvert que les sites Web pourraient être inondés par le racleur de Facebook grâce à sa fonctionnalité de partage. Il l'a signalé à Facebook, mais ils ont choisi de ne rien faire. Peut-être que l'article vous expliquera plus clairement ce qui vous arrive et qu'il vous orientera peut-être dans la bonne direction quant à la manière dont vous souhaitez gérer la situation:
http://chr13.com/2014/04/20/using-facebook-notes-to-ddos-any-website/