Двухфакторная аутентификация RADIUS для межсетевых экранов — Контур.Эгида

В этой статье

Двухфакторная аутентификация RADIUS для межсетевых экранов

16 марта 2026

В инфраструктуре, где используется несколько межсетевых экранов, компрометация одной административной учетной записи может привести к полной потере контроля над сетевой политикой. В этой статье разберем архитектурно корректный подход — централизацию доступа через RADIUS с обязательной двухфакторной аутентификацией. Расскажем, как объединить Cisco, Palo Alto, UserGate и другие устройства под единой политикой безопасности и при этом сохранить управляемость системы.

Фотография Дмитрий Мельников Дмитрий Мельников Руководитель группы

Зачем нужна 2FA через RADIUS для межсетевого экрана

Межсетевой экран, или firewall — это не просто элемент инфраструктуры. Через него проходят все правила доступа, маршрутизация трафика и удаленные подключения. Доступ к его административной панели означает контроль над всей сетевой политикой компании.

Во многих инфраструктурах административный доступ к межсетевому экрану осуществляется через локальную учетную запись устройства — по логину и паролю, без второго фактора. Такой подход создает очевидные риски:

  • пароль можно перехватить через фишинг;
  • его могут подобрать при слабой политике сложности;
  • он может «утечь» вместе с другими учетными данными;
  • один и тот же пароль часто используется в разных системах.

Если пароль скомпрометирован, защита периметра перестает работать. Злоумышленник может изменить настройки, отключить правила безопасности или создать скрытый доступ.

Двухфакторная аутентификация через RADIUS решает эту проблему на архитектурном уровне. Вместо проверки учетных данных только средствами самого устройства межсетевой экран может передавать запрос на внешний сервер аутентификации — например, через RADIUS. В этом случае проверка выполняется централизованно, а не только на стороне самого устройства. Пользователь вводит логин и пароль, а затем подтверждает вход вторым фактором — одноразовым кодом или push-уведомлением. Только после этого система разрешает доступ.

2FA для межсетевого экрана: одноразовые коды

Самый распространенный вариант второго фактора — одноразовые коды (OTP), которые генерируются в приложении на смартфоне. Обычно используется алгоритм TOTP: код действует ограниченное время и меняется каждые 30 секунд.

Сценарий работы выглядит так:

  1. Администратор вводит логин и пароль.
  2. Межсетевой экран отправляет запрос на сервер RADIUS.
  3. Сервер проверяет учетные данные — чаще всего через Active Directory.
  4. Пользователь вводит одноразовый код.
  5. После успешной проверки доступ разрешается.

Даже если пароль стал известен злоумышленнику, без второго фактора он не сможет пройти аутентификацию. Повторно использовать перехваченный код тоже нельзя — он быстро устаревает.

Важно понимать разницу между встроенной двухфакторной защитой конкретного устройства и централизованной схемой через RADIUS. В первом случае настройки привязаны к одному фаерволу. Во втором — создается единая модель авторизации, которую можно применить сразу ко всем межсетевым экранам и VPN-шлюзам в компании.

Настройка Windows NPS: RADIUS 2FA

Во многих инфраструктурах уже используется Windows Server с ролью NPS (Network Policy Server). Он работает как RADIUS-сервер: принимает запросы от VPN, Wi-Fi или сетевого оборудования и проверяет учетные данные через Active Directory. Поэтому идея добавить к нему двухфакторную аутентификацию для межсетевого экрана выглядит логичной.

Как добавить 2FA в Windows NPS

Сам по себе NPS не умеет работать с одноразовыми кодами (OTP). Чтобы добавить второй фактор, нужны сторонние расширения или интеграция с внешним сервисом. Это ведет к проблемам:

  • установка и совместимость дополнительных компонентов;
  • сбои после обновлений Windows Server;
  • ограниченный аудит и слабая гибкость.

При масштабировании поддержка такой схемы становится трудоемкой: каждое изменение политики требует проверки всей цепочки. Поэтому для 2FA часто выбирают отдельный сервер с нативной поддержкой двухфакторной модели, а не доработку NPS.

Active Directory и RADIUS: настройка интеграции

Active Directory — единый источник учетных записей и прав. Связка AD + RADIUS 2FA позволяет:

  • централизованно управлять доступом к межсетевым экранам;
  • разграничивать права и быстро отзывать доступ при увольнении.

При этом важно понимать: второй фактор усиливает защиту, но не исправляет ошибки разграничения прав. Если у администратора избыточные привилегии в AD, 2FA этого не изменит.

Правильная схема:

  1. В AD назначаются учетные записи и права.
  2. Firewall передает запрос на RADIUS-сервер.
  3. RADIUS-сервер проверяет пароль и второй фактор.
  4. Решение об авторизации принимается централизованно.

Это делает управление доступом предсказуемым и контролируемым.

Интеграция с популярными межсетевыми экранами

Независимо от вендора, межсетевой экран делегирует проверку учетных данных внешнему серверу. Второй фактор делает бесполезной кражу одного только пароля.

Принцип один для всех: настроенный RADIUS-сервер становится внешним арбитром, который проверяет пароль и второй фактор. Firewall только передает ему запрос и получает ответ: доступ разрешен или нет. Разница — в интерфейсах и деталях. 

Ниже — краткие инструкции для трех самых распространенных платформ.

Cisco ASA

RADIUS на Cisco ASA защищает админ-доступ, VPN-подключения и удаленный вход в сегменты сети. Что сделать:

  1. Добавить внешний RADIUS-сервер в конфигурацию.
  2. Настроить политики аутентификации для административного интерфейса и/или VPN.
  3. Убедиться, что при входе запрос действительно уходит на RADIUS и требует второй фактор.

С точки зрения безопасности важно:

  • отключить локальные учетные записи администратора (или оставить только как аварийные);
  • ограничить по сети доступ к админке;
  • настроить централизованное логирование попыток входа.

Для Cisco ASA неважно, какой именно второй фактор используется — для него это просто ответ «accept» или «reject».

Palo Alto

Настройка идет через профиль аутентификации, где указывается внешний RADIUS-сервер. Сценарий:

  1. Администратор заходит в веб-интерфейс или CLI;
  2. Palo Alto отправляет запрос на RADIUS;
  3. Сервер проверяет пароль и второй фактор, возвращает результат.

Ключевые моменты:

  • разграничьте роли через группы Active Directory — даже с 2FA не давайте всем полный доступ;
  • 2FA через RADIUS можно применить и к GlobalProtect для защиты VPN.

FortiGate

Внешний RADIUS подключается в разделе User & Authentication, после чего назначается для входа администраторов, SSL-VPN и IPsec VPN.

Ключевые моменты:

  • при использовании OTP правильно настройте таймауты;
  • предусмотрите резервный RADIUS-сервер;
  • протестируйте сценарий отказа: что будет, если RADIUS недоступен.

Если в компании несколько FortiGate, централизованная 2FA через RADIUS позволяет задать политику один раз и применять ко всем устройствам.

Настройка 2FA на UserGate

UserGate и Kerio Control часто используются в сегменте среднего бизнеса: в филиалах, распределенных офисах, образовательных и коммерческих организациях. В таких инфраструктурах администрирование нередко ведется удаленно, и это означает, что защита административного входа без двухфакторной аутентификации становится прямым риском.

UserGate: аутентификация через RADIUS с 2FA

UserGate поддерживает подключение внешнего RADIUS-сервера для проверки учетных данных. Это позволяет отказаться от локальных паролей и централизовать авторизацию.

Пример сценария:

  • администратор или пользователь VPN вводит логин и пароль;
  • UserGate отправляет запрос на RADIUS-сервер;
  • сервер проверяет данные (например, через Active Directory);
  • дополнительно запрашивается второй фактор — одноразовый код или подтверждение входа;
  • при успешной проверке доступ разрешается.

С точки зрения информационной безопасности важно учитывать несколько моментов.

Во-первых, если в системе остаются локальные учетные записи администратора, они должны быть либо отключены, либо защищены отдельно и использоваться только для аварийного входа. Иначе двухфакторную модель легко будет обойти.

Во-вторых, необходимо ограничить доступ к административному интерфейсу по IP или через отдельный управляемый сегмент. 2FA снижает риск компрометации, но не отменяет требования к сетевой изоляции.

В-третьих, стоит проверить, что все попытки входа логируются централизованно. При использовании RADIUS это обычно возможно — события авторизации фиксируются на стороне сервера аутентификации.

Какой второй фактор выбрать: сравниваем методы

Когда межсетевой экран передает аутентификацию на RADIUS-сервер, следующий вопрос — какой именно второй фактор использовать. От этого зависит не только удобство администраторов, но и реальная защита от взлома. В корпоративной среде чаще всего применяются четыре варианта: TOTP-коды, push-уведомления, SMS и аппаратные токены. Разберем плюсы и минусы каждого.

TOTP-приложения: проверенный стандарт

Самый распространенный вариант — одноразовые коды по алгоритму TOTP, которые генерируют мобильные приложения (например, Контур.Коннект или аналоги). При привязке устройства приложение настраивается для генерации временных одноразовых кодов (TOTP). Алгоритм использует общий секрет и текущее время, поэтому приложение и сервер аутентификации могут генерировать одинаковые шестизначные коды, которые обычно меняются каждые 30 секунд и используются при входе.

Плюсы:

  • не требует интернета;
  • код быстро устаревает, повторно использовать нельзя;
  • легко масштабируется на сотни сотрудников.

Минусы:

  • код можно ввести на фишинговом сайте (нет привязки к контексту входа);
  • нужно аккуратно управлять секретами и восстановлением доступа при потере телефона.

Push-уведомления: удобно и безопасно

Push-аутентификация считается более устойчивой к фишингу: пользователь получает уведомление в приложении и подтверждает вход одним касанием, не вводя код.

Плюсы:

  • не нужно вводить одноразовый код вручную;
  • перехватить push сложнее, чем одноразовый код.

Минусы:

  • требуется интернет на смартфоне;
  • возможны атаки с «заспамливанием» запросами, если не настроена защита.

Для администраторов, которые часто работают удаленно, push-подтверждение часто удобнее и безопаснее обычных кодов.

SMS-коды: вариант на крайний случай

SMS с кодом до сих пор встречается, но с точки зрения безопасности это самый слабый вариант.

Минусы:

  • перехват через уязвимости мобильных сетей;
  • замена SIM-карты;
  • зависимость от оператора связи.

RADIUS-сервер: настройка двухфакторной аутентификации и требования к архитектуре

Независимо от того, подключаете ли вы Cisco, MikroTik, Check Point или другой межсетевой экран, сама по себе настройка 2FA через RADIUS — это только часть задачи. Важно, как выстроена вся архитектура.

Есть несколько моментов, которые критичны для безопасности:

  • Во-первых, сервер аутентификации не должен быть единственной точкой отказа. Если он недоступен, вы либо потеряете административный доступ, либо, что хуже, устройство переключится на локальные учетные записи без второго фактора. Поэтому резервирование RADIUS-сервера — обязательное требование.
  • Во-вторых, соединение между межсетевым экраном и сервером аутентификации должно быть доступно только из доверенной сети и защищено на уровне протокола. Например, при использовании RADIUS желательно применять защищенные протоколы аутентификации, такие как MSCHAPv2.
  • В-третьих, локальные администраторы на самом firewall должны быть либо отключены, либо использоваться только как аварийный доступ с отдельным регламентом хранения паролей. Иначе двухэтапная схема легко обходится.

Отдельно стоит продумать аудит. Все попытки входа — успешные и неуспешные — должны фиксироваться централизованно. Это позволяет выявлять перебор паролей, аномальные входы и попытки атаки на админ-доступ.

И, наконец, обязательно нужно тестировать сценарии отказа: что происходит, если сервер аутентификации недоступен, если истек сертификат, если нарушена синхронизация времени (что критично для TOTP). Эти проверки лучше проводить заранее, а не в момент инцидента.

Двухфакторная аутентификация через RADIUS работает эффективно только тогда, когда она встроена в продуманную архитектуру. Если просто «добавить второй фактор», но оставить старые уязвимые практики, реального повышения уровня защиты не произойдет.

Фотография Дмитрий Мельников Дмитрий Мельников Руководитель группы
Узнайте, как сотрудники относятся к информационной безопасности и защищают ресурсы компании
Подписаться

Узнайте, как сотрудники относятся к информационной безопасности и защищают ресурсы компании
Пришлем ссылку на результаты исследований о человеческом факторе в ИБ на почту, которую вы указали
Подписаться