HAProxy als Verteidigungslinie: Schutz vor DDoS und Layer-7-Angriffen

Webseiten werden in der Praxis nicht nur durch klassische Sicherheitslücken angegriffen, sondern sehr häufig durch Überlastung. Für Unternehmen ist deshalb nicht nur die Frage relevant, ob eine Plattform kompromittiert werden kann, sondern vor allem, wie sie unter Last, Missbrauch und gezielten Flooding-Angriffen erreichbar bleibt. DDoS-Angriffe, HTTP-Floods, Bot-Traffic und missbrauchte Applikationsendpunkte gehören zu den häufigsten Ursachen dafür, dass Webdienste nicht mehr sauber reagieren oder komplett ausfallen.

HAProxy ist in diesem Kontext ein sehr wirkungsvolles Werkzeug, weil es auf Layer 7 präzise steuern kann, welche Clients wie schnell, wie oft und auf welche Pfade zugreifen dürfen. Gleichzeitig ist es wichtig sich die Grenzen des Werkzeugs vor Augen zu führen.

Dieser Artikel fasst die wesentlichen Punkte zusammen, die für den produktiven Betrieb einer öffentlich erreichbaren Webplattform relevant sind. Der Schwerpunkt liegt auf einer typischen Architektur mit dediziertem HAProxy-Server, vorgeschalteter Firewall und Linux-Kernel-Härtung auf dem Proxy-Host.

Layer-7- und Layer-3/4-Angriffe: Das Bedrohungsbild im Betrieb

Aus Sicht des Betriebs unterscheiden sich zwei Problemklassen deutlich. Erstens gibt es Angriffe auf die Anwendungsebene, also Layer 7: HTTP-GET/POST-Floods, Bot-Wellen, Login-Bruteforce, übermäßige API-Nutzung oder missbräuchliche Requests auf teure Endpunkte. Zweitens gibt es Netzwerk- und Transportangriffe auf Layer 3 und 4, beispielsweise SYN-Floods oder UDP-Floods, die Leitungen, Firewalls oder Kernel-Ressourcen erschöpfen.

Diese Trennung ist operativ entscheidend. Ein Layer-7-Angriff ist oft durch Semantik erkennbar: zu viele Requests pro IP, ungewöhnliche Zugriffe auf /login, auffällige User-Agents oder hohe Fehlerraten. Ein Layer-3/4-Angriff ist dagegen oft reine Volumenbelastung, bei der schon Bandbreite, Connection-Tracking oder der TCP-Handshake kollabieren, bevor eine HTTP-Logik überhaupt greift.

Für Administroren folgt daraus ein einfaches, aber wichtiges Prinzip: HAProxy ist ein exzellentes Instrument zur Steuerung und Dämpfung von Anwendungstraffic, aber keine alleinige Antwort auf große Floods. Die Architektur muss mehrschichtig sein, sonst wird der Proxy selbst zum Engpass.

Wo HAProxy stark ist: Rate Limiting und Layer-7-Schutz

HAProxy spielt seine Stärke dort aus, wo Verbindungen und HTTP-Anfragen intelligent bewertet werden müssen. Dazu gehören Rate-Limiting, per-IP-Tracking mit stick tables, ACL-basierte Regeln, Schutz sensibler Pfade und die frühzeitige Ablehnung missbräuchlicher Sessions. Genau diese Mechanismen sind für HTTP-Floods und Bot-Verhalten besonders wertvoll.

Ein typisches Beispiel ist die Begrenzung der Request-Rate pro Quell-IP. Wenn ein Client in zehn Sekunden mehrere Dutzend oder Hunderte Requests erzeugt, kann HAProxy daraus mit stick tables direkt Maßnahmen ableiten. Die einfachste Variante ist eine 429-Antwort, eine härtere Variante ist ein temporäres Tarpitting oder Rejecting auf TCP-Ebene.

Ebenso wichtig ist die segmentierte Behandlung sensibler Endpunkte. /login, /password_reset oder /api/auth sollten nie dieselben Schwellenwerte wie eine statische Startseite haben. Gute HAProxy-Konfigurationen unterscheiden daher zwischen allgemeinem Traffic und Hochrisiko-Pfaden und setzen strengere Regeln nur dort, wo sie fachlich sinnvoll sind.

Wo HAProxy an Grenzen stößt: Volumetrische DDoS-Angriffe

Sobald der Angriff primär auf Leitungskapazität, Paketverarbeitung oder TCP-Handshake zielt, muss die Hauptabwehr vor HAProxy stattfinden. Große UDP-Floods oder breite SYN-Wellen sättigen sonst die Bandbreite oder Kernel-Ressourcen des Hosts, bevor HAProxy seine eigentliche Stärke auf Anwendungsebene entfalten kann.

Daher ist eine vorgeschaltete Firewall in einer Webarchitektur nicht nur sinnvoll, sondern auch zwingend notwendig. Aber auch hier gilt: Eine Firewall, die nur TCP 80 und 443 zulässt, reduziert zwar die Angriffsfläche, ersetzt aber kein dediziertes DDoS-Mitigation-Konzept. SYN-Floods auf TCP 80 und 443 erreichen weiterhin den HAProxy. Gegen volumetrische Angriffe bleiben ISP-Mitigation, Anycast, CDN oder Scrubbing-Services die belastbarsten Optionen.

Für System Engineers ist das keine theoretische Feinheit, sondern eine saubere Zuständigkeit. Das CDN oder Scrubbing-Services absorbieren Volumen und unerwünschte Protokolle, der Linux-Kernel stabilisiert Queueing und TCP-Verhalten, und HAProxy regelt die semantische Zugriffskontrolle auf HTTP- und Session-Ebene.

Referenzarchitektur: Firewall, HAProxy und Backend im Zusammenspiel

Eine praxistaugliche Minimalarchitektur besteht aus einer Firewall vor einem oder besser zwei im Failover Cluster befindlichen dedizierten HAProxy-Server, hinter dem die eigentlichen Web- oder API-Backends liegen. Die Firewall lässt von außen nur TCP 80 und 443 zum Proxy durch; HAProxy terminiert TLS, prüft Hosts und Pfade, begrenzt Verbindungen und Requests und verteilt dann auf interne Backend-Systeme.

Diese Struktur bringt mehrere Vorteile:

• Der Proxy-Host ist klar auf Ingress und Traffic-Steuerung spezialisiert
• Die Security- und Routing-Entscheidungen werden zentral umsetzen.
• Die eigentlichen Applikationsserver sind von grobem Missbrauch entkoppelt und sehen im Idealfall nur bereits gefilterten und bewerteten Traffic.

Ein einfaches Routing-Beispiel sieht so aus: 
site.example.com geht auf ein App-Backend, /api auf ein separates API-Backend und /login bekommt strengere Limits als normale Seitenaufrufe. Diese Trennung ist fachlich klein, betriebsseitig aber enorm wirksam.

Härtung auf HAProxy-Ebene: Stick Tables, ACLs und Request-Limits

Der wichtigste Einstiegspunkt auf HAProxy-Seite sind stick tables. Sie erlauben, pro Quell-IP Metriken wie aktuelle Verbindungen, Connection-Rate, HTTP-Request-Rate oder Fehlerquoten zu sammeln. Darauf basierend lassen sich ACLs formulieren, die verdächtiges Verhalten sehr früh abbremsen.

Ein typisches Muster für sichere Defaults ist eine moderate Begrenzung der Request-Rate, beispielsweise 50 Requests in zehn Sekunden pro IP für allgemeine Pfade und deutlich strengere Werte für Login- oder Authentifizierungsrouten. Für eine kleine bis mittlere Plattform ist das oft ausreichend, um triviale Bot-Wellen oder unsaubere Skripte abzufangen, ohne legitime Nutzer hart zu treffen.

Für aggressivere Szenarien kann dieselbe Logik verschärft werden. Dann kommen zusätzliche TCP-Regeln hinzu, etwa ein inspect-delay, das frühe Bewertung erlaubt, oder Limits auf conn_cur und conn_rate, die eine einzelne Quelle nicht ungebremst hunderte parallele Sessions öffnen lassen. Solche Maßnahmen schützen vor allem die Backends und die Worker des Proxys.

Ein bewährtes Muster in Konfigurationen ist außerdem die Kombination aus Whitelist und Blocklogik. Monitoring-Systeme, interne Admin-IP-Adressen oder bekannte Upstream-Systeme werden explizit erlaubt, während unbekannte oder auffällige Quellen strengeren Regeln unterliegen. So reduziert sich das Risiko, die eigenen Betriebswerkzeuge versehentlich auszusperren.

Kernel-Härtung: Sysctl-Parameter für den HAProxy-Host

Auch der sauberste Proxy bleibt angreifbar, wenn der Linux-Kernel unter Last nicht ausreichend gepuffert oder gehärtet ist. Deshalb gehören einige sysctl-Einstellungen in jede produktive Proxy-Rolle. Besonders relevant sind tcp_syncookies, somaxconn, tcp_max_syn_backlog und netdev_max_backlog, weil sie direkt beeinflussen, wie der Host eingehende Verbindungen und Paketspitzen verarbeitet.

Für einen kleinen Host mit 2 vCPU und 2 GB RAM sind konservative Werte oft die bessere Wahl. Ein somaxconn von 1024, ein tcp_max_syn_backlog von 2048, aktivierte SYN-Cookies und moderat erhöhte Buffer reichen meist für stabile Baseline-Setups. Erst wenn das Monitoring zeigt, dass legitimer Traffic diese Grenzen tatsächlich ausreizt, sollte aggressiver nachgeschärft werden.

Ebenfalls wichtig ist der Umgang mit conntrack. Wenn auf dem Host stateful Filtering oder weitere lokale Firewall-Regeln aktiv sind, muss nf_conntrack_max zu den realen Lastmustern passen. Ist der Wert zu klein, kippt die Plattform schon bei Lastspitzen; ist er zu groß gewählt, steigt der Speicherverbrauch unnötig an, was auf kleinen Systemen schnell problematisch wird.

Rolle der Firewall vor dem HAProxy-Server

In der beschriebenen Architektur bildet die Firewall die erste Barriere. Sie sollte nicht nur Ports filtern, sondern – sofern es möglich ist – DDoS- und Flood-Policies aktiviert haben, SYN- und UDP-Anomalien begrenzen und offensichtlichen Nicht-HTTP-Traffic bereits vor dem Proxy verwerfen.

Der praktische Nutzen liegt vor allem darin, dass der HAProxy-Host dadurch weniger irrelevanten Verkehr sieht. Das erhöht die Chance, dass CPU, Memory und Socket-Queues für den tatsächlich relevanten Web-Traffic verfügbar bleiben. Zugleich wird klar: Diese Stufe ist nicht nur „Firewall davor“, sondern ein aktiver Bestandteil der Verfügbarkeitsstrategie.

System Engineers sollten diese Schicht immer zusammen mit dem Provider denken. Wenn ein Angriff mehrere hundert Mbit/s oder mehr erreicht, ist nicht mehr die Feinheit der lokalen ACL entscheidend, sondern die Frage, ob der Traffic vor dem eigenen Uplink abgefangen werden kann.

Sichere Defaults vs. aggressive Werte: Wann was sinnvoll ist

Ein häufiger Fehler in Projekten ist es, zu früh aggressive Werte zu setzen. Gerade auf kleineren HAProxy-Hosts mit 2 GB RAM führen überzogene Limits, zu viele Stick-Table-Einträge oder zu große conntrack-Tabellen schnell zu unnötigem Ressourcenverbrauch. Sichere Defaults sind daher kein Zeichen von Vorsichtslosigkeit, sondern Ausdruck eines kontrollierten Betriebsmodells.

Sichere Defaults bedeuten typischerweise: moderate maxconn-Werte, kurze aber nicht überharte Timeouts, saubere Healthchecks, Begrenzung auf kritischen Pfaden, Backlog-Werte im vernünftigen Rahmen und aktiviertes Logging mit klarer Metrikbasis. Damit entsteht ein System, das stabil bleibt und gleichzeitig sichtbar macht, wo die reale Lastgrenze liegt.

Aggressive Werte gehören erst dann in die Konfiguration, wenn die Plattform gut beobachtet ist. Dazu zählen höhere maxconn-Werte, härtere Login-Limits, stärkere TCP-Reject-Regeln, größere Kernel-Queues und kürzere Timeouts. Diese Maßnahmen sind nicht grundsätzlich falsch, aber sie müssen durch Messwerte begründet werden, sonst steigt das Risiko von False Positives.

HAProxy-Monitoring: Baseline-Metriken in Prometheus und Grafana

Ohne Metriken bleibt jede Härtung spekulativ. Deshalb sollten Administratoren bereits vor der Aktivierung schärferer Regeln eine Baseline aufnehmen: CPU-Last, RAM-Nutzung, Netzwerkpakete pro Sekunde, SYN-Verhalten, etablierte Sessions, conntrack-Auslastung und HAProxy-interne Kennzahlen wie aktuelle Sessions, Request-Rate und 5xx-Antworten.

Mit dem HAProxy selbst lassen sich diese Metriken für Prometheus bereitstellen. So lassen sich Host- und HAProxy-Daten über den node_exporter und dem HAProxy Endpoint einsammeln und in Grafana korrelieren. Der praktische Vorteil ist enorm: Wenn bei einem Test oder Angriff die Request-Rate steigt, aber die Leitung frei bleibt, liegt das Problem eher auf Layer 7; wenn Paketraten und Interface-Last explodieren, ist die Netzschicht zuerst gefragt.

Besonders aussagekräftig sind fünf Kennzahlen: 

• haproxy_frontend_current_sessions
• haproxy_frontend_http_requests_total
• haproxy_frontend_http_responses_total{code="5xx"}
• node_network_receive_packets_total
• node_nf_conntrack_entries

Diese Kombination zeigt sehr schnell, ob ein Problem eher aus HTTP-Missbrauch, Netzwerkvolumen oder State-Exhaustion entsteht.

Testprozedur: Konfiguration, Lasttest und Abuse-Test

Eine praxistaugliche Testprozedur beginnt mit der Syntax- und Integritätsprüfung. Vor jeder Inbetriebnahme wird die Konfiguration mit haproxy -c -f /etc/haproxy/haproxy.cfg validiert, anschließend werden sysctl-Änderungen geladen und Kernel-Logs geprüft. Erst danach sollte mit Lasttests begonnen werden.

Der nächste Schritt ist die Baseline unter legitimer Last. Werkzeuge wie wrk oder hey reichen für den ersten Test aus. Ziel ist nicht, das System sofort an die Grenze zu fahren, sondern ein Gefühl dafür zu entwickeln, wie CPU, Speicher, Sessions und Fehlerraten unter realistischer Nutzung reagieren. Bereits an diesem Punkt zeigt sich häufig, ob Timeouts, Healthchecks oder Backend-Verteilung sauber gewählt sind.

Danach folgt der Abuse-Test auf Layer 7. Hier werden bewusst viele Requests gegen allgemeine Pfade und danach gegen sensible Endpunkte wie /login erzeugt. Erwartet wird, dass Rate-Limits anschlagen, 429-Antworten zurückkommen und die übrige Plattform erreichbar bleibt. Gelingt das nicht, sind Schwellenwerte oder Stick-Table-Logik anzupassen.

Erst in einer kontrollierten Staging-Umgebung sollte schließlich das TCP- und SYN-Verhalten getestet werden, etwa mit Werkzeugen wie hping3. Dabei ist nicht das Ziel, die Umgebung maximal zu beschädigen, sondern zu beobachten, wie Kernel, Firewall und Proxy zusammenspielen: Steigen SYN-Zahlen, ohne dass etablierte Sessions völlig einbrechen, greifen die Schutzmechanismen zumindest teilweise. Kippt bereits die Leitung oder die Firewall, muss die Abwehr weiter nach vorn verlagert werden.

Kompaktes Betriebsbeispiel: HAProxy 3.2 auf einem Host mit 2 vCPU

Angenommen, ein Unternehmen betreibt eine öffentliche Webanwendung hinter einer Firewall. Auf dem dedizierten Proxy-Host läuft HAProxy 3.2 mit 2 vCPU und 2 GB RAM. Die Firewall erlaubt nur TCP 80 und 443 zum HAProxy, HAProxy terminiert TLS, verteilt auf zwei App-Server und ein API-Backend und nutzt stick tables zur Begrenzung auffälliger Clients.

Für diesen Fall wären sichere Defaults eine plausible Startkonfiguration. Das bedeutet: nbthread 2, ein moderates maxconn, Request-Limits auf allgemeinem Traffic, strengere Werte auf /login und solide Healthchecks auf den Backends. Kernel-seitig werden SYN-Cookies aktiviert, der SYN-Backlog erhöht und conntrack nicht überdimensioniert. Das System ist damit nicht „maximal hart“, aber gut beobachtbar und stabil.

Wenn die Metriken später zeigen, dass etwa API-Clients deutlich mehr legitime Requests erzeugen oder Login-Wellen regelmäßig an die Schwelle stoßen, kann gezielt nachgeschärft werden. Genau das ist die operative Stärke dieser Architektur: Härtung erfolgt nicht blind, sondern messwertbasiert.

Typische Fehlannahmen bei HAProxy als DDoS-Schutz

Eine verbreitete Fehlannahme lautet, dass HAProxy auch große DDoS-Angriffe einfach „wegfiltern“ könne. Das ist nur teilweise richtig. Auf Layer 7 kann HAProxy sehr effektiv sein; auf Layer 3/4 endet die Wirksamkeit dort, wo Uplink, Firewall oder Kernel bereits gesättigt sind.

Ebenso problematisch ist die Annahme, dass nur die Anwendung geschützt werden müsse. In Wirklichkeit entscheidet die Summe aus Edge‑Gateway, Host-Kernel, Proxy-Regeln, Backend-Kapazität und Monitoring über die Resilienz. Wird eine dieser Ebenen vernachlässigt, entsteht dort fast zwangsläufig der erste echte Single Point of Failure.

Auch das Gegenteil kommt vor: Teams härten so aggressiv, dass normale Nutzer blockiert werden. Besonders NAT-Szenarien, Unternehmensproxies oder gemeinsame Mobilfunk-Ausgänge können scheinbar „zu viele Requests pro IP“ erzeugen, obwohl das Verhalten legitim ist. Ohne Whitelists, saubere Metriken und schrittweise Einführung werden Schutzmaßnahmen dann selbst zum Betriebsproblem.

Fazit: HAProxy als Teil mehrschichtiger DDoS-Abwehr

Für die sichere Bereitstellung einer Webanwendung ist HAProxy kein Allheilmittel, aber ein sehr präzises Werkzeug in einer mehrschichtigen Verteidigung. Die Kernidee ist einfach: Layer-7-Probleme mit HAProxy steuern, Layer-3/4-Volumen im Netzwerk davor mit Firewall, CDN oder Scrubbing-Services abfangen, den Linux-Kernel des Proxy-Hosts stabil konfigurieren und jede Härtung auf beobachtbaren Metriken aufbauen.

Sie überlegen, wie Sie Ihre Anwendungen und Systeme belastbar gegen DDoS-Angriffe, HTTP-Floods und SYN-Floods absichern? 

Unsere Experten unterstützen Sie bei Analyse, Architekturentwurf und Betrieb passender Schutzmaßnahmen.

Jetzt Kontakt aufnehmen

Häufige Fragen zu HAProxy und DDoS-Schutz

Was ist HAProxy?

HAProxy ist ein hochperformanter Open-Source-Load-Balancer und Reverse Proxy für TCP- und HTTP-basierte Anwendungen. Er nimmt eingehende Verbindungen entgegen, verteilt sie auf Backend-Server und steuert Zugriffe regelbasiert. In sicherheitsrelevanten Architekturen wird HAProxy häufig zur Bot-Abwehr, zum Rate Limiting und als erste Steuerungsschicht für HTTP-Traffic eingesetzt.

Schützt HAProxy zuverlässig vor DDoS-Angriffen?

HAProxy schützt sehr effektiv vor Angriffen auf der Anwendungsebene, etwa HTTP-Floods, Bot-Wellen oder Brute-Force-Versuchen auf Login-Endpunkten. Gegen volumetrische Angriffe auf Layer 3 und 4 reicht HAProxy alleine nicht aus. Hier sind eine vorgeschaltete Firewall, ISP-Mitigation oder ein CDN notwendig.

Was ist der Unterschied zwischen Layer-7- und Layer-3/4-DDoS?

Layer-7-Angriffe zielen auf die Applikationslogik, etwa mit überzogenen HTTP-Requests auf teure Endpunkte oder massiven Login-Versuchen. Layer-3/4-Angriffe sind volumetrisch und sättigen Bandbreite, Connection-Tracking oder den TCP-Handshake, bevor die Anwendung sie überhaupt sieht.

Was sind Stick Tables in HAProxy?

Stick Tables sind ein In-Memory-Speicher von HAProxy, der pro Client (zum Beispiel pro Quell-IP) Metriken wie Verbindungen, Request-Rate oder Fehlerquoten sammelt. Auf dieser Datenbasis lassen sich ACL-Regeln formulieren, die verdächtiges Verhalten frühzeitig drosseln, etwa über eine 429-Antwort oder ein Rejecting auf TCP-Ebene.

HAProxy oder NGINX zur DDoS-Abwehr?

HAProxy ist ein spezialisierter Load Balancer mit besonders feingranularer Steuerung über Stick Tables und ACLs. NGINX ist primär ein Webserver mit Reverse-Proxy-Funktionen. Für komplexes Rate Limiting, Per-IP-Tracking und gezielte Layer-7-Abwehr spielt HAProxy seine Stärken aus, während NGINX überall dort sinnvoll ist, wo zusätzlich statische Inhalte ausgeliefert werden sollen.

Welche sysctl-Einstellungen sind für einen HAProxy-Host sinnvoll?

Besonders relevant sind tcp_syncookies, somaxconn, tcp_max_syn_backlog und netdev_max_backlog, weil sie steuern, wie der Host eingehende Verbindungen und Paketspitzen verarbeitet. Für einen kleinen Host mit zwei vCPU und zwei GB RAM sind konservative Werte sinnvoll, etwa somaxconn von 1024 und tcp_max_syn_backlog von 2048, ergänzt um aktivierte SYN-Cookies.

Reichen Firewall und HAProxy zur DDoS-Abwehr?

Beide zusammen bilden eine solide Basis gegen Bot- und HTTP-Angriffe. Eine Firewall reduziert die Angriffsfläche, HAProxy bewertet semantisch und drosselt missbräuchliche Sessions. Bei volumetrischen Angriffen mit mehreren hundert Mbit/s reicht das nicht: Hier sind ISP-Mitigation, Anycast, CDN oder Scrubbing-Services die belastbaren Optionen.

Welche Metriken zeigen einen laufenden Layer-7-Angriff?

Besonders aussagekräftig sind die Kombination aus haproxy_frontend_current_sessions, haproxy_frontend_http_requests_total, haproxy_frontend_http_responses_total{code="5xx"}, node_network_receive_packets_total und node_nf_conntrack_entries. Steigt die Request-Rate, ohne dass Paketraten und Interface-Last explodieren, deutet das auf Layer 7 hin. Explodieren Paketraten zuerst, liegt das Problem auf der Netzschicht.