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

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

Пассивное снятие отпечатка ОС работает не по JavaScript, а по побочным эффектам сетевого стека: размер окна, TTL, порядок TCP options, MSS, SACK, timestamps. Это не “магия IDS”, а сравнительный анализ того, как ядро формирует SYN/SYN-ACK и отвечает на нестандартные флаги. Разберем энтропию данного параметра: один и тот же браузер на разных ОС уходит в сеть с разной сигнатурой, даже если внешний IP и User-Agent совпадают.

Ключевые маркеры:
— initial TTL и его декремент на маршруте;
— окно приема и scale factor;
— набор и порядок опций в TCP handshake;
— реакция на NULL/FIN/XMAS-пакеты;
— поведение при повторной фрагментации и retransmission.
Именно комбинация, а не отдельное поле, дает устойчивый отпечаток. Один параметр легко шумит, но связка из пяти-шести признаков уже собирается в профиль.

Под капотом Chromium API это не контролируется напрямую: браузер лишь потребляет сетевую среду, а формирует отпечаток ОС ядро, драйвер и иногда VPN/прокси-слой. Поэтому попытки “спуфинга через инъекцию JS-кода” здесь бесполезны: JS видит уже верхний слой, а детект на уровне сетевого стека происходит до рендера страницы. Если нужен контроль, смотри не в DOM, а в конфигурацию TCP stack, MTU, offload-параметры и поведение туннеля.

Практический чек-лист: тестируй SYN-профиль снаружи, сравнивай с эталоном из той же семейства ОС, и отдельно прогоняй нестандартные пакеты через pcap. Если сигнатура “плывет” между сессиями, значит источник шума не браузер, а сеть, виртуализация или промежуточный шлюз.

Вывод простой: пассивный TCP/IP fingerprinting ломает иллюзию, что достаточно спрятать браузер. Сначала выравнивается транспортный слой, потом уже смысл обсуждать Canvas, WebGL и остальную идентификацию.