Лучшие практики проектирования архитектуры для обеспечения информационной безопасности при использовании межсетевых экранов (часть I)

Владислав Кузнецов

ведущий эксперт группы компаний Angara

Аннотация

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

Архитектурные подходы будут приведены в терминах и определениях оборудования Palo Alto Networks, но в целом будут применимы и при использовании межсетевых экранов других производителей. На момент написания статьи NGFW Palo Alto признаны одними из лучших в мире по данным отчетов Gartner Magic Quadrant for Network Firewalls от 17 сентября 2019 г. и NSS LABS Next Generation Firewall Comparative Report: Security от 17 июля 2019 г.

Будут рассмотрены различные варианты обеспечения информационной безопасности как в крупных, так и в небольших организациях с использованием межсетевых экранов:

- на границе сети Интернет;

- в ядре центра обработки данных, локальной сети и выделенного сегмента управления инфраструктуры ИТ;

- на границе зон ответственности и в качестве решения IDS;

- для обеспечения микросегментации в программно-определяемых сетях;

- как решение защиты облачных сред, в виде облачного сервиса и в качестве решения SD-WAN.

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

Все используемые схемы приведены с точки зрения сетевого уровня (L3), т.е. коммутация оборудования (L2 и L1) остается за рамками статьи. Каждая из рекомендуемых архитектур обеспечения информационной безопасности учитывает основные критерии качественного проектирования: масштабируемость (Scalability), удобство в управлении (Manageability) и доступность (Availability).

Классика не стареет

Для защиты сети корпоративной от угроз сети Интернет используют два подхода. Для крупных и средних организаций рекомендуемым является использование следующей схемы: два ISP – своя eBGP AS и PI подсеть адресов – пара граничных роутеров – кластер межсетевых экранов в режиме Active / Passive – сегменты корпоративной сети LAN, DMZ и другие.

Данный подход позволяет:

- разделить зону ответственности между каналообразующим оборудованием и оборудованием обеспечения безопасности;

- обеспечить маршрутизацию с сетью Интернет средствами высокопроизводительных маршрутизаторов, при необходимости поддерживающих Full view BGP;

- отфильтровать неиспользуемые порты и протоколы (SSH, Telnet, RDP, SNMP и т.д.) на самой крайней точке сети;

- применить лучшие практики в части ограничений в соответствии с RFC 3330, 6890, 2827, 5737 и 1918, что позволит заблокировать нелегитимный трафик до попадания на межсетевой экран.

Для небольших организаций более предпочтительным будет использование следующей схемы: два ISP – кластер межсетевых экранов в режиме Active / Passive – сегменты корпоративной сети LAN и DMZ.

Данный подход позволяет:

- распределить нагрузку на каналы связи между провайдерами, опубликовав разные сервисы на разных интерфейсах и используя функционал PBF либо ECMP;

- использовать разделение граничных интерфейсов на зоны безопасности в зависимости от типа трафика.

На самом межсетевом экране при любом из данных подходов должны быть задействованы все возможные средства обеспечения всесторонней безопасности:

- Threat Prevention – Antivirus, Vulnerability protection (anti-malware, IPS) и Anti-spyware (command-and-control, DNS security);

- Application-identification и User-identification;

- SSL/TLS decryption совместно с URL filtering, File blocking и Credential Phishing Prevention.

Также должна использоваться модель Zero Trust Security, и должно быть включено логирование. Хорошей практикой будет обновлять Antivirus раз в сутки, а остальные модули Threat Prevention – не реже двух раз в неделю. Рекомендуется по максимуму задействовать возможности Application-identification средств межсетевого экрана при написании правил безопасности, минимизируя этим использование в правилах TCP/UDP-портов и разрешив приложениям взаимодействовать только по их стандартным протоколам, а также User-identification, предоставляя доступ к определенным ресурсам только конкретным пользователям. User-identification поддерживает интеграцию с популярными пользовательскими репозиториями (Microsoft Exchange Server, Novell eDirectory, Microsoft AD) и серверами удаленного доступа (Citrix XenApp, Microsoft Terminal Services), а также XML API для интеграции со сторонними пользовательскими репозиториями (прокси, беспроводное оборудование и т.д.).

Следует максимально избегать использования «any» в правилах межсетевого экранирования. Поскольку на данный момент около 90% трафика Интернет зашифровано, только SSL/TLS decryption, вместе с URL filtering и File blocking, позволит ограничить доступ к нежелательным ресурсам сети Интернет, что существенно снизит вероятность проникновения в сеть организации вредоносного кода и, в дополнение к этому, разгрузит каналы связи. Важно включать возможность расшифровки не только TLS 1.2, но и HTTP/2 и TLS 1.3. Но при этом нужно учитывать, что сам функционал SSL/TLS decryption снижает пропускную способность в несколько раз, и для корректной работы таких программ, как клиент-банки, некоторых мобильных приложений со встроенным сертификатом сервера (SSL pinning) и им подобных, данный функционал необходимо выборочно отключать.

Для возможности расшифровки web-сервисов Google потребуется заблокировать приложение QUIC. В части File blocking необходимо, как минимум, запретить скачивать исполняемые файлы всем пользователям, кроме сотрудников департамента информационных технологий.

Защита от фишинга учетных данных (Credential Phishing Prevention) работает путем сканирования представленных на веб-сайтах имен пользователей и паролей и сравнения этих представлений с действительными корпоративными учетными данными. Необходимо выбрать, для каких веб-сайтов вы хотите разрешить или заблокировать отправку корпоративных учетных данных, в зависимости от категории URL-адреса веб-сайта.

Хотя использование модели Zero Trust Security предполагает запрет всего, кроме того, что явно разрешено, даже в этом случае правильным подходом будет сделать явные запрещающие правила для приложений торрентов и облачных хранилищ, удаленного доступа и VPN, игровых сервисов и порно, прокси, анонимайзеров и т.п. Также рекомендуется запретить обращаться к DNS в Интернете всем, кроме ваших внутренних DNS-серверов.

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

Для целей удаленного доступа пользователей к корпоративной сети посредством VPN рекомендуется:

- выделить различные точки терминации и пулы IP-адресов для разных типов пользователей;

- включить поддержку IPSec в настройках подключения, так как протокол SSL менее производительный;

- использовать возможности User-identification и Time-scheduling для разграничения доступа с учетом принадлежности к группам в MS Active Directory и согласованных периодов времени удаленной работы;

- настроить профилирование удаленных хостов согласно Compliance (наличие антивируса, патчей операционных систем и т.д.) и соответствующих правил безопасности.

В направлении Интернета рекомендуется запретить все версии протокола SMB и доступ из принтерных, телефонных и прочих подобных систем.

На темной стороне

В ядре центра обработки данных, локальной сети и выделенного сегмента управления инфраструктуры ИТ для обеспечения безопасного взаимодействия вычислительных ресурсов рекомендуется использовать подход, основанный на разделении серверов и пользователей по группам принадлежности к определенным подсистемам и подразделениям. В ядре центра обработки данных рекомендуемым является использование следующей схемы: роутеры зоны обмена маршрутной информации – кластер межсетевых экранов в режиме Active / Passive – виртуальные роутеры – серверные сегменты.

Данный подход позволяет:

- разделить на уровне маршрутизации потоки трафика различных серверных подсистем;

- обеспечить безопасное взаимодействие серверов различных подсистем между собой и с внешними по отношению к центру обработки данных ресурсами.

В ядре локальной сети рекомендуемым является использование следующей схемы: роутеры зоны обмена маршрутной информацией – кластер межсетевых экранов в режиме Active / Passive – виртуальные роутеры – пользовательские сегменты.

Данный подход позволяет:

- разделить на уровне маршрутизации потоки трафика различных подразделений пользователей;

- обеспечить безопасное взаимодействие подразделений пользователей между собой и с внешними по отношению к локальной сети ресурсами;

- изолировать гостевой Wi-Fi от корпоративной сети.

Важным моментом в обеспечении всесторонней безопасности также является ограничение доступа в сеть управления инфраструктурой ИТ по следующей схеме: роутеры зоны обмена маршрутной информации – кластер межсетевых экранов в режиме Active / Passive – виртуальные роутеры – сегменты управления.

Данный подход позволяет:

- разделить на уровне маршрутизации потоки трафика различных сегментов управления;

- исключить взаимодействие сегментов управления между собой;

- ограничить доступ в сегмент управления только из сетей администраторов инфраструктуры и управляющих серверов.

Межсетевой экран в ядре сети должен использовать средства обеспечения всесторонней безопасности такие, как Threat Prevention и Application-identification. Рекомендуется использовать разные политики Threat Prevention для разных сегментов сети. Также, если нет каких-либо особых приложений, хорошей практикой будет изменить правило по умолчанию для IntraZone-трафика с «Allow» на «Drop» и логировать в конце сессии.

В центре обработки данных хорошей практикой будет отключение инспекции ответа сервера (DSRI), поскольку в подавляющем большинстве случае трафик от внутренних серверов компании не содержит вредоносного кода. Да и сниженная в результате инспекции скорость передачи трафика от серверов к пользователям будет вызывать постоянный поток негативных отзывов.

В локальной сети и сети управления будет полезным для написания правил безопасности использовать возможности User-identification, разрешая и запрещая потоки трафика не по IP-адресам сетей, а по группам пользователей, полученным из MS Active Directory.

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

- запрет таких приложений, как smbv1 и Telnet;

- минимизация разрешений для приложений передачи файлов smbv2 и smbv3 (разрешать только в направлении файловых серверов);

- минимизация разрешений для протоколов удаленного доступа (RDP, VNC, SSH);

- минимизация разрешений для сервисов аутентификации (TACACS, RADIUS);

- минимизация разрешений для приложений SNMP, FTP, TFTP, HTTP и HTTPS в направлении оборудования сегментов управления.

Разделяй и властвуй

Рассмотрим ситуацию, когда межсетевые экраны являются точкой обмена трафика между дружественными и не очень компаниями (при слияниях, поглощениях, обеспечении связности с регулирующими, вышестоящими и т.п. организациями) и одновременно выполняют функцию обеспечения выхода в Интернет. В этом случае для обеспечения всесторонней безопасности, кроме использования подхода Zero Trust Security в связке со средствами Threat Prevention и Application-identification, очень важным будет применение сегментирования межсетевого экрана на виртуальные роутеры (virtual routing and forwarding) или даже на виртуальные системы (virtual system).

В этом случае для передачи трафика между сегментами не используют маршрут по умолчанию, а с помощью статической или динамической маршрутизации разрешают взаимодействие только по конкретно определенным IP-сетям. Аналогичный подход рекомендуется использовать и в случае, когда межсетевые экраны ядра отделяют технологическую сеть производственной инфраструктуры (интернет вещей, АСУТП, КИИ и т.п.) от локальной сети предприятия.

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

Рассмотрим, каким образом обеспечить всестороннюю безопасность при использовании современных подходов к построению распределенных сетей передачи данных: два географически распределенных дата-центра – растянутая между ними сеть L2 («по старинке» или VxLAN) – роутеры зоны обмена маршрутной информации – межсетевые экраны – граничные роутеры – офисы.

В данном случае нет единственно верного подхода, но есть список рекомендаций к архитектуре в условиях тех или иных исходных данных.

В случае если позволяет бюджет, и потоки трафика с точки зрения маршрутизации не предполагают асимметрии, в каждом из дата-центров рекомендуется установить по кластеру межсетевых экранов в режиме Active / Passive. Для обмена маршрутной информации на межсетевых экранах использовать BGP / OSPF в связке с протоколом BFD для максимально быстрого переключения маршрутизации при авариях.

Если необходимо встроить межсетевые экраны в текущую инфраструктуру без внесения изменения в маршрутизацию, хорошим вариантом будет использовать их в прозрачном режиме Virtual Wire, минусом которого является исключение межсетевых экранов из вывода команд типа «traceroute», что, в некоторых случаях, может усложнить поиск проблем. Если же асимметрия возможна, то вынужденной мерой для обеспечения передачи трафика будет добавление явных разрешающих правил в обоих направлениях (от клиента к серверу и обратно), а также отключение проверок TCP sanity (tcp asymmetric-path bypass и session tcp-reject-non-syn no).

Если же бюджета не достаточно, можно использовать по одному межсетевому экрану в дата-центрах:

- В режиме Virtual Wire Standalone Active или BGP / OSPF Standalone Active – если не смущают ограничения, указанные выше, и то, что в этом случае отсутствие синхронизации сессий между межсетевыми экранами приведет к разрыву соединений при переходе трафика между ЦОД в случае аварии.

- В режиме Virtual Wire или BGP / OSPF Active / Passive. Для этого потребуется обеспечить связность между межсетевыми экранами для High availability. Несмотря на то, что синхронизация сессий между нодами в указанном режиме имеется, Passive нода не обеспечивает связности для маршрутизации, поэтому при аварии возможны разрывы во время передачи данных таких протоколов, как FTP и SMB.

- В режиме Virtual Wire или BGP / OSPF Active / Active, что потребует не только связности между межсетевыми экранами для High availability, но и отдельного высокоскоростного канала для передачи трафика между нодами во время установки сессии и инспекции асимметричных потоков. Также необходимо глубокое понимание работы режима Active / Active межсетевого экрана.

Отдельно стоит описать возможность использования межсетевого экрана в качестве решения детектирования атак IDS out-of-band. В этом случае трафик с необходимых портов, посредством технологии SPAN или средствами пакетного брокера, перенаправляется на TAP-порты межсетевого экрана.

Это позволяет как провести проверку на угрозы безопасности при помощи средства Threat Prevention, так и показать содержимое туннелей GRE и VxLAN без необходимости внесения изменений в текущую сетевую инфраструктуру. Кроме этого, пакетный брокер в связке с межсетевым экраном позволяет решить и многие другие архитектурные проблемы всесторонней безопасности:

- Bypass Protection – межсетевые экраны могут использовать функциональность пакетного брокера для обеспечения защиты трафика в случае выхода оборудования из строя, обеспечивая резервирование «n+1»;

- Asymmetric Routing Management – пакетный брокер предоставляет эффективную возможность направлять асимметричный трафик на межсетевой экран, который этот трафик должен проинспектировать в обоих направлениях;

- Traffic Distribution – распределение трафика между несколькими межсетевыми экранами, что позволяет эффективно использовать имеющиеся мощности;

- Traffic Filtering – перенаправление только необходимого для инспекции трафика на межсетевой экран;

- Agile Deployment – добавление, удаление и обновление межсетевых экранов, а также преобразование out-of-band мониторинга в средство in-line-инспектирования «на лету», без влияния на прохождение трафика;

- Traffic Aggregation – эффективная утилизация портов межсетевого экрана посредством объединения нескольких низкоскоростных каналов в один для дальнейшей инспекции.

Заключение

В первой части статьи описаны подходы к обеспечению всесторонней безопасности с использованием межсетевых экранов:

- на границе сети Интернет;

- в ядре центра обработки данных, локальной сети и выделенного сегмента управления инфраструктуры ИТ;

- на границе зон ответственности и в качестве решения IDS.

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

- в качестве решения по микросегментации в программно-определяемых сетях;

- при защите облачных сред, в виде облачного сервиса и в качестве решения SD-WAN.

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