SecureExec
ГлавнаяО насБлогЦены
ВойтиРегистрация
← Назад к блогу

Сетевая изоляция хоста — остановить атаку за секунды

15 марта 2026 г.

Когда злоумышленник закрепляется на Linux-сервере, он немедленно начинает горизонтальное перемещение, пытается выгрузить данные или установить persistence. Каждая минута, пока он остаётся подключён к сети — это минута ущерба. Стандартный IR-плейбук говорит: изолируй хост. Реальность такова, что для этого обычно нужен SSH-доступ, изменение правил файрвола или обращение в консоль облачного провайдера — всё это требует времени и несёт риски.

SecureExec теперь позволяет изолировать скомпрометированный хост одним кликом.

Что делает сетевая изоляция хоста

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

Всё остальное блокируется: исходящие C2-соединения, попытки горизонтального перемещения, эксфильтрация данных, входящие callback-соединения атакующего — всё обрывается мгновенно.

Как это работает под капотом

Изоляция реализована в виде модуля ядра Linux (secureexec_kmod), который регистрирует Netfilter-хуки с наивысшим приоритетом (NF_IP_PRI_FIRST) для трафика LOCAL_IN и LOCAL_OUT. Когда режим файрвола переключается в ISOLATED, модуль применяет whitelist: пропускаются только пакеты, соответствующие настроенным правилам; всё остальное дропается на уровне ядра — до того, как любой процесс в userspace увидит трафик.

Модуль ядра использует RCU (Read-Copy-Update) для горячего пути фильтрации пакетов — проверка каждого пакета выполняется без блокировок, добавляя пренебрежимо малую задержку в обычной работе. Изменения правил от агента применяются по схеме clone-and-swap: работающий хук всегда видит консистентный набор правил.

Взаимодействие между агентом SecureExec и модулем ядра происходит через символьное устройство (/dev/secureexec_kmod). Ядро гарантирует, что открыть устройство может только агентный бинарь по настроенному пути — даже root-процессы не смогут манипулировать правилами файрвола в обход этой проверки.

Сам агент получает команду изоляции или снятия изоляции от сервера SecureExec через лёгкий polling-канал, применяет её к модулю ядра и сообщает текущий статус изоляции в каждом heartbeat. Если хост по какой-то причине выходит из синхронизации, сервер обнаруживает это и автоматически повторяет команду.

Когда использовать

Из алерта. Когда срабатывает детект — reverse shell, инъекция кода, дамп учётных данных — вы увидите кнопку «Изолировать хост» прямо на странице алерта. Одно нажатие с подтверждением, и хост изолирован прежде, чем атакующий успеет отреагировать.

Со страницы устройств. Страница Endpoints отображает все зарегистрированные хосты с текущим статусом изоляции. Любой хост можно изолировать или снять изоляцию в любой момент — статус отображается специальным бейджем «Isolated». Это удобно для плановых окон обслуживания или когда вы хотите проактивно изолировать хост в ходе масштабного инцидента.

Автоматизированный ответ. Поскольку изоляция управляется через командный API, её можно запускать из вашей SOAR-платформы или тикет-системы через REST API SecureExec — UI не нужен.

Настройка правил изоляции

Каждая инфраструктура уникальна. Во время расследования часто необходимо, чтобы определённые сервисы на изолированном хосте оставались доступными: команда должна войти по SSH для сбора forensic-данных, система управления конфигурацией — применить патч, SIEM-коллектор — продолжить забирать логи. Полное отключение всего этого создаёт операционные трудности, которые замедляют реагирование.

SecureExec решает это с помощью глобальных правил изоляции — постоянного whitelist-а, который вы настраиваете один раз и который автоматически применяется к каждому endpoint в момент перехода в режим изоляции.

Правила управляются на странице Правила изоляции в боковой панели (требует разрешения agents:manage). Каждое правило задаёт:

  • IP-адрес — конкретный IPv4-адрес источника или назначения, либо пустое значение для совпадения с любым IP.
  • Порт — конкретный номер порта, либо пустое значение для любого порта.
  • Направление — Входящий, Исходящий или Любое.

Примеры типичных правил:

ПравилоIPПортНаправлениеСценарий
Разрешить SSH(любой)22ВходящийКоманда может войти по SSH для расследования и сбора артефактов
Разрешить Salt master10.0.1.54505–4506ИсходящийSaltStack или Ansible продолжает управлять хостом; можно применить патч прямо во время инцидента
Разрешить SIEM10.0.2.20514ИсходящийSyslog или Beats продолжает отправлять логи в SIEM — вы не теряете видимость
Разрешить jump box10.0.0.10(любой)ВходящийТолько ваш jump box может достучаться до хоста, не весь периметр
Разрешить мониторинг10.0.3.19100ВходящийPrometheus или Zabbix-агент продолжает отдавать метрики — можно наблюдать за поведением хоста

Правила глобальные: они одинаково применяются ко всем endpoints организации, которые входят в режим изоляции. Соединение агента с сервером всегда сохраняется вне зависимости от списка правил — агент не может случайно оказаться заблокированным.

Обновление правил в реальном времени

Если вы изменили правила изоляции, пока агент уже находится в изоляции, обновление доходит до него автоматически. Агент периодически опрашивает сервер на предмет актуального набора правил и перепрограммирует модуль ядра на лету — повторная изоляция не нужна, ручного вмешательства не требуется. Хост остаётся изолированным, а новые правила вступают в силу в течение нескольких секунд.

Снятие изоляции

После завершения расследования и устранения угрозы снять изоляцию так же просто: нажмите «Release» на странице устройств или выдайте команду release через API. Модуль ядра немедленно возвращается в нормальный режим, трафик восстанавливается, бейдж «Isolated» исчезает.

Почему важна именно kernel-level изоляция

Правила файрвола, установленные через iptables или nftables из userspace, может перезаписать любой процесс с достаточными привилегиями — включая самого атакующего, если он получил root. Модуль ядра, применяющий изоляцию на уровне NF_IP_PRI_FIRST, работает до любой userspace-обработки пакетов и до любого userspace-управляемого файрвола. Даже root-процесс не может его обойти без выгрузки модуля, а модуль защищает собственный канал управления, проверяя путь к исполняемому файлу открывающего процесса.

Это не мягкий контроль. Это жёсткая сетевая граница, принудительно установленная ядром.

Что сохраняется во время изоляции

ТрафикСтатус в изоляции
Агент → бэкенд SecureExecРазрешён всегда
Loopback (127.0.0.0/8)Разрешён всегда
Правила из страницы «Правила изоляции»Разрешён
Весь остальной входящий трафикЗаблокирован
Весь остальной исходящий трафикЗаблокирован

Попробуйте сейчас

Сетевая изоляция хоста включена во все тарифные планы SecureExec. Установите агент на ваши Linux-серверы, один раз настройте правила изоляции — и получите мгновенную изоляцию при следующем срабатывании детекта, не теряя доступа к инструментам, необходимым для расследования.

Начать работу с SecureExec

SecureExec

Лёгкая платформа безопасности конечных точек. Мониторинг процессов, файлов и сетевой активности в режиме реального времени по всему вашему парку устройств.

Продукт
  • Цены
Компания
  • О нас
  • Блог
  • Связаться с отделом продаж
  • Поддержка
Аккаунт
  • Войти
  • Регистрация
Правовая информация
  • Политика конфиденциальности
  • Условия использования

© 2026 SecureExec. Все права защищены.

Built with Rust & Next.js