Стан NEW у conntrack на ACK-пакеце: што гэта не даказвае

У журнале фаервола ёсць адзін радок, якога вы не чакалі: ACK-пакет, стан conntrack NEW, адрас крыніцы не ваш, порт прызначэння адкрыты. Спакуса — прачытаць гэта як новае ўваходнае злучэнне, на якое ніхто не даваў дазволу. Насамрэч радок кажа вуздзей: калі гэты пакет дасягнуў гэтага хука, у трэкера не было адпаведнага стану, і пакет нёс ACK. Гэта два факты пра дзве розныя рэчы, і ні адзін з іх не з’яўляецца поўным запісам рукапаціскання. Вось парадак, які я праходжу, перш чым рабіць выснову.

Пачніце з пакета, а не з вердыкта

Аддзяліце назіранні, перш чым іх тлумачыць. Сцягі TCP апісваюць гэты пакет, стан трэкера апісвае тое, што ён ведаў на гэтым хуку, а ваш захоп апісвае толькі запісанае акно.

Змешванне гэтых трох — гэта тое, як ACK ператвараецца ў «правайдэр кагосьці ўпусціў».

Што NEW насамрэч значыць на хуку

супастаўленне 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, інтэрфейс і хук

Запіс conntrack будуецца на адрасах, партах і пратаколе, таму любое пераўтварэнне змяняе, які запіс супастаўляецца. Запішыце таксама інтэрфейс і хук, бо пакет, убачаны на няправільным інтэрфейсе або пасля іншага ланцуга, кажа, што шлях не такі, як на схеме. Калі падзея датычыць VPN, вызначце, ці вы глядзіце на ўнутраны пакет або на знешні носьбіт. Потым параўнайце з тым, што шлюз запісаў для таго самага пяцікампанентнага tuple.

Два погляды на адну плынь, якія разыходзяцца, даюць больш, чым любы з іх паасобку.

Калі варта эскаліраваць

Эскаліруйце, калі можаце паказаць службу, да якой можна дасягнуць і якой не павінна быць, разам з плынню, палітыкай, якая гэта дазволіла, і доказамі з абодвух бакоў. Не паведамляйце пра дэфект правайдэра на падставе адной пазнакі стану або аднаго частковага захопу, бо такое паведамленне зачыняць тлумачэннем, якое вы толькі што прачыталі. Калі служба сапраўды адкрытая, уладальнік гэтай мяжы — той, хто павінен яе выправіць, і перанакіраванае адлюстраванне порта або выпадковы слухач з’яўляюцца больш імавернай прычынай, чым памылка.

Потым закрыйце прагал у бачнасці, з-за якога адзін пакет выглядаў як цэлая сесія.