Im November 2020 führte der Cloud-Anbieter Amazon Web Services die AWS Network Firewall als neuen AWS Managed Service ein. Damit wird es einfacher, erweiterte Regeln für die verbesserte Sicherheit des Netzwerks für die umliegenden AWS-Umgebungen bereitzustellen.
Erfahren Sie mehr darüber, wie wir die AWS Network Firewall als Egress Filtering System in einen Networking-Account implementieren. Und wie wir mit Suricata-Regeln dafür sorgen, dass nur bestimmte Domänen für die Backend-Services über das Internet erreichbar sind.
Die AWS Network Firewall ist eine Virtual Managed Firewall, die in die AWS-Plattform integriert ist. Sie schützt Amazon Virtual Private Clouds (VPCs) vor Netzwerkbedrohungen. Dabei ist die Egress Firewall skalierbar und passt sich somit den Anforderungen wachsender Cloud-Umgebungen jederzeit flexibel an.
Die Firewall umfasst eine flexible Regel-Engine, die im Hintergrund Suricata unterstützt. Suricata ist die führende Open Source Engine zum Erkennen von Bedrohungen. Zusätzlich können bereits bestehende Regeln aus anderen Systemen in die Egress Firewall importiert werden.
Die AWS Network Firewall kann mehrere Availability Zones (AZ) umfassen und damit eine hohe Verfügbarkeit gewährleisten.
Große Cloud-Ökosysteme, die aus mehreren AWS-Accounts bestehen, haben oft einen zentralisierten Networking Account, wie in zahlreichen Whitepapern empfohlen.
Diese zentralen Networking Accounts haben gewöhnlich folgende Aufgaben:
Die durch den Networking Account bereitgestellten Verbindungstypen erfordern häufig zusätzliche Sicherheitsmaßnahmen. Etwa durch einen Filter für den Ingress und Egress Traffic, um nur den notwendigen Datenverkehr zuzulassen.
Um die AWS Network Firewall nutzen zu können, muss der gesamte Datenverkehr symmetrisch zum Endpunkt der AWS Network Firewall geleitet werden. Der Firewall-Endpunkt ist wie ein Schnittstellen-Endpunkt der AWS PrivateLink VPC (Virtual Private Cloud). Der Unterschied ist jedoch, dass Unternehmen ihn als Ziel für eine Routing-Tabelle verwenden können. Dazu müssen sie die AWS Network Firewall in einem separaten Subnet der VPC ihres Networking Accounts bereitstellen. Diese Firewall Subnets sollten keine weiteren Services enthalten. Andernfalls können die Anwender den Traffic in diesen Subnets nicht kontrollieren.
Dies zeigen auch einige Best Practices zu Bereitstellungsmodellen für die AWS Network Firewall.
Unser Anwendungsfall besteht aus mehreren AWS-Accounts ohne direkte Internet- und Intranet-Konnektivität. Heißt: Die in diesen Accounts bereitgestellten Workloads benötigen einen zentralen Networking Account. Der Networking Account und die Account Workloads sind mit dem AWS Transit Gateway verbunden, das für die Konnektivität zwischen den Ressourcen sorgt.
Damit der Datenverkehr stetig fließt, haben wir die Workload Accounts in Gruppen eingeteilt, von denen jede mit ihren eigenen Transit-Gateway-Routing-Tabellen verbunden ist.
Jeder Workload Account, der einen ausgehenden Internet- oder Intranet-Zugang benötigt, wird an die zentralisierten Networking Accounts der Virtual Private Cloud geleitet.
Die Architektur für diesen Networking Account besteht aus vier Subnets:
Das Netzwerk nutzt das Konzept eines öffentlichen Intranets und privaten Subnets. AWS Internet Gateway wird im öffentlichen Subnet bereitgestellt. An diesem Punkt befinden sich die AWS NAT Gateway Services.
So bietet das öffentliche Subnet einen direkten Internetzugang. Alle verbundenen Workload Accounts nutzen es. Die AWS NAT Gateways werden hier platziert, um die Verbindung zum Internet herzustellen.
Basierend auf der Bereitstellung von AWS-Fargate im privaten Subnet des Netzwerk-Accounts verwendet auch der zentrale Eingangs-Proxy das öffentliche Subnet, um seinen AWS Application Load Balancer vom Internet aus zugänglich zu machen.
Mehr Informationen zu AWS Fargate und seiner Nutzung finden Sie hier.
Im privaten Subnet wird das AWS Fargate bereitgestellt. Es bietet ein auf NGINX basierendes zentrales Proxy-System, das den eingehenden Datenverkehr aus dem Intranet und dem Internet zu den Backend-Anwendungen in den Workload Accounts ermöglicht. Dabei kommt es jedoch nie zu einem Kontakt mit einem extern über AWS Direct Connect oder das VPN verbundenen Partner. Das zentrale Proxy-System hat keine direkte Verbindung zum Internet.
Das Intranet Subnet ist eine Kopie des öffentlichen Subnets. Es enthält einen AWS NAT Gateway sowie den Application Load Balancer und fungiert als zweiter Eingangspunkt für den Netzwerk-Account.
Das Intranet für unseren Anwendungsfall endet in diesem Subnet. Folglich ist eine Überlappung mit den Intranet-CIDR-Bereichen ausgeschlossen. So können wir NAT in unserer internen AWS-Struktur vollständig vermeiden.
Dieses Subnet ist für den Datenverkehr vom und zum Intranet der Lösung ausgelegt. Der Application Load Balancer verweist außerdem auf die AWS- Fargate-Bereitstellung in dem privaten Unternetz.
Die AWS Network Firewall ist der einzige im Firewall Subnet bereitgestellte Service.
In diesem Szenario erfolgt der Datenfluss für den Egress Traffic direkt. Der von den Workload-Accounts eingehende Datenverkehr hingegen über den AWS Transit-Gateway, der ihn an das Firewall Subnet sendet. Die AWS Network Firewall wendet die konfigurierten Regeln an, entscheidet und nutzt Filter, um Traffic zu blockieren oder akzeptieren.
Wird er akzeptiert, leitet die AWS Network Firewall ihn an die AWS NAT Gateway Services in den öffentlichen Subnets weiter und ermöglicht so den ausgehenden Daten den Zugang zum Internet.
Damit die AWS Network Firewall nach spezifischen Akzeptanzkriterien prüft, ob sie Datenpakete durchlässt oder nicht, können Sie verschiedene Regeln konfigurieren und für die Durchlasskontrolle gruppieren.
Dabei können Sie innerhalb der Firewall zwischen zustandslosen und zustandsbehafteten Regeln unterscheiden.
Zustandslose Regeln dienen dazu, bestimmte Protokolle oder CIDR-Bereiche zuzulassen oder zu blockieren. Die AWS Network Firewall unterstützt die standardmäßige zustandslose 5-Tupel-Regelspezifikation für die Inspektion von Netzwerk-Traffic: Protokoll, Quelle, Quellport, Ziel, Zielport.
Zustandsbehaftete Regeln bieten dagegen deutlich mehr Konfigurationsoptionen: Sie nutzen für das virtuelle Netzwerk die mit Suricata kompatiblen Spezifikationen für ein IPS (Intrusion Prevention System). Suricata ist ein Open-Source-Netzwerk-IPS, das standardmäßige regelbasierte Sprache zur Untersuchung von zustandsbehaftetem Netzwerk-Traffic umfasst. Die AWS Network Firewall unterstützt aktuell Suricata Version 6.0.2.
Wir haben Suricata-Regelsätze verwendet, um eine Whitelist zulässiger Domänen festzulegen und so den zulässigen Traffic von den Workload-Accounts zu definieren.
So können Sie den Beispiel-Regelsatz für die Zulassung von whitelistedpage.com konfigurieren:
pass tls $HOME_NET any -> any any (tls.sni; dotprefix; content:".whitelistedpage.com"; nocase; endswith; msg:"matching TLS allowlisted FQDNs"; priority:1; flow:to_server, established; sid:1; rev:1;)
pass http $HOME_NET any -> any any (http.host; dotprefix; content:".whitelistedpage.com"; endswith; msg:"matching TLS allowlisted FQDNs"; priority:1; sid:2; rev:2;)
drop http $HOME_NET any -> any any (msg:"not matching any HTTP allowlisted FQDNs"; priority:1; sid:3; rev:1;)
drop tls $HOME_NET any -> any any (msg:"not matching any TLS allowlisted FQDNs"; priority:1; flow:to_server, established; sid:4; rev:1;)
Diese Regel lässt HTTP- und HTTPS-Traffic zu whitelistedpage.com sowie den Unterdomänen zu. Jeder andere Traffic für HTTP und HTTPS wird mit entsprechenden Log-Mitteilungen blockiert.
Darüber hinaus lässt Suricata auch andere Protokolle als HTTP und HTTPS zu. Mehr Informationen in der Online-Dokumentation von Suricata gibt es hier.
Wichtig zu wissen: Es gibt eine Variable namens $HOME_NET, die standardmäßig auf den CIDR-Bereich Ihrer Virtual Private Cloud verweist. Wollen Sie auch von anderen Virtual Private Clouds Traffic über die Netzwerk-Firewall leiten, müssen Sie für Ihr privates Netzwerk diese Variable für den CIDR-Bereich anpassen.
Über die AWS-Konsole ist dies aktuell noch nicht möglich, doch hält der Hosting-Anbieter mit AWS CLI dafür eine Alternative bereit. Weitere Details zu der virtuellen Lösung finden Sie hier.
Die Konfiguration lässt sich leicht auf andere Domänen erweitern, die Sie abhängig von den Anforderungen der Backend-Anwendungen in den Workload-Accounts als zulässig festlegen wollen.
Die Suricata-Regelsätze ermöglichen zudem weit mehr Konfigurationen, als in der Suricata-Dokumentation aufgeführt sind.
Ein zentraler Baustein, der den Durchlass von Datenverkehr blockieren kann, ist die Voraussetzung für jegliche Form der Protokollierung.
So können Sie die AWS Network Firewall für Log-Alarme und Flow-Protokolle konfigurieren. Mögliche Protokollziele sind:
Protokollgruppen aus Amazon CloudWatch
Amazon Kinesis Data Firehose
Für unseren Anwendungsfall haben wir CloudWatch Logs so konfiguriert, dass die Log-Mitteilungen an eine verbundene SIEM-Lösung weitergeleitet werden.
Sie können folgende Arten von Protokollen nutzen:
Wir haben die AWS Network Firewall nach der Netzwerkeinrichtung implementiert. Dabei haben wir für die Firewall den „transparenten Modus“ zwischen dem Workload Traffic und dem Internet gewählt. Transparenter Modus bedeutet, dass wir die Firewall ohne Regeln zum Blockieren von Traffic implementiert haben.
Stattdessen ließen wir eine einzige Regel (siehe unten) auf unsere AWS-CloudWatch-Protokollgruppe verweisen, um sämtlichen ausgehenden HTTP- und HTTPS-Traffic an CloudWatch zu protokollieren.
{
"Schema": {"Name": "CloudWatchLogRule",
"Version": 1
},
"AggregateOn": "Count",
"Contribution": {"Filters": [],
"Keys": [
"$.event.tls.sni"
]
},
"LogFormat": "JSON",
"LogGroupNames": [
"/aws/network-firewall/alert"
]
}
Um einen ersten Entwurf der zulässigen Domänen zu erhalten, haben wir die Protokolle über einen bestimmten Zeitraum gesammelt und mit AWS Contributor Insights die Protokollereignisse visualisiert.
So konnten wir vor dem Start der Lösung überprüfen, ob wir wichtige Domänen ausgelassen hatten und gegebenenfalls ergänzen mussten.
Gemeinsam mit den Verantwortlichen der Workloads, die die Aufrufe an die AWS Network Firewall gesendet hatten, konnten wir so fast alle Probleme ausräumen, die häufig auftreten, wenn man den öffentlichen Internetzugang deaktiviert, indem man einen Regelsatz hinzufügt, der nur durch eine Whitelist zugelassene Domänen erlaubt.
Die AWS Network Firewall ist eine einfach einzurichtende Lösung, die den Egress Traffic ins Internet kontrolliert.
Die Protokolle und Metriken unterstützen außerdem eine nahtlose Migration, ohne dass Benutzer mit Zugangsproblemen zu kämpfen haben, die sie vor der Einrichtung der Firewall nicht hatten.
