Зошто tcpdump покажува IPsec чист текст само во една насока

Извршувате tcpdump на надворешниот интерфејс на Linux IPsec порта и гледате две работи одеднаш: дојдовни ESP рамки и, веднаш по нив, дешифрираните внатрешни пакети. На излез се појавува само ESP. Природниот заклучок е дека одговорите не се испраќаат или дека IPsec шифрира една насока и ја заборава другата. Ниту едното не е точно.

Она што го гледате е точка на фаќање. Јадрото ги трансформира излезните пакети пред патеката за пренос на уредот да ги предаде на сокетот за пакети, па сокетот никогаш не ја гледа внатрешната форма при излез. При влез, пакетот прво се фаќа како ESP, а дешифрираната копија станува видлива кога повторно влегува во стекот. Истиот сообраќај, два различни прозорци за набљудување.

Точката на фаќање одлучува што гледате

На нормален интерфејс, сокетот AF_PACKET седи близу до слојот на уредот. Пакетите што го напуштаат домаќинот прво минуваат низ излезната обработка на IPsec, која внатрешниот TCP сегмент го претвора во ESP или UDP-4500 датаграм, и дури потоа стигнуваат до тој слој. Дојдовните пакети се копираат во сокетот како што доаѓаат од жицата, сѐ уште шифрирани, а дешифрираниот резултат станува видлив подоцна кога стекот ќе го достави локално или ќе го препрати.

Тој редослед целосно ја објаснува асиметријата. Тоа не е доказ за насока, политика или однесување на апликацијата, и ако се третира како таков, луѓето почнуваат да го бараат одговорот што цело време бил испратен правилно. Ова е една од малкуте мрежни загатки каде што аномалијата ја создава алатката, а не мрежата.

Усогласете го филтерот со слојот што го мислите

Израз како tcp port 443 избира внатрешна TCP врска. На излез, таа врска веќе станала ESP кога се прашува сокетот, па филтерот не совпаѓа со ништо. Ако сакате да броите заштитен сообраќај, филтрирајте по надворешната форма: протокол 50 за сиров ESP, или UDP порта 4500 кога се користи NAT премин. Двата филтри даваат број на пакети што може да се спореди меѓу двете страни, што обично е и причината за броење. Ниту еден не ви кажува дали внатрешното барање добило одговор.

Не го третирајте бројот на UDP 4500 како број на ESP пакети. IKE исто така ја користи таа порта за NAT-T пораки за одржување и за инкапсулираната размена, па бројот вклучува сообраќај што не се податоците што сакавте да ги измерите. Почетната IKE размена на UDP 500 бара свој филтер ако тоа е прашањето. Број што меша контролен сообраќај со податоци, исто така, ја прави секоја проценка на пропусниот опсег погрешна за непозната маржа. Одделни броења одговараат на одделни прашања.

Запишете го филтерот до прашањето на кое одговара. „Колку ESP излезе од кутијата“ и „дали веб-барањето излезе од кутијата“ се различни мерења со различни филтри, и едно фаќање не може да ги реши двете. Без таа забелешка, две лица ќе споредуваат броеви што никогаш не броеле исто нешто.

Набљудувајте пред трансформацијата, не по неа

Ако треба да го видите излезниот чист текст, преместете ја точката на набљудување порано, пред излезната обработка на IPsec. NFLOG ви дава кука во Netfilter каде правило може да копира избрани пакети во сокет во кориснички простор, што tcpdump може да го чита. Водичот на strongSwan за испис на сообраќај го документира овој пристап токму поради оваа причина.

Совпаѓањето со политиката го ограничува правилото на сообраќај што е пред да влезе во тунел. -m policy --pol ipsec --dir out е тоа што го прави правилото конкретно наместо да го логира секој пакет што кутијата го испраќа. Потоа читајте ја групата на дневник со ограничено фаќање: мал број снимки и ограничување на големината спречуваат дијагностиката да стане архив на сообраќај. Ограниченото фаќање е исто така полесно да се предаде на рецензент без да се влече нерелевантен товар. Одлучете го бројот пред да започнете, а не откако ќе видите колку пристигна.

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'

Изберете ја куката што одговара на текот. OUTPUT го покрива сообраќајот што самата порта го генерира; транзитот од LAN клиент оди низ синџирот FORWARD, и правило на OUTPUT никогаш нема да го види. Адресата и портата погоре се места за пополнување за одобрена тест дестинација.

Што докажува набљудувањето

NFLOG е цел за логирање, не одлука за прифаќање. Пакет што се појавува таму покажува дека стигнал до куката и се совпаднал со правилото. Тоа не покажува дека подоцнежен филтер го дозволил, дека уредот го пренел или дека другата страна примила нешто.

Празниот дневник е исто толку двосмислен. Проверете го бројачот на пакети на правилото, потврдете ја насоката, потврдете дека текот навистина се совпаднал со IPsec политика и потврдете ја дестинацијата. Само совпаѓачки бројач на двете страни го претвора набљудувањето во заклучок. Потоа споредете ги бројачите на безбедносната асоцијација на двете страни за истиот контролиран обид, бидејќи SA бројачите се авторитетен запис за тоа што било заштитено и испратено.

Уште една стапица: „чист текст“ во овој контекст значи надвор од слојот за шифрирање на IPsec. Внатрешната HTTPS сесија сѐ уште има свој TLS. Фаќањето на дешифрираниот пакет не го дешифрира TLS-от на апликацијата, а читањето на читлив HTTP таму значи дека апликацијата никогаш не користела HTTPS.

Исчистете и споредете ги двата краја

Отстранете го точното правило што го вметнавте, според неговиот сопственик, штом набљудувањето заврши. Оставањето правило за логирање на место троши CPU на секој совпаѓачки пакет и тивко создава проблем со задржување на податоци. Избришете го со повторување на правилото со -D наместо да го испразните синџирот што не е ваш.

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

Ако распоредувањето користи IPsec во кориснички простор, XFRM интерфејс или хардверско олеснување, точките на набљудување се поместуваат и овој рецепт може воопшто да не важи. Со libipsec, документираното место за набљудување на внатрешниот сообраќај е уредот TUN. Прво утврдете ја патеката, потоа изберете ја точката што одговара на прашањето, и очекувајте двете насоки да изгледаат различно само кога гледате во погрешната страна на трансформацијата.