Prečo tcpdump zobrazuje otvorený text IPsec iba jedným smerom

Spustíte tcpdump na vonkajšom rozhraní linuxovej brány IPsec a uvidíte dve veci naraz: prichádzajúce rámce ESP a hneď za nimi dešifrované vnútorné pakety. V odchádzajúcom smere sa objaví iba ESP. Prirodzený záver je, že odpovede sa neposielajú, alebo že IPsec šifruje jeden smer a zabúda na druhý. Ani jedno nie je pravda.

To, čo vidíte, je miesto zachytenia. Jadro transformuje odchádzajúce pakety skôr, než ich vysielacia cesta zariadenia odovzdá paketovému socketu, takže socket nikdy nevidí vnútornú podobu pri odchode. Na vstupe sa paket najprv zachytí ako ESP a dekapsulovaná kópia je viditeľná, keď znova vstúpi do zásobníka. Rovnaká prevádzka, dve rôzne pozorovacie okná.

Miesto zachytenia rozhoduje o tom, čo vidíte

Na bežnom rozhraní sedí socket AF_PACKET blízko vrstvy zariadenia. Pakety opúšťajúce hostiteľa prechádzajú najprv výstupným spracovaním IPsec, ktoré zmení vnútorný segment TCP na datagram ESP alebo UDP-4500, a až potom dosiahnu túto vrstvu. Prichádzajúce pakety sa kopírujú do socketu, ako prichádzajú z drôtu, ešte zašifrované, a dešifrovaný výsledok je viditeľný neskôr, keď ho zásobník doručí lokálne alebo prepošle.

Toto poradie asymetriu úplne vysvetľuje. Nie je to dôkaz o smere, politike ani správaní aplikácie, a kto to tak berie, naháňa odpoveď, ktorá bola celý čas odosielaná správne. Je to jedna z mála sieťových hádaniek, kde anomáliu vytvára nástroj, nie sieť.

Zlaďte filter s vrstvou, ktorú máte na mysli

Výraz ako tcp port 443 vyberá vnútorné TCP spojenie. V odchádzajúcom smere sa toto spojenie už stalo ESP v čase, keď sa socket pýta, takže filter nič nezachytí. Ak chcete počítať chránenú prevádzku, filtrujte podľa vonkajšej podoby: protokol 50 pre surové ESP alebo port UDP 4500, keď sa uplatňuje prechod NAT. Oba filtre dávajú počet paketov, ktorý možno porovnať medzi oboma stranami, čo je zvyčajne dôvod počítania. Ani jeden z nich nehovorí, či vnútorná požiadavka dostala odpoveď.

Nepovažujte počet UDP 4500 za počet paketov ESP. IKE používa tento port aj pre správy udržiavania NAT-T a pre zapuzdrenú výmenu, takže číslo zahŕňa prevádzku, ktorá nie je údajmi, ktoré ste chceli merať. Počiatočná výmena IKE na UDP 500 potrebuje vlastný filter, ak je otázkou práve to. Číslo, ktoré mieša riadiacu prevádzku s údajmi, robí aj každý odhad šírky pásma nesprávnym o neznámu mieru. Oddelené počty odpovedajú na oddelené otázky.

Zapíšte filter vedľa otázky, na ktorú odpovedá. „Koľko ESP opustilo stroj“ a „opustila webová požiadavka stroj“ sú rôzne merania s rôznymi filtrami a jeden záznam nemôže vyriešiť oboje. Bez tejto poznámky budú dvaja ľudia porovnávať čísla, ktoré nikdy nepočítali to isté.

Sledujte pred transformáciou, nie po nej

Ak potrebujete vidieť odchádzajúci otvorený text, presuňte pozorovací bod skôr, pred výstupné spracovanie IPsec. NFLOG vám dáva háčik Netfilter, kde pravidlo môže kopírovať vybrané pakety do socketu v používateľskom priestore, ktorý tcpdump vie čítať. Príručka strongSwan pre výpis prevádzky dokumentuje tento postup práve z tohto dôvodu.

Zhoda s politikou obmedzuje pravidlo na prevádzku, ktorá sa chystá vstúpiť do tunela. -m policy --pol ipsec --dir out je to, čo robí pravidlo konkrétnym namiesto logovania každého paketu, ktorý stroj odošle. Potom čítajte skupinu protokolu s obmedzeným zachytením: malý počet snímok a limit veľkosti bránia tomu, aby sa diagnostika stala archívom prevádzky. Obmedzené zachytenie sa tiež ľahšie odovzdáva recenzentovi bez ťahania nesúvisiaceho obsahu. Rozhodnite počet pred začiatkom, nie po tom, čo uvidíte, koľko priš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áčik podľa toku. OUTPUT pokrýva prevádzku, ktorú generuje samotná brána; tranzit od klienta LAN prechádza namiesto toho reťazcom FORWARD a pravidlo na OUTPUT ho nikdy neuvidí. Adresa a port vyššie sú zástupné hodnoty pre schválený testovací cieľ.

Čo pozorovanie dokazuje

NFLOG je cieľ logovania, nie rozhodnutie o prijatí. Paket, ktorý sa tam objaví, ukazuje, že dosiahol háčik a zhodoval sa s pravidlom. Neukazuje, že ho neskorší filter povolil, že ho zariadenie prenieslo alebo že druhá strana niečo prijala.

Prázdny protokol je rovnako nejednoznačný. Skontrolujte počítadlo paketov pravidla, potvrďte smer, potvrďte, že tok skutočne zodpovedal politike IPsec, a potvrďte cieľ. Iba zhodné počítadlo na oboch stranách mení pozorovanie na záver. Potom porovnajte počítadlá bezpečnostnej asociácie na oboch stranách pre ten istý kontrolovaný pokus, pretože počítadlá SA sú autoritatívnym záznamom o tom, čo bolo chránené a odoslané.

Ešte jedna pasca: „otvorený text“ tu znamená mimo šifrovacej vrstvy IPsec. Vnútorná relácia HTTPS má stále vlastný TLS. Zachytenie dekapsulovaného paketu nedešifruje TLS aplikácie, a ak tam vidíte čitateľný HTTP, znamená to, že aplikácia HTTPS vôbec nepoužívala.

Upratajte a porovnajte oba konce

Odstráňte presne to pravidlo, ktoré ste vložili, podľa jeho vlastníka, hneď ako pozorovanie skončí. Ponechané logovacie pravidlo stojí CPU pri každom zodpovedajúcom pakete a ticho vytvára problém s uchovávaním údajov. Vymažte ho zopakovaním pravidla s -D, namiesto preplachovania reťazca, ktorý 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

Ak nasadenie používa IPsec v používateľskom priestore, rozhranie XFRM alebo hardvérové odľahčenie, pozorovacie body sa posúvajú a tento recept nemusí vôbec platiť. Pri libipsec je dokumentovaným miestom na sledovanie vnútornej prevádzky zariadenie TUN. Najprv určte cestu, potom vyberte bod, ktorý odpovedá na otázku, a očakávajte, že oba smery budú vyzerať rozdielne len vtedy, keď sa pozeráte na nesprávnu stranu transformácie.