February 24, 2026

Rate Limiting auf Firewalls: Wann es hilft und wie man es plant

Rate Limiting auf Firewalls ist eine der pragmatischsten Maßnahmen, um Netzwerke und Services gegen Überlast, Missbrauch und bestimmte DDoS-Muster zu schützen – vorausgesetzt, es wird geplant statt „auf gut Glück“ aktiviert. Viele Admins kennen das Problem: Ein einzelner Host erzeugt plötzlich extrem viele Verbindungen, ein Scan läuft aus dem Ruder, ein falsch konfigurierter Client spammt DNS oder VPN-Logins, oder ein volumetrischer Angriff drückt so viele Pakete durch, dass State-Tabellen, CPU oder Bandbreite kollabieren. In solchen Situationen kann Rate Limiting auf Firewalls helfen, den Schaden zu begrenzen, kritische Dienste zu stabilisieren und Zeit für weitere Gegenmaßnahmen zu gewinnen. Gleichzeitig ist Rate Limiting kein Allheilmittel: Zu aggressive Limits verursachen Self-DoS, brechen legitime Anwendungen, führen zu schwer nachvollziehbaren Fehlerbildern und werden im Betrieb schnell wieder abgeschaltet. Ein professioneller Ansatz kombiniert daher Verständnis der eigenen Traffic-Baselines, saubere Zieldefinition (welche Ressourcen sollen geschützt werden?), differenzierte Limits pro Zone/Service sowie eine kontrollierte Einführung mit Monitoring, Logging und Review-Prozess. Dieser Artikel erklärt, wann Rate Limiting wirklich hilft, welche Arten es gibt, wie Sie sinnvolle Schwellenwerte planen und welche typischen Fehler Sie vermeiden sollten.

Table of Contents

Was bedeutet Rate Limiting auf Firewalls?

Rate Limiting ist das Begrenzen von Ereignissen pro Zeiteinheit. Auf Firewalls kann sich das je nach Hersteller und Feature-Set auf unterschiedliche Größen beziehen:

Pakete pro Sekunde (pps): Begrenzung der Paketverarbeitung, oft relevant bei Protokoll-/Volumenmustern.
Bits/Bytes pro Sekunde (bps): Bandbreitenbegrenzung (Traffic Shaping/Policing) für bestimmte Klassen.
Neue Verbindungen pro Sekunde (CPS): Schutz von State-Tabellen und Backends gegen Session-Flooding.
Gleichzeitige Verbindungen (Concurrent Sessions): Begrenzung pro Quelle, Ziel oder Service.
Requests pro Zeit (Layer 7): Bei NGFW/WAF-nahen Funktionen ggf. HTTP-Requests, API-Aufrufe oder Login-Versuche.

Wichtig: Rate Limiting ist immer eine Form von „kontrolliertem Abwerfen oder Verzögern“. Es macht Traffic nicht „besser“, sondern priorisiert Ressourcen, indem es Übermaß begrenzt.

Wann Rate Limiting wirklich hilft

Rate Limiting ist besonders wirksam, wenn eine begrenzte Ressource geschützt werden soll und wenn „zu viel“ Traffic klar definierbar ist. Die besten Anwendungsfälle sind oft nicht spektakuläre Mega-DDoS-Szenarien, sondern alltägliche Störungen und Missbrauchsmuster.

Schutz der Firewall selbst (Control Plane und State)

SYN-/Session-Floods: Zu viele neue Verbindungen pro Sekunde können State-Tabellen füllen.
Scans und Worm-ähnliche Muster: Ein Host kontaktiert viele Ziele/Ports in kurzer Zeit.
Fehlkonfigurationen: Clients, die durch Bugs sehr viele Sessions erzeugen (z. B. Retries in Schleife).

Schutz von Diensten hinter der Firewall

VPN- und Login-Endpunkte: Brute Force, Password Spraying, Credential Stuffing (Rate Limits auf Auth-Pfade).
DNS und andere UDP-Dienste: Begrenzung pro Quelle oder pro Interface, um Missbrauch zu dämpfen.
Öffentliche Web-/API-Services: Wenn die Firewall L7-Limits unterstützt oder mit WAF/Reverse Proxy kombiniert wird.

Schutz des Internet-Uplinks (begrenzter Nutzen, aber sinnvoll als Teilkonzept)

Rate Limiting auf der Firewall kann Bandbreite schützen, wenn der Engpass hinter der Firewall liegt. Wenn der Provider-Port oder die Leitung bereits voll ist, kommt Traffic nicht mehr zuverlässig an – dann muss Mitigation upstream erfolgen (Scrubbing/CDN/Anycast). Rate Limiting bleibt aber nützlich, um interne Ressourcen zu schützen, selbst wenn ein großer Angriff läuft.

Wann Rate Limiting gefährlich wird oder wenig bringt

Rate Limiting ist kein „einfach einschalten“. In diesen Situationen ist das Risiko von Self-DoS oder ineffektiver Abwehr besonders hoch:

Unbekannte Baseline: Wenn Sie nicht wissen, wie viele CPS/pps normal sind, sind Limits schnell zu niedrig.
„Eine Zahl für alles“: Ein globales Limit ignoriert, dass Zonen und Services unterschiedliche Profile haben.
Stateful Firewalls mit vielen NAT/Apps: Limits können Nebenwirkungen erzeugen, die schwer zu debuggen sind.
Große volumetrische Angriffe: Wenn die Leitung saturiert ist, hilft lokales Limiting kaum gegen den Bandbreitenteil.
Legitime Peaks: Release-Rollouts, Marketingkampagnen, Backup-Fenster oder Patchdays erzeugen Lastspitzen.

Welche Arten von Rate Limiting gibt es?

Je nach Gerät und Hersteller begegnen Ihnen unterschiedliche Mechanismen. Für Planung und Kommunikation ist es hilfreich, die Begriffe sauber zu trennen.

Policing vs. Shaping

Policing: Traffic, der über dem Limit liegt, wird verworfen oder markiert. Wirkt sofort, kann aber „hart“ sein.
Shaping: Traffic wird geglättet und verzögert (Queueing), um Peaks abzufedern. Das ist oft freundlicher für TCP, kann aber Latenz erhöhen.

Per-Flow, per Source, per Destination

Per Source: Begrenzung pro Quell-IP oder pro Nutzergruppe (gut gegen einzelne „laute“ Clients).
Per Destination/Service: Schutz eines Zielsystems oder Ports (z. B. VPN/HTTPS/SSH).
Per Zone: Limits pro Interface/Zone (z. B. DMZ-Ingress restriktiver als interne Zonen).

State-basierte Limits (CPS und Concurrent Sessions)

CPS (Connections per Second): Schutz gegen „Connection Storms“.
Concurrent Sessions: Obergrenze für gleichzeitige Sessions, pro Host oder global.

Planung: So finden Sie sinnvolle Schwellenwerte

Der wichtigste Teil ist nicht die Technik, sondern die Planung. Ein gutes Rate-Limiting-Design basiert auf Daten und Risiko, nicht auf Bauchgefühl.

Schritt 1: Baseline messen

Ermitteln Sie Normalwerte für die relevanten Größen – getrennt nach Zonen und Diensten:

pps/bps: Durchschnitt und Spitzenwerte pro Interface (z. B. Internet, DMZ, VPN).
CPS: Neue Sessions pro Sekunde, besonders für öffentliche Dienste.
Concurrent Sessions: Typische Peak-Sessions (z. B. morgens bei Arbeitsbeginn).
Top Talker: Welche Quellen/Ziele dominieren Peaks?

Best Practice: Nutzen Sie mehrere Zeitfenster (Werktag/Weekend, Patchday, Monatsabschluss), damit Limits nicht an einem „happy path“ ausgerichtet sind.

Schritt 2: Kritische Dienste priorisieren

Limits sollten zuerst dort greifen, wo der Schaden am größten ist: Management- und Auth-Services, VPN, DNS, öffentlich exponierte Web-Services, API-Gateways. Definieren Sie pro Dienst ein Schutzziel:

Schutz vor Überlast: „Service muss für legitime Nutzer weiter funktionieren“.
Schutz vor Missbrauch: „Login-Versuche pro Quelle begrenzen“.
Schutz der Infrastruktur: „State Table darf nicht volllaufen“.

Schritt 3: Limits mit Sicherheitsmarge festlegen

Setzen Sie Limits nicht auf den Durchschnitt, sondern auf einen Wert oberhalb typischer Peaks – plus Sicherheitsmarge. Ein pragmatisches Vorgehen:

Startlimit: Peak (p95 oder p99) + Reserve
Dann beobachten: Drops, Latenzen, Tickets, Business-Impact
Nachjustieren: Limits enger oder weiter, abhängig von echten Ereignissen

Schritt 4: „Soft Launch“ statt Big Bang

Monitor-Phase: Wenn möglich zunächst nur zählen und alarmieren, nicht droppen.
Selektive Aktivierung: Erst kritische Zonen/Services, dann ausweiten.
Wartungsfenster: Aktivierung in planbaren Zeiten, mit Rollback-Plan.

Designmuster für typische Szenarien

Die folgenden Muster sind in Unternehmensnetzwerken häufig und eignen sich gut als Ausgangspunkt für ein sauberes Rate-Limiting-Design.

Inbound-Schutz für öffentliche Dienste (DMZ)

CPS-Limit auf VIP/Service: Neue Verbindungen pro Sekunde begrenzen.
Per-Source Limits: Eine Quell-IP darf nur N neue Sessions pro Zeitfenster.
Separate Limits pro Endpoint: Login- oder Suchpfade strenger als statische Inhalte (wenn L7 möglich).

VPN-Login-Schutz

Login-Raten begrenzen: Fehlversuche pro Quelle, pro Konto oder pro Region (wenn möglich).
Schutz gegen Push-Spam: MFA-Anfragen drosseln oder risk-based steuern.
Control-Plane schützen: CPS und pps für den VPN-Endpoint überwachen.

DNS- und UDP-Dämpfung

Per-Source Rate Limits: Ein Client darf nur eine definierte Query-Rate haben.
Block ungeeigneter UDP-Services: UDP nach außen nur, wenn zwingend.
Resolver zentralisieren: Direkte DNS-Abfragen nach außen verhindern, erhöht Signalqualität.

Outbound-„Lärm“ begrenzen

Rate Limiting kann auch intern helfen, wenn einzelne Hosts aus dem Ruder laufen (Malware, Fehlkonfiguration, Datenabfluss). Hier ist Vorsicht wichtig, um keine legitimen Business-Flows zu stören.

Per-Host Outbound Limits: Besonders in Serverzonen, um Exfiltration-Spikes zu dämpfen.
Neue Ziele überwachen: „First seen“ Destinations + hohe Rate = Alarm + optional Drosselung.
Kombination mit Segmentierung: Je restriktiver Egress-Policies, desto besser funktioniert Limiting.

Rate Limiting und TCP: Warum „hartes Droppen“ Nebenwirkungen hat

Bei TCP führt Droppen über dem Limit zu Retransmits, Backoff und ggf. „Verkehrsstau“, was je nach Anwendung unterschiedliche Effekte hat. Deshalb sind Shaping-Mechanismen oder Limits an der richtigen Stelle oft besser als globales Droppen.

Shaping glättet Peaks: Besser für stabile Durchsatzprofile, aber erhöht Latenz.
Policing stoppt Missbrauch schnell: Gut gegen Attacken, aber riskant, wenn Limits zu niedrig sind.
Priorisierung (QoS): Kritische Business-Services bevorzugen, weniger kritische drosseln.

Monitoring und Logging: Ohne Sichtbarkeit wird Rate Limiting zum Blindflug

Rate Limiting ist nur dann betriebssicher, wenn Sie Auswirkungen messen können. Planen Sie deshalb Telemetrie und Alarmierung gleich mit.

Drop Counters: Wie viele Pakete/Connections werden gedroppt oder ge-shapet?
Top Talker unter Limit: Welche Quellen/Ziele triggern Limits?
Service-KPIs: Latenz, Fehlercodes, VPN-Login-Erfolg, CPU/State Table.
Change Audit: Wer hat Limits geändert, wann und warum?

Für Logsammlung und zentrale Auswertung sind SIEM/Syslog-Architekturen sinnvoll; technische Grundlagen zu Syslog finden Sie in RFC 5424.

Zusammenspiel mit DDoS Mitigation: Wo Rate Limiting endet

Rate Limiting ist ein Baustein, aber nicht die vollständige DDoS-Abwehr. Die wichtigste Grenze ist die Leitung: Wenn die Bandbreite upstream saturiert ist, brauchen Sie Scrubbing, CDN/Anycast oder Provider-Filter. Rate Limiting ist dann weiterhin hilfreich, um interne Komponenten zu schützen und die Zeit bis zur Umschaltung zu überbrücken.

Lokales Limiting: gut gegen einzelne laute Quellen, Protokollmissbrauch, Session-Floods
Upstream-Mitigation: notwendig bei volumetrischen Angriffen, Reflexion/Amplifikation
WAF/API-Gateway: notwendig bei Layer-7-Floods

Ein strukturelles Prinzip gegen Spoofing und Reflexion ist Source Address Validation (Ingress Filtering), beschrieben in BCP 38 / RFC 2827.

Typische Fehler beim Rate Limiting auf Firewalls

Limits ohne Baseline: Zu niedrige Werte führen zu Self-DoS und schwer erklärbaren Störungen.
Globale Limits: Ein Limit für alle Zonen ignoriert unterschiedliche Traffic-Profile.
Keine Ausnahme-Strategie: Monitoring, Backups, Updates oder vertrauenswürdige Systeme brauchen ggf. eigene Klassen.
Kein Rollback-Plan: Wenn es knallt, muss ein Limit schnell und kontrolliert zurückgenommen werden können.
Fehlende Dokumentation: Niemand weiß später, warum ein Limit gesetzt wurde.
Nur Rate Limiting statt Architektur: Ohne Segmentierung, WAF und Upstream-Plan bleibt der Schutz lückenhaft.

Praxis-Checkliste: Rate Limiting sinnvoll planen und einführen

Baselines für pps/bps/CPS/Concurrent Sessions pro Zone und Service sind gemessen (inkl. Peaks)
Schutzziele sind definiert (Firewall-Selbstschutz, Service-Schutz, Missbrauchsdämpfung)
Limits sind differenziert (pro Zone, pro Service, pro Quelle) statt global
Einführung erfolgt stufenweise (Monitoring → selektives Droppen/Shaping → Ausbau)
Monitoring/Logging ist vorhanden (Drop Counters, Top Talker, Service-KPIs, Change Audit)
Ausnahmen sind dokumentiert, eng gefasst und regelmäßig rezertifiziert
Rate Limiting ist in ein DDoS-Konzept eingebettet (Upstream-Mitigation, WAF/CDN, Runbooks)
Rollback- und Notfallprozesse sind getestet

Weiterführende Informationsquellen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Netzwerkdesign & Topologie-Planung
Router- & Switch-Konfiguration (Cisco IOS)
VLAN, Inter-VLAN Routing
OSPF, RIP, EIGRP (Grundlagen & Implementierung)
NAT, ACL, DHCP, DNS-Konfiguration
Troubleshooting & Netzwerkoptimierung
Packet Tracer Projektentwicklung & Dokumentation
CCNA Lern- & Praxisunterstützung

Lieferumfang:

Konfigurationsdateien
Packet-Tracer-Dateien (.pkt)
Netzwerkdokumentation
Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.