Типовые инциденты ИБ и реагирование

В данном разделе описаны типовые инциденты информационной безопасности, характерные для платформы НТБот, и классические процедуры реагирования на них.

Процедуры реагирования разделены на четыре этапа:

Блокирование (Containment) — ограничение распространения угрозы
Уничтожение угрозы (Eradication) — устранение причины инцидента
Восстановление (Recovery) — возврат к штатной работе
Анализ (Post-Incident) — разбор произошедшего и улучшение защиты

1. Компрометация учётной записи

Признаки: массовые ошибки авторизации (LOGIN_ERROR) в журнале событий Keycloak, сменяющиеся успешным входом с нетипичного IP-адреса, или фиксация события USER_DISABLED_BY_TEMPORARY_LOCKOUT.

Блокирование:

Принудительное завершение всех активных сессий пользователя: Keycloak Admin Console → Users → выбрать пользователя → Sessions → Logout all sessions.
Временная блокировка учётной записи в корпоративном каталоге (AD/LDAP).

Уничтожение угрозы:

Сброс пароля с требованием установить новый при следующем входе (Users → Credentials → Reset password).
Проверка и перевыпуск факторов MFA (если злоумышленник успел привязать свой OTP-токен): Users → Credentials → удалить существующие OTP-устройства.

Восстановление:

Разблокировка учётной записи после подтверждения личности сотрудника по альтернативным каналам связи.

Анализ:

Проверка журнала Keycloak (Realm Settings → Events → Event Log): какие действия совершил аккаунт за время компрометации.
Проверка журнала launcher-service: какие тесты были запущены под скомпрометированной учётной записью и не использовалась ли платформа для атаки на тестируемые системы.

2. Загрузка вредоносного тестового сценария

Признаки: нетипичные целевые хосты в конфигурации сценария (адреса за пределами разрешённого периметра тестирования), аномальные запросы к внутренней инфраструктуре в логах generator-service, жалобы со стороны владельцев систем на неожиданную нагрузку.

Блокирование:

Немедленная остановка запущенного теста через интерфейс Диспетчера или напрямую через API launcher-service.
Блокировка учётной записи, загрузившей сценарий, в Keycloak Admin Console (Users → Enabled → выключить).

Уничтожение угрозы:

Удаление вредоносного сценария из файлового хранилища платформы (/opt/ntbot) и из базы данных scenario-service.
Проверка остальных сценариев, загруженных той же учётной записью.

Восстановление:

Проверка состояния целевых систем, которые подверглись нагрузке от вредоносного скрипта.
Уведомление владельцев затронутых систем.

Анализ:

Ревью политики прав доступа: кто имеет право загружать и запускать сценарии (роли в Keycloak).
Введение обязательного согласования при указании целевых хостов за пределами штатного стенда нагрузочного тестирования.

3. Несанкционированное изменение конфигурации

Признаки: внезапное появление новых администраторов в Keycloak, изменение списка разрешённых адресов перенаправления (Valid Redirect URIs), отключение подсистемы журналирования событий ИБ — всё это фиксируется в разделе Keycloak Admin Console Realm Settings → Events → Admin Events.

Блокирование:

Отзыв прав у учётной записи, совершившей несанкционированное изменение.
Ограничение доступа к консолям управления (Keycloak Admin Console, config-service) только с доверенных IP-адресов или через VPN.

Уничтожение угрозы:

Откат конфигурации Keycloak через экспорт/импорт realm из резервной копии (см. раздел Резервное копирование).
Откат конфигурации сервисов через git в репозитории config-service:
```
git -C <путь-к-config-service> revert <commit-hash>
```

Восстановление:

Проверка работоспособности всех сервисов после отката (sudo docker ps -a — все контейнеры должны быть в статусе healthy).

Анализ:

Установление причины: злой умысел (инсайдер), ошибка администратора или компрометация административного токена.
Проверка, все ли изменения за период инцидента зафиксированы в Admin Events.

4. DDoS-атака / Отказ в обслуживании

Признаки: лавинообразный рост сетевого трафика, недоступность внешних точек входа платформы (порты 4433, 3001), критическая нагрузка на серверы.

Важно: платформа НТБот является инструментом генерации нагрузки. При фиксации DDoS-инцидента необходимо в первую очередь проверить, не запущены ли активные тесты на продуктивную среду по ошибке — это можно сделать через раздел Тесты → Активные запуски в интерфейсе Диспетчера или через API launcher-service.

Блокирование:

Включение правил Rate Limiting в конфигурации nginx для ограничения числа запросов с одного IP-адреса.
Перенаправление трафика через специализированные сервисы защиты от DDoS (Anti-DDoS провайдеры).

Уничтожение угрозы:

Блокировка атакующих подсетей на уровне межсетевого экрана (если атака не носит глобальный распределённый характер).

Восстановление:

Поэтапный запуск и проверка доступности компонентов: БД → Бэкенд-сервисы → nginx → Фронтенд.
Проверка статуса контейнеров: sudo docker ps -a.

Анализ:

Сбор телеметрии атаки (тип DDoS: на уровне канала — UDP-flood, или на уровне приложений — HTTP-flood) для точечной настройки защиты.
Оценка необходимости внедрения WAF (Web Application Firewall) перед nginx.