Kvifor tcpdump viser IPsec-klartekst berre i éi retning

Du køyrer tcpdump på den ytre grensesnittet til ein Linux IPsec-gateway og ser to ting samtidig: innkomande ESP-rammer og, rett etter dei, dei dekrypterte indre pakkane. Utgåande viser berre ESP. Den naturlege konklusjonen er at svar ikkje blir sende, eller at IPsec krypterer den eine retninga og gløymer den andre. Ingen av delane er sanne.

Det du ser på, er eit fangstpunkt. Kjernen omformar utgåande pakkar før sendebana til eininga overleverer dei til pakkesokkelen, så sokkelen ser aldri den indre forma på veg ut. Innkomande blir pakken først fanga som ESP, og den dekapsulerte kopien blir synleg når han kjem inn i stakken igjen. Same trafikk, to ulike observasjonsvindauge.

Fangstpunktet avgjer kva du ser

På eit vanleg grensesnitt sit ein AF_PACKET-sokkel nær eininglaget. Pakkar som forlèt verten, går først gjennom IPsec-utgangshandsaminga, som gjer eit indre TCP-segment om til eit ESP- eller UDP-4500-datagram, og når først deretter dette laget. Ankomande pakkar blir kopierte til sokkelen mens dei kjem inn frå leidninga, framleis krypterte, og det dekrypterte resultatet blir synleg seinare når stakken leverer det lokalt eller sender det vidare.

Den rekkjefølgja forklarer asymmetrien fullstendig. Det er ikkje bevis om retning, policy eller åtferd til programmet, og å handsame det som det sender folk til å jage eit svar som heile tida vart sendt riktig. Det er ei av få nettverksgåter der instrumentet, ikkje nettverket, skaper anomalien.

Tilpass filteret til laget du meiner

Eit uttrykk som tcp port 443 vel ein indre TCP-tilkopling. Utgåande er den tilkoplinga alt blitt ESP når sokkelen blir spurd, så filteret treff ingenting. Viss du vil telje verna trafikk, filtrer på den ytre forma i staden: protokoll 50 for rå ESP, eller UDP-port 4500 når NAT-traversering er i spel. Begge filtera gir eit pakketal som kan samanliknast mellom dei to partane, som vanlegvis er grunnen til å telje i det heile. Ingen av dei fortel om den indre førespurnaden fekk svar.

Ikkje handsam eit UDP 4500-tal som eit ESP-pakketal. IKE brukar også den porten til NAT-T keepalives og til den innkapsla utvekslinga, så talet omfattar trafikk som ikkje er dataa du ville måle. Den innleiande IKE-utvekslinga på UDP 500 treng sitt eige filter viss det er spørsmålet. Eit tal som blandar kontrolltrafikk med data, gjer også alle bandbreiddaanslag feil med ein ukjend margin. Separate teljingar svarar på separate spørsmål.

Skriv ned filteret ved sida av spørsmålet det svarar på. «Kor mykje ESP forlét boksen» og «forlét nettførespurnaden boksen» er ulike målingar med ulike filter, og éi fangst kan ikkje avgjere begge. Utan den notata vil to personar samanlikne tal som aldri telte det same.

Observer før transformasjonen, ikkje etter

Viss du treng å sjå utgåande klartekst, flytt observasjonspunktet tidlegare, før IPsec-utgangshandsaminga. NFLOG gir deg ein Netfilter-krok der ein regel kan kopiere utvalde pakkar til ein sokkel i brukarrommet, som tcpdump kan lese. strongSwan sin rettleiar for trafikkdump dokumenterer denne tilnærminga nettopp av denne grunnen.

Policytreffet avgrensar regelen til trafikk som er i ferd med å gå inn i ein tunnel. -m policy --pol ipsec --dir out er det som gjer regelen spesifikk i staden for å logge kvar pakke boksen sender. Les deretter loggruppa med ei avgrensa fangst: eit lite tal snapshots og ei storleiksgrense hindrar at diagnosen blir eit trafikkarkiv. Ei avgrensa fangst er også lettare å gi til ein gjennomlesar utan å dra med irrelevant last. Bestem talet før du byrjar, ikkje etter at du har sett kor mykje 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'

Vel kroken som passar til straumen. OUTPUT dekkjer trafikk gatewayen sjølv genererer; transitt frå ein LAN-klient går i staden gjennom FORWARD-kjeda, og ein regel på OUTPUT vil aldri sjå han. Adressa og porten ovanfor er plasshaldarar for eit godkjent testmål.

Kva observasjonen beviser

NFLOG er eit loggmål, ikkje ei akseptavgjerd. Ein pakke som dukkar opp der, viser at han nådde kroken og samsvarte med regelen. Det viser ikkje at eit seinare filter slapp han gjennom, at eininga sende han, eller at motparten tok imot noko.

Ein tom logg er like tvitydig. Kontroller pakketeljaren til regelen, stadfest retninga, stadfest at straumen faktisk samsvarte med ein IPsec-policy, og stadfest målet. Berre ein samsvarande teljar på begge partar gjer ein observasjon til ein konklusjon. Samanlikn deretter teljarane til tryggleiksassosiasjonen på begge partar for det same kontrollerte forsøket, fordi SA-teljarane er den autoritative oversikta over kva som vart verna og sendt.

Ei felle til: «klartekst» tyder her utanfor IPsec-krypteringslaget. Ei indre HTTPS-økt har framleis sin eigen TLS. Å fange den dekapsulerte pakken dekrypterer ikkje TLS-en til programmet, og å sjå leseleg HTTP der tyder på at programmet aldri brukte HTTPS.

Rydd opp og samanlikn begge endar

Fjern nøyaktig den regelen du sette inn, etter eigaren hans, så snart observasjonen er ferdig. Å la ein loggføringsregel stå att kostar CPU på kvar samsvarande pakke og skaper stille eit datalagringsproblem. Slett ved å gjenta regelen med -D i staden for å tømme ei kjede du ikkje eig.

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

Viss utrullinga brukar IPsec i brukarrommet, eit XFRM-grensesnitt eller maskinvareoffload, flyttar observasjonspunkta seg, og denne oppskrifta gjeld kanskje ikkje i det heile. Med libipsec er den dokumenterte staden for å observere indre trafikk TUN-eininga. Identifiser bana først, vel deretter punktet som svarar på spørsmålet, og vent at dei to retningane berre ser ulike ut når du ser på feil side av transformasjonen.