Firewall oder WAF: was jede sieht und was jede stoppt

Was eine Stateful Firewall entscheidet

Eine Layer-3/4-Firewall verfolgt Verbindungen und beurteilt jede neue anhand ihrer Adressen, ihres Ports und des Zustands des Flows, zu dem sie gehört. Cisco Firepower, OPNsense und netfilter machen das alle gut: Ein Port, den keine Regel öffnet, ist geschlossen, eine Antwort wird nur für eine Verbindung erlaubt, die von innen gestartet wurde, und Management-Ports antworten nur den Bereichen, die auf der Allow-List stehen. Ihre Sicht endet auf der Transportschicht. Mit TLS im Pfad kann sie überhaupt nicht in die Nutzlast sehen, es sei denn, sie terminiert die Sitzung, und selbst im Klartext hat sie keinen Begriff von einer URL, einem Header, einem Antwortstatus oder einem Login.

Was eine WAF hinzufügt

Eine Web Application Firewall liest die HTTP-Transaktion nach der TLS-Terminierung, was in der Praxis bedeutet, dass sie im oder neben dem Reverse Proxy lebt. Sie fügt drei Arten von Kontrolle hinzu, die die Firewall nicht ausdrücken kann. Signaturregeln, etwa ModSecurity mit dem OWASP Core Rule Set, erkennen Injection, Traversal und bekannte Exploit-Payloads in der Anfrage. Verhaltensregeln zählen pro Client und pro Pfad: Anfragen pro Minute auf der Login-Route, Antworten auf fehlgeschlagene Logins pro Adresse, Bot-Signale in Headern und Timing. Positive Regeln legen fest, was ein Pfad akzeptiert, etwa welche Methoden, welche Content-Types und welche Body-Größe, und weisen den Rest ab.

Eine WAF ist kein Ersatz für die Firewall. Sie sieht nur den Verkehr, der sie erreicht, und weiß nichts über SSH, Datenbank-Ports oder die Management-Ebene.

Wo Login-Missbrauch sichtbar wird

Ein fehlgeschlagenes Login ist eine Tatsache in der Antwort. Die Anwendung beantwortet ein POST an den Login-Pfad mit einem Status oder einer Weiterleitung, die Fehlschlag von Erfolg unterscheidet, und der Proxy schreibt das bei jedem Versuch in sein Access-Log. Fehlschläge pro Client und Minute zu zählen ist eine Zeile awk über dieses Log, und es ist das Signal, das ein Paketfilter auf keine Weise sehen kann.

Die Kontrolle muss am Client ansetzen, nicht am Konto. Eine Kontosperre allein stoppt Versuche gegen einen Benutzernamen und sperrt dessen Inhaber aus, während der Bot zum nächsten Namen auf seiner Liste weitergeht. Ein Rate Limit pro Client auf der Login-Route leistet, was die Sperre nicht kann:

# nginx: at most 5 login attempts a minute per client, small burst allowed
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;

location = /login {
    limit_req zone=login burst=5 nodelay;
    proxy_pass http://app;
}

HAProxy drückt dieselbe Idee mit einer Stick Table aus, die an die Quelladresse gebunden ist, und ein WAF-Regelsatz kann den Antwortcode des fehlgeschlagenen Logins direkt zählen.

Wie die beiden zusammenpassen

Die Reihenfolge ist Firewall, dann TLS-Terminierung und der Proxy mit seinen WAF-Regeln, dann die Anwendung. Die Erkennung gehört auf Layer 7, denn dort liegen die Beweise. Die Durchsetzung kann auf beiden Ebenen erfolgen. Der Proxy kann dem auffälligen Client bei seiner nächsten Anfrage mit 429 oder 403 antworten, was für die meisten Fälle von Missbrauch genügt. Bei einem Client, der immer wiederkommt, kann der Proxy die Adresse für eine festgelegte Zeit in die dynamische Tabelle des Paketfilters schieben, was auch die übrigen Verbindungen dieses Clients kappt und die Firewall pro Paket nichts kostet.

Zwei Designpunkte kommen, bevor diese Rückkopplungsschleife scharf geschaltet wird. Die Management- und Monitoring-Bereiche des Betreibers kommen zuerst auf die Allow-List, damit ein Test oder ein Tippfehler die Menschen, die die Plattform betreiben, nicht aussperren kann. Und geteilte Adressen sind real: Ein Büro-NAT oder ein Carrier-Grade-NAT stellt viele Menschen hinter eine Adresse, also tragen Sperren eine kurze Ablaufzeit und einen dokumentierten Weg, sie aufzuheben. Die gesamte Kette wird danach von einem Host außerhalb des Netzwerks getestet, so wie ein Angreifer sie antreffen würde, bevor sich jemand darauf verlässt.

Was keine von beiden sieht

Ein richtiges Passwort. Credential Stuffing mit einem geleakten, gültigen Passwort sieht auf jeder Ebene wie ein erfolgreiches Login aus. Diese Lücke schließt Multi-Faktor-Authentifizierung am Konto und eine Allow-List für die administrativen Pfade an der Firewall, sodass ein gültiges Credential von einer Adresse, die nicht Ihre ist, nutzlos ist.