Пробы

Вероятно оттого, что много лет своей практики я потратил на сетевой мониторинг, я верю в IDS, И после того, как они стали вытесняться IPS, и сейчас, когда пропали и последние, войдя в понятия NG-FW, WAF, App-level-FW и т.п.

Аргументы, которыми маркетанты препарируют IDS не состоятельны так же, как не состоятельна и вера в абсолютную эффективность превентивных средств защиты, поскольку у них есть, как минимум, одна большая проблема: если вероятность фолсы (false positive) более 0% существует риск остановить продуктивный сервис, и в этом случае ущерб возможен выше, чем от пропуска атаки (false negative). Поддерживая концепцию эшелонирования подходов: 1) предотвратить, 2) если нельзя - обнаружить, 3) если нельзя - искать и находить, - получаем, что наличие IPS не отменяет необходимости IDS (в общем-то, они обе нужны), тем более не отменяет необходимость IDS наличие *-FW или любой другой пакетной фильтрации (понятно, что технически это может быть как угодно: IDS на RSPAN-е, IPS в разрыве или *-FW с активированными не только блокирующими правилами, но детектирующими (как раз для сбора информации, фингерпринтинга хостов в сети и фолсящих сигнатур, - сюда же всякие ML - не думаю, что кто-то доверит ML\DL что-либо блокировать автоматически)  - это не предмет данной заметки). При генерации грамотных логов, IDS можно использовать и для Threat hunting-а, так как доступна, как минимум, следующая информация:

• пассивный фингерпринтинг хостов в сети (версии ОС, версии приложений, известные уязвимости), 
• по каким протоколам трафик ходит между какими хостами в каком объеме, поскольку разбирается трафик приложений, IDS может видеть пересылаемые файлы (некоторые могут эти файлы выкусывать и складывать),
• всевозможные аномалии: 
• отклонения от RFC, 
• потери пакетов и обращения к несуществующим адресам или закрытым портам - пробы (причем, с контекстом: соединение отвалилось по таймауту, прилетел RST или ICMP unreachable), 
• всевозможные сканирования (причем, нормальная IDS будет определять тип сканирования и в некоторых случаях сканер), бруты, фаззинги,
• пролетающие по сети эксплоиты и нагрузки, в общем случае - все сетевые атаки.

Если даже у вас заблокирован доступ в подсеть, согласитесь, полезно знать кто туда хотел, но не смог, попасть по каким портам - отличный повод с этим поразбираться. Если на какой-то хост вы вдруг стали наблюдать кучу проб, это может означать, что на нем отъехала служба или до нее пропала сетевая доступность, Любопытно видеть попытки подключения к несуществующим хостам или закрытым портам... Тем более интересно видеть попытки отправить туда эксплоит. 

Все сетевые черви, с которыми я сталкивался в своей практике прекрасно ловились и контролировались IDS-кой. Сначала сканы\пробы, затем отправка эксплоита, получение нагрузки, - и вот уже этот хост пробует и сканирует других, отправляет на них эксплоиты и пейлоуды. При наличии достаточного количества информационных событий IDS, можно даже для вполне "тихих" атак составить довольно нефолсяций профиль поведения в виде последовательности и\или совокупности определенных событий IDS, что позволит легко на фоне шума определять атаку еще на первых этапах поиска новой цели.

"Шумность" IDS хорошо профилируется (можете называть это ML, но я о статистике - любой современный SIEM это умеет), поэтому обращать внимание в общем случае нужно на отклонения. Все остальные события (aka "шум") будут крайне полезны при сетевой форенсике, расследовании инцидента.