Как реализован межсетевой экран?
Межсетевой экран (Firewall, сетевой экран) предназначен для защиты устройств локальной сети от атак извне. По умолчанию все компьютеры домашней сети скрыты от пользователей Интернета встроенным сетевым экраном и транслятором адресов NAT.
Механизм трансляции сетевых адресов NAT маскирует адреса компьютеров локальной сети за единственным адресом внешнего интерфейса, и работает непосредственно с содержимым кадров, подменяя адреса источника и назначения.
Сетевой экран действует на трафик уже после трансляции адресов и маршрутизации, и осуществляет контроль и фильтрацию трафика, в соответствии с заданными правилами на основе IP-адресов.
Встроенный сетевой экран интернет-центра разрешает устанавливать соединение из домашних интерфейсов (LAN) сети в публичные (WAN), и запрещает в обратную сторону. Пользовательскими настройками можно изменять параметры безопасности: разрешать или, наоборот, запрещать доступ к конкретным хостам или сервисам сети.
В предустановленных настройках по умолчанию публичным (внешним, public) является интерфейс, предназначенный для соединения с внешними сетями или для доступа в Интернет. Например, такими интерфейсами являются:
— подключение по выделенной линии Ethernet;
— беспроводное подключение по USB-модему мобильного Интернета 3G/4G/LTE;
— подключение с авторизацией на основе протоколов PPPoE/PPTP/L2TP.
Домашними (локальными, private) являются интерфейсы домашней сети (клиенты подключенные к интернет-центру по Ethernet и по Wi-Fi) и гостевой беспроводной сети.
По умолчанию Keenetic принимает сетевые подключения только с локальных интерфейсов. Из домашних интерфейсов разрешено устанавливать соединения в публичные интерфейсы, и на само устройство для управления и доступа к сервисам, которые включены на интернет-центре (FTP, Transmission, сетевое использование USB-накопителей и т.п.). Для клиентов гостевой сети закрыт доступ для управления интернет-центром и к его сервисам.
Между локальными интерфейсами устанавливать соединение запрещено по умолчанию, но при необходимости, доступ можно разрешить.
Из публичных интерфейсов запрещено устанавливать соединения на любые другие интерфейсы, а также на само устройство.
NOTE: Важно! По умолчанию доступ к управлению интернет-центром (к веб-конфигуратору) из внешней сети заблокирован.
1. Как реализован межсетевой экран?
Упрощенно, сетевой экран можно представить как набор преднастроенных и пользовательских фильтров, причем, правила, настроенные пользователем, имеют более высокий приоритет выполнения.
Сетевой экран оперирует следующими настройками:
— IP-параметры (основные критерии правил фильтрации): IP-адрес/Подсеть, Протокол, Номер порта;
— действия этих правил (Запретить или Разрешить) на пакеты сетевого трафика;
— привязка правил к конкретному интерфейсу.
Пользовательская часть сетевого экрана Keenetic выполняет правила фильтрации, созданные для конкретного интерфейса. При создании правила сетевого экрана очень важно правильно определить интерфейс, для которого оно будет создано. Дело в том, что в привязке правил к интерфейсу также задаётся направление потока трафика, к которому данные правила будут применены. Правила могут выполняться для входящего или исходящего потока WAN- или LAN-интерфейса.
Входящее направление (in) — всегда к устройству, исходящее (out) — от него.
Относительно интерфейса, направление потока определяется как:
– входящее (in) для трафика из внешней сети в локальную на WAN-порту, для LAN-интерфейсов это направление исходящее (out);
– поток из локальной сети во внешнюю для WAN-интерфейсов является исходящим (out), а для интерфейсов LAN входящим (in).
Согласно приведённой схеме, входящий пакет из внешней сети в локальную на WAN-интерфейсе — это входящее направление для правила сетевого экрана, но на LAN-интерфейсе правило для контроля этого трафика — уже исходящее (out).
NOTE: Важно! В интернет-центрах серии Keenetic правила сетевого экрана действуют не «по-пакетно», а в рамках сессии (соединения). Поэтому при блокировке доступа куда-либо нужно запрещать прохождение пакетов со стороны инициатора запроса, а не ответы на эти запросы. Например, для запрета доступа по протоколу HTTP с локальных хостов на внешний адрес 77.88.99.10 нужно создать одно правило на локальном интерфейсе LAN, т.к. инициатор установки сессии (входящий трафик) находится в локальной сети.
Также стоит отметить, что в случае когда сессия уже установлена, а ПОСЛЕ этого применена настройка правила сетевого экрана, касающаяся трафика в этой сессии, данную существующую сессию сетевой экран не будет контролировать. Правило начнёт действовать после разрыва текущей сессии – принудительного или по истечении времени жизни сессии.
Для корректной работы вновь созданного правила (для сброса текущих/активных соединений), интерфейс интернет-центра, к которому оно применимо, следует отключить и включить снова.
2. Настройка правил межсетевого экрана
Правила сетевого экрана выполняются в порядке их указания по списку: первое верхнее и далее вниз. Для любого правила (точнее, для их группы или списка управления доступом) должен быть определён интерфейс, на котором они будут выполняться.
В каждом из правил должны быть указаны:
— сети источника трафика и его назначения (IP-адреса хостов или подсетей);
— протокол, для которого будет действовать настройка (TCP, UDP, ICMP);
— для протоколов TCP и UDP обязательно должен быть указан номер порта;
— действие, которое нужно выполнить над пакетом: Запретить (deny) или Разрешить (permit).
NOTE: Важно! В Keenetic правила сетевого экрана обрабатываются после правил Трансляции сетевых адресов (NAT). Поэтому при создании правил сетевого экрана необходимо указывать IP-адрес хоста уже после трансляции адресов.
3. Настройка правил из веб-конфигуратора
Веб-интерфейс интернет-центра предлагает наиболее удобный способ управления правилами сетевого экрана. Но он имеет ограничение: созданные через веб-конфигуратор правила применяются только к входящему (in) направлению. Настроить правила для исходящего (out) направления нельзя. Через интерфейс командной строки (CLI) интернет-центра возможно создавать правила для любого направления.
Настройка правил сетевого экрана производится на странице «Межсетевой экран».
При добавлении или редактировании правила в окне настройки выбирается действие — «Разрешить» прохождение трафика или «Запретить», и далее указываются критерии-условия, при совпадении которых эти действия будут выполняться.
TIP: Советы:
— Правила следует создавать для интерфейса, на котором фильтруемый трафик является инициирующим сессию;
— При создании отсеивающих фильтров, разрешающие правила (permit) должны располагаться выше запрещающих (deny);
— При настройке правил можно использовать только IP-адреса (при указании адреса источника или назначения нельзя использовать доменные имена).
Для получения информации по настройке правил межсетевого экрана из веб-конфигуратора, обратитесь к инструкции «Межсетевой экран».
4. Исключения в работе межсетевого экрана
Некоторые приложения (сервисы), доступные в интернет-центрах Keenetic, самостоятельно изменяют политики безопасности для своей работы. К ним относятся, например, Серверы VPN, FTP, настройка переадресации портов в NAT с внешнего интерфейса на компьютер в локальной сети или служба UPnP (механизм автоматического открытия портов на хосты в локальной сети). Со стороны пользователя при их использовании не требуется никаких дополнительных настроек, нужные разрешения добавляются автоматически (например, при настройке проброса портов в NAT, создание дополнительных правил в межсетевом экране не требуется, разрешения для доступа создаются автоматически).
Но при необходимости с помощью пользовательских правил можно ограничить трафик, который поступает через автоматически открытые направления, оставив только необходимый. Общая логика настройки таких ограничений — «разрешив нужное, запретим всё остальное».
Например, включенный VPN-сервер PPTP автоматически открывает входящий порт tcp/1723 на каждом из активных интерфейсов устройства. Если нужно ограничить возможность подключения для обращений с определённых адресов в сети Интернет, на внешнем интерфейсе следует создать правила, разрешающие прохождение протокола TCP на порт назначения 1723 от требуемых адресов-источников, а затем — запрещающее протокол TCP на порт 1723 от любых других узлов.
5. Выполнить настройку правил межсетевого экрана можно из интерфейса командной строки (CLI) интернет-центра. Дополнительную информацию вы найдете в статье: «Настройка правил межсетевого экрана из командного интерфейса».
TIP: Совет: Рекомендуем ознакомиться с инструкцией «Примеры использования правил межсетевого экрана».
Open source, собственная инфраструктура и экспертиза: как мы сделали аналог зарубежных межсетевых экранов
Современную инфраструктуру любого масштаба сложно представить без межсетевого экрана. Он позволяет сегментировать сети и избавиться от избыточной сетевой доступности, что повышает уровень безопасности. На рынке существуют программно-аппаратные и программные МЭ, которые позволяют реализовать обширный функционал безопасности сети. Но не все на данный момент подходят клиентам в России.
Чтобы учесть потребности бизнеса, мы в Selectel решили создать собственный межсетевой экран, который не зависит от крупных вендоров. Взяли open source, собственную инфраструктуру и компетенции специалистов компании. Под катом рассказываем, как мы реализовали выгодный по цене и функционалу МЭ на выделенных серверах Selectel.
Почему решили делать свой межсетевой экран
Selectel предлагает в аренду МЭ нескольких известных производителей, но некоторое время назад встал вопрос о поиске замены. Предпосылок было несколько:
- высокая стоимость решений — в последнее время цена поднялась в несколько раз,
- порой избыточная для конкретного инстанса производительность, за которую приходится переплачивать,
- недостаток гибкости в используемых компонентах,
- зависимость получения обновлений сигнатур (например, для IPS) от подписок вендора, невозможность добавить свои,
- проблема с оперативной заменой оборудования при выходе из строя (при недостаточном объеме ЗИП либо при необходимости ожидать отправки и возврата оборудования вендору).
В ходе анализа существующих на рынке вариантов мы решили протестировать связку: open source-решение + выделенный сервер (далее — МЭ).
Почему выбрали open source-решение?
- это проверенное временем, надежное решение, основанное на FreeBSD, в которое при необходимости можно устанавливать дополнительные пакеты, расширяющие доступный функционал,
- можно устанавливать как на «железные», так и на виртуальные серверы,
- имеет удобный веб-интерфейс для управления,
- отличная подробная документация,
- развитое комьюнити,
- быстрая установка из ISO-образа,
- есть поддержка расширенных инструкций процессоров для ускорения шифрования.
Почему выделенный сервер?
- высокая производительность,
- возможность использования с другими арендованными серверами,
- аппаратное ускорение функций шифрования.
Выбор платформы для тестирования
Нам нужно было протестировать несколько серверных сборок, чтобы определиться, на какой решение лучше «приживется». Платформу выбирали по нескольким критериям.
Производительность сервера
Здесь смотрели на загруженность процессора и объем используемой оперативной памяти. Используемое open source-решение позволяет разворачивать множество дополнительных пакетов для фильтрации трафика, поэтому нужно было заложить запас вычислительных мощностей с расчетом на добавление новых пакетов.
Наличие аппаратной поддержки шифрования процессором
У используемого ПО есть поддержка аппаратного ускорения шифрования, поэтому было решено брать в тест только процессоры с таким функционалом.
Стоимость платформы
Можно было просто взять самую дорогую сборку сервера и сразу тестировать на нем, но это привело бы к тем же проблемам избыточности ресурсов и высокой стоимости, от которых мы хотели избавиться. Поэтому искали консенсус между стоимостью, производительностью и надежностью оборудования.
МЭ по умолчанию имеет два интерфейса 1GE RJ45. Этого достаточно для настройки межсетевого экранирования сервисов с общей пропускной способностью сети в 1 Гбит/c. Если нужно разбить пропускную способность для разных серых сетей, то МЭ позволяет сделать это с помощью traffic shaping.
Тестирование на выделенном сервере
Тестирование проводили с помощью двух инструментов — iPerf3 и TRex traffic generator.
iPerf3 — пожалуй, самый популярный генератор TCP/UDP-трафика. С его помощью можно измерить максимальную пропускную способность сети при различных вариантах трафика: TCP/UDP, кастомные размеры пакетов, количество потоков и т.д. Дополнительную информацию о продукте можно найти здесь.
TRex — отличный open source-генератор трафика уровней L3-L7, позволяющий генерировать в том числе IMIX-трафик. Подробнее об инструменте можно почитать здесь.
Тестирование с помощью iPerf3
Для тестирования мы собрали следующий стенд:
Как видно из схемы, на два выделенных сервера мы установили pfSense 2.6. Между ними подняли VPN-туннели (IPSec и openVPN). За одним из МЭ в серой сети развернули сервер с iPerf3, доступ к которому был настроен как через port-forwarding (для тестирования производительности по открытому каналу), так и через VPN-туннель. В межсетевом экране можно установить пакет iPerf3 и проводить замеры из веб-интерфейса или консоли.
В процессе тестирования также сравнили скорости в VPN-туннелях с использованием расширенного набора инструкций процессора (AES-NI) и без.
Результаты тестирования для TCP при 128 потоках.
Как видно из графика, включение аппаратного ускорения шифрования дает увеличение пропускной способности в VPN-туннеле примерно в 1,5—2 раза, что весьма существенно. Полученные результаты, в том числе замеры в VPN-туннелях, близки к пропускной способности интерфейса. Причем загрузка CPU сервера в тестах была до 30%, а объем используемой оперативной памяти сборки не превышал 4%.
Тестирование с помощью TRex
Под TRex собрали следующую схему:
В данной схеме каждый из выделенных серверов находится в одном VLAN с соответствующим интерфейсом второго сервера. Алгоритм прохождения трафика следующий:
- TRex с клиентской части генерирует трафик с src-адресами из сети 16.0.0.0/8 и dst-адресами из сети 48.0.0.0/8 и отправляет его из igb0 на igb0 МЭ.
- МЭ получает этот трафик, обрабатывает его в соответствии с правилами FW и отправляет на адрес интерфейса igb1 TRex (так как предварительно на МЭ был добавлен маршрут в сеть 48.0.0.0/8 через 192.168.110.2)
- TRex получает трафик на своей серверной части (dst 48.0.0.0/8) и сравнивает отправленный трафик (скорость, количество пакетов) с полученным.
В условии атак с помощью http-трафика при включенной блокировке Snort объем возвращающихся пакетов на TRex плавно уменьшался. Значит, IPS под нагрузкой работает корректно.
Результаты тестирования IMIX-трафика
-c — количество аппаратных потоков для использования на пару интерфейсов
-m — множитель скорости. TRex умножит скорость CPS каждого шаблона на указанное значение
-d — продолжительность теста в секундах
flows — количество потоков
clients — количество IP-адресов источников трафика
servers — количество IP-адресов получателей трафика
PPs — пакетов в секунду
Tx — отправляемый трафик
Rx — принимаемый трафик
CPU usage МЭ — процент использования CPU
RAM usage МЭ — процент использования RAM
Как это все администрировать
Первоначальная настройка
После выбора платформы приступаем к установке и настройке межсетевого экрана.
Установка из ISO-образа не сложнее установки любой ОС. Необходимо подключить ISO-образ к серверу и выбрать порядок загрузки с носителя.
Более подробное описание установки можно найти по ссылке.
Дополнительная настройка
После первоначальной настройки получаем готовый к работе МЭ. Теперь можно использовать его функционал для создания по-настоящему эффективного и удобного firewall. Так, например, можно:
- экспортировать и импортировать конфигурацию,
- разграничивать доступ пользователям МЭ,
- настраивать различные варианты VPN.
Разграничение доступа. МЭ позволяет гибко настраивать разграничение прав доступа. Это может быть полезно при разделении ответственности за настройку решения между сотрудниками — например, отделов ИТ и ИБ.
VPN. МЭ из коробки имеет возможность создавать VPN с использованием IPSec и OpenVPN.
Подробные инструкции по настройке можно найти в базе знаний Selectel.
Сценарии использования
Рассмотрим несколько сценариев использования межсетевого экрана на выделенном сервере.
Защита выделенных серверов
Самым базовым сценарием является использование МЭ для защиты выделенных серверов, когда LAN-интерфейс межсетевого экрана находится в одном VLAN и в одной сети с выделенными серверами. В этом случае на выделенных серверах необходимо выключить интерфейс, подключенный в коммутатор, и настроить маршрут по умолчанию через МЭ.
В дальнейшем при таком дизайне весь трафик между интернетом и серыми сетями выделенных серверов будет проходить через МЭ, где можно настроить его фильтрацию.
Использование в качестве VPN-шлюза для удаленных ресурсов
Иногда за межсетевым экраном находятся ресурсы, которые не следует публиковать в открытый доступ. Но к ним нужно обеспечить доступ с других площадок или для удаленных пользователей. В таком случае МЭ может быть использован как VPN-шлюз — для Site-to-Site-туннелей и/или для Client Access VPN.
Гибкая настройка протоколов шифрования и хэширования для IPSec позволяют построить туннель с различными устройствами. А с помощью разграничения доступа к туннелируемым серым сетям по определенным портам можно избежать избыточной сетевой доступности в VPN-туннелях.
Сегментирование сетей в выделенных серверах
При реализации схемы с несколькими серверами, предназначенными для разных задач, лучшим вариантом будет сегментация сетей. Для этой задачи также отлично подойдет МЭ с возможностью настройки нескольких IP-адресов на LAN-интерфейсе.
В таком сценарии можно очень гибко настраивать межсетевое экранирование между сетями/отдельными хостами, таким образом организовав DMZ (демилитаризованную зону). Также у МЭ есть возможность использовать QinQ, если требуется разделение на уровне L2.
Использование в качестве FW для нескольких услуг
Межсетевой экран можно использовать как единую точку выхода в интернет для всех услуг. В этом случае схема будет следующей:
Пример дизайна для выхода сети публичного облака в интернет через МЭ.
Описанную инсталляцию мы упаковали в новый межсетевой экран Selectel. Он отфильтрует трафик и защитит от сетевых атак. Клиенту предоставляется программно-аппаратный комплекс в составе сервера фиксированной конфигурации и развернутого на нем межсетевого экрана.
Нам удалось воплотить самую необходимую функциональность в недорогом и надежном аппаратном исполнении.
Что умеет межсетевой экран Selectel
Маршрутизация и NAT
Настройка статической и динамической маршрутизации, политико-ориентированная маршрутизация (Policy-based routing), блокировка немаршрутизуемых адресов.
Сетевые сервисы
Ограничение полосы пропускания, настройка DHCP (server, relay), NTP, SNMP, GRE, GIF, DNS (forwarder, resolver).
Межсетевой экран
Фильтрация трафика, сегментирование сетей с помощью виртуальных IP, фильтрация по URL-адресам, создание групп (IP, портов, URL), возможность запускать правила на определенный промежуток времени или составлять расписания работы правил.
IPSec (Site-to-Site, client access), OpenVPN (Server, Client).
Диагностика и восстановление
Просмотр таблицы ARP, активных сетевых сокетов, контроль утилизации CPU, количества трафика и статистика на интерфейсах. Возможность снятия дампа трафика, проверка соединения TCP-порта, DNS Lookup, использование инструментов ping, traceroute. Возможность сохранения и восстановления конфигурации, просмотр загрузки интерфейсов.
Настраивает межсетевой экран клиент самостоятельно — инструкция в базе знаний. В случае выхода из строя аппаратных компонентов мы оперативно предоставим замену — новый инстанс, на который будет достаточно лишь импортировать ранее сохраненную конфигурацию. После межсетевой экран будет полностью готов к работе.
Selectel отвечает за сервисное обслуживание, подключение к локальной сети выделенных серверов и интернету, настройку маршрутов для выхода в интернет. Сюда же входят все преимущества размещения в дата-центре уровня Tier III – бесперебойное электропитание оборудования и микроклимат.
Лучшие практики проектирования архитектуры для обеспечения информационной безопасности при использовании межсетевых экранов (часть 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.
Также будут рассмотрены критерии выбора межсетевых экранов и лучшие практики по настройке и аудиту сервисов безопасности.