Die Arithmetik der State Table: eine Firewall für Floods dimensionieren, nicht für Durchschnitte

Fragen Sie die meisten Leute, wie groß eine Firewall sein muss, und sie antworten in Bandbreite. Unter Angriff ist Bandbreite selten das, was zuerst ausgeht. Die State Table ist es: die Liste der Verbindungen, die die Firewall verfolgt, die eine feste Größe hat, sich in dem Tempo füllt, in dem neue Verbindungen eintreffen, und sich nur so schnell leert, wie die Timeouts es erlauben. Verstehen Sie diese Arithmetik, und Sie können eine Firewall für den Tag dimensionieren, an dem es darauf ankommt, statt für den Durchschnittstag.

Warum der State vor der Bandbreite ausgeht

Wenn die Tabelle voll ist, werden neue Verbindungen verworfen, legitim oder nicht, selbst wenn die Leitungen fast im Leerlauf sind.

Zwei Arten von Verkehr füllen eine Tabelle schnell:

• SYN-Floods. Jedes gefälschte SYN erzeugt einen halb offenen Eintrag, der nie abgeschlossen wird.
• UDP zu öffentlichen Diensten. DNS, NTP, Game-Server, VoIP und ähnliche Dienste sehen riesige Mengen kurzer Austausche von vielen Quellen, und jeder davon kann seinen eigenen Eintrag erzeugen.

Die Arithmetik

Die Zahl der Einträge in einer Tabelle im eingeschwungenen Zustand ist, in guter Näherung:

entries  =  new flows per second  x  seconds each entry lives

Das ist Littles Gesetz, und es ist das ganze Spiel. Angenommen, ein Flood kommt mit 50.000 neuen SYNs pro Sekunde an, und halb offene TCP-Einträge leben 30 Sekunden. Die Tabelle braucht 1.500.000 Einträge allein für den Angriff, bevor irgendein echter Nutzer eintrifft. Kürzen Sie diesen Timeout während des Floods auf 5 Sekunden, und derselbe Angriff braucht 250.000. Dieselbe Firewall, derselbe Speicher, ein sechsfacher Unterschied durch einen einzigen Timer.

Es gibt also nur drei Hebel: eine größere Tabelle (Speicher), kürzere Lebensdauern (Timeouts) und weniger Einträge pro Flow (gar keine State-Verfolgung dort, wo Sie sie nicht brauchen). Nutzen Sie alle drei.

Hebel eins: Dimensionieren Sie die Tabelle bewusst

Ermitteln Sie, wie viel Speicher die Plattform pro State-Eintrag belegt, entscheiden Sie, wie viel vom RAM der Firewall Sie dem State geben wollen, und leiten Sie das Maximum daraus ab, statt mit einem Standardwert zu leben, der für ein kleines Büro gewählt wurde. Dann alarmieren Sie deutlich, bevor die Tabelle voll ist.

Auf OPNsense und pf-basierten Firewalls sind die Live-Zahlen einen Befehl entfernt:

pfctl -si | grep -A4 "State Table"
pfctl -sm | grep states

Hebel zwei: Adaptive Timeouts und SYN-Cookies

Statische Timeouts sind ein Kompromiss zwischen Nachsicht mit langsamen Clients und dem Überleben eines Floods. Adaptive Timeouts heben den Kompromiss auf: Wenn sich die Tabelle über einen Startschwellwert hinaus füllt, skalieren alle Timeouts linear herunter und erreichen bei einem Endschwellwert null. Normale Tage behalten großzügige Timer. Unter Druck laufen Einträge schnell ab. In pf-Begriffen:

set limit states 2000000
set timeout { adaptive.start 1200000, adaptive.end 2200000 }

Ergänzen Sie SYN-Cookies, idealerweise in einem adaptiven Modus, der sich nur einschaltet, wenn die Tabelle einen Schwellwert überschreitet. Mit Cookies beantwortet die Firewall ein SYN, ohne State zu erzeugen, und baut erst dann einen Eintrag, wenn der Client den Handshake abschließt, was eine gefälschte Quelle nie tut. Das verwandelt den effizientesten Angriff auf eine Stateful Firewall in Verkehr, den die Firewall kaum bemerkt.

Hebel drei: Verfolgen Sie nicht, was keine Verfolgung braucht

Für UDP-Dienste mit hohem Volumen bringt die Verfolgung jedes Austauschs fast nichts: Der Dienst antwortet von einem bekannten Port, und die Regeln sind einfach. Ein zustandsloses Regelpaar (eingehend zum Dienstport erlauben, ausgehend von ihm erlauben) erzeugt überhaupt keine Einträge, sodass ein UDP-Flood die Tabelle nicht im Namen eines DNS- oder NTP-Servers erschöpfen kann. Behalten Sie zustandsbehaftete Verarbeitung für TCP und für alles, bei dem der Rückverkehr streng an eine ausgehende Anfrage gebunden sein muss.

Behalten Sie den State über einen Ausfall hinweg

Die Dimensionierung ist die halbe Arbeit. Die andere Hälfte ist, nicht alles zu verlieren, wenn ein Knoten ausfällt. In einem Paar aus Active und Standby verschiebt CARP die virtuellen Adressen auf das Standby, und pfsync repliziert die State Table fortlaufend zwischen den Knoten, wo möglich über einen dedizierten Link. Wenn der aktive Knoten stirbt, kennt das Standby bereits jede aufgebaute Verbindung, sodass die Sitzungen weiterlaufen, statt dass sich jeder Nutzer neu verbindet. Testen Sie es: Starten Sie einen langen Download oder eine SSH-Sitzung durch das Paar, schalten Sie den aktiven Knoten aus, und sehen Sie zu, wie es weitergeht.

Zwei praktische Gewohnheiten helfen. Spielen Sie Tuning-Änderungen zuerst auf dem Standby ein, verifizieren Sie, dann schalten Sie um und ändern den anderen Knoten. Und verteilen Sie die Paketverarbeitung über CPU-Kerne mit Thread-Zahlen, die zu jeder Appliance passen, damit ein ausgelasteter Kern nicht zur eigentlichen Grenze wird.

Ordnen Sie das Regelwerk für billige Entscheidungen

Ein Flood ist billiger früh zu verwerfen. Setzen Sie die groben, billigen Entscheidungen an den Anfang: eine kombinierte Threat-Intelligence-Sperrliste, dann Ländersperren, dann bekannte missbräuchliche Hosting-Bereiche, und erst dann die Erlaubnisregeln pro Host. Benennen Sie jeden Alias und jede Regel nach dem Host, den sie schützt, damit das Regelwerk sich selbst dokumentiert und alte Regeln mit Zuversicht entfernt werden können.

Prüfen Sie Ihre eigene Firewall

• Wie hoch ist das Limit der State Table, und wie hoch ist die heutige Spitze als Prozentsatz davon?
• Gibt es einen Alarm deutlich unterhalb des Limits?
• Sind adaptive Timeouts konfiguriert, und stehen SYN-Cookies unter Last zur Verfügung?
• Behandeln Sie UDP-Dienste mit hohem Volumen zustandslos?
• Wird in einem HA-Paar der State synchronisiert, und haben Sie ein Failover mit laufenden Sitzungen getestet?
• Wissen Sie, was ein Angriff mit dem Zehnfachen Ihrer normalen Verbindungsrate mit der Tabelle machen würde? Rechnen Sie es aus.

Unsere Perimeter-Firewalls in Athen laufen als zustandsbehaftete Paare, so gebaut und abgestimmt, und werden nur über ihre API geändert. Wenn Sie Hilfe dabei möchten, die Arithmetik für Ihre eigenen zu machen, setzen wir uns gern mit Ihnen zusammen.

Mit einem Ingenieur sprechen

Verwandt: Managed Perimeter-Firewalls · Wie wir Dinge ändern: Disziplin bei Netzwerkänderungen · Netzwerk-Monitoring und Nachweise