IDS с автоматической блокировкой — это уже IPS? Не совсем

Под статьей про IPS на Хабре получилась содержательная дискуссия. Один из инженеров описал рабочую схему: Suricata получает копию трафика через SPAN, обнаруживает угрозу, скрипт разбирает журнал и через API добавляет IP-адрес в список блокировки на MikroTik. Автор несколько лет использует эту схему в рабочей инфраструктуре.

На первый взгляд получается почти IPS: атаку обнаружили, источник автоматически заблокировали. Но важнее не название, а момент, когда принимается решение о пропуске трафика.

В схеме со SPAN Suricata анализирует копию пакета. Оригинальный пакет к этому времени уже передан дальше. Затем событие должно попасть в журнал, его должен обработать скрипт, после чего изменится состояние межсетевого экрана. Это нормальная архитектура обнаружения с автоматической реакцией. Она вполне подходит, например, для блокировки известного C2 или подавления сканирования.

Но она не гарантирует предотвращения той попытки эксплуатации, которая вызвала сработку. К моменту блокировки необходимые атакующему данные уже могли попасть на защищаемый сервер. Здесь и проходит основная граница с IPS, работающим в разрыв трафика.

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

Но и представление «IPS проверил первый пакет и сразу все понял» слишком упрощено. Для части атак одного пакета недостаточно. Системе может потребоваться состояние TCP-потока, данные прикладного протокола, а иногда и расшифрованный TLS-трафик. Поэтому окончательное решение может появиться не сразу: документация Suricata описывает режим IPS как анализ накопленного потока, а не отдельных пакетов.

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

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

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

🔘Если задача — видеть угрозы и ограничивать дальнейшую активность, Suricata на SPAN с автоматической реакцией через межсетевой экран может быть отличным и экономически разумным решением.
🔘Если требование звучит как «эта попытка эксплуатации не должна дойти до сервиса», обнаружение и блокировка должны находиться непосредственно в тракте прохождения трафика.

Это точнее описывает разницу между IDS с автоматической реакцией и IPS, чем привычное «IDS обнаруживает, IPS блокирует».

Если такие технические разборы интересны — напишите в комментариях, продолжим 😉