<b>TCP/IP fingerprinting: почему ОС палится ещё до первого HTTP-запроса</b>

<b>TCP/IP fingerprinting: почему ОС палится ещё до первого HTTP-запроса</b>

Пассивное снятие отпечатков работает не на JS-объектах, а на структуре сетевого стека. Разница видна в TTL, размере окна, порядке TCP options, MSS, SACK и поведении retransmission. Разберем энтропию данного параметра: набор мелочей, который в сумме выдаёт семейство ОС и иногда даже конкретную реализацию ядра.

Детект на уровне сетевого стека строится по сигнатуре SYN-пакета и ответов на нестандартные probe-последовательности. У Linux, Windows и BSD различаются не только значения, но и их порядок: timestamp, window scale, selective ACK permitted. Для антифрода важен не один признак, а согласованность всей цепочки: IP TTL, TCP Initial Window, DF-bit, ICMP-реакции, поведение при фрагментации.

Если эмулировать трафик поверх прокси или VPN, ломается корреляция между прикладным слоем и транспортом. Браузер может выглядеть как обычный Chromium, но сетевой отпечаток выдаст другой стек: другой MSS, иной initial congestion window, чужой профиль keepalive. Под капотом Chromium API это не исправляется JS-инъекцией — нужен контроль на уровне ядра, сетевого драйвера или туннеля.

Практический чек-лист: сравнивайте не один дамп, а серию SYN/SYN-ACK; проверяйте, совпадает ли TTL с типичной дистанцией маршрута; фиксируйте TCP options order; отдельно анализируйте повторные подключения и потерю пакетов. Любой «универсальный спуфинг» без учета этих связей оставляет артефакты, которые хорошо видны в p0f-подобных моделях.

Итог простой: если нужен правдоподобный профиль, эмулировать надо не браузер, а весь путь пакета от хоста до удалённой точки.