Facebook-Crawler ohne Benutzeragenten, der unsere Website bei einem möglichen DoS-Angriff spammt

Auf Facebook registrierte Crawler (ipv6 mit der Endung: face: b00c :: 1) knallten unsere Website und sahen in nur 20 Minuten Zehntausende von Treffern. Wir haben festgestellt, dass sie keinen Benutzeragenten im Header haben, und haben eine Regel für Cloudflare implementiert, um uns selbst zu schützen.

Es scheint, dass sie den Crawler gepatcht und einen Benutzeragenten 'Externalhit / 1.1' hinzugefügt haben, der ein anerkannter Crawler ist. Jetzt umgehen sie die Regel, ich sehe 11.000 Treffer in 15 Minuten. Oft mehrmals auf dieselbe Seite! Dies lähmt unsere Datenbank. Dies verhindert, dass Kunden die Website rechtmäßig nutzen.

Wir haben einen breiten Block für alle IP-Adressen von Facebook implementiert, um dies zu beheben, aber wir haben wahrscheinlich bereits das Geschäft verloren.

Meine Frage ist: Hat das schon mal jemand gesehen? Irgendeine Idee, was es verursacht? 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 landeten in einer URL nur für Sitzungen.

Edit3: Facebook scheint den Fehler bestätigt zu haben und sucht nach einer Lösung .

— L Martin
quelle

Ich möchte nur aktualisieren, dass dies noch andauert und ein verheerender DDOS-Angriff in Kraft ist. Wir erhalten über 1000 Treffer pro Sekunde für eindeutige URLs, die nicht zwischengespeichert werden können. Selbst wenn wir sie auf 499 Antwortcodes beschränken, hämmern sie uns weiter. Eine andere Berichts-URL: developer.facebook.com/support/bugs/1259828030848113

— jerclarke

Bemerkenswert: Ich sehe die No-UA-Treffer nicht mehr, jetzt sind die, die ich bekomme, immer facebookexternalhitmindestens von einer Vielzahl von IPs, die auf FB zurückgehen.

— Jerclarke

Antworten:

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 Metatitel, Beschreibung und Bild durchsucht.

Ich vermute, wenn Facebook Ihre Website in 15 Minuten 11.000 Mal abkratzt, ist das wahrscheinlichste Szenario, dass jemand herausgefunden hat, wie der Facebook-Scraper für DDOS auf Ihrer Website missbraucht werden kann.

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

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

Aufgrund Ihres Problems würde ich den HTML-Ablauf 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 festlegen, dass HTML nach 900 Sekunden abläuft, wird Facebook hoffentlich daran gehindert, eine einzelne Seite mehr als einmal pro 15 Minuten zu crawlen.

Bearbeiten: Ich habe eine schnelle Suche durchgeführt und eine Seite gefunden, die vor einigen Jahren geschrieben wurde und genau das Problem beschreibt, auf das Sie jetzt stoßen. Diese Person entdeckte, dass Websites durch seine Freigabefunktion vom Facebook-Scraper ü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/

— Michael d
quelle

Gute Herangehensweise an das Problem

— Emirodgar

Mir ist auch aufgefallen, dass wenn Sie nichts gegen das Problem unternehmen und Facebook Ihren Server weiterhin überflutet, dies möglicherweise als DDOS-Angriff vor Gericht angesehen werden kann und Sie und Ihr Unternehmen für die Zerstörung Ihres Unternehmens durch finanziell entschädigt werden könnten Facebook-Server.

— Michael d

Wir verwenden Cloudflare, aber viele dieser Seiten können Antworten nicht zwischenspeichern. Sie sind für Tickets und müssen zu 100% auf dem neuesten Stand sein. Der "Schaber" geht auch in unseren Zahlungsprozess ein - was alarmierend ist. Das ist ein klares Nein-Nein in unserer robots.txt. Es bedeutet auch, dass Sitzungen auf unserem Server erstellt werden !!!

— L Martin

Ich habe die URL gelesen, die ich in meine Nachricht aufgenommen habe, nach Schlüsselwörtern gesucht und dann im Internet gesucht, ob jemand eine Lösung für dieses Problem gefunden hat, außer die IP-Adresse von Facebook insgesamt zu blockieren.

— Michael d

Ich glaube nicht, dass es mit dem Nachrichtenartikel über die Sicherheitslücke in FB Notes zusammenhängt. Hier geht es speziell um das Einfügen von Mediendateien, was hier nicht das Problem zu sein scheint. Das Problem ist, dass FB ganze Domänen ohne Rücksicht auf robots.txt oder rel = nofollow spidert. Unser Server ist mit Anfragen überfordert, viele an nutzlose alte URLs, die niemand jemals teilen würde.

— Jerclarke

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

Laut der Antwort von Facebook sollte jede auf Facebook freigegebene Seite erwarten, dass Facebook-Crawler den Verkehr um das 10- bis 20-fache dieser Anzahl von Freigaben erhöhen, wenn ihr Inhalt freigegeben wird.

Das hört sich so an, als würde Facebook den Inhalt bei jedem Zugriff abkratzen, ohne dass ein Caching vorhanden ist.

In unserem Fall ist Facebook wahrscheinlich insgesamt gut für Werbung geeignet. Dies ist jedoch eine enorme Belastung, wenn Sie eine datenbankintensive Seite betreiben, die gemeinsam genutzt wird. Wir müssen den Datenverkehr auf unserer Seite begrenzen, um einen Denial-of-Service-Angriff zu verhindern. Eine ressourcenintensive Antwort auf Facebooks überaktiven Bot.

— L Martin
quelle

Holy Moly, was für ein Durcheinander! Eine solche irrationale Ablehnung von Facebook über das Problem, wie können sie das nicht akzeptieren, ist verheerend schlimm?!

— Jerclarke