Типовые сценарии внедрения NGFW

Disclaimer

В данной статье приводятся лишь примеры типовых сценариев внедрения NGFW. Не стоит брать предложенные схемы за готовый шаблон. В реальной жизни, почти каждое внедрение уникально. Есть много подводных камней, на которые нужно обратить внимание перед планированием топологии сети. Но в целом, все варианты будут “крутиться” вокруг нескольких концептов. Их мы и постараемся обсудить.

Типовая архитектура сети с точки зрения ИБ

Прежде чем описывать варианты внедрения NGFW, мне бы хотелось обсудить несколько типичных сценариев использования средств сетевой защиты. Мы рассмотрим наиболее распространенные средства, которые есть практически в каждой компании (конечно же максимально упрощенно и поверхностно, иначе получится целая книга). Чаще всего на практике можно встретить три самых распространенных варианта:

1) Продвинутый

Довольно типичная схема. На периметре сети используется какой-либо Stateful Firewall, который имеет минимум три сегмента: Internet, DMZ, локальная сеть. На этом же МЭ может организовываться Site-to-Site VPN и RA VPN. В DMZ как правило находятся публичные сервисы. Там же чаще всего находится какое-либо Anti-Spam решение с функционалом антивируса.
За маршрутизацию локального трафика отвечает коммутатор ядра (L3), на котором также минимум два сегмента: сегмент пользователей и сегмент серверов. В сегменте серверов располагают Proxy-сервер с функционалом антивируса и сервер корпоративной почты. Довольно часто сегмент серверов защищается дополнительным МЭ (виртуальный или “железный”).
В качестве дополнительной меры защиты может применяться IPS, который мониторит копию трафика (подключен к SPAN-порту). На практике мало кто “отваживается” ставить IPS в inline режим.
Уверен, что многие угадали в этой схеме свою сеть.

2) Упрощенный

Данный вариант также встречается довольно часто. Почти весь секьюрити функционал развернут в рамках единого UTM-решения (Firewall, Proxy, AV, Anti-Spam, IPS). Для маршрутизации локального трафика используется коммутатор ядра (Core SW L3). На нем же выделен сегмент серверов с почтовым сервером и другими сервисами компании.

3) SMB

Самый простой вариант. Отличается от предыдущего отсутствием коммутатора ядра. Т.е. трафик между локальными сегментами и в Интернет маршрутизируется через одно UTM-устройство. Данный вариант часто встречается в небольших компаниях, где небольшой трафик.

Как я уже писал выше, это очень поверхностное описание трех типовых сценариев использования наиболее распространенных средств сетевой защиты.

NGFW

Next Generation Firewall — межсетевой экран следующего поколения. Мы уже не раз обсуждали что это такое, чем он отличается от UTM, какие лидеры на рынке и на что нужно обратить внимание при выборе. Изначально, главное, ради чего внедрялись NGFW — контроль приложений и deep packet inspection (собственно без последнего невозможно первое). Под приложениями понимаются не только классические “толстые” приложения, но и микро-приложения веб-формата. Пример — posting, video, chatting в социальных сетях.
Однако практически все современные NGFW имеют в своем составе гораздо больше функций:

• Application Control
• URL filtering
• VPN
• IPS
• Anti-Virus
• Anti-Spam

Некоторые решения обладают дополнительным функционалом:

• DLP
• Sandboxing
• Log analyzer and correlation unit

Из-за такого большого наличия функций и возникают вопросы при внедрении. Если бы вы покупали proxy-сервер (ironport например), то сценариев применения было бы гораздо меньше. Тоже самое касается узконаправленных anti-spam решений. Но что делать с такими “комбайнами” как современные NGFW? Куда ставить и как использовать? Давайте рассмотрим несколько типовых сценариев и обсудим как лучше внедрять. Все последующие умозаключения весьма субъективны и основаны лишь на личном опыте и в соответствии неким “best practice”.

1) NGFW как устройство периметра

Самый простой и самый правильный вариант внедрения. NGFW для этого и задумывался — стоять на границе сети.

Какие преимущества:

• Отпадает необходимость использования выделенного proxy. Большинство NGFW умеют функционировать в режиме proxy, однако весь необходимый функционал работает и в режиме “маршрута по умолчанию” для всех локальных сетей. Настроили default gateway и забыли. Никаких явных прокси в браузерах пользователей.
• По умолчанию присутствует IPS и сразу в inline режиме. Можно выставить Detect если боитесь проблем. Не нужно думать о том, как завернуть трафик через выделенное IPS устройство и как быстро вернуть трафик назад в случае проблем.
• Антивирус для веб-трафика, в том числе для HTTPS-трафика (при включенной SSL-инспекции).
• Антивирус для почтового трафика. Проверка ссылок и вложений.
• Анти-спам функционал.
• Возможность быстрого внедрения функционала “песочницы” (sandbox). Практически все современные NGFW имеют возможность активации песочницы (облачной или локальной).
• Встроенная отчетность по всем ИБ инцидентам.

Как видите, схема сильно упрощается. Убирается несколько традиционных средств сетевой защиты. С одной стороны это плюс (упрощается администрирование) с другой стороны минус (единая точка отказа). Не будем сейчас дискутировать о том, что лучше. Мы просто обсуждаем концепт.

На что обратить внимание выбирая NGFW, который будет стоять на периметре сети:

• Наибольшее внимание здесь нужно уделить функционалу проверки почты (конечно если вы собираетесь убирать текущее anti-spam решение). Для полноценной работы с почтой, NGFW должен иметь MTA (mail transfer agent) на борту. Фактически в этом режиме NGFW заменяет SMTP-relay, что позволяет выполнять глубокую проверку почтового трафика. В том числе проверку вложений в “песочнице”. Если MTA нет, то необходимо как минимум оставить SMTP-relay.
• Даже если MTA присутствует в NGFW, внимательно ознакомьтесь с возможностями фильтрации почты. Один из важнейших критериев — наличие карантина (либо способы его организовать).
• Естественно должна поддерживаться HTTPS-инспекция. Без этой функции от NGFW остается одно название.
• Кол-во приложений, которые NGFW может различать. Обязательно проверьте, определяет ли выбранное вами решение нужные вам приложения (в том числе веб-приложения).

Возможные ограничения или проблемы

Часто в качестве пограничного устройства используется маршрутизатор а не МЭ. При этом в текущей схеме может применяться функционал, который отсутствует в чистом виде на NGFW (различные WAN-технологии, протоколы маршрутизации и т.д.). Это нужно учитывать и тщательно планировать перед внедрением. Возможно будет логично оставить роутер и использовать его параллельно (к примеру для организации WAN-сети). Пример:

Резюме

Как я уже написал выше, вариант “NGFW на периметре сети” — идеальный вариант при котором вы получите максимум его возможностей. Но не забывайте, что NGFW это не роутер. Привычные функции (bgp, gre, ip sla и т.д.) могут отсутствовать или присутствовать в весьма урезанном функционале.

2) NGFW как proxy-сервер

Как ни странно, но это тоже довольно распространенный вариант. Хоть NGFW и не разрабатывался как proxy. Типовая схема:

Преимущества такого варианта:

• Скорость внедрения. Заменили старый Proxy и готово.
• Не нужно менять текущую схему или маршрутизацию.

На этом пожалуй плюсы заканчиваются. Хотя озвученные преимущества очень часто становятся решающими для многих компаний.

На что обратить внимание выбирая NGFW, который будет стоять как proxy:

• Самый главный здесь пункт — способ аутентификации пользователей (NTLM, Kerberos, Captive Portal и т.д.). Обязательно проверьте, что выбранное вами решение поддерживает текущий метод авторизации или способно его заменить на что-то адекватное.
• Проверьте, что вас устраивает встроенная отчетность NGFW по пользователям (потребляемый трафик, посещаемые ресурсы и т.д.).
• Возможности по ограничению трафика — QoS, ограничения по скорости (shaping) и объемам скачиваемого трафика (limiting).

Возможные ограничения или проблемы:

• Первое, что нужно помнить, NGFW в режиме прокси — почти всегда урезанный функционал. Вы не сможете задействовать его на 100 процентов. Особенно если речь заходит о проверке почтового трафика.
• Ниже пропускная способность. Почти все NGFW решения в режиме прокси демонстрируют меньшую скорость на пользователя.
• Вы по прежнему будете вынуждены использовать IPS. Т.к. часть вашего трафика может идти в Интернет мимо прокси.

Резюме

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

3) NGFW как ядро

Распространенный вариант для небольших сетей. Маршрутизация всего трафика (Интернет, локальный, серверный) “вешается” на NGFW. L3 коммутатор отсутствует, либо просто не используется для маршрутизации.

Преимущества такого варианта:

• Удобство администрирования. Все access-list-ы в одном месте.
• Скорость развертывания. Как правило NGFW ставится таким образом в топологиях где и до этого МЭ выполнял роль ядра сети.
• Все плюсы варианта “NGFW на периметре сети”.

На что обратить внимание при выборе NGFW в режиме “ядра”

Практически все тоже самое, что и для “NGFW на периметре сети”. Но в данном случае стоит уделить особое внимание наличию функции MTA. В такой небольшой сети желательно обойтись без дополнительного устройства в виде SMTP-relay. Лучше если этот функционал будет присутствовать в вашем NGFW.

Возможные ограничения или проблемы:

• Пожалуй главная проблема — единая точка отказа. При подборе устройства не забудьте учесть ваш локальный трафик, чтобы выбранная модель NGFW справилась с нагрузкой.
• Сеть менее гибкая с точки зрения изменений. Меньше маршрутизирующих устройств — меньше возможностей по управлению трафиком.

Резюме

Возможно это идеальный вариант для небольших компаний. Конечно если для вас допустим риск единой точки отказа.

4) NGFW в режиме bridge

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

Оставлять сторонний IPS в таком случае нет смысла (тем более на мониторинг трафика). NGFW вполне справится с его функцией. Такой вариант применяется чаще всего в более продвинутых инфраструктурах, где изменения топологии по какой-то причине невозможны либо крайне нежелательны.

Преимущества такого варианта:

• Скорость внедрения. Менять логику сети не нужно, максимум переткнуть кабель или “завернуть” VLAN.
• Меньше хопов — проще логика сети.

На этом пожалуй все.

На что обратить внимание при выборе NGFW в режиме “bridge”:

• На ограничения режима “bridge”! Внимательно ознакомьтесь с ними.
• Желательно наличие bypass модулей, чтобы трафик шел через устройство, даже если оно выключено.

Возможные ограничения или проблемы

А вот здесь очень много подводных камней. Я не встречал еще ни одного NGFW решения, которое бы адекватно работало в режиме моста. Возможно мне не везло. Но я делюсь в этой статье исключительно своим опытом. Помимо официальных (документированных) ограничений в функционале, абсолютно всегда всплывают “неофициальные” в виде багов и кучи проблем. Конечно все зависит от функций которые вы используете в режиме моста. Если вы настроите только Firewall, то и проблем практически не будет. Однако если вы включите такие вещи как IPS, Application Control, HTTPS-инспекцию или даже Sandboxing, то будьте готовы к сюрпризам.

Резюме

Как и в случае с прокси, желательно избегать режима bridge. Если это невозможно, то очень желательно протестировать этот режим на вашей инфраструктуре. Затем уже принимать решение.

Отказоустойчивость

Я не мог не затронуть этот пункт. Практически все NGFW решения поддерживают два режима кластеризации:

1. High Availability. Одна нода кластера активная и маршрутизирует трафик, вторая нода пассивная и находится в горячем резерве, готовая стать активной в случае проблем с первой.
2. Load Sharing. Обе ноды активны и трафик “делится” между ними.

Очень многие при планировании и внедрении NGFW слишком сильно полагаются на Load Sharing режим.

— Если трафик делится между устройствами, то нагрузка на них будет в два раза меньше, а значит и устройства можно заложить послабее и дешевле?
— Нет!

Как показывают многочисленные тесты, добиться адекватной балансировки трафика — невозможно. И максимум что вам даст Load Sharing — снижение нагрузки на устройства процентов на 15, не больше. При этом у этого режима практически всегда есть какие-нибудь ограничения, которых нет в High Availability. Обязательно ознакомьтесь с ними. А выбирая устройство всегда рассчитывайте, что одна “железка” должна справиться со всем трафиком.

Резюме

Используйте High Availability режим.

Виртуальный NGFW или “железка”

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

1. NGFW на периметре сети. Здесь безусловно лучший вариант — appliance. Это логично, т.к. периметр сети должен иметь физическое разграничение. Если все же хочется виртуальное решение, то ОЧЕНЬ желательно, чтобы NGFW разворачивался на выделенном сервере, который имеет физическое разграничение с локальной сетью. По сути вы получаете тот же appliance, просто вместо “железа” вендора вы используете свой сервер с гипервизором. Также нужно максимально внимательно подойти к настройкам самого гипервизора, чтобы к нему не получили доступ из внешней сети.
2. NGFW как proxy. Здесь нет особой разницы что выбирать. На мой взгляд виртуальное решение будет более предпочтительным и удобным вариантом.
3. NGFW как ядро сети. Основные требования как и в первом пункте. Т.к. NGFW напрямую подключается к Интернету, то решение должно быть физически отделено от серверов компании — appliance или виртуальная машина на выделенном сервере. Т.к. NGFW в данном случае выполняет еще и роль ядра, то нужно понимать, сколько физических портов вам нужно и каких портов (1g, 10g, оптика). Это также сильно влияет на выбор.
4. NGFW в режиме bridge. Для такого варианта строго рекомендуется аппаратное устройство, т.к. желательно наличие bypass модулей (трафик будет проходить даже при выключенном устройстве).

Давайте в общих чертах рассмотрим плюсы и минусы виртуального решения.

Плюсы виртуального решения:

• Главные достоинства виртуального решения — удобство управления (backup, snapshot) и скорость развертывания.
• Также очень часто это оказывается дешевле и лучше масштабируется. Как правило лицензирование идет по количеству используемых ядер. При необходимости можно просто докупить несколько ядер.

Минусы виртуального решения:

• Нет гарантии на аппаратную часть. Если сломается сервер, разбираться с этим придется самим.
• Если вы безопасник, то вам придется взаимодействовать с IT отделом. Как ни странно, во многих компаниях это очень большая проблема.

Для appliance все наоборот. К тому же «из коробки» доступно большее количество физических портов.

Заключение

Надеюсь данная статья не получилась слишком нудной и поверхностной. Мне хотелось выделить основные моменты и не растягивать “лекцию” на несколько часов чтения. Буду рад, если эта статья действительно кому-то пригодится. Если у вас остались вопросы или замечания, то готов обсудить их в комментариях или личных сообщениях.

Автор: cooper051

Источник