Multicast включён. Тихо. По умолчанию.
Если бы у IP-камер был характер, multicast был бы тем самым пунктом меню, который включён «просто потому что так удобнее на заводе». Его не видно в интерфейсе с первого взгляда, о нём редко пишут в быстрых гайдах, и почти никогда не вспоминают, когда обсуждают безопасность. А зря. Потому что во многих камерах, в том числе у Dahua, multicast-поток 224.1.2.4 включён по умолчанию. Не как экспериментальная опция, не как «для продвинутых», а как нечто само собой разумеющееся. Камера включается, получает IP — и параллельно с привычным unicast начинает «говорить в эфир».
С точки зрения инженера старой школы это выглядит логично. Multicast — вещь полезная, экономит трафик, снижает нагрузку, идеально подходит для локальных сетей с десятками операторов. Но с точки зрения безопасности 2026 года это почти анекдот: устройство, которое транслирует видео, изначально готово делать это для неопределённого круга слушателей. Не «кому разрешили», а «кто подпишется». И вот тут Wired-часть истории только начинается.
Что такое multicast и почему он не спрашивает разрешения
Multicast — это не «подключение», а объявление. Камера не устанавливает сессию, не проверяет логин, не ждёт ответа. Она просто отправляет поток на адрес из диапазона 224.0.0.0–239.255.255.255. Например, на скромный 224.1.2.4. Любой, кто находится в той же сети и знает адрес с портом, может сказать: «я хочу этот поток», и сеть его аккуратно доставит.
В этом и кроется фундаментальная разница с unicast. Unicast — это разговор. Multicast — это радиопередача. У радиопередачи нет пароля. Есть только частота. Если ты знаешь, где крутить ручку, ты слушаешь.
Производители камер исторически включали multicast по умолчанию из благих побуждений. Большие диспетчерские, видеостены, охрана, заводы — всё это работало в изолированных LAN, где «чужих» не было по определению. Но за последние 10–15 лет архитектура сетей изменилась, а настройки остались. Камера по-прежнему думает, что живёт в аккуратной заводской сети 2008 года, а на самом деле стоит за SOHO-роутером с UPnP, VLAN без IGMP и VPN, настроенным «на скорую руку».
Заводская логика против реального мира
Типовой сценарий выглядит почти карикатурно. Камеру распаковывают, подключают к сети, заходят в веб-интерфейс, меняют пароль администратора (в лучшем случае), настраивают RTSP — и на этом всё. Multicast никто не трогает, потому что «мы же его не используем». Камера, в свою очередь, продолжает исправно слать поток в multicast-группу.
Внутри локальной сети это может быть незаметно месяцами. Но как только появляются:
- L2-туннели,
- неправильно настроенные VLAN,
- VPN в режиме bridge,
- или маршрутизатор, который внезапно решил, что multicast можно форвардить,
— поток начинает жить своей жизнью. Он больше не привязан к VMS, не ограничен логином, не проверяет права. Он просто существует.
И это ключевой момент: multicast-поток живёт вне модели аутентификации. Его нельзя «взломать» в классическом смысле. Его можно просто… услышать.
Сценарий первый: утечка через корпоративную сеть
Самый распространённый и самый недооценённый сценарий. Камеры стоят в офисе или на объекте, сеть сегментирована формально, но IGMP Snooping либо выключен, либо настроен «по умолчанию». В результате multicast превращается в broadcast. Поток льётся на все порты коммутатора.
Дальше начинается магия корпоративной реальности:
- кто-то подключает ноутбук в «не тот» порт,
- кто-то поднимает Wi-Fi-точку,
- кто-то запускает VLC «просто проверить».
И внезапно видеопоток с камер оказывается доступен людям, которым он не предназначался. Без логов, без следов, без тревог. Никто ничего не взламывал. Просто сеть сделала то, что ей позволили.
В старых аналоговых системах для этого нужно было физически подключиться к коаксиалу. В IP-мире достаточно оказаться в одном широком сегменте.
Сценарий второй: VPN, который стал радиоантенной
VPN принято считать лекарством от всех сетевых бед. «У нас же VPN, значит безопасно». Пока не выясняется, что VPN поднят в режиме L2 bridge, или что multicast разрешён «на всякий случай, вдруг понадобится».
В этот момент multicast-поток камеры перестаёт быть локальным. Он становится удалённым без аутентификации. Любой клиент VPN, даже с минимальными правами, может подписаться на группу и получить видео. Не через VMS, не через API, не через облако — напрямую.
Самое неприятное здесь то, что:
- VMS ничего не знает об этом доступе,
- камера ничего не логирует,
- SIEM молчит.
С точки зрения системы безопасности ничего не произошло. С точки зрения реальности — кто-то смотрит камеры.
Сценарий третий: маршрутизатор с фантазией
Большинство домашних и офисных роутеров не должны маршрутизировать multicast. Но «не должны» и «не делают» — разные вещи. UPnP, IPTV-режимы, кастомные прошивки, странные ISP-настройки — и multicast внезапно выходит за пределы объекта.
Это редкий, но самый опасный сценарий. Потому что здесь камера фактически транслирует видео во внешнюю сеть. Не в интернет в привычном смысле, а в тот его странный полутень, где живут сканеры, экспериментаторы и люди, которым интересно, что можно поймать на 224.x.x.x.
Важно понимать: multicast не индексируется Google, но это не значит, что его никто не ищет. Есть инструменты, есть методики, есть энтузиасты. И multicast-поток без шифрования — это открытая дверь без замка.
Почему пароли и ONVIF здесь не спасают
Любимый аргумент производителей и интеграторов звучит так: «Но ведь доступ к камере защищён паролем». Да. Доступ к интерфейсу защищён. RTSP-unicast защищён. ONVIF требует аутентификации. Multicast — нет.
Multicast не знает, кто вы. Он не умеет спрашивать. Он просто отдаёт. Это архитектурное свойство протокола, а не баг конкретного производителя. И именно поэтому включать его по умолчанию в устройствах безопасности — мягко говоря, спорное решение.
В мире, где:
- камеры участвуют в судебных разбирательствах,
- видео используется как доказательство,
- и утечка архива может стоить компании репутации,
идея «поток без авторизации» выглядит анахронизмом из эпохи VGA-матриц и CRT-мониторов.
Что с этим делать в реальности, а не в идеальном мире
Первое и самое простое: если multicast не нужен — выключить. Это не оптимизация, не тюнинг, не «может потом». Это базовая гигиена. Камера не должна транслировать то, что никто не использует.
Второе: если multicast нужен — он должен жить в строго контролируемой среде:
- отдельный VLAN,
- включённый IGMP Snooping,
- IGMP Querier там, где нужно,
- никакого L2-VPN «на всякий случай».
Третье: никогда не считать multicast «внутренним по определению». В 2026 году внутренней сети не существует. Есть только сети с разным уровнем хаоса.
Финал без морализаторства
Multicast сам по себе не зло. Это старая, проверенная технология из времени, когда сети были честнее, а мир проще. Но включённый по умолчанию multicast в IP-камере — это как открытое окно в серверной «потому что жарко». Пока никто не залез — кажется, что всё нормально.
Проблема в том, что современные атаки и утечки редко выглядят как взлом. Чаще они выглядят как использование того, что уже работает. Multicast работает. Тихо, стабильно, незаметно. И именно поэтому он заслуживает куда больше внимания, чем получает.
Видеонаблюдение давно перестало быть просто «картинкой». А значит, и сетевые привычки из прошлого пора пересматривать. Даже если раньше «так делали всегда».