Proč tcpdump ukazuje IPsec otevřený text jen jedním směrem

Spustíte tcpdump na vnějším rozhraní linuxové brány IPsec a uvidíte dvě věci najednou: příchozí rámce ESP a hned za nimi dešifrované vnitřní pakety. V odchozím směru se objeví jen ESP. Přirozený závěr je, že se odpovědi neposílají, nebo že IPsec šifruje jeden směr a zapomíná na druhý. Ani jedno není pravda.

To, co vidíte, je místo zachycení. Jádro transformuje odchozí pakety dříve, než je vysílací cesta zařízení předá paketovému socketu, takže socket nikdy nevidí vnitřní podobu při odchodu. Na vstupu se paket nejprve zachytí jako ESP a dekapsulovaná kopie je vidět, když znovu vstoupí do zásobníku. Stejný provoz, dvě různá pozorovací okna.

Místo zachycení rozhoduje o tom, co vidíte

Na běžném rozhraní sedí socket AF_PACKET blízko vrstvy zařízení. Pakety opouštějící hostitele nejprve projdou výstupním zpracováním IPsec, které přemění vnitřní TCP segment na datagram ESP nebo UDP-4500, a teprve potom dosáhnou této vrstvy. Příchozí pakety se kopírují do socketu, jak přicházejí z drátu, stále zašifrované, a dešifrovaný výsledek je vidět později, když jej zásobník doručí lokálně nebo přepošle.

Toto pořadí asymetrii zcela vysvětluje. Není to důkaz o směru, politice ani chování aplikace, a kdo to tak bere, honí odpověď, která byla celou dobu odeslána správně. Je to jedna z mála síťových hádanek, kde anomálii vytváří nástroj, nikoli síť.

Sladěte filtr s vrstvou, kterou máte na mysli

Výraz jako tcp port 443 vybírá vnitřní TCP spojení. V odchozím směru se toto spojení už stalo ESP v době, kdy se socket dotazuje, takže filtr nic nezachytí. Chcete-li počítat chráněný provoz, filtrujte podle vnější podoby: protokol 50 pro surové ESP, nebo port UDP 4500, když se uplatňuje NAT traversal. Oba filtry dávají počet paketů, který lze porovnat mezi oběma peery, což je obvykle důvod počítání. Ani jeden z nich neříká, zda vnitřní požadavek dostal odpověď.

Nepovažujte počet UDP 4500 za počet paketů ESP. IKE tento port používá také pro keepalive zprávy NAT-T a pro zapouzdřenou výměnu, takže číslo zahrnuje provoz, který není data, jež jste chtěli měřit. Počáteční výměna IKE na UDP 500 potřebuje vlastní filtr, pokud je otázkou právě to. Číslo, které míchá řídicí provoz s daty, také dělá každý odhad šířky pásma chybným o neznámou míru. Oddělené počty odpovídají na oddělené otázky.

Zapište filtr vedle otázky, na kterou odpovídá. „Kolik ESP opustilo stroj“ a „opustil webový požadavek stroj“ jsou různá měření s různými filtry a jeden záznam nemůže vyřešit obojí. Bez této poznámky budou dva lidé porovnávat čísla, která nikdy nepočítala totéž.

Sledujte před transformací, ne po ní

Pokud potřebujete vidět odchozí otevřený text, přesuňte pozorovací bod dříve, před výstupní zpracování IPsec. NFLOG vám dává háček Netfilter, kde pravidlo může kopírovat vybrané pakety do socketu v uživatelském prostoru, který tcpdump umí číst. Průvodce strongSwan pro výpis provozu dokumentuje tento postup právě z tohoto důvodu.

Shoda s politikou omezuje pravidlo na provoz, který se chystá vstoupit do tunelu. -m policy --pol ipsec --dir out je to, co pravidlo činí konkrétním místo logování každého paketu, který stroj odešle. Poté čtěte skupinu protokolu s omezeným zachycením: malý počet snímků a limit velikosti brání tomu, aby se diagnostika stala archivem provozu. Omezené zachycení se také snáze předává recenzentovi, aniž byste s sebou táhli nesouvisející obsah. Rozhodněte počet před začátkem, ne poté, co uvidíte, kolik přišlo.

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'

Vyberte háček podle toku. OUTPUT pokrývá provoz, který brána vytváří sama; tranzit od klienta LAN prochází místo toho řetězcem FORWARD a pravidlo na OUTPUT jej nikdy neuvidí. Adresa a port výše jsou zástupné hodnoty pro schválený testovací cíl.

Co pozorování dokazuje

NFLOG je cíl logování, ne rozhodnutí o přijetí. Paket, který se tam objeví, ukazuje, že dosáhl háčku a shodoval se s pravidlem. Neukazuje, že jej pozdější filtr povolil, že jej zařízení přeneslo, nebo že peer něco přijal.

Prázdný protokol je stejně nejednoznačný. Zkontrolujte čítač paketů pravidla, potvrďte směr, potvrďte, že tok skutečně odpovídal politice IPsec, a potvrďte cíl. Jen shodný čítač na obou peerech mění pozorování v závěr. Poté porovnejte čítače bezpečnostní asociace na obou peerech pro stejný kontrolovaný pokus, protože čítače SA jsou autoritativním záznamem o tom, co bylo chráněno a odesláno.

Ještě jedna past: „otevřený text“ zde znamená mimo šifrovací vrstvu IPsec. Vnitřní relace HTTPS má stále vlastní TLS. Zachycení dekapsulovaného paketu nedešifruje TLS aplikace, a pokud tam vidíte čitelný HTTP, znamená to, že aplikace HTTPS vůbec nepoužívala.

Ukliďte a porovnejte oba konce

Odstraňte přesně to pravidlo, které jste vložili, podle jeho vlastníka, jakmile pozorování skončí. Ponechané logovací pravidlo stojí CPU u každého odpovídajícího paketu a tiše vytváří problém s uchováváním dat. Smažte je zopakováním pravidla s -D, místo abyste proplachovali řetězec, který nevlastníte.

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

Pokud nasazení používá IPsec v uživatelském prostoru, rozhraní XFRM nebo hardwarové odlehčení, pozorovací body se posouvají a tento recept nemusí vůbec platit. U libipsec je dokumentovaným místem pro sledování vnitřního provozu zařízení TUN. Nejprve určete cestu, poté vyberte bod, který odpovídá na otázku, a očekávejte, že oba směry budou vypadat rozdílně jen tehdy, když se díváte na špatnou stranu transformace.