Pentest-лаб на Proxmox: VLAN-изоляция и Observium

За три года я собрал больше десяти стендов на Proxmox VE - от двухмашинных до AD-полигонов с несколькими контроллерами домена. Дважды ловил утечку трафика из лаборатории в домашнюю сеть: дефолтный vmbr0 остался привязан к физическому интерфейсу, и широковещательный мусор полез туда, куда не должен. Заметил не руками - Observium показал аномальный объём ARP-запросов на интерфейсе домашнего сегмента ровно в тот момент, когда из Kali работал Responder. Совпадение по таймлайну - стопроцентное.

Каждый гайд по сборке pentest-лаборатории учит ставить Kali и Metasploitable. Ни один русскоязычный не объясняет, как убедиться, что изоляция реально работает. Эта статья закрывает пробел: архитектура VLAN-сегментов, конкретные конфиги бриджей, виртуальный маршрутизатор между сегментами и SNMP-мониторинг через Observium, который покажет утечку раньше, чем она станет проблемой.

Сетевая архитектура pentest-лаборатории на Proxmox VE​

Совет «поставь Kali + Metasploitable в одну Internal Network» работает для первого знакомства с nmap, но разваливается при масштабировании. Когда стенд вырастает до Active Directory с несколькими доменами и нужно отрабатывать LLMNR/NBT-NS Poisoning and SMB Relay (T1557.001, Credential Access) - широковещательный трафик из лабы попадает в домашнюю сеть и начинает отравлять резолвы на рабочем компьютере. Один автор на Habr потратил трое суток, пытаясь изолировать KVM-машины iptables/nftables на уровне хоста. Его вывод: «безопасность не должна зависеть от удачи». Правильный ответ - не фильтровать трафик постфактум, а не давать ему туда попасть изначально.

Proxmox VE решает это на уровне архитектуры: KVM-виртуализация, встроенный firewall, Linux-бриджи с поддержкой VLAN 802.1Q - всё через веб-интерфейс на порту 8006. В отличие от VirtualBox с его четырьмя режимами (NAT, Bridged, Internal, Host-Only), Proxmox даёт полноценное управление L2/L3-сегментацией без танцев с libvirt hooks.

Три VLAN-сегмента: атакующий, целевой, управление​

Минимальная рабочая архитектура для домашней лаборатории для пентестера - три изолированных сегмента. Похожую топологию с разделением на DMZ, internal и external использует Matt Glass в проекте для курсов Pluralsight - только у него три физических Dell PowerEdge, а здесь всё укладывается в один хост.

Сегмент ATTACK (VLAN 10, подсеть 10.10.10.0/24) - Kali Linux или Parrot OS. Отсюда идёт сканирование портов - Network Service Discovery (T1046, Discovery), эксплуатация уязвимых сервисов, перехват хешей через Responder. Маршрута в домашнюю сеть нет, выход в интернет - только через виртуальный маршрутизатор, и только когда это действительно нужно.

Сегмент TARGET (VLAN 20, подсеть 10.10.20.0/24) - уязвимые машины: Metasploitable 2/3, образы VulnHub, Windows Server в роли контроллера домена. Здесь отрабатываются Exploit Public-Facing Application (T1190, Initial Access), Pass the Hash (T1550.002, Lateral Movement) и дамп LSASS Memory (T1003.001, Credential Access). Сегмент полностью изолирован - попасть сюда можно только из ATTACK через маршрутизатор.

Сегмент MGMT (подсеть 192.168.1.0/24) - управляющая сеть. Только веб-интерфейс Proxmox и SSH. Ни одна VM из ATTACK или TARGET не имеет интерфейса в этом сегменте. Совпадает с домашней сетью или выделяется отдельно - зависит от вашей топологии.

Суть сегментации: VM в лабе физически не может отправить пакет в домашнюю сеть, потому что её бридж не связан с физическим интерфейсом. Не «правило запрещает», а «провода нет».

Настройка VLAN и бриджей для сетевой изоляции виртуальных машин​

На уровне Proxmox сетевые сегменты реализуются через Linux-бриджи (vmbr). Каждый бридж - виртуальный коммутатор, к которому подключаются сетевые интерфейсы VM.

Стандартная установка Proxmox создаёт один бридж vmbr0, привязанный к физическому интерфейсу (eno1, enp3s0 - зависит от железа). Этот бридж даёт VM прямой доступ в домашнюю сеть. Для pentest-лаборатории нужны дополнительные бриджи без привязки к физическим портам.

Конфигурация хранится в /etc/network/interfaces на Proxmox-хосте:
vmbr0 привязан к физическому порту eno1 и имеет IP для веб-интерфейса. vmbr1 - бридж для ATTACK, vmbr2 - для TARGET. bridge-ports none - трафик из бриджа физически не может покинуть хост. Вот и вся гарантия изоляции на L2-уровне. Никакой магии.

После редактирования применяйте конфиг командой ifreload -a, а не перезагрузкой - так сохраняется SSH-сессия, и вы не потеряете доступ при ошибке (а ошибки будут, поверьте).

Назначение VM на сегменты в Proxmox​

При создании VM в разделе Network указывается бридж. Kali подключается к vmbr1, Metasploitable - к vmbr2. Proxmox по умолчанию предлагает vmbr0 - один клик «Next» без смены бриджа, и целевая машина уже в домашней сети. Проверяйте каждую VM: Hardware → Network Device → Bridge. Каждую.

Если нужны VLAN-теги вместо отдельных бриджей - тег задаётся в поле «VLAN Tag» настройки сетевого интерфейса VM. VM с тегом 10 не увидит VM с тегом 20 без маршрутизатора: L2-изоляция на уровне 802.1Q. На Proxmox-форуме народ отмечает, что VLAN-зоны через SDN иногда чудят с SNAT и DHCP - для домашнего стенда отдельные бриджи надёжнее и нагляднее.

Когда что выбирать:

OPNsense как виртуальный маршрутизатор в proxmox лаборатории безопасности​

Между ATTACK и TARGET нужен маршрутизатор с firewall. Без него машины из разных бриджей не видят друг друга вообще - а нам нужен контролируемый доступ, не полная слепота. Matt Glass в своей лабе ставит pfSense между internal и DMZ. Я предпочитаю OPNsense (форк pfSense на FreeBSD) - обновляется активнее, веб-интерфейс не из 2008 года.

OPNsense как VM получает три сетевых интерфейса:


Ресурсы VM: 1 vCPU, 2 ГБ RAM, 16 ГБ диска - OPNsense на FreeBSD нетребовательна. Если нужен совсем минимум - pfSense тоже подойдёт, требования аналогичны.

Правила firewall между сегментами​

После установки OPNsense и назначения интерфейсов через веб-интерфейс создайте правила в Firewall → Rules:


Последнее правило - критическое. Даже если WAN-интерфейс OPNsense подключён к vmbr0, правило на WAN-интерфейсе должно явно блокировать доступ к подсети 192.168.1.0/24. Иначе VM из ATTACK теоретически доберётся до домашней сети через цепочку ATTACK → OPNsense → WAN → домашний роутер. Я на это наступал - не повторяйте.

По умолчанию OPNsense блокирует весь входящий трафик на OPT-интерфейсах. Это правильное поведение, сохраняйте его как базу и добавляйте разрешения точечно.

Proxmox firewall: второй рубеж изоляции​

OPNsense контролирует маршрутизацию между сегментами. Но Proxmox имеет собственный встроенный firewall на уровне гипервизора - независимый второй рубеж. Включается на трёх уровнях: Datacenter, Node, VM.

На уровне Datacenter → Firewall → Options: включите firewall, установите Input Policy в DROP, Output Policy в ACCEPT. Весь входящий трафик к хосту запрещён, кроме явно разрешённого.

Необходимые правила на уровне Datacenter:


На уровне VM firewall включается для каждого сетевого интерфейса отдельно. Для VM в TARGET добавьте правило DROP для исходящего трафика на 192.168.1.0/24 - двойная защита поверх OPNsense. Паранойя? Может быть. Но когда в TARGET крутится Metasploitable с 30 открытыми портами, лучше перебдеть.

Proxmox firewall работает на уровне iptables/nftables хоста, но управляется через конфиги в /etc/pve/firewall/. Не редактируйте iptables напрямую - Proxmox перезапишет правила при обновлении или перезапуске pve-firewall.

Мониторинг трафика в домашней лаборатории через Observium и SNMP​

Настроить изоляцию - полдела. Убедиться, что она работает после каждого изменения конфигурации - вторая половина, которую все пропускают. Я пропускал тоже, пока не словил тот самый ARP-шторм на домашнем сегменте. Observium - NMS на базе SNMP, визуализирует трафик на каждом интерфейсе хоста в реальном времени.

Развёртывание Observium как LXC-контейнера​

Observium не требует полноценной VM - хватает LXC-контейнера с 1 vCPU, 1 ГБ RAM, 20 ГБ диска. Контейнер подключается к vmbr0 (сегмент MGMT), чтобы опрашивать SNMP-агенты на Proxmox-хосте и OPNsense. Тот же подход, что у Matt Glass для DNS и email-серверов в его лабе: меньше ресурсов - та же функция.

Observium Community Edition ставится на Debian/Ubuntu как LAMP-стек (Apache, MySQL, PHP) плюс скрипты discovery.php и poller.php по cron. Инструкция на docs.observium.org - пересказывать спеку в сотый раз не вижу смысла. Но есть нюанс: community-версия не поддерживает алертинг через email, только визуальное отображение. Для полноценных алертов нужна подписка или переход на Zabbix - он тяжелее в настройке, зато бесплатен в enterprise-функциях.

Настройка SNMP-агентов​

На Proxmox-хосте установите пакет snmpd и настройте /etc/snmp/snmpd.conf:
Строка rocommunity задаёт community string (замените lab_monitor на свой - оставлять дефолтный public это как оставить пароль admin) и ограничивает SNMP-запросы подсетью управления. После systemctl restart snmpd добавляете хост в Observium: Devices → Add Device → IP хоста, community string, SNMP v2c.

На OPNsense SNMP включается через Services → SNMP → Enable с тем же community string.

Что мониторить для обнаружения утечек​

Через 5–10 минут после добавления устройства Observium начинает отображать все сетевые интерфейсы хоста в разделе Ports - включая vmbr0, vmbr1, vmbr2 и физический eno1.

Трафик на vmbr0/eno1 - здесь допустим только управляющий трафик: SSH, HTTPS на порт 8006, SNMP-поллинг. Если при запуске nmap из Kali график трафика на vmbr0 совпадает по времени с всплеском на vmbr1 - изоляция нарушена. Именно так я поймал свою утечку: два графика синхронно пошли вверх.

Соотношение трафика на vmbr1 и vmbr2 - при активном сканировании трафик на обоих бриджах растёт (ATTACK отправляет, TARGET отвечает). На vmbr0 при этом трафик должен оставаться стабильным.

ARP-таблица на хосте - выполните arp -n на Proxmox-хосте. Если в таблице появились MAC-адреса VM из TARGET-сегмента с IP из подсети 192.168.1.0/24 - какой-то интерфейс попал не в тот бридж.

Настройте визуальный порог в Observium: если пропускная способность vmbr0 превышает 10 Мбит/с при работающей лабе - триггер для ручной проверки. В штатном режиме управляющий трафик редко превышает 1–2 Мбит/с.

Проверка изоляции и типичные ошибки сборки pentest-лаборатории​

DHCP от домашнего роутера. Если интерфейс VM случайно попал в vmbr0, DHCP домашнего роутера выдаст IP, шлюз и DNS - VM получит полный доступ в интернет без единого предупреждения. На домашнем роутере полезно проверять список DHCP-leases после каждой сессии.

По моему опыту, первые две ошибки - причина подавляющего большинства утечек трафика из лабораторий. Observium ловит обе через аномалию на vmbr0, но только если мониторинг настроен до начала работы с машинами.

Главный паттерн, который я вижу в чужих стендах: изоляция настроена один раз и больше не проверяется. Добавили новую VM - забыли сменить бридж. Обновили Proxmox - firewall-правила сбросились. Пересоздали контроллер домена - случайно привязали к vmbr0. Задача не в том, чтобы настроить сетевую изоляцию однажды, а в том, чтобы она оставалась рабочей после каждого изменения.

Observium, Zabbix или любой NMS с SNMP-поллингом превращает «я думаю, что лаба изолирована» в «я вижу, что она изолирована - вот график трафика за последние сутки». Половина стендов, которые мне показывали коллеги для ревью, содержала минимум один забытый интерфейс или маршрут. Причём владельцы были уверены, что всё чисто. Мониторинг - не дополнительная фича для тех, кому нечем заняться, а базовая гигиена домашнего стенда для тестирования на проникновение. Запустите tcpdump -i vmbr0 -c 50 arp прямо сейчас. Если в выводе есть что-то кроме вашего рабочего компьютера - у вас та же проблема, с которой я начал эту статью.