Conntrack NEW на ACK пакету: шта то не доказује

У дневнику заштитног зида постоји ред који нисте очекивали: ACK пакет, conntrack стање NEW, изворна адреса која није ваша, одредишни порт отворен. Искушење је прочитати га као нову долазну везу коју нико није одобрио. Оно што ред заиста каже уже је: када је тај пакет стигао до овог hook-а, тракер није имао одговарајуће стање, а пакет је носио ACK. То су две чињенице о две различите ствари и ниједна није потпун запис руковања. Ево реда којим пролазим пре него што донесем закључак.

Почните од пакета, не од пресуде

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

Мешање тих три је начин на који ACK постаје „провајдер је некога пустио унутра“.

Шта NEW заиста значи на hook-у

подударање conntrack у iptables документује NEW као пакет који започиње везу, или пакет повезан са везом која још није видела саобраћај у оба смера. ESTABLISHED значи да је тракер видео пакете у оба смера. Ниједна дефиниција не каже да је пакет био SYN, нити да је стигао без историје.

Тракер који почне да посматра ток у средини класификује следећи пакет према ономе што зна, а то може бити ништа. То говори о памћењу тракера, не о намери удаљеног хоста.

Лабаво праћење објашњава већину изненађења са ACK

Језгро документује nf_conntrack_tcp_loose, што тракеру омогућава да преузме TCP везе чији почетак није видео. Са подешавањем на подразумеваној вредности, ACK из средине тока може бити прихваћен као успостављен ток. Искључите га и исти пакет ће вероватније бити класификован као INVALID уместо NEW. Оба исхода описују правила тракера, не историју апликације.

Зато проверите то подешавање пре него што изградите теорију на ознаци.

Искључите досадне узроке у овом редоследу

Већина NEW-на-ACK догађаја које сам пратио завршила је на једном од ових, и све их је јефтино проверити:

• Табела conntrack је очишћена или је тракер рестартован.
• Хост је рестартован или се ток преселио у други namespace или уређај.
• Асиметрично рутирање је извело SYN на пут који не снимате.
• NAT је преписао tuple, па запис више не одговара ономе што сте прочитали.
• Снимање је почело касно и никада није видело почетак.

Сваки од њих уклања раније пакете из вида тракера, а касније оставља нетакнуте. Рестарт или чишћење табеле најлакше се потврђују из uptime-а и дневника. Асиметрично рутирање се види као једносмерно снимање. NAT је подмукао, јер tuple који је тракер сачувао није tuple одштампан у дневнику.

Запишите које сте од њих искључили и како, пре него што наставите.

Прочитајте tuple, интерфејс и hook

Запис conntrack се кључира адресама, портовима и протоколом, па сваки превод мења који запис одговара. Забележите и интерфејс и hook, јер пакет виђен на погрешном интерфејсу или после другог ланца говори да пут није онај са дијаграма. Када догађај укључује VPN, одлучите да ли гледате унутрашњи пакет или спољни носач. Затим упоредите са оним што је мрежни пролаз забележио за исти tuple од пет делова.

Два супротстављена погледа на исти ток информативнија су од било ког од њих самог.

Када вреди ескалирати

Ескалирајте када можете да покажете услугу која је доступна и не би требало да буде, заједно са током, политиком која је то дозволила и доказима са оба краја. Не пријављујте дефект провајдера на основу једне ознаке стања или једног делимичног снимка, јер ће то пријављивање бити затворено управо објашњењем које сте тек прочитали. Ако је услуга заиста изложена, власник те границе је права особа да то поправи, а делегирано мапирање портова или ненамерни слушалац вероватнији је узрок од грешке.

Затим затворите празнину у видљивости која је дозволила да један пакет изгледа као цела сесија.