Welche Methoden zur Umgehung von Rate-Limits basieren auf der Manipulation von HTTP-Keep-Alive-Headern?

Die Manipulation von HTTP-Keep-Alive-Headern zielt primär darauf ab, die Erkennung durch connection-basierte Rate-Limiter zu erschweren. Während moderne Systeme meist Request-basierte Limits (Requests pro Zeitfenster pro IP) nutzen, setzen ältere oder simpel konfigurierte Firewalls und Load Balancer auf die Überwachung der Anzahl der TCP-Verbindungen.

Durch das Senden des Headers Connection: keep-alive wird die TCP-Sitzung nach einer Antwort nicht geschlossen, sondern für weitere Requests offen gehalten. Die Manipulation erfolgt hierbei über zwei technische Ansätze:

  1. Vermeidung von Connection-Overhead: Durch die Wiederverwendung einer bestehenden Verbindung entfallen wiederholte TCP- und TLS-Handshakes. Einige Sicherheitsmechanismen triggern Rate-Limits nur bei einem hohen Aufkommen an neuen Verbindungsaufbauten (Connection Rate), nicht bei der Anzahl der Requests innerhalb einer bereits etablierten Session.
  2. Parameter-Steuerung: Über den Header Keep-Alive: timeout=X, max=Y versuchen Clients, die Server-seitige Session-Dauer zu beeinflussen. Ziel ist es, die Verbindung so lange wie möglich aktiv zu halten, um die Sichtbarkeit gegenüber Systemen zu reduzieren, die nur auf Verbindungswechsel oder neue SYN-Pakete reagieren.

Die Wirksamkeit dieser Methode hängt stark von der Architektur des Zielsystems ab:

Limit-TypFokus der ÜberwachungEffekt von Keep-Alive Manipulation
Connection-basedAnzahl paralleler/neuer TCP-SessionsHoch (Session-Reuse umgeht Trigger)
Request-basedRequests pro IP/ZeitfensterGering (Zähler läuft pro Request weiter)
Burst-basedKurzzeitige Spitzen bei HandshakesMittel (Vermeidung von Handshake-Spikes)

Im Rahmen unserer IT-Consulting & Digitale Strategie sehen wir häufig, dass eine fehlerhafte Konfiguration von Reverse Proxies (wie Nginx oder HAProxy) diese Lücke öffnet. Wenn der Proxy die Verbindung zum Backend offen hält, aber die Rate-Limits am Edge-Point nur auf Basis neuer Verbindungen prüft, können Angreifer massenhaft Requests über einen einzigen Stream senden, ohne die Connection-Limits zu überschreiten.

Wir empfehlen den Einsatz von Request-basierten Limits in Kombination mit einer strikten Überwachung der Request-Rate pro TCP-Stream. Wer sich allein auf Connection-Limits verlässt, lässt die Tür für effiziente Scraping-Bots offen. Die einzige belastbare Lösung ist die Implementierung von Token-Buckets oder Leaky-Bucket-Algorithmen auf Applikationsebene, unabhängig vom Transportzustand der TCP-Verbindung.

Sergej Wiens

Sergej Wiens

Gründer & Software Architekt