Короткий ответ

В LAN появился хост 10.0.10.55, которого нет в инвентаре: найдите MAC, порт коммутатора/Wi‑Fi AP, DHCP lease (имя, vendor class). До идентификации изолируйте: карантин VLAN, shutdown порта, ACL «не ходить на DC/FS». Не пускайте его в admin$ «проверить, что это». Не сканируйте чужие сети; свой периметр — только свои диапазоны.

Похожие ветки: исходящий трафик, lateral, DNS.

Симптомы и как отличить

  • Алерт: новый MAC в 10.0.10.0/24.
  • Get-DhcpServerv4Lease / Kea/isc: hostname android-... / пусто.
  • Пользователи: «подключил личный роутер».
  • IDS: сканирование с 10.0.10.55.
НаходкаНе «чужой атакующий»Действие
Новый принтер по заявкезабыли инвентарьвнести, не банить навсегда
Телефон в корпоративном Wi‑FiBYOD политикаVLAN гостей
IP конфликт, «неизвестно» плаваетдва DHCPсеть, не IR malware
VM vNIC после клонадубль MACгипервизор

Возможные причины

  1. Личный ноут/телефон в розетке access VLAN.
  2. Гостевой Wi‑Fi слили в users VLAN ошибкой ACL.
  3. Неучтенный IoT (камера, Smart TV).
  4. Компрометация: точка присутствия атакующего.
  5. Клон VM / сбой гипервизора, старый MAC в ARP.
  6. VPN inner IP, который мониторинг рисует как «новый в LAN» — сверьте пул.

Диагностика

1. ARP/соседи с двух точек

С WS-042 (если он свой) или с jump:

Get-NetNeighbor -IPAddress '10.0.10.55'
arp -a 10.0.10.55
ip neigh show 10.0.10.55
arp -n 10.0.10.55

2. DHCP

Windows DHCP:

Get-DhcpServerv4Lease -IPAddress '10.0.10.55' | Format-List

Kea/isc на Ubuntu host.example (путь как у вас): журнал lease, не «взлом DHCP».

3. Коммутатор — CAM/FDB

На access-свитче (команды вендора штатные): поиск MAC → порт. Зафиксируйте stack/порт/Gi1/0/12, VLAN, PoE (есть ли потребление — намёк на физику).

Wi‑Fi: контроллер, какой AP и SSID.

4. Что это вещает

Только пассивно и своим сканером на свой IP, если политика позволяет:

# с IR- hop, свой диапазон
ip -s link
# nmap своего хоста: не SYN-flood, один таргет
nmap -Pn -sS -T4 --top-ports 20 10.0.10.55

Не пишите кастомные эксплойты «опознать WinRM». Баннер SSH/HTTP достаточно. Если это чужой роутер с DHCP — увидите второй DHCP в VLAN (критично).

Решение

Сценарий A. Порт известен, устройство не из инвентаря

  1. Перевести порт в quarantine VLAN без маршрута на DC/FS или shutdown access-порта.
  2. Найти физически (подпись розетки, PoE).
  3. Идентификация с владельцем этажа.
  4. Гостевые — только guest SSID.

Сценарий B. Wi‑Fi клиент

Блок MAC на контроллере, снять с корпоративного SSID. 802.1X не обходить «для удобства».

Сценарий C. Не нашли порт (MAC плавает / спуф)

Ищите по ARP на шлюзе, DHCP snooping binding, IP source guard если уже включены. Спуф с вашего WS-042 — тогда это компрометация ПК, не «новый планшет».

Сценарий D. Второй DHCP

Выключить порт нарушителя немедленно: это ломает офис. Потом разбор.

DHCP snooping и ложный «свой» принтер

До идентификации не выдавайте устройству маршруты к DC, WS-042 пользователей и файловым шарам. На шлюзе достаточно deny from 10.0.10.55 к 10.0.20.0/24 (серверы) как временный ACL, если порт коммутатора ещё ищут. DHCP: сверьте vendor-class и client-fqdn; пустой hostname плюс OUI одноплатника — типичный «принесли Raspberry». Легитимный принтер по заявке всё равно сначала quarantine: заявки в IT часто отстают от кабеля.

Если MAC прыгает между портами — это не «Wi‑Fi роуминг» на access-свитче без контроллера, это либо петля, либо спуф. Включите (если ещё не) DHCP snooping на VLAN users и не доверяйте ARP до DAI, когда зрелость позволит. Пользователь ivan.petrov «это мой телефон» не отменяет карантин: BYOD — guest SSID, не розетка Access VLAN 10. Документируйте розетку/патч в CMDB в том же тикете, иначе через неделю порт снова откроют «временно».

Не сканируйте устройство агрессивными NSE-скриптами «на всякий»: для IR хватит top-ports и баннера. Если оно отвечает как шлюз с DHCP — стоп всего порта без nmap.

Как проверить, что проблема устранена

  • Lease 10.0.10.55 нет или в quarantine.
  • CAM не показывает MAC на users VLAN.
  • Нет трафика этого MAC на DC/FS (лог шлюза).
  • Инвентарь обновлён или устройство изъято.
  • Если сканировал — нет продолжения после shutdown.

На коммутаторе сохраните вывод CAM/FDB в тикет до shutdown порта: после down MAC исчезнет из таблицы, и вы не докажете, какая розетка это была. Если PoE на порту есть — устройство физическое, не только ARP-спуф с WS-042.

Если не помогло

  • MAC исчез и появился с другим IP — DHCP + спуф, смотрите snooping.
  • Порт uplink: вы тронули не то — откатите, ищите access.
  • Устройство за VPN — это не LAN, идите в VPN.
  • Легитимный сканер SOC без заявки — процесс, не только техника.

Профилактика

  • 802.1X / NAC, гостевой VLAN по умолчанию.
  • DHCP snooping, DAI где зрелость позволяет.
  • Инвентарь MAC принтеров и IoT.
  • Алерт нового MAC в server VLAN — выше приоритет, чем в users.
  • Запрет пользовательских мини-роутеров.

FAQ

Можно ли просто зарезервировать ему IP и забыть?

Нет. Резерв DHCP не делает устройство доверенным.

Стоит ли сразу обходить этаж с ноутбуком-анализатором?

Сначала порт в карантин. Физика — когда порт известен. Не оставляйте чужой хост в прод, пока ищете тумбочку.

nmap не этичен?

По своему адресу из своей IR-политики — рабочий инструмент. Чужие диапазоны и «полный exploit scan» — нет.

Устройство — IP-телефон из коробки

Внести в инвентарь, VLAN voice, не users. До этого — quarantine.

Linux host.example увидел соседа в ARP, Windows DHCP пуст

Статический IP. Тем важнее CAM: кто поставил адрес руками.