Почему так сложно определить производительность NGFW?

Алексей Прокопчук, руководитель группы разработки NGFW Traffic Inspector Next Generation

 

Один из самых распространенных вопросов, связанных с покупкой, внедрением и эксплуатацией Traffic Inspector Next Generation (TING), – о производительности межсетевого экрана. Это, пожалуй, один из немногих вопросов, точного ответа на который не существует, и вот почему.

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

Почему указать точные значения и гарантировать их достижение невозможно? Дело не в конкретном продукте, а в том, что производительность любого файрвола от любого вендора определяется множеством внешних условий, в том числе и человеческим фактором.

 

Когда можно и когда нельзя определить производительность

Для наглядности приведу очень простой пример про коммутатор, не важно какой, управляемый или неуправляемый. В характеристиках любого свитча указано, что он может обрабатывать за секунду определенное число пакетов, – условно, 16 млн. До тех пор, пока он получает количество пакетов, не превышающее это значение, устройство работает без задержек. Как только прилетит больше – начнется "пробуксовка". В этом случае посчитать производительность коммутатора очень просто: она равна значению, которое указано в характеристиках, потому что никаких других факторов, кроме физических, относящихся ко внешней среде, то есть количества пришедших пакетов, которые могут повлиять на процесс передачи данных, не существует.
Зная объемы трафика, можно легко предсказать работоспособность коммутатора.

Для другого сетевого устройства, маршрутизатора, такой прогноз сделать уже невозможно, потому что в этом случае количество вводных уже гораздо больше. Неважно, какую именно маршрутизатор использует операционную систему (Linux, FreeBSD или любую другую). Для того, чтобы определить производительность
в моменте, нужно учитывать то, чем в этот момент занята система. Она может обрабатывать внутренние логи или сложные правила, которые системный администратор прописал в межсетевом экране.

 

Все дело в условиях работы

От сложности правил для файрвола во многом зависит его текущая производительность. Любой пакет, который в
него приходит, должен пройти обработку правилами (теми самыми "да-нет"). Если представить себе этот набор правил в виде таблицы, то станет понятна сложность алгоритма. Если пакет удовлетворяет самому первому требованию, то он сразу же "выйдет" из таблицы и будет отправлен дальше. Если нет, то велика вероятность, что
он будет проверяться на соответствие правилам, которые в таблице указаны дальше. Таких правил может быть несколько десятков, сотен, а иногда даже тысяч – все зависит от фантазии системного администратора. Значительное количество пакетов, которые задерживаются в большом наборе правил, вызовет снижение производительности.

Иными словами, на производительность оказывают непосредственное влияние многие факторы. Например, может вмешаться ошибка администратора, который составил неоптимальные правила работы файрвола. Могут повлиять и специфические условия, например то, чем занимается пользователь, который находится в локальной сети. В периметре может находиться машина, зараженная вирусом и отправляющая множество мелких пакетов кому попало. Антивирус тоже негативно влияет на производительность маршрутизатора, поэтому высчитать твердое значение, которое характеризует производительность, невозможно.

 

Почему замеры скорости некорректны

Часто быстродействие файрвола определяют при помощи замера скорости скачивания данных из сети. Но такой способ некорректен по отношению к файрволу. В этом случае на самом деле измеряется не скорость скачивания, а скорость обмена данными, то есть сочетание скорости самой сети и скорости подключения к внешнему серверу. Это идеальные условия (сетевая карта со скоростью 100 Мбит/с обеспечит в таких условиях те самые 100 Мбит/с). Но в сети постоянно ведется обмен пакетами, и чем больше в сети пользователей, серверов,
сервисов, тем большее количество пакетов они друг другу пересылают. Все они забирают себе часть производительности и определенную скорость.

Поэтому реальную скорость скачивания в такой инфраструктуре обычный замер показать не сможет. И даже специальный софт, который включается для замера при высокой нагрузке, нагрузит сеть еще больше, и она неминуемо начнет тормозить.

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

Среди наших заказчиков есть вуз, в инфраструктуре которого больше тысячи пользователей. В стандартном режиме сеть этой организации никаких проблем не испытывает. Но в прошлом году этот университет (как и многие другие в России) пережил DDoS-атаку, которая привела к тому, что система обнаружения вторжений мгновенно забрала вместо обычных 5-6% ресурсов все 100%. Если бы был сделан замер производительности сети, то он показал бы минимальные значения, даже на топовом, высокопроизводительном оборудовании.

 

AD и производительность

Те же самые факторы оказывают свое влияние и на производительность TING. Она зависит от текущих настроек
файрвола, а те, в свою очередь, от политик безопасности, которые действуют в компании.

Некоторые предприятия всегда по умолчанию проксируют доступ сотрудников в Интернет, при этом авторизацию на прокси-сервере организуют через контроллер домена. Когда пользователей много, и все они обращаются ко внешним ресурсам через один и тот же прокси, при каждом таком обращении идет обмен данными с контроллером домена Active Directiry (AD). Мы сталкивались со случаями, когда только трафик AD, все назначение которого – авторизация, исчисляется сотнями Мбит/c. В такой ситуации мало того, что
канал забивается дополнительным трафиком, еще и генерируется значительная нагрузка на прокси-сервер. В результате производительность упиралась в потолочные значения.

И в Linux, и в FreeBSD существует такая характеристика как Load Average – совокупность загрузки устройств системы: от процессора до устройств ввода-вывода. Когда значение Load Average равно единице, это означает, что достигнут пик производительности для одного процессора. Если это значение превышает единицу, то нагрузка превышает пиковое значение. Для машин с восемью процессорами такое предельное значение Load Average будет равно 8 и т.д.

Мы сталкивались со случаями, когда у некоторых заказчиков при авторизации пользователей на прокси через контроллер домена значение Load Average на восьмипроцессорных машинах достигало 50.

 

Как влияет на производительность IDS/IPS

Не лучшим образом сказывается на производительности файрвола использование средств предотвращения вторжения IDS/IPS. В них существуют свои наборы правил. Они описывают критерии, по которым анализируется входящий трафик и определяется, похож он на атаку или нет. Таких правил может быть единовременно задействовано очень много, и производительность файрвола, естественно, тратится на их обработку.

На производительность файрвола влияет и объем трафика, который на него поступает. Например, в организации, у которой нет ни собственного сайта, ни внешних сервисов, которые она обслуживает, используются TING и IDS/IPS – в этом случае система обнаружения вторжений будет потреблять минимум
ресурсов, и то только в момент атаки, если она случится. Но другая организация с собственным сайтом и личными кабинетами пользователей при такой же схеме организации защиты (файрвол + IDS/IPS) обязательно
столкнется с высокой нагрузкой.

Эта нагрузка станет еще выше, если будет зафиксирована атака, слабое оборудование может ее не выдержать. Кроме того, необходимо учитывать еще и интенсивность атаки. DDoS может "положить" практически любое устройство, даже самое производительное, отразить такое нападение можно только на уровне провайдера.

Поэтому IDS/IPS в компании, где обслуживается большое количество внешних сервисов, всегда будет потреблять большое количество ресурсов и даже может забрать все мощности, если их недостаточно.

Вариантов решения проблемы перегрузки много. Самые очевидные из них: увеличить мощность системы, быстродействие дисковой подсистемы и нарастить пропускную способность локальной сети. Эти способы
действенны, но сопряжены с дополнительными расходами на апгрейд оборудования.

Есть и другие способы привести нагрузку на систему в соответствие с расчетной производительность – например, оптимизация контроллера домена. В ряде случаев такая мера позволяла при той же  пользовательской активности сократить нагрузку на межсетевой экран вдвое.

 

FreeBSD как способ борьбы с нагрузками

В качестве среды исполнения в TING используется FreeBSD – и не потому, что все мы страстные поклонники этой операционной системы или очень любим командную строку. Конечно, можно было использовать и один из дистрибутивов Linux, но дело в том, что FreeBSD отлично ведет себя именно в условиях высокой нагрузки, которая критична для производительности сети. Эта ОС загружает меньше процессов, оставляя место для данных, например, в операциях ввода-вывода, а если и блокирует что-то, то не всю систему разом, а какое-то отдельное действие.

Иными словами, сетевой стек FreeBSD обеспечивает более высокую производительность в условиях высокой нагрузки, отличается большей стабильностью. Сама ОС менее требовательна к ресурсам, а значит и расходует их экономнее, оставляя место для других задач.

Вопрос о производительности кажется простым, но на самом деле ответ на него зависит от огромного количества условий. Предусмотреть все особенности использования TING в конкретной инфраструктуре невозможно, поэтому конкретного ответа нет и быть не может.

 

Источник

Протестируйте бесплатно