Привет, я занимаюсь проектированием, внедрением и тестированием средств защиты информации в Т1 Интеграция.
Как сейчас при отсутствии всяких Palo Alto и прочих Cisco ASA организовать удалённый доступ пользователей в офис небольшой компании, да ещё и недорого? А ещё лучше бесплатно, ну или почти бесплатно. Вот и к нам прилетела такая задача, и первое, что приходит на ум, это использовать действующее оборудование. Рассмотрев имеющийся парк, мы выбрали UserGate. Такая функциональность там заявлена, а наличие сертификата ФСБ, подтверждающего возможности СКЗИ, на тот момент не требовалось. Перед началом внедрения, естественно, надо проверить, как работает многофакторная аутентификация в связке с VPN и какие опции доступны, как это интегрировать.
Сказано — сделано: в лаборатории организовали вот такой стенд:
Порядок проверки был такой:
настраиваем аутентификацию пользователей через AD;
настраиваем VPN;
настраиваем Captive portal;
подключаем второй фактор через TOTP.
Для начала настраиваем подключение к AD. Для этого создаём пользователя ldapconnector в нашем домене lab.local. Пользователь должен быть членом группы Domain Users. Поскольку аккаунт технологический, настраиваем также опции «User cannot change password» и «Password never expires».
Далее в разделе «Пользователи и устройства» создаём сервер аутентификации AD или используем тот, что есть по умолчанию, и в нём для подключения к AD вводим параметры нашего пользователя в формате «ДОМЕН\имя пользователя и его пароль»:
На вкладке «Домены LDAP» надо указать домен, в моём случае это lab.local. На вкладке «Kerberos keytab» необходимо загрузить keytab‑файл. Для его генерации создайте ещё одного пользователя, отличного от ldapconnector, я буду использовать тестовое имя kerb. И после этого при помощи команды сгенерируем на нашем AD‑сервер keytab‑файл. Обратите внимание, что команда чувствительна к регистру, и там, где значение LAB.LOCAL указано в ВЕРХНЕМ РЕГИСТРЕ, так и должно быть:
После загрузки keytab‑файла, можно нажать «проверить соединение» и убедиться в наличии связности с AD:
Клиент на стенде подключается со стороны внешнего интерфейса, то есть со стороны зоны Untrusted надо разрешить в ней работу VPN:
Как и на большинстве современных NGFW, зона — это просто группа интерфейсов, к которой можно применять политики и в которой можно настраивать сервисы. Для прерывания пользователей VPN создаётся отдельный туннельный интерфейс, который мы поместим в отдельную зону VPN for remote access в разделе «Сеть» — «Интерфейсы»:
Подсеть 10.5.5.0/24 — это та подсеть, из которой мы будем выдавать адрес удалённым пользователям.
Чтобы пользователи из VPN for remote access могли ходить в другие зоны, например, к разрешённым ресурсам в зоне Trusted, необходимо создать правило межсетевого экранирования:
В моём случае доступ разрешён из VPN к внутренним ресурсам в сети 10.1.1.0/24. Далее создаём профиль безопасности VPN в разделе «VPN» — «Серверные профили». По умолчанию уже существует профиль Remote access VPN‑profile, будем использовать его:
Для проверки достаточно выбрать протокол IKE2 и задать общий ключ, тот который обычно «preshared», остальные настройки как на рисунке.
Создадим профиль аутентификации RAVPN в разделе «Пользователи и устройства» — «Профили аутентификации»:
На этом этапе профиль MFA пока не используем, подключим его после проверки RA VPN:
На вкладке «Методы аутентификации» добавим ранее созданный нами сервер AD:
Создадим VPN‑сеть в разделе «VPN» — «Сети VPN». Я назову её RAVPN_Net2, но название может быть любым. Здесь зададим желаемый диапазон адресов для удалённых пользователей. Важно, чтобы он был из той же сети, что и VPN‑интерфейс:
Укажем маршруты к приватным сетям, все остальные маршруты в моей сети более узкие или находятся в интернете, поэтому я могу себе такое позволить. В проде, конечно, надо указывать точнее. Маршруты для UserGate Client не задаю, потому что подключение планируется нативным клиентом Windows:
Далее создаем серверное правило Remote access VPN rule, в нём связываем воедино профиль безопасности, сеть VPN, профиль аутентификации и туннельный интерфейс:
>
Зона источника — Untrusted, назначение — адреса на которых разрешено терминировать VPN-подключения , пользователей добавляем из AD, в моём случае это пользователь userovich:
Всё, теперь можно тестировать подключение с компьютера пользователя:
Для аутентификации пользователя указываем протокол PAP, имя пользователя указываем в формате userovich@lab.local:
Так, VPN заработал, осталось прикрутить 2FA. В качестве второго фактора я буду использовать бесплатный клиент FreeOTP для Android. Чтобы его инициализировать, нам потребуется настроить Captive‑портал. Для этого создаём Captive‑профиль со следующими настройками:
На вкладке «Регистрация новых пользователей» оставляем настройки по умолчанию:
В Captive-портале добавляем созданный Captive-профиль:
В зоне источника указываем VPN for remote access:
В назначении — целевая зона Trusted:
Остальные настройки не меняем.
Необходимо также создать профиль TOTP, в котором надо указать, как инициализировать TOTP, и что требуется показать QR‑код:
Теперь в профиле аутентификации укажем профиль MFA:
Метод аутентификации остаётся прежним — через AD.
Для инициализации TOPT необходимо на компьютере клиента, при включённом VPN, перейти по ссылке:
Необходимо дождаться сообщения, что сертификат недоверенный:
После этого введите логин и пароль в нужном формате и отсканируйте QR‑код в приложении:
Всё, можно пользоваться, но надо помнить, что теперь при аутентификации в VPN надо вводить пароль пользователя в формате: Password:otp_code, где otp_code — 6 цифр из приложения, которые будут динамически изменяться при каждом подключении.