Поиск теневых устройств в сети: минимум задач и отчетов

Что такое «теневые» устройства и почему их нужно ловить регулярно

«Теневое» устройство - это любое оборудование, которое появилось в сети без учета и понятного владельца. Оно может быть подключено «на час», но остаться на недели. Важно не то, насколько оно «умное», а то, что о нем никто не знает и его никто не обслуживает.

Чаще всего это вполне бытовые вещи: принтер, домашняя Wi‑Fi точка доступа, мини‑ПК для табло или бухгалтерии, IP‑камера, «умный» TV, VoIP-шлюз. Сюда же попадают временные роутеры «чтобы был интернет» и тестовые ноутбуки в переговорке, которые потом забывают отключить.

Проблема в том, что у таких устройств обычно неизвестные сервисы и настройки. На них часто стоят простые пароли, включены лишние протоколы управления, а обновления не ставились годами. Иногда теневое устройство ломает сегментацию: точка доступа раздает Wi‑Fi прямо в офисную VLAN, или мини‑ПК с двумя интерфейсами фактически «склеивает» две сети.

Разовый поиск почти всегда бесполезен. Сеть меняется каждый день: подрядчик привез камеру, отдел купил принтер, админ поставил временную «затычку» на время поломки. Через месяц всплывает то же самое, только с другим MAC-адресом и в другом кабинете. Поэтому нужен регулярный процесс: обнаруживать, подтверждать, оформлять или отключать.

Обычно в нем участвуют четыре роли. ИБ задает правила (что считается неизвестным, какие зоны критичны, какие сроки реакции). Эксплуатация подтверждает по портам и схемам, где и как устройство подключено. Helpdesk связывается с пользователями и фиксирует владельца или заявку на легализацию. Владельцы сервисов (ИТ, офис, безопасность) принимают решение: добавить в учет, изолировать или убрать.

Регулярный поиск «теневых» устройств - это не охота на ведьм, а гигиена сети: меньше сюрпризов, проще расследования и меньше шансов, что «маленькая коробочка» станет входом в большую проблему.

Минимальный целевой результат для ИБ и эксплуатации

Минимальный результат - не «идеальная карта сети», а управляемость. Достаточно быстро отвечать на три вопроса: какое устройство появилось, где оно подключено, кто за него отвечает. Если на это уходят часы, а не дни, риск заметно падает.

На выходе полезно стабильно получать небольшой набор артефактов:

• список обнаруженных устройств (IP, MAC, имя хоста, вендор по MAC, время первого появления)
• привязка к месту (коммутатор, порт, VLAN, офис/этаж или другая локация)
• статус «известно/неизвестно» и ответственный (владелец системы или подразделение)
• короткая пометка по риску от ИБ (например: «маршрутизатор», «точка доступа», «принтер», «непонятно»)

Зоны ответственности лучше разделить заранее. ИБ фиксирует факт появления и оценивает риск: уместно ли устройство в этой зоне, есть ли признаки обхода правил. Эксплуатация делает «полевую» часть: находит порт, проверяет, не ошибка ли в адресации, связывается с владельцем, при необходимости отключает или переносит устройство в правильный сегмент. В компаниях, где ИТ и ИБ пересекаются по закупкам и поддержке (например, при внедрениях с системными интеграторами уровня GSE.kz), такое разделение особенно важно, чтобы инциденты не зависали между командами.

Частота контроля зависит от сигналов:

• ежедневно: новые MAC и смены MAC-IP
• еженедельно: список «новые и неразобранные» с ответственными и сроками
• ежемесячно: сверка реестра с тем, что реально видно в сети

Отдельно решите, где хранится «истина». Лучше всего - CMDB или инвентарная база. Если ее нет, начните с простой таблицы-реестра: устройство, владелец, локация, дата согласования. Без одного источника правды поиск теневых устройств быстро превращается в бесконечные споры «оно всегда тут было».

Какие данные и доступы нужны до запуска инструментов

Без базовых данных инструменты быстро упираются в потолок: вы увидите «что-то в сети», но не поймете, где оно подключено и кто за него отвечает. До старта договоритесь, какие сегменты вы контролируете и какие источники данных считаются «истиной».

Доступы к сетевой инфраструктуре

Главный минимум для Netdisco - чтение по SNMP с коммутаторов. Без SNMP вы не получите самое ценное: привязку MAC-адреса к порту и коммутатору, а значит не сможете быстро дойти до розетки или точки доступа.

Проверьте, что у вас есть:

• список коммутаторов (адреса управления, модель, площадка) и SNMP read-only доступ
• карта VLAN и подсетей, которые входят в контроль (офис, Wi‑Fi, гостевая, серверная)
• права на просмотр конфигураций портов (хотя бы через эксплуатацию), чтобы уточнять режим порта, trunk/access, описание
• понимание «где нельзя трогать»: сегменты и устройства, которые нельзя активно сканировать

Данные из сервисов, чтобы связать IP, MAC и владельца

DHCP журналы аренды часто дают самый быстрый ответ, кто и когда получил IP. Если вы видите новый MAC в arpwatch, следующий шаг - связать его с IP и временем выдачи в DHCP.

Заранее согласуйте исключения. Например, принтеры, терминалы, медоборудование и часть OT часто нельзя проверять активным Nmap. Тогда фиксируйте, какие сети сканируются только пассивно (SNMP, DHCP, ARP) и кто дает разрешение на исключение.

Чтобы отчеты не превращались в «список MAC», введите простое правило именования и место фиксации (CMDB, таблица, тикет-система): площадка, кабинет или стойка, VLAN, роль устройства и контакт владельца. Тогда найденный «неизвестный» роутер в гостевой сети будет не загадкой, а задачей с понятным адресом и ответственным.

Netdisco: быстрый учет устройств и привязка к портам

Netdisco помогает быстро отвечать на два вопроса: что подключено к сети и к какому порту. Для поиска теневых устройств это особенно полезно, потому что он опирается на данные коммутаторов: MAC-таблицы, сведения о портах, а также LLDP/CDP (если включены). В результате видно не только присутствие устройства, но и его перемещения по розеткам и стойкам.

Базовая настройка обычно простая: добавить управляемые коммутаторы (SNMP на чтение), включить регулярный сбор MAC-таблиц и, где возможно, LLDP/CDP. Важно иметь хотя бы один стабильный источник правды по VLAN и названиям площадок/шкафов, иначе отчеты будут «про IP», но не «про место».

Чаще всего достаточно трех отчетов, которые закрывают большую часть рутины:

• новые устройства (MAC впервые замечен в сети)
• устройство сменило порт (вчера было в одном месте, сегодня в другом)
• неизвестный вендор по OUI (подозрительные или «безымянные» MAC)

Важное ограничение: если устройство сидит за неуправляемым свитчом, Netdisco увидит только аплинк-порт и «смешанную» картину MAC-адресов. Похожая история бывает с Wi‑Fi, если вы собираете данные не с контроллера, а только с коммутаторов.

Чтобы это не стало «еще одним отчетом», заранее задайте реакцию. Например: для критичных VLAN (финансы, домен, медоборудование) новый MAC проверяет дежурный эксплуатации за 4 часа, а ИБ дает классификацию риска до конца рабочего дня. На практике это выглядит так: Netdisco показал новый MAC на порту в переговорке, эксплуатация сверяет с заявками, ИБ смотрит OUI и контекст VLAN, и дальше решают - отключить порт, перевести в гостевую VLAN или узаконить устройство.

arpwatch: простые события «появилось новое устройство»

arpwatch дает простое событие: в сегменте появился новый MAC-адрес, или у известного MAC сменился IP. Это не инвентаризация, а ранний датчик, который хорошо дополняет регулярный поиск теневых устройств.

Где ставить

arpwatch видит только то, что проходит через ARP. Поэтому его ставят там, где ARP-трафик реально наблюдаем: на шлюзе сегмента (маршрутизатор, L3-коммутатор), на сервере в той же VLAN, или за зеркалом порта (SPAN) на коммутаторе. Удобнее начинать с самых важных VLAN: серверной, пользовательской офисной и гостевой.

Обычно полезно включить в уведомления и логи:

• новый MAC в сегменте (new station)
• смена IP у известного MAC (changed address)
• дубликаты IP или MAC (flip-flop, duplicate)
• частые изменения у одного MAC за короткое время

Как снизить шум и что считать инцидентом

arpwatch быстро становится «шумным», если не отделить норму от странностей. Дайте эксплуатации возможность вести белый список для инфраструктуры (шлюзы, точки доступа, принтеры, IP-телефоны) и отдельно помечать зоны, где много временных клиентов (переговорные, гостевой Wi‑Fi).

Чтобы ИБ и эксплуатация одинаково понимали, что требует реакции, зафиксируйте правила. Чаще всего инцидентом считают:

• новый MAC в серверной VLAN или в сегменте управления
• дубликат IP (часто признак ошибки или попытки перехвата)
• «скачущий» MAC на разных портах (может быть петля, перенос свитча, подмена)
• частые смены IP у одного MAC без понятной причины

Пример: в серверной VLAN появляется новый MAC, который получает адрес не из списка статических. Даже если сервисы не упали, это повод проверить порт на коммутаторе, владельца устройства и цель подключения, а затем зафиксировать результат в журнале изменений.

Nmap: подтверждение и быстрый профиль устройства

Nmap полезен, когда Netdisco или arpwatch уже подсказали «кто-то появился», а вам нужно подтвердить присутствие и понять, что это за устройство. Для ИБ это способ отделить шум от реальной угрозы, для эксплуатации - быстро понять, к кому идти дальше. Часто Nmap закрывает вопрос за 5-10 минут.

Есть два режима, и их важно не смешивать. Первый - мягкое обнаружение: проверить, что IP живой, и (в одном L2-сегменте) получить MAC через ARP. Второй - ограниченное сканирование портов по правилам: только короткий список портов, без агрессивных опций и без «прочесывания всего подряд».

Примеры команд, которые обычно достаточно безопасны для старта:

# Мягкая проверка хоста
nmap -sn 192.168.10.25

# Ограниченное сканирование по короткому списку портов
nmap -sS -Pn -p 22,80,443,445,3389 192.168.10.25

Минимальный набор данных, который стоит фиксировать в тикете или журнале:

• IP-адрес и подсеть
• MAC-адрес (если виден в вашем сегменте)
• имя хоста (если резолвится)
• открытые порты из короткого списка и их сервисы

Сканирование лучше запускать в спокойные окна и ограничивать скорость, чтобы не создавать ложные проблемы. Чувствительные подсети (медицинское оборудование, АСУ, критичные сервисы) исключайте, если нет отдельного согласованного окна и ответственного.

Что считать «подозрительным» при первичном профиле:

• веб-интерфейс управления на 80/443 у устройства, которого нет в учете
• SMB (445) или RDP (3389) там, где обычно только офисные ПК и принтеры
• необычные открытые порты, которых не бывает в типовом профиле сегмента
• «тихий» хост: отвечает на ARP, но не пингуется и не показывает сервисы

Небольшой пример: arpwatch прислал новый MAC в офисном VLAN. Nmap показывает 80/443 и заголовок веб-админки. Это повод не спорить «кто поставил», а изолировать порт и дальше разбираться по процедуре.

Пошаговый регламент: как организовать регулярное обнаружение

Регулярность держится на коротком повторяемом цикле: что считаем нормой, как ловим новое, кто принимает решения и как фиксируем результат.

1) Зафиксируйте «известную базу»

Начните с простого реестра. Достаточно, чтобы по каждому устройству были: MAC, IP (или подсеть), владелец (подразделение или ФИО), локация (офис, стойка, этаж), критичность (обычное, важное, запрещенное). Без этого любое «новое» будет спорным: непонятно, кто поставил и зачем.

2) Настройте постоянные сигналы о новом

Для ключевых сегментов (офис, Wi‑Fi, серверная, сегменты подрядчиков) включите arpwatch, чтобы получать события о появлении новых MAC и смене IP. Заранее решите, куда падают события (почта, тикеты) и кто дежурит.

Дальше цикл можно держать таким:

• ежедневно: разбор событий arpwatch (новый MAC, смена IP, «флаппинг»)
• по событию: Netdisco для поиска коммутатора/порта и истории перемещений
• раз в неделю: Nmap по утвержденным подсетям и сравнение с прошлой неделей
• для каждой находки: идентификация, согласование, действие (изоляция/блокировка или легализация)
• закрытие: обновить реестр, чтобы устройство больше не считалось «новым»

Пример: arpwatch сообщает новый MAC в бухгалтерской подсети. Netdisco показывает порт в переговорной, а Nmap определяет, что это домашний роутер с веб-интерфейсом. Дальше решение простое: изоляция порта, поиск владельца помещения, затем либо запрет, либо оформление как разрешенного оборудования и фиксация в реестре.

Минимальный набор отчетов, который реально читать

Отчеты должны отвечать на один вопрос: что именно сделать ИБ и эксплуатации сегодня. Если отчет не приводит к действию (проверить, подтвердить, отключить, завести заявку), его лучше не выпускать.

Практично держать 4-5 отчетов и в каждом иметь две колонки: «статус разбора» и «владелец разбора» (ИБ или эксплуатация). Без этого он быстро станет «мертвым».

• Еженедельный «Новые устройства»: MAC, IP, VLAN, порт (коммутатор/интерфейс), время первого появления, способ обнаружения (Netdisco/arpwatch/Nmap), статус разбора.
• «Устройства без владельца»: все, что найдено, но не привязано к подразделению, заявке или ответственному.
• «Смена порта или локации»: что переехало, куда, когда, кто подтвердил.
• «Неожиданные сервисы»: короткий список открытых портов и где они появились (например, 22/3389/445), с пометкой «ожидалось/не ожидалось».
• Ежемесячная «Реестр vs факт»: сколько расхождений, основные причины и динамика по месяцам.

Пример: в «Новых устройствах» появляется MAC с IP из офисной подсети, а в «Неожиданных сервисах» у него открыт 53 порт. Эксплуатация проверяет порт коммутатора и физическую точку, ИБ ставит статус «подозрение на роутер/точку доступа» и фиксирует решение: легализовать через заявку или отключить.

Частые ошибки и ловушки при поиске «теневых» устройств

Самая частая проблема - превращать задачу в разовую акцию. Находки не становятся процессом: кто-то один сканирует, пишет в чат, и на этом все.

Обычно сбои происходят в нескольких местах:

• Запускают слишком широкий Nmap без окна работ и ограничений по скорости. Сеть и сервисы начинают «плыть», пользователи жалуются, а к проверкам появляется недоверие.
• Нет единого реестра известных устройств (пусть даже простого). Тогда одно и то же устройство «открывают» снова и снова.
• Не определен маршрут эскалации. ИБ видит новый MAC, но эксплуатация не ищет порт, владелец не назначен, значит ничего не меняется.
• Не учитывают неуправляемые свитчи и Wi‑Fi. На схеме и в отчетах порт выглядит «чистым», а реальное устройство спрятано за точкой доступа или маленьким свитчом.
• Игнорируют дубликаты IP или MAC. В итоге пропускают конфликты, «переезды» устройств и возможную подмену.

Помогают три заранее согласованные вещи: когда можно сканировать, где хранится реестр, и кто принимает решение по неизвестной находке. Даже если инструмент показывает только «подозрительно», у заявки должен быть владелец и срок.

Пример: в офисе появляется «новый принтер» по названию в DHCP, но по факту это домашний роутер, который раздает Wi‑Fi. Если нет проверки дубликатов и привязки к порту, он будет всплывать как «еще одно устройство» и жить неделями. Если же есть правило: новый MAC + неизвестный производитель + нетипичные открытые порты, это сразу уходит в эскалацию, и эксплуатация ищет точку подключения на уровне доступа.

Короткий чек-лист для еженедельной проверки

Еженедельная проверка должна быть короткой и заканчиваться понятным результатом: что принять как норму, а что разобрать.

Сначала держите под рукой список VLAN, где появление нового устройства опаснее всего. Обычно это пользовательские сети офисов, Wi‑Fi для сотрудников, сегменты с доступом к критичным сервисам и любые «переходные» зоны между отделами.

Дальше пройдитесь по событиям появления новых MAC-адресов за неделю:

• Понятно, в каком VLAN замечен MAC, и критичен ли этот VLAN. Если критичен, разбор идет в тот же день.
• Есть привязка к коммутатору и порту. Если привязки нет, должна быть записана причина (NAT, неуправляемый свитч, нет SNMP/LLDP) и заведена задача на устранение слепой зоны.
• Назначен владелец и зафиксировано основание появления: заявка, замена, тестовый стенд, проект. «Не знаем» - это незакрытый инцидент.
• Сделан минимальный профиль: как устройство отвечает в сети и похоже ли оно на свою роль (адреса, имя, типовые порты, веб-интерфейс, RDP/SSH, принтерные сервисы).
• После разбора обновлен реестр: добавлен актив или внесено исключение с датой и причиной.

Если по итогам недели остается больше 5-10 «непонятных» MAC без владельца, обычно не хватает доступа к данным или дисциплины фиксации изменений.

Пример сценария: найден неизвестный роутер в офисной сети

Утром в офисе появляется новое устройство: кто-то подключил небольшой роутер или точку доступа в свободную розетку у переговорной. Через пару минут оно получает IP по DHCP и начинает раздавать Wi‑Fi. Никто из ИТ об этом не предупреждал, а в списке разрешенных устройств его нет.

Первым срабатывает arpwatch. В журнале появляется new station: новый MAC-адрес, время первого появления и выданный IP. Уже этого достаточно, чтобы понять масштаб: это не разовый ноутбук гостя, а устройство, которое закрепилось в сети.

Дальше помогает Netdisco. По IP или MAC быстро находится коммутатор и порт, к которому подключено устройство. Там же часто видна история: этот MAC появлялся и раньше, но перемещался между кабинетами. Это превращает догадку в понятный инцидент для эксплуатации.

Чтобы понять, что это за устройство, запускают Nmap по найденному IP. Если видны 80/443 с веб-панелью и, например, открыт 22 (SSH), можно уверенно предположить роутер или точку доступа, а не принтер.

Дальше действия должны быть короткими:

• временно изолировать порт (shutdown или перенос в карантинную VLAN)
• через офис/службу безопасности найти владельца: кто и зачем подключил устройство
• принять решение: легализовать (учесть, настроить) или удалить
• обновить правила: где можно ставить Wi‑Fi, кто согласует, как маркируются устройства

В отчете фиксируют итог: что нашли (MAC/IP/порт), причина появления, какие меры приняли и что поменяли в регламенте, чтобы подобное ловилось раньше и решалось без споров.

Следующие шаги: закрепить процесс и подготовить инфраструктуру

Процесс должен «жить» в понятном месте: где он ведется, кто отвечает за разбор и как выглядит готовый результат.

Минимальный регламент на 1 страницу

Сделайте короткий документ, который можно открыть в любой момент и быстро понять, что делать:

• роли: кто смотрит отчеты (ИБ), кто проверяет на сети (эксплуатация), кто принимает решение (владелец сегмента)
• сроки реакции: например, «критичные сегменты - в течение 4 часов», «офис - до конца дня»
• список отчетов: 2-3 понятных сводки без «простыней»
• правила эскалации: когда блокируем порт сразу, а когда сначала уточняем у подразделения
• исключения: принтеры, переговорные панели, тестовые стенды - кто их согласует и как они помечаются

Начните с малого и расширяйте охват

Не пытайтесь охватить всю сеть за неделю. Практичнее начать с 1-2 сегментов, где риск и польза очевидны: офисная сеть и серверная. В офисе быстрее всплывают «левые» точки доступа и домашние роутеры, а в серверной - неожиданные устройства в стойках и на управляемых VLAN.

Дальше решите, где будет работать мониторинг и где хранить данные: отдельный небольшой сервер, виртуальная машина в существующем кластере или выделенный узел в ЦОД. Заранее продумайте резервное копирование конфигураций, сроки хранения логов (хотя бы 30-90 дней) и доступы по принципу «минимально необходимого».

Если задача упирается не только в инструменты, но и в инфраструктуру и поддержку (сервер, рабочие места, учет, сопровождение), имеет смысл подключить системного интегратора. Например, GSE.kz как производитель и интегратор может помочь собрать основу под мониторинг и инвентаризацию (включая локально произведенные серверы и рабочие станции) и закрепить процесс так, чтобы он не держался на одном человеке.