WebRTC через mDNS: как корпоративная сеть всё равно выдаёт лишнее

WebRTC через mDNS: как корпоративная сеть всё равно выдаёт лишнее

WebRTC не раскрывает локальный IP напрямую, но это не означает отсутствия следов. При mDNS браузер подменяет адрес псевдонимом вида host.local, однако в корпоративной среде утечка смещается в другую плоскость: на DNS-подобные запросы, тайминг, поведение STUN и несогласованность сетевых интерфейсов.

Анализируем энтропию параметров. Если у узла одновременно видны несколько NIC, VPN-туннель и активный WebRTC-поток, корреляция становится тривиальной по косвенным признакам:
— запросы mDNS идут только в локальный сегмент;
— STUN отвечает адресом, который не совпадает с ожидаемым egress;
— браузерное окружение передает больше данных, чем кажется, через кандидаты ICE и приоритеты интерфейсов.

Для корпоративного детекта важны не сами адреса, а паттерн. Смотрят на частоту локальных резолвов, попытки резолва .local, а также на то, как быстро меняется набор кандидатов при смене сети. Разбираем сигнатуру на уровне syscall: если браузер регулярно открывает UDP-сокеты к внешнему STUN и параллельно инициирует локальное mDNS, это уже устойчивый маркер среды, а не случайный шум.

Практически это лечится только дисциплиной конфигурации: сегментация сетей, контроль исходящего UDP, ограничение WebRTC там, где он не нужен, и тестирование с несколькими адаптерами одновременно. Скрытность — это не отсутствие следов, это шум, сливающийся с фоном.