Läs poster och fält i Flow Logs

En flow log-post är en enda rad som beskriver trafik för en anslutning under aggregeringsintervallet. Standardformatet är en fast sekvens av blankstegsseparerade fält. Att snabbt kunna läsa denna rad är en grundläggande färdighet vid alla nätverksutredningar i AWS.

Kärnan i en post är femtupletten: källadress, destinationsadress, källport, destinationsport och protokollnummer. Den identifierar en kommunikation unikt. Protokoll 6 är TCP och 17 är UDP. Tillsammans visar dessa fält exakt vilka slutpunkter som kommunicerade och via vilken tjänst.

Fälten srcaddr och dstaddr visar de IP-adresser som berörs. För trafik som lämnar en instans är srcaddr instansen; för inkommande trafik är det den externa motparten. Det är avgörande att läsa riktningen korrekt: om källa och destination förväxlas kan hela förståelsen av en händelse bli fel.

dstport anger vanligtvis tjänsten: 443 är HTTPS, 22 är SSH, 3389 är RDP och 3306 är MySQL. Oväntade destinationsportar, till exempel utgående trafik på 6667 (IRC), som ofta används av botnät, är varningssignaler. srcport är vanligtvis en tillfällig port med högt nummer som klienten väljer.

Fälten bytes och packets räknar data som överförts under intervallet. En liten begäran som följs av en mycket stor mängd utgående byte kan tyda på dataexfiltrering. Genom att följa dessa volymer över tid blir det lättare att skilja normal kommunikation från en värd som plötsligt skickar gigabyte till en okänd adress.

Fältet action är ACCEPT eller REJECT. REJECT betyder att en säkerhetsgrupp eller NACL blockerade flödet. Många REJECT från en källa mot många portar tyder på skanning. Säkerhetsgrupper är tillståndsbevarande, så en REJECT därifrån återspeglar vanligtvis en NACL-regel, vilket hjälper dig att avgöra vilken kontroll som agerade.

Det sista fältet, log-status, är OK, NODATA eller SKIPDATA. NODATA betyder att ingen trafik förekom under intervallet och SKIPDATA betyder att vissa poster hoppades över på grund av kapacitetsbegränsningar. SKIPDATA är en varning om att det finns ett glapp i insynen, vilket är viktigt när du behöver fullständiga data i en utredning.

Varje post innehåller en start- och end-tid i Unix-epoksekunder för aggregeringsfönstret, inte för varje paket. När du korrelerar Flow Logs med CloudTrail eller applikationsloggar bör du komma ihåg att tiderna anger intervallets gränser. En händelse kan därför ha inträffat när som helst under fönstret.

Ett anpassat format kan lägga till värdefulla fält som instance-id, vpc-id, subnet-id, tcp-flags och flow-direction. Fälten pkt-srcaddr och pkt-dstaddr visar de ursprungliga adresserna bakom NAT, som de grundläggande fälten srcaddr/dstaddr kan dölja. Dessa extra fält gör utredningar betydligt snabbare.

För att tolka en rad identifierar du först femtupletten, därefter åtgärden och byteantalet och sedan kopplar du destinationsporten till en tjänst. Fråga dig om riktningen, volymen och motparten är rimliga för instansens roll. Denna systematiska läsning omvandlar en kryptisk loggrad till en tydlig beskrivning av vad som hände.

Med övning upptäcker du avvikelser direkt: SSH från en okänd internet-IP-adress, stora utgående överföringar till en ny region eller upprepade REJECT vid skanning av ett subnät. Fälten ändras aldrig, så färdigheten handlar om mönsterigenkänning. Denna säkerhet är precis vad provet testar i scenarier om nätverkssynlighet.

En flow log-post kretsar kring femtupletten (käll-/destinationsadress, käll-/destinationsport och protokoll) samt bytes, packets, åtgärden ACCEPT/REJECT och en log-status på OK, NODATA eller SKIPDATA. Destinationsportar avslöjar tjänster, byteantal kan tyda på exfiltrering och anpassade format lägger till fält som instance-id och tcp-flags. Genom att läsa tuplen först bygger du snabbt upp utredningsintuition.