IPS в NGFW: как не дать себя обмануть красивыми циферками

Алексей Егоров, главный архитектор стратегических проектов по информационной безопасности, Positive Technologies

Включили IPS на файрволе, а производительность просела на 60%? Добро пожаловать в клуб! История про то, как маркетинговые 99% детекта превращаются в реальные головные боли, знакома каждому сетевому инженеру. Сегодня разберём, что творится внутри системы предотвращения вторжений, почему она так безжалостно пожирает ресурсы и главное — как сделать так, чтобы IPS работала на вас, а не против.

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

Принцип работы: никакой магии, только логика

NGFW пропускает трафик по своим политикам, а IPS параллельно сверяет содержимое с сигнатурами и выполняет указанное в них действие. Звучит просто, но дьявол кроется в деталях. IPS обрабатывает поток пошагово: видит протокол и направление, восстанавливает контекст сессии и сверяет полезную нагрузку с предикатами сигнатуры. При совпадении — действует ровно так, как сказано в правиле.

Сигнатура — это точное описание признаков нежелательной активности, которое даёт системе формальный критерий: «это похоже на атаку, пора реагировать». Думайте о ней как о рецепте: чёткие ингредиенты, пропорции и последовательность действий. Только вместо борща получаем детект угрозы.

Почему все говорят на языке Snort и Suricata

Открытые движки Snort и Suricata задали синтаксис де-факто. Даже когда вендор пишет собственный IPS, ему удобнее поддерживать «snort/suricata-язык», чтобы аналитики могли быстро формировать качественные правила. От качества формулировок зависит не только охват техник, но и производительность — чем умнее условие, тем меньше ложных совпадений в продакшене.

В реальных продуктах часто используют собственный движок, но синтаксис оставляют совместимым — это снижает порог входа для экспертов, которые пишут и сопровождают правила. Как говорится, зачем изобретать велосипед, когда можно просто сделать его быстрее?

Анатомия сигнатуры: разбираем живой пример

Чтобы понять, как IPS принимает решения, разберём реальную сигнатуру для детекта активности Sliver C2 — кросс-платформенного фреймворка для red team операций:

alert http any any -> any any (sid:10008548; rev:3; msg:"TOOLS [PTsecurity] Sliver C2 HTTP Polling (English)"; classtype:attack-feature; flow:established, from_server; http.header; content:"Content-Type|3A| text/plain|3B| charset=utf-8|0d 0a|"; nocase; content:!"Content-Encoding"; nocase; http.response_body; pcre:"/^(?:[A-Z]{2,20}\s?){40,}$/Q"; flowbits:isset, Sliver.HTTP.Encoders; threshold:type limit, track by_src, count 1, seconds 300; metadata:updated_at 2025_03_20; metadata:att_ck TA0011-T1071.001, attack_target client; reference:url,github.com/BishopFox/sliver;)

Общая информация

• SID (Signature ID): 10008548 — уникальный идентификатор правила
• Ревизия: 3 — порядковый номер версии сигнатуры
• Название: TOOLS [PTsecurity] Sliver C2 HTTP Polling (English)
• Тип класса: attack-feature (атакующая функциональность)
• Последнее обновление: 20 марта 2025 года

Основные условия срабатывания

1. Тип трафика: HTTP на любых адресах и портах — правило не привязано к конкретным узлам

http any any -> any any

2. Состояние соединения: анализируются ответы при установленной сессии, то есть трафик от сервера

flow:established, from_server

3. HTTP-заголовки:

• В ответе явно указан Content-Type: http.header; content:"Content-Type|3A| text/plain|3B| charset=utf-8|0d 0a|"; nocase;
• И нет Content-Encoding (значит, тело не сжато или не перекодировано): content:!"Content-Encoding"; nocase;

4. Тело ответа: длинная «россыпь» слов из заглавных букв — маркер специфического кодирования команд

http.response_body; pcre:"/^(?:[A-Z]{2,20}\s?){40,}$/Q";

5. Контекст: ранее установленный flowbit подтверждает, что мы уже видели характерный этап обмена этого C2

flowbits:isset, Sliver.HTTP.Encoders;

Дополнительные параметры

Антиспам-ограничение: не чаще одного совпадения в 300 секунд по источнику

threshold:type limit, track by_src, count 1, seconds 300;

Привязка к MITRE ATT&CK: помогает отнести событие к правильной тактике и технике:

• тактика: TA0011 — Command and Control
• техника: T1071.001 — Application Layer Protocol: Web Protocols
• цель атаки: клиент (client)

Логика сигнатуры: что ловим и почему

Правило рассчитано на HTTP-ответы без компрессии, где вместо обычных данных — длинные цепочки «слов» из заглавных букв. Такой паттерн отражает передачу команд/данных в рамках Sliver C2 через веб-трафик. Условие с flowbits гарантирует, что это не случайная строка, а продолжение распознанного обмена.

В итоге правило ловит управляемые сессии фреймворка Sliver, не трогая нормальные ответы. Важная деталь — привязка к ранее установленному контексту: без соответствующего флага правило не сработает, что снижает шум.

Пример трафика, который попадёт под сигнатуру

Вот HTTP-обмен, на который сработает наша сигнатура:

GET /bundle/bundle/app.js?q=2819b7413 HTTP/1.1
Host: 10.158.3.2
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4019.462 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Language: en-US,en;q=0.9
Cookie: AWSALBCORS=6653bcb1366c9410c0e122b604fc0ccc
Upgrade-Insecure-Requests: 1
Accept-Encoding: gzip

HTTP/1.1 200 OK
Date: Tue, 19 Sep 2023 19:30:30 GMT
Content-Length: 597
Content-Type: text/plain; charset=utf-8

BITTEREST THINGUMAJIG AUTOMATING AEROMETERS BOLL FIRETHORNS TIMIDITY ADROIT BOIL HOLOENZYME CHILIADAL SABERLIKE ALLOSTERIES INCIDENTALS TASKING UNFREED RIOJAS LESSENS CINEPHILE WEATHERGLASSES FOLD LANDLESSNESS BYLINES SATORIS SISSIES SUBOPTIMIZATION SUBMUCOSAL PEAKEDNESSES ANATOMICAL ANIMALIZED BIBLICISTS COUNTERMARCHING CYMA MITOCHONDRIAL ENSORCELLED BOUSED RECOMMENDING COLUMNEA COMPELLING VENTUROUSNESSES JILT OUTTELLS GANTRY BOMBARDMENT STULTIFICATIONS EGRESS REVERBERATION ARGILLITES CATCHWORDS REHEARSING OUTLIVED RATANIES DEERSTALKER DECAPITATES INARGUABLE MALODOROUS DROPSONDES TOLIDINES

Действия IPS: что происходит после детекта

Когда контекст совпадений выстроен, IPS выполняет действие из правила - здесь это действие alert. При смене режима на блокирующий важно сначала проверить поведение в журналировании, затем переводить те же сигнатуры в блокировку на контролируемых сегментах.

Сигнатуры поддерживают базовый набор действий движка, и понимать их семантику критично для правильной политики:

1. alert — Создаёт событие и пишет его в журнал, не вмешиваясь в обмен. Подходит для наблюдения и тонкой обкатки набора правил.
2. drop — Отбрасывает пакеты, попавшие под условие. Используется для немедленного пресечения атаки в потоке.
3. reject — Блокирует и уведомляет одну или обе стороны (варианты: rejectsrc, rejectdst, rejectboth). Полезно, когда нужно явно завершить сессию.
4. quarantine (название зависит от вендора) — Изолирует инициатора или получателя — логика близка к антивирусному карантину.

IPS vs потоковый антивирус: в чём разница?

Частый вопрос: чем IPS отличается от потокового антивируса, если оба «на сигнатурах»? Пространством видимости и уровнем модели OSI. IPS работает на 3/4/7 уровнях, анализируя весь поток, а потоковый антивирус сфокусирован на объектах прикладного уровня.

В реальности они дополняют друг друга: хостовый агент закрывает то, что сетевой экран не видит, а NGFW с IPS и песочницей снимает риски ещё до попадания файла на узел. Хостовый антивирус к тому же не влияет на полосу пропускания межсетевого экрана, поэтому для стойкости разумно использовать эшелонированную схему.

Синтаксис: красота и проклятье совместимости

Синтаксис «как у Suricata» встречается повсеместно: в правиле всегда зафиксированы направление, протокол и искомый контент, а также параметры поиска (смещения, глубина, окно). Цена удобства — производительность: включение IPS у большинства производителей по даташитам заметно урезает паспортную полосу (порядка 60–70%), потому что движок выполняет глубокий разбор пакетов, восстанавливает сессии и применяет крупные наборы условий.

Почему IPS превращает файрвол в тормоза

Производительность проседает по честной причине: DPI разбирает каждый пакет, восстанавливает сессию, анализирует заголовки и полезную нагрузку на протоколах HTTP/HTTPS/DNS/FTP и др., а потом гоняет всё через большие множества правил. Чем шире и «тяжелее» набор сигнатур и чем глубже анализ (много PCRE, flowbits, декодеров), тем выше стоимость обработки.

Поэтому использование IPS с настройками «по умолчанию» (когда включены все доступные правила без разбора) почти всегда приводит к падению сквозной скорости — и к разочарованию. Количество правил само по себе не равно качеству: куда важнее их релевантность вашим сервисам и точно сформулированные условия срабатывания. Под условиями срабатывания понимаются предикаты — логические выражения в сигнатуре, которые определяют, при каких именно обстоятельствах правило должно сработать. Например, проверка конкретного содержимого в HTTP-заголовках, анализ определённых байтовых последовательностей в полезной нагрузке или сочетание нескольких факторов одновременно. Чем точнее сформулированы эти условия, тем меньше ложных срабатываний и выше общая производительность системы.

Контроль приложений: когда IPS становится умнее

Контроль приложений (Application Control) добавляет IPS контекст: по поведенческим признакам и TLS-фингерпринтам движок понимает источник трафика и применяет релевантные сигнатуры — меньше лишних проверок и выше точность детекта. Это помогает корректно распознавать «приложения поверх TLS» (вроде Skype over HTTPS или Telegram MTProto), где одних портов/адресов недостаточно.

Работа под нагрузкой: что происходит на пике

На пике нагрузки важно, как устроена логика работы NGFW. В некоторых системах IPS выключают, чтобы сохранить доступность. В других — как в PT NGFW — проверки на действующих сессиях не останавливаются, а просто перестают открываться новые, чтобы атака не прошла под шумок. Такой подход уменьшает окно для злоумышленника, который мог бы попытаться перегрузить устройство DDoS-ом и пройти дальше при выключенном движке.

Тестирование: как не попасться на маркетинговые цифры

«Сделаем быстро и без просадки» — заманчиво, но бесполезно, если сигнатуры поверхностные. Качество IPS меряют в двух плоскостях: руками и с помощью специализированных средств. Эталон — сочетать оба метода и проверять не только факт детекта, но и влияние на производительность.

Ручное тестирование: медленно, но честно

Ручной подход — заведомо уязвимые сервисы, Metasploit, эксперимент с ICMP-туннелем — даёт прозрачный результат и ценную отладку компенсирующих мер, но требует времени и аккуратности. Плюс этого пути — максимально приближённая к реальности проверка, где видно, как IPS ведёт себя на конкретных протоколах и полезных нагрузок вашей инфраструктуры.

Сканеры автоматизируют рутину и хорошо закрывают стадию разведки из MITRE ATT&CK (адреса, порты, сервисы), но не претендуют на полноту по всем тактикам/техникам/процедурам.

• Тактика — желаемый итог злоумышленника на конкретном этапе атаки, то, к чему он стремится в рамках операции.
• Техника — способ достижения этой цели: используемые приёмы, утилиты, эксплойты, скрипты, фреймворки и прочие средства.
• Процедура — пошаговая реализация выбранного способа. Пример: вредонос через PowerShell выгружает полезную нагрузку, после чего она подтягивает Cobalt Strike и пытается запуститься на удалённых системах.

Результаты нужно уметь интерпретировать. Полезно фиксировать, какие именно этапы «цепляет» IPS и почему: это облегчает настройку правил и харденинга после тестов.

Синтетические тесты: красивые цифры, сомнительная польза

Многие вендоры NGFW тестируют IPS на IXIA: экран подключают двумя интерфейсами и гоняют поток со «страйками» — наборами атак, подобранных по актуальности, сервисам и CVSS. Смысл есть только тогда, когда страйки совпадают с реальными сервисами вашей инфраструктуры.

Итог дают в одной цифре — catch rate, доле отражённых атак. Цифру легко «надуть» сигнатурами, заточенными под синтетику: на бумаге 99–100%, в живом трафике — шум, ложные срабатывания и сожжённый CPU. Из-за дефицита экспертизы синтетика нередко становится единственным мерилом, хотя рынку нужна общая, прозрачная методика оценки NGFW.

Реальная эксплуатация: как не отключить IPS «временно»

Плохо написанные правила либо режут легитимный трафик, либо тормозят железо, и администратор их просто отключит — устойчивость упадёт. Ответственность за качество лежит на вендоре: экспертные центры, разбор реальных инцидентов, «экономные» и точные сигнатуры.

В реальности всё, что мешает продакшену, чаще всего сначала отключают «временно», а потом об этом попросту забывают. Так нередко и заканчивается история IPS — печальный, но типичный сценарий.

Два подхода к применению правил

Чтобы этого не случилось, важно понимать, как именно движок проверяет поток у разных вендоров. В целом встречаются два подхода:

• Вариант первый — проверка только теми правилами, которые входят в набор, привязанный к конкретному разрешающему правилу межсетевого экрана. Администратору приходится вручную собирать релевантный список сигнатур под нужный трафик и после каждого изменения внимательно смотреть на последствия для детекта и производительности.
• Вариант второй — анализ всем пулом сигнатур вне зависимости от того, какие наборы подвешены к правилу. При этом действия над трафиком и события в логах возникают только по тем сигнатурам, что включены в выбранный набор. Такой режим упрощает жизнь администратору: не нужно нервничать из-за распределения «тяжёлых» правил между наборами и их влияния на ресурсы. Именно так устроен IPS в PT NGFW.

В обоих случаях нельзя забывать об обновлениях. База правил регулярно меняется, и после очередной выгрузки нагрузка на устройство может подрасти — если новые или переработанные сигнатуры сделаны неаккуратно. А может и не измениться вовсе — всё упирается в качество экспертизы поставщика.

Практические советы: как внедрить IPS без боли

Когда сеть меняется — появляются новые сервисы, подсети и доступы — важно не «убить» перегретый межсетевой экран при включении IPS на новом сегменте. Рабочая схема простая: зеркалировать весь трафик с интерфейсов через ответвители, а шифрованный — с NGFW через сетевой брокер в NTA; на брокере обязательно исключать шифрованный поток.

Это даёт возможность заранее изучить трафик новых сегментов, увидеть, какие сигнатуры срабатывают, и осознанно добавить нужные в набор IPS у соответствующего правила NGFW.

Если NTA нет, включите полный набор сигнатур в режиме alert, отследите ложные срабатывания на легитимный трафик, затем переведите безопасные правила в drop/reject. На границах критичных сегментов IPS заметно повышает защищённость, а гранулярные политики доступа по геолокации, TCP/UDP-портам, приложениям и пользователям сужают поверхность атаки и мешают латеральному перемещению.

Заключение: сигнатуры — это код вашей безопасности

NGFW остаётся ключевым элементом сетевой архитектуры и инструментом реагирования — выбирайте и эксплуатируйте его аккуратно. В сухом остатке: сигнатуры — это код вашей безопасности. Чем качественнее они написаны, чем аккуратнее подобран набор и чем прозрачнее процесс валидации, тем тише спят пользователи и тем спокойнее живёт ваш NGFW.

Помните: красивые цифры в презентациях вендоров — это одно, а реальная работа в продакшене — совсем другое. Тестируйте, настраивайте постепенно и не забывайте, что IPS — это не панацея, а важная часть эшелонированной защиты. Правильно настроенная система может стать вашим надёжным щитом, а плохо настроенная — головной болью на долгие месяцы.