In diesem Blogartikel zeige ich eine Lösung auf, wie ausgehender Datenverkehr in AWS zu geringen Kosten gefiltert werden kann. Es gibt eine Vielzahl von Methoden, den Outbound Traffic bei AWS-Workloads zu filtern. Ich werde einige davon vorstellen und miteinander vergleichen. Am Ende erkläre ich die kosteneffiziente Lösung und stelle sie auch als Infrastructure-as-Code-Template bereit.
Was bedeutet Outbound Traffic Filtering?
Outbound Traffic Filtering bezieht sich auf den Prozess, durch den der ausgehende Traffic von einem Netzwerk überwacht und reguliert wird. Insbesondere in Cloud-Umgebungen wie AWS ist dies eine wichtige Sicherheitsmaßnahme, um zu kontrollieren, welche Daten das Netzwerk verlassen dürfen und welche nicht.
Im Detail kann Outbound Traffic Filtering folgendes umfassen:
- Blockierung von Datenverkehr: Unautorisierte oder unerwünschte Datenpakete werden daran gehindert, das Netzwerk zu verlassen. Dies könnte zum Beispiel der Verkehr zu bekannten bösartigen Domains oder IPs sein.
- Regulierung des Datenflusses: Beschränkungen für die Bandbreite oder die Art des Verkehrs (wie z.B. bestimmte Protokolle oder Ports), um die Nutzung der Netzwerkressourcen optimal zu gestalten.
- Überwachung und Protokollierung: Aufzeichnung des ausgehenden Datenverkehrs, um ungewöhnliche Aktivitäten zu erkennen und auf Sicherheitsvorfälle reagieren zu können.
Welche Netzwerkarchitektur ist häufig zu sehen?
In vielen AWS-Umgebungen, besonders in kleineren, ist es häufig zu beobachten, dass jede VPC über ein eigenes NAT-Gateway verfügt. Mithilfe dieser Gateways ist es für EC2-Instanzen, die sich in privaten Subnetzen befinden, möglich, auf das Internet zuzugreifen. Die Security Groups und Network Access Control Lists (NACLs) sind meist nur für den eingehenden Verkehr konfiguriert, während der ausgehende Verkehr oft uneingeschränkt bleibt.
Aber warum ist das so? Meiner Meinung nach liegt es daran, dass mit den Security Groups und NACLs lediglich IP-Adressen und Ports, nicht jedoch Domänen, beschränkt werden können. Das AWS NAT-Gateway bietet ebenfalls keine Möglichkeit zum Domain-Filtering.
Folglich ist es mit dieser Standard-Netzwerkarchitektur in kleineren Umgebungen nicht umsetzbar, dass die EC2-Instanzen in den privaten Subnetzen nur auf freigegebene Domänen wie beispielsweise amazonaws.com und susecloud.net zugreifen können, während aller anderer Outbound-Traffic blockiert wird.
Natürlich könnte jemand auf die Idee kommen, einfach die IP-Adressen von amazonaws.com und susecloud.net in einer NACL zu erlauben und alle anderen zu blockieren. Jedoch ist dies keine wartbare Lösung, da sich die IP-Adressen der Domänen jederzeit ändern können.
Wie lässt sich Outbound Filtering für Domains realisieren?
Ich würde gerne auf folgende drei Möglichkeiten eingehen:
- Route 53 Resolver DNS Firewall
- AWS Network Firewall
- Squid Proxy on EC2
Route 53 Resolver DNS Firewall
Sofern für die DNS-Auflösung Route 53 genutzt wird – was definitiv zu empfehlen ist – besteht die Möglichkeit, die Route 53 Resolver DNS Firewall zu nutzen. Dies ist eine von AWS verwaltete Firewall, welche die DNS-Auflösung einschränken kann. Beispielsweise könnte die DNS-Auflösung nur für amazonaws.com und susecloud.net zugelassen werden, während alle anderen Domains nicht aufgelöst werden. Das bedeutet, dass die EC2-Instanz keine IP-Adresse von Route 53 als Antwort erhält, wenn versucht wird, beispielsweise microsoft.com aufzurufen. Dies würde den Outbound-Traffic einschränken: EC2-Instanzen wäre es nicht mehr möglich, beliebig im Internet zu surfen oder andere Domains aufzurufen, die nicht auf der Allow-Liste stehen. Diese Lösung ist auch sehr kostengünstig mit 0,0005 USD pro Monat pro Domain und 0,60 USD pro Million verarbeiteter Anfragen. Bei kleineren Umgebungen belaufen sich die Kosten auf unter 1 USD pro Monat.
Es gibt jedoch einen Haken: Die EC2-Instanzen haben nach wie vor die Möglichkeit, sämtlichen Outbound-Traffic direkt über die IP-Adressen abzuwickeln und sich eigene Host-Einträge in /etc/hosts anzulegen oder schlichtweg einen anderen DNS-Server einzutragen und somit nicht mehr Route 53 zu nutzen.
AWS Network Firewall
Die AWS Network Firewall wird als Zwischenschicht durch ein dediziertes Subnet zwischen das NAT-Gateway und das Internet-Gateway eingefügt. Sie bietet eine Vielzahl fortschrittlicher Funktionen, darunter Stateful- und Stateless-Regelverarbeitung, Intrusion Detection System (IDS) und Intrusion Prevention System (IPS), Filterung des ein- und ausgehenden Verkehrs, Deep Packet Inspection und Kompatibilität mit Suricata, einem Open-Source-IDS/IPS. Ebenso ermöglicht sie ein effektives Domain Filtering. Die Firewall zeichnet sich durch ihre Hochverfügbarkeit aus und kann direkt über die AWS Management Console verwaltet werden.
Ein Nachteil ist allerdings, dass sie nicht in die Kategorie „Low Budget“ fällt, da die Kosten pro Availability Zone (AZ) bei etwa 288 USD liegen, zuzüglich der Gebühren für den Traffic (65 USD pro TB). Bei einem VPC, das drei Availability Zones umfasst, können sich die monatlichen Kosten inklusive Traffic schnell auf 1.000 USD summieren. Trotz der vielen Features der AWS Network Firewall können diese Kosten für viele kleinere AWS-Umgebungen zu hoch sein.
Squid Proxy on EC2
Kommen wir nun zu der eingangs erwähnten kosteneffizienten Lösung. Eine Option besteht darin, die NAT-Gateways durch EC2-Instanzen zu ersetzen, auf denen die Open-Source-Software Squid Proxy läuft. Dieser Proxy ermöglicht es, dass EC2-Instanzen, die sich in einem privaten Subnetz befinden, nur über HTTP und HTTPS sowie zu freigegebene Domains kommunizieren können. Zudem lässt sich pro Availability Zone (AZ) ein Squid-Proxy einrichten, wodurch im Falle eines Ausfalls der Datenverkehr über den Squid Proxy einer anderen AZ umgeleitet wird. Auch ein automatisiertes Patching des Amazon Linux 2 und des Squid Proxys ist vorhanden.
Obwohl diese Lösung vielleicht weniger Features bietet und nicht so ausfallsicher oder leistungsfähig wie eine AWS Network Firewall ist, kann sie dennoch interessant sein. Durch das Ersetzen der NAT-Gateways, die pro AZ etwa 37 USD plus 53 USD pro 1 TB Traffic kosten, mit einer Lösung, die nur rund 25 USD pro AZ beträgt, können die Gesamtkosten wesentlich reduziert werden, verglichen mit dem ungefilterten Durchleiten des Traffics über das AWS NAT-Gateway.
Die Squid-Proxy-Lösung kann auch zentral in einem dedizierten AWS Network-Account implementiert werden, um als zentraler Internet-Ausgangspunkt für mehrere VPCs zu dienen. Dafür ist eine Anbindung der einzelnen VPCs über ein Transit Gateway erforderlich.
In diesem GitHub-Repository
erläutere ich, wie Sie die Lösung schnell und einfach mit einem CloudFormation-Template bereitstellen können.
Conclusion
Die Auswahl der passendsten Lösung für Ihre AWS-Umgebung hängt von einer Reihe von Faktoren ab und sollte sorgfältig bedacht werden. Ich freue mich auf Ihr Feedback und bin gespannt darauf, ob meine Squid-Proxy-Lösung auch in Ihrer AWS Umgebung zum Einsatz kommt.
Wir freuen uns auf einen persönlichen Austausch zu diesem Thema. Folgen Sie unserem Autor Patrick Zink auf LinkedIn und schreiben Sie ihm gerne zu diesem Thema.