Slowloris-Angriff: So funktioniert er, so prüfen Sie Ihre Abwehr

Ein Slowloris-Angriff kann einen Webserver von einem einzelnen Laptop an einem Heimanschluss aus lahmlegen. Er sendet fast keine Daten, erzeugt fast keine Anfragen pro Sekunde und hat mit dem Datenverkehr, gegen den Ihr DDoS-Schutz beschafft wurde, nichts gemein.

Genau darin liegt das Problem. Die meisten Schutzmassnahmen sind auf Volumen ausgelegt: Gigabit pro Sekunde, Anfragen pro Sekunde, Pakete pro Sekunde. Slowloris erreicht sein Ziel gerade dadurch, dass er so wenig wie möglich sendet, so langsam wie möglich und so lange wie möglich. Verwendet Ihr Schutz die Rate als Schlüssel, läuft dieser Angriff daran vorbei, ohne eine Schwelle zu berühren.

Dies ist der erste Beitrag einer Serie über die zehn Simulationstypen, die Obsidio durchführt – einer je Angriff. Sie setzen an ganz unterschiedlichen Stellen an, und genau deshalb braucht ein Testprogramm Abdeckung über die Kategorien hinweg statt Masse in einer einzigen. Wie sie zusammenspielen und wie Sie einen ersten Durchlauf aufbauen, steht in unserem Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was ein Slowloris-Angriff tatsächlich tut

Slowloris öffnet viele parallele TCP-Verbindungen zu einem Webserver und weigert sich dann, auch nur eine davon zu Ende zu bringen. Jede Verbindung sendet den Anfang einer HTTP-Anfrage – die Request-Zeile und einen Host-Header – und schickt danach alle paar Sekunden eine weitere Header-Zeile nach. Die abschliessende Leerzeile, die dem Server sagt «die Anfrage ist vollständig, du kannst sie jetzt verarbeiten», trifft nie ein.

Der Server tut das Naheliegende: Er wartet. Er hält die Verbindung offen, hält ihr einen Worker oder einen Platz im Verbindungspool zugewiesen und wartet auf den Rest einer Anfrage, der nie kommt. Rechnen Sie das mal ein paar hundert Verbindungen, und der Pool ist voll. Echte Nutzer bekommen dann einen Timeout und keine Fehlerseite, weil der Server gar nicht erst so weit kommt, sie zu bedienen.

Stellen Sie sich zwanzig Leute vor, die in einem Geschäft anrufen, jeweils eine Bestellung beginnen und dann jeden Satz so in die Länge ziehen, dass das Gespräch nie endet. Das Personal bleibt höflich in der Leitung. Niemand sonst kommt durch.

Neu ist die Technik nicht. Das ursprüngliche Slowloris-Werkzeug erschien am 17. Juni 2009, und es funktioniert bis heute, weil das, was es ausnutzt, kein Fehler ist. Es ist eine Annahme, die tief in der Verbindungsbehandlung von HTTP-Servern steckt: dass ein Client, der zu sprechen begonnen hat, auch vorhat, fertig zu werden.

Welche Ihrer Schutzmassnahmen das hätte abfangen müssen

Es lohnt sich, die ganze Kette abzugehen, die eine Anfrage durchläuft, denn die Antwort liegt selten bei der Massnahme, die man erwartet. Drei Gruppen zählen: was der Last vorgelagert ist, was auffängt, was durchkommt, und ob Ihnen überhaupt etwas meldet, dass es passiert ist.

Diese letzte Gruppe entdecken Teams meist spät. Eine Massnahme, die greift, aber unsichtbar bleibt, ist ebenso ein Befund wie eine, die versagt, ohne dass es jemand bemerkt.

Vier Vektoren, vier verschiedene Versagensmuster

«Slowloris» wird oft behandelt, als wäre es ein einziger Angriff. In der Praxis hat das Offenhalten einer Verbindung mehrere eigenständige Formen, und ein Server oder Proxy, der gegen eine gehärtet ist, kann gegen eine andere trotzdem verwundbar sein. Die Slowloris-Simulation von Obsidio führt vier davon aus:

• Slow Header. Der Klassiker. Er sendet GET /path HTTP/1.1 und einen Host-Header, schickt dann je Intervall eine Header-Zeile nach und sendet den Abschluss nie. Der Server bleibt im Zustand «Lese Request-Header» stehen.
• Slow POST. Er sendet einen vollständigen, gültigen POST-Header-Block mit Transfer-Encoding: chunked, schickt dann je Intervall einen Chunk von einem Byte nach und sendet den Chunk der Länge null, der den Body beendet, nie. Die Header sind fertig, ein Timeout für das Lesen der Header greift also nicht.
• Slow Read. Er sendet eine vollständige, vollkommen gültige Anfrage und hört dann auf, die Antwort zu lesen. Der Empfangspuffer des Clients füllt sich, der Sendepuffer des Servers staut sich, und die Verbindung lässt sich nicht abbauen. An der Anfrage ist nichts fehlerhaft; der Angriff findet auf der Leseseite statt.
• Slow Drop. Er sendet eine gültige Keep-Alive-Anfrage, bleibt untätig und reisst die Verbindung dann zu einem zufälligen Zeitpunkt abrupt ab. Das bringt reset-artige Fluktuation in die Verbindungstabelle statt gleichmässiger Belegung und belastet damit Verbindungsabbau und Buchführung statt der Kapazität.

Die Unterscheidung zählt, sobald Sie eine Gegenmassnahme konfigurieren. Ein Timeout für das Lesen der Header stoppt Slow Header und richtet gegen Slow Read nichts aus. Ein Timeout für den Body stoppt Slow POST und richtet gegen die beiden anderen nichts aus. Einen Vektor zu prüfen und die Klasse damit für erledigt zu erklären – so werden Teams am Ende überrascht.

Welche Server verwundbar sind

Die Anfälligkeit hängt von der Architektur ab. Server, die je Verbindung einen Thread oder Prozess reservieren, gehen ihnen aus; ereignisgesteuerte Server multiplexen die Verbindungen und verlieren ihre Leistung weit gnädiger.

Apache 1.x und 2.x sind der klassische verwundbare Fall aus der ursprünglichen Offenlegung, dazu dhttpd und der Entwicklungsserver von Flask. Als widerstandsfähig dokumentiert sind nginx, lighttpd, Hiawatha, Cherokee und IIS. «Widerstandsfähige Architektur» ist aber nicht dasselbe wie «sichere Installation»: nginx wird nach wie vor mit den Standard-Timeouts client_header_timeout 60s und client_body_timeout 60s ausgeliefert, also 60 Sekunden freie Belegung je Verbindung, und ein Anwendungsserver hinter dem Proxy hat womöglich überhaupt keinen solchen Schutz.

Prüfen Sie, was in Ihrem System die Verbindung tatsächlich beendet, und nicht, was die Marketing-Seite einer einzelnen Komponente behauptet.

Wie Sie sich gegen einen Slowloris-Angriff schützen

Bei der Abwehr geht es darum, nicht unbegrenzt zu warten, und darum, zu begrenzen, wie viel ein einzelner Client belegen darf. Vier Massnahmen leisten den grössten Teil der Arbeit:

• Timeouts für unvollständige Anfragen. Bei Apache ist mod_reqtimeout die direkte Antwort. Geladen lauten seine Standardwerte RequestReadTimeout handshake=0 header=20-40,MinRate=500 body=20,MinRate=500. Das setzt eine Mindestdatenrate und nicht bloss eine Frist – und erst das würgt ein häppchenweises Senden wirklich ab. Vergewissern Sie sich, dass das Modul geladen ist; verfügbar ist nicht dasselbe wie aktiv.
• Mindestdatenrate statt blosser Frist. Eine feste Frist lässt sich aushebeln, indem gerade schnell genug nachgeschickt wird. Eine Untergrenze für die Rate nicht.
• Verbindungslimits je IP-Adresse. Begrenzen Sie die gleichzeitigen Verbindungen je Quelle, damit ein einzelner Client keinen nennenswerten Anteil des Pools belegen kann. Gegen ein Slowloris aus einer einzigen Quelle wirkt das; gegen ein verteiltes deutlich schwächer – und der verteilte Fall ist der, den zu prüfen sich lohnt.
• Ein puffernder Reverse Proxy oder ein CDN. Ein Proxy, der die Anfrage vollständig puffert, bevor er sie weiterleitet, hält die unvollständige Anfrage in seiner eigenen Verbindungstabelle fest und weckt Ihren Ursprungsserver nie. Das ist ein starker Schutz, solange der Ursprungsserver nicht direkt erreichbar ist. Eine über einen Proxy ausgelieferte Website mit offen liegender IP-Adresse des Ursprungsservers ist nicht geschützt.

Jeder dieser Werte steht in irgendeiner Konfigurationsdatei, und damit kann jeder davon falsch sein, veraltet oder von einer späteren Änderung überschrieben, die niemand nachgeprüft hat.

Was Sie selbst prüfen können – und was dabei danebengeht

Drei dieser Fragen können Sie heute ohne fremde Hilfe beantworten. Es lohnt sich zu wissen, welche das sind – und zu wissen, wo eine billige Prüfung Sie in die Irre führt.

Lesen Sie die Konfiguration. Bestätigen Sie, dass das Timeout-Modul geladen ist, sehen Sie sich die tatsächlichen Werte an, prüfen Sie, ob Ihr Proxy puffert. Das sagt Ihnen, dass die Einstellung existiert. Es sagt Ihnen nicht, dass sie hält, wenn viele Verbindungen gleichzeitig offen sind, und das ist eine andere Aussage.

Prüfen Sie den Alarmweg für sich allein. Lösen Sie einen synthetischen Alarm aus und sehen Sie nach, ob er den richtigen Pikettdienst erreicht und ob jemand handelt. Damit prüfen Sie den Meldeweg tatsächlich, und Angriffsverkehr brauchen Sie dafür überhaupt nicht.

Führen Sie einen Test aus einer einzigen Quelle gegen eine Staging-Umgebung durch, mit Freigabe aus dem Change-Management, auf Infrastruktur, die Ihnen gehört. Das ist zulässig und nützlich. Und genau hier liegt die Falle.

Ein Test von einer Maschine lässt die vorigen Fragen nicht nur offen. Er beantwortet mehrere davon falsch, und zwar beruhigend falsch. Ihr Verbindungslimit je IP-Adresse fängt eine einzelne Quelle sofort ab. Die Bot-Erkennung markiert einen einzelnen auffälligen Client. Die Reputationsfilterung sortiert ihn aus. Jede Massnahme der ersten Gruppe scheint zu greifen, und Sie schliessen daraus, dass Sie abgesichert sind.

Dann trifft ein echter verteilter Angriff aus Tausenden von Adressen in Privathaushalten ein, und dieselben Massnahmen verhalten sich völlig anders, weil sie an der Konzentration der Quelle und an der Echtheit des Verkehrs ansetzen – und genau das kann eine einzelne Maschine nicht nachbilden. Die billige Prüfung erzeugt ein falsches Bestanden bei genau den Massnahmen, denen Sie am meisten vertrauen müssen.

Dieselbe Schieflage gilt für die Erkennung. Ein synthetischer Alarm belegt, dass der Meldeweg funktioniert. Er kann Ihnen nicht sagen, ob Ihre Dashboards während eines echten langsamen Angriffs überhaupt etwas zeigen oder ob Ihr Logging ihn erfasst, denn diese Fehler hängen daran, dass der Verkehr echt ist.

Wie Sie prüfen, ob Ihre Slowloris-Abwehr funktioniert

Aus einer Konfigurationsprüfung lässt sich das nicht ableiten. Ob der Pool tatsächlich hält, entscheidet sich im Zusammenspiel von Proxy, Webserver, Anwendungsserver und Verbindungslimits bei echter Parallelität, und dieses Zusammenspiel zeigt keine einzelne Konfigurationsdatei.

Obsidio führt Slowloris als kontrollierte, autorisierte Simulation gegen Infrastruktur durch, die Ihnen gehört. Die Domain-Inhaberschaft wird über einen DNS-TXT-Eintrag geprüft, bevor Verkehr fliesst; die Durchläufe fahren schrittweise hoch, und jeder Durchlauf lässt sich im Betrieb abbrechen. Sie wählen den Vektor, die Zahl der je Worker offen gehaltenen Sockets und das Intervall, in dem nachgeschickt wird, und beobachten dann, was Ihr System tut. Weil die Last von über 100’000 weltweit verteilten echten Geräten kommt und nicht von einer Handvoll Instanzen im Rechenzentrum, wird ein Verbindungslimit je IP-Adresse so geprüft, wie ein tatsächlicher verteilter Angriff es prüfen würde.

Zwei Punkte, die während des Durchlaufs zählen und über die regelmässig gestolpert wird:

• Lassen Sie die Kurve der Anfragerate beiseite. Bei einem langsamen Angriff zählt die Rate geöffnete Verbindungen und nicht Durchsatz. Sie bleibt niedrig, gerade während der Angriff wirkt. Verfolgen Sie stattdessen die gleichzeitig offen gehaltenen Verbindungen und die Spitzenzahl der Verbindungen; das ist die Kennzahl, an der Sie sehen, ob sich der Pool füllt.
• Messen Sie von aussen. Serverseitige Kennzahlen können ruhig aussehen, während echte Nutzer in der Warteschlange in den Timeout laufen. Bestätigen Sie den Effekt mit einer unabhängigen Anfrage von ausserhalb Ihres eigenen Netzes.

Planen Sie auch die Fragen zur Erkennung ein. Obsidio kann berichten, wie Ihre Schutzmassnahmen am Netzrand reagiert haben und wie viele Verbindungen offen gehalten wurden, weil das von aussen sichtbar ist. Ob Ihr SIEM etwas aufgezeichnet hat und ob jemand alarmiert wurde, wissen nur Ihre eigenen Konsolen – lassen Sie deshalb während des Zeitfensters jemanden darauf schauen.

Stärke wird bewiesen, nicht versprochen. Slowloris prüft nicht Ihre Bandbreite. Er prüft, ob seit dem Tag, an dem Ihre Verbindungs-Timeouts gesetzt wurden, überhaupt jemand sie nachgesehen hat.

Wo das in ein Testprogramm gehört

Slowloris gehört zur Kategorie der langsamen Angriffe, neben RUDY, das statt eines Header-Blocks einen Request-Body aushungert. Beide sondieren die Verbindungsbehandlung und die Timeout-Konfiguration. Keinen von beiden deckt ein Flood-Test auf der Anwendungsschicht ab, und deshalb lässt ein Programm, das nur HTTP-Floods durchführt, diese ganze Klasse ungeprüft.

Die zehn Simulationstypen führen an ganz unterschiedlichen Stellen zum Ausfall. Ein HTTP-Flood-Angriff kehrt fast alles Obige um: Die vorgelagerten Schutzmassnahmen haben endlich ein Signal, an dem sie ansetzen können, der Schaden reicht bis in Ihren Datenbank-Verbindungspool, und bei der Erkennung kippt das Problem ins Gegenteil – statt Stille eine Flut von Alarmen. Entscheidend ist die Abdeckung über die Kategorien hinweg, nicht die Masse in einer einzelnen.

Für regulierte Institute muss der Testlauf zudem einen Nachweis hinterlassen. Obsidio erstellt kryptografisch attestierte, manipulationssichere Berichte, die FINMA, DORA und NIS2 zugeordnet sind und in Trusted Execution Environments entstehen – das Ergebnis eines Durchlaufs ist damit ein Beleg für die Akten und kein Screenshot, für dessen Echtheit Sie geradestehen müssen.

Um den Prüfumfang einer autorisierten Slowloris-Simulation gegen Ihre eigene Infrastruktur festzulegen, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.