10 Tipps für Ihre Next-Gen WAF

Als Technical Account Management Team von Fastly sind wir unseren Kunden dabei behilflich, unsere Next-Gen WAF (powered by Signal Sciences) so effektiv wie möglich zu nutzen. Wir kümmern uns im direkten Austausch mit unseren in den verschiedensten Branchen tätigen Kunden darum, einen reibungslosen Betrieb zu gewährleisten. 

Im Folgenden haben wir einige Empfehlungen für Sie zusammengestellt, wie Sie mit unserer Next-Gen WAF maximale Erfolge erzielen können. 

Best Practices für die Next-Gen WAF

1. Beugen Sie Client IP Spoofing vor

Dieser grundlegende Schritt wird oft übersehen. Wenn wir nicht in der Lage sind, die wahre Client IP zu erfassen, kann ein Angreifer unsere WAF gezielt umgehen, indem er einfach die erforderlichen Header ändert, um nicht blockiert zu werden. 

Der Next-Gen WAF (NGWAF) Agent verwendet den X-Forwarded-For-Header, um die Client-IP-Adresse zu ermitteln. Zum Beispiel client-ip-header="Fastly-Client-IP". Dieser Header kann ziemlich leicht gefälscht werden, indem einfach eine andere IP-Adresse im Header angegeben wird. 

In unserer Kundendokumentation</u> gehen wir auf dieses Problem ein. Als Lösung wird vorgeschlagen, einen anderen Header anzugeben und den Agent dann so zu konfigurieren, dass er diesen Header verwendet, um die wahre Client IP zu ermitteln. Außerdem wird empfohlen, den Agent so zu konfigurieren, dass er die X-Forwarded-For-IP-Adresse von rechts nach links anstatt standardmäßig von links nach rechts liest. Dies kann durch die Konfiguration local-networks="private" erreicht werden.

Bei On-Premise-Bereitstellungen (Module/Agent) wollen wir sichergehen, dass wir die wahre IP-Adresse validieren, ehe der NGWAF Agent den Header erhält. NGINX verfügt beispielsweise über das Modul ngx_http_realip_module, das die Client-IP-Adresse validiert.

Kunden, die unser Fastly CDN der NGWAF vorschalten, können die IP-Adresse über spezifischen VCL Code weitergeben. (Genaueres dazu erfahren Sie hier</u>.) Dadurch wird die wahre Client IP an den Fastly Client-IP-Header übergeben.

Die alternativen Header können über die Nutzeroberfläche konfiguriert werden. Für Nicht-Cloud-WAF-Bereitstellungen sind die Schritte hier dokumentiert</u>.

Für Cloud-WAF-Bereitstellungen können wir dies auf der Cloud-WAF-Instanz einrichten. Um den zu verwendenden Header festzulegen, wählen wir unter Instance location die Option Advanced:

Da wir jetzt wissen, welche Header wir für Ihre wahre Client-IP-Adresse brauchen, können wir Schwellenwerte zu unserem Vorteil nutzen, indem wir IPs und Signale als Schlüssel verwenden.

2. Passen Sie Angriffsschwellenwerte an

Unter Observed Sources -> Suspicious IPs können wir prüfen, ob sich IPs den Schwellenwerten nähern, ohne sie zu überschreiten.

Die Festlegung von Schwellenwerten ist eine wichtige Funktion unserer NGWAF. Damit können wir verhindern, dass legitimer Traffic bei Fehlalarmen blockiert wird. Wenn IPs die aktuell als Angriffssignal definierten Schwellenwerte nicht erreichen, bedeutet dies, dass der NGWAF potenzielle Angriffe möglicherweise durch die Lappen gehen. 

Der standardmäßig als Angriffssignal definierte Schwellenwert liegt bei 50 Anfragen pro Minute. Im obigen Screenshot können Sie sehen, dass zwei IPs sogar über dem Schwellenwert von 75 % liegen. Das bedeutet, dass etwa 37 SQLi-Anfragen in einer Minute zugelassen wurden. In vielen Fällen ist es sinnvoll, den Schwellenwert zu senken, da man vielleicht nicht so viele Angriffe zulassen möchte. Vor der Änderung des Schwellenwerts sollten Sie jedoch Tests und Validierungen berücksichtigen, damit in der Produktivumgebung keinerlei Probleme auftreten.

Im Falle des SQLi-Angriffs aus dem obigen Beispiel möchten wir den für SQLi festgelegten Angriffsschwellenwert auf 25 Anfragen pro Minute senken.

Dies sollte in der Regel schrittweise geschehen – in einigen Fällen sollten Sie sogar in Betracht ziehen, alle Angriffs-Requests wie SQLi von vornherein zu blockieren. Erstellen Sie zu diesem Zweck eine Anfrageregel, wonach dieses Signal blockiert wird.

3. Blockieren Sie Angriffe von böswilligen IPs

Im Rahmen dieser Anfrageregel lassen sich die als böswillige IP-Adressen festgelegten Signale einsetzen, um Angriffs-Requests unmittelbar zu blockieren, ohne erst abzuwarten zu müssen, bis Schwellenwerte erreicht sind. 

Die NGWAF bezieht IP-Informationen aus mehreren Quellen. Eine davon ist die SANS Malicious IP List, die regelmäßig vom SANS Internet Storm Center</u> importiert wird. IP-Adressen werden aus vielerlei Gründen zu dieser Liste hinzugefügt, zum Beispiel wegen Port-Scanning oder weil sie als Bot- oder Ransomware-Quellen identifiziert wurden. Auf dieser Liste befindliche IPs werden mit dem Signal Malicious IP gekennzeichnet. Die NGWAF importiert auch regelmäßig eine Liste an TOR Exit Nodes des gemeinnützigen The Tor Project. Diese IPs werden mit dem Signal Tor Traffic versehen. Außerdem beobachten wir im Rahmen der IP-Reputation-Funktionalität unserer NGWAF Plattform das Angriffsverhalten aller NGWAF Kunden und fügen sie gegebenenfalls zu unserer internen Gefahrenliste hinzu. Diese IPs werden mit dem Signal SigSci IP gekennzeichnet. 

Die bloße Feststellung dieser drei Signale ist keine Garantie für böswilliges Verhalten. Deshalb empfehlen wir, diese Signale zusätzlich zu den bereits in der NGWAF definierten Angriffssignalen</u> zu verwenden. Mit der unten stehenden Regel wird demnach sofort jeder von einer bekannten Bedrohungsquelle ausgehende Angriffsversuch auf Ihre Anwendung blockiert.

4. Blockieren Sie Anfragen, die aus Ländern auf der OFAC Liste stammen

Wir können eine Regel erstellen, wonach alle Anfragen blockiert werden, die aus einem der auf der Office of Foreign Assets Control (OFAC) Liste aufgeführten Länder stammen. Der Screenshot unten zeigt ein Standortverzeichnis, das zur Identifikation der Ländercodes auf der Liste verwendet wird.

In dieser Liste sind keine Regionen angegeben. Das liegt daran, dass wir mehr als nur den Ländercode benötigen, um den geografischen Standort einer Quell-IP zu bestimmen. 

Um dieses Problem zu lösen, können Sie Ihr Fastly CDN beispielsweise so einrichten, dass die ASN-Informationen</u> in einem Header angegeben werden. Über den ASN-Header können Sie also eine Liste von ASNs festlegen, denen der Zugriff auf Ihre Anwendung verwehrt werden soll, indem Sie eine ähnliche Liste und Anfrageregel erstellen.

5. Blockieren Sie Anfragen von böswilligen User Agents

Diese Maßnahme ist relativ einfach. Wir wollen sicherstellen, dass über einen gültigen User Agent auf die Anwendung zugegriffen wird. Wir können also eine Liste von nicht zulässigen User Agents erstellen und diese sofort blockieren. Hier eine Liste von User Agents, die nie auf meine Anwendung zugreifen sollen:

Hinweis: In dieser Liste wird zwischen Groß- und Kleinschreibung unterschieden, Sie sollten also die Verwendung von Wildcards</u> in Betracht ziehen, um alle Möglichkeiten zu berücksichtigen.

Ich kann diese Liste in einer Anfrageregel verwenden, um Traffic sofort zu blockieren:

6. Blockieren Sie Anfragen mit ungültigem Host-Header

Durch diese Regel werden alle Zugriffe auf die Anwendung blockiert, die direkt über die IP-Adresse erfolgen oder bei denen nicht einmal der Host-Header ausgefüllt ist. Wir können eine Liste gültiger Domains erstellen, die für den Zugriff auf die Anwendung verwendet werden sollen. Alternativ können Sie sie wie unten dargestellt selbst auflisten:

Ich verwende diese Regel, um zu erkennen, wenn der Host-Header nicht mit der Domain meiner Anwendung übereinstimmt, und füge dann ein Signal hinzu, das diese Anfrage als ungültige Anfrage kennzeichnet. Anschließend füge ich eine zweite Aktion hinzu, wonach blockiert wird.

Haftungsausschluss: Diese Regel sollte nur verwendet werden, wenn Sie sicher sind, dass der Host-Header zur Identifizierung gültiger Anfragen verwendet wird. Verwenden Sie im Zweifelsfall die Regel zunächst im Logging-Modus.

7. Blockieren Sie auf einer Website vorgemerkte IP-Adressen

Hinweis: Dieses Signal ist nur in Kombination mit der Premier Lizenz verfügbar.

Mit dem Signal „Site-Flagged-IP“ wird angezeigt, wenn eine Anfrage von einer IP empfangen wurde, die wegen Überschreitung von Angriffsschwellenwerten auf einer bestimmten Website vorgemerkt wurde. Bitte entnehmen Sie Details der entsprechenden Dokumentation: System Signals – Signal Sciences Help Center</u>. 

Mit der unten stehenden Regel lassen sich Anfragen von IP-Adressen blockieren, die gekennzeichnet wurden. Sobald also eine IP böswillig handelt, können wir den gesamten Zugriff auf die Anwendung blockieren.

8. Regulieren Sie Enumeration-Angriffe durch Rate Limiting

Hinweis: Für diese Funktion ist eine Premier Lizenz erforderlich.

Oftmals versuchen Angreifer, eine Anwendung oder API durch Ausprobieren verschiedener Techniken zu „durchleuchten“. Wenn ein Angreifer beispielsweise versucht, mit der Brute-Force-Methode auf Dateien und Verzeichnisse zuzugreifen oder Credential Stuffing auszuführen, wird er wahrscheinlich eine Vielzahl von 4XX- und 5XX-Fehlern</u> generieren. 

Um diese Enumeration-Angriffe frühzeitig im Keim zu ersticken, können wir Rate-Limiting-Regeln zum Schutz der App oder API anwenden. Solche Regeln eignen sich grundsätzlich für allgemeinere Anwendungsfälle, können aber je nach Situation individuell angepasst werden.

In diesem Beispiel suchen wir nach jeglichen Requests, die eine 4XX- oder 5XX-Antwort auslösen. Wenn wir eine solche Anfrage entdecken, werten wir sie als Enumeration-Versuch. Das Zählsignal (in diesem Fall Suspected Attacker) protokolliert diesen Versuch. Ist der Schwellenwert erreicht, werden alle weiteren Anfragen des Angreifers blockiert.

9. Aktivieren Sie Benachrichtigungen über neue Features und Releases

Lassen Sie sich über neue Funktionen und Releases benachrichtigen. Neue Funktionsankündigungen enthalten Informationen über Produktverbesserungen nur für Agent-Releases. Dazu gehören in der Regel Fehlerbehebungen oder Verbesserungen des Agents, die auf die neue Agent-Version angewendet wurden.

Gehen Sie zu Corp Manage > Corp Integration und wählen Sie die folgenden Events aus, um Benachrichtigungen zu aktivieren:

Benachrichtigungen über neue Funktionen werden hier veröffentlicht: Announcements – Signal Sciences Help Center.

„Release Created“ Events gelten nur für Agent-Releases, die hier veröffentlicht werden: Agent – Signal Sciences Help Center.

10. Erfassen Sie Logdaten mit APIs oder Syslog

Die Erfassung von Logdaten ist wichtig, insbesondere im Hinblick auf die Observability Ihrer Sicherheitsprodukte. Dazu können Sie Logdaten zum Beispiel auch von der Next-Gen WAF in Ihr SIEM exportieren. Je nach Anwendungsfall kann dies auf unterschiedliche Weise geschehen. Lesen Sie weiter</u>, um mehr zu erfahren.

Wenn Sie mit der Erfassung von gesampelten/redigierten Daten vertraut sind, empfehlen wir, zum Extrahieren der Daten aus dem NGWAF Dashboard die API zu nutzen. Hier finden Sie ein beispielhaftes Python Skript</u> dafür. Wenn Sie Splunk verwenden, hilft die Splunk App weiter, die ebenfalls die API nutzt.

Wenn Sie sich eher mit nicht gesampelten/unredigierten Daten auskennen, empfehlen wir, Agent Logs mit Syslog zu erfassen und sie dann an einen Syslog Server weiterzuleiten. Dazu müssen wir allerdings die Debug-Logging-Funktion auf dem Agent aktivieren. Fügen Sie die folgenden Konfigurationen zur agent.conf hinzu:

debug-log-web-inputs = 1
debug-log-web-outputs = 1
log-out = “/var/log/sigsci.log”

Für Kunden, die Cloud WAF verwenden, ist diese Debug-Logging-Funktion aktuell nicht verfügbar.

Schützen Sie Ihre Apps mit der Next-Gen WAF

Diese Tipps helfen Ihnen hoffentlich dabei, die Next-Gen WAF von Fastly uneingeschränkt zu nutzen und Ihre Anwendungen – egal wo – besser als je zuvor zu schützen. Sollten Sie weitere Unterstützung benötigen, steht Ihnen das Fastly TAM Team jederzeit zur Verfügung.

Weitere Details zu unserer Next-Gen WAF finden Sie auf der Produktseite</u>.