Benutzerdefinierte Netzwerk-ACLs für Ihre VPC
Sie können eine benutzerdefinierte Netzwerk-ACL erstellen und einem Subnetz zuordnen. So können Sie bestimmten eingehenden oder ausgehenden Datenverkehr auf der Subnetzebene verweigern. Weitere Informationen finden Sie unter Erstellen einer Netzwerk-ACL für Ihre VPC.
Jede Netzwerk-ACL enthält eine Standardregel für eingehenden Datenverkehr und eine Standardregel für ausgehenden Datenverkehr, deren Regelnummer ein Sternchen (*) ist. Über diese Regel wird sichergestellt, dass Pakete, die mit keiner anderen Regel übereinstimmen, abgelehnt werden.
Sie können eine Netzwerk-ACL ändern, indem Sie Regeln ergänzen oder entfernen. Sie können keine Regeln löschen, deren Nummer ein Sternchen enthält.
Für jede hinzugefügte Regel muss eine entsprechende Regel für ausgehenden oder eingehenden Datenverkehr existieren, die Antworten ermöglicht. Weitere Informationen zur Auswahl des passenden Bereichs für flüchtige Ports finden Sie unter Flüchtige Ports.
Beispiel: Regeln für eingehenden Datenverkehr
Die folgende Tabelle zeigt die Beispielregeln für eingehenden Datenverkehr für eine Netzwerk-ACL. Die Regeln für IPv6 werden nur ergänzt, wenn der VPC ein IPv6-CIDR-Block zugeordnet ist. IPv4- und IPv6-Datenverkehr werden separat bewertet. Daher sind die Regeln für IPv4-Datenverkehr für den IPv6-Datenverkehr nicht anwendbar. Sie können IPv6-Regeln neben den entsprechenden IPv4-Regeln oder die IPv6-Regeln nach der letzten IPv4-Regel ergänzen.
Wenn ein Paket im Subnetz eingeht, werden die Regeln für eingehenden Datenverkehr der Netzwerk-ACL, die mit dem Subnetz verknüpft ist, nacheinander ausgewertet, beginnend mit der Regel mit der niedrigsten Nummer. Nehmen wir beispielsweise an, dass IPv4-Datenverkehr mit dem HTTPS-Port (443) als Ziel vorhanden ist. Das Paket stimmt nicht mit Regel 100 oder 105 überein. Es entspricht Regel 110, die den Datenverkehr in das Subnetz zulässt. Wenn das Paket für Port 139 (NetBIOS) bestimmt gewesen wäre, stimmte es mit keiner der nummerierten Regeln überein und die Regel * für IPv4-Datenverkehr lehnt das Paket letztlich ab.
| Regel Nr. | Typ | Protocol (Protokoll) | Port-Bereich | Source | Erlauben/Verweigern | Kommentare |
|---|---|---|---|---|---|---|
100 |
HTTP |
TCP |
80 |
0.0.0.0/0 |
ERLAUBEN |
Lässt eingehenden HTTP-Datenverkehr von jeder IPv4-Adresse zu. |
105 |
HTTP |
TCP |
80 |
::/0 |
ERLAUBEN |
Lässt eingehenden HTTP-Datenverkehr von jeder IPv6-Adresse zu. |
110 |
HTTPS |
TCP |
443 |
0.0.0.0/0 |
ERLAUBEN |
Lässt eingehenden HTTPS-Datenverkehr von jeder IPv4-Adresse zu. |
115 |
HTTPS |
TCP |
443 |
::/0 |
ERLAUBEN |
Lässt eingehenden HTTPS-Datenverkehr von jeder IPv6-Adresse zu. |
120 |
SSH |
TCP |
22 |
|
ERLAUBEN |
Lässt eingehenden SSH-Datenverkehr vom öffentlichen IPv4-Adressbereich Ihres Heimnetzwerks (über das Internet-Gateway) zu. |
140 |
Custom TCP |
TCP |
|
0.0.0.0/0 |
ERLAUBEN |
Lässt eingehenden zurückfließenden IPv4-Datenverkehr vom Internet (für Anfragen aus dem Subnetz) zu. |
145 |
Custom TCP |
TCP |
|
::/0 |
ERLAUBEN |
Lässt eingehenden zurückfließenden IPv6-Datenverkehr vom Internet (für Anfragen aus dem Subnetz) zu. |
* |
Gesamter Datenverkehr |
Alle |
Alle |
0.0.0.0/0 |
DENY |
Verweigert den gesamten eingehenden IPv4-Datenverkehr, der nicht von einer vorangehenden Regel gehandhabt wird. (Kann nicht verändert werden.) |
* |
Gesamter Datenverkehr |
Alle |
Alle |
::/0 |
VERWEIGERN |
Verweigert den gesamten eingehenden IPv6-Datenverkehr, der nicht von einer vorangehenden Regel gehandhabt wird. (Kann nicht verändert werden.) |
Regeln für ausgehenden Datenverkehr
Die folgende Tabelle zeigt die Beispielregeln für ausgehenden Datenverkehr für eine benutzerdefinierte Netzwerk-ACL. Die Regeln für IPv6 werden nur ergänzt, wenn der VPC ein IPv6-CIDR-Block zugeordnet ist. IPv4- und IPv6-Datenverkehr werden separat bewertet. Daher sind die Regeln für IPv4-Datenverkehr für den IPv6-Datenverkehr nicht anwendbar. Sie können IPv6-Regeln neben den entsprechenden IPv4-Regeln oder die IPv6-Regeln nach der letzten IPv4-Regel ergänzen.
| Regel Nr. | Typ | Protocol (Protokoll) | Port-Bereich | Zielbereich | Erlauben/Verweigern | Kommentare |
|---|---|---|---|---|---|---|
100 |
HTTP |
TCP |
80 |
0.0.0.0/0 |
ERLAUBEN |
Lässt ausgehenden HTTP-Datenverkehr über IPv4 vom Subnetz zum Internet zu. |
105 |
HTTP |
TCP |
80 |
::/0 |
ERLAUBEN |
Lässt ausgehenden HTTP-Datenverkehr über IPv6 vom Subnetz zum Internet zu. |
110 |
HTTPS |
TCP |
443 |
0.0.0.0/0 |
ERLAUBEN |
Lässt ausgehenden HTTPS-Datenverkehr über IPv4 vom Subnetz zum Internet zu. |
115 |
HTTPS |
TCP |
443 |
::/0 |
ERLAUBEN |
Lässt ausgehenden HTTPS-Datenverkehr über IPv6 vom Subnetz zum Internet zu. |
120 |
Custom TCP |
TCP |
|
|
ERLAUBEN |
Lässt ausgehende Antworten für den SSH-Datenverkehr von Ihrem Heimnetzwerk zu. |
140 |
Custom TCP |
TCP |
|
0.0.0.0/0 |
ERLAUBEN |
Lässt ausgehende IPv4-Antworten an Clients im Internet zu (beispielsweise zur Bereitstellung von Webseiten). |
145 |
Custom TCP |
TCP |
|
::/0 |
ERLAUBEN |
Lässt ausgehende IPv6-Antworten an Clients im Internet zu (beispielsweise zur Bereitstellung von Webseiten). |
* |
Gesamter Datenverkehr |
Alle |
Alle |
0.0.0.0/0 |
DENY |
Verweigert den gesamten ausgehenden IPv4-Datenverkehr, der nicht von einer vorangehenden Regel gehandhabt wird. |
* |
Gesamter Datenverkehr |
Alle |
Alle |
::/0 |
DENY |
Verweigert den gesamten ausgehenden IPv6-Datenverkehr, der nicht von einer vorangehenden Regel gehandhabt wird. |
Flüchtige Ports
Die Beispiel-Netzwerk-ACL im vorhergehenden Abschnitt verwendet den flüchtigen Portbereich 32768 bis 65535. Abhängig vom Client-Typ, den Sie verwenden oder mit dem Sie kommunizieren, kann es jedoch sinnvoll sein, einen anderen Bereich für Ihre Netzwerk-ACL zu verwenden.
Der flüchtige Portbereich wird vom Client festgelegt, von dem die Anfrage ausgeht. Der Bereich ist abhängig vom Betriebssystem des Clients.
-
Viele Linux-Kernel (einschließlich des Amazon Linux-Kernels) verwenden Ports 32768-61000.
-
Anforderungen, die von Elastic Load Balancing stammen, verwenden Ports 1024-65535.
-
Windows-Betriebssysteme bis Windows Server 2003 verwenden die Ports 1025 bis 5000.
-
Ab Windows Server 2008 werden die Ports 49152 bis 65535 verwendet.
-
NAT-Gateways verwenden die Ports 1024 bis 65535.
-
AWS Lambda-Funktionen verwenden die Ports 1024-65535.
Wenn eine Anfrage beispielsweise von einem Windows 10-Client im Internet auf einem Webserver in Ihrer VPC eingeht, muss Ihre Netzwerk-ACL über eine Regel für ausgehenden Datenverkehr verfügen, die Datenverkehr für die Ports 49152-65535 erlaubt.
Wenn die Anfrage von einer Instance in Ihrer VPC ausgeht, muss Ihre Netzwerk-ACL über eine Regel für eingehenden Datenverkehr verfügen, um Datenverkehr zu den spezifischen Ports des Betriebssystems zuzulassen.
In der Praxis empfiehlt es sich, die flüchtigen Ports 1024 bis 65535 zu öffnen, um die unterschiedlichen Client-Typen abzudecken, von denen Datenverkehr an öffentliche Instances in Ihrer VPC gelangen kann. Sie können der ACL jedoch auch Regeln hinzufügen, um Datenverkehr für böswillige Ports innerhalb dieses Bereichs zu verweigern. Platzieren Sie die deny (verweigern)-Regeln in der Tabelle vor den allow (erlauben)-Regeln, die den gesamten flüchtigen Portbereich freigeben.
Benutzerdefinierte Netzwerk-ACLs und andere AWS-Services
Wenn Sie eine benutzerdefinierte Netzwerk-ACL erstellen, müssen Sie berücksichtigen, wie sie sich auf die Ressourcen auswirkt, die Sie mit anderen AWS-Services erstellen.
Wenn Sie für Ihre Backend-Instances eine Netzwerk-ACL konfiguriert haben, die eine deny (verweigern)-Regel für den gesamten Datenverkehr mit der Quelle 0.0.0.0/0 oder den CIDR-Bereich des Subnetzes enthält, kann der Load Balancer mit Elastic Load Balancing keine Zustandsprüfung für die Instances durchführen. Weitere Informationen zu den empfohlenen Netzwerk-ACL-Regeln für Load Balancer und Backend-Instances finden Sie unter:
Beheben von Problemen mit der Erreichbarkeit
Reachability Analyzer ist ein Tool zur statischen Konfigurationsanalyse. Mit Reachability Analyzer können Sie die Netzwerkerreichbarkeit zwischen zwei Ressourcen in Ihrer VPC analysieren und debuggen. Reachability Analyzer erstellt Hop-by-Hop-Details des virtuellen Pfads zwischen diesen Ressourcen, wenn sie erreichbar sind, und identifiziert andernfalls die blockierende Komponente. Zum Beispiel kann er fehlende oder falsch konfigurierte Netzwerk-ACL-Regeln identifizieren.
Weitere Informationen finden Sie im Leitfaden Reachability Analyzer.
