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 з п’яти частин.

Два суперечливі погляди на один потік інформативніші за будь-який із них окремо.

Коли варто ескалювати

Ескалюйте, коли можете показати доступну службу, якої не повинно бути, разом із потоком, політикою, що це дозволила, і доказами з обох боків. Не повідомляйте про дефект провайдера на підставі однієї позначки стану або одного часткового захоплення, бо таке повідомлення буде закрито саме тим поясненням, яке ви щойно прочитали. Якщо служба справді відкрита, власник цієї межі — правильна людина, щоб це виправити, і делеговане зіставлення портів або випадковий слухач імовірніше є причиною, ніж помилка.

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