Пентестер держит стенды и трофеи: своя лаборатория на арендованном сервере

MAATRIX

Чтобы легально тестировать защищённость систем по договору с заказчиком, пентестеру нужно постоянно тренироваться на уязвимых стендах — поднимать заведомо дырявые машины, проходить CTF-площадки, отрабатывать новые техники в безопасной песочнице. Держать это на рабочем ноутбуке — плохая идея сразу по нескольким причинам: от конфликта с корпоративным VPN и антивирусом до банального риска, что уязвимая VM окажется в одной сети с рабочими файлами. Разберём, почему отдельный арендованный сервер решает эту задачу лучше, чем локальная машина, и как выглядит такая лаборатория на практике.

Почему рабочий ноутбук — плохое место для уязвимых стендов

У ноутбука пентестера обычно уже есть основная нагрузка: рабочая почта, VPN до инфраструктуры заказчика, корпоративные пароли, иногда — материалы текущего проекта. Поднимать рядом с этим заведомо уязвимые виртуалки — значит намеренно создавать риск для собственного рабочего окружения.

Проблема не абстрактная. Уязвимая VM, которую вы разворачиваете для тренировки, по определению имеет открытые дыры — это её смысл. Если она в одной локальной сети с рабочей машиной (а на ноутбуке через мост virtualbox/VMware она обычно именно там и оказывается), любая ошибка в сетевых настройках виртуализации потенциально открывает путь от учебного стенда к реальным данным. Добавьте сюда корпоративный EDR/антивирус, который либо блокирует инструменты тестирования как вредоносные, либо создаёт логи и алерты, которые потом придётся объяснять службе безопасности своей же компании.

Есть и более приземлённая причина — ресурсы. Полноценная лаборатория из нескольких уязвимых машин, атакующего хоста и сетевого сегмента между ними ощутимо грузит CPU, RAM и диск. На ноутбуке, где параллельно открыт браузер с двадцатью вкладками и IDE, это заканчивается тем, что лаборатория живёт максимум пару часов, а потом удаляется до следующего раза — то есть по факту не используется.

Изоляция как основной принцип

Ключевая идея отдельной лаборатории — она физически и сетево не пересекается с рабочим окружением. Арендованный сервер для тренировочных стендов не имеет доступа к рабочей почте, корпоративным системам заказчиков, VPN до их инфраструктуры. Это отдельная машина с отдельным набором учётных данных, живущая своей жизнью.

Практическая схема выглядит так:

• сервер стоит отдельно от локальной сети и от рабочего ноутбука — доступ только через SSH или VPN до самого сервера, не «сквозь» него куда-то ещё;
• на сервере поднимается гипервизор или Docker/контейнеризация для изоляции стендов друг от друга;
• сетевые сегменты стендов не имеют выхода наружу, кроме управляющего интерфейса, которым вы подключаетесь;
• рабочие проекты (данные заказчиков, отчёты, переписка) физически хранятся в другом месте — на другом сервере или в другом каталоге с другими правами доступа, без сетевой связности с лабораторией.

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

Что развернуть под учебные стенды

Технически лаборатория пентестера — это гипервизор плюс набор виртуальных машин или контейнеров с намеренно уязвимой конфигурацией. Вариантов организации несколько, и они не взаимоисключающие:

Гипервизор с виртуальными машинами. Proxmox VE или чистый KVM/libvirt на арендованном сервере дают возможность держать несколько изолированных VM с разными ОС и уязвимыми сервисами, переключаться между снапшотами, поднимать целые сети из нескольких машин (например, «внешний периметр + внутренняя сеть» для отработки продвижения по сети). Это ближе всего к реальным условиям на выезде к заказчику, где инфраструктура тоже состоит из нескольких сегментов.

Контейнеры для быстрых учебных задач. Docker удобен, когда нужен один конкретный уязвимый сервис — веб-приложение с известной уязвимостью, устаревшая версия CMS, сервис с неправильной конфигурацией. Поднять, потренироваться, снести контейнер — минуты, а не часы на разворачивание VM.

Сетевая топология между стендами. И для VM, и для контейнеров важно продумать сеть заранее: отдельный виртуальный свитч/bridge под лабораторию, без маршрута наружу, кроме вашего управляющего подключения. В Proxmox это отдельный vmbr-интерфейс без выхода на внешний, в Docker — user-defined network с internal: true.

Пример изолированной сети для учебного стенда в docker-compose:

services:
  vulnerable-app:
    image: some-vulnerable-app:latest
    networks:
      - lab-net
    # порт наружу НЕ пробрасываем — доступ только внутри lab-net

networks:
  lab-net:
    driver: bridge
    internal: true   # без выхода в интернет и в другие сети хоста

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

Снапшоты вместо переустановки

Уязвимый стенд по своей природе одноразовый — после успешной атаки или неудачного эксперимента его состояние часто нужно откатить назад, а не разбирать руками, что где сломалось. Снапшоты решают это за секунды вместо часов на переустановку.

Логика простая: разворачиваете стенд в чистом состоянии, снимаете снапшот сразу после установки и базовой настройки. Дальше работаете, ломаете, эскалируете привилегии — а после разбора результата откатываетесь к снапшоту и повторяете с новым подходом или переходите к следующей задаче. Это особенно ценно при подготовке к сертификациям с практическими экзаменами, где важно прогнать один и тот же сценарий несколько раз до автоматизма.

У снапшотов есть и обратная сторона, о которой стоит знать заранее: они не бесплатны по месту на диске и могут заметно проседать по производительности диска, если копятся цепочкой без очистки. Мы разбирали механику подробнее в статье про то, как устроены снапшоты в Proxmox — если лаборатория живёт на Proxmox, это стоит прочитать до того, как снапшоты станут привычкой, а не осознанным решением.

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

Где хранить находки и материалы по проекту

Здесь важно разделить два разных типа данных, которые пентестер накапливает в работе, и не смешивать их физически.

Учебные материалы и тренировочные стенды — это то, что живёт в изолированной лаборатории. Их не жалко потерять, они не содержат чужих данных, и единственный риск — если стенд «утечёт» наружу и станет вектором атаки на что-то реальное. Для них изоляция сети важнее шифрования.

Рабочие находки по проектам заказчиков — отчёты об уязвимостях, скриншоты, логи с реальными данными, учётные записи, полученные в ходе легального теста по договору — это совершенно другая категория. Она подпадает под условия договора с заказчиком (NDA, сроки хранения, порядок уничтожения после сдачи отчёта) и должна храниться отдельно от учебной лаборатории, с шифрованием диска и ограниченным доступом. Смешивать эти два хранилища на одном сервере без разделения — плохая практика: если тренировочный стенд когда-нибудь скомпрометирует сеть лаборатории, рабочие материалы заказчика не должны оказаться рядом.

Для учётных данных, которые накапливаются в процессе — тестовые логины к стендам, ключи к CTF-площадкам, служебные пароли самой лаборатории — удобно использовать отдельный self-hosted менеджер паролей вместо файла passwords.txt в домашней папке. Мы разбирали разворачивание такого сервиса в статье про бэкап и восстановление Vaultwarden — тот же принцип: пароли живут в зашифрованном хранилище с бэкапом, а не в текстовом файле, который легко забыть на неправильном диске.

Отдельно про сам отчёт заказчику по итогам легального теста — это уже не про лабораторию, а про безопасную передачу чувствительного документа, и это отдельная большая тема с шифрованием и правами доступа.

Доступ к серверу лаборатории

Раз сервер лаборатории содержит инструменты тестирования и потенциально чувствительные результаты тренировок, доступ к нему стоит настраивать так же аккуратно, как к любому рабочему серверу — не «на скорую руку, это же просто учебная песочница».

Базовый набор:

• вход по SSH-ключу, пароль отключён — если раньше не настраивали, у нас есть разбор частых ошибок при переходе на SSH-ключи;
• отдельный непривилегированный пользователь для повседневной работы, root — только через sudo при необходимости;
• файрвол, который закрывает всё, кроме управляющего порта SSH и, при необходимости, VPN-порта до самой лаборатории — сеть уязвимых стендов при этом остаётся внутренней и наружу не торчит вообще;
• если лабораторией пользуется не только один человек (например, небольшая команда пентестеров тренируется вместе) — отдельные учётки на хосте вместо одного общего логина, чтобы было понятно, кто что запускал.

Пример базового правила ufw, которое оставляет открытым только управляющий доступ:

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp comment 'ssh admin'
ufw enable

Сеть самих учебных стендов при этом не описывается правилами файрвола хоста наружу вообще — она изолирована на уровне гипервизора или Docker-сети, как в примере выше, и файрвол хоста её просто не видит снаружи.

Легальность: где проходит граница

Важно проговорить это прямо, без недомолвок: всё, что описано выше, — про легальную деятельность. Лаборатория пентестера — это заведомо уязвимые машины, которые вы сами разворачиваете для тренировки, официальные CTF-площадки и учебные платформы, и работа по реальным проектам строго в рамках подписанного договора с заказчиком (SOW, scope of work, официальное разрешение на тестирование). Ничего из этого не имеет отношения к несанкционированному доступу к чужим системам — это уголовно наказуемо в большинстве юрисдикций и не является темой этой статьи.

Отдельный арендованный сервер, о котором мы говорим, не «помогает обойти закон» — он помогает организовать легальную тренировочную и проектную работу аккуратнее, чем это получится на одном ноутбуке вперемешку с личными файлами. Если вы держите сервер за рубежом для рабочих задач как ИП или самозанятый из России, у нас есть отдельный разбор, законно ли держать сервер в США для бизнеса из РФ — общие принципы там применимы и к серверу в Великобритании.

Если тестовая площадка или CTF требуют доступа с определённой геолокации, или заказчик просит тестировать доступность сервиса из конкретного региона — учитывайте это при выборе локации сервера, но это уже частность конкретного проекта, а не общее правило для лаборатории.

Частые вопросы