TCP/IP fingerprinting: как ОС выдает себя еще до HTTP и JS

TCP/IP fingerprinting: как ОС выдает себя еще до HTTP и JS

Пассивное снятие отпечатка начинается на уровне сетевого стека: анализируется не один «параметр», а связка признаков в TCP SYN, SYN/ACK и последующем обмене. Разберем энтропию данного параметра: MSS, window size, порядок опций, наличие SACK, timestamps, scale factor. Сами по себе они шумные, но в комбинации дают устойчивый профиль ядра, драйвера и иногда прокси-слоя.

Классический пример — разный формат TCP options и их последовательность. Один стек предпочитает MSS+SACK+TS+WS, другой меняет порядок или округляет значения window. Плюс важны TTL, DF-bit, initial window, поведение при ретрансмиссии и реакция на некорректные флаги. Это уже не «отпечаток браузера», а детект на уровне сетевого стека.

Практически это ломает простые схемы маскировки: можно подменить User-Agent, Canvas и WebGL, но оставить нативный TCP/IP профиль. Если поверх антифрод-системы стоит корреляция L7 и L4, несостыковка видна сразу. Под капотом Chromium API тут не поможет — сигнал рождается ниже, в ОС и сетевом маршруте.

Что проверять в диагностике: • pcap SYN-пакета и порядок опций; • совпадение TTL и MSS с заявленной платформой; • наличие характерных timestamp-расчетов; • поведение при повторной отправке SYN. Если профиль «плавает» между сессиями, это признак не стабильной среды, а смеси драйверов, туннелей и NAT-обвязки.

Итог простой: надежный антидетект начинается не с косметики браузера, а с согласования L4-отпечатка с остальным стеком. Иначе любой спуфинг через инъекцию JS-кода остается поверхностным слоем, который сеть опровергает первой.