Короткий ответ
Изолировать WS-042 / host.example = убрать сеть, не убирать питание. Способы по предпочтению: access-порт shutdown / quarantine VLAN, отключение vNIC, физический кабель, Wi‑Fi off. Не shutdown /s, не poweroff, не reset гипервизора, не disk wipe, не Safe Mode reboot «почистить». Диск оставить подключённым. Исключение: физическая угроза пожара/снятия сервера ворами — тогда иные приоритеты.
Зачем: RAM и незакрытые журналы живут, пока есть питание. Сеть кормит C2 и шифрование шаров.
Симптомы и как отличить
Когда изоляция нужна: подтверждённый malware, ransomware, C2, сканер с хоста, скомпрометированный сервер.
Когда не путать:
| Действие | Это изоляция? | Риск |
|---|---|---|
| Кабель LAN out, питание on | да | потеря текущих TCP, это ок |
Stop-VM / virsh destroy | нет, это стоп CPU/RAM | потеря памяти |
| Airplane mode + кабель | да | ок |
| BitLocker wipe / reset TPM | нет | уничтожение ключей/данных |
| Disable NIC в ОС | да, но malware может включить | лучше порт коммутатора |
Возможные причины
- Reboot вместо кабеля.
- Выключили VM.
- Отрезали iSCSI.
- Поставили хост в VLAN без шлюза, но SMB через второй NIC жив.
- Wi‑Fi остался.
- Пользователь воткнул кабель обратно.
Диагностика
- Сколько NIC? USB-док, Wi‑Fi, VPN-адаптер.
- Это VM? Какой vSwitch?
- Есть ли out-of-band?
- Не является ли хост единственным DNS/DC? (изолировать DC — отдельное, болезненное решение)
Get-NetAdapter | Format-Table Name, Status, MacAddress, LinkSpeed
Get-NetIPAddress -AddressFamily IPv4ip -br a
nmcli dev statusРешение
Сценарий A. Физический ПК WS-042
- Консоль/человек на месте: Ethernet вынуть, Wi‑Fi off.
- Если человека нет: порт коммутатора
shutdownили VLAN quarantine без маршрута на FS/DC/backup. - Питание кнопкой не жать.
- Наклейка «IR, не включать в сеть».
Quarantine лучше, чем чёрная дыра, если нужен сбор на IR-коллектор в том же VLAN карантина. Часто проще полный off сети и съём с USB/консоли.
Сценарий B. VM
Отключить vNIC в гипервизоре (не внутри гостя). Не Save/Restore как «изоляция». Snapshot диска можно после сети down, если гипервизор доверенный.
Сценарий C. Linux host.example, несколько NIC
Режьте все, включая management, кроме согласованного OOB. Иначе C2 уйдёт в BMC-сеть, если она маршрутизируется (не должна).
# внутри гостя — запасной вариант, если нет гипервизора
sudo ip link set eth0 down
sudo ip link set eth1 down
# не poweroffWindows запасной:
Get-NetAdapter | Disable-NetAdapter -Confirm:$falseMalware с правами админа может вернуть NIC. Порт коммутатора надёжнее.
Сценарий D. Нужен точечный стоп исходящего, хост критичен
Редко: оставить NIC, но ACL «deny any any» кроме IR. Сложно ошибиться. Для рабочей станции не надо. Для платёжного шлюза — решение владельца, не дежурного в одиночку.
Два NIC, VPN-адаптер и «изолировали не то»
Перед портом коммутатора снимите MAC всех адаптеров: док-станция даёт второй Ethernet, Wi‑Fi живёт после вынутого кабеля, Always-On VPN создаёт интерфейс, который снова ходит в LAN как 10.0.10.55 inner. На VM отключайте vNIC в гипервизоре: Disable-NetAdapter внутри гостя malware вернёт. Не отключайте iSCSI/FC, приняв их за «ещё одну сеть» — потеряете диск, то есть данные, которые берегли.
Питание ноутбука: подключите зарядку без LAN, иначе батарея умрёт и RAM с ней. Пользователь ivan.petrov не «проверит почту с LTE» — заберите SIM/модем. OOB iLO не должен маршрутизироваться в интернет; если должен был быть management-only и вдруг NAT — это дыра, не канал сбора. После изоляции наклейте на корпус: кто сорвёт кабель обратно, сорвёт IR.
Сервер-платёжка: quarantine VLAN с ACL «только коллектор» вместо полного down — решение владельца, записанное, не импровизация дежурного.
Как проверить, что проблема устранена
Изоляция — мера, не победа над атакой.
- С коллектора/FS нет трафика этого MAC/IP.
- Ping к
10.0.10.55с LAN не идёт (или только из карантина). - Хост отвечает на консоли, диск на месте, uptime не сброшен.
- Второй NIC/Wi‑Fi тоже мёртв.
- Пользователь не воткнул кабель (контроль).
Get-NetAdapter | Format-Table Name, StatusНа коммутаторе: порт down / VLAN 999.
Дежурный заранее знает, как найти порт по MAC WS-042 и не путает access с uplink. Запрет второго Wi‑Fi политикой. Учение: изолировать стендовую VM за две минуты без poweroff. Пользователь ivan.petrov не возвращает кабель «чтобы допечатать». Адрес 10.0.10.55 после down не должен отвечать с LAN.
Если не помогло
- Трафик жив — второй интерфейс, Wi‑Fi, модем USB, другой хост с тем же IP (конфликт).
- VM vNIC отключили не тот — проверьте MAC.
- Отрезали DC, офис лёг — это цена; не включайте DC в грязный VLAN «на минуту». Поднимайте пользователей на второй DC, если он чист.
- Хост выключился сам (батарея ноута) — потеря RAM, дальше диск; подключите питание без сети.
Профилактика
- OOB/iLO заранее.
- На коммутаторах готовый quarantine VLAN.
- Дежурный знает, как найти порт по MAC.
- Запрет второго Wi‑Fi на корпоративных ПК политикой.
- Учение: изолировать стендовую VM за 2 минуты.
FAQ
Можно ли просто выдернуть питание?
Только если идёт разрушение диска и нет другого стопа — край. RAM умрёт. Для ransomware на шарах кабель сети важнее питания ПК.
Sleep / hibernate?
Hibernate пишет RAM на диск и меняет состояние — обычно не надо. Sleep может держать RAM, но политики пробуждают по сети (WoL) — отключите WoL на порту.
Изолировать весь users VLAN?
Если источник неизвестен и шары горят — как сдерживание, да, с владельцем. Это уже не «узел».
Linux bonding
Спускайте bond и слейвы, иначе один slave останется up.
После изоляции нужен RDP «снять логи»
Нет. Консоль, USB, гипервизор. RDP требует сеть.