На проверке Виртуальный патчинг уязвимостей: compensating controls когда патч не готов

[Сергей Попов]

По данным Mandiant, среднее время от раскрытия уязвимости до первой эксплуатации сократилось до дней, а иногда эксплуатация фиксируется ещё до публикации патча. При этом среднее время установки обновления на критическую CVE в enterprise-инфраструктуре превышает 100 дней. Сто. Дней. Последние три года я настраивал виртуальные патчи на Snort, Suricata и Trend Micro Deep Security в ситуациях, когда вендорский апдейт тестировался в стейджинге неделями, а Nessus уже фиксировал активные попытки эксплуатации на периметре. Это практический разбор того, как виртуальный патчинг уязвимостей и compensating controls закрывают окно экспозиции, когда классический цикл патч-менеджмента объективно не успевает.

Почему цикл патч-менеджмента проигрывает атакующим​

Проблема не в незнании уязвимостей. Проблема в процессе: регрессионное тестирование, окно изменений, цепочка утверждений, план отката, риск простоя сервиса. По данным AppSec Stats Flash, среднее время устранения высокосерьёзных уязвимостей в приложениях растёт и может превышать 200 дней.

С точки зрения MITRE ATT&CK, атакующие целенаправленно используют этот разрыв. Exploit Public-Facing Application (T1190, Initial Access) - стандартная точка входа через публичные сервисы с известными CVE. Exploitation of Remote Services (T1210, Lateral Movement) - горизонтальное перемещение через внутренние сервисы, где патчи ставят ещё медленнее, чем на периметре. Exploitation for Privilege Escalation (T1068) - повышение привилегий через уязвимости ядра или системных сервисов, которые месяцами ждут обновления.

Бизнес-логика атаки проста: Vulnerability Scanning (T1595.002, Reconnaissance) позволяет массово сканировать диапазоны IP на непатченные сервисы, а Vulnerabilities (T1588.006, Resource Development) - заранее приобретать или разрабатывать эксплоиты под конкретные CVE. Финансовый импакт - от шифровальщика до кражи данных клиентов. OWASP подтверждает масштаб: A06:2021 (Vulnerable and Outdated Components) сидит в топ-10 рисков веб-приложений не первый год.

Виртуальный патчинг и compensating controls не заменяют установку обновлений. Но они сокращают окно экспозиции с месяцев до часов - и это разница между инцидентом и предотвращённой атакой.

Виртуальный патч WAF IPS: три уровня реализации​

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

IPS-сигнатуры для виртуального патчинга: Snort и Suricata​

Работает если: IPS стоит в inline-режиме на пути трафика к уязвимому сервису; трафик не зашифрован или проходит через TLS-инспекцию; сигнатура покрывает конкретный паттерн эксплуатации.

Не работает если: атакующий использует нестандартную обфускацию, которая не покрыта PCRE; трафик идёт по зашифрованному каналу без терминации; уязвимость эксплуатируется через локальный доступ, а не через сеть.

Сетевой IPS - первый эшелон защиты от уязвимостей без патча. Snort и Suricata позволяют написать кастомную сигнатуру под конкретный CVE за минуты. При массовой эксплуатации Log4Shell мне удавалось закрыть вектор атаки кастомными IPS-правилами в течение часа после публикации PoC, пока реальный патч библиотеки Log4j тестировался неделями.

Пример правила Suricata для детектирования JNDI-инъекции в HTTP-заголовках (для полного покрытия Log4Shell аналогичные правила нужны также для http.uri;, http.request_body; и других точек инъекции):

alert http any any -> $HOME_NET any ( \
  msg:"VP Log4Shell JNDI in HTTP Header"; \
  flow:to_server,established; \
  http.header; content:"${jndi:"; nocase; fast_pattern; \
  pcre:"/\$\{(j|J)\s*\{?\s*(n|N)\s*\{?\s*(d|D)\s*\{?\s*(i|I)\s*:/"; \
  classtype:attempted-admin; sid:2100001; rev:3;)

PCRE-часть покрывает попытки разбить строку jndi: пробелами и одиночными фигурными скобками. Без PCRE правило ловит только прямое вхождение. Но эта регулярка не покрывает вложенные lookup-конструкции вида ${j${::-n}di:}, Unicode-escape (\u0024\u007bjndi:), а также табуляцию и переносы строки внутри ключевого слова - для их детектирования нужна нормализация на уровне препроцессора или дополнительные правила с более сложными PCRE.

Ограничение: сетевой IPS слеп к трафику внутри TLS без терминации. Если приложение доступно только по HTTPS и TLS терминируется на самом сервере - IPS-правило бесполезно. Ставьте правило после TLS-offload, на балансировщике или reverse proxy. Ещё нюанс - производительность: сложная PCRE на высоконагруженном IPS может добавить 2-5 мс latency на каждый пакет, что для real-time систем уже больно.

WAF-правила: ModSecurity и коммерческие решения​

Работает если: WAF стоит перед уязвимым веб-приложением; уязвимость эксплуатируется через HTTP/HTTPS; правило написано для конкретного параметра, а не для «всего трафика».

Не работает если: уязвимость не в веб-приложении (RDP, SMB, SSH); WAF не видит тело запроса (binary uploads, WebSocket); атака использует легитимные значения параметров (business logic flaws).

WAF работает на уровне приложения и понимает HTTP-семантику: URI, параметры, заголовки, тело запроса. Это делает его точнее сетевого IPS для веб-уязвимостей, но ограничивает область применения HTTP/HTTPS протоколом.

Два подхода к созданию виртуального патча WAF:

Позитивная модель (whitelist) - определяет допустимый формат входных данных и блокирует всё остальное. Этот подход эффективнее для снижения риска: он защищает от неизвестных вариантов обфускации, а не только от конкретного PoC.

Пример для ModSecurity - валидация параметра id, который должен содержать только числа:

SecRule ARGS:id "!^[0-9]+$" \
  "id:100001,phase:2,deny,status:403, \
  msg:'VP: non-numeric id parameter', \
  severity:CRITICAL,tag:'virtual-patch/sqli'"

Негативная модель (blacklist) - блокирует известные паттерны атаки. Быстрее в создании, но хрупче: каждый новый вариант обфускации требует обновления правила.

И вот тут главная ошибка, которую я вижу регулярно: не пишите виртуальный патч под конкретный эксплоит. Если пентест нашёл SQL-инъекцию через ' OR 1=1--, создавать правило, блокирующее именно эту строку - путь в никуда. Завтра атакующий использует Unicode-кодирование, и патч мёртв. Виртуальный патч закрывает класс уязвимости (A03:2021 - Injection по OWASP), а не единичный exploit.

Ограничение: WAF-правила хрупки при изменении параметров приложения. Если уязвимый URL или имя параметра меняется при обновлении - виртуальный патч нуждается в перенастройке. Привязывайте правило к конкретному location/URI и документируйте связь правила с CVE-ID.

RASP: виртуальный патч внутри приложения​

Работает если: приложение на JVM или CLR; RASP-агент совместим с версией рантайма; допустимы 5-15% overhead на latency запросов.

Не работает если: приложение - бинарный C/C++ без managed runtime; legacy-система на устаревшей Java (ниже 8); требования к latency критичны (high-frequency trading, real-time processing в OT).

RASP (Runtime Application Self-Protection) работает внутри процесса приложения. Сидя в рантайме, он контролирует каждую инструкцию до её выполнения и может заблокировать эксплуатацию на уровне вызова функции, а не сетевого пакета. Это ближе всего к «настоящему» патчу без изменения исходного кода - по сути, третий тип виртуального патчинга, ставший возможным благодаря bytecode instrumentation API в JVM и CLR (Java Instrumentation API, .NET Profiling API).

Но RASP - не серебряная пуля. Overhead реален, и для высоконагруженных систем он может быть неприемлем. Плюс RASP-агент покрывает только то приложение, в которое встроен, - не инфраструктуру вокруг.

Compensating controls информационная безопасность: за пределами WAF и IPS​

Виртуальный патч на WAF или IPS - самый обсуждаемый compensating control, но далеко не единственный. Когда уязвимость эксплуатируется не через сеть, или когда IPS/WAF невозможно поставить перед уязвимой системой - нужны другие временные меры защиты.

Сетевая сегментация как временная мера​

Если патч недоступен, а виртуальный патч на IPS не покрывает вектор - изолируйте уязвимую систему. Firewall-правила и ACL на маршрутизаторах ограничивают доступность уязвимого сервиса до минимально необходимого набора источников, радикально снижая поверхность атаки.

Типичный сценарий: внутренний сервер с критической уязвимостью в RDP без доступного патча. Действия:

1. Ограничить доступ к порту 3389 только с jump-host'ов администраторов через ACL на ближайшем L3-коммутаторе или firewall-правило.
2. Включить аудит подключений к этому порту в SIEM.
3. Запретить исходящие соединения с уязвимого сервера на внешние IP - это блокирует reverse shell.

Уязвимость на месте, но теперь атакующему нужно сначала скомпрометировать jump-host - а это дополнительное действие, которое даёт время на детектирование.

Ограничение: сегментация не защищает от атакующего, который уже внутри разрешённого сегмента. Если скомпрометирован jump-host - уязвимая система снова доступна. Сегментация снижает вероятность, но не гарантирует защиту.

Ужесточение доступа и отключение функциональности​

Иногда самый эффективный compensating control - просто выключить уязвимый компонент:

• Log4Shell: параметр log4j2.formatMsgNoLookups=true полностью устранял вектор атаки без обновления библиотеки. Одна строка в конфиге.
• Уязвимые REST-эндпоинты: если endpoint не используется в production - отключите его через конфигурацию приложения или reverse proxy. Зачем держать открытой дверь, в которую никто из своих не ходит?
• Уязвимости в аутентификации: временное ужесточение MFA-требований или ограничение методов аутентификации.

NIST CSF 2.0 в субкатегории PR.AA-01 прямо указывает на управление учётными данными и контролем доступа как базовый защитный контроль. Ужесточение доступа к уязвимой системе - прямое применение этого принципа.

Усиленный мониторинг как компенсирующий контроль​

Мониторинг не блокирует эксплуатацию, но сокращает время обнаружения (MTTD) с дней до минут. В контексте PCI DSS compensating controls усиленный мониторинг - допустимая мера, если вы можете документально подтвердить, что она обеспечивает эквивалентный уровень защиты.

Что включить:

• Правила SIEM/IDS на паттерны эксплуатации конкретной CVE (аналогично IPS-сигнатурам, но в режиме alert).
• Мониторинг аномалий в поведении уязвимой системы: нетипичные исходящие соединения, создание новых процессов, изменение файлов конфигурации.
• Алерты на сканирование. Vulnerability Scanning (T1595.002) означает, что атакующие сканируют перед атакой. Детектирование сканов даёт фору.

NIST CSF 2.0 DE.AE-01 (Adverse Event Analysis) требует baseline сетевых операций и ожидаемых потоков данных. Без baseline нет контекста для детектирования аномалий - мониторинг как compensating control не работает. Соответствие A09:2021 (Security Logging and Monitoring Failures) по OWASP: если логирование не настроено, все остальные меры слепы.

RBVM и управление уязвимостями: жизненный цикл виртуального патча​

Виртуальный патчинг уязвимостей - не изолированное действие, а этап в risk-based vulnerability management. Если виртуальный патч поставлен, но не привязан к жизненному циклу уязвимости в RBVM-системе - он гарантированно останется навечно. Я это видел неоднократно: правило, написанное «на неделю», живёт два года.

Жизненный цикл виртуального патча:

1. Обнаружение. Nessus, Qualys, MaxPatrol или аналогичный сканер находит CVE на активе. Сканер даёт CVSS-скор и контекст: доступность из сети, наличие эксплоита, affected versions.
2. Приоритизация. RBVM-платформа обогащает данные: реальная доступность из интернета, наличие weaponized exploit, критичность актива для бизнеса. Не каждая Critical-CVE требует экстренного виртуального патча - только те, где совпадают exploit availability, network reachability и asset criticality. Далеко не каждая уязвимость с формально критическим CVSS-скором - реальная угроза в вашем конкретном окружении.
3. Митигация. Выбирается тип compensating control: IPS-правило, WAF-правило, сегментация, ограничение доступа. Решение фиксируется в тикет-системе с привязкой к CVE-ID.
4. Валидация. После развёртывания - повторное сканирование или ручная попытка эксплуатации. Без этого шага вы не знаете, работает ли compensating control. Проверяйте. Всегда.
5. Мониторинг. Виртуальный патч в production: отслеживание ложных срабатываний, логирование заблокированных запросов, оценка влияния на легитимный трафик.
6. Вывод. После установки постоянного патча виртуальный патч деактивируется. Правило удаляется или переводится в monitor-only. Дата фиксируется.

Метрика, которую стоит внедрить - Mean Time to Mitigate (MTTM): время от обнаружения уязвимости до развёртывания compensating control. MTTM дополняет классический Mean Time to Patch и показывает реальную скорость реакции команды. Если ваш MTTM для критических CVE больше 4 часов - процесс нуждается в оптимизации.

Защита legacy систем без обновлений​

Отдельная категория - системы, для которых патча не будет никогда: вендор прекратил поддержку, версия снята с maintenance, или система настолько кастомизирована, что обновление означает полную переделку. В OT/ICS-средах это рутина: SCADA-системы, контроллеры (PLC), HMI-панели работают на устаревших ОС и протоколах.

Для legacy виртуальный патч становится не временной мерой, а постоянным уровнем защиты:

• IPS-сигнатуры на специализированном OT-шлюзе фильтруют трафик до legacy-устройства.
• Сегментация отделяет legacy-сегмент с минимальными ACL на входе.
• Мониторинг аномалий на уровне сетевого трафика - единственный способ детектирования без агентов на самом устройстве.

Ограничение: для legacy-систем с проприетарными протоколами (Modbus TCP function codes 1-6/15-16 для чтения/записи регистров, DNP3 в OT-средах) стандартные IPS/WAF не имеют релевантных сигнатур. Нужны специализированные решения с пониманием промышленных протоколов и их function codes - Snort из коробки тут не поможет. Это отдельная дисциплина, и если у вас в сети ходит Modbus без какого-либо контроля - у вас проблема посерьёзнее отсутствия патчей.

Когда виртуальный патчинг создаёт ложное чувство безопасности​

Виртуальный патч опасен именно тогда, когда создаёт иллюзию защищённости:

Ситуация	Почему виртуальный патч недостаточен
Уязвимость локальной эскалации привилегий (T1068)	Сетевой IPS/WAF не видит локальные вызовы. Нужно обновление ядра.
Множественные точки входа к одному компоненту	Виртуальный патч на одном пути не защищает остальные.
Business logic flaw	Эксплуатация через легитимные значения параметров - сигнатура не поможет.
Уязвимость в криптографии	Слабый алгоритм или ключ не компенсируется фильтрацией трафика.
Патч доступен и тестирование завершено	Откладывание реального патча в пользу виртуального - необоснованный риск.

Главное правило: виртуальный патч - это таймер, а не решение. Каждый compensating control должен иметь дату истечения и ответственного за установку постоянного исправления. Если через 90 дней правило всё ещё на месте, а реальный патч не установлен - это проблема процесса, а не технологии.

Чек-лист: от обнаружения CVE до виртуального патча​

Требования к окружению: доступ к IPS/WAF в inline-режиме (Snort/Suricata 6+ или ModSecurity 2.9+/3.x), SIEM для логирования (ELK, Splunk, KUMA, MaxPatrol SIEM), сканер уязвимостей для валидации, тестовая среда для проверки правил перед production.

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

На практике для типовой веб-уязвимости с известным вектором чисто техническая часть укладывается в 30–60 минут - без учёта corporate change management, который даже для emergency change может добавить часы или дни. Для сложных случаев - zero-day без PoC, множественные точки входа - закладывайте 2-4 часа, включая согласование с владельцами сервисов.

Со временем compensating controls начинают восприниматься как полноценная замена патчу. Это самая опасная точка в зрелости процесса. Виртуальный патч, который пережил три цикла обновлений и два аудита - уже не временная мера защиты, а архитектурный костыль. PCI DSS требует документирования compensating controls с обоснованием, почему стандартный контроль неприменим. На практике документ пишется один раз, а compensating control живёт годами без пересмотра.

Вопрос не в том, умеете ли вы ставить виртуальные патчи. Вопрос - умеете ли вы их снимать. Процесс вывода compensating control после установки постоянного патча должен быть таким же формализованным: тикет, верификация патча, деактивация правила, повторный скан, закрытие. Без этого замкнутого цикла управление уязвимостями превращается в бесконечное накопление workaround'ов, каждый из которых - точка отказа и источник ложных срабатываний. Если интересно, как другие команды выстраивают lifecycle виртуальных патчей и какие грабли собирают - обсуждение в тематическом треде на форуме codeby.net.