Лаборатория сканирования уязвимостей Nessus — Azure

Полный жизненный цикл управления уязвимостями — сканирование, обнаружение, исправление, проверка — выполненный в моей лабораторной среде Azure Active Directory с использованием выделенного сканера Nessus, развернутого через Terraform.

Что демонстрирует эта лаборатория

Я развернул выделенную виртуальную машину сканера на Ubuntu 24.04 в своей существующей лабораторной среде Azure AD, выполнил неаутентифицированное базовое сканирование и аутентифицированное сканирование контроллера домена, файлового сервера и присоединённого к домену клиента, проанализировал результаты, устранил уязвимость высокого уровня серьёзности (CVE-2013-3900) с помощью усиления реестра через PowerShell и подтвердил исправление повторным сканированием. Это полный рабочий процесс, который корпоративные программы управления уязвимостями выполняют непрерывно.

	Неаутентифицированное базовое	Аутентифицированное сканирование
Находки	35	64
Видимость	Только внешняя поверхность атаки — взгляд злоумышленника	Внутри ОС — уровни исправлений, конфигурация реестра, локальные проверки
Аутентификация	Не удалась (все 3 хоста)	Учётные данные Windows через NTLMv2, никогда не передаются в открытом виде
Время сканирования	15 минут	23 минуты

Этот скачок в количестве находок — главный аргумент в пользу аутентифицированного сканирования: уязвимость CVE-2013-3900 высокого уровня серьёзности, которую я устранил в этой лаборатории, является локальной проверкой, которую неаутентифицированное сканирование вообще не могло увидеть.

Архитектура

Диаграмма архитектуры Выделенный сканер NESSUS01 в подсети Subnet-Servers с аутентифицированными путями сканирования ко всем трём целям Windows. Панель управления доступна только через SSH-туннель с рабочей станции администратора — порт 8834 никогда не открывается публично.

Сканер подключается к существующей виртуальной сети лаборатории из серии Enterprise Azure Infrastructure Automation, развёрнут как независимая конфигурация Terraform с собственным удалённым состоянием.

Хост	Роль	ОС	Частный IP
NESSUS01	Сканер уязвимостей	Ubuntu 24.04 LTS	10.0.1.8
DC01	Контроллер домена (lab.local)	Windows Server 2025	10.0.1.5
FS01	Файловый сервер	Windows Server 2025	10.0.1.6
CLIENT01	Рабочая станция, присоединённая к домену	Windows 11 Pro	10.0.1.7

Архитектурные решения, которые я принял:

Выделенная виртуальная машина сканера вместо установки Nessus на цель. Корпоративные сканеры размещаются как независимые сетевые устройства с беспрепятственным обзором целей — сканирование с хоста, который также является целью, искажает результаты.
Источники данных Terraform для существующей инфраструктуры. Конфигурация сканера ссылается на существующую виртуальную сеть и подсеть через блоки data, не дублируя их, с изолированным состоянием в собственном ключе nessus-scanner.tfstate, чтобы сканер можно было создавать и уничтожать, не затрагивая основное состояние лаборатории.
Веб-интерфейс Nessus (порт 8834) никогда не открывается публично. NSG разрешает только SSH (22) с моего административного IP; я получаю доступ к интерфейсу через SSH-туннель (ssh -L 8834:localhost:8834). Открытость плоскости управления — главная причина компрометации сканеров.
Только аутентификация по SSH-ключам — пара ключей ed25519, без аутентификации по паролю на сканере.

Фаза 0 — Предстартовая проверка безопасности (Практикуйте то, что сканируете)

Перед развёртыванием я проверил существующие правила NSG — и обнаружил именно ту неправильную конфигурацию, для выявления которой и существует эта лаборатория: правило RDP разрешало источник * (любой IP в интернете).

NSG до усиления Предстартовая проверка: запрос az network nsg list обнаруживает правило Allow-RDP-3389, открытое для любого источника (*).

Я ограничил его своим текущим публичным IP перед продолжением:

az network nsg rule update -g RG-FileServerLab --nsg-name NSG-RDP \
  -n Allow-RDP-3389 --source-address-prefixes $(curl -s ifconfig.me)

NSG после усиления То же правило после устранения — источник ограничен одним административным IP.

Обнаружение и устранение уязвимости в собственной среде перед тем, как направить на неё сканер — это переход от мышления «запускаю инструмент» к «занимаюсь безопасностью».

Фаза 1 — Развёртывание сканера с помощью Terraform

Пять ресурсов — публичный IP, NSG, сетевой интерфейс, привязка NSG и виртуальная машина Ubuntu — развёрнуты менее чем за две минуты:

terraform apply: 5 добавлено, 0 изменено, 0 уничтожено. Выходные данные содержат готовую к использованию команду SSH.

Затем я подключился по SSH и выполнил безголовую установку Nessus Essentials 10.12.1:

SSH-сессия сканера Первое SSH-подключение к NESSUS01 с аутентификацией по ключу — Ubuntu 24.04 работает на 10.0.1.8, готов к безголовой установке Nessus.

Фаза 2 — Неаутентифицированное базовое сканирование

Первое сканирование: без учётных данных — это то, что видит злоумышленник в сегменте сети.

Конфигурация базового сканирования Базовое сетевое сканирование, нацеленное на все три хоста: 10.0.1.5, 10.0.1.6, 10.0.1.7.

Результаты базового сканирования Базовые результаты: 35 находок на 3 хостах, столбец Auth показывает Fail — Nessus не смог войти, поэтому все результаты получены только из внешнего наблюдения.

Фаза 3 — Аутентифицированное сканирование

Аутентифицированное сканирование является корпоративным стандартом для внутреннего управления уязвимостями. Я подготовил цели Windows, включив службу Remote Registry и открыв необходимые группы правил брандмауэра в профиле Domain:

Set-Service -Name RemoteRegistry -StartupType Automatic
Start-Service RemoteRegistry
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -Profile Domain
Set-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" -Enabled True -Profile Domain

nessus-vulnerability-scanning-lab

Популярное