Zašto tcpdump prikazuje IPsec otvoreni tekst samo u jednom smjeru

Pokrećete tcpdump na vanjskom interfejsu Linux IPsec gatewaya i vidite dvije stvari odjednom: dolazne ESP okvire i, odmah nakon njih, dešifrirane unutrašnje pakete. U odlaznom smjeru pojavljuje se samo ESP. Prirodan zaključak je da se odgovori ne šalju ili da IPsec šifrira jedan smjer i zaboravlja drugi. Nijedno nije tačno.

Ono što gledate jeste točka snimanja. Kernel transformira odlazne pakete prije nego što ih transmitni put uređaja preda paketnom socketu, pa socket nikada ne vidi unutrašnji oblik koji izlazi. Na ulazu se paket prvo snima kao ESP, a dekapsulirana kopija postaje vidljiva kada ponovo uđe u stack. Isti saobraćaj, dva različita prozora posmatranja.

Točka snimanja odlučuje šta vidite

Na normalnom interfejsu AF_PACKET socket nalazi se blizu sloja uređaja. Paketi koji napuštaju host prvo prolaze kroz IPsec izlaznu obradu, koja unutrašnji TCP segment pretvara u ESP ili UDP-4500 datagram, i tek onda stižu do tog sloja. Dolazni paketi kopiraju se u socket dok dolaze s žice, još šifrirani, a dešifrirani rezultat postaje vidljiv kasnije kada ga stack dostavi lokalno ili proslijedi dalje.

Taj redoslijed u potpunosti objašnjava asimetriju. To nije dokaz o smjeru, politici ili ponašanju aplikacije, i ako se tako tretira, ljude šalje u potjeru za odgovorom koji je cijelo vrijeme bio ispravno poslan. To je jedna od rijetkih mrežnih zagonetki u kojima anomaliju stvara instrument, a ne mreža.

Uskladite filter sa slojem koji mislite

Izraz poput tcp port 443 odabire unutrašnju TCP vezu. U odlaznom smjeru ta veza je već postala ESP dok se socket pita, pa filter ne pronalazi ništa. Ako želite brojati zaštićeni saobraćaj, filtrirajte po vanjskom obliku: protokol 50 za sirovi ESP ili UDP port 4500 kada je u igri NAT traversal. Oba filtera daju broj paketa koji se može uporediti između dva peera, što je obično i razlog brojanja. Nijedan od njih ne kaže je li unutrašnji zahtjev dobio odgovor.

Ne tretirajte broj UDP 4500 kao broj ESP paketa. IKE također koristi taj port za NAT-T keepalive poruke i za enkapsuliranu razmjenu, pa broj uključuje saobraćaj koji nije podatak koji ste htjeli mjeriti. Početna IKE razmjena na UDP 500 traži vlastiti filter ako je to pitanje. Broj koji miješa kontrolni saobraćaj s podacima također čini svaku procjenu propusnog opsega pogrešnom za nepoznatu marginu. Odvojeni brojevi odgovaraju na odvojena pitanja.

Zapišite filter pored pitanja na koje odgovara. „Koliko je ESP izašlo iz kutije“ i „je li web zahtjev izašao iz kutije“ različita su mjerenja s različitim filterima, a jedno snimanje ne može riješiti oba. Bez te zabilješke dvije osobe će upoređivati brojeve koji nikada nisu brojali istu stvar.

Posmatrajte prije transformacije, ne poslije

Ako trebate vidjeti odlazni otvoreni tekst, pomjerite točku posmatranja ranije, prije IPsec izlazne obrade. NFLOG vam daje Netfilter hook gdje pravilo može kopirati odabrane pakete u socket korisničkog prostora, koji tcpdump može čitati. strongSwanov vodič za dump saobraćaja dokumentira taj pristup upravo iz tog razloga.

Podudaranje s politikom ograničava pravilo na saobraćaj koji tek treba ući u tunel. -m policy --pol ipsec --dir out je ono što pravilo čini konkretnim umjesto da se loguje svaki paket koji kutija pošalje. Zatim čitajte log grupu s ograničenim snimanjem: mali broj snimaka i ograničenje veličine sprječavaju da dijagnostika postane arhiva saobraćaja. Ograničeno snimanje je i lakše predati recenzentu bez vučenja nepovezanog tereta. Odlučite broj prije nego što počnete, a ne nakon što vidite koliko je stiglo.

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'

Odaberite hook koji odgovara toku. OUTPUT pokriva saobraćaj koji gateway sam generira; tranzit od LAN klijenta prolazi kroz lanac FORWARD, a pravilo na OUTPUT ga nikada neće vidjeti. Adresa i port iznad su zamjenske vrijednosti za odobrenu testnu destinaciju.

Šta posmatranje dokazuje

NFLOG je odredište za logovanje, a ne odluka o prihvatanju. Paket koji se tamo pojavi pokazuje da je stigao do hooka i da se podudara s pravilom. Ne pokazuje da ga je kasniji filter propustio, da ga je uređaj prenio ili da je peer nešto primio.

Prazan log je jednako dvosmislen. Provjerite brojač paketa pravila, potvrdite smjer, potvrdite da se tok zaista podudarao s IPsec politikom i potvrdite destinaciju. Samo podudarajući brojač na oba peera pretvara posmatranje u zaključak. Zatim uporedite brojače sigurnosne asocijacije na oba peera za isti kontrolirani pokušaj, jer su SA brojači mjerodavni zapis o tome šta je bilo zaštićeno i poslano.

Još jedna zamka: „otvoreni tekst“ u ovom kontekstu znači izvan IPsec sloja šifriranja. Unutrašnja HTTPS sesija i dalje ima vlastiti TLS. Snimanje dekapsuliranog paketa ne dešifrira TLS aplikacije, a ako se tamo vidi čitljiv HTTP, to znači da aplikacija nikada nije koristila HTTPS.

Počistite i uporedite oba kraja

Uklonite tačno ono pravilo koje ste ubacili, po njegovom vlasniku, čim posmatranje završi. Ostavljeno pravilo za logovanje troši CPU na svaki odgovarajući paket i tiho stvara problem zadržavanja podataka. Izbrišite ga ponavljanjem pravila s -D umjesto ispiranjem lanca koji ne posjedujete.

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

Ako implementacija koristi IPsec u korisničkom prostoru, XFRM interfejs ili hardverski offload, točke posmatranja se pomjeraju i ovaj recept možda uopće ne važi. S libipsec, dokumentirano mjesto za posmatranje unutrašnjeg saobraćaja je TUN uređaj. Prvo identificirajte put, zatim odaberite točku koja odgovara na pitanje, i očekujte da će dva smjera izgledati različito samo kada gledate pogrešnu stranu transformacije.