it-swarm.com.de

Facebook-Crawler ohne User-Agent, der unsere Website bei möglichen DoS-Angriffen spammt

Auf Facebook registrierte Crawler (ipv6 endend mit: face: b00c :: 1) haben unsere Website zugeschlagen und in nur 20 Minuten Zehntausende Zugriffe verzeichnet. Wir haben festgestellt, dass der Header keinen Benutzeragenten enthält, und haben eine Cloudflare-Regel implementiert, um uns zu schützen.

Offenbar haben sie den Crawler gepatcht und einen Benutzeragenten 'Externalhit/1.1' hinzugefügt, bei dem es sich um einen erkannten Crawler handelt. Jetzt umgehen sie die Regel, ich sehe 11.000 Treffer in 15 Minuten. Oft mehrmals auf derselben Seite! Dies lähmt unsere Datenbank. Es verhindert, dass Kunden die Website rechtmäßig nutzen.

Wir haben eine breite Sperre für alle IP-Adressen von Facebook implementiert, um dies zu beheben. Wahrscheinlich haben wir dadurch bereits das Geschäft verloren.

Meine Frage ist: Hat das schon mal jemand gesehen? Irgendeine Idee, woran es liegt? Gibt es einen Kanal, um eine Antwort von Facebook zu erhalten, oder gibt es einen legalen Weg, den wir gehen sollten?

Link zu unserem Tweet: https://Twitter.com/TicketSource/status/969148062290599937 Versuchte FB-Entwicklergruppe und Facebook-Repräsentant und wurden an den Support weitergeleitet. Ein Ticket eingereicht, keine Antwort.

Protokollbeispiel:

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: Diese IPs werden gecrawlt, da wir URLs aus unserem Zahlungsprozess gefunden haben. Also folgten sie einem Link und endeten in einer Session-URL.

Edit3: Facebook scheint den Bug bestätigt zu haben und sucht nach einem Fix .

7
L Martin

https://developers.facebook.com/bugs/1894024420610804

Laut der Antwort von Facebook sollte jede Seite, die auf Facebook geteilt wird, erwarten, dass Facebook-Crawler bei geteiltem Inhalt den Datenverkehr um das 10-20-fache erhöhen.

Dies klingt so, als würde Facebook den Inhalt jedes Mal, wenn darauf zugegriffen wird, kratzen, ohne dass ein Caching stattfindet.

In unserem Fall ist Facebook wahrscheinlich insgesamt gut für Werbung, dies ist jedoch eine enorme Belastung, wenn Sie eine datenbankintensive Seite betreiben, die gemeinsam genutzt wird. Wir müssen den Datenverkehr auf unser Ende beschränken, um einen Denial-of-Service-Angriff zu verhindern. Eine ressourcenintensive Antwort auf Facebooks Over Active Bot.

1
L Martin

Quellen sagen, dass Facebook/Externalhit die Crawling-Verzögerung in robots.txt nicht berücksichtigt, da Facebook keinen Crawler verwendet, sondern einen Scraper.

Wenn eine Ihrer Seiten auf Facebook geteilt wird, wird Ihre Website nach Ihrem Metatitel, Ihrer Beschreibung und Ihrem Bild durchsucht.

Ich schätze, wenn Facebook Ihre Website in 15 Minuten 11.000 Mal schabt, ist das wahrscheinlichste Szenario, dass jemand herausgefunden hat, wie der Facebook-Schaber für DDOS Ihre Website missbraucht werden kann.

Vielleicht führen sie einen Bot aus, der immer wieder auf Ihren Freigabe-Link klickt, und Facebook kratzt Ihre Seite jedes Mal, wenn dies der Fall ist.

Das erste, was ich tun würde, ist, die Seiten, die Facebook kratzt, zwischenzuspeichern. Sie können dies in htaccess tun. Dadurch wird Facebook hoffentlich angewiesen, Ihre Seite nicht mit jeder Freigabe zu laden, bis der Cache abläuft.

Aufgrund Ihres Problems würde ich den Ablauf von HTML auf länger als gewöhnlich einstellen

In .htaccess:

<IfModule mod_expires.c> 
  ExpiresActive On
  ExpiresDefault "access plus 60 seconds"
  ExpiresByType text/html "access plus 900 seconds"

</IfModule>

Wenn Sie HTML so einstellen, dass es nach 900 Sekunden abläuft, kann Facebook hoffentlich nicht mehr als einmal pro 15 Minuten eine einzelne Seite crawlen.


Bearbeiten: Ich habe eine Schnellsuche durchgeführt und eine Seite gefunden, die vor einigen Jahren geschrieben wurde und genau das Problem behandelt, auf das Sie gerade stoßen. Diese Person entdeckte, dass Websites vom Facebook-Scraper über die Share-Funktion überflutet werden könnten. Er hat es Facebook gemeldet, aber sie haben beschlossen, nichts dagegen zu unternehmen. Vielleicht sagt Ihnen der Artikel klarer, was mit Ihnen passiert, und vielleicht kann er Sie in die richtige Richtung führen, wie Sie mit der Situation umgehen möchten:

http://chr13.com/2014/04/20/using-facebook-notes-to-ddos-any-website/

7
Michael d