Waarom tcpdump IPsec-platte tekst maar in één richting toont

Je draait tcpdump op de buiteninterface van een Linux IPsec-gateway en ziet twee dingen tegelijk: inkomende ESP-frames en, direct daarna, de ontsleutelde binnenpakketten. Uitgaand verschijnt alleen ESP. De voor de hand liggende conclusie is dat antwoorden niet worden verstuurd, of dat IPsec de ene richting versleutelt en de andere vergeet. Geen van beide is waar.

Wat je ziet, is een opnamepunt. De kernel omvormt uitgaande pakketten voordat het verzendpad van het apparaat ze aan de packetsocket geeft, zodat de socket de binnenste vorm naar buiten nooit ziet. Inkomend wordt het pakket eerst als ESP opgevangen en de gedecapsuleerde kopie wordt zichtbaar wanneer het weer de stack binnenkomt. Hetzelfde verkeer, twee verschillende observatievensters.

Het opnamepunt bepaalt wat je ziet

Op een normale interface zit een AF_PACKET-socket dicht bij de apparaatlaag. Pakketten die de host verlaten, gaan eerst door de IPsec-uitvoerverwerking, die een binnenste TCP-segment omzet in een ESP- of UDP-4500-datagram, en bereiken pas daarna die laag. Aankomende pakketten worden naar de socket gekopieerd terwijl ze van de kabel komen, nog versleuteld, en het ontsleutelde resultaat wordt later zichtbaar wanneer de stack het lokaal aflevert of doorstuurt.

Die volgorde verklaart de asymmetrie volledig. Het is geen bewijs over richting, beleid of toepassingsgedrag, en het als zodanig behandelen stuurt mensen achter een antwoord aan dat al die tijd correct verzonden werd. Het is een van de weinige netwerkspuzzels waarbij het instrument, niet het netwerk, de anomalie veroorzaakt.

Laat het filter bij de laag passen die je bedoelt

Een uitdrukking zoals tcp port 443 selecteert een binnenste TCP-verbinding. Uitgaand is die verbinding al ESP geworden tegen de tijd dat de socket wordt geraadpleegd, dus het filter matcht niets. Als je beschermd verkeer wilt tellen, filter dan op de buitenste vorm: protocol 50 voor ruwe ESP, of UDP-poort 4500 wanneer NAT-traversal in het spel is. Beide filters leveren een pakketnummer op dat tussen de twee peers vergeleken kan worden, wat meestal de reden is om te tellen. Geen van beide vertelt je of het binnenverzoek beantwoord is.

Behandel een UDP 4500-telling niet als een ESP-pakkettelling. IKE gebruikt die poort ook voor NAT-T-keepalives en voor de ingekapselde uitwisseling, dus het getal bevat verkeer dat niet de gegevens zijn die je wilde meten. De eerste IKE-uitwisseling op UDP 500 heeft een eigen filter nodig als dat de vraag is. Een getal dat controleverkeer met gegevens mengt, maakt ook elke bandbreedteschatting fout met een onbekende marge. Aparte tellingen beantwoorden aparte vragen.

Schrijf het filter op naast de vraag die het beantwoordt. 'Hoeveel ESP heeft de doos verlaten' en 'heeft het webverzoek de doos verlaten' zijn verschillende metingen met verschillende filters, en één opname kan beide niet beslechten. Zonder die notitie vergelijken twee mensen getallen die nooit hetzelfde telden.

Observeer vóór de transformatie, niet erna

Als je uitgaande platte tekst wilt zien, verplaats het observatiepunt dan eerder, vóór de IPsec-uitvoerverwerking. NFLOG geeft je een Netfilter-hook waar een regel geselecteerde pakketten naar een socket in gebruikersruimte kan kopiëren, die tcpdump kan lezen. De traffic-dumpgids van strongSwan documenteert deze aanpak precies om die reden.

De beleidsmatch beperkt de regel tot verkeer dat op het punt staat een tunnel binnen te gaan. -m policy --pol ipsec --dir out is wat de regel specifiek maakt in plaats van elk pakket te loggen dat de doos verstuurt. Lees daarna de loggroep met een begrensde opname: een klein aantal snapshots en een groottelimiet voorkomen dat de diagnostiek een verkeersarchief wordt. Een begrensde opname is ook makkelijker aan een beoordelaar te geven zonder irrelevante lading mee te slepen. Bepaal het aantal voordat je begint, niet nadat je hebt gezien hoeveel er aankwam.

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 de hook die bij de stroom past. OUTPUT dekt verkeer dat de gateway zelf genereert; transit van een LAN-client loopt in plaats daarvan door de FORWARD-keten, en een regel op OUTPUT zal die nooit zien. Het adres en de poort hierboven zijn plaatsaanduidingen voor een goedgekeurd testdoel.

Wat de observatie bewijst

NFLOG is een logdoel, geen acceptatiebeslissing. Een pakket dat daar verschijnt, laat zien dat het de hook bereikte en aan de regel voldeed. Het laat niet zien dat een later filter het toestond, dat het apparaat het verzond of dat de peer iets ontving.

Een leeg log is even dubbelzinnig. Controleer de pakketteller van de regel, bevestig de richting, bevestig dat de stroom echt aan een IPsec-beleid voldeed en bevestig de bestemming. Alleen een overeenkomende teller bij beide peers maakt van een observatie een conclusie. Vergelijk daarna de tellers van de beveiligingsassociatie bij beide peers voor dezelfde gecontroleerde poging, want de SA-tellers zijn het gezaghebbende verslag van wat beschermd en verzonden is.

Nog een valkuil: 'platte tekst' betekent hier buiten de IPsec-versleutelingslaag. Een binnenste HTTPS-sessie heeft nog steeds zijn eigen TLS. Het opvangen van het gedecapsuleerde pakket ontsleutelt de TLS van de toepassing niet, en leesbare HTTP daar zien betekent dat de toepassing nooit HTTPS gebruikte.

Ruim op en vergelijk beide uiteinden

Verwijder de exacte regel die je hebt ingevoegd, door zijn eigenaar, zodra de observatie klaar is. Een logregel laten staan kost CPU bij elk overeenkomend pakket en creëert stil een probleem met gegevensbewaring. Verwijder door de regel te herhalen met -D in plaats van een keten te legen die niet van jou is.

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

Als de uitrol IPsec in gebruikersruimte, een XFRM-interface of hardware-offload gebruikt, verschuiven de observatiepunten en geldt dit recept misschien helemaal niet. Bij libipsec is de gedocumenteerde plek om binnenverkeer te observeren het TUN-apparaat. Identificeer eerst het pad, kies dan het punt dat de vraag beantwoordt, en verwacht dat de twee richtingen er alleen anders uitzien als je naar de verkeerde kant van de transformatie kijkt.