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

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

Пассивное снятие отпечатка строится не на содержимом пакета, а на микроскопических решениях стека: TTL, размер окна, MSS, порядок опций, NOP-padding, SACK, timestamps. Эти поля формируются на уровне ядра и TCP-реализации, поэтому их комбинация часто стабильнее, чем браузерный Canvas. Разберем энтропию данного параметра: даже при NAT и прокси часть сигнатуры сохраняется.

Ключевой источник — SYN/SYN-ACK. Анализируют:
• начальный TTL и его «ступеньку» по пути;
• window size и scale factor;
• набор и порядок TCP options;
• поведение при фрагментации и retransmit;
• ICMP-ответы на некорректные пакеты.

У Linux, Windows и BSD различаются не только дефолтные значения, но и способ их упаковки в сегмент. Детект на уровне сетевого стека часто использует не один признак, а профиль: если MSS типичен для одной ОС, а ordering опций — для другой, отпечаток становится аномальным. Это хорошо видно в p0f-подобных моделях: они сравнивают не «ОС целиком», а вектор параметров.

Для антидетекта задача не в грубом подмене TTL, а в согласованности слоями. Если браузер имитирует одну платформу, а TCP/IP стек остается от другой, несостыковка всплывает на корреляции с TLS Client Hello, поведением HTTP/2 и локальными задержками. Под капотом Chromium API это не исправить одной JS-инъекцией.

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