Сканирование уязвимостей: почему инструмент защиты ломает продуктив и как выстроить процесс который работает
Сканер уязвимостей не знает, что он на вашей стороне. Его трафик неотличим от действий атакующего на стадии разведки. Именно поэтому всё, что связано со сканированием (расписание, профили, интеграция, приоритизация) должно строиться вокруг этого простого факта, а не вокруг инструкции к конкретному продукту. https://seberd.ru/2187
Почему сканер ведёт себя как нарушитель
Сканер уязвимостей работает через активное зондирование. Он последовательно обращается к каждому порту, читает баннеры служб, отправляет пробные запросы к веб-интерфейсам, пробует аутентификацию к известным сервисам по стандартным спискам. Всё это ровно та же цепочка действий, которую выполняет пентестер или атакующий при первичном осмотре сети.
Часть зондов специально нестандартна. OpenVAS/GVM, как и коммерческий Nessus, использует TCP-пакеты с нетипичными комбинациями флагов для проверки конкретных уязвимостей. Так называемые Xmas-пакеты содержат одновременно установленные флаги FIN, URG и PSH. Такая комбинация в нормальном трафике не встречается никогда. По RFC 793, реакция корректно реализованного стека на такой пакет предсказуема. Но у систем с устаревшими реализациями TCP конкретная комбинация флагов вызывает панику ядра, перезагрузку сервиса или полное зависание.
Система обнаружения вторжений блокирует сканер, принимая его за агрессивный хост. Поведение сканера распознаётся как агрессивное по тем же причинам, по которым будет заблокирован настоящий нарушитель: инструменты идентичны.
Из этого вытекает практическое следствие, которое часто игнорируют. Добавление IP-адреса сканера в белые списки WAF и IPS не решает проблему, а скрывает её. Если задача сканирования в том числе в том, чтобы проверить, насколько WAF защищает приложение, сканирование в обход WAF отвечает только на половину вопроса. Правильная архитектура предполагает два режима: сканирование снаружи периметра через все защитные слои и сканирование изнутри с прямым доступом к хостам. Первое проверяет покрытие защиты, второе ищет уязвимости самого хоста независимо от периметра. Большинство организаций делают только одно из двух.
Что убивает легаси-серверы
Объяснение «сканер перегрузил сеть» технически верно лишь отчасти. Реальная причина инцидентов на старых серверах состоит не в высоком трафике, а в конкретных зондах, попадающих в уязвимые места сетевого стека.
Windows Server 2003 имеет задокументированные баги в обработке TCP-сегментов с определёнными нестандартными флагами. Промышленное оборудование с SCADA-интерфейсами перестаёт отвечать уже при нескольких SYN-пакетах подряд на порты, которые физически открыты, но не обрабатываются операционной системой нормально. Старые коммутаторы и маршрутизаторы могут исчерпать таблицу ARP или состояние stateful firewall при одновременном сканировании нескольких сотен портов, хотя при обычной работе трафик через них в десятки раз выше.
Ответ состоит не в том, чтобы запускать сканирование реже или позже, а в правильных профилях и в изоляции чувствительных сегментов.
Современные сканеры поддерживают безопасный профиль (safe checks), который исключает деструктивные зонды и ограничивает использование нестандартных пакетов. В OpenVAS разница между режимами «Full and Fast» и «Full and Deep» именно в этом: деструктивные NVT-плагины в безопасном режиме не запускаются. Для продуктивных серверов это разумный компромисс: покрытие чуть ниже, риск аварии сведён к минимуму.
Критичные системы, которые нельзя трогать агрессивными зондами, выносят в отдельную группу с явным ограничением параллелизма. Пять одновременных подключений к одному хосту вместо дефолтных двадцати не перестраховка, а понимание ограничений конкретного оборудования. Стандартные настройки большинства сканеров рассчитаны на корпоративную сеть с новым оборудованием. В смешанной инфраструктуре, где рядом живут виртуальные машины текущего года и физические серверы десятилетней давности, дефолтные значения гарантированно создадут проблемы на легаси-узлах.
Перед первым запуском на любом сегменте имеет смысл провести тестирование на изолированном стенде с репликой нескольких целевых систем. Несколько часов на подготовку дают ответ на вопрос, какие профили безопасны для конкретного окружения, и исключают сюрпризы при запуске на продуктиве.
Аутентифицированное сканирование и привилегированный аккаунт
Неаутентифицированный скан показывает то, что видит внешний наблюдатель: открытые порты, версии служб по баннерам, доступные веб-интерфейсы. Для проверки периметра этого достаточно. Для внутренней инфраструктуры нет.
Аутентифицированный скан читает содержимое системы изнутри: версии установленных пакетов, содержимое реестра, параметры конфигурационных файлов, права на директории, настройки служб. Только через аутентифицированный доступ сканер находит библиотеку с известной уязвимостью, которая не видна ни на каком порту снаружи. Разница в качестве отчётов принципиальная. Без аутентифицированного сканирования вы знаете, как выглядит инфраструктура снаружи, и почти ничего не знаете о том, что происходит внутри.
Проблема в уровне прав. Не гостевой аккаунт, а права локального администратора на Windows-хостах и суперпользователя или sudoer с широкими полномочиями на Linux. Служебный аккаунт сканера с такими правами в масштабах сети становится одним из наиболее привлекательных объектов для атакующего. Скомпрометировать этот аккаунт означает получить административный доступ ко всем хостам, которые сканер когда-либо проверял.
Промышленная практика решает эту коллизию через несколько механизмов одновременно.
Временные токены: аккаунт активен только в период сканирования, создаётся за несколько минут до запуска и удаляется или блокируется сразу после завершения. Реализация через PowerShell-скрипты или Ansible-плейбуки, интегрированные в планировщик платформы.
Сетевая изоляция: отдельный VLAN для трафика сканирования с правилами межсетевого экрана, разрешающими подключения только от конкретного IP сканирующего хоста к конкретным портам управления. Случайное подключение к скан-аккаунту из произвольного узла сети становится технически невозможным.
На Windows-окружениях использование WinRM вместо SMB для кредентиального доступа упрощает контроль: WinRM легче ограничить групповыми политиками и детально логировать в журналах событий.
Организации, которые отказываются от аутентифицированного сканирования из соображений безопасности, получают отчёт с половиной картины. Принятое решение в таком случае представляет собой осознанный компромисс, а не более безопасную альтернативу.
Расписание, которое не создаёт инцидентов
Запуск через внешний cron работает для простых скриптов. Для полноценных платформ сканирования внешний планировщик создаёт конфликты: cron запускает задачу, не зная о текущей нагрузке на базу данных сканера, о задаче в очереди, о процессе синхронизации базы сигнатур.
OpenVAS/GVM использует внутренний планировщик gvmd, который учитывает состояние всех активных задач и нагрузку на PostgreSQL. Nessus и Qualys имеют собственные менеджеры расписаний с аналогичной логикой. Настройка запуска через внутренний планировщик платформы предпочтительнее внешнего cron: причина не в удобстве интерфейса, а в том, что встроенный планировщик управляет конкурентным доступом к ресурсам и не запустит новую задачу поверх незавершённой предыдущей.
Второй принцип: дифференциация по критичности актива. DMZ-серверы и публично доступные приложения проверяются еженедельно или чаще. Внутренняя инфраструктура общего назначения обходится ежемесячно, если нет изменений в составе. После деплоя новой версии приложения или изменения конфигурации имеет смысл запускать внеплановое целевое сканирование автоматически через вебхук из CI/CD-системы.
Привязка всех задач к одному времени суток создаёт очередь. Запуск всего в полночь первого числа месяца конкурирует с резервным копированием, антивирусными обновлениями и плановой сборкой мусора баз данных. Распределение задач на интервал в три-четыре часа с учётом часовых поясов для географически распределённой инфраструктуры снижает пиковую нагрузку без потери охвата.
Отдельный момент касается окон обслуживания. Если у сервера зарегистрировано плановое техническое обслуживание, сканирование в этот период даёт артефакты: часть служб выключена, часть конфигурации временно изменена, статус системы не соответствует рабочему состоянию. Синхронизация расписания с CMDB или ITSM-системой позволяет автоматически переносить задачи при зарегистрированных окнах и исключает мусор из отчётов.
Почему CVSS-оценки обманывают тех, кто на них полагается
CVSS (Common Vulnerability Scoring System) представляет собой шкалу для описания характеристик уязвимости в вакууме: насколько легко её эксплуатировать технически, какой потенциальный ущерб она может нанести, требует ли она привилегий или взаимодействия со стороны пользователя. Шкала создавалась не для ответа на вопрос, будет ли конкретная уязвимость атакована в конкретной инфраструктуре. Об этом прямо написано в документации FIRST.
Исследования по эффективности приоритизации показали следующее: если ориентироваться на принцип «закрывать всё с CVSS 7.0 и выше», реально эксплуатируемые уязвимости составят около двух-трёх процентов от получившегося списка. Остальные задачи не приносят результата с точки зрения снижения реальных рисков. При этом уязвимость с CVSS 6.1, активно используемая в атаках прямо сейчас, в приоритетный список не попадёт.
Вторая проблема CVSS заключается во временной слепоте. Оценка присваивается при публикации CVE и редко обновляется. Атакующие создают инструменты автоматической эксплуатации, публикуют proof-of-concept в открытом доступе, продают эксплойты на специализированных площадках. Уязвимость с умеренным базовым баллом может за неделю стать одной из наиболее активно эксплуатируемых в интернете, при этом оценка остаётся прежней.
EPSS, KEV и как правильно ставить приоритеты
EPSS (Exploit Prediction Scoring System) обновляет оценку вероятности эксплуатации каждой CVE в реальных атаках ежедневно. Модель машинного обучения анализирует несколько классов сигналов: публикации proof-of-concept, активность на хакерских форумах, изменения в базах данных эксплойтов, трафик honeypot-сетей. Ежедневное обновление принципиально отличает EPSS от статичного CVSS.
CVE-2024-4577, критическая уязвимость в PHP, наглядно показывает разницу: EPSS-оценка для неё поднялась до высоких значений за несколько дней до того, как NVD опубликовал полный анализ с CVSS-баллом. Команды, ориентировавшиеся исключительно на CVSS-фиды, оставались в слепой зоне, пока уязвимость уже активно эксплуатировалась в реальных атаках.
CISA KEV (Known Exploited Vulnerabilities catalog) ведёт публичный список, в который американское агентство по кибербезопасности вносит уязвимости с задокументированными фактами эксплуатации. Попадание CVE в KEV означает не «теоретически опасно», а «атакующие используют это прямо сейчас». Для приоритизации этот сигнал наиболее прямой из всех доступных.
В 2025 году NIST ввёл LEV (Likely Exploited Vulnerabilities) как ретроспективную метрику, оценивающую вероятность того, что уязвимость уже эксплуатировалась, на основе накопленных исторических EPSS-данных. LEV закрывает слепое пятно: CVE, которые прошли незамеченными в ежедневном потоке обновлений, но по ретроспективной картине с высокой вероятностью уже использовались в атаках.
Рабочая схема приоритизации объединяет все три источника:
[√] Есть в CISA KEV → немедленное устранение вне очереди и вне спринта
[√] EPSS выше 10% → высокий приоритет в текущем цикле работ
[ ] Высокий CVSS, но EPSS ниже 1% и нет в KEV → плановое устранение
[x] Информационные находки без CVE → регистрация, пересмотр при изменении контекста
EPSS обновляется ежедневно, поэтому оценка, которая была низкой вчера, может стать высокой завтра. Проверка актуальных значений раз в неделю, а не только при выходе нового отчёта сканера, соответствует этой динамике. Автоматический мониторинг изменений через API FIRST делает процесс непрерывным.
800 строк в отчёте и что с ними делать
Сырой экспорт из любого сканера выглядит как инвентарь катастрофы: тысячи строк, критические находки перемешаны с информационными уведомлениями о заголовках HTTP, дубли с нескольких сетевых интерфейсов одного сервера, баннеры служб, которые не обновлялись с прошлого квартала.
Первый шаг состоит в нормализации с учётом контекста актива. CVSS-значение имеет смысл только в связке с тем, что представляет собой конкретная система. Одна и та же уязвимость в публично доступном веб-приложении и в изолированной тестовой среде без сетевого доступа требует принципиально разного ответа. Без атрибуции находок к бизнес-контексту отчёт остаётся списком технических фактов.
Формула взвешенного приоритета приводит разнородные переменные к единой шкале. Каждый параметр нормализован до диапазона от 0 до 1:
Приоритет = (CVSS ÷ 10) × 0,35 + КритичностьАктива × 0,30 + EPSSScore × 0,25 + БизнесВоздействие × 0,10
Критичность актива берётся из реестра CMDB или заполняется вручную при инвентаризации. Бизнес-воздействие субъективно, но обязательно. База данных с данными клиентов и тестовый стенд с идентичной уязвимостью требуют разных сроков реакции, а формула без этого параметра не разграничит их.
Откуда берутся ложные срабатывания
Несколько типовых источников.
Кэшированные страницы. Сканер видит устаревшую версию приложения, которая уже обновлена, но не сброшена в кэше. В отчёт попадает CVE, которой фактически нет.
Виртуальные хосты. Несколько сайтов отвечают с одного IP, сканер получает смешанные результаты и неверно атрибутирует находки.
Намеренно устаревшие баннеры. Часть организаций оставляет ложную версию службы как приманку для атакующих. Сканер честно фиксирует «устаревшее ПО» и добавляет соответствующие CVE.
Для каждого типа правила подавления настраиваются отдельно и версионируются вместе с конфигурацией платформы. Без версионирования через несколько месяцев накапливается хаос из взаимоисключающих фильтров, которые никто не помнит зачем создавал.
Верификация критических находок в изолированном контуре нужна до того, как выставлять тикет команде разработки. Отдел безопасности, несущий разработчикам необработанный вывод сканера, быстро теряет доверие. Слишком много ложных тревог приводит к тому, что команда начинает игнорировать уведомления.
Что происходит между отчётом и закрытым тикетом
Здесь живёт главная проблема большинства программ управления уязвимостями. Не в настройке сканера. Не в расписании.
Сканер нашёл уязвимость. Она попала в отчёт. Отчёт попал в тикет. Тикет создан и назначен команде. Дальше всё идёт не по учебнику.
Команда разработки видит тикет как конкурента задачам из спринта. Сроки устранения, установленные командой ИБ, не согласованы с циклом разработки. Разработчик открывает CVE, видит описание на английском про библиотеку, которую он не трогал и не знает, и закрывает тикет как «не воспроизводится». Тикет зависает на месяцы. Сканер на следующей неделе находит то же самое.
Эффективный процесс строится на нескольких принципах.
Первый: владелец уязвимости не команда ИБ, а владелец актива. Команда ИБ находит и приоритизирует, команда-владелец системы принимает решение о способе устранения и несёт ответственность за соблюдение SLA. Без этого разделения ответственность размыта настолько, что тикет не закроет никто.
Второй: митигация допустима как временная мера с явным сроком пересмотра. Если обновление ломает совместимость или невозможно по договору с вендором, ограничение сетевого доступа к уязвимому компоненту или дополнительный слой контроля доступа остаётся приемлемым ответом. Каждое исключение регистрируется с датой создания, ответственным лицом и датой обязательного пересмотра. Реестр исключений без аудита через полгода превращается в список хронических проблем, которые никто не трогает, потому что никто не помнит, почему они там оказались.
Третий: повторное сканирование после применения патча не опциональное. Патч применяется не к тому серверу, применяется к не той ветке, закрывается один вектор, но не замечается второй. Автоматический целевой скан после закрытия тикета и сверка результата замыкают контур. Без него «закрытая» уязвимость может оставаться открытой ещё несколько месяцев.
Типичные сроки устранения, на которые ориентируется большинство зрелых программ:
| Уровень риска | Диапазон CVSS | Срок |
|---|---|---|
| Критический + есть в KEV | 9.0–10.0 | 24–72 часа |
| Высокий | 7.0–8.9 | 14 дней |
| Средний | 4.0–6.9 | 30 дней |
| Низкий | 0.1–3.9 | 90 дней или следующий плановый цикл |
Для объектов КИИ (критической информационной инфраструктуры) сроки жёстче. Соответствующие требования зафиксированы в приказах ФСТЭК России.
Интеграция с SIEM и тикет-системами
Передача данных через файлы на диске по расписанию работает ровно до первого сбоя: файл не появился, директория не смонтирована, парсер не распознал формат обновлённой версии экспорта. Следующий отчёт придёт через неделю, и никто не заметит пробела.
Прямой путь к коллектору событий пролегает через API сканера или экспорт через вебхук в формате JSON. Logstash и Fluentd принимают такой поток и трансформируют его в структурированные события для SIEM. Базовая конфигурация Logstash для разбора событий OpenVAS:
filter {
json {
source => "message"
}
mutate {
add_field => {
"vuln_severity" => "%{[result][severity]}"
"host_ip" => "%{[result][host]}"
"cvss_score" => "%{[result][cvss][base_score]}"
"plugin_name" => "%{[result][nvt][name]}"
}
}
if [vuln_severity] in ["High", "Critical"] {
mutate { add_tag => ["urgent_remediation"] }
}
}
Параметр sincedb_path в конфигурации file input указывает на файл хранения смещения. Без него после перезапуска Logstash начнёт повторно обрабатывать все старые события: тикет-система получит дубли, аналитики потратят время на разбор уже закрытых находок.
Тикеты автоматически создаются только для находок выше заданного порога. Ниже порога накопление идёт в SIEM для трендового анализа без создания задач. Переполнение тикет-системы низкоприоритетными находками убивает дисциплину быстрее, чем любой другой фактор. Когда каждый день приходит тридцать новых задач с пометкой «low», люди перестают открывать уведомления. Не из лени, а как реакция на бесполезный шум.
Маршрутизация тикетов к конкретной команде работает только при наличии актуального реестра активов с ответственными группами. Сотрудники уходят, команды переформировываются, системы меняют владельца. Тикет, назначенный на уволившегося человека, зависнет до следующего ручного аудита.
Механизм эскалации при нарушении SLA настраивается через таймеры в тикетной системе. Если тикет не закрыт в установленный срок, автоматически создаётся уведомление руководителю подразделения. Механизм переносит ответственность за просроченные уязвимости на управленческий уровень и снимает с команды ИБ роль единственного напоминателя.
Отчётность для регулятора
В России регуляторная рамка для сканирования уязвимостей строится вокруг приказов ФСТЭК: № 17 (государственные информационные системы) и № 239 (объекты КИИ). Для организаций, обрабатывающих персональные данные, актуальны требования 152-ФЗ в части технических мер защиты.
При проверках регуляторы смотрят не на абсолютную цифру найденных уязвимостей, а на динамику и на процесс. Организация с тысячей открытых уязвимостей, у которой есть задокументированный процесс устранения, реестр исключений с обоснованиями и снижение среднего времени устранения за последний квартал, выглядит значительно лучше организации с сотней уязвимостей, но без следов организованной работы с ними. Проверяющий задаёт один и тот же вопрос: «Что вы сделали с находками?», а не «Сколько их было?»
Структура отчёта включает несколько обязательных блоков: охват инфраструктуры (количество проверенных хостов как процент от общего реестра активов), распределение по уровням риска на дату последнего сканирования, динамика за квартал и реестр исключений с обоснованием по каждому случаю.
Юридическое оформление сканирования начинается до первого запуска. Письменное согласование с владельцами систем в области проверки защищает от обвинений в несанкционированном доступе. В больших организациях, где ИБ-служба и подразделение являются отдельными юридическими лицами или структурами с разными руководителями, этот документ становится обязательным.
Хранение результатов сканирования подпадает под требования к защите информации: отчёты содержат детали об уязвимостях системы, которые сами по себе чувствительны. Персональные данные, которые могут оказаться в логах (имена пользователей из реестра, данные из LDAP-запросов при аутентифицированном сканировании), маскируются до формирования итоговых документов.
Признаки того, что процесс работает
Нулевых находок не бывает в живой инфраструктуре. Нулевые находки в отчёте означают либо слишком узкую область сканирования, либо неправильно настроенный сканер, либо оба варианта.
Признаки работающего процесса выглядят иначе. Среднее время устранения критических находок снижается от квартала к кварталу. Процент повторно открытых уязвимостей (re-opened) невысокий: это значит, что патчинг делается правильно с первого раза. Соотношение новых находок к закрытым остаётся стабильным или смещается в сторону закрытых.
Метрика, которую стоит отслеживать отдельно — coverage, процент инфраструктуры, реально охваченный регулярным сканированием. Не «мы сканируем», а «мы сканируем X% от всех зарегистрированных активов с частотой не реже Y». Всё за пределами этого охвата по определению является слепой зоной, независимо от качества всего остального процесса. Именно там атакующий будет чувствовать себя комфортно дольше всего.
Проверочный список для оценки зрелости:
[√] Сканирование охватывает более 80% зарегистрированных активов
[√] Критические и высокие находки получают тикеты в течение 24 часов
[√] SLA устранения согласованы с командами-владельцами активов
[√] Реестр исключений ведётся и проходит плановый пересмотр
[√] Повторное сканирование после патчинга выполняется автоматически
[ ] EPSS-оценки проверяются как минимум еженедельно, а не только при новых сканах
[ ] Аутентифицированное сканирование настроено хотя бы для критичных систем
[x] Все задачи запускаются через cron без учёта состояния платформы
[x] Единственная метрика приоритизации — CVSS-балл
Автоматизация через сканер снижает объём ручной работы, но не заменяет инженерного суждения. Сканер покажет, что порт открыт и версия сервиса содержит известную CVE. Он не скажет, что порт открыт намеренно по требованию интеграции с партнёром, что CVE не применима к конкретной сборке пакета, что владелец системы уже согласовал временное исключение. Контекст остаётся за людьми. Инструмент работает только в связке с тем, кто понимает, что именно ищет.