Radius ключ шифрования что это
Защита беспроводных сетей, WPA: теория и практика (часть первая)
Тема безопасности беспроводных сетей по-прежнему остается актуальной, хотя уже достаточно давно существуют надежные (на сегодняшний момент, конечно же) методы защиты этих сетей. Разумеется, речь идет о технологии WPA (Wi-Fi Protected Access).
Большинство существующего на данный момент Wi-Fi оборудования имеет поддержку данной технологии, но, к сожалению, до сих пор в нашей лаборатории попадаются экземпляры, не знающие о WPA. Это более чем странно — заканчивается 2005 год, а некоторые производители до сих пор считают, что технология WEP спасет пользователей беспроводной сети от утечки информации. WEP уже давно устарела. На смену этой технологии пришел WPA, а также на горизонте виднеется новый стандарт 802.11i (некоторые производители преподносят его, как WPA2).
За шифрование данных в WPA отвечает протокол TKIP, который, хотя и использует тот же алгоритм шифрования — RC4 — что и в WEP, но в отличие от последнего, использует динамические ключи (то есть ключи часто меняются). Он применяет более длинный вектор инициализации и использует криптографическую контрольную сумму (MIC) для подтверждения целостности пакетов (последняя является функцией от адреса источника и назначения, а также поля данных).
RADIUS-протокол предназначен для работы в связке с сервером аутентификации, в качестве которого обычно выступает RADIUS-сервер. В этом случае беспроводные точки доступа работают в enterprise-режиме.
Если в сети отсутствует RADIUS-сервер, то роль сервера аутентификации выполняет сама точка доступа — так называемый режим WPA-PSK (pre-shared key, общий ключ). В этом режиме в настройках всех точек доступа заранее прописывается общий ключ. Он же прописывается и на клиентских беспроводных устройствах. Такой метод защиты тоже довольно секьюрен (относительно WEP), очень не удобен с точки зрения управления. PSK-ключ требуется прописывать на всех беспроводных устройствах, пользователи беспроводных устройств его могут видеть. Если потребуется заблокировать доступ какому-то клиенту в сеть, придется заново прописывать новый PSK на всех устройствах сети и так далее. Другими словами, режим WPA-PSK подходит для домашней сети и, возможно, небольшого офиса, но не более того.
В этой серии статей будет рассмотрена работа WPA совместно с внешним RADIUS-сервером. Но прежде чем перейти к ней, немного подробнее остановимся на механизмах работы WPA. А перед этим рассмотрим технологию WPA2.
Технология WPA являлась временной мерой до ввода в эксплуатацию стандарта 802.11i. Часть производителей до официального принятия этого стандарта ввели в обращение технологию WPA2, в которой в той или иной степени используются технологии из 802.11i. Такие как использование протокола CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol), взамен TKIP, в качестве алгоритма шифрования там применяется усовершенствованный стандарт шифрования AES (Advanced Encryption Standard). А для управления и распределения ключей по-прежнему применяется протокол 802.1x.
Как уже было сказано выше, протокол 802.1x может выполнять несколько функций. В данном случае нас интересуют функции аутентификации пользователя и распределение ключей шифрования. Необходимо отметить, что аутентификация происходит «на уровне порта» — то есть пока пользователь не будет аутентифицирован, ему разрешено посылать/принимать пакеты, касающиеся только процесса его аутентификации (учетных данных) и не более того. И только после успешной аутентификации порт устройства (будь то точка доступа или умный коммутатор) будет открыт и пользователь получит доступ к ресурсам сети.
Кроме вышеперечисленных, следует отметить следующие два метода, EAP-TTLS и EAP-PEAP. В отличие от предыдущих, эти два метода перед непосредственной аутентификацией пользователя сначала образуют TLS-туннель между клиентом и сервером аутентификации. А уже внутри этого туннеля осуществляется сама аутентификация, с использованием как стандартного EAP (MD5, TLS), или старых не-EAP методов (PAP, CHAP, MS-CHAP, MS-CHAP v2), последние работают только с EAP-TTLS (PEAP используется только совместно с EAP методами). Предварительное туннелирование повышает безопасность аутентификации, защищая от атак типа «man-in-middle», «session hihacking» или атаки по словарю.
На рис.1 показана структура EAP кадра. Протокол PPP засветился там потому, что изначально EAP планировался к использованию поверх PPP туннелей. Но так как использование этого протокола только для аутентификации по локальной сети — излишняя избыточность, EAP-сообщения упаковываются в «EAP over LAN» (EAPOL) пакеты, которые и используются для обмена информацией между клиентом и аутентификатором (точкой доступа).
Описанный процесс проиллюстрирован на рис.3 (там показан один из простейших методов EAP):
Как видно из рисунка, для коммуникации между клиентом (supplicant) и точкой доступа (authenticator) используются пакеты EAPOL. Протокол RADIUS используется для обмена информацией между аутентификатором (точкой доступа) и RADIUS-сервером (сервером аутентификации). При транзитной пересылке информации между клиентом и сервером аутентификации пакеты EAP переупаковываются из одного формата в другой на аутентификаторе.
Детальное рассмотрение алгоритмов шифрования, а также методы генерации сессионных ключей шифрования, пожалуй, выходят за рамки данного материала, поэтому рассмотрю их лишь вкратце.
Первоначальная аутентификация производится на основе общих данных, о которых знают и клиент, и сервер аутентификации (как то логин/пароль, сертификат и т.д.) — на этом этапе генерируется Master Key. Используя Master Key, сервер аутентификации и клиент генерируют Pairwise Master Key (парный мастер ключ), который передается аутентификатору со стороны сервера аутентификации. А уже на основе Pairwise Master Key и генерируются все остальные динамические ключи, которым и закрывается передаваемый трафик. Необходимо отметить, что сам Pairwise Master Key тоже подлежит динамической смене.
Теперь перейдем от сухой теории к реальности, а именно реализации WPA в Windows XP. Нормальная поддержка WPA (с поддержкой AES) появилась, только начиная с windows service pack 2.
Во второй части статьи будет рассмотрена настройка Windows-клиентов (Windows XP SP2), RADIUS-сервера (FreeRadius), и PKI на основе OpenSSL. Последние два компонента работают в операционной системе Gentoo Linux.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
RADIUS (Remote Authentication in Dial-In User Service)
| Communications protocol | |
| Purpose | Обеспечивает централизованную аутентификацию, авторизацию и учёт пользователей, подключающихся к различным сетевым службам |
|---|---|
| Developer(s) | Carl Rigney, Livingston Enterprises |
| Introduced | 1991 ; 30 years ago ( 1991 ) |
| Based on | TCP, UDP |
| OSI layer | Application layer |
| Port(s) | 1812, 1813 |
| RFC(s) | RFC 2548, RFC 2809, RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869, RFC 2882, RFC 3162 |
RADIUS — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. [Источник 1]
Аббревиатура «RADIUS» расшифровывается как «Remote Authentification Dial In User Services» — «аутентификация для удаленного доступа к пользовательским сервисам»
Содержание
Создание RADIUS
Протокол RADIUS был разработан Карлом Ригни (Carl Rigney) в фирме Livingston Enterprises для их серверов доступа (Network Access Server) серии PortMaster к сети интернет. На данный момент существует несколько коммерческих и свободно распространяемых RADIUS-серверов. Они несколько отличаются друг от друга по своим возможностям, но большинство поддерживает списки пользователей в текстовых файлах и различных базах данных. Учётные записи пользователей могут храниться в текстовых файлах, различных базах данных, или на внешних серверах. Существуют прокси-серверы для RADIUS, упрощающие централизованное администрирование и/или поз-воляющие реализовать концепцию интернет-роуминга. Популярность RADIUS-протокола, во многом объясняется: открытостью к наполнению новой функциональностью при сохранении работоспособности с устаревающим оборудованием, чрезвычайно высокой реактивностью при обработке запросов ввиду использования UDP в качестве транспорта пакетов, а также хорошо параллелизуемым алгоритмом обработки запросов; способностью функционировать в кластерных, архитектурах и мультипроцессорных платформах — как с целью повышения производительности, так и для реализации отказоустойчивости. [Источник 2]
Назначение
RADIUS — клиент-серверный протокол, работающий на прикладном уровне. Он является так называемым «протоколом ААА» (англ. «Protocol AAA»), что указывает на его назначение и области использования:
Аутентификация
Аутентификация (Authentication) — процесс, позволяющий аутентифицировать (проверить подлинность) субъекта по его идентификационным данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю;
Авторизация
Авторизация (Authorization)— процесс, определяющий полномочия идентифицированного субъекта, конкретного пользователя на доступ к определённым объектам или сервисам.
Учет (или контроль) — процесс, позволяющий вести сбор сведений и учётных данных об использованных ресурсах. Первичными данными, традиционно передаваемыми по протоколу RADIUS являются величины входящего и исходящего трафиков: в байтах/октетах (с недавних пор в гигабайтах). Однако протокол предусматривает передачу данных любого типа, что реализуется посредством VSA (Vendor Specific Attributes). Так, например, может учитываться время, проведенное в сети, посещаемые ресурсы и т. д.
Последняя функция делает возможным применение RADIUS-серверов в качестве компонентов биллинговых систем, ответственных за сбор информации об использовании телекоммуникационных услуг, их тарификацию, выставление счетов абонентам, обработку платежей и т. д.
Свойства RADIUS
Помимо непосредственно аутентификации, авторизации и учета, RADIUS-сервера могут выполнять ряд иных функций
Вышеперечисленное активно используется провайдерами Интернет-услуг, в среде которых RADIUS получил наиболее широкое распространение
Ограничения RADIUS
Механизм работы
Как уже упоминалось, RADIUS — прикладной протокол. На транспортном уровне используется протокол UDP, порты: 1812 и 1813.
Общая структура сети
Несмотря на то, что существует множество способов построения сетей с использованием RADIUS, общая структура может быть представлена в следующем виде:
Место NAS (Network Access Server) может занимать VPN-сервер, RAS (Remote Access Server), сетевой коммутатор и т. д.
Конечный RADIUS-сервер может быть частью исключительно локальной сети или же иметь доступ к сети Интернет.
Базы аутентификации хранят информацию о пользователях (абонентах) и правах их доступа к различным сервисам. Термин «база» в данном случае является собирательным, так как данные могут хранится как в локально, в текстовых файлах и различного рода базах данных, так и на удаленных серверах (SQL, Kerberos, LDAP, Active Directory и т. д.).
Структура пакета
Общая структура RADIUS-пакета имеет вид:
Код показывает тип операции, к которой принадлежит данный код. Так, выделяют следующие коды:
| Код | Операция |
|---|---|
| 1 | Access-Request |
| 2 | Access-Accept |
| 3 | Access-Reject |
| 4 | Accounting-Request |
| 5 | Accounting-Response |
| 11 | Access-Challenge |
| 12 | Status-Server (экспериментальная возможность) |
| 13 | Status-Client (экспериментальная возможность) |
| 255 | Зарезервировано |
Идентификатор служит для различения запросов и ответов.
Поле длины указывает размер всего пакета, с учетом длины кода, идентификатора, самого поля длины, аутентификатора и AVP.
Аутентификатор используется для аутентификации ответа от сервера и шифрования пароля.
AVP или пары «атрибут — значение» (англ. «Atribute-Value Pairs») содержат непосредственно сами передаваемые данные — как запроса, так и ответа, и участвуют во всех стадиях обмена данными: аутентификации, авторизации и учете. Структура AVP:
| Тип (8 бит) | Длина (8 бит) | Значение |
Поле типа служит для указания атрибута, содержащегося в пакете. Выделяют 63 атрибута, в числе которых: имя пользователя и пароль (коды 1 и 2, соответственно), тип сервиса (6), ответ сервера (18), состояние RADIUS-прокси (33), состояние учета (40) и задержка учета (41) и т.д.
Длина указывает размер значения атрибута, которое непосредственно содержится в последнем поле.
Аутентификация и авторизация
Аутентификация и авторизация Механизмы аутентификации и авторизации описаны в RFC 2058. Они протекают по следующей схеме: RADIUS-клиент отправляет RADIUS-серверу запрос доступа (AccessRequest), в котором содержатся данные аутентификации (логин и пароль, сертификат доступа). После сличения полученных данных с имеющимися в базе, сервер может отправить один из нескольких ответов [Источник 3] :
Защищенность
Пароли от NAS к RADIUS-серверу не пересылаются в открытом виде (даже в случае с PAP). Для шифрования паролей используется принцип «разделения секрета» и хэш-функция MD5.
Однако, в силу частичной реализации данных функции и недостаточ-ной защиты, предоставляемой ими, на практике необходимо использование дополнительных мер — таких как применение IPsec или физической защиты корпоративных сетей. Это позволяет в дальнейшем защитить трафик между сервером доступа и RADIUS-сервером.
Кроме того, передаваемые данные подвергаются защите лишь частично: защищены логин и пароль, в то время, как другие данные, возможно являющиеся секретными или приватными, не защищены.
Этот недостаток устранен в протоколе RadSec, который, будучи основан на RADIUS содержит ряд улучшений безопасности.
Пример настройки Radius
Начнём с того, что создадим в домене две локальных группы безопасности с ограниченными и полными правами Radius.
Создание группы с полными правами
В первую группу включим пользователей которым нужно предоставить полный административный доступ на управление коммутаторами, во вторую соответственно, — доступ только на чтение текущей конфигурации и состояния устройств. При этом, стоит помнить, что для пользователей, которые будут включаться в эти группы должно быть установлено разрешение в домене, дающее право удалённого доступа (значение настройки Network Access Permission на закладке Dial-In свойств учетной записи пользователя) [Источник 4]
О Radius подробно
Для аутентификации и авторизации пользователей или организации их учета можно порекомендовать использовать RADIUS. Тем более, когда речь идет об обширных сетях, доступ к которым разрешен немалому числу людей.
Oсновные составные части службы идентификации удаленных пользователей (Remote Authentication Dial-In User Service, RADIUS) описываются двумя RFC от IETF: RFC 2865 под названием Remote Authentication Dial-In User Service (RADIUS) в форме проекта стандарта и RFC 2866 под названием RADIUS Accounting в виде «информационного RFC». Изначально концепция 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 определены следующие типы сообщений:
Сообщение RADIUS всегда состоит из заголовка и атрибутов, каждый из которых содержит ту или иную информацию о попытке доступа: например, имя и пароль пользователя, запрашиваемые услуги и IP-адрес сервера доступа. Таким образом, главной задачей атрибутов RADIUS является транспортировка информации между клиентами, серверами и прочими агентами RADIUS. Атрибуты RADIUS определены в нескольких RFC, а именно: RFC 2865, RFC 2866, RFC 2867, RFC 2868, RFC 2869 и RFC 3162.
RADIUS может совместно работать с различными протоколами аутентификации. Наиболее часто используются протокол аутентификации пароля (Password Authentication Protocol, РАР), протокол аутентификации с предварительным согласованием (Challenge Handshake Authentication Protocol, CHAP), а также MS-CHAP (CHAP от Microsoft в первой версии или MS-CHAPv2 — во второй). Кроме того, возможно применение RADIUS вместе с PPP, протоколом передачи «точка-точка» (Point-to-Point Protocol). Результаты сеанса аутентификации между сервером доступа и действующим клиентом передаются на сервер RADIUS, который их потом удостоверяет.
Для защиты сообщений клиент и сервер RADIUS обладают «общим секретом» или, проще говоря, ключом. При этом речь, как правило, идет о цепочке символов, имеющейся как на серверах, так и на клиенте RADIUS.
РАСШИРЕННЫЙ ПРОТОКОЛ АУТЕНТИФИКАЦИИ
Расширенный протокол аутентификации (Extensible Authentication Protocol, EAP) изначально задумывался как дополнение к РРР для поддержки различных механизмов аутентификации доступа к сети. Протоколы аутентификации для РРР, например CHAP, MS-CHAP и MS-CHAPv2, определяют механизм аутентификации во время фазы установления соединения. На этом этапе необходимо применять согласованный протокол аутентификации, с целью «верификации» соединения. В данном случае речь идет о заранее определенной последовательности сообщений, причем они должны отсылаться в соответствии с заданной схемой, а точнее, в указанной очередности.
При использовании EAP в процессе установления соединения в рамках РРР специальный механизм аутентификации не определяется. Лишь на этапе аутентификации участники взаимодействуют по специальной схеме аутентификации EAP, обозначаемой также как «схема типа EAP».
ЕАР позволяет осуществлять обмен сообщениями между клиентом, запрашивающим доступ, и аутентифицирующим сервером (в его роли часто выступает сервер RADIUS). При этом обмен сообщениями может варьироваться с учетом особенностей различных соединений; он состоит собственно из запросов, в которых требуется предоставление информации об аутентификации, а также из соответствующих ответов. Длительность и конкретные детали сеанса аутентификации зависят от заданной схемы EAP.
В архитектурном плане ЕАР задумывался таким образом, чтобы аутентификацию можно было выполнять с помощью подключенных модулей с обеих сторон соединения: от клиента и от сервера. Если библиотечный файл ЕАР установить на обоих концах, то в любой момент можно применить новую схему аутентификации. Тем самым ЕАР предоставляет гибкую среду для внедрения безопасных методов аутентификации.
ЕАР удобен при таких видах аутентификации, как токены (Generic Token Card), однократные пароли (One Time Password), запрос/ответ (MD5-Challenge) или защита на транспортном уровне (Transport Level Security). Кроме того, эта концепция открыта для применения лучших технологий аутентификации в будущем. Однако ЕАР используется не только вместе с РРР. Он, помимо всего, поддерживается на канальном уровне стандарта IEEE 802.
К примеру, службу RRAS операционной системы Windows 2000 можно настроить таким образом, что система с каждым сообщением запроса доступа станет отправлять атрибут удостоверение сообщения (Message-Authenticator). При этом в соответствующем диалоговом окне необходимо выбрать в свойствах опцию always use digital signatures («всегда использовать цифровую подпись»). Служба аутентификации в Internet (Internet Authentication Service, IAS) настраивается со стороны Windows 2000 так, чтобы при получении любого сообщения запроса доступа проверялось наличие атрибута Message-Authenticator. Администратор должен установить соответствующий флажок в свойствах клиента RADIUS, чтобы клиент постоянно пересылал в запросе атрибут подписи.
Если по каким-либо причинам такой вариант невозможен, в этом случае остается один выход: Windows 2000 обладает механизмом «учета и блокировки аутентификации». Благодаря ему клиент не может превысить заданное количество попыток аутентификации за установленное время. Если же это происходит, система сразу прервет с ним связь.
НЕПРАВИЛЬНО СКОНФИГУРИРОВАННЫЙ ОБЩИЙ СЕКРЕТ
Еще одна потенциально слабая точка реализации RADIUS касается «общего секрета» (Shared Secret). Это связано с тем, что очень часто один и тот же «общий секрет» служит для поддержки максимального количества пар «клиент-сервер» в службе RADIUS. К тому же в большинстве случаев криптологически он недостаточно устойчив против атаки с перебором слов по словарю в автономном режиме. Значение поля Response Authenticator и содержимое атрибута Message Authenticator легко вычисляются. Потом эти данные сравниваются с перехваченным сообщением Access-Accept, Access-Reject или Access-Challenge. Таким образом, легко разгадываемый «общий секрет» может быть быстро скомпрометирован.
Сложившаяся ситуация усугубляется также некоторыми вариантами реализации RADIUS — довольно часто длина «общего секрета» не может превышать определенной величины, или же набор символов, из которых образуется ключевое слово, ограничен. В качестве примера приведем распространенную установку на использование только тех символов из набора ASCII, которые находятся непосредственно на клавиатуре — то есть лишь 94 из доступных 256 символов ASCII.
Важно знать, что в случае, если выбор ограничен только возможностями клавиатуры, последовательность символов должна состоять как минимум из 22 знаков и при этом содержать примерно в одинаковой пропорции строчные и прописные буквы, цифры и специальные символы. Если же «общий секрет» может быть задан в виде строки из шестнадцатеричных чисел, следует задавать не менее 32 цифр.
RFC 2865 предписывает использование 16 символов в «общем ключе». Однако для достижения энтропии (в теории информации энтропия отражает количество информации в последовательности символов) равной 128 бит каждый отдельный символ должен иметь энтропию 8 бит. В случае же, когда выбор символов ограничен имеющимися на клавиатуре, энтропия 8-битного символа уменьшается до 5,8 бит. Поэтому, чтобы добиться уровня энтропии в 128 бит, необходимо 22 символа. В среде Windows 2000 максимально возможная длина «общего секрета» может быть равна 64 символам (из имеющихся на клавиатуре).
Качественно улучшить результаты позволяет использование программ для генерирования «общего секрета», поскольку при этом обычно получаются лучшие, по сравнению с ручным вводом, значения энтропии. Кроме того, пара «клиент-сервер», использующая RADIUS, всегда должна быть защищена одним и тем же «общим секретом».
МЕХАНИЗМ СОКРЫТИЯ
Для шифрования пароля пользователя и прочих атрибутов применяются «общий секрет», аутентификатор запросов и алгоритм хэширования MD5. Эту комбинацию нельзя назвать верхом совершенства с точки зрения надежности шифрования, что отражено и в RFC 2865 — в документе рекомендуется как можно лучше позаботиться о надежности передачи.
Примером лучшей защиты атрибутов является применение IPSec. В комплекте с протоколом инкапсуляции защищаемой полезной нагрузки (Encapsulated Security Payloаd, EPS) и мощным шифровальным механизмом, наподобие Triple DES, можно добиться очень высокой надежности передачи данных и конфиденциальности сообщения RADIUS.
Если же совместная работа IPSec, ESP и алгоритма шифрования невозможна, у администратора сети остается еще один способ уменьшения вероятности взлома выполненной реализации RADIUS:
ПРИМЕНЕНИЕ RADIUS
Соблюдение некоторых принципов при вводе RADIUS в эксплуатацию поможет свести различные риски к минимуму. Для повышения достоверности передаваемых сообщений RADIUS рекомендуется применение IPSec и EPS. При этом следует использовать алгоритм шифрования Triple DES. Такой метод описан также в документе RFC 3162. Путем шифрования всего сообщения RADIUS при помощи IPSec защищаются особо чувствительные его части — такие, как поле удостоверения запроса в сообщении запроса доступа — и атрибуты RADIUS (к примеру, пароль пользователя или атрибуты ключа МРРЕ). Тому, кто предпримет попытку проникновения в систему, понадобится сначала расшифровать защищенное с помощью ESP сообщение RADIUS, и лишь после этого он сможет анализировать его содержимое. Чтобы предотвратить атаки на сервер RADIUS извне, рекомендуется установить программное обеспечение для аутентификации IPSec с использованием сертификатов. Помимо этого, возможны и другие варианты защиты, которые могут использоваться как в совокупности с IPSec, так и отдельно.
Нижеперечисленные советы помогут в реализации дополнительной защиты аутентификации.
ИСПОЛЬЗОВАНИЕ RADIUS ДЛЯ УДАЛЕННОГО ДОСТУПА И VPN
 |
| Рисунок 2. Пункт «Конфигурация RAS» в Windows 2000 предлагает несколько опций. |
 |
| Рисунок 3. Сервер RAS должен понимать протоколы, посредством которых отдельные клиенты пытаются получить к нему доступ. |
Подключение работающего сервера RADIUS к виртуальной частной сети (Virtual Private Network, VPN) или службе удаленного доступа (Remote Access Service, RAS) выполняется сравнительно просто. В операционной системе Windows 2000 для этого предусмотрены опции Remote Access Service (RAS) и VPN Server. Начать следует с пункта «Конфигурация сервера». Затем пользователю будут помогать различные программные эксперты. Для конфигурации RAS посредством «Ассистента настройки для сервера маршрутизации и RAS» в меню «Пуск — Программы — Управление» нужно выбрать пункт «Маршрутизация и удаленный доступ». Затем указать желаемое имя сервера, щелкнуть мышью на пункте «Конфигурация и активизация маршрутизации и RAS» в исходном меню и нажать кнопку «Далее». Администратору предоставится возможность выбора нескольких опций (см. Рисунок 2). Он должен выбрать пункт «cервер RAS», перейти к окну выбора протокола поддержки удаленного клиента (см. Рисунок 3) и отметить в нем тип соединения, через которое происходит связь с Intranet.
 |
| Рисунок 4. Соединение сервера RAS с сервером Radius. |
Далее необходимо указать способ распределения IP-адресов в диалоговом окне «Распределение IP-адресов». Если администратор выберет пункт «Автоматически», тогда сервер удаленного доступа для распределения IP-адресов между удаленными клиентами будет использовать протокол динамической конфигурации хоста (Dynamic Host Configuration Protocol, DHCP). С другой стороны, одну или даже несколько специальных областей IP-адресов можно распределить статично. По завершении этого этапа появляется окно «Управление несколькими серверами RAS». После чего в игру вступает соединение с RADIUS (см. Рисунок 4). Если администратор остановит выбор на пункте «Да, должен использоваться сервер RADIUS», то он обязан сразу же специфицировать первый сервер RADIUS, а при необходимости и второй (но это необязательно). После чего выполняются завершающие действия, и службу RAS можно запускать. Если применяется сервер VPN, то конфигурацию осуществляют соответствующим образом.