TCP/IP fingerprinting: как ОС выдает себя на уровне MSS, TTL и опций

TCP/IP fingerprinting: как ОС выдает себя на уровне MSS, TTL и опций

Пассивное снятие отпечатка строится не на одном поле, а на связке параметров в первом же SYN/SYN-ACK: initial TTL, window size, MSS, SACK, timestamp, NOP и их порядок. Разберем энтропию данного параметра: у Windows, Linux и BSD разные дефолты стека, а у NAT и прокси след остается в корреляции значений, даже если адрес уже скрыт.

Ключевая ошибка — смотреть только на TTL. Он часто нормализуется маршрутизатором по пути и сам по себе дает слабый сигнал. Гораздо устойчивее: размер окна в сочетании с MSS и набором TCP options. Если профиль TCP показывает `MSS=1460`, `WScale`, `SACKOK`, `TSval`, но порядок опций не совпадает с семейством ядра, антифрод видит не ОС, а кустарную подмену.

Под капотом Chromium API браузер не управляет этим стеком напрямую: отпечаток формирует ОС и сетевой стек под ней. Поэтому спуфинг через инъекцию JS-кода не решает задачу — скрипт меняет Canvas, WebGL или Navigator, но не переписывает TCP SYN. На практике детект на уровне сетевого стека ловится до рендеринга страницы.

Что проверять в дампе: SYN-пакеты без полезной нагрузки, последовательность TCP options, поведение retransmission, ECN, MSS clamp, а также различия между IPv4 и IPv6. Для сравнения полезны p0f-подобные сигнатуры и собственные PCAP-логи: одна и та же машина за разными VPN может менять маршрут, но не базовый профиль стека.

Вывод простой: если нужно снизить узнаваемость, менять надо не только браузерный слой, а всю цепочку сети и ОС; иначе отпечаток остается консистентным и легко связывается между сессиями.