Waarom tcpdump IPsec-platte teks net in een rigting wys

Jy voer tcpdump uit op die buitekoppelvlak van ’n Linux-IPsec-hek en sien twee dinge gelyk: inkomende ESP-rame en, direk daarna, die ontsyferde binne-pakkette. Uitgaande verskyn net ESP. Die natuurlike gevolgtrekking is dat antwoorde nie gestuur word nie, of dat IPsec een rigting versyfer en die ander vergeet. Nie een is waar nie.

Wat jy sien, is ’n vasleggingspunt. Die kernel verander uitgaande pakkette voordat die toestel se stuurpad hulle aan die pakketsoket oorhandig, so die soket sien nooit die binne-vorm wat uitgaan nie. Inkomend word die pakket eers as ESP vasgevang en die gedekapsuleerde kopie word sigbaar wanneer dit weer die stapel binnegaan. Dieselfde verkeer, twee verskillende waarnemingsvensters.

Die vasleggingspunt bepaal wat jy sien

Op ’n normale koppelvlak sit ’n AF_PACKET-soket naby die toestellaag. Pakkette wat die gasheer verlaat, gaan eerste deur IPsec-uitvoerverwerking, wat ’n binne-TCP-segment in ’n ESP- of UDP-4500-datagram omskep, en bereik eers daarna daardie laag. Pakkette wat aankom, word na die soket gekopieer soos hulle van die draad af kom, nog versyfer, en die ontsyferde resultaat word later sigbaar wanneer die stapel dit plaaslik aflewer of aanstuur.

Daardie volgorde verduidelik die asimmetrie heeltemal. Dit is nie bewyse oor rigting, beleid of toepassingsgedrag nie, en om dit so te behandel, laat mense ’n antwoord jaag wat heeltemal reg gestuur is. Dit is een van die min netwerkraaisels waar die instrument, nie die netwerk nie, die afwyking skep.

Pas die filter by die laag wat jy bedoel

’n Uitdrukking soos tcp port 443 kies ’n binne-TCP-verbinding. Uitgaande het daardie verbinding reeds ESP geword teen die tyd dat die soket geraadpleeg word, so die filter pas niks. As jy beskermde verkeer wil tel, filter eerder op die buitevorm: protokol 50 vir rou ESP, of UDP-poort 4500 wanneer NAT-traversal in die spel is. Beide filters lewer ’n pakkettelling wat tussen die twee eweknieë vergelyk kan word, wat gewoonlik die rede is om hoegenaamd te tel. Nie een van hulle sê of die binneversoek beantwoord is nie.

Moenie ’n UDP 4500-telling as ’n ESP-pakkettelling beskou nie. IKE gebruik ook daardie poort vir NAT-T-lewendhouers en vir die gekapsuleerde uitruiling, so die getal sluit verkeer in wat nie die data is wat jy bedoel het om te meet nie. Die aanvanklike IKE-uitruiling op UDP 500 het sy eie filter nodig as dit die vraag is. ’n Getal wat beheerverkeer met data meng, maak ook enige bandbreedteskatting met ’n onbekende marge verkeerd. Afsonderlike tellings beantwoord afsonderlike vrae.

Skryf die filter neer langs die vraag wat dit beantwoord. “Hoeveel ESP het die boks verlaat” en “het die webversoek die boks verlaat” is verskillende metings met verskillende filters, en een vaslegging kan nie albei besleg nie. Sonder daardie nota sal twee mense getalle vergelyk wat nooit dieselfde ding getel het nie.

Kyk voor die transformasie, nie daarna nie

As jy uitgaande platte teks moet sien, skuif die waarnemingspunt vroeër, voor die IPsec-uitvoerverwerking. NFLOG gee jou ’n Netfilter-haak waar ’n reël geselekteerde pakkette na ’n gebruikerspasoket kan kopieer, wat tcpdump kan lees. strongSwan se verkeersdump-gids dokumenteer hierdie benadering juis om hierdie rede.

Die beleidsooreenstemming beperk die reël tot verkeer wat op die punt staan om ’n tonnel binne te gaan. -m policy --pol ipsec --dir out is wat die reël spesifiek maak in plaas daarvan om elke pakket wat die boks stuur, te log. Lees dan die loggroep met ’n begrensde vaslegging: ’n klein opnamegetal en ’n groottelimiet verhoed dat die diagnose ’n verkeersargief word. ’n Begrensde vaslegging is ook makliker om aan ’n keurder te gee sonder om onverwante loonvrag saam te sleep. Besluit die getal voordat jy begin, nie nadat jy sien hoeveel aangekom het nie.

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'

Kies die haak om by die stroom te pas. OUTPUT dek verkeer wat die hek self genereer; deurgang van ’n LAN-kliënt gaan eerder deur die FORWARD-ketting, en ’n reël op OUTPUT sal dit nooit sien nie. Die adres en poort hierbo is plekhouers vir ’n goedgekeurde toetsbestemming.

Wat die waarneming bewys

NFLOG is ’n logteiken, nie ’n aanvaardingsbeslissing nie. ’n Pakket wat daar verskyn, wys dat dit die haak bereik en die reël gepas het. Dit wys nie dat ’n latere filter dit toegelaat het, dat die toestel dit versend het, of dat die eweknie iets ontvang het nie.

’n Leë log is ewe dubbelsinnig. Kontroleer die reël se pakketteller, bevestig die rigting, bevestig dat die stroom werklik by ’n IPsec-beleid gepas het, en bevestig die bestemming. Net ’n ooreenstemmende teller by beide eweknieë verander ’n waarneming in ’n gevolgtrekking. Vergelyk dan die sekuriteitsassosiasie-tellers by beide eweknieë vir dieselfde beheerde poging, want die SA-tellers is die gesaghebbende rekord van wat beskerm en gestuur is.

Nog ’n valstrik: “platte teks” beteken in hierdie konteks buite die IPsec-versyferingslaag. ’n Binne-HTTPS-sessie het steeds sy eie TLS. Die vasvang van die gedekapsuleerde pakket ontsyfer nie die toepassing se TLS nie, en as jy leesbare HTTP daar sien, beteken dit die toepassing het nooit HTTPS gebruik nie.

Ruim op en vergelyk beide kante

Verwyder die presiese reël wat jy ingevoeg het, deur sy eienaar, sodra die waarneming klaar is. Om ’n logreël in plek te laat, kos CPU op elke passende pakket en skep stilweg ’n databewaringsprobleem. Skrap deur die reël te herhaal met -D eerder as om ’n ketting te spoel wat nie aan jou behoort nie.

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

As die ontplooiing gebruikerspas-IPsec, ’n XFRM-koppelvlak of hardeware-aflewering gebruik, skuif die waarnemingspunte en hierdie resep pas dalk glad nie. Met libipsec is die gedokumenteerde plek om binneverkeer te dophou die TUN-toestel. Identifiseer eers die pad, kies dan die punt wat die vraag beantwoord, en verwag dat die twee rigtings net anders lyk wanneer jy na die verkeerde kant van die transformasie kyk.