Hvorfor tcpdump viser IPsec-klartekst bare i én retning

Du kjører tcpdump på den ytre grensesnittet til en Linux IPsec-gateway og ser to ting samtidig: innkommende ESP-rammer og, rett etter dem, de dekrypterte indre pakkene. Utgående vises bare ESP. Den naturlige konklusjonen er at svar ikke sendes, eller at IPsec krypterer den ene retningen og glemmer den andre. Ingen av delene er sanne.

Det du ser på, er et fangstpunkt. Kjernen omformer utgående pakker før enhetens sendebane overleverer dem til pakkesokkelen, så sokkelen ser aldri den indre formen på vei ut. Innkommende fanges pakken først som ESP, og den dekapsulerte kopien blir synlig når den kommer inn i stakken igjen. Samme trafikk, to forskjellige observasjonsvinduer.

Fangstpunktet avgjør hva du ser

På et vanlig grensesnitt sitter en AF_PACKET-sokkel nær enhetslaget. Pakker som forlater verten, går først gjennom IPsec-utgangsbehandlingen, som gjør et indre TCP-segment om til et ESP- eller UDP-4500-datagram, og når først deretter dette laget. Ankommende pakker kopieres til sokkelen mens de kommer inn fra ledningen, fortsatt kryptert, og det dekrypterte resultatet blir synlig senere når stakken leverer det lokalt eller videresender det.

Den rekkefølgen forklarer asymmetrien fullstendig. Det er ikke bevis om retning, policy eller applikasjonsatferd, og å behandle det som det sender folk til å jage et svar som hele tiden ble sendt riktig. Det er ett av få nettverksgåter der instrumentet, ikke nettverket, skaper anomalien.

Tilpass filteret til laget du mener

Et uttrykk som tcp port 443 velger en indre TCP-tilkobling. Utgående er den tilkoblingen allerede blitt ESP når sokkelen spørres, så filteret treffer ingenting. Hvis du vil telle beskyttet trafikk, filtrer på den ytre formen i stedet: protokoll 50 for rå ESP, eller UDP-port 4500 når NAT-traversering er i spill. Begge filtrene gir et pakketall som kan sammenlignes mellom de to partene, som vanligvis er grunnen til å telle i det hele tatt. Ingen av dem forteller om den indre forespørselen ble besvart.

Ikke behandle et UDP 4500-tall som et ESP-pakketall. IKE bruker også den porten til NAT-T keepalives og til den innkapslede utvekslingen, så tallet omfatter trafikk som ikke er dataene du ville måle. Den innledende IKE-utvekslingen på UDP 500 trenger sitt eget filter hvis det er spørsmålet. Et tall som blander kontrolltrafikk med data, gjør også ethvert båndbreddeanslag feil med en ukjent margin. Separate tellinger svarer på separate spørsmål.

Skriv ned filteret ved siden av spørsmålet det besvarer. «Hvor mye ESP forlot boksen» og «forlot nettforespørselen boksen» er forskjellige målinger med forskjellige filtre, og én fangst kan ikke avgjøre begge. Uten den noten vil to personer sammenligne tall som aldri telte det samme.

Observer før transformasjonen, ikke etter

Hvis du trenger å se utgående klartekst, flytt observasjonspunktet tidligere, før IPsec-utgangsbehandlingen. NFLOG gir deg en Netfilter-krok der en regel kan kopiere utvalgte pakker til en sokkel i brukerrommet, som tcpdump kan lese. strongSwans veiledning for trafikkdump dokumenterer denne tilnærmingen nettopp av denne grunnen.

Policytreffet begrenser regelen til trafikk som er i ferd med å gå inn i en tunnel. -m policy --pol ipsec --dir out er det som gjør regelen spesifikk i stedet for å logge hver pakke boksen sender. Les deretter loggruppen med en begrenset fangst: et lite antall snapshots og en størrelsesgrense hindrer at diagnosen blir et trafikkarkiv. En begrenset fangst er også lettere å gi til en gjennomleser uten å dra med irrelevant last. Bestem tallet før du begynner, ikke etter at du har sett hvor mye som kom.

iptables -I OUTPUT 1 -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5
tcpdump -ni nflog:5 -s 128 -c 20 'host 10.83.0.44 and tcp port 8443'

Velg kroken som passer til strømmen. OUTPUT dekker trafikk gatewayen genererer selv; transitt fra en LAN-klient går i stedet gjennom FORWARD-kjeden, og en regel på OUTPUT vil aldri se den. Adressen og porten ovenfor er plassholdere for et godkjent testmål.

Hva observasjonen beviser

NFLOG er et loggmål, ikke en akseptbeslutning. En pakke som dukker opp der, viser at den nådde kroken og samsvarte med regelen. Det viser ikke at et senere filter slapp den gjennom, at enheten sendte den, eller at motparten mottok noe.

En tom logg er like tvetydig. Kontroller reglens pakketeller, bekreft retningen, bekreft at strømmen faktisk samsvarte med en IPsec-policy, og bekreft målet. Bare en samsvarende teller på begge parter gjør en observasjon til en konklusjon. Sammenlign deretter sikkerhetsassosiasjonens tellere på begge parter for det samme kontrollerte forsøket, fordi SA-tellerne er den autoritative oversikten over hva som ble beskyttet og sendt.

En felle til: «klartekst» betyr i denne sammenhengen utenfor IPsec-krypteringslaget. En indre HTTPS-økt har fortsatt sin egen TLS. Å fange den dekapsulerte pakken dekrypterer ikke applikasjonens TLS, og å se lesbar HTTP der betyr at applikasjonen aldri brukte HTTPS.

Rydd opp og sammenlign begge ender

Fjern nøyaktig den regelen du satte inn, etter dens eier, så snart observasjonen er ferdig. Å la en loggingsregel stå igjen koster CPU på hver samsvarende pakke og skaper stille et datalagringsproblem. Slett ved å gjenta regelen med -D i stedet for å tømme en kjede du ikke eier.

iptables -D OUTPUT -d 10.83.0.44/32 -p tcp --dport 8443 -m policy --pol ipsec --dir out -j NFLOG --nflog-group 5

Hvis utrullingen bruker IPsec i brukerrommet, et XFRM-grensesnitt eller maskinvareoffload, flytter observasjonspunktene seg, og denne oppskriften gjelder kanskje ikke i det hele tatt. Med libipsec er det dokumenterte stedet for å observere indre trafikk TUN-enheten. Identifiser banen først, velg deretter punktet som svarer på spørsmålet, og forvent at de to retningene bare ser forskjellige ut når du ser på feil side av transformasjonen.