Компания UserGate давно планирует выпустить на рынок UserGate Client — продукт для безопасного удаленного подключения пользователей к корпоративной сети. Как заверяет разработчик, нас ждет VPN-клиент, который в некоторых сценариях можно использовать как решение NAC и даже EDR.
Мы в Nubes (НУБЕС) настроили и протестировали нерелизную версию UserGate Client совместно с Management Center и NGFW (build 7.1.0.1704R). Результатами решили поделиться на Хабре.
Спойлер: в целом ок, но есть нюансы.
В этой статье рассмотрим:
что представляет собой UserGate Client,
какие есть требования к установке и варианты аутентификации,
процесс настройки в связке с Management Center и NGFW: от загрузки сертификатов SSL до передачи логов в SIEM.
Что это такое
UserGate Client — решение, которое можно одновременно классифицировать как:
бесплатный Remote Access VPN (Virtual Private Network) для нелицензируемого подключения внешних пользователей к корпоративной сети,
решение NAC (Network Access Control). В таком режиме VPN-клиент работает только в связке с другими продуктами экосистемы UserGate (сервером управления Management Center, сервером аналитики Log Analyzer и файрволом нового поколения UserGate). В этом сценарии можно контролировать доступ пользователей к сети и вариативно защищать их станции от угроз,
инструмент EDR (Endpoint Detection & Response). Вместе с теми же продуктами решение берет на себя мониторинг состояния безопасности рабочих станций, поиск опасных событий и блокирование этих угроз.
Подробности и подходы к архитектуре
Вариант с бесплатным RA VPN предполагает подключение UserGate Client в режиме NGFW. В этом случае функционал UserGate Client сводится к VPN и сбору-отсылке телеметрии. Вся информация собирается на UserGate NGFW, там же применяется политика доступа, комплаенс-проверка устройства (разработчик называет это профилированием) и принятие решения о дальнейшем допуске клиента в локальную сеть.
Однако в режиме NGFW есть важное неудобство — управление продуктом лежит на стороне конечных пользователей. Второй вариант — администратор постоянно связывается с ними, чтобы изменить настройки в ПО на их устройствах.
Второй и третий сценарии предполагают подключение UserGate Client в режиме Management Center (сервер управления). Именно на него отправляются данные телеметрии с устройства.
С помощью Management Center администратор может централизованно управлять настройками UserGate Client на всех подключенных устройствах и без участия пользователей. Причем сами устройства могут находиться как за периметром локальной сети, так и внутри.
Связка «UserGate Client + Management Center» на практике может выглядеть по-разному. На наш взгляд, есть минимум два актуальных подхода к архитектуре.
1. Management Center находится внутри корпоративной сети, где также размещаются контроллер, Log Analyzer и другие серверы. При этом сервер управления может «жить» внутри сети без публикации:
В этом случае UserGate Client будет работать с актуальными политиками, если устройство находится в той же сети. Если пользователь заберет ноутбук с собой домой, то VPN-клиент будет использовать последние сохраненные политики.
2. Management Center может «жить» внутри сети, но с публикацией наружу. В таком режиме UserGate Client будет подключаться к нему напрямую, всегда использовать актуальные политики и отправлять телеметрию.
Схема расположения Management Center в DMZ-сегменте:
Конечно, в теории возможны другие схемы. Можно, например, использовать два сервера Management Center: один будет управлять парком NGFW, другой — UserGate Client :)
Нюанс. В теории можно использовать нативные средства VPN-подключения, которые встроены в популярные ОС (Windows, Android) и работают по IKEv2. Однако в таком сценарии нет раздельного туннелирования. Управлять маршрутами при нативном подключении можно только добавляя либо исключая их из туннеля. Данные для комплаенс-проверок в этом случае тоже не собираются. |
Функционал и необходимые лицензии
По необходимым лицензиям и функционалу разница тоже есть:
UserGate Client + Management Center | UserGate Client + NGFW | UserGate Client + нативные средства ОС | |
VPN | Endpoint лицензия Management Center, Лицензия пользователя NGFW | Лицензия пользователя NGFW | Лицензия пользователя NGFW |
IKev1 (Аутентификация L2TP) | + | + | + |
IKev2 (Аутентификация по сертификатам) | + | + | + |
IKev2 (Аутентификация по логину-паролю с помощью EAP MS-CHAPv2) | + | + | + |
IKev2 (MFA) | + | + | - |
IKev2 (Раздельное туннелирование) | + | + | - |
HIP (комплаенс-проверки) | Endpoint лицензия Management Center, NAC подписка Management Center | Лицензия пользователя NGFW, NAC подписка NGFW | - |
Чтобы изучить базовый функционал, мы решили не лезть в сложные схемы и выбрать более простой для нас способ использования. А точнее — протестировать UserGate Client на машинах вне корпоративной сети с подключением к шлюзу безопасности (UserGate NGFW).
Требования к установке и варианты аутентификации
Базовые требования к компьютеру пользователя для установки UserGate Client:
ОС — Windows 10/11,
объем оперативной памяти — от 2 Гб,
процессор с тактовой частотой не ниже 2 ГГц,
минимум 200 Мб свободного пространства на жестком диске.
Нюанс. Установить UserGate Client можно только на Windows. Версии для Linux пока нет. По нашим данным, сейчас она находится в разработке. |
После установки нужно выбрать метод, по которому мы будем подключаться к корпоративному шлюзу безопасности с нашего VPN-клиента. На данный момент доступны два варианта: сертификат и логин-пароль.
По сертификату
Мы установили решение на виртуальную машину (UG Client 1). Она находится на внешнем периметре. При этом есть внешний адрес, который принадлежит интерфейсу шлюза безопасности, и на него нацелено некое доменное имя. В нашем случае это vpn.nubes.lab. На него выписали сертификат, который содержит доменное имя и ip-адрес.
При подключении по сертификату все эти параметры сравниваются. Благодаря этому можно удостовериться, что точка, к которой мы стучимся, является именно той, что нам нужна.
Нюанс. При подключении UserGate Client можно использовать только именные сертификаты SSL. Wildcard-сертификат не поддерживается. Поверьте: лучше не тратить время на попытки заставить работать то, что работать не будет. |
По логину-паролю
Что касается варианта с логином-паролем, то здесь все намного проще. Вводим данные пользователя. Если он состоит в определенных группах пользователей на NGFW, то разрешаем/запрещаем подключение. При положительном решении выделяется соответствующий туннельный адрес. После этого пользователь может пользоваться интернетом и/или локальной сетью.
В чем принципиальная разница этих двух вариантов? В том, что в режиме NGFW процесс подключения и выбор метода аутентификации лежит на стороне пользователя. А в режиме Management Center созданные администратором политики «спускаются» на UserGate Client. Пользователю остается лишь выбрать доступный вариант подключения.
Процесс настройки
Разворачиваем стенд
Итак, мы решили выяснить, как работает новое решение VPN IKEv2 и как его настроить средствами UserGate 7.1. Для этого мы собрали тестовый стенд, который выглядит так:
Подробнее о стенде
По схеме понятно, что условно стенд делится на три блока:
Кластер UserGate c VPN-серверами в режиме active-passive (по центру схемы).
Внешний периметр, имитирующий публичную зону (Untrusted, розовый блок справа). В ней мы создали две виртуальные машины с VPN-клиентом на борту. Одна работает в режиме «UserGate Client + NGFW», другая — «UserGate Client + Management Center».
Внутренняя сеть компании (Trusted), в которой находится три машины:
с Active Directory, на ней же будут роли сервера Microsoft RADIUS NPS и центра сертификации Microsoft CA. Последний будет выпускать сертификаты для VPN-серверов и пользователей,
с Management Center, который мы позже опубликуем, чтобы UserGate Client из внешнего периметра мог в нем регистрироваться и получать какие-то централизованно настроенные параметры,
с Log Analyzer — это скорее бонусный сервер, на который будут отправляться логи о событиях с удаленных устройств пользователей.
Начинаем с сертификатов SSL
Технически для тестирования можно использовать сертификаты, которые несложно сгенерировать утилитой OpenSSL. Другой вариант — получить их от корпоративного центра сертификации Microsoft СА (Certificate Authority).
Первый вариант мы не рассматриваем совсем, так как его используют редко — сертификатами OpenSSL сложно управлять. Поэтому мы воспользовались вторым способом.
Сертификат сервера
На машине с Active Directory, которая является контроллером нашего домена nubes.lab, поднимаем роль Microsoft СА (Certificate Authority). Далее выпускаем сертификат по обычному сценарию.
Единственное, что мы сделали вне стандартной процедуры, — настроили DNS-записи. Добавили записи auth, block, logout, которые ведут на адрес интерфейса UserGate в зоне Trusted. Также создали записи для публикации Management Center (mc), VPN-адреса (vpn).
Во втором случае видим адрес внешнего интерфейса кластера UserGate — 192.168.0.254, через который мы потом будем публиковать Management Center и выстраивать к нему VPN-туннель с удаленных устройств пользователей из недоверенной зоны:
Для выпуска серверного сертификата нам понадобится шаблон Web Server (для пользовательского сертификата используется шаблон User).
Что здесь важно учесть? В свойствах шаблона указываем, что он предназначен для цифрового подписания (в поле Purpose стоит Signature and encryption).
Также видим роль нашего сервера — Server Authentication в поле Intended Purpose.
Предназначение шаблона User будет таким же, как и в случае с сервером, — цифровая подпись. Он нужен для выпуска сертификатов для аутентификации пользователей.
Нюанс. Если мы откроем в каждом из шаблонов вкладку Security, то увидим, что у аутентифицированных пользователей нет права на запрос сертификата. Чтобы запросить его, мы делегируем эту возможность какому-то аккаунту. Мы, например, разрешили делать запросы любому пользователю из нашего домена (через Active Directory). |
Далее переходим к локальному хранилищу сертификатов, где можно сделать прямой запрос на получение — опция доступна по щелчку правой кнопки мыши.
А дальше открывается окно, в котором пошагово выбираем Active Directory Enrollment Security — Web Server. Потом указываем все параметры, которые нам необходимы:
в Subject name: Type — Common name (обязательно для сертификата сервера), Value — vpn.nubes.lab (прописываем на свое усмотрение),
в Alternative name: Type — DNS, Value — vpn.nubes.lab. Здесь еще дополнительно завели ip-адрес внешнего интерфейса кластера UserGate — 192.168.0.254, о котором мы уже говорили выше.
Такая настройка позволит нам подключаться как по доменному имени, так и по ip-адресу.
Затем переходим на вкладку Private Key и указываем, что закрытый ключ для этого сертификата может быть экспортирован:
Теперь можно нажимать на Enroll. После этого закрываем окно запроса и видим наш сертификат в списке:
Далее его можно экспортировать. Обязательно делаем это с закрытым ключом и придумываем пароль для контейнера.
Также есть другой вариант — сделать запрос из консоли UserGate NGFW. Можно создать CSR и перенести его на центр сертификации. Далее там подписываем запрос, получаем открытый ключ и импортируем обратно в NGFW.
Сертификат пользователя
В Active Directory у нас есть два пользователя — User1 и User2. Именно с их устройств (машин) мы будем подключаться по VPN к NGFW.
Выпустим сертификаты для User1 и User2. Если у вас под рукой есть машина в домене, то запрос сертификата лучше делать на ней либо через веб-службу регистрации сертификатов. Но мы пошли другим путем — через хранилище сертификатов пользователей.
Открываем консоль под пользователями User1 и User2 по очереди и переходим в локальное хранилище сертификатов.
Далее делаем запрос на выпуск нового сертификата. Не забываем, что мы его делаем с помощью шаблона User:
Сертификат готов. В нем есть все поля, что нам нужны для дальнейшей настройки. Но на всякий случай стоит проверить поле SAN (Subject Alternative Name). В нем должны содержаться данные об email или VPN.
Точно так же выпускаем сертификат для другого пользователя. А затем экспортируем с закрытым ключом, прописываем пароль для контейнера и т.д.
Подключаем Microsoft NPS
Для чего это нужно + инструкция
Напомним, что для одного из серверов на контроллере домена мы установили роль Network Policy Server:
Этот статус позволяет нам повысить функционал сервера Active Directory, который будет выступать в качестве сервера RADIUS.
При этом у нас две ноды UserGate. А значит, в теории мы можем придумать общий пароль, чтобы его указывать для наших клиентов. И они будут при подключении и создании коннектора вводить этот пароль в соответствующих окнах.
Далее создаем два RADIUS-клиента, которые являются нодами нашего кластера. Назовем их UG-A и UG-B, укажем IP-адреса и возможность подключения по паролю, который установили на предыдущем шаге:
Точно так же создаем еще один объект — UG-VIP. Получаем такую картину:
Переходим к настройкам политик. Создаем политику VPN и указываем условия. Мы не стали сильно заморачиваться — указали только время суток.
Остальные параметры оставили по умолчанию. Единственное — настроили переопределение политик. Аутентификация пользователей в UserGate работает по протоколу EAP-MSCHAP v2.
Если вы планируете использовать мультифакторную аутентификацию по OTP-кодам, то также нужно будет поставить галочку напротив PAP.
Затем создадим политику сети. Назовем ее VPN. И далее возможны варианты. Например, мы можем снова указать время суток или выбрать группу пользователей. Такую же группу пользователей мы можем создать не только на стороне NPS-сервера, но и в настройках NGFW.
Мы остановились на варианте с временем суток. Далее выполняем те же действия, что и выше (указываем протоколы EAP-MSCHAP v2, PAP).
В итоге в списке политик получаем три записи:
Настраиваем NGFW
Сертификаты
У нас уже есть преднастроенная дефолтная инсталляция UserGate NGFW в режиме active backup кластера с двумя сетями (внешнего и внутреннего периметров). Виртуальные ip-адреса, указанные во вкладке «Управление устройством» соответствуют тем, что мы видим на нашей схеме тестового стенда — 10.0.0.1/24 и 192.168.0.254/24.
Далее идем импортировать выпущенный нами сертификат сервера. Подгружаем корневой открытый ключ центра сертификации (ROOT CA), который нужен для дальнейшей настройки.
Потом импортируем сертификат сервера VPN — называем его vpn.nubes.lab, подгружаем сам сертификат. Вводим пароль, который придумывали при экспорте, и сохраняем.
Проверяем: цепочка у сертификата vpn.nubes.lab есть, закрытый ключ — тоже. Смотрим Alternative name и видим то, что вводили при выпуске сертификата (DNS: vpn.nubes.lab, IP:192.168.0.254).
Затем переходим в раздел основных настроек и указываем, что сертификатом конечного устройства будет vpn.nubes.lab. Теперь он будет использоваться при общении между UserGate Client и NGFW.
Профили клиентских сертификатов
Следующим шагом создаем профиль клиентского сертификата. На основании этого профиля мы будем видеть сертификат для конечного пользователя и, забирая оттуда данные, проверять существование такого пользователя и его валидность.
Допустим, у нас есть сертификат, с участием которого мы будем осуществлять подключение по VPN к корпоративной инфраструктуре. В таком случае нужно указать атрибут, на который будем смотреть при валидации пользователя. У нас это Common-name.
В том же окне указываем открытый ключ центра сертификации, выпускающий сертификаты для наших пользователей.
Зоны
Указываем, что на внешней зоне, к которой мы будем подключаться с UserGate Client или с помощью нативного подключения, должен быть разрешен сервис VPN.
Этот шаг необходим для того, чтобы на NGFW можно было принимать запросы на построение туннелей.
Нюанс. Есть заблуждение, что если пользователь подключается с помощью сертификата, то никакое решение типа PAM или iDM не нужно. На практике мы увидели вот что: шлюз безопасности должен иметь коннект к базе всех пользователей. В ней должен быть пользователь, сертификат которого используется при подключении к VPN. В нашем случае шлюз безопасности идет в Active Directory и смотрит, есть ли там пользователь или нет. Если пользователя удалить, а его сертификат будет валидным, подключение не пройдет. |
Серверы аутентификации
Переходим к настройкам серверов аутентификации. Добавляем коннектор LDAP, называем его AD Nubes.lab, указываем его доменное имя, учетную запись и пароль:
В следующей вкладке указываем домен LDAP — nubes.lab. Остальное не меняем.
Дальше проверяем соединение. Получаем уведомление. Не пугаемся предупреждения о не заданном LDAP keytab (на наше тестирование эта история не влияет):
Далее добавляем RADIUS-сервер, задаем имя и добавляем секрет (тот самый PSK, что мы создавали для RADIUS ранее). Затем указываем IP-адрес контроллера домена и сохраняем.
Профили аутентификации
Здесь создаем профиль, называем его LDAP auth profile. В методах аутентификации выбираем Сервер LDAP/Active Directory: AD Nubes.lab.
Точно так же добавляем профиль RADIUS auth profile. Методом аутентификации в этом случае будет Сервер RADIUS: RADIUS Nubes.lab.
Нюанс. При настройке профиля RADIUS есть тонкий момент. После аутентификации пользователя на RADIUS требуется также проверить его в каталоге Active Directory. Для этого нужно добавить Сервер LDAP/Active Directory: AD Nubes.lab. |
UserID агент
Функция UserID дает нам прозрачную аутентификацию пользователей. Мы добавили коннектор к нему тоже, чтобы всегда можно было отследить логи.
Добавляем запись Microsoft Active Directory, указываем название, адрес сервера, пользователя (userid@nubes.lab) и его пароль. Затем выбираем наш профиль аутентификации LDAP, который отвечает за поиск по всему дереву данных о существовании пользователя.
Затем сохраняем и проверяем статус — зеленый (онлайн). Значит, все ок.
Серверный профиль аутентификации
На этом этапе плавно подходим к настройкам VPN. Но сначала включим правило VPN for Remote Access на межсетевом экране:
Теперь можно настраивать серверные профили безопасности. Открываем наш серверный профиль. В нем оформляем название, выбираем IKE версию:
В поле Сертификат сервера добавляем созданный ранее (vpn.nubes.lab). Далее определяем, каким методом будет происходить аутентификация пользователей: AAA (Microsoft NPS), PKI (по сертификату) или любой. Если выбираете второй или третий вариант, то вас также обяжут указать Профиль клиентского сертификата. Он у нас уже есть — VPN CN. В этом профиле решение будет просматривать сертификат Common-name и оттуда забирать данные о пользователе.
Далее переходим в Фазу 1. Меняем время жизни ключа, если это необходимо. Все остальное не редактируем, так как для тестирования это кажется излишним. По той же причине оставляем без изменений Фазу 2.
Сети VPN
По умолчанию здесь заготовлены две сети: для Remote Access и для соединения Site-to-Site.
Заходим в первую и видим диапазон ip-адресов, которые будут выдаваться клиентам. Также можем формировать список DNS, предоставляемых клиентам при подключении.
Там же можно настроить маршруты VPN и сплит-туннелинга. Соответствующие настройки мы нашли в третьей и четвертой (последней) вкладке.
Серверные правила VPN
Здесь снова видим два готовых правила: Remote Access и Site-to-Site. Для начала исправляем первое правило. Указываем необходимый профиль безопасности VPN (RA VPN profile), сеть VPN (RA VPN network), профиль аутентификации (RADIUS auth profile) и туннельный интерфейс (tunnel1 — он помещен в зону RA VPN).
В следующих вкладках указываем зону источника — Untrusted, а также пользователей, которые будут иметь доступ к этой зоне. Если вспомнить настройки политик на RADIUS-сервере, мы говорили о том, что будем учитывать временной интервал для запросов на аутентификацию.
Добавляем группу пользователей из Active Directory, в которую входят User1 и User2. Именно ее мы и будем использовать для подключения.
Правило готово. Оно гласит, что если мы подключаемся из внешней зоны, с любых адресов и на любой адрес назначения, то сможем строить туннель. Также в этом окне можно проверить, что все важные поля содержат все необходимые данные: профиль безопасности, сеть VPN и профили аутентификации. Если все перечисленное на месте, нажимаем «Включить».
Переходим к Management Center
Публикация Management Center
Сервер управления нужно публиковать в зону Untrusted, чтобы установленный на наших удаленных устройствах UserGate Client мог к нему обращаться через внешний интерфейс кластера UserGate NGFW.
При необходимости публикация может проводиться напрямую в интернет, о чем мы расскажем далее. Но в целом делать это необязательно. Решение зависит от конкретного сценария.
Публикация проводится двумя сервисами — через порты 9712 и 4045. Первый — TCP-порт, который необходим для обмена ключами шифрования и нужен при первоначальной регистрации клиента на сервере Management Center. На его основе потом будет построено безопасное общение UserGate Client с Management Center через порт 4045. По нему направляются данные телеметрии и приходят централизованные политики со стороны Management Center.
Для публикации создаем правило DNAT на NGFW (раздел NAT и маршрутизация). Называем его DNAT MC, указываем источник — зону Untrusted. В назначение добавляем внешний интерфейс UserGate (192.168.0.254).
Далее во вкладке Сервисы добавляем сервисы tcp_9712 и tcp_4045, которые мы заготовили ранее.
Также, чтобы можно было принимать логи, сервер управления нуждается в общении по порту tcp_22000. Добавляем и его. Теперь при установлении безопасного обмена данными каждый UserGate Client будет отправлять логи в Management Center через порт tcp_22000.
Далее прописываем адрес назначения DNAT — 10.0.0.10 (Management Center). Сохраняем правило и видим такую запись:
Установка UserGate Client в режиме NGFW
Переходим к настройкам конечной машины. Напомним, что у нас в схеме их две: на одной UserGate Client будет работать в режиме NGFW, на другой — в режиме Management Center. Первая называется UG-Cl-1, вторая — UG-Cl-2.
Начнем с UG-Cl-1. Мы заранее перенесли сюда дистрибутив UserGate Client и клиентские сертификаты, которые были добавлены в локальное хранилище:
Нюанс. Для установки UserGate Client нам пришлось перевести машину в тестовый режим. Это необходимо сделать, чтобы не запускалась проверка подписей драйверов на ОС. Без такой манипуляции текущая версия UserGate Client работать пока не будет. |
Запускаем инсталляцию с дистрибутива. В процессе появляется окно такого вида:
От нас требуют ввести IP-адрес либо доменное имя, которое будет вести на Management Center. А еще там есть некий Device code — персональный код устройства, о котором поговорим чуть позже.
Так как мы подключаем машину в режиме NGFW, связка с Management Center не нужна — нажимаем Cancel. Далее инсталляция закончится, после чего нужно будет перезагрузить машину.
После загрузки операционной системы мы видим, что появился значок нового приложения:
Далее проверяем все сетевые параметры:
Какую IPv4-адресацию мы получаем на нашем клиенте? Видим — 192.168.0.111 из зоны Untrusted. Основным шлюзом у нас является оператор, при этом DNS-сервер указан — и это внешний интерфейс UserGate (192.168.0.254).
Возможно, это не совсем корректная настройка. Но мы сделали так намеренно, потому что домен nubes.lab не публичный. И чтобы не делать костыли с host-файлами и не плодить сторонние DNS-сервера, мы обошлись NGFW. Именно межсетевой экран будет разрешать имена согласно параметрам, которые в нем настроены с участием Active Directory.
Итак, VPN-клиент установлен. А значит, мы можем осуществлять подключение. В поле VPN server мы вводим его доменное имя — vpn.nubes.lab. Поле Passphrase мы оставляем пустым. Его необходимо использовать, если нам нужно подключение по протоколу L2TP\IPsec.
Далее жмем Connect и выбираем метода аутентификации, которым будем пользоваться при подключении. Вариантов, как вы помните, два: логин/пароль или сертификат (наш случай).
Далее видим те самые сертификаты, которые уже есть. На этом шаге можем изменить их, если это необходимо. Дожидаемся самого подключения. Вот и оно:
Подключение установлено, нам выдали туннельный адрес из пула сети VPN.
Установка UserGate Client в режиме Management Center
Переключаемся на машину UG-CL-2, которая находится во внешней сети. Выясняем, корректно ли мы настроили публикацию Management Center. Проверяем по портам 9712 и 4045.
Переходим к установке. Снова видим всплывающее окно. Вводим доменное имя нашего Management Center и код устройства.
Где взять код устройства? Идем в управляемую область Management Center и смотрим добавленные устройства, выбираем нужное и просим показать уникальный код:
Если код введен верно, то получаем сообщение об успешной регистрации. Завершаем инсталляцию и перезагружаем машину.
В это время в Management Center мы видим, что устройство действительно зарегистрировано и пока еще не подключено. Статус говорит, что на самом деле машина еще перезагружается либо служба UserGate Client пока не запустилась.
После перезагрузки и запуска службы мы видим окно, в котором нам предлагают выбрать VPN-сервер. Но вариантов на этом этапе пока не будет.
Поэтому идем в Management Center. Здесь выясняем, что пользовательское устройство подключено, идет сбор данных телеметрии.
Также отсюда мы можем посмотреть всю информацию о хосте и выполнять различные действия, в том числе управлять автозапуском приложений, завершать работу запущенных служб и т.д.
Настройка VPN
Чтобы настроить сервер VPN средствами Management Center, переключаемся на вкладку «Конечные устройства — конфигурация». Затем в меню слева выбираем пункт «Настройка VPN».
Далее добавляем нужные нам параметры. Указываем название подключения — vpn.nubes.lab c пометкой PKI, так как мы будем использовать в данном случае пользовательский сертификат. Вводим адрес VPN-сервера, который указан в сертификате.
Затем выбираем протокол — IKEv2 c сертификатом. Заполняем Фазу 1 и Фазу 2, если это необходимо.
Сохраненную настройку мы увидим на удаленном устройстве спустя 10 секунд:
Таким же образом настроим подключение через логин-пароль (vpn.nubes.lab c пометкой ААА). Единственное отличие здесь будет в протоколе — выбираем IKEv2 с именем и паролем.
Затем идем в локальное хранилище сертификатов. Проверяем, что нужные нам пользовательские сертификаты на месте. Они должны быть с закрытым ключом.
Важный момент: лучше еще заглянуть в путь сертификации. Вся цепочка и корневой сертификат должны находиться на конечной машине.
Переходим к тестированию подключения. Сначала выбираем вариант с сертификатом. Затем указываем, что сертификат используем из локального хранилища:
Далее выбираем нужный сертификат из предложенных и видим, что подключение прошло успешно:
Затем тестируем подключение с логином-паролем. Заодно проверяем, есть ли записи с активными пользователями в NGFW:
Также на этом этапе можно протестировать, сохраняются ли логи в Журнале трафика:
Проверяем, считал ли UserID необходимые данные об аутентификации пользователя при его подключении. Да, все ок.
Настройка политик сети
Рассмотрим ограничения доступа на конечной машине с установленным UserGate Client к конкретным ресурсам в публичных сетях. Создадим такое правило для веб-почты на межсетевом экране. Называем его, выбираем область применения: везде, внутри периметра (в корпоративной сети, когда доменная машина подключается по VPN) или снаружи (подключение с недоменной машины).
Дальше выбираем действие «Запретить». Если нужно, то можно указать необходимость записывания логов и определить позицию правила в общем списке правил доступа.
Дальше можно настроить остальные параметры, в том числе на каких пользователей распространяется правило, а также выбрать сервис (в нашем случае https), категорию URL (Веб-почта), устройства и т.д.
Правило создано. Теперь оно отражается во вкладке «Межсетевой экран»:
Далее переходим на виртуальную машину пользователя. Там открываем браузер, пытаемся залогиниться в запрещенном веб-ресурсе:
Запрет, как видите, срабатывает даже без режима VPN. Появляется уведомление. В нем указано, по какому именно правилу пользователь не может посетить данный ресурс.
Логирование событий
Для этой задачи мы развернули виртуальную машину с SIEM. Сформировали шаблоны и группы шаблонов для Log Analyzer и SIEM, а также добавили новое устройство и подключили SIEM к Management Center.
А теперь пройдем шаги вместе. Сначала создаем шаблон — SIEM template.
Далее создаем группу шаблонов — SIEM group template. Добавляем в него наш шаблон:
Идем в SIEM, открываем настройки. В интерфейсах видим зону Management с портом 10.0.0.9.
В Зонах выбираем запись Management. Проверяем, разрешен ли необходимый нам сервис (Log Analyzer):
Потом переходим в Management Center. Добавляем устройство SIEM, выбираем группу шаблонов — SIEM group template, а также тип синхронизации:
Переходим во вкладку Действия:
Выбираем «Показать уникальный код устройства», копируем его. Идем в SIEM, ищем настройку агента Management Center. В открывшемся окне вбиваем ip-адрес Management Center и код устройства. Обновляем.
Видим справа внизу, что агент подключен:
В данных об устройстве в Management Center теперь отображается информация о подключенной SIEM.
На этом этапе мы уже можем настроить отправку журналов логирования с UserGate Client на Management Center c доставкой в SIEM. Переключаемся в основной блок настроек конечного устройства.
Справа в Устройствах LogAn выбираем SIEM и ставим галочку напротив «Синхронизировать». Другие настройки менять здесь не будем.
Теперь можно протестировать всю эту связку в работе. Создаем правило, которое разрешает всё и всем. Выглядит оно так:
Дальше переключаемся на одну из наших конечных машин и имитируем бурную активность в браузере. Чтобы посмотреть логи, переходим в SIEM — в журнал правил конечного устройства. Здесь видим, как работают оба правила:
Первое впечатление
Если сравнивать с другими решениями Remote Access VPN, то UserGate Client — неплохой представитель своего класса. Тем не менее, в процессе настройки и тестирования мы столкнулись с десятком нюансов. О некоторых сказали ранее, но самый важный оставили напоследок.
Нюанс. Мы взяли на изучение версию продукта, которая еще только планируется к выходу на рынок. Чтобы протестировать функционал, пришлось переводить Windows в тестовый режим. Как именно UserGate Client будет показывать себя в боевом режиме, говорить пока рано. Также рано судить о том, какой именно функционал из нашей версии попадет в предстоящий релиз. |
На этом моменте мы завершаем обзор, но не прощаемся. Продукт меняется, а это значит, что уже скоро мы можем вернуться и рассказать о VPN-клиенте что-то еще :)