TCP/IP Fingerprinting: как ОС выдает себя еще до ответа приложения

TCP/IP Fingerprinting: как ОС выдает себя еще до ответа приложения

Пассивное снятие отпечатка работает без сканов и баннеров: анализируется то, как стек формирует SYN/SYN-ACK, TTL, MSS, window size, порядок TCP options и поведение при retransmit. Разберем энтропию данного параметра: ядро, драйвер и сетевой фильтр оставляют более устойчивый след, чем пользовательский агент.

Ключевые признаки:
— начальный TTL и его кратность после пути;
— MSS и размер окна;
— набор опций TCP и их порядок: SACK, timestamps, NOP;
— политика DF, ECN, window scaling;
— реакция на нестандартные флаги и дубли пакетов.

На практике сильнее всего детект на уровне сетевого стека дают не отдельные поля, а связка. Два хоста могут совпасть по TTL, но отличаться по framing опций и алгоритму выставления окна. Именно поэтому простая подмена одного параметра почти бесполезна: профиль ломается на корреляции, а не на одном значении. Под капотом Chromium API это не лечится — браузер не управляет тем, как ОС отвечает в TCP.

Если нужна правдоподобная среда, проверяйте согласованность всей цепочки: ОС, ядро, сетевой адаптер, NAT, прокси и путь до точки наблюдения. Любой разрыв между локальным стеком и заявленным профилем заметен в pcap быстрее, чем в UI. Наблюдение через tcpdump и сравнение с эталонными трассами дает больше, чем десяток «антидетект-настроек».

Вывод простой: пассивный TCP/IP fingerprint — это не про браузер, а про поведение сетевого стека. Если не совпадает базовая механика пакетов, спуфинг через инъекцию JS-кода не спасает.