1.4.3.3 DoS-Angriffe bei Persistent HTTP

Die Auslieferung von Webseiten erfolgt mit Hilfe von HTTPHyperText Transfer Protocol, wobei HTTP auf TCPTransmission Control Protocol basiert. Es gibt verschiedene Varianten von HTTP, die TCP-Verbindungen unterschiedlich nutzen. Aus der Sicht der Leistungsfähigkeit wäre die Verwendung von Persistent HTTP zu empfehlen, aber diese Möglichkeit kann von Angreifern zu DDoSDistributed Denial of Service-Angriffen genutzt werden.

Um dieses nachvollziehen zu können, werden an dieser Stelle, die drei HTTP-Varianten erklärt.

  • Non-persistent HTTP: Die urspüngliche HTTP-Implementierung (HTTP 1.0) stammt noch aus einer Zeit (1996), in der Webseiten sehr textlastig waren und, wenn überhaupt, nur wenige Bilder oder andere Objekte enthielten. Es wird zunächst eine TCP-Verbindung verwendet, um den Text von der Seite zu laden. Die Seite wird vom Client ausgewertet und dann wird nacheinander für jedes Objekt in der Webseite eine TCP-Verbindung geöffnet, um es zu laden. Das ganze ist relativ ineffizient, zum einen wegen der häufigen TCP-Segmente zum Beginnen und Schließen von Verbindungen (Three-Way-Handshake und Four-Way-Close) und zum anderen wegen der geringen Datenrate am Anfang von TCP-Verbindungen (Slow Start).
  • Multiple Simultaneous Connections: Vom damals führenden Browseranbieter Netscape wurde dann eine verbesserte Methode implementiert, mit der parallele TCP-Verbindungen genutzt werden. Der Text in der Webseite wird wie bisher in einer einzigen TCP-Verbindung geladen, die Objekte in der Seite jedoch mit einer Anzahl von parallelen Anfragen. Beispielsweise könnten immer sechs Objekte in parallel laufenden TCP-Verbindungen angefragt werden. Die Anzahl der insgesamt verwendeten TCP-Verbindungen bleibt jedoch gleich.
  • Persistent HTTP: Mit HTTP 1.1 wurde als empfohlene Methode das Persistent HTTP eingeführt (auch als Keep Alive bezeichnet). Hiermit wird eine TCP-Verbindung nicht nach jedem Objekt geschlossen, sondern offen gehalten bis über die Verbindung alle Objekte transferiert wurden. Damit lässt sich das häufige Öffnen und Schließen von TCP-Verbindungen vermeiden. Außerdem kann innerhalb der TCP-Verbindung eine hohe Datenrate erreicht werden, sobald die Slow Start-Phase beendet ist. Das ganze lässt sich mit Request Pipelining noch verbessern, bei dem man auch innerhalb der Verbindung gleich mehrere Objekte kurz nacheinander anfragt, ohne das jeweils vorherige Objekt schon erhalten zu haben. Diese weitere Verbesserung ist aber nicht wesentlich und begünstigt die im folgenden dargestellte Schwachstelle hinsichtlich DDoS. An dieser Stelle ist aber zu bemerken, dass Persistent HTTP nur bei Objekten möglich ist, die vom selben Server geladen werden. Moderne Webseiten enthalten aber in vielen Fällen Objekte von einer Reihe von verschiedenen Servern, so dass diese Verbesserung nur teilweise anwendbar ist.

Insgesamt bleibt dennoch soweit der Eindruck, dass das Persistent HTTP nur Vorteile bietet, insbesondere da die Nutzer eine rasche Auslieferung von Webseiten erwarten. Diese Methode hat aber den Nachteil, dass sie DDoS-Angriffe begünstigt. Dieses liegt daran, wie die TCP-Verbindungen geschlossen werden. Bei den vorherigen Methoden ist klar, wann eine Verbindung nicht mehr benötigt wird. Sie wird zur Übertragung eines Objekts benötigt und so kann der Server die Verbindung nach Beendigung der Übertragung schließen. Beim Persistent HTTP weiß der Server jedoch nicht, wieviele Objekte der Client in Zukunft noch über die Verbindung übertragen möchte. Er verlässt sich daher auf den Client, dass dieser die Verbindung schließt. Er selber hat eine relativ lange Wartezeit (z.B. 60 s), bis zu der er von sich aus die Verbindung beendet. Dieses bietet nun die Möglichkeit für DDoS-Angriffe, bei der Angreifer viele TCP-Verbindungen öffnen und diese nicht von sich aus schließen. Dadurch wird der Server, der irgendwann das Maximum der möglichen TCP-Verbindungen erreicht überlastet und kann keine weiteren TCP-Verbindungen mehr annehmen. Diese Problematik sollte man bei der Konfiguration eines Servers bedenken und entweder kein Keep Alive verwenden oder die Timeout-Zeit relativ kurz ansetzen.

Der Firefox-Browser bietet mit dem AddOn Firebug (Reiter Netzwerk) eine ausführliche Analysemöglichkeit für die TCP-Verbindungen bei der Auslieferung einer Webseite und deren zeitliche Reihenfolge. Mit dem auf Empfehlungen von Yahoo basierenden AddOn YSlow ("Warum langsam?") werden zudem Tipps gegeben, wie man als Betreiber des Servers die Auslieferung verbessern kann. YSlow wird als zusätzlicher Reiter in Firebug angezeigt. Eine vergleichbare Funktionalität wie Firebug ist im Google Chrome Browser bereits enthalten (Navigation auf der rechten Seite, weitere Tools, Entwicklertools).