Ни один уважающий себя UTM-шлюз сетевой безопасности не обходится без системы обнаружения вторжений IDS (Intrusion Detection System). Другое дело, что опция зачастую указывается производителем для галочки, чтобы не отставать от конкурентов. Знаю по своему опыту тестировщика, как это бывает — вроде бы IDS есть, но по факту никуда не годится. Именно поэтому, когда мне предложили протестировать относительно недорогую UTM-“железку”, я предложил в первую очередь “прогнать” ее СОВ.

Если у вас есть опыт работы с IDS, интересно прочитать про него в комментариях к статье. Желательно — не про дорогие “железки” (понятное дело, что у какой-нибудь Cisco NGFW за миллион всё хорошо), а про решения, более доступные по цене. Думаю, администраторам локалок и потенциальным пользователям сетевых шлюзов будет любопытно обсудить, у кого как работает IDS, и стоит ли покупать задорого, когда можно, поплясав с бубном, добиться того же за меньшие деньги.

В данном тесте речь про модель S100 — самое демократичное по цене в линейке Traffic Inspector Next Generation (цифры означают, что она рассчитана на 100 абонентов). Вот ее описание на официальном сайте>>>. Если коротко, то в “железке” есть, например, сетевой фильтр, VPN, блокировщик ресурсов и, конечно же, IDS.

Методику тестирования предлагаю простую — проверяем пропускную способность, и строим зависимость количества отброшенных пакетов от интенсивности трафика с шагом: 50, 100, 150 и 200 Мб/с. Почему берем именно такие интервалы? Отталкиваемся от 100 Мб/с — самого популярного клиентского запроса, и от него откладываем плюс и минус, чтобы увидеть, что происходит в более и менее нагруженном режимах, а также в экстремальном режиме 200 Мб/с.

Жизненный опыт мне подсказывает, что со всеми активными правилами S100 может не потянуть, поэтому я предлагаю описанную процедуру провести в трех режимах: сначала когда все правила активны, затем с выключением части правил (назовем ее Группа № 1) и, наконец, только когда активно всего несколько правил (назовем ее Группа № 2). Формируем такие группы правил:

– Группа № 0: ну это понятно, все правила без исключения.
– Группа № 1: группа правил Emerging Threads (правила мне известны со времен тестирования IDS Snort, за исключением правил emerging-games).
– Группа № 2: группа правил, которые я считаю просто обязательными для работы IDS (см. ниже), в том числе добавим правила p2p, так как по собственному опыту знаю, как крупные компании негативно относятся к тому, что их сотрудники активно используют корпоративную сеть для скачивания любимых сериалов.

Тестирование осуществим с использованием утилиты tcpreplay. Данная утилита позволяет воспроизвести записанный предварительно сетевой трафик с определенной скоростью. Команда: tcpreplay –i <интерфейс> -l 0 testTI.pcap. Файл testTI.pcap содержит 1 146 313 пакетов (такой объем выбираем, чтобы, с одной стороны, была хорошая статистика, с другой — время на «прогон» не было бы слишком большим, в нашем случае — не более 15 минут ). Помимо этого, как я уже сказал, запускаем торрент-трекер.

Схема тестового стенда:




UTM-железка Traffic Inspector Next Generation S100 и свитч Cisco 2960G

Если у кого-то будут вопросы по методике тестирования — готов ответить в комментах.

Итак, результаты.

Группа № 0

Тестирование на полном наборе подразумевает загрузку всех правил, а их 30 305.

При тестировании используем настройки IDS по умолчанию:



Начинаем тестирование со 100 Мб/с и и понимаем, что железка еле тянет: из 114 тысяч пакетов 109 тысяч отброшено! Так что нет никакого смысла тестировать на 150 и тем более на 200 Мб/с. Наоборот, предлагаю дать девайсу шанс и провести дополнительный тест на 10 Мб/с. Результат в таблице:



Примечание:

kernel_packets — отправленные пакеты;
kernel_drops — отброшенные пакеты. Как видим, при настройках по умолчанию и при полном наборе правил происходят большие потери пакетов (> 30% относительно kernel_packets). Будем надеяться, что оптимизация правил настроек изменит ситуацию;
decoder_packets — количество пакетов, которые система корректно обработала;
detect_alerts — количество выявленных атак. Основную массу составляют атаки типа «Фрагментированный пакет», но и атаки «Выявление торрент-трекера» также были определены.

Группа № 1

Очевидно, что “железка” не оптимизирована работать как полноценная мощная IDS, но есть место для маневра, а именно — возможность изменить механизм поиска маршрутов, отключить загрузку в отчеты содержимого пакета (payload), а также отключить группы правил и собственно определенные группы пакетов. Немного экспериментов с настройками — и приходим к варианту, который представляю на следующем рисунке.



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



Результат тестирования:



Как видим, с этой группой правил картина существенно улучшилась (процент отброшенных пакетов уменьшился в несколько раз). Атака типа «Выявление торрент-трекера» была успешно обнаружена (атаки «Фрагментированный пакет» больше не появлялись).

Группа № 2

Настройки — те же. Список активных правил:



Результат в таблице:


Тут картина по обработке пакетов еще лучше, что ожидаемо.

Резюме

Финальная таблица результатов, выраженная в процентах kernel_drops относительно kernel_packets, показана ниже:



Графически результат выглядит следующим образом:



Как видим, количество активных правил и настройки напрямую влияют на эффективность. Включать настройки по максимуму и все правила одновременно не имеет никакого смысла — потери сразу зашкаливают даже на 10 Мб/с. В оптимизированных режимах “железка” нормально себя чувствует вплоть до 100 Мб/с, но на более интенсивном трафике потери резко возрастают. Впрочем, для “офисного” использования 100 Мб/с вполне достаточно. Если гонять девайс на этой скорости и подбирать правила, можно добиться вполне удовлетворительной работы IDS.

Возможно, для использования полного набора правил нужны доработки по использованию механизма pf_ring (https://www.ntop.org/products/packet-capture/pf_ring/) в качестве механизма передачи пакета в userspace из буфера сетевой карты. Для этого придется задействовать несколько экземпляров Suricata, что, естественно, отберет ресурсы от других процессов, но, возможно, игра будет стоить свеч.

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

P.S. Как уже говорил выше, призываю читателей написать о своем опыте использования IDS в относительно недорогих решениях.

P.P.S. Тест выложен в аккаунте производителя, так как не хочу себя “светить”. Тем не менее, я готов ответить на все вопросы и подискутировать в комментариях, но, опять-таки, не от своего имени:)