хж. Служба radius и её настройка
 Скачать 1.08 Mb.
|
ОГЛАВЛЕНИЕОГЛАВЛЕНИЕ 4 ВВЕДЕНИЕ 5 1.1.Что такое RADIUS? 6 1.3.Основные различия между RADIUS и TACACS+ 9 1.4.Механизм сокрытия 10 ВВЕДЕНИЕПротокол RADIUS является IETF-стандартом для AAA. Используется с начала 1990-х годов и первоначально применялся для коммутируемых модемных соединений. Изначально использовался для расширения Layer 2 протокола точка-точка (PPP) между конечным пользователем и сервером доступа к сети (NAS), передавая трафик аутентификации с NAS на AAA-сервер. Сведения от аутентификации и авторизации доставляются одним типом пакетов, а учет обрабатывается отдельным процессом. RADIUS имеет широкое распространение и поддерживается большинством производителей устройств и разработчиков программных продуктов. Актуальность работы: актуальность данной выпускной квалификационной работы определяется тем, что служба RADIUS Цель работы: RADIUS Объект исследования: Предмет исследования: базовая настройка данной службы. Методы работы: Задачи исследования, опираясь на поставленные цели, включают в себя: ГЛАВА I.ОСНОВНЫЕ СВЕДЕНИЯ О СЛУЖБЕ RADIUS Что такое RADIUS?RADIUS (Remote Authentication in Dial-In User Service) — протокол для реализации аутентификации, авторизации и сбора сведений об использованных ресурсах, разработанный для передачи сведений между центральной платформой и оборудованием. Этот протокол применялся для системы тарификации использованных ресурсов конкретным пользователем/абонентом. Изначально концепция RADIUS состояла в обеспечении удаленного доступа через коммутируемое телефонное соединение. Со временем выкристаллизовались и другие области применения этой технологии. К ним относятся серверы виртуальных частных сетей (Virtual Private Network, VPN) — они в большинстве своем поддерживают Rаdius, — а также точки доступа беспроводных локальных сетей (Wireless LAN, WLAN), и это далеко не все. Концепция службы идентификации удаленных пользователей подразумевает, что клиент RADIUS — обычно сервер доступа, сервер VPN или точка доступа беспроводной локальной сети — отсылает серверу RADIUS параметры доступа пользователя (в англоязычной документации они часто называются Credentials, т. е. мандат, куда, к примеру, входят его настройки безопасности и права доступа), а также параметры соответствующего соединения. Для этого клиент использует специальный формат, так называемый RADIUS-Message (сообщение RADIUS). В ответ сервер начинает проверку, в ходе которой он аутентифицирует и авторизует запрос клиента RADIUS, а затем пересылает ему ответ — RADIUS-Message-response. После этого клиент передает на сервер RADIUS учетную информацию. Еще одна особенность — поддержка агентов RADIUS. Эти системы предназначены исключительно для обеспечения обмена сообщениями RADIUS между клиентами, серверами и другими агентами. Отсюда можно сделать вывод, что сообщения никогда не передаются непосредственно от клиента к серверу. Сами по себе сообщения RADIUS передаются в форме пакетов UDP. Причем информация об аутентификации направляется на порт UDP с номером 1812. Некоторые серверы доступа используют, однако, порты 1645 (для сообщений об аутентификации) или, соответственно, 1646 (для учета) — выбор должен определять своим решением администратор. В поле данных пакета UDP (так называемая полезная нагрузка) всегда помещается только одно сообщение RADIUS. В соответствии с RFC 2865 и RFC 2866 определены следующие типы сообщений: Access-Request - "запрос доступа". Запрос клиента RADIUS, с которого начинается собственно аутентификация и авторизация попытки доступа в сеть; Access-Accept - "доступ разрешен". С помощью этого ответа на запрос доступа клиенту RADIUS сообщается, что попытка соединения была успешно аутентифицирована и авторизована; Access-Reject - "доступ не разрешен". Этот ответ сервера RADIUS означает, что попытка доступа к сети не удалась. Такое возможно в том случае, если пользовательских данных недостаточно для успешной аутентификации или доступ для пользователя не авторизован; Access-Challenge - "вызов запроса". Сервер RADIUS передает его в ответ на запрос доступа; Accounting-Request - "запрос учета", который клиент RADIUS отсылает для ввода учетной информации после получения разрешения на доступ; Accounting-Response - "ответ учета". Таким образом сервер RADIUS реагирует на запрос учета и подтверждает факт обработки запроса учета. Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами, серверами и прочими агентами RADIUS. Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS. Что такое TACACS+? Данный протокол разработан компанией Cisco и является развитием прошлых версий TACACS и XTACACS. Несмотря на схожесть названий, TACACS+ был сильно видоизменен и не имеет обратной совместимости с TACACS, который сейчас практически нигде не применяется. Основная сфера использования TACACS+ – это администрирование сетевых устройств, однако он может применяться для некоторых типов AAA при доступе в сеть. TACACS + использует Transmission Control Protocol (TCP) порт 49, а не UDP, так как он обладает большей надежностью и позволяет заранее получать информацию о потенциальных ошибках благодаря пакету TCP-RST. ТСP более медленный протокол, но обладает дополнительными преимуществами: возможность разделения аутентификации, авторизации и учета в качестве отдельных и независимых функций, множественная авторизация после одной аутентификации, шифрование всего содержимого пакета. TACACS+ также поддерживает несколько других протоколов (отличных от IP), таких как AppleTalk, NetBIOS, NetWare Asynchronous Service Interface (NASI) и X.25, но в современных сетях их использование сошло на нет.  Основные различия между RADIUS и TACACS+Основные различия сводятся к тому, что TACACS+ шифрует все содержимое пакета, оставляя только простой заголовок. Такой способ защищает от злоумышленников, которые прослушивают сообщения, передаваемые между устройствами. Также TACACS+ реализует функции AAA раздельно, что позволяет вынести каждую из них на отдельный сервер или даже использовать другой протокол (не TACACS+). TACACS+ также предлагает более тесную интеграцию с устройствами Cisco и позволяет осуществлять детальное управление маршрутизаторами (процесс авторизации). С сервером TACACS + возможно реализовать управление командами с применением уровней доступа (которые далее настраиваются на самих устройствах). RADIUS позволяет частично реализовать эту возможность, но не так хорошо и гибко, как TACACS+. При использовании протокола TACACS+ между клиентом и сервером не может быть брендмауэра, так как сервер должен получить запрос от клиента с его IP-адресом, а не с адресом брендмауэра. У RADIUS IP-адрес клиента содержится еще и в самом пакете, что позволяет ААА-серверу получить его оттуда. А вот самый большой недостаток TACACS+ заключается в том, что Cisco разработала этот протокол для собственных нужд и поэтому самую широкую его поддержку получили именно сетевые устройства этой компании. Однако постепенно ситуация меняется, и остальные производители стали также поддерживать TACACS+. Какой протокол для ААА-сервера использовать, необходимо выбирать в зависимости от задачи. Если это администрирование устройств, то TACACS+ станет лучшим вариантом, а если доступ к сети, то более универсальный и быстрый – RADIUS. Механизм сокрытияДля шифрования пароля пользователя и прочих атрибутов применяются «общий секрет», аутентификатор запросов и алгоритм хэширования MD5. Эту комбинацию нельзя назвать верхом совершенства с точки зрения надежности шифрования, что отражено и в RFC 2865 — в документе рекомендуется как можно лучше позаботиться о надежности передачи. Примером лучшей защиты атрибутов является применение IPSec. В комплекте с протоколом инкапсуляции защищаемой полезной нагрузки (Encapsulated Security Payloаd, EPS) и мощным шифровальным механизмом, наподобие Triple DES, можно добиться очень высокой надежности передачи данных и конфиденциальности сообщения RADIUS. Если же совместная работа IPSec, ESP и алгоритма шифрования невозможна, у администратора сети остается еще один способ уменьшения вероятности взлома выполненной реализации RADIUS: применение атрибутов аутентификации должно быть обязательным для всех сообщений с запросом доступа; в качестве удостоверений запросов необходимо использовать криптологически сильные величины; к использованию должны допускаться только трудно угадываемые пользовательские пароли; для предотвращения атак с перебором по словарю предпочтителен механизм "учета и блокировки аутентификации"; "общий секрет" должен иметь энтропию, равную по меньшей мере 128 бит. Применение RADIUS Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. Для повышения достоверности передаваемых сообщений RADIUS рекомендуется применение IPSec и EPS. При этом следует использовать алгоритм шифрования Triple DES. Путем шифрования всего сообщения RADIUS при помощи IPSec защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации IPSec с использованием сертификатов.  Аутентификация и авторизация через RADIU 1  Онлайн учёт через RADIUS-сервер 1 Помимо этого, возможны и другие варианты защиты, которые могут использоваться как в совокупности с IPSec, так и отдельно. Используемый "общий секрет" должен иметь длину не менее 32 шестнадцатеричных символов или, соответственно, 22 символов клавиатуры. Для всех сообщений с запросом доступа обязательны атрибуты удостоверения сообщения. Для клиента RADIUS это означает, что атрибут удостоверения сообщения нужен и для всех сообщений запроса доступа. Это правило требуется соблюдать также в случае сервера RADIUS. С криптографической точки зрения непременным условием является качественное удостоверение запроса. Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации. Следует пользоваться ЕАР или схемами типа ЕАР с поддержкой сильных методов аутентификации. Хороший пример подобного метода - ЕАР-TLS. Он требует обмена сертификатами между клиентом, пытающимся получить доступ, и сервером RADIUS. Все сообщения ЕАР должны иметь атрибуты удостоверения сообщения для защиты тех сообщений запроса доступа, к которым IPSec не применяется. Желательно выбирать методы аутентификации, рассчитанные на двустороннюю аутентификацию. При таком подходе противоположные конечные точки соединения аутентифицируют свои системы. Если с какой-либо стороны аутентификация пройдет неудачно, то в установлении соединения будет отказано. Примерами подобных методов служат ЕАР-TLS и MS-CHAPv2. Так, в случае ЕАР-TLS сервер RADIUS проводит проверку пользовательского сертификата клиента, пытающегося получить доступ, а клиент в свою очередь - сертификата сервера RADIUS. Если аутентификация производится посредством РАР, то эту опцию следует отключить. При аутентификации с помощью однократных паролей или токенов происходит откат к PAP. Но поскольку IEEE 802.1x не поддерживает РАР, в подобных случаях чаще всего пользуются соединениями РРР. Проверка подлинности RADIUS Схемы проверки подлинности, использующие протокол EAP, называются типами EAP. Для успешной проверки подлинности клиент удаленного доступа и сервер, выполняющий проверку подлинности, должны поддерживать один и тот же тип EAP. Теперь вернемся к RADIUS серверу, который проверяет информацию, полученную от NAS. Сервер проверяет идентичность пользователя, а также корректность дополнительной информации, которая может содержаться в запросе: сетевой адрес устройства пользователя, телефонный номер, состояние счета, его привилегии при доступе к запрашиваемому сетевому ресурсу. По результатам проверки RADIUS сервер посылает NAS один из трех типов откликов: Access-Reject - показывает, что данный пользовательский запрос неверный. При желании сервер может включить текстовое сообщение в Access-Reject, которое может быть передано клиентом пользователю. Никакие другие атрибуты (кроме Proxy-State) не разрешены в Access-Reject. Access-Challenge - запрос дополнительной информации от пользователя, например, второй пароль, пин-код, номер карты и т.п. Этот отклик также используется для более полного аутентификационного диалога, где защитный туннель выполняется между устройством пользователя и RADIUS сервером, так что сертификаты доступа скрываются от NAS. Access Accept - пользователю разрешен доступ. Поскольку пользователь аутентифицирован, то RADIUS сервер проверяет авторизацию на использование запрошенных пользователем ресурсов. Например, пользователю может быть разрешён доступ через беспроводную сеть, но запрещен доступ к VPN сети.Таким образом, работа RADIUS протокола может в общем случае быть представлена, как показано на таблице ниже. ГЛАВА II. РЕАЛИЗАЦИЯ 2.1. П В первую очередь создаём в домене Active Directory группу безопасности AllowRemoteCiscoUsers, в которую нужно добавить пользователей, которым будет разрешена аутентификации на маршрутизаторах и коммутаторах Cisco.  Установка необходимых компонентов завершена, теперь приступить к подготовительной настройке дополнительных утилит.  Для начала настроим AD, в ходе чего нам нужно создать новый лес.  После чего мы можем выбрать версию Window Server с которой хотим иметь совместимость при необходимости, но в нашем случае мы только указываем пароль, больше ничего трогать не нужно.  DNS делегацию мы не создаем, так как у нас нет в этом какой-либо необходимости, просто нажимаем далее.  Нажимаем закрыть, после чего компьютер автоматически перезагрузится и загрузит необходимые параметры.  В данном окне, tools, выбираем необходимы нам пункт - Network Policy Server  Для полноценного использования NPS-сервера в домене необходимо зарегистрировать его в домене Active Directory. В оснастке на NPS, щелкните ПКМ по вашему NPS узлу и выберите Register server in Active Directory.  При этом мы должны предоставите серверу полномочия на чтение свойств учётных записей пользователей, касающихся удалённого доступа. Сервер при этом будет добавлен во встроенную доменную группу RAS and IAS Servers.  На вкладке Settings заполняем поля Friendly name, Cl и пароль — Shared Secret + Confirm shared (этот пароль вы будете использовать в настройках коммутатора или маршрутизатора Cisco для установления доверительных отношений с Radius сервером).  Во вкладке Advanced выберите в поле Vendor name — Cisco.  Теперь нужно создать политики доступа на сервере RADIUS. С помощью политик доступа мы свяжем клиента Radius и доменную группу пользователей.  Укажите Имя политики (Policy name). Тип сервера доступа к сети (Type of network access server) оставляем без изменения (Unspecified):  На следующем шаге Specify conditions нам нужно добавить условия, при которых будет применяться данная политика RADIUS. Добавим два условия:  На следующем выберите значение Доступ разрешен (Access Granted).  Т.к. наш коммутатор Cisco поддерживает только метод аутентификации Unencrypted authentication (PAP, SPAP), снимаем все остальные флажки.  В разделе Configure Settings перейдем в секцию RADIUS Attributes -> Standard. Удалить имеющиеся там атрибуты и нажать на кнопку Add. Выберать Access type -> All, затем Service-Type->Add. Указать Others=Login.  Теперь в секции RADIUS Attributes -> Vendor Specific добавим новый атрибут. В пункте Vendor, найти Cisco и нажать Add. Здесь нужно добавить сведения об атрибуте. Нажать Add и указать следующее значение атрибута:  На последнем экране будут указаны все созданные вами настройки политики NPS, нажимаем Finish:  ЗАКЛЮЧЕНИЕ На основе выше проделанной работы мы изучили протокол ‘RADIUS’ Исходя из проделанной выше работы мы можем сделать вывод, что RADIUS необходим для реализации аутентификации, авторизации и сбора сведений об использованных ресурсах, разработанный для передачи сведений между центральной платформой и оборудованием. Так же можно добавить, что RADUIS в настоящее время используется для виртуального доступа к частным сетям (VPN), беспроводным точкам доступа (Wi-Fi), Ethernet коммутаторам и другим сетевым устройствам. Так же аналогом ‘RADIUS’ является lanbilling 2, в целом он относительно так же прост в использовании, но в основном все настраивается при помощи скриптов. В целом RADIUS необходим для отслеживания трафика и контроля доступа при удаленном подключении. На практическом примере мы реализовали протокол ‘RADIUS’, чтобы убедиться в полной работоспособности протокола, основанной на теоретических сведениях. СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ: ru.wikipedia.org osp.ru vasexperts.ru miniorange.com youtube.com | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||