Кратко и по делу — план действий разделён на: анализ инцидента, срочные меры (containment & remediation), исправление уязвимости в коде и долгосрочные архитектурные изменения для предотвращения повторения.
1) Анализ инцидента (forensics)
- Сохранить и зафиксировать состояние (preserve): логи приложений, прокси/балансировщика, веб‑серверов, NAT/файрволов, DNS, облачные логи (CloudTrail/Audit), дампы памяти и диск‑снапшоты для скомпрометированных инстансов.
- Собрать входящие HTTP‑запросы, заголовки, полезную нагрузку и параметры, которые приводили к внешним запросам; найти точную реквест‑строку и реферер.
- Определить вектор SSRF: какие URL/хосты запрашивались, целевые внутренние API, IP‑диапазоны. Идентифицировать обращения к внутренним адресам, например: $\mathrm{127.0.0.1}$, $\mathrm{169.254.169.254}$, приватные сети $10.0.0.0/8$, $172.16.0.0/12$, $192.168.0.0/16$.
- Оценить последствия: какие данные были прочитаны/переданы (логины, токены, конфиги), были ли извлечены учётные данные или получен доступ к службе метаданных облака.
- Проследить ошибочные или повторяющиеся попытки (pivoting) — какие внутренние API использовались для продвижения атаки.
- Определить постфактум индикаторы компрометации (IoC): IP злоумышленника, user‑agent, специфические URL/параметры, таймстемпы.
2) Срочное устранение (containment)
- Отключить/ограничить пострадавшую функциональность (фичу, endpoint) до исправления.
- Перекрыть сетевой доступ: временно запретить исходящие HTTP(S) запросы от сервисов, которые делают SSRF‑запросы (блокировка на уровне VPC/NAT/Proxy).
- Заблокировать доступ к метаданных облака (или включить протекции) — например, включить IMDSv2 в AWS и ограничить доступ: адрес $\mathrm{169.254.169.254}$ недоступен для приложений.
- Поменять/отозвать скомпрометированные секреты: API‑ключи, токены, учётные данные, сертификаты. Сделать ротацию всех ключей, которые могли стать доступны.
- Если есть подозрение на глубже компрометацию инстанса — изолировать/пересоздать (rebuild) машину из доверенного образа.
3) Устранение уязвимости в коде (fixes)
- Валидация входа: применять allow‑list конечных хостов или доменов, а не deny‑list. Если нужно загружать внешние URL — проверять домен против белого списка.
- Резолв и проверка IP: перед выполнением запроса резолвить DNS и проверять итоговый IP против приватных/локальных диапазонов; отвергать запросы, если IP в $10.0.0.0/8$, $172.16.0.0/12$, $192.168.0.0/16$, $127.0.0.0/8$, или равен $\mathrm{169.254.169.254}$.
- Запрет схем/протоколов: не позволять `file://`, `gopher://`, `ftp://`, `dict://` и т.п.; ограничить только `http(s)`.
- Не следовать редиректам автоматически; если следовать, повторять проверки для каждого Location (проверять окончательный IP/domain).
- Таймауты и лимиты: установить таймаут подключения/чтения (например, $5$–$10$ секунд), лимит на размер ответа и ограничения по количеству параллельных запросов.
- Использовать безопасный HTTP‑клиент/браузер, который можно сконфигурировать для запрещения локальных адресов и схем.
- Логирование и трассировка: логировать исходящие запросы (URL, resolved IP, caller) и связывать с исходным входящим запросом для последующего анализа.
4) Архитектурные изменения и защитные механизмы
- Egress фильтрация: разрешать исходящие HTTP(S) запросы только через центральный прокси/туннель (forward proxy) с строгой политикой и аудитом. Все сервисы должны иметь фронт‑прокси, через который контролируются домены/адреса.
- Сеть: сегментация сервисов, минимальные ACL/sg (security groups) — запрет доступа сервисов фронта напрямую к закрытым внутренним API. Внутренние API доступны только из доверенных подсетей или через сервис‑мэш.
- Service‑to‑service authentication: требовать взаимную аутентификацию (mTLS) или жесткие токены/обмен короткоживущими доверительными данными для внутренних API. Даже при SSRF без корректных сертификатов/токенов доступ запрещён.
- Превенция метаданных утечки: использовать IMDSv2 (AWS) или прокси для метаданных; ограничить доступ к metadata endpoint на сетевом уровне.
- Прокси/верификатор запросов: централизовать все исходящие запросы через шлюз, который делает allow‑list и проверки заголовков/редиректов и умеет блокировать локальные IP.
- WAF и runtime‑защита: добавить правила WAF для обнаружения аномальных URL и паттернов SSRF; включить RASP/agents для обнаружения небезопасных вызовов на рантайме.
- Политики least privilege: внутренние API должны выдавать минимально нужные права и иметь аудит доступа, короткие TTL для токенов, минимальные роли.
5) Мониторинг, обнаружение и тестирование
- Настроить алертинг на: исходящие запросы к внутренним/metadata IP, необычные паттерны окружения, частые DNS‑запросы на разные домены из одного клиента.
- Регулярные pentest/SSRF фазы, fuzzing для входных параметров, CI‑checks статического анализа, unit+integration тесты, которые эмулируют локальные адреса и проверяют защиту.
- Bug bounty и код‑ревью процессов для критичных мест, где приложение выполняет запросы по URL от пользователей.
6) Процедуры после инцидента (lessons, отчет)
- Документировать ход атаки, root cause, какие данные утекли и какие меры приняты.
- Провести ретроспективу и внести задачи в roadmap: egress proxy, сетевые ACL, смена секретов, тесты.
- Обучить разработчиков: безопасное обращение с внешними URL, SSRF‑паттерны и анти‑паттерны.
Короткие практические проверки/правила (чтобы быстро внедрить)
- Блокировать доступ к $\mathrm{169.254.169.254}$ на уровне хоста/iptables или security group.
- Везде, где принимается URL от пользователя — применять allow‑list доменов; если allow‑list невозможен — запрещать запросы к приватным IP после DNS‑резолва.
- Не хранить долгоживущие облачные ключи в конфигурации; использовать short‑lived credentials.
Если нужно — могу привести пример проверки разрешённого IP после DNS‑резолва или шаблон правила для прокси/iptables.