Datenverkehr in Subnetzen mit Netzwerk-ACLs steuern - Amazon Virtual Private Cloud

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Datenverkehr in Subnetzen mit Netzwerk-ACLs steuern

Eine Netzwerk-Zugriffssteuerungsliste (ACL) erlaubt oder verweigert bestimmten eingehenden oder ausgehenden Datenverkehr auf der Subnetzebene. Sie können die Standard-Netzwerk-ACL für Ihre VPC verwenden, oder Sie können eine benutzerdefinierte Netzwerk-ACL für Ihre VPC mit Regeln erstellen, die den Regeln für Ihre Sicherheitsgruppen ähneln, um Ihrer VPC eine zusätzliche Sicherheitsebene hinzuzufügen.

Für die Nutzung von Netzwerk-ACLs fallen keine zusätzlichen Gebühren an.

Das folgende Diagramm zeigt eine VPC mit zwei Subnetzen. Jedes Subnetz hat eine Netzwerk-ACL. Wenn Datenverkehr in die VPC gelangt (z. B. von einer durch Peering verbundenen VPC, einer VPN-Verbindung oder dem Internet), sendet der Router den Datenverkehr an das Ziel. Netzwerk-ACL A bestimmt, welcher Datenverkehr, der für Subnetz 1 bestimmt ist, in Subnetz 1 gelangen darf und welcher Datenverkehr, der für einen Standort außerhalb von Subnetz 1 bestimmt ist, Subnetz 1 verlassen darf. In ähnlicher Weise bestimmt Netzwerk-ACL B, welcher Datenverkehr in Subnetz 2 ein- und ausgehen darf.

Eine VPC mit zwei Subnetzen und einer Netzwerk-ACL für jedes Subnetz.

Weitere Informationen zu den Unterschieden zwischen Sicherheitsgruppen und Netzwerk-ACLs finden Sie unter Vergleichen von Sicherheitsgruppen und Netzwerk-ACLs.

Grundlagen von Netzwerk-ACLs

Nachfolgend werden die Grundlagen von Netzwerk-ACLs beschrieben:

  • Ihre VPC verfügt automatisch über eine Standardnetzwerk-ACL, die Sie bearbeiten können. Standardmäßig wird der gesamte eingehende und ausgehende IPv4-Datenverkehr und gegebenenfalls IPv6-Datenverkehr erlaubt.

  • 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.

  • Jedes Subnetz in Ihrer VPC muss mit einer Netzwerk-ACL verknüpft werden. Sofern Sie einem Subnetz nicht explizit eine Netzwerk-ACL zuordnen, gilt für das Subnetz automatisch die Standardnetzwerk-ACL.

  • Sie können eine Netzwerk-ACL mehreren Subnetzen zuordnen. Ein Subnetz kann jedoch jeweils nur einer Netzwerk-ACL zugeordnet werden. Wenn Sie einem Subnetz eine Netzwerk-ACL zuordnen, wird die bisherige Zuordnung gelöscht.

  • Eine Netzwerk-ACL hat Regeln für eingehenden und ausgehenden Datenverkehr. Jede Regel kann Datenverkehr entweder erlauben oder verweigern. Jede Regel hat eine Nummer von 1 bis 32.766. Die Regeln werden der Reihe nach ausgewertet, beginnend mit der Regel mit der niedrigsten Nummer, um zu entscheiden, ob der Verkehr zugelassen oder abgelehnt wird. Wenn der Datenverkehr mit einer Regel übereinstimmt, wird die Regel angewendet und wir werten keine zusätzlichen Regeln aus. Wir empfehlen, zunächst Regeln in Abschnitten zu erstellen (z. B. Abschnitte von 10 oder 100). So können Sie später neue Regeln einfach in Ihre Rangordnung einfügen.

  • Wir werten die Netzwerk-ACL-Regeln aus, wenn Datenverkehr in das Subnetz ein- und ausläuft, nicht wenn er innerhalb eines Subnetzes geroutet wird.

  • NACLs sind zustandslos, das heißt, Informationen über zuvor gesendeten oder empfangenen Datenverkehr werden nicht gespeichert. Wenn Sie beispielsweise eine NACL-Regel erstellen, um bestimmten eingehenden Datenverkehr zu einem Subnetz zuzulassen, werden Antworten auf diesen Datenverkehr nicht automatisch zugelassen. Dies steht im Gegensatz zur Funktionsweise von Sicherheitsgruppen. Sicherheitsgruppen sind zustandsbehaftet, das heißt, dass Informationen über zuvor gesendeten oder empfangenen Datenverkehr gespeichert werden. Wenn beispielsweise eine Sicherheitsgruppe eingehenden Datenverkehr zu einer EC2-Instance zulässt, werden Antworten unabhängig von den Regeln der ausgehenden Sicherheitsgruppe automatisch zugelassen.

  • Netzwerk-ACLs können DNS-Anfragen an oder vom Route 53 Resolver (auch bekannt als VPC+2-IP-Adresse oder DNS) nicht blockieren. AmazonProvided Um DNS-Anfragen durch den Route 53 Resolver zu filtern, können Sie die Route 53 Resolver DNS Firewall im Entwicklerhandbuch für Amazon Route 53 aktivieren.

  • Netzwerk-ACLs können den Datenverkehr zum Instance Metadata Service (IMDS) nicht blockieren. Informationen zur Verwaltung des Zugriffs auf IMDS finden Sie unter Konfiguration der Instance-Metadatenoptionen im Benutzerhandbuch für Amazon EC2.

  • Netzwerk-ACLs filtern keinen Datenverkehr, der für die folgenden Ziele bestimmt ist oder von diesen ausgeht:

    • Amazon Domain Name Services (DNS)

    • Amazon Dynamic Host Configuration Protocol (DHCP)

    • Amazon EC2-Instance-Metadaten

    • Amazon-ECS-Endpunkte für Aufgabenmetadaten

    • Lizenzaktivierung für Windows-Instances

    • Amazon Time Sync Service

    • Reservierte IP-Adressen, die vom Standard-VPC-Router verwendet werden

  • Es gibt Kontingente (bekannt als Grenzwerte) für die Anzahl der Netzwerk-ACLs pro VPC und die Anzahl der Regeln pro Netzwerk-ACL. Weitere Informationen finden Sie unter Amazon VPC-Kontingente.

Regeln für Netzwerk-ACLs

Sie können der Standardnetzwerk-ACL Regeln hinzufügen oder Regeln entfernen oder zusätzliche Netzwerk-ACLs für Ihre VPC erstellen. Wenn Sie Regeln zu einer Netzwerk-ACL hinzufügen oder daraus entfernen, werden die Änderungen automatisch auf die mit der Netzwerk-ACL verknüpften Subnetze angewendet.

Eine Netzwerk-ACL-Regel besteht aus folgenden Bestandteilen:

  • Rule number (Regelnummer. Regeln werden nacheinander beginnend mit der niedrigsten Nummer ausgewertet. Sobald der Datenverkehr mit einer Regel übereinstimmt, wird die Regel angewendet. Dabei werden Regeln mit höherer Nummer, die dieser Regel möglicherweise widersprechen, ignoriert.

  • Typ. Die Art des Datenverkehrs, z. B. SSH. Sie können auch den gesamten Datenverkehr oder einen benutzerdefinierten Bereich angeben.

  • Protocol (Protokoll. Sie können ein beliebiges Protokoll mit einer Standardprotokollnummer auswählen. Weitere Informationen finden Sie unter Protocol Numbers. Wenn Sie als Protokoll ICMP auswählen, können Sie beliebige bzw. alle ICMP-Typen und -Codes angeben.

  • Port-Bereich. Der Listening-Port oder Portbereich für den Datenverkehr. Beispiel: 80 für HTTP-Datenverkehr.

  • Quelle. [Nur eingehende Regeln] Die Quelle des Datenverkehrs (CIDR-Bereich).

  • Ziel. [Nur ausgehende Regeln] Das Ziel für den Datenverkehr (CIDR-Bereich).

  • Erlauben/Verweigern. Gibt an, ob der angegebene Datenverkehr erlaubt oder verweigert werden soll.

Wenn Sie eine Regel mit einem Befehlszeilen-Tool oder der Amazon EC2-API hinzufügen, wird der CIDR-Bereich automatisch in die kanonische Form geändert. Wenn Sie beispielsweise 100.68.0.18/18 für den CIDR-Bereich angeben, erstellen wir eine Regel mit dem CIDR-Bereich 100.68.0.0/18.

Standardnetzwerk-ACL

Die Standardnetzwerk-ACL ist so konfiguriert, dass der gesamte ein- und ausgehende Datenverkehr für die mit ihr verknüpften Subnetze erlaubt wird. Jede Netzwerk-ACL enthält auch eine Regel, deren Regelnummer ein Sternchen (*) ist. Über diese Regel wird sichergestellt, dass Pakete, die mit keiner anderen Regel übereinstimmen, abgelehnt werden. Diese Regel kann weder bearbeitet noch gelöscht werden.

Nachfolgend finden Sie ein Beispiel für eine Standardnetzwerk-ACL für eine VPC, die ausschließlich IPv4 unterstützt.

Eingehend
Regel Nr. Typ Protocol (Protokoll) Port-Bereich Source Erlauben/Verweigern

100

Gesamter IPv4-Datenverkehr

Alle

Alle

0.0.0.0/0

ERLAUBEN

*

Gesamter IPv4-Datenverkehr

Alle

Alle

0.0.0.0/0

DENY

Ausgehend
Regel Nr. Typ Protocol (Protokoll) Port-Bereich Zielbereich Erlauben/Verweigern

100

Gesamter IPv4-Datenverkehr

Alle

Alle

0.0.0.0/0

ERLAUBEN

*

Gesamter IPv4-Datenverkehr

Alle

Alle

0.0.0.0/0

DENY

Wenn Sie eine VPC mit einem IPv6 CIDR-Block erstellen oder Ihrer vorhandenen VPC einen IPv6 CIDR-Block zuordnen, werden automatisch Regeln hinzugefügt, über die der gesamte IPv6-Datenverkehr für das Subnetz erlaubt wird. Außerdem werden Regeln mit einem Sternchen als Nummer hinzugefügt, um sicherzustellen, dass Pakete, die mit keiner anderen nummerierten Regel übereinstimmen, abgelehnt werden. Diese Regeln können weder bearbeitet noch gelöscht werden. Nachfolgend finden Sie ein Beispiel für eine Standardnetzwerk-ACL für eine VPC, die IPv4 und IPv6 unterstützt.

Anmerkung

Wenn Sie die Eingangsregeln Ihrer Standard-Netzwerk-ACL geändert haben, fügen wir nicht automatisch eine ALLOW-Regel für eingehenden IPv6-Verkehr hinzu, wenn Sie einen IPv6-Block mit Ihrer VPC verknüpfen. Ebenso fügen wir nicht automatisch eine ALLOW-Regel für ausgehenden IPv6-Verkehr hinzu, wenn Sie die Regeln für ausgehenden Verkehr geändert haben.

Eingehend
Regel Nr. Typ Protocol (Protokoll) Port-Bereich Source Erlauben/Verweigern

100

Gesamter IPv4-Datenverkehr

Alle

Alle

0.0.0.0/0

ERLAUBEN

101

Gesamter IPv6-Datenverkehr

Alle

Alle

::/0

ERLAUBEN

*

Gesamter Datenverkehr

Alle

Alle

0.0.0.0/0

DENY

*

Gesamter IPv6-Datenverkehr

Alle

Alle

::/0

VERWEIGERN

Ausgehend
Regel Nr. Typ Protocol (Protokoll) Port-Bereich Zielbereich Erlauben/Verweigern

100

Gesamter Datenverkehr

Alle

Alle

0.0.0.0/0

ERLAUBEN

101

Gesamter IPv6-Datenverkehr

Alle

Alle

::/0

ERLAUBEN

*

Gesamter Datenverkehr

Alle

Alle

0.0.0.0/0

DENY

*

Gesamter IPv6-Datenverkehr

Alle

Alle

::/0

VERWEIGERN

Benutzerdefinierte Netzwerk-ACL

Das folgende Beispiel illustriert eine benutzerdefinierte Netzwerk-ACL für eine VPC, die nur IPv4 unterstützt. Es enthält eingehende Regeln, die HTTP- und HTTPS-Verkehr zulassen (100 und 110). Es gibt eine entsprechende Ausgangsregel, die Antworten auf diesen eingehenden Verkehr (140) zulässt, der die ephemeren Ports 32768-65535 abdeckt. Weitere Informationen zur Auswahl des passenden Bereichs für flüchtige Ports finden Sie unter Flüchtige Ports.

Die Netzwerk-ACL enthält außerdem Regeln für eingehenden Datenverkehr, die SSH- und RDP-Datenverkehr für das Subnetz zulassen. Die Regel für ausgehenden Datenverkehr 120 ermöglicht Antworten, das Subnetz zu verlassen.

Die Netzwerk-ACL verfügt über Regeln für ausgehenden Datenverkehr (Regeln 100 und 110), über die ausgehender HTTP- und HTTPS-Datenverkehr für das Subnetz erlaubt wird. Es gibt eine entsprechende Eingangsregel, die Antworten auf diesen eingehenden Verkehr (140) zulässt, der die ephemeren Ports 32768-65535 abdeckt.

Jede Netzwerk-ACL enthält eine Standardregel mit der Nummer "*". Über diese Regel wird sichergestellt, dass Pakete, die mit keiner anderen Regel übereinstimmen, abgelehnt werden. Diese Regel kann weder bearbeitet noch gelöscht werden.

Eingehend
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.

110

HTTPS

TCP

443

0.0.0.0/0

ERLAUBEN

Lässt eingehenden HTTPS-Datenverkehr von jeder IPv4-Adresse zu.

120

SSH

TCP

22

192.0.2.0/24

ERLAUBEN

Lässt eingehenden SSH-Datenverkehr vom öffentlichen IPv4-Adressbereich Ihres Heimnetzwerks (über das Internet-Gateway) zu.

130

RDP

TCP

3389

192.0.2.0/24

ERLAUBEN

Lässt eingehenden RDP-Datenverkehr vom öffentlichen IPv4-Adressbereich Ihres Heimnetzwerks (über das Internet-Gateway) zu den Webservern zu.

140

Custom TCP

TCP

32768-65535

0.0.0.0/0

ERLAUBEN

Lässt eingehenden zurückfließenden IPv4-Datenverkehr vom Internet (also für Anfragen aus dem Subnetz) zu.

Dieser Bereich dient nur der Veranschaulichung.

*

Gesamter Datenverkehr

Alle

Alle

0.0.0.0/0

VERWEIGERN

Verweigert den gesamten eingehenden IPv4-Datenverkehr, der nicht von einer vorangehenden Regel gehandhabt wird. (Kann nicht verändert werden.)

Ausgehend
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.

110

HTTPS

TCP

443

0.0.0.0/0

ERLAUBEN

Lässt ausgehenden HTTPS-Datenverkehr über IPv4 vom Subnetz zum Internet zu.

120 SSH

TCP

1024 - 65535

192.0.2.0/24

ERLAUBEN

Ermöglicht ausgehenden SSH-Rückverkehr in den öffentlichen IPv4-Adressbereich Ihres Heimnetzwerks (über das Internet-Gateway).

140

Custom TCP

TCP

32768-65535

0.0.0.0/0

ERLAUBEN

Lässt ausgehende IPv4-Antworten an Clients im Internet zu (beispielsweise zur Bereitstellung von Webseiten an Personen, die die Webserver im Subnetz besuchen).

Dieser Bereich dient nur der Veranschaulichung.

*

Gesamter Datenverkehr

Alle

Alle

0.0.0.0/0

DENY

Verweigert den gesamten ausgehenden IPv4-Datenverkehr, der nicht von einer vorangehenden Regel gehandhabt wird. (Kann nicht verändert werden.)

Wenn ein Paket im Subnetz eingeht, werden die Regeln für eingehenden Datenverkehr der ACL, mit der das Subnetz verknüpft ist, nacheinander (von oben am Anfang der Liste bis unten) ausgewertet. Die Auswertung für ein Paket für den HTTPS-Port (443) sieht wie folgt aus. Das Paket stimmt nicht mit der ersten ausgewerteten Regel (Regel 100) überein. Es stimmt mit der zweiten Regel (Regel 110) überein, die das Paket in das Subnetz lässt. Wenn das Paket für Port 139 (NetBIOS) bestimmt gewesen wäre, stimmt es mit keiner der Regeln überein und die Regel * lehnt das Paket letztlich ab.

Es kann sinnvoll sein, eine deny (verweigern)-Regel zu erstellen, wenn Sie aus einem bestimmten Grund einen großen Portbereich freigeben müssen, einzelne Ports innerhalb dieses Bereichs jedoch gesperrt werden sollen. Platzieren Sie die deny (verweigern)-Regel in der Tabelle vor der Regel, die den gesamten Portbereich freigibt.

Sie fügen allow (erlauben)-Regeln je nach Anwendungsfall hinzu. Sie können beispielsweise eine Regel hinzufügen, die ausgehenden TCP- und UDP-Zugriff auf Port 53 für die DNS-Auflösung zulässt. Für jede hinzugefügte Regel müssen Sie sicherstellen, dass eine entsprechende Regel für ausgehenen oder eingehenden Datenverkehr existiert, die Antworten ermöglicht.

Im folgenden Beispiel wird eine benutzerdefinierte Netzwerk-ACL für eine VPC gezeigt, die einen zugehörigen IPv6-CIDR-Block hat. Diese Netzwerk-ACL enthält Regeln für den gesamten HTTP- und HTTPS-Datenverkehr über IPv6. In diesem Fall wurden neue Regeln zwischen den bestehenden Regeln für IPv4-Datenverkehr eingefügt. Sie können die Regeln auch als Regeln mit höheren Nummern nach den IPv4-Regeln hinzufügen. IPv4- und IPv6-Datenverkehr wird separat bearbeitet. Daher sind die Regeln für den IPv4-Datenverkehr für IPv6-Datenverkehr nicht anwendbar.

Eingehend
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

192.0.2.0/24

ERLAUBEN

Lässt eingehenden SSH-Datenverkehr vom öffentlichen IPv4-Adressbereich Ihres Heimnetzwerks (über das Internet-Gateway) zu.

130

RDP

TCP

3389

192.0.2.0/24

ERLAUBEN

Lässt eingehenden RDP-Datenverkehr vom öffentlichen IPv4-Adressbereich Ihres Heimnetzwerks (über das Internet-Gateway) zu den Webservern zu.

140

Custom TCP

TCP

32768-65535

0.0.0.0/0

ERLAUBEN

Lässt eingehenden zurückfließenden IPv4-Datenverkehr vom Internet (also für Anfragen aus dem Subnetz) zu.

Dieser Bereich dient nur der Veranschaulichung.

145

Custom TCP TCP 32768-65535 ::/0 ERLAUBEN

Lässt eingehenden zurückfließenden IPv6-Datenverkehr vom Internet (also für Anfragen aus dem Subnetz) zu.

Dieser Bereich dient nur der Veranschaulichung.

*

Gesamter Datenverkehr

Alle

Alle

0.0.0.0/0

VERWEIGERN

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.)

Ausgehend
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.

140

Custom TCP

TCP

32768-65535

0.0.0.0/0

ERLAUBEN

Lässt ausgehende IPv4-Antworten an Clients im Internet zu (beispielsweise zur Bereitstellung von Webseiten an Personen, die die Webserver im Subnetz besuchen).

Dieser Bereich dient nur der Veranschaulichung.

145

Custom TCP

TCP

32768-65535

::/0

ERLAUBEN

Lässt ausgehende IPv6-Antworten an Clients im Internet zu (beispielsweise zur Bereitstellung von Webseiten an Personen, die die Webserver im Subnetz besuchen).

Dieser Bereich dient nur der Veranschaulichung.

*

Gesamter Datenverkehr

Alle

Alle

0.0.0.0/0

DENY

Verweigert den gesamten ausgehenden IPv4-Datenverkehr, der nicht von einer vorangehenden Regel gehandhabt wird. (Kann nicht verändert werden.)

*

Gesamter Datenverkehr

Alle

Alle

::/0

VERWEIGERN

Verweigert den gesamten ausgehenden IPv6-Datenverkehr, der nicht von einer vorangehenden Regel gehandhabt wird. (Kann nicht verändert werden.)

Benutzerdefinierte Netzwerk-ACLs und andere Dienste AWS

Wenn Sie eine benutzerdefinierte Netzwerk-ACL erstellen, sollten Sie sich darüber im Klaren sein, wie sich dies auf Ressourcen auswirken kann, die Sie mit anderen AWS Diensten 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 Netzwerk-ACLs für Load Balancer in einer VPC im Benutzerhandbuch für Classic Load Balancer.

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 Anforderung von einer Instance in Ihrer VPC ausgeht, muss Ihre Netzwerk-ACL über eine Regel für eingehenden Datenverkehr verfügen, um Datenverkehr zu den flüchtigen Ports des Instance-Typs zuzulassen (Amazon Linux, Windows Server 2008 usw.).

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.

Path MTU Discovery

Path MTU Discovery wird verwendet, um den Pfad-MTU-Wert zwischen zwei Geräten zu ermitteln. Die Pfad-MTU ist die maximale Paketgröße, die auf dem Pfad zwischen dem sendenden Host und dem empfangenden Host unterstützt wird.

Wenn ein Host ein Paket sendet, das größer als die MTU des empfangenden Hosts ist bzw. das größer als die MTU eines Geräts auf dem Pfad ist, löscht der empfangende Host bzw. das Gerät bei IPv4 das Paket und gibt dann die folgende ICMP-Meldung zurück: Destination Unreachable: Fragmentation Needed and Don't Fragment was Set (Typ 3, Code 4). Dies weist den übertragenden Host an, die Nutzlast in mehrere kleinere Pakete aufzuteilen und diese dann erneut zu übertragen.

Das IPv6-Protokoll unterstützt keine Fragmentierung im Netzwerk. Wenn ein Host ein Paket sendet, das größer als die MTU des empfangenden Hosts ist bzw. das größer als die MTU eines Geräts auf dem Pfad ist, löscht der empfangende Host bzw. das Gerät das Paket und gibt dann die folgende ICMP-Meldung zurück: ICMPv6 Packet Too Big (PTB) (Typ 2). Dies weist den übertragenden Host an, die Nutzlast in mehrere kleinere Pakete aufzuteilen und diese dann erneut zu übertragen.

Wenn die maximale Übertragungseinheit (MTU) zwischen Hosts in Ihren Subnetzen unterschiedlich ist oder Ihre Instances mit Peers über das Internet kommunizieren, müssen Sie die folgende Netzwerk-ACL-Regel sowohl ein- als auch ausgehend hinzufügen. Dadurch wird sichergestellt, dass Path MTU Discovery ordnungsgemäß funktioniert und Paketverlust verhindert wird. Wählen Sie Custom ICMP Rule (Benutzerdefinierte ICMP-Regel) für den Typ und Destination Unreachable (Zielbereich nicht erreichbar), Fragmentation required (Fragmentierung erforderlich) und DF flag set (DF-Markierung gesetzt) für den Portbereich (Typ 3, Code 4). Wenn Sie Traceroute verwenden, fügen Sie außerdem die folgende Regel hinzu: wählen Sie als Typ Custom ICMP Rule (Benutzerdefinierte ICMP-Regel) und als Port-Bereich Time Exceeded (Zeit überschritten), TTL expired transit (TTL bei Übertragung abgelaufen) (Typ 11, Code 0). Weitere Informationen finden Sie unter Network Maximum Transmission Unit (MTU) für Ihre EC2-Instance im Amazon EC2 EC2-Benutzerhandbuch.

Arbeiten mit Netzwerk-ACLs

Die folgenden Aufgaben veranschaulichen, wie Sie unter Verwendung der Amazon VPC-Konsole mit Netzwerk-ACLs arbeiten.

Bestimmen der Netzwerk-ACL-Zuordnungen

Über die Amazon VPC-Konsole können Sie herausfinden, welche Netzwerk-ACL mit einem Subnetz verknüpft ist. Netzwerk-ACLs können mehreren Subnetzen zugeordnet werden, daher können Sie auch feststellen, welche Subnetze einer Netzwerk-ACL zugeordnet sind.

So bestimmen Sie, welche Netzwerk-ACL einem Subnetz zugeordnet ist
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Wählen Sie im Navigationsbereich Subnets und dann das Subnetz aus.

    Sie finden die dem Subnetz zugeordnete Netzwerk-ACL einschließlich der Netzwerk-ACL-Regeln auf der Registerkarte Network ACL.

So bestimmen Sie, welche Subnetze einer Netzwerk-ACL zugeordnet sind
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Wählen Sie im Navigationsbereich Network ACLs aus. Der Spalte Associated With können Sie entnehmen, wie viele Subnetze einer Netzwerk-ACL zugeordnet sind.

  3. Wählen Sie eine Netzwerk-ACL aus.

  4. Wählen Sie im Detailbereich Subnet Associations (Subnetzzuordnungen) aus, um die Subnetze anzuzeigen, die der Netzwerk-ACL zugeordnet sind.

Erstellen einer Netzwerk-ACL

Sie können für Ihre VPC benutzerdefinierte Netzwerk-ACLs erstellen. Standardmäßig verweigern benutzerdefinierte Netzwerk-ACLs den gesamten Datenverkehr, bis Sie Regeln hinzufügen. Neu erstellte Netzwerk-ACLs müssen einem Subnetz erst zugeordnet werden.

So erstellen Sie eine Netzwerk-ACL
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Wählen Sie im Navigationsbereich Network ACLs aus.

  3. Klicken Sie auf Create Network ACL.

  4. Im Dialogfeld Create Network ACL (Netzwerk-ACL erstellen) können Sie der Netzwerk-ACL einen Namen geben. Wählen Sie dann die ID Ihrer VPC in der Liste VPC aus. Wählen Sie dann Yes, Create (Ja, erstellen) aus.

Hinzufügen und Löschen von Regeln

Wenn Sie eine Regel zu einer ACL hinzufügen oder daraus löschen, sind alle Subnetze, die der ACL zugeordnet sind, von dieser Änderung betroffen. Sie müssen die Instances im Subnetz nicht beenden und neu starten. Die Änderungen werden nach kurzer Zeit wirksam.

Wichtig

Seien Sie sehr vorsichtig, wenn Sie Regeln gleichzeitig hinzufügen und löschen. Netzwerk-ACL-Regeln definieren die Arten des ein- und ausgehenden Netzwerkverkehrs Ihrer VPCs. Wenn Sie eingehende oder ausgehende Regeln löschen und dann mehr neue Einträge hinzufügen, als in Amazon VPC-Kontingente erlaubt sind, werden die zum Löschen ausgewählten Einträge entfernt und neue Einträge werden nicht hinzugefügt. Dies kann zu unerwarteten Verbindungsproblemen führen und versehentlich den Zugriff auf und von Ihren VPCs verhindern.

Wenn Sie die Amazon EC2-API oder ein Befehlszeilen-Tool verwenden, können Sie keine Regeln ändern. Sie können nur Regeln hinzufügen und löschen. Wenn Sie die Amazon VPC-Konsole verwenden, können Sie die Einträge für vorhandene Regeln ändern. Die Konsole entfernt die vorhandene Regel und fügt eine neue Regel für Sie hinzu. Wenn Sie die Reihenfolge von Regeln innerhalb der ACL ändern möchten, müssen Sie eine neue Regel mit der neuen Regelnummer hinzufügen und die ursprüngliche Regel löschen.

So fügen Sie einer Netzwerk-ACL Regeln hinzu
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Wählen Sie im Navigationsbereich Network ACLs aus.

  3. Klicken Sie im Detailbereich abhängig von der hinzuzufügenden Regel entweder auf die Registerkarte Inbound Rules oder die Registerkarte Outbound Rules und anschließend auf Edit.

  4. Geben Sie unter Rule # eine Regelnummer (z. B. 100) ein. Die Regelnummer darf nicht bereits in der Netzwerk-ACL vorhanden sein. Regeln werden von der niedrigsten Nummer an der Reihe nach abgearbeitet.

    Wir empfehlen, zwischen den Regelnummern Lücken zu lassen (z. B. 100, 200, 300), statt aufeinanderfolgende Nummern zu verwenden (101, 102, 103). So können Sie jederzeit problemlos neue Regeln hinzufügen, ohne die vorhandenen Regeln neu nummerieren zu müssen.

  5. Wählen Sie aus der Liste Type eine Regel aus. Wenn Sie beispielsweise eine Regel für HTTP hinzufügen möchten, wählen Sie HTTP aus. Um eine Regel zu erstellen, die den gesamten TCP-Datenverkehr erlaubt, wählen Sie All TCP aus. Für einige dieser Optionen (beispielsweise HTTP) wird der Port automatisch ausgefüllt. Wenn Sie ein Protokoll verwenden möchten, das nicht in der Liste enthalten ist, wählen Sie Custom Protocol Rule aus.

  6. (Optional) Wenn Sie eine benutzerdefinierte Protokollregel erstellen, wählen Sie die Protokollnummer und den Namen aus der Liste Protocol aus. Weitere Informationen finden Sie unter IANA List of Protocol Numbers.

  7. (Optional) Wenn für das ausgewählte Protokoll eine Portnummer erforderlich ist, geben Sie die Portnummer oder den Portbereich durch einen Bindestrich getrennt (z. B. 49152-65535) ein.

  8. Geben Sie im Feld Source oder Destination (je nachdem, ob es sich um eine Regel für eingehenden oder ausgehenden Datenverkehr handelt) den CIDR-Bereich ein, auf den die Regel angewendet werden soll.

  9. Wählen Sie in der Liste Allow/Deny ALLOW aus, um den ausgewählten Datenverkehr zu erlauben, oder DENY, um den ausgewählten Datenverkehr zu verweigern.

  10. (Optional) Um eine weitere Regel hinzuzufügen, wählen Sie Add another rule aus und wiederholen Sie die Schritte 4 bis 9.

  11. Klicken Sie abschließend auf Save.

So löschen Sie eine Regel aus einer Netzwerk-ACL
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Klicken Sie im Navigationsbereich auf Network ACLs und wählen Sie dann die Netzwerk-ACL aus.

  3. Klicken Sie im Detailbereich entweder auf die Registerkarte Inbound Rules oder die Registerkarte Outbound Rules und anschließend auf Edit. Klicken Sie für die gewünschte Regel auf Remove und anschließend auf Save.

Zuweisen eines Subnetzes zu einer Netzwerk-ACL

Damit die Regeln einer Netzwerk-ACL auf ein bestimmtes Subnetz angewendet werden können, müssen Sie das Subnetz der Netzwerk-ACL zuordnen. Sie können eine Netzwerk-ACL mehreren Subnetzen zuordnen. Ein Subnetz kann jedoch nur einer Netzwerk-ACL zugeordnet werden. Subnetze, die keiner bestimmten ACL zugewiesen sind, werden standardmäßig der Standardnetzwerk-ACL zugewiesen.

So weisen Sie ein Subnetz einer Netzwerk-ACL zu
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Klicken Sie im Navigationsbereich auf Network ACLs und wählen Sie dann die Netzwerk-ACL aus.

  3. Klicken Sie im Detailbereich auf der Registerkarte Subnet Associations auf Edit. Aktivieren Sie das Kontrollkästchen Associate für das Subnetz, um es der Netzwerk-ACL zuzuordnen, und klicken Sie auf Save.

Aufheben der Zuordnung einer Netzwerk-ACL zu einem Subnetz

Sie können die Zuordnung einer benutzerdefinierten Netzwerk-ACL zu einem Subnetz aufheben. Wenn das Subnetz von der benutzerdefinierten Netzwerk-ACL getrennt wurde, wird es dann automatisch der Standard-Netzwerk-ACL zugeordnet.

So heben Sie die Zuordnung eines Subnetzes zu einer Netzwerk-ACL auf
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Klicken Sie im Navigationsbereich auf Network ACLs und wählen Sie dann die Netzwerk-ACL aus.

  3. Klicken Sie im Detailbereich auf die Registerkarte Subnet Associations.

  4. Klicken Sie auf Edit und deaktivieren Sie das Kontrollkästchen Associate neben dem Subnetz. Wählen Sie Speichern.

Ändern der Netzwerk-ACL eines Subnetzes

Sie können die einem Subnetz zugeordnete Netzwerk-ACL ändern. Wenn Sie beispielsweise ein Subnetz erstellen, wird dieses zunächst der Standardnetzwerk-ACL zugeordnet. Möglicherweise möchten Sie es jedoch einer eigenen, benutzerdefinierten Netzwerk-ACL zuordnen.

Nachdem Sie die Netzwerk-ACL eines Subnetzes geändert haben, müssen Sie die Instances im Subnetz nicht beenden und neu starten. Die Änderungen werden nach kurzer Zeit wirksam.

So ändern Sie die Netzwerk-ACL-Zuordnung eines Subnetzes
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Wählen Sie im Navigationsbereich Subnets und dann das Subnetz aus.

  3. Wählen Sie die Registerkarte Network ACL aus und klicken Sie auf Edit.

  4. Wählen Sie aus der Liste Change to (Ändern zu) die Netzwerk-ACL aus, die Sie dem Subnetz zuordnen möchten, und klicken Sie auf Save (Speichern).

Löschen einer Netzwerk-ACL

Sie können eine Netzwerk-ACL nur löschen, wenn ihr keine Subnetze zugeordnet sind. Die Standardnetzwerk-ACL kann nicht gelöscht werden.

So löschen Sie eine Netzwerk-ACL
  1. Öffnen Sie die Amazon VPC-Konsole unter https://console.aws.amazon.com/vpc/.

  2. Wählen Sie im Navigationsbereich Network ACLs aus.

  3. Wählen Sie die Netzwerk-ACL aus und klicken Sie auf Delete.

  4. Wählen Sie im Bestätigungsdialogfeld Yes, Delete aus.

Überblick über die API und Befehlszeile

Sie können die auf dieser Seite beschriebenen Aufgaben über die Befehlszeile oder eine API ausführen. Weitere Informationen über Befehlszeilenschnittstellen und eine Liste der verfügbaren APIs finden Sie unter Arbeiten mit Amazon VPC.

Erstellen einer Netzwerk-ACL für Ihre VPC
Beschreiben Ihrer Netzwerk-ACLs
Hinzufügen von Regeln zu einer Netzwerk-ACL
Löschen von Regeln aus einer Netzwerk-ACL
Ersetzen von vorhandenen Regeln innerhalb einer Netzwerk-ACL
Ersetzen einer Netzwerk-ACL-Zuordnung
Löschen einer Netzwerk-ACL

Netzwerk-ACLs mit Firewall Manager verwalten

AWS Firewall Manager vereinfacht Ihre Netzwerk-ACL-Administrations- und Wartungsaufgaben für mehrere Konten und Subnetze. Sie können den Firewall Manager verwenden, um Konten und Subnetze in Ihrer Organisation zu überwachen und die von Ihnen definierten Netzwerk-ACL-Konfigurationen automatisch anzuwenden. Firewall Manager ist besonders nützlich, wenn Sie Ihre gesamte Organisation schützen möchten oder wenn Sie häufig neue Subnetze hinzufügen, die Sie automatisch von einem zentralen Administratorkonto aus schützen möchten.

Mit einer Firewall Manager Manager-Netzwerk-ACL-Richtlinie können Sie mit einem einzigen Administratorkonto die Mindestregelsätze konfigurieren, überwachen und verwalten, die Sie in den Netzwerk-ACLs, die Sie in Ihrem Unternehmen verwenden, definiert haben möchten. Sie geben an, welche Konten und Subnetze in Ihrer Organisation in den Geltungsbereich der Firewall Manager Manager-Richtlinie fallen. Firewall Manager meldet den Konformitätsstatus der Netzwerk-ACLs für Subnetze im Geltungsbereich, und Sie können Firewall Manager so konfigurieren, dass nicht konforme Netzwerk-ACLs automatisch behoben werden, um sie konform zu machen.

Weitere Informationen zur Verwendung von Firewall Manager zur Verwaltung Ihrer Netzwerk-ACLs finden Sie in den folgenden Ressourcen im AWS Firewall Manager Entwicklerhandbuch:

Beispiel: Steuern des Zugriffs auf Instances in einem Subnetz

In diesem Beispiel können die Instances in Ihrem Subnetz miteinander kommunizieren und sind von vertrauenswürdigen Remote-Computern aus zugreifbar. Der Remotecomputer kann ein Computer in Ihrem lokalen Netzwerk oder eine Instance in einem anderen Subnetz oder VPC sein. Sie verwenden ihn, um eine Verbindung zu Ihren Instances herzustellen, um administrative Aufgaben auszuführen. Die Sicherheitsgruppenregeln und Netzwerk-ACL-Regeln erlauben den Zugriff von der IP-Adresse Ihres Remote-Computers (172.31.1.2/32). Der gesamte Datenverkehr aus dem Internet oder anderen Netzwerken wird verweigert. Dieses Szenario bietet die Flexibilität, Sicherheitsgruppen oder Sicherheitsgruppenregeln für Instances zu ändern und die Netzwerk-ACL als zusätzliche Schutzebene zu nutzen.

Verwenden einer Sicherheitsgruppe und einer Netzwerk-ACL

Im Folgenden finden Sie ein Beispiel für eine Sicherheitsgruppe, die mit den Instances verknüpft werden soll. Sicherheitsgruppen sind zustandsbehaftet. Daher benötigen Sie keine Regel, die Antworten auf eingehenden Datenverkehr zulässt.

Eingehend
Protokolltyp Protocol (Protokoll) Port-Bereich Source Kommentare
Gesamter Datenverkehr Alle Alle sg-1234567890abcdef0 Alle mit dieser Sicherheitsgruppe verbundenen Instances können miteinander kommunizieren.
SSH TCP 22 172.31.1.2/32 Lässt eingehenden SSH-Zugriff von dem Remote-Computer zu.
Ausgehend
Protokolltyp Protocol (Protokoll) Port-Bereich Zielbereich Kommentare
Gesamter Datenverkehr Alle Alle sg-1234567890abcdef0 Alle mit dieser Sicherheitsgruppe verbundenen Instances können miteinander kommunizieren.

Im Folgenden finden Sie ein Beispiel für eine Netzwerk-ACL, die mit den Subnetzen für die Instances verknüpft wird. Die Netzwerk-ACL-Regeln gelten für alle Instances im Subnetz. Netzwerk-ACLs sind zustandslos. Daher benötigen Sie eine Regel, die Antworten auf eingehenden Datenverkehr zulässt.

Eingehend
Regel Nr. Typ Protocol (Protokoll) Port-Bereich Source Erlauben/Verweigern Kommentare
100 SSH TCP 22 172.31.1.2/32 ERLAUBEN Lässt eingehenden Datenverkehr von dem Remote-Computer zu.
* Gesamter Datenverkehr Alle Alle 0.0.0.0/0 VERWEIGERN Verweigert jeglichen anderen eingehenden Datenverkehr.
Ausgehend
Regel Nr. Typ Protocol (Protokoll) Port-Bereich Zielbereich Erlauben/Verweigern Kommentare
100 Custom TCP TCP 1024 - 65535 172.31.1.2/32 ERLAUBEN Lässt ausgehende Antworten an den Remote-Computer zu.
* Gesamter Datenverkehr Alle Alle 0.0.0.0/0 VERWEIGERN Verweigert jeglichen anderen ausgehenden Datenverkehr.

Wenn Sie versehentlich Ihre Sicherheitsgruppenregeln zu offen gestalten, erlaubt die Netzwerk-ACL in diesem Beispiel weiterhin den Zugriff nur über die angegebene IP-Adresse. Die folgende Sicherheitsgruppe enthält beispielsweise eine Regel, die eingehenden SSH-Zugriff von jeder IP-Adresse aus zulässt. Wenn Sie diese Sicherheitsgruppe jedoch einer Instance in einem Subnetz zuordnen, das die Netzwerk-ACL verwendet, können nur andere Instances im Subnetz und Ihr Remote-Computer auf die Instance zugreifen, da die Netzwerk-ACL-Regeln anderen eingehenden Datenverkehr im Subnetz verweigern.

Eingehend
Typ Protocol (Protokoll) Port-Bereich Source Kommentare
Gesamter Datenverkehr Alle Alle sg-1234567890abcdef0 Alle mit dieser Sicherheitsgruppe verbundenen Instances können miteinander kommunizieren.
SSH TCP 22 0.0.0.0/0 Lässt SSH-Zugriff von beliebigen IP-Adressen zu.
Ausgehend
Typ Protocol (Protokoll) Port-Bereich Zielbereich Kommentare
Gesamter Datenverkehr Alle Alle 0.0.0.0/0 Lässt den gesamten ausgehenden Datenverkehr zu.

Beheben Sie Probleme mit der Erreichbarkeit

Reachability Analyzer ist ein Tool zur statischen Konfigurationsanalyse. Verwenden Sie Reachability Analyzer, um die Netzwerkerreichbarkeit zwischen zwei Ressourcen in Ihrer VPC zu analysieren und zu debuggen. Reachability Analyzer erzeugt hop-by-hop Details zum virtuellen Pfad zwischen diesen Ressourcen, wenn sie erreichbar sind, und identifiziert andernfalls die blockierende Komponente. Es kann beispielsweise fehlende oder falsch konfigurierte Netzwerk-ACL-Regeln identifizieren.

Weitere Informationen finden Sie im Leitfaden Reachability Analyzer.