Unsere Reihe zu Signals, Teil 3: Signale auf der Edge

In Teil 1 dieser Blogpost-Reihe haben wir Ihnen anhand einiger Beispiele für die Blockierung von mutmaßlich schädlichem oder unerwünschtem Verhalten gezeigt, welche Möglichkeiten Ihnen die nutzerdefinierten Signale unserer Next-Gen WAF bieten. Teil 2 befasste sich mit Systemsignalen, die es Security- und DevOps-Teams ermöglichen, Web-Apps und APIs ohne eigene Konfigurationen zu schützen.

In Teil 1 dieser Blogpost-Reihe haben wir Ihnen anhand einiger Beispiele für die Blockierung von mutmaßlich schädlichem oder unerwünschtem Verhalten gezeigt, welche Möglichkeiten Ihnen die nutzerdefinierten Signale unserer Next-Gen WAF bieten. Teil 2 befasste sich mit Systemsignalen, die es Security- und DevOps-Teams ermöglichen, Web-Apps und APIs ohne eigens erstellte Konfigurationen zu schützen.

In Teil 3 der Signals-Reihe beschäftigen wir uns mit zwei weiteren Anwendungsfällen: dem Erkennen bekannter Angreifer und dem Tracken von Antwortcodes. Außerdem erfahren Sie, wie Sie mithilfe von Signalen die Sicherheit Ihrer Systeme verbessern und wie Sie nachgelagerte Systeme durch die Verlagerung gewisser Sicherheitsentscheidungen auf Fastlys Edge mithilfe von nutzerdefinierten Antwortcodes noch besser schützen können.

Erkennen bekannter Angreifer

Um den Schutz vor Cyberangriffen wird viel Lärm gemacht, und das aus gutem Grund: Code-Injection-Angriffe, Exfiltration von Kundendaten und API-Missbrauch sind laufende Bedrohungen beim Bereitstellen von Webservices. 

Aber jede Medaille hat zwei Seiten, und eine davon wird bei der Bedrohungsanalyse oft nicht berücksichtigt: Zu viele Fehlalarme und „Alarmmüdigkeit“ (auch als „Alert Fatigue“ bezeichnet) überlasten Teams. Denn Sicherheitsteams, die laufend False Positives nachgehen müssen, arbeiten weniger effizient. 

In einem Bericht der ESG heißt es, dass 23 % der Sicherheitsexperten der Meinung sind, dass die größte Herausforderung für ihr Unternehmen in der Bewältigung von Unmengen an Cybersicherheitsalarmen liegt. Eine Maßnahme im Kampf gegen die Alarmmüdigkeit ist die automatische Erkennung bekannter Angreifer mithilfe einer WAF. Indem Traffic oder Anfragen durch Metadaten als „gutartig“ gekennzeichnet werden, kann sich Ihr Team besser auf die wirkungsvolle Abwehr von echten Bedrohungen konzentrieren. Die Fastly Next-Gen WAF bietet Ihnen die Möglichkeit, zu dieser Art von Traffic ein spezifisches Signal hinzuzufügen. Dies kann entweder über eine IP-Adresse oder über sonstige eindeutige Kennungen erfolgen. 

Im Folgenden finden Sie ein Beispiel zum Konfigurieren von Regeln für eine Website, mit denen ein nutzerdefiniertes Signal zur Kennzeichnung eines gängigen, in einer Liste von IP-Adressen aufgeführten Scanners eingefügt wird. Sobald eine solche Liste erstellt wurde, lässt sich die eigentliche Site Rule relativ einfach festlegen. Schauen wir uns die grundlegenden Schritte in der UI an: Zuerst erstellen wir eine Liste, die wir unmittelbar für die Regel nutzen. In diesem Beispiel liegt uns eine Liste der zu erkennenden IP-Adressen vor:

Im obigen Screenshot haben wir drei fiktive IP-Adressen hinzugefügt, die für bekannte Schwachstellenscanner stehen. Sobald die Liste erstellt wurde, können wir dieser Traffic-Kategorie mithilfe einer neuen Anfrage-Regel wie folgender ein Signal zuweisen:

Mit dieser Regel lassen wir Traffic von den in dieser speziellen Liste aufgeführten IP-Adressen zu und kennzeichnen die entsprechende Anfrage für zukünftige Zwecke mit dem Signal known-scanner. Ohne diese Regel würde die Fastly Next-Gen WAF den Traffic auf Angriffe untersuchen und den Scanner bei seiner Arbeit behindern. Das hätte unnötige Alarmmeldungen an Ihre Sicherheitsteams zur Folge. Anhand des an die Anfrage angehängten Signals known-scanner können Sie zudem die Aktivität, die Sie vom Scanner erwarten, bestätigen und visualisieren. 

Als Nächstes zeige ich Ihnen eine komplexere Methode zum Tracken von Angriffen, bei der wir nicht nur die eingehende Payload betrachten, sondern auch die Auswirkungen, die die Anfrage auf eine nachgelagerte Anwendung hatte (oder eben nicht hatte).

Antwort-Tracking

Einfache Ansätze zur Bedrohungsanalyse im Web gehen oft davon aus, dass mögliche Angreifer leicht durchschaubar sind. Alle Angreifer tragen (selbstverständlich) einen schwarzen Hoodie und verfügen über eine einzige, ausgeklügelte Payload. Diese Payload senden sie genau an die richtige Stelle der Anwendung (URL) und verursachen so die absolute Katastrophe im angegriffenen System – meist in Form einer Datenexfiltration, eines Denial of Service oder einer anderen Form des Missbrauchs.

Danach geht es dann so weiter: Wie schön wär’s nur, wenn wir die perfekte Möglichkeit hätten, diesen Angriff (in Form einer bösartigen HTTP-Anfrage) abzufangen. Dann könnten wir ihn unterbinden, bevor er Schaden anrichtet, und hätten sozusagen das Nirvana der Websicherheit erreicht. 

Nicht selten baut der Schutz von Webanwendungen auf diesem etwas einseitigen Denkprozess auf. Die Folge ist ein Modell, das auf bereits bekannten Bedrohungen und Signaturen basiert. Es ist also wenig überraschend, wenn sich in herkömmlichen WAFs im Laufe der Zeit Hunderte (oder sogar Tausende) von Regeln ansammeln. Gibt es da nicht vielleicht einen besseren Ansatz? 

Mit nutzerdefinierten Signalen können wir diese Logik erweitern und sogar noch einen Schritt weitergehen. Die Fastly Next-Gen WAF bestimmt sowohl anhand der Anfrage als auch der Antwort, ob ein Anfrage/Antwort-Paar mit einem Angriffs- oder Anomaliesignal versehen wird. Einige unserer Systemsignale (wie beispielsweise forcefulbrowsing) basieren auf der Kenntnis von Anfrage und Antwort, bevor das Signal zu einer Anfrage hinzugefügt wird.

Dadurch wird der simple Schutz vor Fire-and-Forget-Angriffen auf das Erlangen von Transparenz und Erkenntnissen über deutlich raffiniertere Angriffe ausgedehnt. Wäre es nicht gut, wenn wir herausfinden könnten, auf welche Weise Angreifer nach Schwachstellen eines Authentifizierungs-Endpoints suchen? Authentifizierungs-APIs sind beliebte Ziele für Angreifer, da sie von Haus aus ziemlich ungeschützt dastehen. Anderenfalls würden diese APIs ja nicht funktionieren können. Ein nutzerdefiniertes Signal zum Tracken von Authentifizierungsfehlern (in diesem Fall HTTP 302) kann Sie auf enorm viele fehlgeschlagene Anmeldungen aufmerksam machen – möglicherweise ein Zeichen für versuchte Credential-Stuffing-Angriffe. Im Folgenden finden Sie eine einfache Vorlage zum Erstellen einer Site Rule für diesen Fall:

Im vorherigen Beispiel haben wir fehlgeschlagene Authentifizierungen mit dem Signal AuthFailure getaggt. Noch wissen wir nicht, ob uns jemand schaden wollte, aber unerwartet viele fehlgeschlagene Authentifizierungen könnten ein Hinweis auf einen laufenden Angriff sein. Diese Art von Erstindikatoren könnte Sie dazu veranlassen, die Anwendung, die für die Authentifizierung zuständig ist, mit zusätzlichen Sicherheitskontrollen zu versehen, da solche Indikatoren einen möglichen koordinierten Angriff erkennen lassen. Auf einem nutzerdefinierten Dashboard könnte das Signal so aussehen:

In diesem Beispiel zeigt ein Dashboard, wie häufig dieses Signals über die vergangene Stunde hinweg aufgetreten ist. Zwischen 10:30 Uhr und 10:45 Uhr fällt ein deutlich höheres Auftreten dieses Signals auf. Dies könnte ein Hinweis auf einen Angriffsversuch sein, insbesondere dann, wenn dieses Signal normalerweise viel seltener vorkommt.

Ausweiten des Schutzes auf die Edge

Antworten zu tracken ist eine gute Idee, aber was ist mit Enforcement-Maßnahmen wie Blocking oder Rate Limiting? Was ist, wenn Sie diese Maßnahmen bereits an einer vorgelagerten Stelle ergreifen wollen? An dieser Stelle ist die Chance wohl schon vertan. Schließlich hat der Agent seine Arbeit bereits erledigt und die Antwort ist schon auf dem Weg zum Client. 

Hier kann eine Ausweitung des Sicherheitsperimeters auf die Edge weiterhelfen. Signale in der Antwort können anhand von nutzerdefinierten Antwortcodes an die Edge zurückgereicht werden. Auf diese Weise lassen sich aus den von der Next-Gen WAF bereitgestellten zusätzlichen Informationen Maßnahmen für die Deliver und Compute Umgebungen von Fastly ableiten. Für Varnish Kunden gestaltet sich das Ganze so einfach wie das Hinzufügen von Logik um die Variable beresp.status. Compute Kunden könnten auf ähnliche Weise mit den (sprachabhängigen) relevanten Variablen in der Antwort vorgehen.

Die Variable beresp.status enthält den HTTP-Statuscode der von Ihrem Origin-Server empfangenen Antwort. Wenn Ihre Site Rule beispielsweise eine 550 anstatt einer 401 zurückgibt, könnte die Edge an dieser Stelle Sicherheitsentscheidungen wie Blocking, Edge Rate Limiting oder Tarpitting des Clients treffen. Alle diese Maßnahmen würden den Angreifer ausbremsen und Traffic für die Dauer des Angriffs vom Origin fernhalten. Dieser zusätzliche Schutz lässt sich zum Beispiel umsetzen, indem Sie die Blocking-Regel wie folgt modifizieren und den Antwortcode ändern:

Nach dem Ändern der Regel in der Next-Gen WAF kann Varnish um weitere Sicherheitslogik ergänzt werden. Diese Logik ergreift Maßnahmen, wenn „beresp.status“ den Wert 550 hat. Wenn die Bedrohung für Ihre Anwendung immer ausgefeilter und umfangreicher wird, steigt auch der Vorteil der Sicherheitsdurchsetzung auf der Edge. 

Fastlys Next-Gen WAF kann das Treffen von Sicherheitsentscheidungen auf eine Vielzahl von Stellen in einer Umgebung verteilen. Dadurch werden Schutz und Entscheidungsfindung an mehreren Stellen realisiert: auf der Edge, in den Anwendungen selbst (Core-Bereitstellung) oder als eigenständiger Reverse-Proxy (Cloud WAF). 

Vorschau auf den nächsten Teil

Wir hoffen, dass die in diesem Blogpost vorgestellten weiteren Anwendungsfälle für nutzerdefinierte Signale Ihnen Inspiration für nützliche Anwendungsmöglichkeiten in Ihrem Unternehmen gegeben haben. Für sonstige Konzepte oder Beispiele wenden Sie sich bitte an Ihren Technical Account Manager. Auch unseren nächsten Beitrag aus dieser Blogpost-Reihe sollten Sie auf keinen Fall verpassen.

Noch kein Fastly Next-Gen-WAF-Kunde? Kontaktieren Sie uns. Wir beraten Sie gerne.