Привет, Хабр! Меня зовут Андрей Бирюков. Я независимый эксперт в области ИТ и ИБ, преподаю в учебных центрах и пишу книги.
Системы обнаружения/предотвращения вторжений (IDS/IPS) наряду с межсетевыми экранами являются наиболее распространенными средствами защиты, используемыми в большинстве организаций. В большинстве компаний, где мне приходилось внедрять системы ИБ, IDS либо уже использовался, либо мы его внедряли. Сейчас многие решения по обнаружению атак встроены в аппаратные межсетевые экраны и не требуют отдельного устройства.
Но, несмотря на большую распространенность этих решений, во многих организациях их используют совершенно неправильно.
Представьте, что вы купили новую охранную сигнализацию, подключили её к сети датчиков движения и включили в боевой режим. Через час она орёт от каждого сквозняка, шороха собственной кошки и вибрации от проезжающей снегоуборочной машины. Соседи пишут заявления, вы отключаете датчики один за другим, а через неделю выбрасываете систему на помойку.
С сетевыми IPS/IDS происходит ровно та же история, только вместо кошки — легитимные бэкапы, а вместо снегоуборочной машины — массовые обновления Windows по WSUS и аналогичные сетевые активности.
В этой статье мы будем говорить преимущественно об ошибках при использовании IPS, то есть систем, которые блокируют трафик, но и к системам IDS, создающим только уведомления без блокировок, тема статьи тоже имеет непосредственное отношение, так как большое количество уведомлений, вызванных ложными срабатываниями, также является ошибкой настройки IDS.
Основная ошибка при внедрении IPS носит имя «отсутствие baseline», то есть эталонного профиля нормального трафика. Как у нас обычно бывает с внедрением ИТ и ИБ систем.
Руководитель требует быстрого результата, аудитор давит, что «система обнаружения вторжений должна быть внедрена до конца квартала», и команда ИБ сразу включает фильтрацию в режиме inline — блокировать. И мы тут же получаем шквал ложных срабатываний. При этом самые опасные ложные срабатывания — не те, что просто пишут алерт в лог, а те, которые рвут бизнес‑критические сессии.
К примеру, IPS, увидев необычно длинную строку в URL (а для бэкенда это обычный Base64-кодированный параметр поиска), решает, что идёт попытка SQL‑инъекции, и отправляет RST‑пакет. Сервер приложений падает в ошибку, клиент видит «502 Bad Gateway», менеджер бежит к вам с вопросом, почему сломалась выгрузка отчётности. Вы отключаете эту сигнатуру — и тут же понимаете, что настоящую атаку вы тоже пропустите. В результате, доверие к системе падает мгновенно.
Для лучшего понимания данной проблемы рассмотрим пару примеров из жизни.
Один инфраструктурный администратор в производственной компании рассказывал, как после установки нового IPS упал весь цеховой документооборот. Здесь сразу стоит сделать поправку: через данный IPS не шел трафик от промышленных SCADA‑систем. Однако, сигнатура, предназначенная для обнаружения EternalBlue (знаменитой уязвимости SMBv1), сработала на легитимные SMB‑запросы от сканера штрих‑кодов. Старый сканер использовал нестандартный диалект SMB, который IPS принял за попытку эксплойта.
В итоге блокировались не атаки, а работа склада готовой продукции. Команда ИБ потратила двое суток, чтобы выяснить, что дело не в вирусе, а в «слепой» встроенной сигнатуре. Производственный отдел после этого случая полгода голосовал против любых новых средств защиты.
Другой случай произошёл в крупном банке. Система IPS была включена в боевом режиме сразу после установки, без предварительного анализа. В первый же рабочий день сотрудники отдела автоматизации не смогли запустить ни один легитимный PowerShell‑скрипт для обновления отчётности. IPS блокировал каждый вызов Invoke‑Expression, потому что в правилах по умолчанию этот паттерн был жёстко привязан к поведению вредоносного кода.
В банке остановилась подготовка обязательной отчётности для ЦБ. Заместитель председателя правления вызвал начальника ИБ на ковёр, а команде пришлось в экстренном порядке выгружать IPS из ядра сети, возвращаясь к обычной маршрутизации. Сигнатуру починили, но осадок остался — руководство до сих пор считает, что IPS «ломает всё подряд».
В чём же корень зла?
Суть ошибки заключается в том, что среднестатистическая корпоративная сеть — это хаос. У неё нет «нормального» поведения в классическом смысле. Есть часовые всплески активности: репликация баз данных в 2 часа ночи, потоковые RDP‑сессии бухгалтеров утром, SSH‑скрипты администрирования с нестандартными флагами и другие «подозрительные» активности.
Атакующие эту нормальную аномалию прекрасно знают — они сами будут подражать вашим же бэкап‑агентам, когда будут исследовать вашу сеть после проникновения. Но если baseline не выстроен, вы не отличите маскировку реального злоумышленника от собственной кривой настройки.
Правильный путь выглядит иначе. До включения блокировок система должна минимум две, а лучше четыре недели работать в режиме мониторинга — только предупреждения, без разрыва сессий. При этом лучше сразу не включать все правила даже в режим мониторинга, так как уведомлений может быть слишком много. Включайте правила постепенно, блоками по несколько штук, и затем разбирайтесь с полученными предупреждениями.
За это время вы собираете метрики по каждому правилу: частоту срабатываний, распределение по источникам, привязку к временным окнам и бизнес‑приложениям. Затем вы смотрите на правила, которые срабатывают чаще всего, — и по очереди решаете, что с ними делать. Возможно, нужно поднять порог чувствительности для конкретного сервера.
Возможно, стоит исключить подсеть CI/CD из проверки на Command Injection, потому что там по долгу службы передают заведомо опасные строки. А возможно, отдельное правило просто сломано — и его лучше переписать с использованием новых контекстных ключей, например, внимания к HTTP‑методу или MIME‑типу.
Только после этой дополнительной настройки вы включаете IPS в режим блокировки. И то — сначала на не самых критичных сегментах сети, например, в DMZ или на тестовых контурах. Каждое срабатывание вы продолжаете анализировать ещё как минимум неделю, чтобы случайно не задушить очередной «кошачий сквозняк».
Делаем правильные выводы
В этой статье мы рассмотрели те ошибки, которые очень часто допускают администраторы при внедрении систем IPS. Самый дорогой урок, который можно вынести из этой темы: IDS/IPS — это не пожарная сигнализация из коробки.
Это музыкальный инструмент, который надо настраивать под звучание вашей конкретной сети. И главная ошибка внедрения — верить, что установка и включение — это уже защита. Из‑за большого количества ложных срабатываний ваша IDS‑система превратится в помойку с кучей бесполезных уведомлений, а IPS просто будет блокировать легитимный трафик.
Важно помнить, что без baseline ваш IPS будет не щитом, а генератором случайных помех. И первое, что он заблокирует по‑настоящему, — это терпение службы эксплуатации.
Если после внедрения IPS не хочется разбираться с ложными срабатываниями уже на горящем проде, лучше заранее понять, как такие системы устроены и где они должны стоять в инфраструктуре.
На курсе «IDS/IPS. Инфраструктурные компоненты защиты» разбирают современные системы обнаружения и предотвращения атак: как они анализируют трафик, чем отличаются IDS и IPS, как работать с сигнатурами, как выстраивать эшелонированную защиту и почему «включить всё по умолчанию» — плохая стратегия.
Присмотритесь к открытым урокам. Они бесплатные, проходят в рамках курса и помогают заранее познакомиться с форматом обучения и преподавателем‑практиком. На вебинарах можно будет задать вопросы и обсудить реальные сценарии применения IDS/IPS в инфраструктуре:
3 июня в 20:00. «IDS/IPS: как работают современные системы обнаружения и предотвращения атак».
На уроке покажем, почему IDS/IPS — это не «чёрный ящик», который автоматически делает сеть безопасной, и как такие системы реально помогают защищать инфраструктуру.16 июня в 20:00. «IDS/IPS как часть эшелонированной защиты инфраструктуры».
Поговорим о месте IDS/IPS в многоуровневой защите: рядом с NGFW, EDR и SIEM, без иллюзии, что один инструмент закроет все риски.
А ещё подписывайтесь на канал OTUS в Max — там публикуем анонсы открытых уроков, полезные материалы по IT и разборы для тех, кто хочет развиваться в профессии без лишнего шума.