- PVSM.RU - https://www.pvsm.ru -
В данной статье приводятся лишь примеры типовых сценариев внедрения NGFW. Не стоит брать предложенные схемы за готовый шаблон. В реальной жизни, почти каждое внедрение уникально. Есть много подводных камней, на которые нужно обратить внимание перед планированием топологии сети. Но в целом, все варианты будут “крутиться” вокруг нескольких концептов. Их мы и постараемся обсудить.
Прежде чем описывать варианты внедрения NGFW, мне бы хотелось обсудить несколько типичных сценариев использования средств сетевой защиты. Мы рассмотрим наиболее распространенные средства, которые есть практически в каждой компании (конечно же максимально упрощенно и поверхностно, иначе получится целая книга). Чаще всего на практике можно встретить три самых распространенных варианта:
Довольно типичная схема. На периметре сети используется какой-либо Stateful Firewall, который имеет минимум три сегмента: Internet, DMZ, локальная сеть. На этом же МЭ может организовываться Site-to-Site VPN и RA VPN. В DMZ как правило находятся публичные сервисы. Там же чаще всего находится какое-либо Anti-Spam решение с функционалом антивируса.
За маршрутизацию локального трафика отвечает коммутатор ядра (L3), на котором также минимум два сегмента: сегмент пользователей и сегмент серверов. В сегменте серверов располагают Proxy-сервер с функционалом антивируса и сервер корпоративной почты. Довольно часто сегмент серверов защищается дополнительным МЭ (виртуальный или “железный”).
В качестве дополнительной меры защиты может применяться IPS, который мониторит копию трафика (подключен к SPAN-порту). На практике мало кто “отваживается” ставить IPS в inline режим.
Уверен, что многие угадали в этой схеме свою сеть.
Данный вариант также встречается довольно часто. Почти весь секьюрити функционал развернут в рамках единого UTM-решения (Firewall, Proxy, AV, Anti-Spam, IPS). Для маршрутизации локального трафика используется коммутатор ядра (Core SW L3). На нем же выделен сегмент серверов с почтовым сервером и другими сервисами компании.
Самый простой вариант. Отличается от предыдущего отсутствием коммутатора ядра. Т.е. трафик между локальными сегментами и в Интернет маршрутизируется через одно UTM-устройство. Данный вариант часто встречается в небольших компаниях, где небольшой трафик.
Как я уже писал выше, это очень поверхностное описание трех типовых сценариев использования наиболее распространенных средств сетевой защиты.
Next Generation Firewall — межсетевой экран следующего поколения. Мы уже не раз обсуждали что это такое, чем он отличается от UTM [1], какие лидеры на рынке [2] и на что нужно обратить внимание при выборе. Изначально, главное, ради чего внедрялись NGFW — контроль приложений и deep packet inspection (собственно без последнего невозможно первое). Под приложениями понимаются не только классические “толстые” приложения, но и микро-приложения веб-формата. Пример — posting, video, chatting в социальных сетях.
Однако практически все современные NGFW имеют в своем составе гораздо больше функций:
Некоторые решения обладают дополнительным функционалом:
Из-за такого большого наличия функций и возникают вопросы при внедрении. Если бы вы покупали proxy-сервер (ironport например), то сценариев применения было бы гораздо меньше. Тоже самое касается узконаправленных anti-spam решений. Но что делать с такими “комбайнами” как современные NGFW? Куда ставить и как использовать? Давайте рассмотрим несколько типовых сценариев и обсудим как лучше внедрять. Все последующие умозаключения весьма субъективны и основаны лишь на личном опыте и в соответствии неким “best practice”.
Самый простой и самый правильный вариант внедрения. NGFW для этого и задумывался — стоять на границе сети.
Какие преимущества:
Как видите, схема сильно упрощается. Убирается несколько традиционных средств сетевой защиты. С одной стороны это плюс (упрощается администрирование) с другой стороны минус (единая точка отказа). Не будем сейчас дискутировать о том, что лучше. Мы просто обсуждаем концепт.
На что обратить внимание выбирая NGFW, который будет стоять на периметре сети:
Возможные ограничения или проблемы
Часто в качестве пограничного устройства используется маршрутизатор а не МЭ. При этом в текущей схеме может применяться функционал, который отсутствует в чистом виде на NGFW (различные WAN-технологии, протоколы маршрутизации и т.д.). Это нужно учитывать и тщательно планировать перед внедрением. Возможно будет логично оставить роутер и использовать его параллельно (к примеру для организации WAN-сети). Пример:
Резюме
Как я уже написал выше, вариант “NGFW на периметре сети” — идеальный вариант при котором вы получите максимум его возможностей. Но не забывайте, что NGFW это не роутер. Привычные функции (bgp, gre, ip sla и т.д.) могут отсутствовать или присутствовать в весьма урезанном функционале.
Как ни странно, но это тоже довольно распространенный вариант. Хоть NGFW и не разрабатывался как proxy. Типовая схема:
Преимущества такого варианта:
На этом пожалуй плюсы заканчиваются. Хотя озвученные преимущества очень часто становятся решающими для многих компаний.
На что обратить внимание выбирая NGFW, который будет стоять как proxy:
Возможные ограничения или проблемы:
Резюме
Личный совет — если есть возможность избежать “NGFW как proxy”, то избегайте. На практике начинают вдруг “вылазить” недокументированные особенности. И самый большой минус — невозможность полноценной проверки почты (технически конечно это можно сделать, но это будет “костыль”).
Распространенный вариант для небольших сетей. Маршрутизация всего трафика (Интернет, локальный, серверный) “вешается” на NGFW. L3 коммутатор отсутствует, либо просто не используется для маршрутизации.
Преимущества такого варианта:
На что обратить внимание при выборе NGFW в режиме “ядра”
Практически все тоже самое, что и для “NGFW на периметре сети”. Но в данном случае стоит уделить особое внимание наличию функции MTA. В такой небольшой сети желательно обойтись без дополнительного устройства в виде SMTP-relay. Лучше если этот функционал будет присутствовать в вашем NGFW.
Возможные ограничения или проблемы:
Резюме
Возможно это идеальный вариант для небольших компаний. Конечно если для вас допустим риск единой точки отказа.
Менее популярный вариант, но все же встречается чаще чем хотелось бы. В этом случае текущая логика сети никак не меняется, трафик на втором уровне проходит через NGFW, который работает в режиме моста:
Оставлять сторонний IPS в таком случае нет смысла (тем более на мониторинг трафика). NGFW вполне справится с его функцией. Такой вариант применяется чаще всего в более продвинутых инфраструктурах, где изменения топологии по какой-то причине невозможны либо крайне нежелательны.
Преимущества такого варианта:
На этом пожалуй все.
На что обратить внимание при выборе NGFW в режиме “bridge”:
Возможные ограничения или проблемы
А вот здесь очень много подводных камней. Я не встречал еще ни одного NGFW решения, которое бы адекватно работало в режиме моста. Возможно мне не везло. Но я делюсь в этой статье исключительно своим опытом. Помимо официальных (документированных) ограничений в функционале, абсолютно всегда всплывают “неофициальные” в виде багов и кучи проблем. Конечно все зависит от функций которые вы используете в режиме моста. Если вы настроите только Firewall, то и проблем практически не будет. Однако если вы включите такие вещи как IPS, Application Control, HTTPS-инспекцию или даже Sandboxing, то будьте готовы к сюрпризам.
Резюме
Как и в случае с прокси, желательно избегать режима bridge. Если это невозможно, то очень желательно протестировать этот режим на вашей инфраструктуре. Затем уже принимать решение.
Я не мог не затронуть этот пункт. Практически все NGFW решения поддерживают два режима кластеризации:
Очень многие при планировании и внедрении NGFW слишком сильно полагаются на Load Sharing режим.
— Если трафик делится между устройствами, то нагрузка на них будет в два раза меньше, а значит и устройства можно заложить послабее и дешевле?
— Нет!
Как показывают многочисленные тесты, добиться адекватной балансировки трафика — невозможно. И максимум что вам даст Load Sharing — снижение нагрузки на устройства процентов на 15, не больше. При этом у этого режима практически всегда есть какие-нибудь ограничения, которых нет в High Availability. Обязательно ознакомьтесь с ними. А выбирая устройство всегда рассчитывайте, что одна “железка” должна справиться со всем трафиком.
Резюме
Используйте High Availability режим.
Еще один очень частый вопрос при планировании NGFW. Выбрать виртуальное решение или же appliance. Здесь нет однозначного ответа. Все зависит от вашей текущий инфраструктуры, бюджета и возможностей изменения логики сети. Но у нас все же есть общие рекомендации для разных вариантов внедрения:
Давайте в общих чертах рассмотрим плюсы и минусы виртуального решения.
Плюсы виртуального решения:
Минусы виртуального решения:
Для appliance все наоборот. К тому же «из коробки» доступно большее количество физических портов.
Надеюсь данная статья не получилась слишком нудной и поверхностной. Мне хотелось выделить основные моменты и не растягивать “лекцию” на несколько часов чтения. Буду рад, если эта статья действительно кому-то пригодится. Если у вас остались вопросы или замечания, то готов обсудить их в комментариях или личных сообщениях.
Автор: cooper051
Источник [3]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/informatsionnaya-bezopasnost/299785
Ссылки в тексте:
[1] что это такое, чем он отличается от UTM: https://habr.com/company/tssolution/blog/323606/
[2] какие лидеры на рынке: https://habr.com/company/tssolution/blog/333338/
[3] Источник: https://habr.com/post/430484/?utm_campaign=430484
Нажмите здесь для печати.