Miért csak egy irányban mutatja a tcpdump az IPsec nyílt szövegét

A Linux IPsec-átjáró külső interfészén futtat tcpdumpot, és egyszerre két dolgot lát: bejövő ESP-kereteket, majd közvetlenül utánuk a visszafejtett belső csomagokat. Kifelé csak ESP jelenik meg. A természetes következtetés az, hogy a válaszok nem mennek ki, vagy hogy az IPsec az egyik irányt titkosítja, a másikat pedig elfelejti. Egyik sem igaz.

Amit lát, az egy rögzítési pont. A kernel átalakítja a kimenő csomagokat, mielőtt az eszköz továbbítási útja átadná őket a csomagszocketnek, így a szocket soha nem látja a kimenő belső formát. Bemenetkor a csomag először ESP-ként kerül rögzítésre, és a dekapszulált másolat akkor válik láthatóvá, amikor újra belép a verembe. Ugyanaz a forgalom, két különböző megfigyelési ablak.

A rögzítési pont dönti el, mit lát

Normál interfészen az AF_PACKET szocket az eszközréteg közelében ül. A gazdagépet elhagyó csomagok először az IPsec kimeneti feldolgozásán mennek át, amely a belső TCP-szegmenst ESP- vagy UDP-4500-datagrammá alakítja, és csak ezután érnek el ehhez a réteghez. A beérkező csomagok a vezetékről érkezve, még titkosítva másolódnak a szocketbe, és a visszafejtett eredmény később válik láthatóvá, amikor a verem helyben kézbesíti vagy továbbítja.

Ez a sorrend teljesen megmagyarázza az aszimmetriát. Ez nem bizonyíték az irányról, a szabályzatról vagy az alkalmazás viselkedéséről, és ha így kezeljük, az emberek olyan válasz után kutatnak, amelyet végig helyesen küldtek. Ez az egyik kevés hálózati rejtvény, ahol az eszköz, nem a hálózat hozza létre az anomáliát.

Illessze a szűrőt a szándékolt réteghez

Egy olyan kifejezés, mint a tcp port 443, belső TCP-kapcsolatot választ ki. Kifelé ez a kapcsolat már ESP-vé vált, mire a szocketet megkérdezik, így a szűrő semmire nem illeszkedik. Ha a védett forgalmat szeretné számolni, inkább a külső formára szűrjön: 50-es protokoll a nyers ESP-hez, vagy 4500-as UDP-port, ha NAT-átjárás van játékban. Mindkét szűrő olyan csomagszámot ad, amely a két fél között összehasonlítható, és általában éppen ez a számolás oka. Egyik sem mondja meg, hogy a belső kérés kapott-e választ.

Ne kezelje a UDP 4500 számlálóját ESP-csomagszámként. Az IKE is használja ezt a portot NAT-T életben tartó üzenetekhez és a beágyazott cseréhez, így a szám olyan forgalmat is tartalmaz, amely nem az az adat, amelyet mérni akart. Az UDP 500-on induló IKE-csere saját szűrőt igényel, ha a kérdés ez. Az a szám, amely vezérlőforgalmat kever adatokkal, minden sávszélesség-becslést is ismeretlen mértékben tesz hibássá. A külön számlálások külön kérdésekre válaszolnak.

Írja fel a szűrőt annak a kérdésnek a mellé, amelyre válaszol. A „mennyi ESP hagyta el a dobozt” és a „elhagyta-e a webkérés a dobozt” különböző mérések különböző szűrőkkel, és egyetlen rögzítés nem döntheti el mindkettőt. E feljegyzés nélkül két ember olyan számokat hasonlít össze, amelyek soha nem ugyanazt számolták.

Az átalakítás előtt figyeljen, ne utána

Ha látnia kell a kimenő nyílt szöveget, mozdítsa a megfigyelési pontot korábbra, az IPsec kimeneti feldolgozása elé. Az NFLOG egy Netfilter-horgot ad, ahol egy szabály kiválasztott csomagokat másolhat egy felhasználói téri szocketbe, amelyet a tcpdump olvasni tud. A strongSwan forgalomkiíró útmutatója pontosan ezért dokumentálja ezt a megközelítést.

A házirend-egyezés arra a forgalomra korlátozza a szabályt, amely éppen alagútba készül lépni. -m policy --pol ipsec --dir out az, ami a szabályt konkrét­tá teszi, ahelyett hogy a doboz minden küldött csomagját naplózná. Ezután olvassa a naplócsoportot korlátozott rögzítéssel: néhány pillanatkép és egy mérethatár megakadályozza, hogy a diagnosztika forgalmi archívummá váljon. A korlátozott rögzítést könnyebb átadni egy bírálónak is, anélkül hogy irreleváns terhelést cipelne. A számot indulás előtt döntse el, ne azután, hogy látta, mennyi érkezett.

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'

Válassza a folyamathoz illő horgot. Az OUTPUT a maga az átjáró által generált forgalmat fedi le; a LAN-ügyféltől jövő átmenő forgalom helyette a FORWARD láncon halad át, és az OUTPUT-on lévő szabály soha nem látja. A fenti cím és port egy jóváhagyott tesztcél helyőrzői.

Mit bizonyít a megfigyelés

Az NFLOG naplózási cél, nem elfogadási döntés. Az ott megjelenő csomag azt mutatja, hogy elérte a horgot és illeszkedett a szabályhoz. Nem mutatja, hogy egy későbbi szűrő engedte át, hogy az eszköz továbbította, vagy hogy a partner kapott valamit.

Az üres napló ugyanolyan kétértelmű. Ellenőrizze a szabály csomagszámlálóját, erősítse meg az irányt, erősítse meg, hogy a folyam valóban illeszkedett egy IPsec-házirendhez, és erősítse meg a célt. Csak a két félen egyező számláló tesz egy megfigyelést következtetéssé. Ezután hasonlítsa össze a biztonsági társítás számlálóit mindkét félen ugyanarra a kontrollált kísérletre, mert az SA-számlálók a hiteles feljegyzés arról, mi volt védve és elküldve.

Még egy csapda: a „nyílt szöveg” itt az IPsec titkosítási rétegen kívülit jelenti. Egy belső HTTPS-munkamenetnek továbbra is saját TLS-e van. A dekapszulált csomag rögzítése nem fejti vissza az alkalmazás TLS-ét, és ha ott olvasható HTTP látható, az azt jelenti, hogy az alkalmazás soha nem használt HTTPS-t.

Takarítson, és hasonlítsa össze mindkét véget

Távolítsa el a pontosan azt a szabályt, amelyet beszúrt, a tulajdonosa szerint, amint a megfigyelés véget ért. Az otthagyott naplózási szabály minden illeszkedő csomagnál CPU-t fogyaszt, és csendesen adatmegőrzési problémát teremt. Törölje a szabály -D-tel való megismétlésével, ne egy olyan lánc kiürítésével, amely nem az Öné.

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

Ha a telepítés felhasználói téri IPsecet, XFRM-interfészt vagy hardveres tehermentesítést használ, a megfigyelési pontok elmozdulnak, és ez a recept egyáltalán nem alkalmazható. A libipsec esetében a belső forgalom megfigyelésének dokumentált helye a TUN-eszköz. Először azonosítsa az útvonalat, majd válassza ki a kérdésre válaszoló pontot, és számítson rá, hogy a két irány csak akkor tűnik különbözőnek, ha az átalakítás rossz oldalára néz.