Средняя
В сентябре 2025 года злоумышленники использовали уязвимости CVE-2025–20333 и CVE-2025–20362 в Cisco ASA и Cisco FTD. Позднее CISA сообщила о компрометации Cisco Firepower-устройства в федеральном гражданском ведомстве США. По данным агентства, атака, вероятно, была связана с одной или обеими уязвимостями. Отдельное внимание привлекла вредоносная программа FIRESTARTER, которая позволяла сохранять скрытый доступ к устройству даже после стандартных действий по обновлению.
Этот случай хорошо показывает важную проблему: устранение уязвимости на сетевом оборудовании не заканчивается установкой патча. Нужно понимать, какие устройства затронуты, где они находятся в сети, какие сервисы на них доступны, какие правила открывают к ним путь и не осталось ли признаков компрометации после обновления.
Содержание
Почему межсетевые экраны стали привлекательной целью?
Межсетевой экран обычно воспринимается как средство защиты. Но для атакующего это ещё и очень ценный узел инфраструктуры.
В случае FIRESTARTER речь идёт не просто об эксплуатации уязвимости. Вредоносная программа была рассчитана на сохранение доступа к устройству. Поэтому такой инцидент нельзя рассматривать как обычную задачу обновления: после установки исправлений нужно дополнительно проверять состояние устройства и признаки компрометации.
В чём сложность устранения таких уязвимостей?
На практике обновление сетевого оборудования редко бывает простой операцией.
Во‑первых, нужно быстро понять, какие устройства затронуты. В крупной инфраструктуре могут быть десятки или сотни МЭ, виртуальные контексты, резервные площадки, старые версии ПО, филиалы и тестовые сегменты.
Во‑вторых, нужно оценить сетевую экспозицию. Уязвимое устройство, опубликованное в интернет, и уязвимое устройство, доступное только из административного сегмента, — это разные уровни риска.
В‑третьих, нельзя просто выключить периметровый МЭ «на всякий случай». Через него могут проходить VPN сотрудников, доступы к внешним сервисам, межсегментное взаимодействие и каналы с партнёрами.
И наконец, нужно понять, не был ли МЭ уже скомпрометирован. В случае FIRESTARTER патч закрывает уязвимость, но не обязательно устраняет последствия уже произошедшей атаки.
Где здесь помогает NSPM?
NSPM не заменяет патч-менеджмент, сканер уязвимостей, SIEM или расследование инцидента. Его роль прикладная: собрать сетевой контекст и помочь понять, где риск действительно критичен.
- какие устройства работают на уязвимых версиях;
- какие из них доступны из недоверенных зон;
- какие сервисы опубликованы наружу, например VPN или WebVPN;
- через какие правила и маршруты к ним можно обратиться;
- какие бизнес-сервисы завязаны на эти устройства;
- что изменилось в конфигурациях до и после устранения;
- не было ли изменений вне штатного процесса.
NSPM помогает связать конфигурации, топологию, политики доступа, NAT, маршруты, зоны безопасности, историю изменений и результаты сканирования. В итоге команда работает не с абстрактным списком уязвимостей, а с конкретным перечнем устройств, доступов и действий.
Практический сценарий: устранение CVE-2025-20333 и CVE-2025-20362
Разберём, как может выглядеть процесс реагирования на эти уязвимости в Cisco ASA/FTD.
1. Найти затронутые устройства
Сначала команда формирует список потенциально уязвимых устройств: Cisco ASA, Cisco Secure Firewall, Firepower и FTD.
По каждому устройству важно собрать:
- модель и версию ПО;
- площадку и роль в сети;
- наличие VPN/WebVPN;
- внешние и внутренние интерфейсы;
- принадлежность к кластеру или HA-паре;
- виртуальные контексты;
- дату последнего обновления;
- актуальность резервной копии конфигурации.
Главный риск на этом этапе — не найти все устройства, которые нужно проверить. В реальной инфраструктуре Cisco ASA может быть на периметре, в ЦОДе, в филиале, в резервной площадке или в старом технологическом сегменте.
2. Расставить приоритеты
Дальше устройства нужно разделить по уровню риска. В первую очередь обрабатываются те, у которых:
- VPN/WebVPN доступен из интернета;
- management-интерфейсы доступны из широких или недоверенных сегментов;
- устройство стоит на периметре;
- через него проходят доступы к критичным системам;
- есть широкие правила доступа;
- недавно были изменения в конфигурации;
- нет актуальной резервной копии.
Устройства без прямой внешней экспозиции тоже нужно обновлять, но их срочность может быть ниже.
3. Проверить достижимость уязвимых сервисов
Следующий шаг — понять, откуда доступны потенциально уязвимые интерфейсы.
Проверяются:
- доступность VPN/WebVPN снаружи;
- доступность management-интерфейсов;
- правила ACL;
- правила NAT;
- маршруты;
- доступы из пользовательских, серверных и административных сегментов.
Например, два устройства могут иметь одну и ту же уязвимую версию. Но первое публикует VPN в интернет, а второе доступно только из выделенного административного сегмента. Формально CVE одна, но порядок действий должен быть разным.
Результатом может быть таблица для реагирования:
| Устройство | Экспозиция | Критичность | Действие |
|---|---|---|---|
| ASA-EDGE-01 | WebVPN доступен из Internet | Критично | Срочное обновление, проверка IOC, подготовка reimage |
| ASA-DC-02 | Доступ только из admin-сегмента | Высокая | Обновление в ближайшее окно, проверка логов |
| FTD-BRANCH-04 | Внешней экспозиции нет | Средняя | Плановое обновление, контроль конфигурации |
4. Временно снизить риск до обновления
Не всегда можно немедленно обновить периметровый МЭ. Иногда нужно согласовать окно, проверить совместимость, подготовить резервирование и предупредить владельцев сервисов.
До установки исправлений можно:
- ограничить доступ к WebVPN или management-интерфейсам;
- закрыть доступ с недоверенных направлений;
- сузить source-сети для администрирования;
- отключить неиспользуемые сервисы;
- включить дополнительный мониторинг;
- проверить наличие логирования;
- усилить контроль изменений.
Но такие действия нужно делать аккуратно. Перед изменением правил важно проверить, какие пользователи и сервисы могут быть затронуты. После изменения — убедиться, что критичные доступы продолжают работать.
5. Обновить ПО и проверить компрометацию
Для CVE-2025–20333 и CVE-2025–20362 недостаточно просто поставить обновление и закрыть задачу. Процесс должен включать два трека.
Первый трек — устранение уязвимости:
- определить исправленную версию;
- сделать резервную копию конфигурации;
- согласовать окно;
- обновить устройство;
- проверить HA/кластер;
- проверить доступность критичных сервисов.
Второй трек — устранение уязвимости:
- проверить индикаторы компрометации;
- проанализировать подозрительные процессы и артефакты;
- сопоставить события с SIEM;
- проверить историю изменений;
- при подозрении на FIRESTARTER выполнить reimage по процедуре производителя;
- восстановить конфигурацию из доверенного источника;
- повторно проверить сетевые доступы.
Ключевая мысль простая: патч закрывает уязвимость, но не всегда удаляет последствия уже произошедшей атаки.
6. Проверить состояние после восстановления
После обновления или reimage нужно убедиться, что устройство вернулось в контролируемое состояние.
Проверяются:
- версия ПО;
- соответствие конфигурации последней доверенной версии;
- локальные пользователи;
- настройки AAA;
- удалённый доступ;
- ACL и NAT;
- маршруты;
- логирование;
- отправка событий в SIEM.
Особенно важно сравнивать устройство не только с состоянием «до обновления», но и с последней доверенной конфигурацией. Если устройство было скомпрометировано, последняя текущая версия могла уже содержать нежелательные изменения.
7. Проверить бизнес-доступы и зафиксировать результат
После изменений на периметре нужно убедиться, что рабочие процессы не сломались. Проверяются VPN, опубликованные сервисы, межсегментные доступы, маршруты к критичным системам, NAT и прохождение обратного трафика.
Финальный результат лучше оформить в отчёт:
- какие устройства были затронуты;
- какие версии ПО были до и после;
- какая была сетевая экспозиция;
- какие временные меры применялись;
- где выполнялся reimage;
- какие изменения внесены в правила;
- какие проверки выполнены;
- какие остаточные риски остались;
- кто отвечал за работы и по каким заявкам.
Такой отчёт нужен не только ИБ. Он полезен эксплуатации, владельцам сервисов, внутреннему аудиту и руководителям.
Вывод
История с CVE-2025–20333, CVE-2025–20362 и FIRESTARTER показывает: современные атаки на сетевое оборудование бьют не только по уязвимому ПО, но и по слабым местам операционного процесса.
Патч нужен. Но одного патча мало.
Нужно знать, где находятся уязвимые устройства, какие сервисы на них доступны, какие правила открывают к ним путь, как менялась конфигурация и были ли признаки компрометации.
Именно здесь управление сетевыми политиками становится частью практического реагирования на уязвимости. Чем быстрее команда связывает CVE с реальной топологией, доступами и изменениями, тем быстрее она может не просто «закрыть задачу», а действительно снизить риск для инфраструктуры
Адрес:
121205, г. Москва, муниципальный округ Можайский, территория инновационного центра «Сколково», б-р Большой, д. 42, стр. 1, этаж 2, помещение № 162/№ 4
Телефон:
+7 (495) 255-35-82
Почта:
info@netopia.pro
Деятельность осуществляется компанией ООО «Нетопия» при грантовой поддержке Фонда «Сколково»
© Netopia.pro
