Im Rahmen der Thesis "Sicherheitskonzepte für Anwendungen in der Cloud" wird anhand einer bestehenden Cloud-Applikationen eine Mechanismus zur Absicherung der Anwendung konzipiert. Hierbei handelt es sich um einen Software-as-a-Service Dienst, der dem Endkunden zur Verfügung gestellt werden soll. Dieser hat per Definition somit keinerlei Möglichkeiten die Platform oder die darunterliegende Infrastruktur gegen Angriffe von Außerhalb zu konfigurieren. Diese Vorkehrungen müssen aus diesem Grunde von dem Anbieter der Cloud-Dienstes eingerichtet werden. Von Seiten der Rechenzentren, die Dienste wie Platform-as-a-Service oder Infrastructure-as-a-Service anbieten, wird in den häufigsten Fällen direkt an der Firewall auf verdächtiges Verhalten im Netzwerk-Traffic geachtet und bei auftauchenden Anomalien ein vorgefertigtes Protokoll ausgeführt, das die betriebenen Anwendungen von Gefahren wie Denial of Service (DoS) oder Distributed Denial of Service (DDoS) schützen soll. Dies ist jedoch nicht immer gegeben und die Vorkehrungen, die von den Anbietern getroffen werden, sind in den meisten Fällen nicht klar ersichtlich.
Das Endprodukt dieser Arbeit soll durch Verwendung von maschinellen Lernalgorithmen und der Funktion als Proxy den eingehenden Netzwerkverkehr überwachen und bei Anomalien ein Throttling einleiten, das die oben beschriebenen Threat-Modelle abwehren soll.
Zur Simulation der vorhandenen Cloud-Umgebung wurde, wie im nachfolgenden Schema skizziert, ein Anwendungsverbund aus NGINX Reverse Proxy (lokaler Ersatz für einen Ingress), einem Duende Identity Server (Identity Provider), zwei Web APIs (schützenswerte Ressourcen) und einer Angular Single Page Applikation konzipiert.
Für das Messen von Metriken und Lastverteilungen wurden zusätzlich eine Prometheus und Grafana Instanz in die Architektur eingebracht. Zur Log-Analyse wird Elasticsearch und Kibana verwendet.
Bei erfolgreicher Implementierung des Intrusion Detection bzw. Prevention Systems (nachfolgend auch ML.Proxy genannt), wird dieser zwischen den NGINX Reverse Proxy bzw. im Kubernetes Kluster direkt hinter den Ingress des Klusters gestellt. Dies soll gewährleisten, dass alle Anfragen, die an das Backend gehen zuerst über den ML.Proxy geprüft und bei verdächtigem Verhalten gedrosselt werden.
Im Rahmen dieser Arbeit wurde das Szenario des DoS- bzw. DDoS-Angriffs als Vektor für das Intrusion Detection und Prevention System gewählt. Hierbei werden in der Praxis die Tools LOIC, Slowloris und GoldenEye eingesetzt, die auf unterschiedliche Art und Weise einen Denial of Service bei den zu attackierenden Anwendungen auslösen sollen. Nach simulierten Angriffen mit den genannten Anwendungen konnte aufgrund der Deaktivierung des Ports 80 und einer Reduzierung des zulässigen Client-Timeouts beim vorgelagerten NGINX die Gefahren durch LOIC und Slowloris eliminiert werden. Die genaue Ursache, weshalb diese Tools ihre Effektivität auf verteilte Cloud-Anwendungen eingebüst haben, sind in den Kapiteln der Analyse des Soll-Ist-Zustandes der beiliegenden Arbeit zu entnehmen. Einzig das GoldenEye-Tool besitzt die Möglichkeit durch Absetzen von Anfragen mittels TLS 1.2 die Backend-Anwendungen durch den vorgelagerten NGINX zu attackieren. Genau an diesem Punkt setzt die Funktion des ML.Proxy ein. Durch die Verwendung von YARP, einer Bibliothek zur Simulation von Proxy-Verhalten mit einer .NET-Webanwendung und ML.NET, konnte ein Mechanismus etabliert werden, der eingehende Angriffe aufgrund ihrer Paketgröße identifiziert und blockt. Für das Mitschneiden der Netzwerkpakete wurde SharpPcap und Packet.NET eingesetzt, die es ermöglichen Netzwerkverkehr auf den vorhandenen Netzwerkinterfaces abzuhören und zu prozessieren. Für das Throtteling bzw. Blockieren der einzelnen Anfragen kam die Bibliothek ThrottlR zum Einsatz. Hier wurden vereinzelt Änderungen vorgenommen, damit die bereitgestellte Middleware auf die eingeführten Attack-Header reagiert und die markierten Anfragen blockt. Die verwendeten Trainingsdatensätze sind Teil eines Projektes der University of New Brunswick, die auf Basis einer simulierten Anwendungslandschaft innerhalb einer AWS Infrastruktur Angriffe simuliert und den aufgetretenen Netzwerkverkehr mitgeschnitten hat. Für die Erstellung der Datensätze und die Berechnung der enthaltenen Werte kam die Software CICFlowMeter-V3 zum Einsatz, die als Grundlage für die Berechnung der eigenen verwendeten Werte innerhalb des ML.Proxy, fungierte.
Für den Start der Anwendung muss eine Docker Desktop Version auf dem lokalen Rechner installiert sein. Anschließend kann die Anwendung entweder innerhalb von Visual Studio oder mittels des Docker-Compose Befehls im Root-Verzeichnis des Projektes gestartet werden:
docker-compose up -d --buildDes Weiteren besteht die Möglichkeit für den Betrieb in einem Kubernetes-Kluster. Die Manifest-Files und Deployment-Skripte für die Ausführung via Powershell liegen dem Projekt bei. Verwendet werden sie wie folgt:
# Baut die Container und transferiert sie auf eine Container Registry
.\BuildContainerAndPushToRegistry.ps1 Build
# Platziert die Anwendung innerhalb eines Namespaces im Kubernetes Kluster
.\manifests\DeployToAzure.ps1 Install
- Prometheus Konfiguration für Docker-Compose aus dem aktuellen Repo
- Angular OAuth OIDC Package Konfiguration aus dem aktuellen Repo
- Konfiguration für das Grafana Dashboard von hier
- "Adding ML.NET to your Web APIs", .NET Live Video
- Fortführende Dokumentation zu ML.NET bei Microsoft Learn
- Weitere .NET Community Standups zum Thema ML.NET
- Metriken aus dem NGINX auslesen von hier