Hvorfor tcpdump viser IPsec-klartekst i kun én retning

Du kører tcpdump på den ydre grænseflade på en Linux IPsec-gateway og ser to ting på én gang: indgående ESP-rammer og, lige efter dem, de dekrypterede indre pakker. Udgående vises kun ESP. Den naturlige konklusion er, at svar ikke sendes, eller at IPsec krypterer den ene retning og glemmer den anden. Ingen af delene er sande.

Det, du ser på, er et optagelsespunkt. Kernen omdanner udgående pakker, før enhedens sendesti giver dem til pakke-socketen, så socketen ser aldrig den indre form på vej ud. Indgående fanges pakken først som ESP, og den dekapsulerede kopi bliver synlig, når den igen kommer ind i stakken. Samme trafik, to forskellige observationsvinduer.

Optagelsespunktet afgør, hvad du ser

På en normal grænseflade sidder en AF_PACKET-socket tæt på enhedslaget. Pakker, der forlader værten, går først gennem IPsec-udgangsbehandlingen, som omdanner et indre TCP-segment til et ESP- eller UDP-4500-datagram, og når først derefter dette lag. Ankommende pakker kopieres til socketen, når de kommer ind fra ledningen, stadig krypterede, og det dekrypterede resultat bliver synligt senere, når stakken leverer det lokalt eller videresender det.

Den rækkefølge forklarer asymmetrien fuldstændigt. Det er ikke bevis om retning, politik eller applikationsadfærd, og når man behandler det som sådant, sender man folk efter et svar, der hele tiden blev sendt korrekt. Det er et af de få netværksproblemer, hvor instrumentet, ikke netværket, skaber anomalien.

Tilpas filteret til det lag, du mener

Et udtryk som tcp port 443 vælger en indre TCP-forbindelse. Udgående er den forbindelse allerede blevet ESP, når socketen spørges, så filteret matcher intet. Hvis du vil tælle beskyttet trafik, så filtrer på den ydre form i stedet: protokol 50 for rå ESP eller UDP-port 4500, når NAT-traversal er i spil. Begge filtre giver et pakketal, der kan sammenlignes mellem de to parter, hvilket normalt er grunden til at tælle. Ingen af dem fortæller, om den indre anmodning blev besvaret.

Behandl ikke et UDP 4500-tal som et ESP-pakketal. IKE bruger også den port til NAT-T keepalives og til den indkapslede udveksling, så tallet omfatter trafik, der ikke er de data, du ville måle. Den indledende IKE-udveksling på UDP 500 kræver sit eget filter, hvis det er spørgsmålet. Et tal, der blander kontroltrafik med data, gør også ethvert båndbreddeestimat forkert med en ukendt margin. Adskilte tal besvarer adskilte spørgsmål.

Skriv filteret ned ved siden af det spørgsmål, det besvarer. »Hvor meget ESP forlod boksen« og »forlod webanmodningen boksen« er forskellige målinger med forskellige filtre, og ét optag kan ikke afgøre begge. Uden den note vil to personer sammenligne tal, der aldrig talte det samme.

Overvåg før omdannelsen, ikke efter

Hvis du skal se udgående klartekst, flyt observationspunktet tidligere, før IPsec-udgangsbehandlingen. NFLOG giver dig et Netfilter-krog, hvor en regel kan kopiere udvalgte pakker til en socket i brugerniveau, som tcpdump kan læse. strongSwans guide til trafikdump dokumenterer netop denne tilgang af netop den grund.

Politikmatchningen begrænser reglen til trafik, der er ved at gå ind i en tunnel. -m policy --pol ipsec --dir out er det, der gør reglen specifik i stedet for at logge hver pakke, boksen sender. Læs derefter loggruppen med et afgrænset optag: et lille antal snapshots og en størrelsesgrænse forhindrer, at diagnosticeringen bliver et trafikarkiv. Et afgrænset optag er også lettere at give til en bedømmer uden at slæbe irrelevant last med. Beslut antallet, før du starter, ikke efter du har set, hvor meget der ankom.

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'

Vælg kroppen, så den passer til strømmen. OUTPUT dækker trafik, som gatewayen selv genererer; transit fra en LAN-klient går i stedet gennem FORWARD-kæden, og en regel på OUTPUT ser den aldrig. Adressen og porten ovenfor er pladsholdere for en godkendt testdestination.

Hvad observationen beviser

NFLOG er et logmål, ikke en acceptbeslutning. En pakke, der vises der, viser, at den nåede kroppen og matchede reglen. Det viser ikke, at et senere filter tillod den, at enheden sendte den, eller at modparten modtog noget.

En tom log er lige så tvetydig. Kontroller reglens pakketæller, bekræft retningen, bekræft at strømmen faktisk matchede en IPsec-politik, og bekræft destinationen. Kun en matchende tæller på begge parter gør en observation til en konklusion. Sammenlign derefter sikkerhedsassociationens tællere på begge parter for det samme kontrollerede forsøg, fordi SA-tællerne er den autoritative registrering af, hvad der blev beskyttet og sendt.

En fælde mere: »klartekst« betyder i denne sammenhæng uden for IPsec-krypteringslaget. En indre HTTPS-session har stadig sin egen TLS. Optagelse af den dekapsulerede pakke dekrypterer ikke applikationens TLS, og hvis man kan læse HTTP der, betyder det, at applikationen aldrig brugte HTTPS.

Ryd op, og sammenlign begge ender

Fjern den præcise regel, du indsatte, efter dens ejer, så snart observationen er færdig. At lade en logregel blive stående koster CPU på hver matchende pakke og skaber stille et datalagringsproblem. Slet ved at gentage reglen med -D i stedet for at skylle en kæde, du ikke ejer.

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 udrulningen bruger IPsec i brugerniveau, en XFRM-grænseflade eller hardware-offload, flytter observationspunkterne sig, og denne opskrift gælder måske slet ikke. Med libipsec er det dokumenterede sted at overvåge indre trafik TUN-enheden. Identificer først stien, vælg derefter det punkt, der besvarer spørgsmålet, og forvent, at de to retninger kun ser forskellige ud, når du kigger på den forkerte side af omdannelsen.