Кибератака не всегда выглядит как взлом. Иногда это обычный вход по легальному ключу, в рабочее время, через открытый 22-й порт: файрвол пропускает, потому что все правила соблюдены. Он решает, кому открыть дверь, а что вошедший делает внутри — уже не его задача.
Смотреть внутрь умеют другие системы — IDS и IPS. Они смотрят не только на адреса и порты, но и на протоколы, содержимое и поведение трафика, а еще замечают то, для чего у файрвола нет правила, — сканирование, попытку эксплуатации уязвимости или странную активность уже после входа.
Рассказываем, чем IDS отличается от IPS, какими они бывают по месту установки и принципу работы, куда их включают в сеть, что выбрать из бесплатного и почему IPS чаще всего мешает работе в первую же неделю после включения.
Материал пригодится админам и девопсам, которые впервые настраивают защиту периметра, начинающим специалистам по ИБ и студентам — тема стабильно попадается на собеседованиях.
Что такое IDS и IPS
IDS (Intrusion Detection System) — это система обнаружения вторжений, ПО, которое анализирует сетевой трафик или события на хостах, находит подозрительную активность и сообщает о ней администратору.
IPS (Intrusion Prevention System) — это система предотвращения вторжений. Она не только выявляет подозрительные действия, но и блокирует трафик или разрывает соединение, чтобы их остановить.
В российских документах и вакансиях встречаются и аббревиатуры СОВ и СОА: СОВ — система обнаружения вторжений, СОА — система обнаружения атак.
Рассмотрим на примере охраны здания. IDS ведет себя как камера с сигнализацией: она замечает, что кто-то подошел к запертой двери в три часа ночи, и присылает сообщение на пост охраны, но не блокирует двери. IPS в той же схеме — охранник у входа, который сам решает, пускать человека дальше.
Вторжением здесь называют подозрительную активность, которая может указывать на атаку или попытку получить несанкционированный доступ. IDS и IPS ищут признаки вторжения на разных этапах — от разведки до вывода данных. Например, при сканировании портов тот, кто атакует, массово опрашивает хост в поисках открытых сервисов. При эксплуатации известной уязвимости злоумышленник отправляет специально сформированный пакет, который заставляет уязвимый код выполнить нежелательное действие. При брутфорсе система фиксирует множество попыток входа по SSH или в веб-панель. Если злоумышленник уже заразил машину внутри сети, она может периодически связываться с сервером управления — такой исходящий трафик тоже становится признаком компрометации. Наконец, на этапе вывода данных система может заметить необычную передачу большого объема информации на внешний адрес, например архива с базой клиентов через FTP или HTTPS.
Чем IDS отличается от IPS
Для сетевых IDS и IPS одно из ключевых различий — режим подключения к сети. IDS обычно работает с копией трафика: зеркалированный порт коммутатора или отдельный ответвитель отдают ей дубликат пакетов, а оригинал идет своим путем независимо от того, что решит система анализа. IPS для блокировки ставят в разрыв канала: через нее физически проходит весь трафик, поэтому она может остановить конкретный пакет или сбросить сессию целиком.
Отсюда разная цена ошибки. Ложное срабатывание IDS оборачивается лишним алертом, который аналитик должен проверить. Ложное срабатывание IPS может заблокировать легитимный запрос клиента, а неточное правило — нарушить работу сервиса, причем чем крупнее компания, тем дороже обходится каждая минута простоя.
Чтобы снизить этот риск, используют аппаратный обход — bypass. Это отдельный модуль в самой IPS или во внешней коробке, который при отказе софта или потере питания может замкнуть канал напрямую, в обход анализирующего движка. Если IPS настроена на fail closed, отказ inline-сенсора без bypass может остановить канал связи; при fail open трафик продолжит идти без фильтрации.
Из-за этой разницы в рисках вендоры сейчас все чаще продают единый продукт под маркировкой IDPS вместо отдельных IDS и IPS — он умеет работать в обоих режимах и переключается между ними в зависимости от того, насколько администратор уверен в конкретном правиле.
Зачем нужны IDS и IPS, если уже есть файрвол
Пакетный файрвол или файрвол с отслеживанием состояния соединений принимает решение в основном по IP-адресам, портам и состоянию соединения. Файрволы с прикладной инспекцией могут анализировать и прикладной трафик. IDS и IPS смотрят на содержимое и поведение трафика: например, разбирают протоколы, ищут характерные паттерны атаки или отмечают, что один и тот же хост за минуту опросил три тысячи портов подряд.
Тот же вопрос обычно всплывает и про соседние классы систем. WAF занимается похожей задачей, но узко для веб-трафика: разбирает HTTP-запросы и ловит SQL-инъекции и XSS на уровне приложения, а на TCP-аномалии или атаки на другие протоколы не обращает внимания.
SIEM решает другую задачу — сопоставляет логи из разных источников, включая те же IDS, файрволы и серверы, и для него IDS остается одним из поставщиков сырых событий. EDR тоже работает на конечных точках, но идет дальше простого обнаружения: позволяет расследовать события и выполнять ответные действия — например, изолировать устройство или остановить вредоносный процесс.
Там, где заканчивается зона ответственности файрвола, начинается зона IDS и IPS. Как она устроена, разберем дальше.
Как устроены IDS и IPS изнутри
Проще всего понять архитектуру, если проследить путь одного пакета от сетевой карты до алерта на экране аналитика.
В сетевой IDS первым пакет получает сенсор — модуль, который снимает копию сетевого трафика с интерфейса. У хостовых систем источники другие — это системные события, процессы, файлы и логи.
Дальше данные проходят нормализацию: отдельные пакеты собираются обратно в TCP-поток, а разные варианты записи одного и того же протокола приводят к единому виду. HTTP-запрос можно закодировать десятком способов, и сравнивать сырые байты с сигнатурой бессмысленно, если атакующий раздробил вредоносный запрос на несколько мелких пакетов или использовал нестандартную кодировку заголовка. Именно на этом этапе IDS ловит попытки обхода через фрагментацию, когда исходный вредоносный запрос специально режут на куски, каждый из которых по отдельности безобиден, а движок без нормализации проверяет пакеты по одному и пропускает угрозу.
После нормализации данные попадают в движок, который сравнивает их с базой правил — сигнатур или статистической модели нормального трафика, в зависимости от типа анализа. Результат уходит в одном из трех направлений: в локальный лог системы, во внешнюю систему сбора событий вроде SIEM или сразу в модуль блокировки, если система работает как IPS.
База правил — отдельная история, в которой стоит разобраться до настройки системы. Для популярных IDS/IPS-продуктов Suricata и Snort основной бесплатный источник — набор Emerging Threats, который поддерживает компания Proofpoint и обновляет по несколько раз в неделю. Утилита suricata-update просто скачивает актуальную версию по расписанию через cron. Коммерческие вендоры держат собственные лаборатории анализа угроз и обновляют сигнатуры быстрее, но и стоит это дороже.
Виды IDS по месту установки
По месту установки IDS делятся на два основных типа: одни следят за всей сетью, другие — за отдельным компьютером.
NIDS — сетевые
NIDS установлены на уровне сети и получают копию трафика целого сегмента через зеркалированный порт или ответвитель. Они видят сканирование портов, попытки эксплуатации через протокол, аномальные объемы трафика между хостами — все, что происходит между машинами.
Чего они не увидят, так это действий внутри одного хоста: что запустил пользователь после того, как получил доступ, какой процесс читает файл с паролями, менялся ли системный реестр. Если активность не выходит за пределы памяти и дисков конкретной машины, для NIDS ее просто не существует.
HIDS — хостовые
HIDS ставят агентом прямо на сервер или рабочую станцию. Они отслеживают происходящее изнутри: системные вызовы, изменения файлов, записи в логах аутентификации, запущенные процессы. За счет этого HIDS видит события на самом хосте и действия после успешного входа, которые могут пройти мимо сетевой IDS. Если приложение уже расшифровало TLS-трафик, доступность этих данных для HIDS зависит от возможностей конкретного агента. Соседние серверы в том же сегменте для них недоступны, и если агент не установлен на конкретную машину, то для HIDS этой машины не существует.
Офисная сеть с зонами видимости NIDS и HIDS
Какие еще IDS бывают
Встречаются и более узкие обозначения. WIDS — версия NIDS для Wi-Fi, которая ловит поддельные точки доступа и попытки деаутентификации. PIDS следит за одним протоколом, например отдельно разбирает FTP-сессии на файловом сервере. APIDS работает на уровне конкретного приложения, часто — веб-сервера или СУБД, и понимает логику именно этого софта тоньше, чем универсальный NIDS.
Отдельно стоит honeypot — подставная система, которая изображает уязвимый сервер и ничего реально не защищает, зато любое обращение к ней подозрительно по определению: у настоящего пользователя нет причин туда стучаться. Часто honeypot ставят рядом с IDS именно ради этого — любой трафик к нему становится готовым поводом для алерта без единой сигнатуры.
Виды IDS и IPS по принципу действия
Классификация по месту установки отвечает на вопрос, где стоит система. Следующая делит их по другому признаку — что именно система сравнивает, чтобы решить, атака перед ней или нет.
Сигнатурный анализ
Сигнатурный анализ сравнивает трафик с базой готовых шаблонов, описывающих уже известные атаки. Разберем настоящее правило из набора Emerging Threats, которое ловит характерный признак сработавшего теста testmynids.org — к нему еще вернемся в практической части:
alert ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; classtype:bad-unknown; sid:2100498; rev:7;)
Здесь:
- alert — действие; если правило сработает, событие уйдет в лог как алерт вместо того, чтобы быть молча пропущенным;
- ip — протокол; правило смотрит на любой IP-трафик, не сужаясь до TCP или UDP;
- any any -> any any — направление; адреса и порты источника и назначения не ограничены, важен только сам байтовый паттерн внутри пакета;
- content:»uid=0|28|root|29|» — конкретная строка, которую движок ищет в теле пакета; скобки в исходном тексте uid=0(root) закодированы шестнадцатеричными значениями |28| и |29|, потому что круглые скобки — служебные символы самого языка правил и их приходится экранировать именно так;
- classtype — категория для отчетов и приоритизации;
- sid:2100498 — уникальный номер правила, по которому его можно найти в базе и в собственных логах;
- rev:7 — седьмая редакция этого правила с момента создания в 2010 году.
У сигнатурного анализа есть жесткая граница возможностей: он ловит то, что уже описано в правилах. Атака нулевого дня, для которой нет подходящей сигнатуры, может пройти мимо такого анализа независимо от того, насколько свежую версию базы вы скачали вчера.
Анализ аномалий
Анализ аномалий работает иначе: система сначала какое-то время наблюдает за трафиком без готовых шаблонов и строит статистическую модель того, что для этой сети нормально — какие порты обычно открыты, сколько соединений в минуту устанавливает типичный сотрудник, в какое время суток идет основная нагрузка. Дальше все, что заметно отклоняется от этой модели, помечается как подозрительное.
Первые недели после запуска почти всегда получаются шумными: система еще не набрала достаточно данных, поэтому любая нестандартная, но легальная активность — ночное резервное копирование, разовая массовая рассылка из отдела маркетинга — попадает в подозрительные.
Период обучения от двух до четырех недель закладывают именно по этой причине. Хотя в бесплатной поставке большинство пользователей ограничиваются сигнатурами и репутационными списками, а полноценное машинное обучение для поведенческого анализа чаще встречается уже в коммерческих продуктах вроде линеек Kaspersky и Positive Technologies.
Гибридный подход и репутационные списки
На практике редко используют только один из двух методов. Сигнатуры хорошо ловят описанное и известное, аномалии реагируют на новое и нетипичное. Сверху обычно добавляют репутационные списки — базы IP-адресов и доменов, которые уже засветились в атаках на других сетях, и обращение к ним само по себе повод для алерта без разбора содержимого пакета.
Комбинация методов дает более полную картину, но каждый добавляет свою долю рутины.
| Метод | Что ловит | Что пропускает | Ложных срабатываний | Работы после внедрения |
| Сигнатуры | Известные атаки с опубликованным паттерном | Новые техники и измененные эксплойты | Немного, если база актуальна | Регулярное обновление правил |
| Аномалии | Отклонения от привычного трафика, включая новые схемы | Атаки, похожие на обычный трафик | Зависит от модели и качества настройки, в среднем — много в первые недели, потом снижается | Настройка порогов, разбор ложных тревог |
| Репутационные списки | Обращения к уже засвеченным адресам и доменам | Свежую инфраструктуру, еще не попавшую в списки | Минимум при качественном списке | Подписка на фид репутации и его обновление |
Куда включают IDS и IPS в сети
Физически подключить IDS или IPS к сети можно четырьмя способами.
Зеркалирование порта (SPAN) — самый распространенный вариант: коммутатор настраивается так, чтобы отправлять копию трафика с одного или нескольких портов на отдельный порт, к которому подключен сенсор.
Сетевой ответвитель (tap) — отдельное устройство, которое физически встраивается в кабель между двумя точками сети и снимает копию сигнала, не полагаясь на настройки коммутатора, поэтому переживает даже перегрузку самого коммутатора.
Включение в разрыв дает IPS прямую возможность отбрасывать проходящий трафик: весь поток физически идет через сенсор. Агент на хосте относится уже к HIDS: программа ставится прямо на сервер и снимает данные из самой системы.
Отдельный вопрос — ставить систему до файрвола или после. До файрвола IDS увидит весь входящий трафик, включая то, что файрвол потом отбросит, и это удобно для статистики по атакам на периметр в целом. После файрвола система разбирает уже отфильтрованный трафик — тот, что реально дошел до внутренней сети, — и этот вариант ставят чаще: выискивать атаку внутри пакетов, которые все равно никуда не попадут, довольно затратно по ресурсам и не очень полезно на практике.
По расположению системы обычно делят на три зоны:
- периметр, где встречается основной объем внешнего трафика;
- демилитаризованная зона, где стоят публичные сервисы вроде почтового сервера или веб-приложения;
- внутренние сегменты, где ловят уже перемещение атакующего внутри сети после того, как первый рубеж пройден.
Облако работает по другим правилам: физического порта для зеркалирования там просто нет, и копию трафика приходится запрашивать у самой платформы. В AWS для этого есть VPC Traffic Mirroring. В Azure Network Watcher Packet Capture используют для захвата пакетов, а Virtual Network TAP — для передачи копии трафика в анализатор.
Главное ограничение работает одинаково и в облаке, и на железе: подавляющая часть трафика сегодня зашифрована, а внутрь TLS-сессии система без дополнительных мер не заглянет.
Первый вариант — расшифровывать трафик на отдельном устройстве, SSL-инспекторе, который встает посередине сессии, разбирает содержимое и снова зашифровывает пакет перед отправкой дальше. У этого решения есть цена — дополнительная задержка и вопросы о том, что именно и в каком объеме разрешено расшифровывать.
Второй вариант — анализировать то, что видно и без расшифровки: размеры и тайминг пакетов, длину и порядок TLS-хендшейка, отпечаток клиента по JA3. Такой отпечаток помогает сопоставлять TLS-клиента с известными приложениями или вредоносными образцами, но сам по себе не доказывает, что трафик вредоносный.
Какие IDS и IPS выбрать
Для защиты сети и хостов есть сетевые движки с открытым кодом, отдельный класс хостовых агентов для конечных точек и коммерческие платформы. Разберем каждый класс по порядку, начиная с инструмента, с которого все началось.
Snort
Snort — первая по-настоящему массовая система такого рода, ее написал Мартин Реш в 1998 году. Формат правил Snort — тот самый action/protocol/direction/options, разобранный выше, — стал отраслевым стандартом, его понимают почти все конкуренты, включая Suricata. Третья версия, Snort 3, вышла в статусе GA в 2021 году и добавила многопоточность, которой первым двум версиям не хватало.
Suricata
Suricata изначально строилась с прицелом на многопоточную обработку. Snort 3 тоже поддерживает несколько потоков обработки пакетов, поэтому производительность современных версий корректнее сравнивать на конкретном трафике, железе и наборе правил. При этом у Suricata есть свои преимущества: движок понимает правила формата Snort почти без переделки, умеет работать и в режиме наблюдения, и в режиме блокировки, а логи по умолчанию пишет в JSON через eve.json. Их удобно скармливать любой системе анализа без написания отдельного парсера под текстовый формат.
Zeek
Zeek, до 2018 года известный как Bro, — не классическая сигнатурная IDS. Это платформа анализа сетевого трафика со своим языком сценариев: она разбирает протоколы в подробные структурированные логи и позволяет задавать локальные правила обнаружения и уведомлений. Его часто ставят рядом с Suricata именно за эту детализацию: когда сигнатурная система нашла подозрительный IP, логи Zeek позволяют быстро поднять всю историю его активности в сети, вплоть до конкретных файлов, которые скачивались с этого адреса.
Хостовые агенты: Wazuh, Falco
Wazuh — система мониторинга безопасности на основе OSSEC (Open Source Security Event Correlator), с современным веб-интерфейсом и встроенными инструментами для работы с логами. Его обычно ставят на обычные серверы и рабочие станции, где нужен полноценный HIDS с анализом логов, контролем целостности файлов и проверкой конфигурации на соответствие CIS-бенчмаркам.
Falco — инструмент для обнаружения подозрительной активности в контейнерной инфраструктуре. Он в реальном времени отслеживает системные вызовы Linux и по ним выявляет необычные действия внутри контейнеров и Kubernetes. Falco изначально создавали в компании Sysdig для защиты контейнерных сред, поэтому его используют там, где обычного мониторинга отдельного сервера недостаточно.
Например, Falco может заметить, что контейнер запустил оболочку, обратился к чувствительному файлу или неожиданно попытался изменить системные настройки. Такой подход дополняет HIDS: классические HIDS в первую очередь контролируют отдельный сервер, а Falco учитывает специфику контейнеров и Kubernetes.
Российские решения и смежные системы
На российском рынке есть продукты разных классов. Kaspersky KUMA — SIEM, PT NAD анализирует сетевой трафик и обнаруживает атаки, а PT Sandbox предназначен для анализа подозрительных файлов и вредоносного ПО. Такие системы могут работать в одном контуре защиты, но решают разные задачи.
В регулируемых системах требования к средствам защиты зависят от типа системы и применимого нормативного акта. Для ГИС действует приказ ФСТЭК №117, для значимых объектов КИИ — приказ №239. Поэтому перед выбором IDS/IPS нужно проверить требования именно для своего контура.
Как работает IPS/IDS на примере: практика с Suricata
Дальше — быстрый практический пример, чтобы увидеть весь цикл от установки до первого алерта своими глазами. Ставить будем на Ubuntu, потому что под нее собраны официальные пакеты, а разворачивать — либо на VPS, либо в Docker-контейнере на любой машине с Linux. Для теста подойдет даже минимальная конфигурация вроде бесплатного тарифа AWS.
Подключаемся к серверу по SSH и обновляем список пакетов:
sudo apt update && sudo apt install -y suricata
После установки смотрим имя сетевого интерфейса командой ip addr и проверяем его в конфигурации Suricata.
Дальше обновляем набор правил встроенной утилитой:
sudo suricata-update
По умолчанию она скачивает открытый набор Emerging Threats Open и сохраняет правила в /var/lib/suricata/rules, объединяя их в файл suricata.rules.
Запускаем сервис и проверяем статус:
sudo systemctl restart suricata sudo systemctl status suricata
Если статус active (running), сенсор слушает интерфейс и готов ловить трафик. Открываем второе окно терминала и держим лог на экране:
sudo tail -f /var/log/suricata/fast.log
С этого же сервера отправляем запрос к специальному тестовому адресу командой curl http://testmynids.org/uid/index.html:
Сайт в ответ присылает строку uid=0(root) gid=0(root) groups=0(root) — безобидную по сути, но специально подобранную так, чтобы совпасть с сигнатурой из примера выше. В окне с логом почти сразу появится строка вида:
09/07/2026-10:13:45.520650 [**] [1:2100498:7] GPL ATTACK_RESPONSE id check returned root [**] [Classification: Potentially Bad Traffic] [Priority: 2] {TCP} 217.160.0.187:80 -> 172.31.31.156:39788
Разберем эту строку по частям, слева направо. 09/07/2026-10:13:45.520650 — время события с точностью до микросекунд.
[1:2100498:7] — тройка generator id, sid и rev: единица означает обычный движок правил, 2100498 — номер сработавшей сигнатуры, 7 — ее редакция, та же, что и в тексте правила выше.
GPL ATTACK_RESPONSE id check returned root — это поле msg из правила, человекочитаемое описание того, что сработало.
[Classification: Potentially Bad Traffic] — расшифровка classtype в читаемую категорию.
[Priority: 2] — приоритет события: чем меньше число, тем критичнее считается сигнатура.
{TCP} — протокол.
Последняя часть, 217.160.0.187:80 -> 172.31.31.156:39788, — это адрес и порт источника, затем адрес и порт назначения.
Для более подробной версии того же события смотрим eve.json — структурированный лог, где на каждый алерт приходится полный набор полей: время, IP и порты обеих сторон, протокол приложения, категория и приоритет сигнатуры. Для удобного чтения ставим jq:
sudo apt install -y jq sudo tail -n 1 /var/log/suricata/eve.json | jq .
Получится развернутая карточка того же события, которое секундой раньше промелькнуло одной строкой в fast.log.
В конце имеет смысл хотя бы посмотреть, как включается режим блокировки, но не оставлять его включенным на этом же сервере.
Перевод в inline-режим на одиночной VPS с одним сетевым интерфейсом требует настройки NFQUEUE через iptables и фактически означает, что весь трафик сервера, включая собственный SSH-сеанс, начинает проходить через анализирующий движок.
Если политика в этот момент настроена неточно или движок на секунду завис под нагрузкой, сессия управления обрывается вместе с остальным трафиком, а восстановить доступ можно только через отдельную консоль провайдера — у AWS это EC2 Serial Console, — потому что обычный SSH к заблокированному хосту уже не достучится.
Именно поэтому промышленные внедрения IPS почти всегда используют схему с двумя интерфейсами и отдельным управляющим каналом — единственный порт, через который проходит вообще все, для такой задачи слишком рискован.
Частые ошибки при внедрении
Как выбрать IPS/IDS и с чего начать
Универсального ответа «зависит от задач» здесь сознательно избегаем, потому что для первого опыта обычно хватает четырех конкретных вопросов:
- Сколько трафика нужно анализировать?
- Есть ли в команде человек, который будет регулярно разбирать уведомления?
- Нужна ли сертификация ФСТЭК по типу инфраструктуры?
- Что из смежных систем уже куплено — SIEM, файрвол нового поколения со встроенным IPS-модулем?
От объема трафика зависит, справится ли бесплатный сенсор с работой на обычном сервере или нужно закладывать отдельное железо под нагрузку. Система без человека, который читает алерты, превращается в дорогой генератор логов, которые никто не открывает. Если для конкретной инфраструктуры действуют обязательные требования к средствам защиты, их нужно учитывать при выборе продукта. Докупать отдельную систему туда, где нужная функциональность уже есть вместе с другим продуктом, обычно не имеет смысла.
Порядок внедрения при этом обычно похожий. Сначала система работает в режиме наблюдения и собирает данные: вы донастраиваете правила под свой трафик и разбираетесь, что из срабатываний — норма именно для вашей сети. Дальше включаете блокировку для небольшой группы самых надежных сигнатур — тех, где ложных срабатываний почти не бывает, — и только после того, как эта группа отработала стабильно, постепенно расширяете список правил, переведенных в режим блокировки.
