Защита SSL VPN одноразовыми паролями и взаимной аутентификацией с WiKID

Краткое пояснение проблемы

SSL VPN изначально проектировались для упрощения конфигурации на клиентских ПК. Однако распространение общественных Wi‑Fi увеличило риск атак «человек посередине» (MITM). Злоумышленник может перехватить SSL‑трафик и повторно использовать одноразовый пароль, введённый пользователем, в момент соединения. Чтобы исключить такую возможность, требуется взаимная (двусторонняя) аутентификация: сервер подтверждает личность клиента, а клиент — подлинность сервера.

Определение. Взаимная аутентификация — это режим, при котором обе стороны соединения предъявляют аутентификационные доказательства друг другу (например, серверный сертификат и одноразовый пароль с подтверждением сервера).

Важно: простая двухфакторная схема, в которой токен только генерирует OTP локально, не защищает от активного MITM без гарантии подлинности сервера.

Почему WiKID вместо клиентских сертификатов

Коротко:

• Централизованная база пользователей для разных сервисов (SSL VPN, OpenVPN, SSH и т.д.).
• Серверная проверка PIN делает систему более устойчивой к пассивному подбору.
• Упрощённое управление — отсутствие необходимости в CRL и сложной инфраструктуре PKI.
• Удобство для администраторов при массовом управлении токенами и восстановлении доступа.

Когда WI KID уступает: если в вашей организации уже развёрнута зрелая PKI с автоматической выдачей и управлением клиентских сертификатов, и вы готовы администрировать CRL/OCSP — клиентские сертификаты остаются жизнеспособным решением.

Предпосылки

• Рабочие SSL‑Explorer и WiKID сервера (виртуальные машины VMware используются для примера).
• Сеть и DNS настроены; у вас есть доступ к веб‑интерфейсам обоих серверов.
• Права администратора на WiKID и на SSL VPN сервер.

План действий

1. Добавить домен в WiKID.
2. Создать сетевого клиента (Network Client).
3. Добавить и зарегистрировать пользователя.
4. Протестировать сценарии успешного и неуспешного входа.
5. Внедрить контрольные и аварийные процедуры.

Настройка сервера WiKID

Добавление домена в WiKID

В веб‑админке WiKID перейдите на вкладку Domains и нажмите Create New Domain. Введите имя домена для шлюза и имя устройства — оно появится на токене. В поле Registered URL укажите URL SSL VPN сервера, начиная с https://, чтобы WiKID мог получить сертификат удалённого VPN.

Параметр «server code» заполняется маршрутизируемым IP адресом WiKID в нулёво‑падовом формате (пример: 10.1.1.1 -> 010001001001). Настройте длину PIN и остальные параметры по политике безопасности — короткий PIN повышает удобство, длинный — теоретически безопасность.

Советы по конфигурации:

• Указывайте корректный Registered URL с https://.
• Проверьте, что WiKID имеет сетевой доступ к указанному URL для получения сертификата.
• Документируйте server code и храните его в конфигурации шлюза.

Создание сетевого клиента

После сохранения домена перейдите на вкладку Network Client и нажмите Create New Network Client. Укажите имя клиента и IP адрес SSL VPN сервера во внутренней сети. В протоколе выберите Radius и привяжите созданный домен.

Проверьте секрет RADIUS между WiKID и SSL VPN. Он должен быть одинаков на обоих концах. Ограничьте IP‑допуск до RADIUS сервера на стороне VPN для дополнительной защиты.

Добавление пользователя и регистрация токена

Если пользователей много, используйте автоматическую интеграцию с Active Directory через прилагаемые скрипты (ASP, Java, Python, PHP, Ruby). Для простоты мы рассмотрим ручную регистрацию.

1. Установите WiKID PC token client на рабочую станцию пользователя.
2. При первом запуске клиент попросит создать фразу‑ключ.
3. В клиенте выберите Actions → Create New Domain и введите 12‑значный идентификатор домена. Публичный ключ токена отправится на сервер WiKID.
4. Введите и подтвердите PIN.

После отправки сервер вернёт код регистрации, который нужно вручную подтвердить в веб‑интерфейсе WiKID.

На сервере WiKID: Users → Manually Validate A User, выберите Registration Code и назначьте имя пользователя.

После ручной валидации учётная запись активируется. Пользователь вводит PIN в токене и получает одноразовый пароль, который будет автоматически скопирован в буфер обмена и перенаправит браузер на Registered URL.

Что ожидать при работе и при ошибках

Ожидаемое поведение при успешном соединении:

• Пользователь запускает токен-клиент и выбирает домен.
• Вводит PIN, получает OTP.
• Браузер автоматически открывает Registered URL и устанавливает SSL‑соединение.
• WiKID проверяет OTP и возвращает успех по RADIUS.

Типичные ошибки и их устранение:

• «Нет соединения с RADIUS» — проверьте секрет, ACL, доступ по сети и порт 1812.
• «Серверный сертификат не получен» — убедитесь, что указали https:// в Registered URL и что WiKID может подключиться к VPN.
• «Код регистрации неверен» — проверьте правильность 12‑значного идентификатора домена и повторите процедуру регистрации токена.
• «OTP принимается злоумышленником» — это симптом отсутствия взаимной аутентификации: проверьте, что клиент проверяет серверный сертификат и что Registered URL совпадает с ожидаемым адресом.

Технические рекомендации по безопасности

• Ограничьте доступ к WiKID‑API и административному интерфейсу по IP и VPN.
• Используйте сильные случайные секреты RADIUS.
• Логируйте неудачные попытки входа и настраивайте оповещения.
• Планируйте процедуру отзыва устройств и PIN‑смены при компрометации.

Примечание: серверная проверка PIN снижает риск пассивного перебора. Но при компрометации учётной записи администрация должна иметь быстро выполнимый план отзыва.

Альтернативные подходы и когда они подходят

• Клиентские сертификаты: подходят при зрелой PKI и строгом контроле рабочих станций.
• Push‑уведомления на смартфон: удобны, но зависят от доступности мобильной сети и устойчивы к фишингу не всегда.
• Hardware tokens (апплеты): повышают физическую стойкость, но сложнее в управлении при большом количестве пользователей.

Мини‑эвристика для выбора: если вам нужна централизованная проверка PIN и поддержка разных сервисов — выбирайте WiKID. Если требуется массовая автораздача сертификатов и вы готовы поддерживать CRL/OCSP — выбирайте PKI.

Контрольный список для внедрения

Администратор сети:

• Настроил домен в WiKID и сохранил server code.
• Создал Network Client с протоколом RADIUS и проверил секрет.
• Ограничил доступ к RADIUS по IP и портам.
• Настроил логирование и оповещения по неудачным логинам.

Администратор безопасности:

• Провёл оценку риска MITM и утвердил политику PIN.
• Подготовил процедуру отзыва токенов и смены PIN.
• Провёл обучение конечных пользователей по проверке Registered URL.

Пользователь:

• Установил токен‑клиент и создал фразу‑ключ.
• Зарегистрировал домен и завершил валидацию в WiKIDAdmin.
• Отработал сценарий входа и восстановления доступа.

Критерии приёмки

• Все тестовые пользователи успешно проходят аутентификацию через WiKID и подключаются к SSL VPN.
• Неуспешные попытки блокируются и заносятся в лог с причинами.
• Процедуры отзыва и восстановления протестированы и документированы.

Мини‑методология развёртывания

1. Подготовка тестовой среды с 2–3 пользователями.
2. Настройка домена и сетевого клиента в WiKID.
3. Регистрация и валидация токенов.
4. Тестирование успешного и отрицательного сценариев.
5. Переход в производство по слоям с контролируемым откатом.

Быстрая схема принятия решений

flowchart TD
  A[Начать развёртывание] --> B{Есть ли PKI?}
  B -- Да --> C[Оценить существующую PKI и управляемость]
  B -- Нет --> D[Использовать WiKID]
  C --> E{PKI зрелая}
  E -- Да --> F[Использовать клиентские сертификаты или гибрид]
  E -- Нет --> D
  D --> G[Настроить домен, RADIUS, регистрацию токенов]
  G --> H[Тестирование]
  H --> I[Внедрение]

Тестовые сценарии и приёмка

• Тест 1: Пользователь с правильным PIN получает OTP и подключается. Ожидается успешный RADIUS Access‑Accept.
• Тест 2: Пользователь вводит неверный PIN → сервер возвращает Access‑Reject и запись появляется в логах.
• Тест 3: Попытка подключения через MITM‑прокси, подменяющий сертификат сервера. Клиент должен отказать в соединении, если Registered URL или сертификат не совпадают.

Рекомендации по эксплуатации и откату

• Храните резервные учётные записи администратора вне WiKID с ограниченным доступом.
• Тестируйте процедуру отката: отключите RADIUS на WiKID и проверьте, что у вас есть запасной способ аутентификации.
• Планируйте регулярные ревизии зарегистрированных доменов и списков сетевых клиентов.

Итог

Взаимная аутентификация с одноразовыми паролями, реализованная через WiKID и интегрированная с SSL‑Explorer по RADIUS, значительно повышает безопасность соединения и закрывает класс атак MITM, характерный для общественных сетей. Эта схема даёт централизованное управление, отказоустойчивость и упрощает поддержку нескольких типов удалённого доступа.

Ключевые действия: настроить домен и сетевого клиента в WiKID, зарегистрировать и вручную валидаировать токены, протестировать позитивные и негативные сценарии, внедрить мониторинг и процедуру отзыва.

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