TCP/IP fingerprinting: как ОС выдают себя еще до первого байта HTTP

TCP/IP fingerprinting: как ОС выдают себя еще до первого байта HTTP

Пассивное снятие отпечатков ОС работает не через JS, а на уровне сетевого стека. Анализируются параметры SYN/SYN-ACK: размер окна, MSS, порядок опций, наличие SACK, timestamps, TTL и даже типичные дефолты реализации ядра. Разберем энтропию данного параметра: чем меньше «шум» в конфигурации стека, тем легче связать трафик с конкретной ОС.

Классическая схема — сравнение pcap с базой сигнатур. У Linux, Windows и BSD различаются не только значения, но и последовательность TCP options. Отдельно смотрят на IP-ID, поведение при фрагментации, реакцию на некорректные флаги и особенности retransmission. Это уже не маркетинговый «антифрод», а детект на уровне сетевого стека.

Для практики важно понимать, что один параметр редко решает все. Сильный матч дают комбинации: TTL + window size + MSS + timestamps + ordering options. Если вы подменяете только HTTP-заголовки, а TCP-слой остается «родным», корреляция сохраняется. Под капотом Chromium API это не лечится: браузер не управляет тем, как ядро формирует SYN.

Что проверять в дампе:
— initial TTL и его кратность до цели
— набор TCP options и их порядок
— window scaling и типичный MSS
— поведение на повторных SYN и разницу в таймингах

Практический вывод: при анализе антифрода смотрите не на один fingerprint, а на связку сетевых признаков. Если стек и браузер спорят между собой, система почти всегда поверит стеку.