Мы погрузились с головой в жизнь с российскими NGFW и пережили не одно внедрение в самые разные по сложности сети заказчиков. Собрали для вас 10 советов как внедрить UserGate и не наступить на грабли.
Немного обо мне и нашей компании
Привет! Меня зовут Евгений, я работаю системным инженером в компании “Первый Интегратор” – мы располагаемся в Тюмени, но помогаем внедрять решения нашим заказчикам по всей России. Мы на рынке уже 7 лет, а в последние годы мы просто обязаны были погрузиться в отечественный рынок решений по информационной безопасности. Считаем, что погружение прошло успешно, и нам есть о чём вам рассказать!
Содержание
- Почему мы выбираем UserGate?
- Как сделать всё так, чтобы получился ожидаемый результат
- МСЭ – это L3 устройство
- Почему стоит использовать внешний DHCP-сервер
- Внутренний УЦ – это не сложно
- Разделяй! (Но не властвуй). Про важность сегментации сети
- Кейс: два провайдера, две ноды в кластере
- Некоторые Best Practices при настройке:
- Антиспуфинг на зонах
- Защита от DoS
- Защита DNAT от случайной блокировки правилами МСЭ
- Почему мы всегда предлагаем ставить кластер
- Защита почты – как работает DNSBL
- Скрипты и другие полезности:
- Автоматическое создание VPN-подключения на Windows
- Split DNS средствами Active Directory
- Заключение
Почему мы выбираем UserGate?
UserGate “в народе” часто называют “самым фичастым” NGFW – и с этим трудно не согласиться. Он может предложить гораздо больше, чем его конкуренты: собственные списки URL, сигнатур приложений и Системы Обнаружения Вторжений (СОВ), которые регулярно обновляются – и это только NGFW-функционал. Помимо этого, последний год активно разрабатываются решения на собственных платформах на базе процессоров ARM, добавляется новый сетевой функционал – в последней версии появился BFD, WAF, очень гибкий в плане лицензирования и подключения UserGate Client, который и EDR, и VPN, и вообще вещь в хозяйстве незаменимая.
Безусловно, этот продукт не без проблем, как и многие (все?) продукты на рынке, в том числе и иностранные. Поэтому важно и то, как отрабатывает техническая поддержка – как быстро решаются проблемы.
В данной статье я поделюсь опытом, накопившимся за многие внедрения в самые различные сети заказчиков и поговорю об особенностях, которые стоит учитывать.
Как сделать всё так, чтобы получился ожидаемый результат
МСЭ – это L3 устройство
Некоторые желают установить МСЭ как L2 устройство, чтобы не менять топологию сети и не перестраивать маршрутизацию. Для этого можно использовать мосты, proxy-arp, и другие технологии, которые лишь усложняют схему. Особенно это мешает, когда необходимо разобраться, почему что-то не работает. Мы всегда избегаем схем включения МСЭ в сеть как L2/L3-бриджи и предпочитаем перестроить сеть так, чтобы МСЭ был полноценным устройством L3 – ведь именно таким оно и является. NGFW расшифровывает трафик, авторизует пользователей, имеет потоковый антивирус – все эти функции корректно работают, только если устройство является полноценным шлюзом устройств. Если же мы все же будем использовать L2/L3 мосты, мы столкнемся с ограничениями, например:
Функционал DNS-фильтрации и мост L2 в текущей версии несовместимы – при включении DNS-фильтрации DNS-запросы через мост проходить перестают.
Почему стоит использовать внешний DHCP-сервер
На самом деле, МСЭ стоит использовать как МСЭ (и совсем немного как маршрутизатор). Функционал, для которого это устройство не предназначено, лучше доверить созданным для этого ПО или устройствам.
Немного о том, почему не стоит использовать DHCP-сервер на NGFW:
- При отказе МСЭ вы потеряете не только доступ во внешнюю сеть, но и взаимодействие внутри компании – аренды адресов постепенно истекут и устройства потеряют свои адреса.
- В случае кластера межсетевых экранов UserGate (а у вас ведь кластер, так?), пулы не являются общими для кластера, поэтому должны быть настроены на каждой ноде отдельно. При этом эти пулы не могут пересекаться – это должны быть разные подсети. Конечно, вы можете разделить вашу /24 подсеть на две /25, под каждый узел кластера. Но при смене мастера всем устройствам придется заново получить свой адрес из другого пула /25.
Внутренний УЦ – это не сложно
Для инспекции SSL (расшифровки трафика) UserGate предлагает использовать самоподписанный сертификат UserGate. Может показаться, что это удобно – осталось лишь добавить политиками GPO его в доверенные на корпоративные компьютеры.
Мы же настоятельно рекомендуем разворачивать роль AD CA на своих серверах и выписывать промежуточный корневой сертификат для UG.
На это есть несколько причин:
1. Это просто!
Не нужно создавать политику, убеждаться, что она применилась ко всем пользователям. Пользователи будут автоматически доверять всем сертификатам, подписанным доменным корневым УЦ. Роль AD CA разворачивается за 15 минут.
Первое видео из поиска на эту тему (спасибо нашим коллегам из Индии):
02. Installing an Enterprise Root Certificate Authority | Windows Server 2019
Далее заходим от имени администратора домена по адресу https://AD-DC/certsrv , переходим в раздел “Request a certificate” и выбираем “advanced certificate request”. Вставляем содержимое файла Certificate Sign Request (CSR) обязательно вместе с текстом -----BEGIN CERTIFICATE-----.
Выбираем Certificate Template: либо веб-сервер (для сертификата веб-портала, консоли администратора, страниц блокировки, т.е. всего, кроме сертификата инспекции SSL), либо, соответственно, SubCA для сертификата инспекции SSL.
2. Перевыпуск сертификатов такой же прозрачный.
При использовании самоподписанного сертификата, через 5 лет сертификат истечет, и вам вновь придется распространять новый сертификат политиками. В случае использования доменного УЦ нужно лишь выписать новый сертификат для UserGate.
3. Откат/обновление UserGate на мажорную версию.
При обновлении UserGate с версии 6.0 до версии 7.0, необходимо выполнить чистую установку. Вы можете экспортировать все настройки и загрузить их, но сертификаты (в частности, закрытые ключи) экспортированы не будут. При чистой установке будет выпущен новый самоподписанный корневой сертификат, и эта ситуация может застать вас врасплох.
При использовании внешнего УЦ вам потребуется лишь подписать новый (или загрузить старые закрытый и открытый ключи) сертификат.
Разделяй! (Но не властвуй)
Про важность сегментации сети
Часто встречаются сети, где все пользователи находятся в одном VLAN’е. Повезет, если в той же подсети нет серверов. В таком случае важно наладить контакт с сетевыми инженерами и провести сегментацию сети. Без разделения сети будет трудно создавать политики инспектирования трафика:
- доменные пользователи доверяют нашему сертификату автоматически; серверы на Unix, как правило, требуют ручной установки корневого сертификата; гостевые – совсем нет. Если эти группы хостов разделены на разные подсети, можно легко создать различные политики для них.
- доменных пользователей мы можем прозрачно аутентифицировать, а серверы либо не должны проходить аутентификацию вовсе, либо иметь статическую привязку.
- хорошим тоном будет выделять сегменты сетей, для которых требуется проверять трафик потоковым антивирусом. Например, проверка трафика WSUS (обновления Windows), создаст лишнюю нагрузку на МСЭ.
Кейс: два провайдера, две ноды в кластере
Когда используется кластер МСЭ, где в каждый узел подключено два одинаковых провайдера, мы пришли к следующим требованиям, без которых реализация будет хромать:
1. Для каждого провайдера создается своя зона Untrusted.
Это необходимо для того, чтобы создать два правила SNAT и в каждом принудительно указать IP адрес, в который будут транслироваться пакеты – виртуальный адрес соответствующего провайдера. Иначе (при создании одного правила в зону Untrusted без явного указания адреса) ноды будут транслировать пакеты в собственные IP адреса, и при переключении мастера сессии будут разорваны.
2. Необходимость в N+1 IP адресах для каждого провайдера (при сценарии кластера из N нод).
Например, для N=2:
Если хотя бы у одного провайдера не будет трех IP адресов, никаких плюсов от наличия 3х адресов на других провайдеров вы не получите. В этом случае 1 адрес используется как виртуальный – в него транслируются пакеты пользовательского трафика. Два других – собственные IP адреса для каждой ноды, которые требуются для скачивания обновлений, а также для проверки лицензии и доступности сети – отправки PING до указанного адреса.
Мы можем использовать серые IP адреса для нод, но тогда нода не сможет отправлять запросы PING (т.к. они отправляются с собственных адресов). Значит, если хотя бы один провайдер не может предоставить вам 3 IP адреса, при включенной проверке сети с помощью PING шлюз будет всегда недоступен, и, следовательно, нет смысла в том, что эта проверка включена для других провайдеров.
Вывод: либо у вас 3 IP адреса для каждого из провайдеров, либо обходимся одним от каждого, но без проверки сети (только по наличию ARP ответов).
Некоторые Best Practices при настройке
Антиспуфинг на зонах
На Untrusted зоне желательно включить защиту от IP-спуфинга в режим “инвертировать” и следующим списком IP-адресов:
0.0.0.0/8
169.254.0.0/16
192.0.2.0/24
192.168.0.0/16
198.18.0.0/15
198.51.100.0/24
203.0.113.0/24
240.0.0.0/4
10.0.0.0/8
127.0.0.0/8
172.16.0.0/12
224.0.0.0/4
Защита от DoS
На Trusted и Untrusted зонах следует сразу повысить или вовсе отключить лимиты для UDP пакетов. SIP и ВКС трафик скажет вам спасибо – стандартные лимиты малы даже для небольших офисов.
Защита DNAT от случайной блокировки правилами МСЭ
Здесь мы не придумали никаких новшеств – спасибо Константину (@Kentmmm) из телеграм-канала UserGate!
При минимальной конфигурации (создано только правило DNAT) всё работает корректно, т.е. создается неявное разрешающее правило МСЭ. Однако, если добавить запрещающее правило МСЭ, под которое попадает трафик DNAT в прямом или обратном направлении – DNAT будет блокироваться, при этом в журнале вы не увидите событий о блокировке этого трафика. Для того чтобы избежать такой ситуации, мы всегда добавляем для каждого правила DNAT своё разрешающее правило в МСЭ. Например:
Для правила DNAT:
- адрес назначения = 77.88.77.88
- DNAT адрес назначения = 192.168.1.1
- порт = 80
Создаем правило МСЭ:
- зона источника = Untrusted
- адрес назначения = 192.168.1.1
- порт = 80
Почему мы всегда предлагаем ставить кластер
Безусловно, кластер увеличивает сложность и стоимость системы (спойлер: не в 2 раза), но мы пришли к тому, что кластер, так или иначе, нужен всегда. Если заказчик покупал отдельно стоящий МСЭ, затем все равно докупал зип.
Вы скажете спасибо интегратору, который уговорил вас установить кластер МСЭ, когда будете обновлять ПО – так прерывания сервиса можно избежать. Также нельзя исключать баги в обычной работе ПО – пару раз нам приходилось переключать мастер ноду и отправлять её в перезагрузку из-за нестабильности работы ПО (при редактировании настроек зон переставал работать модуль МСЭ, помогала только перезагрузка).
Защита почты – как работает DNSBL
В UserGate есть встроенный модуль защиты почты от спама и вирусов (aka Cisco ESA?) и велик соблазн за небольшую стоимость докупить его, закрыв гештальт спама и вирусов.
И если вы уже стали счастливым обладателем данного модуля – во-первых, поздравляю с покупкой! Ну а во-вторых – журнал работы данного модуля появился только в версии 7.1.0 (на момент написания статьи, версия в статусе Release Candidate). Поэтому здесь я опишу, как можно проверить, почему блокируется тот или иной внешний почтовый сервер.
Первый делом, если у вас что-то работает некорректно – следует обратиться к документации.
Алгоритм настройки защиты почтового трафика - UserGate :: База Знаний
По ссылке описан алгоритм настройки правил, важен порядок включения правил DNAT и Mail Security. Также проверяем, что на внешней (untrusted) зоне включен SMTP-прокси и добавлены правила расшифровки SMTPS соединений.
Вторым шагом следует проверить, загружены ли на железку анти-спам базы и присутствует ли лицензия. Сделать это можно только через обращение в техподдержку и включение удаленного доступа к UserGate – лучше не стесняться и писать сразу. Пара наших кейсов: в одном случае сгенерировали новый лицензионный ключ, чтобы загрузились базы; в другом сотрудник технической поддержки сам загрузил эти базы.
После всех этих операций мы можем начать разобраться, как же работает механизм DNSBL и как его можно проверить. Механизм проверки IP адреса внешнего почтового сервера следующий: делается DNS запрос с перевернутым IP адресом. То есть, для сервера 1.2.3.4 запрос к DNSBL серверу dnsbl.com будет следующим: 4.3.2.1.dnsbl.com.
По тому, какую A-запись вернет сервер, UserGate будет судить, присутствует ли данный почтовый сервер в спам-базах. Коды ответов в таблице:
По кодам ответов можно реализовать разную логику их обработки:
- Все что не пустое – спам. Не совсем верно, ведь есть еще коды ошибок. Например, запрос через рекурсивный DNS.
- Если вернулся адрес из подсети 127.0.0.0/22 – это спам. Здесь уже все верно.
Какая именно логика реализована в UserGate Mail Security нам достоверно неизвестно, но считаем, что лучше перестраховаться и выбрать те DNSBL серверы, которые не будут ругаться на ваши запросы через публичные рекурсивные DNS серверы. По умолчанию в UserGate настроены 4 DNSBL сервера, и тут уже для каждого ситуация своя – зависит от используемых вами DNS серверов. Для нас надежным вариантом стал rbl.rbldns.ru.
Скрипты и другие полезности
Автоматическое создание VPN-подключения на Windows
(актуально для IKEv1)
Add-VpnConnection -Name "<Имя соединения>" -ServerAddress "<IP>" -RememberCredential -SplitTunneling -L2tpPsk "<Общий ключ>" -TunnelType "l2tp" -AuthenticationMethod Pap -Force
Данный скрипт создает VPN подключение, устанавливает нужные параметры аутентификации и включает Split-Tunneling – то есть, готов к использованию сразу же, без необходимости лезть дополнительно в настройки сетевого интерфейса.
Сохраняем с расширением .ps1 и отправляем пользователям (запускать через ПКМ – выполнить с помощью PowerShell).
Split DNS средствами Active Directory
Задача:
Если у вас несколько офисов, используются VPN для удаленного доступа, либо VPN Site-to-Site, мы можем столкнуться со следующей ситуацией:
Доменные записи {utm, auth, block, logout}.company.com указывают на внутренний интерфейс UserGate в головном офисе, поэтому при попытке зайти на эти страницы, подключившись по VPN или из другого филиала (VPN Site-to-Site), этот запрос будет заблокирован UserGate (так называемый Zone Drifting): это попытка подключиться к интерфейсу другой зоны.
Workaround:
Можно зайти на нужную страницу по IP адресу соответствующей зоны, но в сценарии аутентификации это работать не будет – в ней срабатывает автоматическое перенаправление на доменное имя auth.company.com, а не на IP адрес.
Решение данной задачи – DNS Policy в Active Directory DNS
Суть: в зависимости от подсети, из которой пришел DNS запрос клиента, отдавать разные ответы для тех же доменных записей.
Настройка (на примере зоны company.com):
#Добавляем подсети клиентов – подсеть второго офиса (приходят в зону VPN Site-to-Site), и подсеть VPN Remote Access.
Add-DnsServerClientSubnet -Name "DNS_SUBNET_BRANCH2" -IPv4Subnet "10.20.0.0/16"
Add-DnsServerClientSubnet -Name "DNS_SUBNET_VPN" -IPv4Subnet "10.255.0.0/24"
#Получить список созданных подсетей:
Get-DnsServerClientSubnet
#Добавляем два скоупа ("подзона", куда мы будем добавлять наши DNS записи)
Add-DnsServerZoneScope -ZoneName "company.com" -Name "DNS_SCOPE_BRANCH2"
Add-DnsServerZoneScope -ZoneName "company.com" -Name "DNS_SCOPE_VPN"
#Добавляем DNS запись "utm" с другим IP адресом, который указывает на соответствующий интерфейс UserGate в нужной зоне.
Add-DnsServerResourceRecord -ZoneName "company.com" -A -Name "utm" -IPv4Address "10.10.255.254" -ZoneScope "DNS_SCOPE_BRANCH2"
Add-DnsServerResourceRecord -ZoneName "company.com" -A -Name "utm" -IPv4Address "10.255.0.254" -ZoneScope "DNS_SCOPE_VPN"
#Получить DNS записи в каждом скоупе
Get-DnsServerResourceRecord -ZoneName "company.com" -ZoneScope DNS_SCOPE_BRANCH2
Get-DnsServerResourceRecord -ZoneName "company.com" -ZoneScope DNS_SCOPE_VPN
#Добавляем политику – при обращении из подсети DNS_SUBNET_BRANCH2 и запросе доменного имени utm.company.com, нужно применить политику и посмотреть адрес не в основной зоне, а в скоупе.
#Важно: обязательно указываем параметр -FQDN, чтобы политика применялась ТОЛЬКО при запросе этой записи.
#Иначе политика будет отрабатывать для всех запросов от клиентов указанной подсети, и они не смогут получить DNS записи из основного скоупа (любой запрос будет искаться в скоупе DNS_SCOPE_BRANCH2, а в нем есть только одна запись)
Add-DnsServerQueryResolutionPolicy -Name DNS_POLICY_BRANCH2_UTM -Action ALLOW -ClientSubnet "eq,DNS_SUBNET_BRANCH2" -FQDN "eq,utm.company.com" -ZoneScope "DNS_SCOPE_BRANCH2,1" -ZoneName company.com -PassThru
Add-DnsServerQueryResolutionPolicy -Name DNS_POLICY_VPN_UTM -Action ALLOW -ClientSubnet "eq,DNS_SUBNET_VPN" -FQDN "eq,utm.company.com" -ZoneScope "DNS_SCOPE_VPN,1" -ZoneName company.com -PassThru
#Получить список созданных политик
Get-DnsServerQueryResolutionPolicy -ZoneName company.com
Заключение
Переход с иностранных решений в области информационной безопасности, давно присутствующих на рынке, очевидно, сопровождается определёнными ожиданиями. Особенно в случае, когда этот переход происходит не по собственной воле, настрой становится не таким положительным. Мы привыкли, что на Cisco ASA можно повесить и PoE, и DHCP, и всё-всё-всё, но такого никогда не было в Best Practices. Используйте МСЭ как шлюз безопасности и будет вам счастье :)
Надеюсь, вы нашли для себя что то новое!
