Cloudflare WAF erkennt jetzt vollständige HTTP-Transaktionen

Ab sofort erweitern wir unsere Web Application Firewall (WAF) um zwei neue Funktionen: die Erkennung vollständiger HTTP-Transaktionen und Antwortregeln. Bei der Erkennung vollständiger Transaktionen werden HTTP-Anfragen gemeinsam mit den jeweiligen Antworten analysiert, um Hinweise auf die erfolgreiche Ausnutzung von Schwachstellen zu finden. So lässt sich nicht nur die Frage beantworten, ob eine Anfrage verdächtig ist, sondern auch, was tatsächlich passiert ist, als die Anwendung sie verarbeitet hat. Mit den neuen Antwortregeln lässt sich die Antwort des Ursprungsservers blockieren, bevor sie den Anfragenden erreicht.

Diese zusätzlichen Schutzfunktionen sind besonders wichtig, weil die neuesten hochentwickelten KI-Modelle zunehmend Schwachstellen aufdecken, die tief in weitverbreiteter Software verborgen sind. Das hilft Sicherheitsteams dabei, gezielt Sicherheitslücken zu schließen. Gleichzeitig eröffnet es Angreifern aber auch neue Möglichkeiten, solche Schwachstellen auszunutzen. Wie groß die Gefahr sein kann, zeigt die kürzlich aufgedeckte Schwachstelle php2shell: Schon eine Sicherheitslücke in einer weitverbreiteten Softwarekomponente kann Anwendungen im gesamten Internet gefährden. KI-Agenten, die gezielt nach Schwachstellen suchen, können dabei äußerst hartnäckig vorgehen. Sie passen ihre Angriffsmethoden anhand der erhaltenen Rückmeldungen laufend an und kombinieren verschiedene Schwachstellen, Zugangsdaten und Berechtigungen, um tiefer in Systeme einzudringen. Die Antwort einer Anwendung kann dabei verraten, ob ein Angriffsversuch erfolgreich war. Gleichzeitig liefert sie Angreifern möglicherweise weitere Informationen, mit denen sie ihren Angriff fortsetzen können.

Die Überprüfung eingehender Anfragen bleibt deshalb unverzichtbar, um bekannte Angriffsmuster frühzeitig zu erkennen und Angriffe abzuwehren, bevor sie die Anwendung erreichen. Manche Bedrohungen lassen sich allerdings erst erkennen, wenn auch die Antwort des Ursprungsservers berücksichtigt wird. Denn es macht einen entscheidenden Unterschied, ob eine verdächtige Anfrage dazu führt, dass sensible Informationen preisgegeben werden, oder ob die Anwendung die Anfrage zurückweist beziehungsweise eine Fehlermeldung ausgibt.

Mit den neuen Funktionen können Cloudflare-Kunden entweder die von Cloudflare bereitgestellten Schutzmechanismen nutzen oder eigene Sicherheitsregeln erstellen, die sowohl Eigenschaften der Anfragen als auch der zugehörigen Antworten berücksichtigen. Damit bauen wir unser Framework für den kontinuierlichen Anwendungsschutz weiter aus. Die Ergebnisse der Bedrohungserkennung stehen in Security Analytics zur Verfügung und können dort für Sicherheitsanalysen und Untersuchungen genutzt werden.Unsere ersten vorkonfigurierten Schutzmechanismen auf Basis dieser neuen Technologie richten sich gegen die kürzlich bekannt gewordene Schwachstelle php2shell.

Und das Beste daran: Die neuen Funktionen stehen allen Cloudflare-Kunden zur Verfügung – auch Nutzern des kostenlosen Free-Tarifs.

Die Überprüfung von Anfragen allein reicht nicht aus

Cloudflare WAF schützt Websites und APIs mithilfe von verwalteten Regeln, benutzerdefinierten Regeln und Rate Limiting. Verwaltete Regeln schützen vor bekannten Angriffstechniken und Schwachstellen. Mit benutzerdefinierten Antwortregeln wird die Erkennung vollständiger Transaktionen zu einem direkten Schutzmechanismus: Sie können übereinstimmende Antworten des Ursprungsservers blockieren, bevor diese den Anfragenden erreichen. Diese Schutzmaßnahmen greifen auf Anfrageebene und verhindern, dass Angriffe oder unerwünschter Traffic den Ursprungsserver erreichen.

Bei vielen Bedrohungen ist dies der richtige Ansatz. Werden jedoch alle verdächtigen Anfragen als bestätigte Angriffe eingestuft, entsteht ein schwieriger Zielkonflikt. Breit gefasste Angriffssignaturen können zwar mehr potenzielle Angriffe erkennen, aber auch Fehlalarme (False Positives) auslösen, indem sie legitimen Traffic als Angriff einstufen. Dadurch kann die Funktionsfähigkeit von Anwendungen beeinträchtigt werden. Werden hingegen nur Regeln eingesetzt, die keine Fehlalarme auslösen, sinkt dieses Risiko. Gleichzeitig steigt jedoch die Wahrscheinlichkeit, dass nicht eindeutig einzuordnender Traffic den Server erreicht.

Die Antwort liefert die fehlenden Hinweise. Cloudflare kann sie jetzt mit der zugehörigen Anfrage verknüpfen und so bei der Erkennung das Ergebnis der gesamten HTTP-Transaktion berücksichtigen.

Betrachten wir beispielsweise eine Anwendung, mit der Nutzer Dateien herunterladen können. Ein Angreifer manipuliert den Dateiparameter, um eine private Konfigurationsdatei außerhalb des zulässigen Verzeichnisses anzufordern:

GET /download?file=../../config/database.ini

Die Überprüfung der Anfrage kann diesen Directory-Traversal-Versuch erkennen und blockieren, bevor er die Anwendung erreicht. Anhand der Anfrage allein lässt sich jedoch nicht feststellen, ob die Anwendung die Datei tatsächlich preisgeben würde. Möglicherweise weist sie die Anfrage zurück, ignoriert den Directory-Traversal-Versuch oder gibt eine Fehlermeldung zurück.Wenn die Anfrage den Ursprungsserver erreicht, kann eine Antwort wie diese zusätzliche Hinweise liefern:

200 OK
Content-Type: text/plain
[database]
username=app_service
password=EXAMPLE_SECRET

Die Erkennung vollständiger Transaktionen schließt hier eine entscheidende Lücke: Sie kann den versuchten Dateizugriff mit Antwortinhalten verknüpfen, die für eine private Konfigurationsdatei typisch sind. Texte, die Konfigurationsdateien ähneln, können auch in legitimen Dokumentationen oder Beispieldateien vorkommen. In Kombination mit einem Directory-Traversal-Versuch liefern sie jedoch deutlich stärkere Hinweise auf die Offenlegung sensibler Daten als jedes dieser Anzeichen für sich genommen. Eine Antwortregel kann daraufhin die Antwort des Ursprungsservers durch eine Cloudflare-WAF-Blockierungsseite mit dem HTTP-Statuscode 403 ersetzen, bevor sie den Anfragenden erreicht. So wird der Angriff wirksam blockiert, indem verhindert wird, dass sensible Informationen an den Angreifer gelangen.

Erkennung und Abwehr sind bewusst voneinander getrennt

Die Erkennung vollständiger Transaktionen erweitert das ​Framework zur kontinuierlichen Bedrohungserkennung, das wir Anfang dieses Jahres eingeführt haben. Dabei analysieren Erkennungsmechanismen den Traffic und versehen Anfragen und Antworten mit Metadaten. Anschließend entscheiden Regeln, wie mit den Ergebnissen umgegangen wird.

Durch die Trennung dieser beiden Aufgaben erhalten Kunden zunächst einen besseren Überblick, bevor sie eigene Sicherheitsrichtlinien festlegen. Sicherheitsteams können die Erkennungsergebnisse in ihrem eigenen Traffic untersuchen, nachvollziehen, welche Endpunkte und Signaturen betroffen sind, und die passende Reaktion für ihre Anwendung auswählen. Ähnlich wie bei der anfragebasierten ​Attack Signature Detection werden die Erkennungsergebnisse in Feldern gespeichert. Diese lassen sich in benutzerdefinierten Antwortregeln verwenden oder für die Blockierung von Traffic durch verwaltete Erkennungsmechanismen nutzen.

Analog zu den bestehenden Feldern für die anfragebasierte Erkennung ergänzen wir unsere Plattform um folgende neue Felder:

Die ersten Erkennungsmechanismen für vollständige Transaktionen konzentrieren sich darauf, die Ausnutzung besonders bekannter Schwachstellen zu bestätigen. Dazu gleichen sie verdächtige Eingaben mit Merkmalen der Antwort ab, die auf einen erfolgreichen Angriff hindeuten können.

Im Laufe der Zeit werden wir die Abdeckung auf weitere Anwendungsfälle ausweiten, darunter die Erkennung offengelegter Daten und von Anzeichen für Datenexfiltration. Das ist über einzelne Anwendungen hinaus für das gesamte Internet von Bedeutung: Schutzmechanismen können zwischen bloßen Angriffsversuchen und Hinweisen auf tatsächliche Auswirkungen unterscheiden. Gleichzeitig profitieren auch Kunden ohne eigenes Sicherheitsteam, das jede WAF-Regel individuell optimiert, von der Erkennung offengelegter Daten und Dienste.

Regeln für Antworten erstellen

Die Erkennung von Hinweisen auf die Ausnutzung einer Schwachstelle ist besonders wertvoll, wenn sich darauf in Echtzeit reagieren lässt. Mit benutzerdefinierten Antwortregeln wird die Erkennung vollständiger Transaktionen zu einem direkten Schutzmechanismus: Sie blockieren die Antwort des Ursprungsservers, bevor diese den Anfragenden erreicht. Bereits auf dem Ursprungsserver ausgeführte Aktionen lassen sich dadurch allerdings nicht rückgängig machen.

Sicherheitsteams können jetzt Eigenschaften von Anfragen und Antworten mit den Erkennungsergebnissen kombinieren und so festlegen, welche Antworten blockiert werden sollen. Wenn eine Blockierungsregel greift, ersetzt Cloudflare die Antwort des Ursprungsservers durch eine WAF-Blockierungsseite oder eine benutzerdefinierte Antwort.

Die Einstellungen für die Antwortphase befinden sich im Cloudflare-Dashboard unter Sicherheit > Sicherheitsregeln  am unteren Seitenrand. Dort stehen sowohl verwaltete Schutzmechanismen als auch benutzerdefinierte Regeln zur Verfügung.

Wir haben beide Regeltypen für alle Tarife freigegeben, einschließlich des kostenlosen Free-Tarifs. Langfristig werden wir denselben Ansatz wie bei der anfragebasierten Erkennung verfolgen: In kostenlosen Tarifen konzentrieren sich die verwalteten Erkennungsmechanismen​ auf besonders relevante Schwachstellen, während zahlende Kunden Zugriff auf einen umfangreicheren Katalog an Erkennungsmechanismen erhalten.

Verwaltete Erkennungen

Alle Kunden profitieren vom vollständigen Schutzumfang der Transaktionserkennung durch das Regelwerk Cloudflare Managed Response Firewall Default. Dieses ermöglicht eine einfache Aktivierung mit nur einem Klick und eine unkomplizierte Konfiguration. Wenn eine Signatur übereinstimmt, blockiert der verwaltete Erkennungsmechanismus die Antwort und gibt stattdessen eine standardmäßige WAF-Blockierungsseite zurück.

Sie können den Geltungsbereich von Cloudflare Managed Response Firewall Default anpassen, sodass die Erkennung nur für bestimmte Teile Ihrer Anwendungen ausgeführt wird. Beispielsweise können Sie einzelne Pfade ausschließen oder die Erkennung auf einen bestimmten Pfad beschränken. Zahlende Kunden können die Erkennungsfelder außerdem in benutzerdefinierten Antwortregeln verwenden, um gezieltere Sicherheitsrichtlinien zu erstellen.

Benutzerdefinierte Regeln

Mit benutzerdefinierten Antwortregeln erhalten Kunden die volle Kontrolle über die Regellogik. Eine solche Regel kann beispielsweise verhindern, dass eine Administrationsoberfläche zugänglich wird, wenn ein Authentifizierungs-Gateway die Anfrage nicht als intern gekennzeichnet hat. Beispiel:

http.request.uri.path starts_with "/admin" and not http.request.headers["x-internal-user"][0] eq "true" and http.response.code eq 200 and http.response.headers["content-type"][0] contains "text/html"

Die Regel blockiert die Antwort nur dann, wenn eine nicht authentifizierte Anfrage auf /admin zugreift und der Ursprungsserver tatsächlich eine erfolgreiche HTML-Antwort mit der Administrationsoberfläche zurückgibt. Normale Authentifizierungsfehler, Weiterleitungen oder Traffic, der nicht die Administrationsoberfläche betrifft, werden hingegen nicht blockiert.

Dabei lassen sich bis zu drei benutzerdefinierte Antwortregeln erstellen, die die Aktionen Log (Protokollieren) und Block (Blockieren) unterstützen. Welche Felder und Funktionen für benutzerdefinierte Antwortregeln verfügbar sind, hängt vom jeweiligen Tarif ab. Der Funktionsumfang entspricht dabei dem der bereits verfügbaren ​benutzerdefinierten Anfrageregeln. Regeln, die den Inhalt des Antwort-Bodys berücksichtigen, lassen sich derzeit noch nicht erstellen.

Ähnlich wie bei der  Attack Signature Detection können zahlende Kunden außerdem über die oben aufgeführten Felder cf.waf.signature.response.*  auf die Ergebnisse der Angriffserkennung zugreifen. Diese Felder lassen sich mit weiteren Parametern wie Hostname, URL-Pfad, Quell-IP-Adresse oder Anfrage-Header kombinieren. Dadurch können Schutzmaßnahmen gezielt auf einzelne Pfade angewendet oder auf bestimmte Bereiche einer Anwendung beschränkt werden. Die neuen Antwortfelder werden derzeit schrittweise für alle Kundenkonten bereitgestellt. Falls Sie noch keinen Zugriff darauf haben, wenden Sie sich bitte an Ihr Account-Team.

Übereinstimmende Anfragen untersuchen

Wenn eine verwaltete oder benutzerdefinierte Antwortregel eine Transaktion protokolliert oder blockiert, wird das entsprechende Ereignis unter Sicherheitsereignissen angezeigt. So können Sicherheitsteams jede erkannte Bedrohung auf den vollständigen Kontext der Anfrage und die Regel zurückführen, die die entsprechende Aktion ausgelöst hat.

Derzeit werden sowohl Regeln, die ausschließlich Anfragen überprüfen, als auch Regeln für vollständige Transaktionen auf derselben Analyseseite angezeigt. Unter Security Events werden die von Antwortregeln erzeugten Ereignisse den Diensten Managed Rules oder Custom Rules zugeordnet. Im entsprechenden Bereich der Regelliste können Sie die Ereignisse nach einer bestimmten Regel-ID filtern.

Jetzt loslegen

Die Erkennung vollständiger Transaktionen ist ab sofort für alle Zonen verfügbar, deren Traffic über Cloudflare geleitet wird. Um zu überprüfen, ob Ihre Anwendungen geschützt sind, öffnen Sie im Cloudflare-Dashboard den Bereich Sicherheit > Sicherheitsregeln. Wenn Sie Ihre Sicherheitsrichtlinien anpassen möchten, überprüfen Sie zunächst die Ergebnisse der Erkennung vollständiger Transaktionen unter Security Analytics. Anschließend können Sie passende Sicherheitsregeln für die Antwortphase Ihrer Anwendung erstellen.