NEW на ACK пакет в conntrack: какво не доказва

В журнала на защитната стена има ред, който не сте очаквали: 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.

Два изгледа на един поток, които се разминават, дават повече от всеки от тях поотделно.

Кога да ескалирате

Ескалирайте, когато можете да покажете услуга, до която се стига и не би трябвало, заедно с потока, политиката, която го е разрешила, и доказателства от двете страни. Не съобщавайте дефект при доставчика въз основа на един етикет на състояние или едно частично прихващане, защото такова съобщение ще бъде затворено с обяснението, което току-що прочетохте. Ако услугата наистина е изложена, собственикът на тази граница е правилният човек да я поправи, а делегирано пренасочване на порт или нежелан слушател е по-вероятна причина от бъг.

После затворете пропуска във видимостта, който позволи един пакет да изглежда като цяла сесия.