Зашто 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 уређај. Прво утврдите пут, затим изаберите тачку која одговара на питање, и очекујте да два смера изгледају различито само када гледате у погрешну страну трансформације.