Wie lässt sich ein AWS-Bot stoppen, der 2 Milliarden Anfragen pro Monat sendet?

• In einer AWS-Infrastruktur trat unerwartet ein Problem mit massiven Webanfragen auf
• Es wurde ein sprunghafter Anstieg des Traffics von 200 Millionen auf 2 Milliarden pro Monat gemeldet
• Die Log-Analyse zeigte wiederholte Anfragen von einem bestimmten User-Agent
• Zwar wurde der AWS-Support kontaktiert, doch eine klare Lösung blieb aus
• Es besteht Bedarf, verschiedene Blockierungsmaßnahmen wie Firewall-Regeln, User-Agent-Sperren usw. zu prüfen

---

Problemüberblick

• Ein AWS-Nutzer stellte eine Frage zu einem Vorfall, bei dem auf einem Webserver innerhalb eines Monats 2B (2 Milliarden) Anfragen auftraten
• Diese Anfragen stammten von einem Bot mit einem bestimmten User-Agent und stellen anomalen Traffic dar, der nicht dem normalen Nutzungsmuster entspricht
• Der plötzliche Traffic-Anstieg birgt das Risiko steigender Kosten und zusätzlicher Systemlast

Ursachenanalyse

• Der Großteil der enormen Zahl an Anfragen kam aus verdächtigen AWS-IP-Bereichen
• Durch die Zugriffsprotokolle wurde festgestellt, dass ein bestimmter Bot oder ein Skript die Ursache ist
• Im User-Agent gibt es gemeinsame Muster, wodurch Filterung möglich ist

Bisherige Reaktion und Grenzen

• Der AWS-Support wurde kontaktiert, konnte jedoch keine entscheidende Lösung liefern
• Solch eine große Zahl an Anfragen erhöht das Risiko von Service-Störungen und steigenden Kosten

Lösungsansatz und Überlegungen

• Es wird geprüft, verschiedene Sperrmaßnahmen einzuführen, darunter zusätzliche Firewall-Regeln, Blocking auf Basis des User-Agent und IP-Blacklists
• Langfristig wird die Notwendigkeit gesehen, das Traffic-Monitoring zu verstärken und ein System zur Erkennung und automatischen Blockierung ungewöhnlicher Zugriffe aufzubauen

[GN⁺]

Hacker-News-Kommentar

• Ich habe schon einmal 30x-Redirects ausprobiert, etwa indem ich per 301-Antwort auf sehr große Dateien umgeleitet habe, die von Firmen gehostet werden, die ich nicht mag. Wenn man eine AWS-Instanz dazu bringt, 70.000 Windows-ISOs gleichzeitig herunterzuladen, würden sie das sicher bemerken. Außerdem kann man, auch wenn das mit Cloudflare nicht so einfach ist, die sogenannte „Tarpit“-Strategie verwenden: Nach Eingang einer Anfrage wird die Antwort Zeichen für Zeichen gesendet, mit 30 Sekunden Verzögerung pro Zeichen. Bei 10 KB Header/Antwort pro Anfrage und 700 Anfragen pro Sekunde würde der Server extrem langsam wirken.
  • Falls dir die jeweilige Firma als 301-Ziel nicht gefällt, würde ich etwas wie Amazon empfehlen.
  • Die Strategie, eine Anfrage anzunehmen und dann Zeichen für Zeichen langsam zu senden, ist im Grunde das genaue Gegenteil eines Slow-Loris-DDoS-Angriffs. Eine Erklärung zu Slow Loris gibt es bei Cloudflare. Der Angriff erfolgt also nicht mit langsamen Verbindungen, sondern die Verteidigung antwortet mit langsamen Verbindungen.
  • Alternativ könnte man auch per 301 auf eine offizielle Regierungsseite unter .sg umleiten, damit sich die örtlichen Strafverfolgungsbehörden darum kümmern.
  • Es wird darauf hingewiesen, dass eingehender Traffic bei AWS kostenlos ist. Selbst wenn der Instanzinhaber also riesige Datenmengen empfängt, entstehen AWS dadurch keine zusätzlichen Kosten.
• Eine weitere Möglichkeit ist, den Betrieb eines eindeutig bösartigen Bots kostenseitig schmerzhaft zu machen. Besonders Methoden wie eine gzip bomb wirken, wenn der Bot dafür anfällig ist. Aber schon ein einfaches Warten von etwa 10 Sekunden vor der Antwort kann auf dem Server des Bots ungefähr 7.000 Ports belegen. Die meisten Linux-Prozesse halten das nicht aus und sterben. Mit nginx + mod-http-echo ist das leicht umzusetzen.
  • Es gibt tatsächlich Leute, die diese Strategie bereits implementiert haben. Das sieht man an den User-Agent-Listen im Open-Source-Code, und die Implementierung selbst ist sehr einfach. Den Quellcode gibt es hier.
  • AWS-Kunden zahlen für ausgehenden Traffic, aber ich frage mich umgekehrt auch, ob es eine Möglichkeit gibt, große Datenmengen von AWS oder Cloudflare an uns zu senden.
  • Ich hatte eine ähnliche Situation. Wiederholtes bösartiges Scraping zielte auf die Preisinformationen unserer Website, und wir hatten Millionen Katalogprodukte, deren Preise dynamisch berechnet wurden, was enorme Ressourcen verbrauchte. Eine plötzliche Flut von Anfragen hätte unsere Infrastruktur beinahe lahmgelegt. Als Abwehrstrategie versuchten wir, Spam-Traffic per Tagging zu unterscheiden und so zu cachen, dass echte Kunden nicht beeinträchtigt werden. Zusätzlich diskutierten wir, den Preisen zufällige Fehlerwerte hinzuzufügen, um die Daten selbst wertlos zu machen. Am Ende blieb es bei einer Zusammenarbeit mit Cloudflare, um bösartige Anfragen schnell zu blockieren, aber der Zeit- und Kostenaufwand war hoch. Der Angreifer schien ein ausgelagerter Dienst eines Konkurrenten zu sein, obwohl eine offizielle API verfügbar gewesen wäre, was es umso frustrierender machte, dass niemand direkt nachfragte. Früher herrschte bei solchen Problemen eher die Haltung „Wenn du den Traffic nicht aushältst, ist die Website schuld“, aber heute scheint sich die Wahrnehmung deutlich geändert zu haben.
  • Ich frage mich, ob dabei nicht auch auf meinem Server 7.000 Ports verbraucht werden.
  • Ist bei dieser Technik nicht auch mein Server mit derselben Menge an Verbindungen belastet?
• Ich bin der Hauptautor von Anubis. Ich habe die Erfahrung gemacht, dass der Bot aufhört, weiter auf einen einzuschlagen, sobald man Cloudflare so konfiguriert, dass ein HTTP-200-Response zurückgegeben wird.
  • Übrigens scheint es gerade ein Problem mit der Hauptseite zu geben.
  • Ich habe auch ausprobiert, auf Anwendungsebene erkannte Verbindungen sofort hart zu kappen. Wenn die Cloudflare-Konfiguration schwierig ist, scheint das gegen primitive Bots zu funktionieren.
• Ich hatte vor Jahren auf meinem privaten Blog etwas Ähnliches. Vor 7 oder 8 Jahren schoss der Traffic plötzlich hoch, und ich dachte erst, der Blog sei viral gegangen, aber das Muster wirkte zu mechanisch. Bei der Suche nach der Ursache stellte sich heraus, dass irgendein Bot/Crawler testweise meine Seite scrape-te. Nach mehreren höflichen Bitten über Monate hinweg ohne Wirkung habe ich den Bot schließlich per Redirect auf zufällige Pornoseiten umgeleitet, woraufhin das Crawling aufhörte.
  • Das ist praktisch die beste Methode. Leite den Crawler einfach auf Dinge um, die er nicht in seinen Logs haben will, oder auf sich selbst, seinen Anbieter oder unerwünschte Inhalte.
• Es wäre auch eine ziemlich befriedigende Rache, in einen 200-Response den EICAR-Teststring im Body einzubauen, um Datenkontamination auszulösen. Siehe die Erklärung zur EICAR-Testdatei.
  • Sozusagen das Gegenteil eines SSRF-Angriffs: Es wäre lustig, den Bot auf eine Cloud-Metadata-API umzuleiten, damit er einen Endpoint wie <shutdown> aufruft. Man könnte sogar den EICAR-Teststring in die Redirect-Antwort aufnehmen, damit auch automatische Security-Erkennungssysteme anspringen.
• Wenn man ohnehin nie legitimen Traffic aus AWS Singapore erhält, wäre auch ein komplettes Blackholing dieses Bereichs eine Option.
  • Man kann die Pakete einfach mit einer WAF droppen. Die „block“-Funktion der Cloudflare WAF ist genau dafür da.
  • Ich habe das früher auch so gemacht. Der von Byte Dance betriebene Byte Spider hat Millionen Bilder abgesaugt, und ich habe schließlich sogar bei Cloudinary gebeten, den User Agent zu blockieren, und anfangs ganz Singapore gesperrt. Ich war wirklich wütend darüber, wie bösartig Bots von AI-Scraping-Firmen betrieben werden. Mit einem guten Dienst wie Cloudinary konnte ich wenigstens Kosten sparen, und inzwischen blocke ich einfach alle AI-Bots über Cloudflare.
  • Zur Referenz: Die IP-Bereiche je AWS-Region findet man hier.
• 2018 hatte ich etwas Ähnliches in viel kleinerem Maßstab. Ich habe ein Tool gebaut, das die offizielle AWS-IP-Range-JSON-Liste einliest und diese Bereiche in der Windows Firewall blockiert. Den zugehörigen Blogpost gibt es hier, und das Readme des Tools kann man hier ansehen. Es lief jahrelang als geplanter Task auf meinem Server, aber ich bin mir nicht sicher, ob es heute noch funktioniert. Falls Interesse besteht, könnte ich den Code veröffentlichen oder an jemand anderen übergeben. Selbst umzusetzen ist es nicht besonders schwierig. Viel Glück.
• Die Telekommunikationsaufsicht in Singapur verbietet sogar schon den bloßen Besitz von Pornografie. Daher der Vorschlag, einem bösartigen Bot als Gegenmaßnahme Softcore-Inhalte zu schicken und gleichzeitig eine Meldung an die Behörde und an AWS per E-Mail zu senden.
  • Wenn jemand im Internet wiederholt Schaden anrichtet, ist es am wirksamsten, mit den Gesetzen des betreffenden Landes zu arbeiten. Von anderen Stellen ist meist kaum irgendeine Maßnahme zu erwarten.
• Wenn man Cloudflare mitteilt, dass der Traffic bösartig ist, kann dort außerhalb des eigenen Accounts blockiert werden, sodass die Belastung nicht in den eigenen Traffic-Zahlen landet.
• Ich hatte etwas Ähnliches: Es wurden in riesiger Menge Requests für einen 80-MB-Software-Installer gestellt. Ich habe die betreffenden Anfragen auf eine Datei namens „please-stop.txt“ umgeleitet und in der Datei die Situation erklärt und darum gebeten, aufzuhören — und tatsächlich haben sie aufgehört.