Inhalt
Seit einiger Zeit beobachten wir bei einem unserer Kunden aus dem öffentlichen Sektor einen ungewöhnlichen Effekt: Die Zahl der Unique IPs ist sprunghaft angestiegen, von den üblichen 2.000 bis 2.500 auf regelmäßig 5.000 bis 8.000 in den Spitzenzeiten. Wer bei dieser Verdopplung der Besucherzahlen eine proportionale Zunahme der Anfragen und der benötigten Bandbreite erwartet, erlebt eine Überraschung: Die Bandbreite und das Request-Volumen steigen nur moderat (in diesem Fall um den Faktor 1,3 bis 1,7), während die Zahl der Unique IPs quasi konstant erhöht bleibt.
Dies ist mehr als eine statistische Fußnote. Es ist ein Hinweis auf ein durch Bots ausgelöstes Phänomen mit unerwarteter Struktur.
Wie sieht das Phänomen aus?
Beim Kunden zeigt sich seit dem Stichtag ein anhaltender Anstieg der Unique IPs, der nicht nur von kurzer Dauer ist.
Die Metriken im Überblick: Die Anzahl der Unique-IPs verdreifacht sich stellenweise, die Anzahl der Requests steigt nur um etwa 50 bis 70 Prozent und die Bandbreite um etwa 30 bis 70 Prozent. Gleichzeitig verschlechtert sich die Antwortzeit des Origin-Servers: Es gibt größere Durchschnittswerte, mehr Spitzen und gelegentlich mehr 500er-Fehler. Klassische Indikatoren für einen massiven Download von Inhalten (Bilder, Skripte) fehlen jedoch, die Profilverschiebung des Webseiten-Traffics ist subtil und widersprüchlich.
Warum ist diese Diskrepanz auffällig?
Steigen die echten Nutzerzahlen, nehmen Bandbreite und Request-Volumen in etwa gleichmäßig zu. Browser laden nämlich nicht nur HTML-Seiten, sondern auch Bilder, Schriften, Stylesheets, Skripte oder Videos. Das verursacht eine merklich höhere Auslastung.
Bei Bots sieht das anders aus: Sie interessieren sich meist nur für das HTML, also den „Rohtext“ der Seite. Alles, was für die Darstellung nötig ist, ignorieren sie.
Das erklärt, warum die Zahl der Unique IPs explodiert, ohne dass die Bandbreite im gleichen Maß zunimmt:
- Viele Bots erzeugen wenig Daten pro Anfrage,
- aber in Summe entsteht eine enorme Verbindungsdichte.
Ein Bot, der nur HTML lädt, verursacht pro Zugriff nur einen Bruchteil des Traffics eines echten Browsers. Wenn jedoch Tausende davon gleichzeitig anfragen, bindet das erhebliche Ressourcen.
Technische Auffälligkeiten
- Hohe Anzahl an Unique IPs, moderate Bandbreite: Anzahl der Unique IPs steigt um den Faktor 2 bis 3, Bandbreite nur um den Faktor 1,3 bis 1,7.
- Erhöhte Server-Latenzen: Die Origin-Antwortzeiten liegen im Mittel höher und weisen deutlich mehr Spitzen auf.
- Request-Mix: POST-Requests steigen prozentual von rund 1 % auf rund 3 %, ein Zeichen für Formular-/Suchmaschinen-Missbrauch.
- Source-Profile: Zunahme des Traffics von Infrastruktur-/Cloud-Providern statt Verteilung über Endkunden-ISPs.
- Geografische Anomalie: Ein großer Anteil iranischer Requests stammt fast vollständig von einem einzelnen ISP. Dabei sind 99 % eines Landesanteils von einem Provider eher ungewöhnlich.
- Keine klaren Fehlerwellen: Die 500er- und Redirect-Raten zeigen nur moderate Veränderungen, sodass kein kompletter Systemausfall vorliegt.
Plausible Erklärungen, worauf die Daten hinweisen
Die Mischung aus vielen Unique-IPs bei vergleichsweise geringer Bandbreitensteigerung passt zur Hypothese eines Botnets, das überwiegend spartanische HTTP-Requests absetzt wie etwa Suchanfragen oder Versuche, Formulare auszufüllen.
Drei Varianten sind denkbar:
- Kompromittierte Server/Cloud-VMs: Die starke Präsenz von Infrastrukturprovidern spricht dafür, dass viele Quellen leistungsfähige Server und nicht nur IoT-Geräte sind. Solche Hosts können viele Requests mit geringem Overhead erzeugen.
- Private Endkunden-Bots in einzelnen Ländern: Der stark konzentrierte Traffic aus einem einzelnen Land kann auf gezielt eingesetzte Proxies oder eine orchestrierte Aktion hinweisen.
- Langsame oder „connection-heavy“ Attacken
Auch wenn keine klassischen Slowloris-Angriffe vorliegen, kann ein ähnlicher Effekt entstehen. Viele gleichzeitige, kurzlebige Verbindungen binden Serverressourcen. Moderne Browser optimieren Verbindungen mithilfe von Keep-Alive, Multiplexing und Session-Reuse. Dadurch entsteht weniger Overhead pro Anfrage. Einfache Bots tun das nicht. Sie bauen für jede Anfrage eine neue TCP-Verbindung auf. Der Server muss jedes Mal den vollständigen Verbindungsaufbau durchführen, inklusive Handshake und TIME_WAIT-Phase.
Das Ergebnis: Tausende kurzlebige Verbindungen, die kaum Daten übertragen, aber massiv Ressourcen binden.
So kann selbst ein einfaches Botnetz die Wirkung einer Slowloris-Attacke erreichen – allein durch die schiere Anzahl an Verbindungen.
Warum Browser und Bots sich so unterschiedlich verhalten
Echte Browser sind „kooperativ“. Sie halten Verbindungen offen, bündeln Anfragen, nutzen HTTP/2-Multiplexing und verarbeiten Inhalte effizient. Bots verhalten sich genau gegenteilig: Sie öffnen viele kleine Sessions, oft ohne Keep-Alive oder Kompression, und fordern lediglich die nackten HTML-Seiten an.
So entsteht ein hohes Verbindungsvolumen bei niedriger Bandbreite – und damit genau das Muster, das in den Logs unseres Kunden sichtbar wurde. Auffällig ist außerdem, dass viele dieser Bots keine weiteren Aktionen ausführen. Sie rufen keine Bilder oder Skripte nach und interagieren nicht mit Formularen oder Cookies.
Das spricht gegen reale Nutzer und für automatisierte Crawler oder Angriffsskripte, die systematisch Endpunkte scannen oder Belastungstests durchführen.
Was bislang fehlt und warum das wichtig ist
Die aktuellen Monitoring-Daten liefern nur ein grobes Bild des Geschehens. Sie zeigen Trends, aber keine Details über das Verhalten einzelner Verbindungen. Dadurch bleibt unter anderem unklar, ob die Anfragen kurzlebig oder langanhaltend waren, wie groß die übertragenen Datenmengen pro Sitzung ausfielen und ob sich die Clients „menschlich“ verhielten oder klar maschinell agierten.
Um dies zu verstehen, ist eine detaillierte Netzwerkbeobachtung erforderlich, d. h. es müssen Metriken erfasst werden, die einzelne Sessions, Anfragetypen und Antwortzeiten erfassen. Ergänzend helfen kurze Traffic-Mitschnitte (Packet Captures) oder Flow-Daten mit höherer Auflösung, um Muster und Wiederholungen zu erkennen. Erst damit lässt sich sicher bestimmen, ob es sich um koordinierte Bots, Fehlkonfigurationen oder gezielte Belastungstests handelt.
Auch Bot-Management-Systeme oder Web Application Firewalls (WAFs) könnten hier helfen, da sie typisches Botverhalten anhand bestimmter Merkmale erkennen, beispielsweise JavaScript-Verhalten, Browseraktivität oder Cookie-Nutzung. Diese Informationen sind entscheidend, um menschliche Zugriffe von automatisiertem Traffic zuverlässig zu trennen.
Kontaktieren Sie unsere Experten und erfahren Sie, wie Sie schädliche Bots entfernen können, ohne hilfreiche Bots auszusperren. Ein bewährtes Bot-Management kann Ihnen dabei helfen.
Konkrete Sofortmaßnahmen
Um die Situation zu stabilisieren und Erkenntnisse zu gewinnen, wären folgende pragmatische Schritte zu empfehlen:
- Bot-Management & WAF: Ein Bot-Management-Tool einsetzen (oder als Interimslösung eine WAF mit Rate-Limits und Challenge-Mechanismen). CAPTCHAs für Formulare und JavaScript-Checks für Suchendpunkte reduzieren automatisierten Traffic schnell.
- Feinere Netzwerkbeobachtung: Sessionbasierte Logs und Packet Captures aktivieren, um das Verhalten einzelner Anfragen zu analysieren.
- Rate-Limits und ratenbasierte Regeln: Rate Limits auf Search- und Contact-Endpunkte, Connection-Timeouts und Keep-Alive-Limits durchsetzen.
- Provider-Kontakt: Identifizieren Sie ISPs, die ungewöhnlich viel Traffic liefern und reichen Sie Abuse-Tickets ein.
- Content-Delivery und Scrubbing: Überprüfung, ob CDN- oder Scrubbing-Dienste kurzfristig einspringen können, um besonders aktive IPs oder stark belastende Quellen (Bots oder Server) zu absorbieren.
Warum Resilienz jetzt gelernt werden muss
Dieser Fall ist ein Beispiel für die neuen, hybriden Bot-Phänomene: eine hohe Anzahl an Quellen bei geringer Bandbreite pro Quelle sowie eine gezielte Belastung von dynamischen Endpunkten – und das alles über Wochen hinweg. Klassische Schwellenalarme reichen hier nicht aus, nötig ist ein adaptives Monitoring- und Schutzkonzept.
Der Vorfall zeigt: Netzresilienz entsteht nicht durch starre Regeln, sondern durch die Fähigkeit, Verhalten zu erkennen, anzupassen und automatisiert Gegenmaßnahmen auszulösen.
Wenn Sie wissen möchten, wie gut Ihre Dienste gegen solche subtilen Bot-Angriffe geschützt sind, sprechen Sie uns an. Wir helfen Ihnen bei der Analyse und bei der Erstellung von Schutzkonzepten, damit Ihr Service nicht zum Ziel eines Angriffs wird.
Share this post
