В закупке эти три слова до сих пор считают синонимами. Пишут «межсетевой экран нового поколения (UTM)» в одной строке технического задания и получают предложения, которые несопоставимы между собой ни по цене, ни по тому, что будет происходить с трафиком под нагрузкой.
Списки функций у всех одинаковые: межсетевой экран, VPN, IPS, антивирус, веб-фильтр, разбор приложений, расшифрование TLS. Различает продукты не список, а то, как эти функции уживаются в одной коробке под нагрузкой.
Сразу оговорка, без которой дальше будет неправильно понято. Названия классов ничего не гарантируют. Нет правила, по которому всё, названное UTM, обрабатывает пакет последовательно, а всё, названное NGFW, — одновременно. Одна и та же платформа сегодня умеет оба режима: у FortiOS, например, flow и proxy описаны как разные режимы инспекции одного устройства. Поэтому ниже — про две архитектурные развилки, с которых начинался NGFW, и про то, как проверить, на какой стороне стоит конкретный продукт в конкретном режиме. Не про то, как он называется.
Откуда взялись оба названия
UTM (Unified Threat Management) — это «всё в одном». Идея простая: поставить на один сервер несколько движков защиты, дать им общее управление и продавать одной коробкой. Администратор получает единую консоль вместо пяти разных устройств, бухгалтерия — одну строку в счёте.
Движки при этом обычно не свои. Их покупают, лицензируют у профильных вендоров или берут открытые: IPS на базе Snort или Suricata, антивирус на базе ClamAV, пакетный фильтр на базе netfilter, маршрутизация на базе готового демона. Собрать такое устройство дешевле и быстрее, чем разработать каждый движок самому, — поэтому UTM и появились первыми.
Две развилки, с которых начинался NGFW
Первая — очередь. В последовательной схеме проверки обрабатывают пакет одна за другой: каждая ждёт, пока закончит предыдущая. Следствие арифметическое: чем больше функций включено, тем больше суммарная задержка. Дальше начинается история, которую я видел много раз: чтобы сеть работала, администратор выключает антивирус, потом часть сигнатур IPS, потом IPS целиком. Устройство куплено как средство защиты, а используется как маршрутизатор.
Ответ, с которого начинался NGFW: разбирать поток один раз и отдавать результат всем проверкам сразу, а не прогонять его через них по очереди. Это не значит, что у каждой проверки свой отдельный процессор и что конкуренции за ресурсы нет — она есть всегда, вопрос в том, складываются ли задержки. Что спрашивать у поставщика: как устроен путь пакета, где происходит разбор и что именно добавляет включение очередной проверки.
Вторая — сколько нужно накопить до проверки. Часть проверок работает на лету, по мере поступления данных; часть требует собрать объект целиком — так устроены некоторые форматы и глубокие проверки. Чем больше приходится буферизовать, тем больше памяти и задержки, и тем раньше устройство упирается в предел.
Предел этот не обязательно дисковый: у продуктов есть документированные режимы поведения при нехватке ресурсов, когда проверки отключаются или новые сессии перестают приниматься. У FortiOS это conserve mode с настройками av-failopen и fail-open для IPS. Важно не название, а сам факт: такой режим есть, он срабатывает под нагрузкой, и что именно он делает — пропускает без проверки или отбрасывает — надо знать до покупки, а не выяснять в аварии.
Вопрос к поставщику формулируется так: какой объём буферизуется, что происходит при превышении лимита, задействуется ли диск и при каких условиях. У продуктов это описано в настройках протоколов — например, у FortiOS в Protocol options прямо указаны ограничения памяти при буферизации. Ответ «у нас всё в памяти» сам по себе ничего не значит: память тоже кончается.
Схема: очередь против параллельной обработки
Третья развилка: порт или приложение
Обычный межсетевой экран работает на четвёртом уровне модели OSI: он видит адреса и порты. Двадцать лет этого хватало. Сегодня по 443-му порту ходит почти всё, и правило «разрешить 443» не означает ничего.
NGFW разбирает трафик до седьмого уровня и оперирует приложением, а не портом: видно, что за приложение установило соединение и какой файл передало. Это вскрывает туннелирование внутри разрешённых протоколов и даёт блокировать конкретное приложение вместо порта, за которым прячутся сотни приложений сразу.
Здесь важно не повторить распространённую ошибку. Указание в правиле и приложения, и порта — само по себе нормально и не означает двух конкурирующих политик: в PAN-OS, например, есть application-default, где приложение и служба работают как условия одного правила.
Проверять надо другое: единый ли порядок принятия решения и можно ли по журналу объяснить, какое правило сработало и почему. Если после каждого инцидента приходится гадать, какая из проверок дала окончательный ответ, эксплуатировать такую политику тяжело независимо от того, как продукт называется.
Что из этого проверяется на пилоте
Архитектуру нельзя прочитать в спецификации, зато её можно измерить. Четыре проверки, которые разводят UTM и NGFW за полдня:
- Включить все проверки разом и снять производительность на смешанном трафике, а не на однородном UDP из спецификации. Заметное падение — повод для диагностики, а не готовый вывод: упереться можно в процессор, память, криптографию и даже в генератор трафика. По одной разнице в пропускной способности порядок обработки не устанавливается.
- Прогнать большой файл и архив через SMB и HTTPS, посмотреть на загрузку устройства и на то, не сработал ли автоматический обход проверок. Спросить прямо: есть ли режим поведения при нехватке ресурсов, что он делает и как настраивается — с точными именами параметров вашей версии.
- Написать правило по приложению и проверить по журналу, что решение принято и объяснимо. Смотреть надо не на наличие поля порта, а на то, понятно ли постфактум, какое правило сработало.
- Включить расшифрование TLS и повторить первые два пункта. Это самая дорогая функция, и её честнее всего мерить последней.
Что писать в техническом задании
Не «межсетевой экран нового поколения (UTM)». Не потому, что это разные классы с гарантированно разной механикой, а потому, что название класса вообще ничего не обещает: получите несравнимые предложения.
Формулируйте требование поведением под нагрузкой: производительность при одновременно включённых IPS, антивирусе, веб-фильтре и расшифровании TLS на вашем профиле трафика; приложение как объект правила; объяснимость срабатывания по журналу; описанное поведение при нехватке ресурсов.
Полный набор критериев с вопросами поставщику — на странице как выбрать NGFW. Как это проверить на испытаниях — в программе пилота.
Этот материал переписан из моей статьи 2017 года в блоге «Реальная безопасность». Вопросы к обработке трафика с тех пор те же, а вот ответы на них теперь зависят от конкретной реализации и режима — и проверять их надо по документации вашей версии, а не по названию класса.