Web-Application-Firewalls (WAF)

Web Application Firewalls (WAF) sind eine Art von Reverse-Proxy-Technologie, die auf Layer 7 des OSI-Stapels (Open Systems Interconnection) ausgeführt wird. Sie werden im Allgemeinen implementiert, um Webanwendungen und Web-Services vor schädlichem Datenverkehr oder Angreifern zu schützen. Eine WAF wird in der Regel als Hardware- oder Softwarekomponente oder als cloudnativer verwalteter Dienst bereitgestellt. Sie arbeitet in erster Linie als Reverse-Proxy, manchmal in einer 1:1-Konfiguration zu Backend-Systemen und manchmal zur Unterstützung mehrerer Backend-Systeme und mehrerer Frontend-IPs oder Hostnamen.

WAFs unterscheiden sich von regulären Reverse-Proxys, da sie zum Schutz der Backend-Anwendung konzipiert sind. Sie leiten Anforderungen nicht einfach transparent weiter, sondern verfügen in der Regel über eine Logik, um die Anforderungen, einschließlich der Anforderungs-URL, der Header, der Quelle und des Bodys, auf schädliche oder potenziell schädliche Inhalte zu überprüfen. Die meisten WAFs implementieren einen allgemeinen Regelsatz, der entweder vom Hersteller oder von einer Community definiert wird, um gängige böswillige Versuche wie SQL-Injection-Versuche, SSRF-Angriffe (Server-Side Request Forgery) oder Ähnliches zu identifizieren. WAFs können außerdem Messungen implementieren, um die Anzahl an Anforderungen in einem bestimmten Zeitraum zu begrenzen, vor verteilten DoS-Angriffen (Denial of Service) zu schützen und den Zugriff so zu filtern, dass IPs aus bestimmten geographischen Gebieten oder Quellen blockiert werden. Jede dieser Regeln kann individuell konfiguriert werden. Die WAF kann Hunderte oder Tausende dieser Regeln implementieren und auf die geschützte Anwendung anwenden.

WAFs verfügen häufig über zwei konfigurierbare Modi:

• Erkennungsmodus: Im Erkennungsmodus wird der Datenverkehr im Allgemeinen transparent durch die WAF geleitet. Dabei werden alle Anforderungen, die eine Regelerkennung auslösen, protokolliert. Anhand dieses Protokolls kann der Administrator möglicherweise gültigen Datenverkehr aufspüren und die betreffende Regel ggf. deaktivieren oder anpassen, um sicherzustellen, dass gültige Anforderungen nicht blockiert werden.
• Schutzmodus: Im Schutzmodus wird jede Anforderung, die diese Regeln auslöst, aktiv blockiert (und ein HTTP-Fehler oder ein Timeout zurückgegeben).

Überwachung des eingehenden Datenverkehrs

Die Überwachung des eingehenden Datenverkehrs bezieht sich auf die Überprüfung und Filterung der bei einem System eingehenden Anforderungen, wobei es gleichgültig ist, ob diese Anforderungen aus internen oder öffentlichen Quellen stammen. Auch wenn sich die Überwachung des eingehenden Datenverkehrs auf Methoden oder Ansätze beziehen kann, die über WAFs hinausgehen, sind diese Konzepte oft eng miteinander verknüpft.

Arbeiten mit WAFs für den Zugriff auf ArcGIS-Systeme

ArcGIS-Software basiert auf einer Vielzahl von HTTP-Anforderungstypen und -Antworten. Sie reichen von GET-, POST- und OPTIONS-Anforderungen bis hin zu großen Content-Bodys, eindeutigen Headern und verschiedenen Methoden für die tokenbasierte Authentifizierung. Eine allzu konservative WAF dürfte sich bei Client-Anwendungen einer ArcGIS Enterprise-Bereitstellung als problematisch erweisen.

Bei der Implementierung oder Verwendung einer WAF mit einer ArcGIS-Bereitstellung sollten daher die folgenden Punkte berücksichtigt werden:

• Im Erkennungsmodus mit tatsächlichem Benutzerverkehr beginnen: Auf diese Weise können gültige Anforderungen (die echte, nützliche Benutzeraktivitäten darstellen) identifiziert werden, die im Schutzmodus von der WAF blockiert würden.
• Empfehlungen von Esri prüfen: Esri hat eine Reihe von empfohlenen Regeleinstellungen für das Azure WAF-Produkt vorbereitet, die zur Identifizierung potenziell problematischer Regeln in anderen WAF-Produkten verwendet werden können.
• Testen, testen, testen: Im Schutzmodus sollte eine umfassende Reihe von Workflows von der Veröffentlichung über die Dateninteraktion bis zum Herunterladen getestet werden, um Regeln aufzuspüren, die möglicherweise falsch konfiguriert sind. Beispielsweise empfiehlt es sich, eine synchrone Geoverarbeitungsanforderung mit langer Laufzeit zu testen, um sicherzustellen, dass das Standard-Timeout des Systems nicht zu kurz eingestellt ist.
• Fehlerbehebung durch 1:1-Tests: Wenn eine Anforderung blockiert wird oder einen Fehler über die WAF zurückgibt, sollte die Anforderung zunächst mit einem HTTP-Client und der Backend-URL (hinter der WAF) getestet werden, um sicherzustellen, dass kein Systemproblem vorliegt. Anschließend kann die WAF-Konfiguration so geändert werden, dass die Anforderung zugelassen wird.

Esri stellt ein detailliertes Beispiel für die Kompatibilität von WAF-Regeln bereit, das auf dem Azure WAF-Angebot basiert und Regeln oder Konfigurationen identifiziert, die bei ArcGIS-Bereitstellungen Probleme verursachen können und deaktiviert werden sollten. Dieses Dokument ist im ArcGIS Trust Center: ArcGIS Enterprise Web Application Filter Rules verfügbar (ArcGIS-Anmeldung erforderlich).

Das Beispiel enthält zwar spezifische Regeln von einem bestimmten WAF-Anbieter, kann aber einen einfacheren Weg zum Konfigurieren der spezifischen WAF-Regelsätze einer Organisation bieten. Außerdem sollte berücksichtigt werden, dass bestimmte Anwendungsfunktionen durch eine WAF blockiert werden können. Dies kann akzeptabel sein, wenn die Anwendung oder der Service nicht für die Verwendung mit einem System vorgesehen ist, sodass die Tatsache, dass der Datenverkehr blockiert wird, als unwichtig angesehen werden kann. Sobald weitere WAF-Tests oder -Validierungen abgeschlossen sind, werden auf dieser Seite zusätzliche Ressourcen referenziert. Zum gegenwärtigen Zeitpunkt ist der Azure WAF-Regelsatz das einzige verfügbare detaillierte Beispiel, auch wenn er möglicherweise die ordnungsgemäße Konfiguration anderer WAF-Produkte oder -Angebote beeinflusst.