Dirk Bautz Bei vielen Firmen und Institutionen ist es mittlerweile normal, dass Dienste direkt per Internet erreichbar sind. Sei es der Webshop, die Nachverfolgung für Produktion, Bestellung oder Lieferung, verschiedene Ticketsysteme oder sei es auch nur der Mailserver. Es gibt eine Vielzahl von Diensten die allgemein, von bestimmten Quellen oder nur nach Anmeldung aus dem Internet erreichbar sein müssen.
In der Regel werben die jeweiligen Hersteller oder Anbieter dieser Systeme mit einer einfachen und unkomplizierten Inbetriebnahme. Oft stimmt das auch, die Systeme lassen sich einfach und schnell aufbauen, mit unterschiedlichen Hostnamen ansprechen und somit einfach sowohl intern als auch extern adressieren. Die Anbindung zum Internet basiert meistens nur auf einem NAT Eintrag in der Firewall und normalerweise der Freischaltung des Ports 443 zur Nutzung von HTTPS.
Keine Regel ohne Ausnahme
Allerdings gibt es in fast jedem dieser Systeme Pfade oder Bereiche, die nicht von Extern erreichbar sein sollten. Oft sind das Pfade, die z.B. für die Verwaltung, das Backup oder die Installation benötigt werden. Auch Bereiche, die nur von der Anwendung selbst aufgerufen werden, sollten nicht direkt ansprechbar sein.
Auch wenn der Dienst einen eigenen Anmeldedialog bietet, ist das System selbst erstmal frei und für jeden erreichbar, sofern der Zugriff nicht auf bestimmte Quellsysteme limitiert ist. Somit bietet jedes dieser Systeme grundsätzlich eine Angriffsfläche für Menschen mit genügend krimineller Energie.
Leider machen sich nur wenige IT-Verantwortliche Gedanken, ob ihre Systeme dadurch auch ausreichend sicher sind. Oft hört man dann, dass ja eine Firewall davor geschalten sei. Es kann also nichts passieren, die Systeme sind sicher. Aber ist das wirklich so?
Aktuelles aus der Praxis
Wie man am aktuellen Beispiel von Microsoft Exchange Server sieht, ist das meistens nicht der Fall und daher auch keine gute Idee, sich ausschließlich auf die Netzwerkfirewall zu verlassen. Auch namhafte Hersteller haben Schwierigkeiten, ihre immer komplexeren Systeme entsprechend abzusichern und keine Angriffsfläche zu bieten.
Die klassische Firewall basiert meistens auf Regeln, die das Protokoll, den Port, sowie Quell- und Ziel-Adresse definieren. Es wird noch geprüft, ob das Protokoll auch wirklich das ist, das es vorgibt zu sein oder ob das Antwortpaket auch zu einer Anfrage passt. Next Generation Firewalls gehen noch etwas weiter, aber keines dieser Systeme prüft die eigentlichen Daten, die über die Verbindung gehen, im jeweiligen und aktuellen Kontext. Und genau da liegt das Problem.
Die meisten Angriffe auf Webdienste laufen mittlerweile auf höheren OSI (Open System Interconnection) Schichten und werden daher von einer (Netzwerk-) Firewall nicht als solche erkannt.
Die Kontrolle muss deshalb auch auf den höheren OSI-Schichten stattfinden. Es muss geprüft werden, ob die Daten, die über diesen Netzwerkzugriff gehen, auch zulässig sind. Das kann nur im jeweiligen Kontext sinnvoll stattfinden. Hier kommen entsprechende Application Delivery Controller (ADC) zum Einsatz.
Die ADC arbeiten im ersten Ansatz wie ein Reverse Proxy. Ein reiner Reverse Proxy ist aber für eine Abwehr nicht geeignet, da dieser die nicht zulässigen Anfragen und Daten einfach ebenfalls weiterreichen würde.
Gute ADC-Systeme arbeiten mehrstufig
In der ersten Stufe arbeitet praktisch ein Reverse Proxy. Die Netzwerkzugriffe terminieren am ADC, auf TCP Ebene wird einiges optimiert und die SSL/TLS Ver- und Entschlüsselung wird vorgenommen. Oft findet man auch Caching Funktionen.
In der zweiten Stufe wird schon grundlegend sortiert und geprüft, ob die Zugriffe regelkonform sind (RFC basierend), ob die URL/URI stimmt und ob z.B. bestimmte Header vorhanden oder nicht vorhanden sind. Es können auch Veränderungen an den Daten vorgenommen werden. Das Ganze erfolgt idealerweise sowohl ein- als auch ausgehend.
In der dritten Stufe kann das ADC System eine Authentifizierung vornehmen und somit anonyme Zugriffe auf die dahinter liegenden Webserver verhindern. Über Single-Sign-On-Mechanismen erfolgt dann auch die Anmeldung an weitere Systeme und/oder an die Web –Dienste, die hinter dem ADC liegen.
In der vierten Stufe bieten einige ADC Systeme dann eine voll integrierte Web Application Firewall (WAF). Hier werden die Daten anhand von Regeln und/oder Signaturen geprüft. Optimalerweise ist beides in Kombination möglich. Wichtig ist, dass hier die Daten, die über die bestehende Netzwerkverbindung gehen, geprüft werden. Es wird also geprüft, ob z.B. an dem bestimmten Eingabefeld auch Sonderzeichen zulässig sind. Zusätzlich wird geprüft, ob die URL/URI unzulässige Zeichen enthält oder ob die URL in Abhängigkeit von z.B. bestimmten Headern zulässig ist. Es sind hier sehr viele und tiefgreifende Prüfungen und Auswertungen möglich.
Einige ADC Systeme bieten noch weitere Funktionen, wie eine Front-End Optimierung, ein Bot Management, das die Zugriffe darauf untersucht, ob diese von einem Bot oder von einem Menschen kommen, oder auch ein Reputation Service, der die Quell-IP auf bekannte Aktivitäten prüft.
Warum Application Delivery Controller so wichtig sind
Einem Exchange-Server mit einem vorgeschalteten Application Delivery Controller und aktivierter Authentifizierung für alle Dienste kann die derzeit laufenden Hafnium Attacke nichts anhaben. Der Angriff ist ohne gültige Anmeldung nicht möglich. Wenn dann noch die WAF aktiviert und mit den aktuellen Signaturen ausgestattet ist, kann auch bei einem anonymen Zugriff oder mit gültiger Anmeldung ein Angriff wirksam unterbunden werden.
Ein gutes Beispiel ist hier der Citrix Application Deliver Controller. In der Lizenzierung Premium sind alle oben genannten Prüfungen möglich.
Für die integrierte WAF, die aber auch separat als eigenständiges System ohne ADC betrieben werden kann, sind bereits aktuelle Signaturen verfügbar, die die aktuellen CVE’s beinhalten. Der Citrix ADC ist sowohl on-Prem als auch in den meisten Cloudsystemen verfügbar.
Wir empfehlen grundsätzlich den Einsatz von ADC Systemen bei Veröffentlichung von Web Diensten. Unabhängig davon, ob dies in der Cloud oder im lokalen Rechenzentrum passiert.
