Выделенный сервер для анализа вредоносного ПО: как устроить изолированную защитную лабораторию
В защитной лаборатории полезно начинать день с одного скучного вопроса: куда отсюда вообще можно попасть? На рабочий ноутбук аналитика? В корпоративную сеть? В интернет? К соседней виртуальной машине, где лежат результаты вчерашнего исследования?
Если ответ приходится искать уже после запуска подозрительного файла, лаборатория пока больше похожа на надежду. Надежда — замечательное человеческое качество, но в таблице маршрутизации ей делать нечего.
Выделенный сервер позволяет построить отдельную среду для исследования подозрительных файлов, проверки средств защиты и обучения специалистов реагированию на инциденты. На нём можно держать несколько гостевых систем, воспроизводить разрешённые сценарии и собирать результаты. Однако аренда целой машины сама по себе не делает эту работу безопасной и допустимой. У неё есть две независимые предпосылки: согласие провайдера на конкретный вид исследования и технически проверенная изоляция.
Поэтому разговор о тарифе здесь начинается позже обычного. Сначала нужно определить границы лаборатории. Процессор подождёт: даже сорок восемь ядер умеют терпеливо стоять в выключенной виртуальной машине.
Содержание
- Сначала условия размещения, затем выбор сервера
- Что именно должна изолировать песочница
- Почему контейнер не заменяет виртуальную машину для такого стенда
- Сеть без внешнего выхода: проверить нужно больше одного запрета
- Сколько памяти и ядер нужно серверу для анализа ПО
- Диски расходуют не только образцы, но и следы исследования
- Рабочий процесс важнее красивой панели песочницы
- Когда выделенный сервер для песочницы имеет смысл
Подберите конфигурацию для своего проекта
Характеристики, стоимость и условия подготовки выделенных серверов MAATRIX в России и США.
Выбрать выделенный серверСначала условия размещения, затем выбор сервера
В публичной оферте на сайте MAATRIX запрещены вредоносное ПО, вредоносный трафик и несанкционированные сканирования. Публичный документ ориентирован на VPS; из него нельзя самостоятельно вывести разрешение на хранение и запуск образцов на выделенном сервере. Изолированное защитное исследование необходимо предварительно письменно согласовать с провайдером, описав назначение среды и ограничения её сети.
До такого согласования разумно ограничиться проектированием лаборатории и работой с безопасными учебными материалами. Оплата тарифа не заменяет разрешения на конкретную деятельность. В письме провайдеру важнее понятное описание границ, чем внушительный список инструментов: кто отвечает за стенд, откуда поступают образцы, как исключён выход исследуемой среды наружу, как прекращается работа при нарушении изоляции.
Отдельно определяют право организации исследовать материалы. Файл из собственного инцидента, предоставленный заказчиком образец и случайная коллекция из интернета — разные ситуации с точки зрения происхождения, конфиденциальности и условий использования. Согласование аренды не решает вопросы доступа к чужим данным и лицензирования гостевых ОС.
Задача этой статьи — устройство защитной среды для уполномоченных специалистов. Она не предполагает разработку вредоносных программ, проверку их незаметности для защиты или взаимодействие с чужими системами. Вредоносный трафик за пределами стенда исключается.
Что именно должна изолировать песочница
Слово «песочница» создаёт уютное впечатление: ограда, несколько игрушек, всё под присмотром. В вычислительной среде это набор отдельных ограничений. Нужно разделить исследуемую систему, управляющую инфраструктуру, другие эксперименты, хранилище материалов и внешний мир.
Виртуальная машина полезна потому, что предоставляет отдельную гостевую ОС и позволяет возвращаться к подготовленному состоянию. Но остаются гипервизор, его интерфейсы управления, виртуальные устройства и средства обмена данными. Ошибка в их настройке может свести на нет правильную настройку гостевого firewall.
В руководстве NIST по предотвращению и обработке инцидентов с вредоносным ПО активный анализ рассматривается на изолированных тестовых системах, отдельно от рабочих компьютеров. Документ полезен как основа организации процесса; конкретные настройки современного гипервизора нужно сверять с его текущей документацией.
Первое практическое следствие: сервер лаборатории не совмещают с магазином, почтой, рабочими базами и инфраструктурой резервного копирования компании. Отдельная виртуальная машина на общем производственном хосте всё равно оставляет общий гипервизор и часть управления. Для исследования недоверенного кода такая экономия требует слишком дорогого доверия.
Второе следствие: физически отдельный сервер ещё не означает отдельную сеть. Если его виртуальный коммутатор связан с корпоративным сегментом, выделенное железо исправно доставит нежелательный трафик туда, куда ему разрешили. Изоляцию проверяют по фактическим путям связи, а не по названию услуги.
Почему контейнер не заменяет виртуальную машину для такого стенда
Контейнеры удобны для служебных компонентов: интерфейса учёта, обработки отчётов, отдельных вспомогательных сервисов. Но обычный контейнер использует ядро хостовой системы и не должен автоматически считаться достаточной границей для запуска неизвестного исполняемого кода.
Документация Docker по безопасности отдельно обращает внимание на поверхность атаки демона, влияние предоставленных полномочий и неполноту изоляции при сочетании настроек с уязвимостями ядра. Доступ к сокету управления Docker, привилегированный режим или смонтированные каталоги хоста особенно плохо сочетаются с недоверенным содержимым.
Поэтому гостевую систему для активного исследования обычно отделяют средствами аппаратной виртуализации, а её конфигурацию делают минимальной. Отключают ненужные общие папки, общий буфер обмена, перенос файлов через интерфейс гостя и подключение лишних устройств. Это сокращает число мостиков, о которых легко забыть после удобной настройки рабочего стола.
При этом виртуальная машина не даёт обещания абсолютной защиты от выхода за её пределы. Гипервизор обновляют, его службы ограничивают, управление отделяют от экспериментальной сети. Различия между механизмами изоляции подробнее разобраны в статье «Уровни изоляции: что теряется на каждом». Для лаборатории важно не название механизма, а то, какую конкретную границу он обеспечивает.
Сеть без внешнего выхода: проверить нужно больше одного запрета
Для рассматриваемой лаборатории исследуемые гостевые системы не получают маршрута в интернет или рабочую сеть. Если сценарию требуется сетевое окружение, его воспроизводят внутри разрешённого изолированного сегмента с контролируемыми учебными сервисами. Это позволяет наблюдать поведение без обращения к настоящим внешним адресатам.
Одного запрета входящих соединений мало: программа внутри гостя сама может инициировать исходящее соединение. Также недостаточно проверить только IPv4, оставив другую семью адресов без рассмотрения. DNS, прокси, дополнительные интерфейсы и автоматически создаваемые виртуальные сети способны открыть путь, которого не было на первоначальном рисунке.
Сегмент исследуемых систем не должен иметь доступ к управлению гипервизором. Аналитик подключается к управлению через отдельный защищённый путь, а исследуемая машина не получает паролей, ключей и доступа к этому пути. Если используется промежуточная административная система, на неё не переносят образцы для удобного двойного щелчка.
Настройки с названием host-only тоже нужно читать внимательно. Такой режим обычно предполагает связь гостя с хостом и, в зависимости от конфигурации, другими гостями. Это не синоним полного отсутствия любых связей. В официальном проекте Mandiant FLARE-VM после установки рекомендуют host-only и снимок VM, но эти шаги не заменяют проектирование всей лабораторной сети.
Проверку выполняют на чистой гостевой системе до загрузки образцов. Подтверждают отсутствие внешней доступности и закрытость управляющих интерфейсов, смотрят журналы на границах сегмента, отдельно проверяют разрешённые внутренние взаимодействия. После изменения сети проверку повторяют. Хорошее правило: пока границы стенда не подтверждены, активный эксперимент не начинается.
Сколько памяти и ядер нужно серверу для анализа ПО
Потребность считают по одновременным экспериментам, гостевым ОС и объёму собираемых данных. Один специалист, который последовательно исследует материалы, и группа с несколькими параллельными Windows- и Linux-машинами предъявляют разные требования. Число файлов в коллекции почти ничего не говорит о необходимом процессоре.
Представим условный стенд: четыре гостевые системы с выделенными 8 GB RAM каждая. Это уже 32 GB гостевой памяти. Дополнительно нужны память гипервизору, сборщикам наблюдений и файловому кэшу. Если для отдельной работы гостю требуется 16 GB, прежний расчёт перестаёт действовать. Это бюджетирование стенда, а не норматив расхода памяти на анализ одного файла.
При последовательной интерактивной работе полезны быстрые отдельные ядра. При независимых параллельных исследованиях возрастает ценность числа ядер и общей памяти. Для анализа больших дампов памяти существенны также скорость диска и свободное место для промежуточных результатов. Заканчивающийся накопитель способен остановить исследование раньше, чем процессор успеет проявить характер.
Из приведённой линейки ANKH с Ryzen 7600X, 6 ядрами, 64 GB DDR5 и 1 TB NVMe за $329 в месяц можно рассматривать как кандидата для небольшой лаборатории после согласования размещения и проверки нагрузки. PYLON с Ryzen 7950X, 16 ядрами, теми же 64 GB RAM и 1 TB NVMe за $429 даёт больше процессорных ресурсов для параллельной работы, но не увеличивает объём памяти или диска.
NECROPOLIS предлагает EPYC 7642, 48 ядер, 128 GB DDR4 и 2 × 1 TB NVMe за $529 в месяц. Он интересен при нескольких независимых рабочих средах и заметном потреблении памяти. При этом число ядер не является обещанием количества одновременных песочниц: каждой нужны гостевая ОС, место, наблюдение и понятный лимит ресурсов.
Российский CARTOUCHE с двумя Xeon E5-2680 v4, 28 физическими ядрами суммарно, 128 GB DDR4 и 2 × 600 GB SSD за $295 может быть кандидатом, когда важны российское размещение и объём памяти. У него меньше дисковая ёмкость; интерактивную скорость на этой платформе нужно проверять своей задачей. Указанные тарифы описывают оборудование, а не предоставляют разрешение на исследование вредоносного ПО.
Диски расходуют не только образцы, но и следы исследования
Сами подозрительные файлы иногда занимают удивительно мало места по сравнению с окружением. Основную ёмкость расходуют базовые образы ОС, рабочие копии, снимки, дампы памяти, сетевые записи и результаты наблюдений. При нескольких параллельных экспериментах этот объём растёт незаметно, пока свободное место не превращается в главный объект исследования.
Снимки полезны для возврата гостевой системы к известному состоянию. Однако они не заменяют независимую копию чистого базового образа и не доказывают, что управляющий хост не пострадал. Если есть признаки нарушения границы изоляции, простого отката гостя недостаточно: стенд останавливают и проверяют по процедуре реагирования.
Два диска NECROPOLIS допускают разные схемы использования, которые заранее согласуют с провайдером и выбирают при настройке. Зеркало из 2 × 1 TB даёт около 1 TB номинальной полезной ёмкости до накладных расходов, а не 2 TB. Оно помогает пережить отказ одного накопителя, но не отменяет ошибочное удаление, компрометацию или необходимость внешней копии важных результатов.
Для каждого исследования полезно задать сроки хранения материалов и наблюдений. Сырой дамп, проверенный отчёт и чистый образ ОС требуют разных режимов доступа. Всё, что поступило из исследуемого гостя, сначала остаётся недоверенным. Нельзя автоматически переносить его в обычную общую папку компании только потому, что файл называется report.
Процесс выдачи результата предусматривает проверку содержимого, минимально необходимый состав и безопасный формат для адресата. Образцы и потенциально активные вложения не смешивают с обычной документацией. Проблема слишком доверенного хранилища обсуждается и в материале «Почему бэкап, доступный с сервера, — это не бэкап»: управляющие доступы и возможность испортить независимые копии нужно разделять.
Рабочий процесс важнее красивой панели песочницы
Исследование начинается с регистрации материала: источник, разрешение на работу, контрольная сумма, ответственный специалист, цель. Сначала рассматривают методы, которые не требуют запуска подозрительного кода: изучение свойств файла, метаданных и уже имеющихся следов инцидента. Активное исследование выполняют только тогда, когда оно оправдано задачей и подготовлена подходящая среда.
Базовые образы и инструменты готовят отдельно от активных экспериментов. Обновление среды планируют как отдельную операцию; временный интернет-доступ не должен появляться у гостя с образцом «на минуту, чтобы скачать библиотеку». Для чистой подготовки и исследования нужны разные состояния и явно проверяемый переход между ними.
Во время работы фиксируют не только результаты, но и состояние изоляции. Ограничивают длительность эксперимента, объём записей и ресурсы гостя, чтобы один запуск не вытеснил наблюдение или управление. После завершения материалы сохраняют в предусмотренное место, гостевую среду возвращают к проверенному исходному состоянию, а временные права отзывают.
Отдельный сценарий нужен на случай отклонений: появился неожиданный внешний маршрут, возникла связь с управляющим сегментом, обнаружены признаки изменения хоста. В этом случае приоритет — прекращение опасных связей и сохранение необходимых свидетельств по внутреннему регламенту. Продолжать эксперимент ради красивого отчёта не следует.
Установка средств анализа — только одна строка в этом процессе. FLARE-VM, собственный набор инструментов или коммерческая платформа помогают специалисту, но не назначают владельца риска, не согласуют условия аренды и не проверяют сеть вместо администратора.
Когда выделенный сервер для песочницы имеет смысл
Отдельная физическая машина оправдана, если организации нужна воспроизводимая среда, несколько гостевых ОС, контролируемая параллельная работа и независимость от производственных хостов. Её выбирают после определения разрешённого сценария, бюджета ресурсов и модели изоляции. Для редкого учебного упражнения с безопасными материалами постоянно арендованная большая машина может оказаться лишней.
Первый успешный результат здесь выглядит скромно: чистая тестовая VM не видит внешнюю сеть и управление, возврат к исходному образу работает, результат можно безопасно извлечь, ответственный знает, как остановить стенд. Только затем проверяют, сколько рабочих сред выдерживает конкретный тариф и удобна ли аналитикам его скорость.
Такой порядок не уменьшает ценность мощного сервера. Он помогает использовать мощность по назначению. В защитной лаборатории лучшая незапланированная активность — та, которая вовремя осталась внутри согласованных границ и не стала новым инцидентом для всего офиса.
Подберите конфигурацию для своего проекта
Характеристики, стоимость и условия подготовки выделенных серверов MAATRIX в России и США.
Выбрать выделенный серверВыделенный сервер для разработки и тестирования: staging-ферма для нескольких командСледующая статья →
SCARAB или ANKH: стоит ли доплачивать за Ryzen 7600X и 64 ГБ памяти
Все материалы о выделенных серверах
Обсудить статью, задать вопрос или начать новую тему
Есть вопрос по этой статье, идея для обсуждения или просто хотите поделиться опытом? Сообщество MAATRIX ждёт. Для общения, пожалуйста, зарегистрируйтесь в нашем личном кабинете.
Перейти в сообщество →