Beispiele für Flow-Protokolldatensätze

Im Folgenden finden Sie Beispiele für Flow-Protokolldatensätze, die spezifischen Datenverkehr erfassen.

Informationen zum Format des Flow-Protokolldatensatzes finden Sie unter Flow-Protokolldatensätze. Informationen zum Erstellen von Flow-Protokollen finden Sie unter Arbeiten mit Flow-Protokollen.

Zulässiger und abgelehnter Datenverkehr

Im Folgenden finden Sie Beispiele für Standard-Flow-Protokolldatensätze.

In diesem Beispiel ist der SSH-Verkehr (Zielport 22, TCP-Protokoll) von der IP-Adresse 172.31.16.139 zur Netzwerkschnittstelle mit privater IP-Adresse 172.31.16.21 und die ID eni-1235b8ca123456789 im Konto 123456789010 wurde zugelassen.

2 123456789010 eni-1235b8ca123456789 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK

In diesem Beispiel wurde RDP-Datenverkehr (Zielport 3389, TCP-Protokoll) zur Netzwerkschnittstelle eni-1235b8ca123456789 im Konto 123456789010 abgelehnt.

2 123456789010 eni-1235b8ca123456789 172.31.9.69 172.31.9.12 49761 3389 6 20 4249 1418530010 1418530070 REJECT OK

Keine Daten und übersprungene Datensätze

Im Folgenden finden Sie Beispiele für Standard-Flow-Protokolldatensätze.

In diesem Beispiel wurden während des Aggregationsintervalls keine Daten aufgezeichnet.

2 123456789010 eni-1235b8ca123456789 - - - - - - - 1431280876 1431280934 - NODATA

In diesem Beispiel wurden Datensätze während des Aggregationsintervalls übersprungen. VPC Flow Logs überspringt Datensätze, wenn es während eines Aggregationsintervalls keine Flow-Protokolldaten erfassen kann, weil sie die interne Kapazität überschreiten. Ein einzelner übersprungener Datensatz kann mehrere Datenflüsse darstellen, die während des Aggregationsintervalls nicht für die Netzwerkschnittstelle erfasst wurden.

2 123456789010 eni-11111111aaaaaaaaa - - - - - - - 1431280876 1431280934 - SKIPDATA

Sicherheitsgruppen- und Netzwerk-ACL-Regeln

Wenn Sie mithilfe von Flow-Protokollen übermäßig restriktive oder offene Sicherheitsgruppenregeln oder Netzwerk-ACL-Regeln diagnostizieren, müssen Sie dabei beachten, inwieweit eine Ressource zustandsbehaftet ist. Sicherheitsgruppen sind zustandsbehaftet, d. h. Antworten auf zulässigen Datenverkehr sind immer zulässig, auch wenn die Regeln der Sicherheitsgruppe dies nicht zulassen würden. Netzwerk-ACLs hingegen sind zustandslos und Antworten auf zulässigen Datenverkehr sind somit abhängig von den Netzwerk-ACL-Regeln.

Sie senden beispielsweise den Befehl ping von Ihrem privaten Computer (mit der IP-Adresse 203.0.113.12) an Ihre Instance (mit der privaten IP-Adresse der Netzwerkschnittstelle 172.31.16.139). Die Regeln für eingehenden Datenverkehr Ihrer Sicherheitsgruppe lassen ICMP-Datenverkehr zu, die Regeln für ausgehenden Datenverkehr lassen ICMP-Datenverkehr jedoch nicht zu. Da die Sicherheitsgruppen zustandsbehaftet sind, ist der Antwort-Ping von Ihrer Instance zulässig. Ihre Netzwerk-ACL erlaubt eingehenden, jedoch keinen ausgehenden ICMP-Datenverkehr. Da Netzwerk-ACLs zustandslos sind, verfällt der Antwortping und wird nicht an den Computer gesendet. In einem Flow-Standardprotokoll wird dies als zwei Flow-Protokolldatensätze angezeigt:

• Ein ACCEPT-Datensatz für den ursprünglichen Ping, der sowohl von der Netzwerk-ACL als auch der Sicherheitsgruppe zugelassen wird und daher zur Instance durchdringen konnte

• Ein REJECT-Datensatz für den Antwortping, der von der Netzwerk-ACL abgelehnt wurde

2 123456789010 eni-1235b8ca123456789 203.0.113.12 172.31.16.139 0 0 1 4 336 1432917027 1432917142 ACCEPT OK

2 123456789010 eni-1235b8ca123456789 172.31.16.139 203.0.113.12 0 0 1 4 336 1432917094 1432917142 REJECT OK

Wenn Ihre Netzwerk-ACL ausgehenden ICMP-Datenverkehr zulässt, enthält das Flow-Protokoll zwei ACCEPT-Datensätze (einen für den ursprünglichen Ping und einen für den Antwortping). Wenn Ihre Sicherheitsgruppe eingehenden ICMP-Datenverkehr ablehnt, enthält das Flow-Protokoll einen REJECT-Datensatz, da der Datenverkehr die Instance nicht erreicht hat.

IPv6-Datenverkehr

Der folgende Code ist ein Beispiel für einen Standard-Flow-Protokolldatensatz. Im Beispiel war der SSH-Verkehr (Port 22) von IPv6-Adresse 2001:db8:1234:a100:8d6e:3477:df66:f105 an die Netzwerkschnittstelle eni-1235b8ca123456789 auf Konto 123456789010 zulässig.

2 123456789010 eni-1235b8ca123456789 2001:db8:1234:a100:8d6e:3477:df66:f105 2001:db8:1234:a102:3304:8879:34cf:4071 34892 22 6 54 8855 1477913708 1477913820 ACCEPT OK

TCP-Flag-Sequenz

Dieser Abschnitt enthält Beispiele für benutzerdefinierte Flow-Protokolle, die die folgenden Felder in der folgenden Reihenfolge erfassen.

version vpc-id subnet-id instance-id interface-id account-id type srcaddr dstaddr srcport dstport pkt-srcaddr pkt-dstaddr protocol bytes packets start end action tcp-flags log-status

tcp-flagsDas Feld in den Beispielen in diesem Abschnitt wird durch den Wert im second-to-last Flow-Protokoll dargestellt. Mit Hilfe von TCP-Flags können Sie die Richtung des Datenverkehrs ermitteln, z. B. welcher Server die Verbindung initiiert hat.

Anmerkung

Weitere Informationen über die Option tcp-flags und eine Erklärung der einzelnen TCP-Flags finden Sie unter Verfügbare Felder.

In den folgenden Datensätzen (mit Beginn um 19:47:55 und Ende um 19:48:53) wurden zwei Verbindungen von einem Client auf einem Server gestartet, der auf Port 5001 ausgeführt wird. Der Server empfing zwei SYN-Flags (2) vom Client von verschiedenen Quell-Ports auf dem Client (43416 und 43418). Für jedes SYN wurde ein SYN-ACK vom Server an den Client (18) auf dem entsprechenden Port gesendet.

3 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-01234567890123456 eni-1235b8ca123456789 123456789010 IPv4 52.213.180.42 10.0.0.62 43416 5001 52.213.180.42 10.0.0.62 6 568 8 1566848875 1566848933 ACCEPT 2 OK
3 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-01234567890123456 eni-1235b8ca123456789 123456789010 IPv4 10.0.0.62 52.213.180.42 5001 43416 10.0.0.62 52.213.180.42 6 376 7 1566848875 1566848933 ACCEPT 18 OK
3 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-01234567890123456 eni-1235b8ca123456789 123456789010 IPv4 52.213.180.42 10.0.0.62 43418 5001 52.213.180.42 10.0.0.62 6 100701 70 1566848875 1566848933 ACCEPT 2 OK
3 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-01234567890123456 eni-1235b8ca123456789 123456789010 IPv4 10.0.0.62 52.213.180.42 5001 43418 10.0.0.62 52.213.180.42 6 632 12 1566848875 1566848933 ACCEPT 18 OK

Im zweiten Aggregationsintervall ist jetzt eine der Verbindungen beendet, die während des vorherigen Flows hergestellt wurde. Der Client hat ein FIN-Flag (1) für die Verbindung auf Port 43418 an den Server gesendet. Der Server hat ein FIN-Flag an den Client auf Port 43418 gesendet.

3 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-01234567890123456 eni-1235b8ca123456789 123456789010 IPv4 10.0.0.62 52.213.180.42 5001 43418 10.0.0.62 52.213.180.42 6 63388 1219 1566848933 1566849113 ACCEPT 1 OK
3 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-01234567890123456 eni-1235b8ca123456789 123456789010 IPv4 52.213.180.42 10.0.0.62 43418 5001 52.213.180.42 10.0.0.62 6 23294588 15774 1566848933 1566849113 ACCEPT 1 OK

Für kurze Verbindungen (z. B. wenige Sekunden), die innerhalb eines einzigen Aggregationsintervalls hergestellt und beendet werden, können die Flags in derselben Zeile im Flow-Protokolldatensatz für Datenverkehr in die gleiche Richtung festgelegt werden. Im folgenden Beispiel wird die Verbindung innerhalb desselben Aggregationsintervalls hergestellt und beendet. In der ersten Zeile lautet der Wert des TCP-Flags 3. Dies deutet darauf hin, dass eine SYN- und eine FIN-Meldung vom Client an den Server gesendet wurden. In der zweiten Zeile lautet der Wert des TCP-Flags 19. Dies deutet darauf hin, dass eine SYN-ACK- und eine FIN-Meldung vom Server an den Client gesendet wurden.

3 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-01234567890123456 eni-1235b8ca123456789 123456789010 IPv4 52.213.180.42 10.0.0.62 43638 5001 52.213.180.42 10.0.0.62 6 1260 17 1566933133 1566933193 ACCEPT 3 OK
3 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-01234567890123456 eni-1235b8ca123456789 123456789010 IPv4 10.0.0.62 52.213.180.42 5001 43638  10.0.0.62 52.213.180.42 6 967 14 1566933133 1566933193 ACCEPT 19 OK

Datenverkehr durch ein NAT-Gateway

In diesem Beispiel greift eine Instance in einem privaten Subnetz über ein NAT-Gateway in einem öffentlichen Subnetz auf das Internet zu.

Das folgende benutzerdefinierte Flow-Protokoll für die Netzwerkschnittstelle des NAT-Gateways erfasst die folgenden Felder in der folgenden Reihenfolge.

instance-id interface-id srcaddr dstaddr pkt-srcaddr pkt-dstaddr

Das Flow-Protokoll zeigt den Flow des Datenverkehrs von der IP-Adresse der Instance (10.0.1.5) über die Netzwerkschnittstelle des NAT-Gateways zu einem Host im Internet (203.0.113.5). Die Netzwerkschnittstelle des NAT-Gateways ist eine vom Anforderer verwaltete Netzwerkschnittstelle. Daher zeigt der Flow-Protokolldatensatz für das Feld instance-id das Symbol '-'. Die folgende Zeile zeigt Datenverkehr von der Quell-Instance zur Netzwerkschnittstelle des NAT-Gateways. Die Werte für die Felder dstaddr und pkt-dstaddr unterscheiden sich. Das Feld dstaddr zeigt die private IP-Adresse der Netzwerkschnittstelle des NAT-Gateways an und das Feld pkt-dstaddr zeigt die endgültige Ziel-IP-Adresse des Hosts im Internet an.

- eni-1235b8ca123456789 10.0.1.5 10.0.0.220 10.0.1.5 203.0.113.5

Die nächsten beiden Zeilen zeigen den Datenverkehr von der Netzwerkschnittstelle des NAT-Gateways zum Ziel-Host im Internet sowie den Antwortdatenverkehr vom Host zur Netzwerkschnittstelle des NAT-Gateways an.

- eni-1235b8ca123456789 10.0.0.220 203.0.113.5 10.0.0.220 203.0.113.5
- eni-1235b8ca123456789 203.0.113.5 10.0.0.220 203.0.113.5 10.0.0.220

Die folgende Zeile zeigt den Antwortdatenverkehr von der Netzwerkschnittstelle des NAT-Gateways zur Quell-Instance an. Die Werte für die Felder srcaddr und pkt-srcaddr unterscheiden sich. Das Feld srcaddr zeigt die private IP-Adresse der Netzwerkschnittstelle des NAT-Gateways an und das Feld pkt-srcaddr zeigt die IP-Adresse des Hosts im Internet an.

- eni-1235b8ca123456789 10.0.0.220 10.0.1.5 203.0.113.5 10.0.1.5

Sie erstellen ein weiteres benutzerdefiniertes Flow-Protokoll mit derselben Gruppe an Feldern wie oben. Sie erstellen das Flow-Protokoll für die Netzwerkschnittstelle für die Instance im privaten Subnetz. In diesem Fall gibt das Feld instance-id die ID der mit der Netzwerkschnittstelle verknüpften Instance zurück und die Felder dstaddr und pkt-dstaddr sowie srcaddr und pkt-srcaddr unterscheiden sich nicht. Anders als bei der Netzwerkschnittstelle für das NAT-Gateway handelt es sich bei dieser Netzwerkschnittstelle nicht um eine Netzwerkzwischenschnittstelle für Datenverkehr.

i-01234567890123456 eni-1111aaaa2222bbbb3 10.0.1.5 203.0.113.5 10.0.1.5 203.0.113.5 #Traffic from the source instance to host on the internet
i-01234567890123456 eni-1111aaaa2222bbbb3 203.0.113.5 10.0.1.5 203.0.113.5 10.0.1.5 #Response traffic from host on the internet to the source instance

Datenverkehr durch ein Transit-Gateway

In diesem Beispiel stellt ein Client in VPC A über ein Transit-Gateway eine Verbindung mit einem Webserver in VPC B her. Client und Server befinden sich in verschiedenen Availability Zones. Der Datenverkehr erreicht den Server in VPC B über eine elastische Netzwerkschnittstellen-ID (in diesem Beispiel ist die ID eni-11111111111111111) und verlässt VPC B über eine andere (z. B. eni-22222222222222222).

Sie erstellen ein benutzerdefiniertes Flow-Protokoll für VPC B mit dem folgenden Format.

version interface-id account-id vpc-id subnet-id instance-id srcaddr dstaddr srcport dstport protocol tcp-flags type pkt-srcaddr pkt-dstaddr action log-status

Die folgenden Zeilen aus den Flow-Protokolldatensätzen zeigen den Flow des Datenverkehrs an der Netzwerkschnittstelle für den Webserver. Die erste Zeile zeigt den Anfragedatenverkehr vom Client und die letzte Zeile zeigt den Antwortdatenverkehr vom Webserver.

3 eni-33333333333333333 123456789010 vpc-abcdefab012345678 subnet-22222222bbbbbbbbb i-01234567890123456 10.20.33.164 10.40.2.236 39812 80 6 3 IPv4 10.20.33.164 10.40.2.236 ACCEPT OK
...
3 eni-33333333333333333 123456789010 vpc-abcdefab012345678 subnet-22222222bbbbbbbbb i-01234567890123456 10.40.2.236 10.20.33.164 80 39812 6 19 IPv4 10.40.2.236 10.20.33.164 ACCEPT OK

Die folgende Zeile zeigt den Anforderungsdatenverkehr auf eni-11111111111111111, einer vom Anforderer verwalteten Netzwerkschnittstelle für das Transit-Gateway in Subnetz subnet-11111111aaaaaaaaa. Daher zeigt der Flow-Protokolldatensatz für das Feld instance-id das Symbol '-'. Das Feld srcaddr zeigt die private IP-Adresse der Netzwerkschnittstelle des Transit-Gateways an, und das Feld pkt-srcaddr zeigt die Quell-IP-Adresse des Clients in VPC A an.

3 eni-11111111111111111 123456789010 vpc-abcdefab012345678 subnet-11111111aaaaaaaaa - 10.40.1.175 10.40.2.236 39812 80 6 3 IPv4 10.20.33.164 10.40.2.236 ACCEPT OK

Die folgende Zeile zeigt den Antwortdatenverkehr auf eni-22222222222222222, einer vom Anforderer verwalteten Netzwerkschnittstelle für das Transit-Gateway in Subnetz subnet-22222222bbbbbbbbb an. Das Feld dstaddr zeigt die private IP-Adresse der Netzwerkschnittstelle des Transit-Gateways an, und das Feld pkt-dstaddr zeigt die IP-Adresse des Clients in VPC A an.

3 eni-22222222222222222 123456789010 vpc-abcdefab012345678 subnet-22222222bbbbbbbbb - 10.40.2.236 10.40.2.31 80 39812 6 19 IPv4 10.40.2.236 10.20.33.164 ACCEPT OK

Servicename, Verkehrspfad und Flow-Richtung

Im Folgenden finden Sie ein Beispiel der Felder für einen benutzerdefinierten Flow-Protokolldatensatz.

version srcaddr dstaddr srcport dstport protocol start end type packets bytes account-id vpc-id subnet-id instance-id interface-id region az-id sublocation-type sublocation-id action tcp-flags pkt-srcaddr pkt-dstaddr pkt-src-aws-service pkt-dst-aws-service traffic-path flow-direction log-status

Im folgenden Beispiel ist die Version 5, da die Datensätze Felder der Version 5 enthalten. Eine EC2-Instance ruft den Amazon S3-Service auf. Flow-Protokolle werden auf der Netzwerkschnittstelle für die Instance erfasst. Der erste Datensatz hat eine Flow-Richtung von ingress und der zweite Datensatz hat eine Flow-Richtung von egress. Für den egress-Datensatz ist traffic-path 8, was darauf hinweist, dass der Datenverkehr über ein Internet-Gateway läuft. Das Feld traffic-path wird nicht für ingress-Verkehr unterstützt. Wenn pkt-srcaddr oder pkt-dstaddr eine öffentliche IP-Adresse ist, wird der Servicename angezeigt.

5 52.95.128.179 10.0.0.71 80 34210 6 1616729292 1616729349 IPv4 14 15044 123456789012 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-0c50d5961bcb2d47b eni-1235b8ca123456789 ap-southeast-2 apse2-az3 - - ACCEPT 19 52.95.128.179 10.0.0.71 S3 - - ingress OK
5 10.0.0.71 52.95.128.179 34210 80 6 1616729292 1616729349 IPv4 7 471 123456789012 vpc-abcdefab012345678 subnet-aaaaaaaa012345678 i-0c50d5961bcb2d47b eni-1235b8ca123456789 ap-southeast-2 apse2-az3 - - ACCEPT 3 10.0.0.71 52.95.128.179 - S3 8 egress OK