Radius

Введение

Долгое время считалось, что классический метод аутентификации, основанный на комбинации логина и пароля, весьма надёжен. Однако сейчас утверждать такое уже не представляется возможным. Всё дело в человеческом факторе и наличии у злоумышленников больших возможностей по угону пароля. Не секрет, что люди редко используют сложные пароли, не говоря уже о том, чтобы регулярно их менять. К сожалению, является типичной ситуация, когда для различных сервисов и ресурсов применяется один и тот же пароль. Таким образом, если последний будет подобран посредством брутфорса или украден с помощью фишинговой атаки, то у злоумышленника появится доступ ко всем ресурсам, для которых применялся этот пароль. Для решения описанной проблемы можно использовать дополнительный фактор проверки личности. Решения, основанные на таком методе, называются системами двухфакторной аутентификации (two-factor authentication, 2FA) или многофакторной аутентификации (multi-factor authentication, MFA). Одним из таких решений является Multifactor от компании Мультифактор. Эта система позволяет выбрать в качестве второго фактора один из следующих инструментов: аппаратный токен, SMS-сообщения, звонки, биометрию, UTF, Google Authenticator, Яндекс.Ключ, Telegram или мобильное приложение. Необходимо добавить, что данное решение предлагается только в качестве сервиса, когда у заказчика устанавливаются лишь программные агенты, а ядро системы размещается на стороне вендора, избавляя таким образом специалистов заказчика от проблем с внесением изменений в инфраструктуру и решением вопросов по организации канала связи с провайдерами для приёма звонков и SMS-сообщений.

Функциональные возможности системы Multifactor

Система Multifactor обладает следующими ключевыми функциональными особенностями:

• Большой выбор способов аутентификации: Telegram, биометрия, U2F, FIDO, OTP, Google Authenticator, Яндекс.Ключ, мобильное приложение Multifactor, звонки и SMS-сообщения.

• Предоставление API для управления пользователями из внешних систем.

• Журналирование действий пользователей при получении доступа.

• Управление ресурсами, к которым осуществляется доступ.

• Управление пользователями из консоли администрирования.

• Возможность импорта пользователей из файлов формата CSV или простого текстового файла.

• Большой перечень ресурсов, с которыми возможна интеграция Multifactor: OpenVPN, Linux SSH, Linux SUDO, Windows VPN, Windows Remote Desktop, Cisco VPN, FortiGate VPN, Check Point VPN, VMware vCloud, VMware Horizon, VMware AirWatch, Citrix VDI, Huawei.Cloud (в России SberCloud), Outlook Web Access, и другие.

• Управление функциями системы Multifactor через единую консоль администратора.

• Информирование администратора системы о потенциальных инцидентах в сфере ИБ.

• Поддержка Active Directory и RADIUS. Возможность возвращать атрибуты на основе членства пользователя в группе.

Архитектура системы Multifactor

Как уже было сказано, Multifactor является сервисным продуктом. Таким образом, вычислительные мощности и сетевая инфраструктура, необходимые для работы системы, размещены в Москве, в дата-центре Даталайн. ЦОД сертифицирован по стандартам PCI DSS (уровень 1) и ISO/IEC 27001:2005. На стороне заказчика устанавливаются только следующие программные компоненты с открытым исходным кодом:

• RADIUS Adapter (для приёма запросов по протоколу RADIUS)

• IIS Adapter (для включения двухфакторной аутентификации в Outlook Web Access)

• Портал самообслуживания (для самостоятельного управления средствами аутентификации со стороны пользователей).

Системные требования Multifactor

Для корректного функционирования Multifactor производитель установил отдельные системные требования по каждому из компонентов системы. В таблице 1 указаны минимальные ресурсы для RADIUS Adapter.

В таблице 2 приведены показатели, соответствие которым необходимо для установки портала самообслуживания (Self-Service Portal).

Для взаимодействия с большей частью средств коммутации и сервисов в целях осуществления доступа в Multifactor используется сетевой протокол RADIUS (Remote Authentication Dial-In User Service). Система полагается на данный протокол в следующих сценариях:

• Схема двухфакторной аутентификации, где в качестве первого фактора пользователь применяет пароль, а в качестве второго мобильное приложение, Telegram или одноразовый код (OTP);

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

Для того чтобы можно было использовать протокол RADIUS, необходимо обеспечить беспрепятственное подключение устройства доступа (сервер, межсетевой экран или другое средство сетевой коммутации) к адресу radius.multifactor.ru по UDP-порту 1812. Соответственно, данный порт и веб-адрес должны находиться в списке разрешённых.

Кроме того, протокол RADIUS можно применять для обеспечения безопасности подключения по SSH, использования команды SUDO и других операций, требующих усиленного контроля доступа. Также сетевой протокол RADIUS пригодится как дополнительный инструмент проверки подлинности Windows для подключения к удалённому рабочему столу (Remote Desktop).

Для полноценного использования протокола RADIUS в Multifactor применяется программный компонент Multifactor RADIUS Adapter. Multifactor RADIUS Adapter реализует следующие возможности:

• получение запросов для прохождения аутентификации по протоколу RADIUS;

• проверка логина и пароля пользователя в Active Directory или NSP (Microsoft Network Policy Server);

• проверка второго фактора аутентификации на мобильном устройстве пользователя;

• настройка доступа на основе принадлежности пользователя к группе в Active Directory;

• включение второго фактора на основе принадлежности пользователя к группе в Active Directory;

• применение мобильного телефона пользователя из Active Directory для отправки одноразового кода через SMS.

Помимо RADIUS в Multifactor также используется протокол взаимодействия SAML, который кроме двухфакторной аутентификации предоставляет технологию единого входа (SSO) в корпоративные и облачные приложения, где первым фактором может быть логин и пароль от учётной записи в Active Directory либо в Google или Yandex. При использовании протокола SAML в Multifactor можно настроить взаимодействие для аутентификации со следующими приложениями и сервисами: VMware, Yandex.Cloud, SberCloud, Salesforce, Trello, Jira, Slack и др.

Если вас заинтересовал данный продукт, то мы готовы провести совместное тестирование. Следите за обновлениями в наших каналах (Telegram,Facebook,VK,TS Solution Blog)!

• Цель статьи

• Определение

• Компоненты

• Общие понятия

• Сфераприменения

  • -login

  • -VPN (ppp*)

  • -wifi

  • -dot1x

• диагностика

• выводы

Цель

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

Определение, назначение, общие сведения

RADIUS - это протокол, для авторизации, аутентификации и учёта (AAA).

Позволяет повысить безопасность сети и централизованно управлять доступами.

Сервер RADIUS может иметь свою базу данных с учетными данными (например файлы илиmysql) или работать в паре с другим сервером, например Active Directory.

Кроме AAA позволяет передать некоторые дополнительныеданные (настройки) клиенту прошедшему аутентификацию, в том числе vendor-specific attributes (VSA). У Mikrotik такие тоже есть, позже пройдемся по самым интересным.

Существуют много популярных приложенийрадиус сервера, самый популярные: freeRADIUSи Служба NPS (Network Policy Server) Windows Server. Более подробно мырассмотрим второй вариант.

Компоненты кейса

• Суппликант - устройство которое намеренопройти процедуру авторизации и аутентификации.

• Аутентификатор - устройство к которому подключается суппликант, которое получаету суппликанта данные авторизации и которое проверяет их на RADIUS сервере. NB! Является клиентом для радиус-сервера.

• RADIUS сервер (он же радиус сервер, он же сервер аутентификации).

Настройка

Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц

1. Добавлениерадиус клиента на радиус-сервере Намнужно заполнить "понятное имя", IP адрес и придумать пароль (а.к.а. "секрет"), которыйпонадобится при настройке аутентификатора (mikrotikв нашем случае)

   

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

Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущаяи так далее. К примеру, это поможет разделить правила обработки для проводных\беспроводных и впн клиентов. {.is-warning}

2. Добавление политики запросов на подключение

3. Добавление сетевой политики

Некоторые типовые кейсы применения радиус сервера :

1. централизованная аутентификация на устройствах поддерживающихaaa

2. аутентификация для vpn (pptp\l2tp)

3. аутентификация вwifi

4. аутентификация устройств при подключении к порту rj45 - dot802.1x

Итак подробнее, + некоторые плюшки. Для всех наших пунктов нам нужнонастроить радиус клиента вmikrotik

/radius add address=10.10.11.100 comment="PVE AD" secret=STRONG_SECRET_PASSWORD service=ppp,login,hotspot,wireless,dhcp,ipsec,dot1x timeout=600ms

address -Адрес радиус сервера secret - пароль, который мы совсем недавно настраивали для радиус клиента service -сервисы в mikrotik, которые могут использовать радиусдля аутентификации.

Отдельно стоит отметить пункт timeout=600ms, если вы используете радиусчерез медленные каналы с большими задержками, стоит увеличитьэто значение.

Теперь можно начинать настраиватьинтересные вещи.

1. настроим входна микротик

/user aaaset accounting=yes default-group=read use-radius=yes

Стоит уделить внимание параметру default-group он означаетгруппу по умолчанию,вкоторая применится к пользователю.

Теперь настроим NPS:

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

ОбратимсякWikimikrotik, мы можем заметить RADIUS атрибут, который позволяет определитьдоступы какой группыприменятся к пользователюкоторый аутентифицируется на устройстве черезRADIUS. *Mikrotik-Group - Router local user group name (defines in /user group) for local users; HotSpot default profile for HotSpot users; PPP default profile name for PPP users. * воспользовавшись промт'оммы понимаем что этот атрибут позволяет задать нам имя встроенной группы при авторизации , или задать имя профиля при аутентификациив сервисыvpn или hostspot. этот атрибут мы буем использовать и позже.что бы отделить мух от котлет приавторизации для впн мы будем использовать дополнительные условия, но это позже.

итак, как мы этого добьемся мы можем создать вSystem -> users ->groupдве группы со специфичными параметрами доступа, а можем и воспользоваться уже существующими, к примеруfullиread.

Но все это ничего без второй части, нам необходимо настроитьNPS. Давайте создадим в остнастке Пользователи и компьютерыДве группы пользователей admins-network иadmins-junior. И два пользователяnet-juniorи net-admin,добавим их в соответствующие группы.

Политику запроса на подключение мы уже создали, перейдем к сетевым политикам. в Оснастке NPSсоздадим двеполитики mikrotik-login-juniorиmikrotik-admin-network ,в условиях первойзададим :

А вот так будет выглядеть настройка необходимого нам атрибута, из которого микротик определит в какую группу поместить подключенного пользователя.

Сразу попробуем авторизоваться ивидим что попали в нужную группуread

В методах проверки подлинности указываем :

Политика mikrotik-admin-networkбудет отличаться тем что в условияхвыберем группу admins-networkа значение отрибутаMIKROTIK_GROUPзададим как full Результат ожидаемый, мы залогинилисьв микротик под полными правами:

/user active print detailFlags: R - RADIUS, M - by-romon 0 R when=jan/05/2021 10:36:52 name="net-admin" address=10.10.15.7 via=winbox     group=full 1 R when=jan/05/2021 10:37:04 name="net-admin" address=10.10.15.7 via=telnet     group=full

Перейдем к впн, и к стразу более интересному сценарию.

Предположим мы хотим отделитьадминов, от остальных работников. Выдадим админам профиль с подсетью которая будет иметь доступ к management vlanи не только, и выдадимотстальным сотрудникам профильс подсетью которая будет меть ограниченый доступ только к 1c, RDP, etc.. . Предположим, мы используюем для впнl2tp\ipsec/ Для этого создадим в микротик два профиля в PPP -> profile

/ip pool add name=pool_l2tp_admin ranges=10.10.21.10-10.10.21.250/ip pool add name=pool_l2tp_users ranges=10.10.22.10-10.10.22.250/ppp profile add dns-server=10.10.21.1 local-address=10.10.21.1 name=l2tp-vpn-admin remote-address=pool_l2tp_admin use-compression=no use-encryption=yes/ppp profile add dns-server=10.10.22.1 local-address=10.10.22.1 name=l2tp-vpn-users remote-address=pool_l2tp_users use-compression=no use-encryption=yes

В настройки правил форейвола дляограничения доступа подсетей япожалуй не буду углубляться,подразумевается что вы понимаете как изодной подсети запретить доступ кресурсу икак разрешить. (с)предпологается, что вы немного сетевик. Касательно примера подсети10.10.21.0/24необходимо разрешить форвард в подсети серверов и managementа подсети 10.10.22.0/24необходимо разрешить только доступк корпоративным сервисам, но не к сетям управления.

Настроим NPS. В остнастке Пользователи и компьютеры создадим 2 группы пользователей vpn-admins иvpn-users, знакомого нам net-adminвключим в 1ю группу, а net-buhво вторую. Политика запросов на подключение у нас будет использоваться та же. А политики сети созадим. В Условиях важно не только задать группу пользователей, но и тип порта NAS

Знакомым нам образом добавим атрибут указывающий какой профиль микротика использовать.

Методы проверки подлинности используем как и в прошлый раз. В настройках Сервера VPNрекомендуется указать точно такой же тип.

На вскидку полезными так же могут отказаться атрибуты : Mikrotik-Rate-Limit - дляограничения скорости vpnклиентов

Настроим тестовое поключение и увидим что получилиIPиз пуладля сетевых администраторов.

Теперь настроим политику дляобычных пользователей:

Результат - пользователь получилipизнужной подсети

Wifiи Dot1x

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

• настроить службу центрасертификацииWindowsтыц, актуально и для следующего пункта

• настроить GPO для распространения CAсертификата домена тыц

• GPOавтоматического получения сертификата компьютераdocs.microsoft

• GPOвключение службы dot1X (проводная автонастройка) исоздать Политики проводных сетей (802.3) для выбора способа проверки подлинности тыц

• GPOАвтоматическое подключение кWifiдо логина пользователя тыц

Данные пункты не маленькиечто бы включать их в эту статью, но достаточно освещены в статьях интернета.

wifi

Настройку WiFiкаждый настраивает как ему удобно. Я к примеру,предпочитаю CapsMan,дажеесли это будетединственная APв сети. В любом случае нас интересует только Security Profile/Security Cfg.

Создадим политику сети: В условиях выберем Тип порта NAS= Беспроводная - IEEE 802.11

А в методах проверки подлинности следующее.

Как понять что все получилось или что то идет не так )? - все просто в первую очередь идем в логи. Видим событие с подробной информациейкто куда и когда ходил и согласно какой политике получилразрешение или отказ ы доступе.

Какие радиус атрибуты могут быть нам полезны:

• Framed-Pool - можемдля отдельных групп пользователей использоватьсвойipпули выполнять какие то манипуляции на основе этого вфорейволе

• Filter-Id - применять какое то правило форейвола сразу к клиенту

• Mikrotik-Wireless-VLANID - указать в какойvlanдолжен попасть клиент (Возможно, однажды, по заявкампользователейя дополню статью примером с ипользованиемvlanвwifi)

• устанавливать лимитыпо обьему или/и скорости трафика

• имногие другие параметры из вики, либо их комбинации с условиями сетевой политики, смотря сколько у вас фантазии :)

dot1x

Зачем нужен dot1X и как его настроить.. очень много интересных слов можно было бы тут написать, но все сказанодо нас. Например на каналеодного прекрасного тренераили wiki

Половина смысла с саркальной точки зрения в dot1xв том, что в случае успешной проверки подлинности наше устройство попадетв влан указанный нами в микротике или в влан который мы поличим в качестве атрибута у радиуса. Еслипроверка подлинности пройдет с отказом или ответ не будет получен от радиуса (например в случае его недоступности), то порт перейдет в изолироованный режим (будет заблокирован любой трафик на порту) или в случае если указан Reject VLAN IDто попадет в влан,для которогомы настроили(я надеюсь все таки настроили) максимально безопасные правилафорейвола для чужеродных устройств .

Начнем с микротика:

Настроим политики сети: В условиях необходимо отобрать проводные клиенты

Параметры аутентификации:

В настройках атрибутами выдадим рабочий влан

К примеру вот так выглядит отказ вавторизации:

А вот так успешное подключение:

Диагностика

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

• логи mikrotik

  Идем в system logging add topics=radius,debug action=memory disabled=noи пробуем что то делать, в log printпоявятся записи связанные с радиусом. -логи Службы

• политики сети и доступа

  я уже приводил пример, еще раз - искатьздесь, и читать внимательно сообщения

  

• возможны проблемы из заwindows брандмауерапочинить можно

Get-NetFirewallRule -DisplayGroup "Сервер политики сети" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

илидляанглоязычной версии:

Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any 

• radclientиз пакета freeradius-utils. Позволяет из командной строки проверить некоторые типы авторизации, к примеру подключение кvpn

Тест:

echo "User-Name = USER,User-Password=PASSWORD,NAS-Port-Type=Virtual" | radclient -s 10.10.11.100:1812 auth SHARE_NPS_SECRET -x

Вывод программы:

Sent Access-Request Id 177 from 0.0.0.0:42354 to 10.10.11.100:1812 length 56       User-Name = "USER"       User-Password = "PASSWORD"       NAS-Port-Type = Virtual       Framed-Protocol = PPP       Cleartext-Password = "PASSWORD"Received Access-Accept Id 177 from 10.10.11.100:1812 to 10.10.15.7:42354 length 94       Mikrotik-Group = "pptp-nps"       Framed-Protocol = PPP       Service-Type = Framed-User       Class = 0xa1cd098c00000137000102000a0a0b6400000000ec967e14be8346ce01d6d63b3e2ca9d70000000000000092Packet summary:       Accepted     : 1       Rejected     : 0       Lost         : 0       Passed filter : 1       Failed filter : 0

Выводы

RADIUSв сетевой средеочень полезенв плане безопасностии удобен вплане централизованного управления. Настраивать не так уж и сложно, главное читать, понимать документацию и логи.

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

Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.

Благодарности:

Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.