Автоматизация NGN сетей с применением технологии RADIUS » Страница 4 » Привет Студент!

3.1 Основные понятия AAA

В связи с возникшими и описанными в предыдущей главе проблемами при создании SIP номеров, было решено рассмотреть семейство протоколов Аuthentication, Аuthorization, Аccounting и выбрать один, который максимально подходит к нашим требованиям.

Единый термин AAA обозначает действия по аутентификации, авторизации и учету (Authentication, Authorization, Accounting). Важность эти операций все более возрастает по мере распространения сетей NGN. Все три составляющие AAA связаны тесно друг с другом, представляют собой единое целое.

− аутентификация – сопоставление персоны (запроса) существующей учётной записи в системе безопасности. Осуществляется по логину, паролю, сертификату, смарт-карте и т. д;

− авторизация – проверка полномочий, проверка уровня доступа, выяснение определённых полномочий (или запрета на доступ). В общем случае авторизация может быть «негативной» (пользователю А запрещён доступ к серверам компании);

− учёт – сбор информации о распределении ресурсов пользователем.

Существуют два вида аутентификации:

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

2) трехсторонняя. В данной модели точки доступа будут только передатчиками аутентификационной информации к единому хранилищу, которое содержит всю необходимую для аутентификации любого пользователя информацию. Она характеризуется след набором компонентов: поставщик аутентификационной информации, сервер доступа к сети, сервер AAA.

Любой сервис-провайдер использует как раз трехстороннюю модель аутентификации. Функциональная схема используемой модели расположена ниже.

Трехсторонняя модель аутентификации. На участке обмена между NAS (Network Access Server),сервером доступа к сети и сервером ААА и лежит зона ответственности AAA-протоколов.

Точное определения каждой из трех выше описанных процедур AAA позволяет сделать вывод об их тесной взаимосвязи – в реальности в подавляющем большинстве используется одновременно минимум 2 процедуры.

Рисунок 17 – Функциональная схема трехсторонней аутентификации

3.2 Протоколы AAA

Существует несколько протоколов обеспечения функционирования метода AAA. Примерами являются протоколы RADIUS, TACACS , DIAMETER, TACACS и XTACACS. Наиболее распространенными протоколами являются RADIUS, Diameter и TACACS . Ниже дано краткое описание этих трех протоколов. Не будем заострять внимание на протоколах TACACS и XTACACS, потому что они являются старыми версиями TACACS и уже не используются на практике.

RADIUS (англ. Remote Authentication in Dial-In User Service) это протокол для реализации аутентификации, авторизации и сбора сведений об использованных ресурсах, разработанный для передачи сведений между центральной платформой и оборудованием. Этот протокол был разработан независимой группой разработчиков (на данный момент протокол не модифицируется) и поэтому получил широкое распространение у сторонних разработчиков. Как правило, все производители программных и аппаратных клиентов поддерживают данный протокол. На рисунке 18 представлен процесс обмена сообщениями по протоколу RADIUS.

Рисунок 18 – Процесс обмена сообщениями по протоколу RADIUS

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

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

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

Среди определенных протоколом RADIUS сообщений наибольший интерес, представляют два – это сообщения запроса доступа Access-Request и разрешения доступа Access-Accept. Сообщение Access-Request посылается от сетевого сервера доступа к RADIUS-серверу и содержит в своем формате поля, соответствующие имени пользователя и его паролю. Информация о пользовательском имени и пароле представляется в определенной форме – в атрибутах RADIUS User-Name и User-Password.

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

По результатам проверки пользователь либо получает доступ к сетевым ресурсам, либо ему дается отказ. В первом случае RADIUS-сервер посылает в обратном направлении сообщение Access-Accept, содержащее IP-адрес (Framed-IP-Address), который указывает сетевому серверу доступа IP-адрес, присвоенный пользователю для запрашиваемого доступа.

Соответствие между сообщениями Access-Request и Access-Accept устанавливается с помощью служебных идентификационных полей.

Существует два алгоритмически различных процесса: процесс аутентификации, изображенный на рисунке 19 и процесс аудита (учета), изображенный на рисунке 20.

Процесс аутентификации заключается в следующих этапах:

1) пользователь инициирует процесс аутентификации, делая запрос к NAS-серверу;

2) NAS-сервер запрашивает логин и пароль, пользователь их вводит;

3) NAS-сервер посылает RADIUS-серверу пакет Acces-Request, содержащий логин, пароль и другие атрибуты. Пароль посылается в открытом или зашифрованном виде, в зависимости от типа аутентификации (наиболее популярные PAP или CHAP/MSCHAPv2);

Рисунок 19 – Функциональная схема процесса аутентификации

4) RADIUS-сервер идентифицирует пользователя по логину, проверяет верен ли пароль, есть ли возможность подключения (ибо есть максимальное число подключений на NAS), сумму на балансе, включена ли услуга и т. п.;

5) RADIUS-сервер возвращает один из вариантов пакета:

а) access-Accept – пользователь аутентифицирован;

б) access-Reject – пользователь не аутентифицирован;

в) access-Challenge – используется при аутентификации по методу CHAP и ему подобных.

6) дополнительно RADIUS-сервер добавляет в пакет атрибуты, содержащие настройки подключения (скорость подключения, запрещенные/разрешенные порты/службы и т. п.).

В процессе учета NAS-сервер, в зависимости от настроек, посылает пакеты Accounting-Request, содержащие информацию о сессиях (start/stop/alive). На каждый присланный пакет RADIUS-сервер отвечает пакетом Accounting-Response, иначе NAS будет слать пакеты, пока не получит ответа.

Рисунок 20 – Функциональная схема процесса учета

RADIUS базируется на протоколе UDP (пакетная передача данных, без гарантии передачи пакета).RADIUS-клиент на любой запрос должен дожидаться ответа от сервера в течении некоторого времени (timeout) и при в случае отсутствии ответа переслать пакет еще раз.

Diameter. Название DIAMETER – игра слов, отражающая превосходство нового протокола над предшественником RADIUS (диаметр – удвоенный радиус). С появлением новых технологий и приложений, таких как беспроводные сети и Mobile IP, требования к аутентификации и авторизации значительно повысились, а механизмы контроля доступа стали более сложными. На основе RADIUS был создан протокол Diameter, предназначенный для того, чтобы стать общей структурной основой для последующих AAA-приложений. Протокол Diameter широко используется в IMS-архитектуре (IP multimedia system) для обмена AAA-информацией между IMS-объектами. Он извлекает суть AAA-протокола из RADIUS и определяет набор сообщений, являющихся достаточно общими, для того чтобы служить ядром базового протокола Diameter. Различные приложения, нуждающиеся в AAA-функциях, могут определять свои собственные расширения на основе базового протокола Diameter.

Diameter имеет одноранговую архитектуру (Peer-To-Peer), и каждый хост, реализующий протокол Diameter, может выступать либо клиентом, либо сервером, в зависимости от сетевой инфраструктуры. Поэтому термин Diameter-узлы используется для ссылки на Diameter-клиент, на Diameter-сервер или на Diameter-агент, с которым мы познакомимся позже. Узел протокола Diameter, принимающий пользовательский запрос на соединение, выступает как Diameter-клиент. В большинстве случаев Diameter-клиентом будет NAS. После сбора информации, удостоверяющей пользователя, такой как имя пользователя и пароль, он передаст сообщение запроса на доступ одному Diameter-узлу, обслуживающему запрос. Для простоты мы предполагаем, что это Diameter-сервер. Diameter-сервер выполняет аутентификацию пользователя на основе предоставленной информации. Если процесс аутентификации выполняется успешно, в ответное сообщение включаются полномочия пользователя, и это сообщение передается обратно соответствующему Diameter-клиенту. В противном случае передается сообщение об отказе.

Для протокола Diameter является обязательным возможность работы по TCP или SCTP. Как и в большинстве моделей взаимодействия клиент-сервер, Diameter-сессия начинается с передачи сообщения запроса от клиента серверу. В контексте Diameter Diameter-клиент передаст сообщение auth-request, содержащее уникальный Session-Id, Diameter-серверу (или Diameter-прокси, если необходимо перенаправление сообщения). Используемые для аутентификации и авторизации пары AVP зависят от приложения и что они не определены в базовом протоколе.

После приема сообщения auth-request Diameter-сервер может включить Authorization-Lifetime.

AVP в ответное сообщение. Эта пара AVP используется для указания количества времени в секундах, которое требуется Diameter-клиенту для повторной авторизации. После истечения лимита времени и допустимого Auth-Grace-Period, Diameter-сервер будет удалять сессию из своего списка сессий и освобождать все ресурсы, выделенные для нее.

Во время сессии Diameter-сервер может инициировать запрос повторной аутентификации или повторной авторизации. Этот тип запросов используется для проверки продолжения использования пользователем службы, и если ответ отрицателен, сервер удаляет сессию, чтобы остановить начисление средств. Кроме того, для догадки об исключительном закрытии сессии используется пара AVP OriginState-Id. Отправитель запроса будет включать эту AVP, и, поскольку необходимо, чтобы это значение монотонно увеличивалось, получатель запроса может легко догадаться о том, что предыдущая сессия была закрыта либо по аварийному завершению работы устройства доступа, либо из-за каких-либо других исключительных ситуаций. Получатель запроса может затем удалить сессию из своего списка, освободить ресурсы и, возможно, уведомить свои Diameter-серверы, если он работает как прокси-сервер.

Завершение сессии.

Сообщения о завершении сессии используются только в контексте аутентификации и авторизации и только тогда, когда поддерживалось состояние сессии. Для служб работы с учетными записями вместо этого сообщения используется сообщение об остановке учета. Сообщение о завершении сессии может быть инициировано либо Diameter-клиентом, либо Diameter-сервером. Когда Diamete-клиент полагает, что нужно закрыть сессию, он передает сообщение Session-Termination-Request Diameter-серверу. В этот запрос включается AVP Termination-Clause, указывающая Diameter-серверу причину, почему сессия должна быть закрыта. В свою очередь, если Diameter-сервер обнаруживает, что сессия должна быть закрыта (возможно, из-за того, что клиент вышел за пределы предоставленного кредита, или просто для административных целей), Diameter-сервер передает сообщение Abort-Session-Request Diameter-клиенту. Однако, в зависимости от различной политики или сценариев использования, Diameter-клиент может решить не закрывать сессию, даже при получении сообщения от сервера о ее завершении, и позволить пользователю продолжать пользоваться своим сервисом [10].

TACACS (Terminal Access Controller Access Control System plus).

TACACS – результат дальнейшего усовершенствования TACACS, предпринятого Cisco. Улучшена безопасность протокола (шифрование), а также введно разделение функций аутентификации, авторизации и учёта, которые теперь можно использовать по отдельности. TACACS использует понятия сеансов. В рамках TACACS возможно установление трёх различных типов сеансов: authentication, authorization и accounting. Установление одного типа сеанса в общем случае не требует предварительного успешного установления какого-либо другого. Конкретно: спецификация протокола не требует для открытия сеанса authorization открыть сначала сеанс authentication. Сервер TACACS может потребовать authentication, но сам протокол этого не оговаривает.

Данный протокол является разработкой фирмы Cisco Systems и его реализация периодически модифицируется. Данный протокол является новым витком развития более ранних версий протоколов TACACS и XTACACS: хоть в официальных выпусках и говорится, что была просто повышена безопасность протокола, но реально весь протокол технически был переписан заново (осталась разве только идеология), поэтому не стоит путать между собой эти протоколы (в повседневной жизни и в описаниях очень часто оконечный « » опускают, откуда и появляется неразбериха; более старый протокол TACACS практически никто сейчас не использует. Протокол основан на использовании протокола TCP, поэтому потенциально медленнее RADIUS (установление TCP соединения довольно накладная операция), но за то позволяет вести мультипроцессную обработку запросов (в каждый момент времени могут обслуживаться несколько пользователей). Степень защищенности – высокая (зашифровано все тело пакета).

Для обработки какого-либо запроса TACACS сервер и клиент должны установить TCP-соединение (даже если весь процесс будет состоять из посылки и приема двух небольших пакетов), с точки зрения времени это довольно накладный процесс (именно поэтому TACACS по определению относительно медленен). Но ввиду использования протокола TCP, гарантия передачи пакета сто процентная. На основе приведенного примера, можно сразу сказать, что RADIUS будет более эффективен в сетях, где процент потерянных пакетов менее 5-10 %; в других сетях лучше использовать TACACS .

Схема работы TACACS состоит из трёх частей, которые могут работать независимо друг от друга. Опишем их работу.

Процесс аутентификации (установления сеанса authentication). Для сеанса authentication определены три типа пакетов: START, CONTINUE и REPLY. Клиент направляет серверу пакеты START и CONTINUE, сервер отвечает REPLY.

Сеанс начинается с посылки клиентом пакета START, содержащий:

а) используемый метод аутентификации: ASCII, PAP, CHAP, ARAP, MSCHAP;

б) уровень доступа, для которого будет выполняться аутентифи-кация, предопределенная на 4 уровня доступа: MIN, USER, ROOT и MAX;

в) данные (или часть, или ничего – в зависимости от метода и желания клиента) для аутентификации.

В ответ на START сервер должен послать REPLY, с одним из возможных результатов (зависящих от метода аутентификации):

− PASS – сообщение об успешном прохождении аутентификации;

− FAIL – о неудачной попытке;

− GETUSER – запрос имени пользователя. Например, если был выбран метод ASCII, но имя пользователя не было включено в пакет START;

− GETPASS – запрос пароля;

− GETDATA – запрос дополнительных сведений. Используется в других методах.

Разные методы аутентификации могут потребовать обмена различным числом сообщений между клиентом (сервером доступа) и сервером TACACS . Все последующие пакеты (после START) от клиента должны быть CONTINUE.

Клиент может прервать сеанс в любое время, установив флаг ABORT в очередном пакете CONTINUE.

Сервер может запросить переустановку сеанса (статус RESTART в пакете REPLY), а также перенаправить клиента (статус FOLLOW в пакете REPLY). В этом случае сервер в поле данных пакета передаёт список серверов.

Авторизация. Она подразумевает обмен всего двумя пакетами:

− клиент пакетом REQUEST запрашивает права на использование определённых служб;

− сервер отвечает пакетом RESPONSE, содержащим код ответа.

Сервер также может изменять параметры запроса клиента (например, авторизовать доступ, но с другим IP адресом) или добавить свои. Для этих случаев есть свои коды статуса: PASS_REPL, PASS_ADD.

Учёт. Клиент направляет серверу REQUEST, в котором определяется набор параметров учёта.

Для выбора необходимого протокола для решения поставленной задачи, а именно оптимизации процесса предоставления услуги прописки SIP абонента ниже приведена сводная таблица протоколов метода AAA

Исходя из нижестоящей таблицы 1, предпочтение целесообразно отдать протоколу RADIUS основываясь на следующих аспектах:

− протоколы TACACS и DIAMETER являются функционально перегруженными, следовательно, более требовательными к вычислительным ресурсам, что влечёт большее время отклика, а это в свою очередь является критическим показателем для системы;

− протокол RADIUS работает на основе транспортного протокола UDP, что делает его более быстродействующим (DIAMETER и TACACS используют TCP);

− протокол RADIUS использует порт 1645 или 1812 UDP для аутентификации и порт 1646 или 1813 UDP для учета активности пользователя

− протокол RADIUS позволяет перенаправлять запросы от одного RADIUS-сервера к другому;

− протокол RADIUS использует RADIUS прокси-сервер;

− в протоколе RADIUS процессы аутентификации и авторизации совмещены в один процесс RADIUS;

− протокол RADIUS шифрует только пароли;

− протокол RADIUS поддерживает технологии удаленного доступа, 802.1X и SIP.

Реализацией протокола RADIUS является RADIUS-сервер.

Таблица 1 – Сравнительный анализ рассматриваемых протоколов

3.3 Существующие модели RADIUS-серверов

Чтобы выбрать оптимальный по всем параметрам RADIUS-сервер, для оптимизации существующей схемы предоставления услуги SIP телефонии, необходимо рассмотреть и сравнить существующие сервера. Так как RADIUS сервером является прикладное программное обеспечение, необходимо рассмотреть наиболее популярные из них: Radiator steal belt radius server, Softpi radius, Tekradius, Clear box, Freeradius.

Radiator Steal Belt RADIUS server.

Радиатор поддерживает широкий спектр функций, которых нет во многих других серверов RADIUS:

− максимальная гибкость и возможность настройки с веб-графического интерфейса и мониторинга;

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

− неограниченное число пользователей;

− производительность и масштабируемость для больших систем;

− поддержка IPv4 и IPv6 на RADIUS, прокси-сервер, TACACS , SNMP;

− поддержка VOIP аутентификации: совместимая с Asterisk, SIP Express.

Поддерживает несколько методов аутентификации EAP, используемые в беспроводных локальных сетях 802.1X. Это означает, можно легко настроить безопасную аутентификацию беспроводной связи. Может выступать в качестве шлюза между PEAP-mschapv2 клиентов и не-EAP серверов RADIUS. Поддерживает Novell Edirectory с универсальными паролями. Универсальные пароли могут быть использованы с PAP, CHAP, MSCHAP, mschapv2, TLS, TTLS-*, PEAP, EAP-MD5 и т.д.

Прост в создании веб-отчетов для анализа пользовательских сессий. Поддерживает SNMP Radius IETF MIB Сервера: собирает статистику с сервера по SNMP. Полный набор алгоритмов балансировки нагрузки для RADIUS прокси-серверов. Автоматически распределяет IP адреса из базы данных SQL и DHCP. Поддерживает ADSL. Поддерживает GPRS.

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

− any Unix including Linux (Red Hat, Debian, Mandrake, SuSE, Lindows, Slackware, Ubuntu etc on Intel, Sparc, PPC, HP-PA etc), FreeBSD, NetBSD, SunOS, AIX, IRIX, SCO Open Server, Digital, HP-UX, etc;

− solaris 8, 9, 10. 32-Bit or 64-Bit. SPARC or Intel;

− windows 95, 98, NT, 2000, ME, XP, 2003, 2008, etc;

− mac OS9, Mac OS X;

Radiator работает с любой базой данных SQL, которая имеет Perl DBD поддержку:

− oracle;

− informix;

− Sybase;

− MySQL;

− microsoft SQL including versions 6.5, 7, 2000 and 2005;

− ODBC;

− interbase;

− SAP;

− PostgreSQL;

− SQLite.

Radiator поддерживает многие системы биллинга, включая:

− platypus;

− emerald;

− engageIP (previously Hawk-i) ;

− billmax;

− rodopi;

− freeside;

− ISPBill;

− advanced ISP billing;

− micros-fidelio opera;

− property management system;

− jet ISP billing.

SoftPI RADIUS.

Сис­те­ма Soft­PI RA­DI­US предс­тав­ля­ет со­бой RA­DI­US-сер­вер, ра­бота­ющий под опе­раци­он­ны­ми сис­те­мами Win­dows и пред­назна­чен­ный для вы­пол­не­ния функ­ций аутен­ти­фика­ции, ав­то­риза­ции и уче­та поль­зо­вате­лей при подк­лю­чении и ис­поль­зо­вании ре­сур­сов ин­тернет/инт­ра­нет в со­от­ветс­твии с RFC 2865, 2866, 2868, 2869, 2548, 3748 и 5176. Soft­PI RA­DI­US сер­вер мо­жет ис­поль­зо­вать­ся для про­вод­ных и бесп­ро­вод­ных (Wi-Fi) поль­зо­вате­лей, для поль­зо­вате­лей VPN се­тей и дру­гих се­тевых ре­сур­сов.

Soft­PI RA­DI­US сер­вер яв­ля­ет­ся ре­али­заци­ей RA­DI­US сер­ве­ра для опе­раци­он­ных сис­тем се­мей­ства Win­dows 2000/XP/2003/Vis­ta/2008/7. Под­держи­ва­ют­ся ос­новные функ­ции RA­DI­US сер­ве­ра: аутен­ти­фика­ция (Aut­henti­cati­on), ав­то­риза­ция (Aut­ho­riza­ti­on) и учет ис­поль­зу­емых ре­сур­сов (Ac­co­un­ting).

Под­держи­ва­ют­ся сле­ду­ющие про­токо­лы аутен­ти­фика­ции поль­зо­вате­лей:

− PAP;

− CHAP;

− MS-CHAP v2;

− EAP-MD5;

− EAP-MS-CHAP v2;

− PE­AP MS-CHAP v2.

Гиб­кая наст­рой­ка па­рамет­ров аутен­ти­фика­ции и ав­то­риза­ции поль­зо­вате­лей:

− зна­чения ат­ри­бутов поль­зо­вате­ля при­вязы­ва­ют­ся к уст­рой­ству доступа;

− воз­можность за­дания пра­вила для про­вер­ки зна­чения ат­ри­бута;

− под­держи­ва­ют­ся спе­цифи­чес­кие ат­ри­буты про­из­во­дите­ля (Ven­dor-Spe­cific ат­ри­буты). Сис­те­ма со­дер­жит бо­лее 30 шаб­ло­нов ат­ри­бутов раз­личных про­из­во­дите­лей: 3COM, Al­ca­tel, Cis­co, Ju­niper, HP, Mic­ro­soft, Ava­ya-Nor­tel.

В Soft­PI RA­DI­US сер­вер ре­али­зован учет ис­поль­зу­емых поль­зо­вате­лями ре­сур­сов в со­от­ветс­твии с RFC 2866, что мо­жет ис­поль­зо­вать­ся при вза­имо­дей­ствии с бил­линго­выми сис­те­мами. Эта функ­ция ин­тегри­рова­на с бил­линго­вым комп­лек­сом Ta­ris­co­pe 3.5 (Soft­PI).

Все наст­рой­ки па­рамет­ров Soft­PI RA­DI­US осу­щест­вля­ют­ся в удоб­ном графичес­ком ин­терфей­се. Имеется возможность контролировать сессии пользователей: воз­можность раз­ры­ва сес­сии поль­зо­вате­ля пу­тем за­дания ее дли­тель­нос­ти.

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

Soft­PI RA­DI­US под­держи­ва­ет воз­можность синх­ро­низа­ции поль­зо­вате­лей и их ат­ри­бутов, ис­поль­зуя про­токол LDAP, нап­ри­мер, с Ac­ti­ve Di­rec­to­ry.

Soft­PI RA­DI­US со­дер­жит ре­жим, обес­пе­чива­ющий по­луче­ние ин­форма­ции о его ра­боте. При этом ад­ми­нист­ра­тор Soft­PI RA­DI­US мо­жет с по­мощью филь­тра за­дать лю­бые ус­ло­вия филь­тра­ции ин­форма­ции и при­менить слож­ные ус­ло­вия сор­ти­ров­ки ин­форма­ции.

От­чет мо­жет быть экс­пор­ти­рован в один из сле­ду­ющих фор­ма­тов: PDF, Ex­cel (Mic­ro­soft), HTML, текс­то­вый. Име­ет­ся воз­можность пред­ва­ритель­но­го прос­мотра от­че­та и его рас­пе­чат­ки.

В це­лях бе­зопас­ности ад­ми­нист­ри­рова­ние Soft­PI RA­DI­US сер­ве­ра вы­пол­ня­ет­ся с ис­поль­зо­вани­ем SSL про­токо­ла. Ра­бота это­го про­токо­ла ос­но­выва­ет­ся на сер­ти­фика­те. Ис­поль­зо­вание та­кого сер­ти­фика­та поз­во­ля­ет вы­пол­нить про­вер­ку под­линнос­ти сер­ве­ра и шиф­ро­вать об­мен дан­ны­ми при ад­ми­нист­ри­рова­нии. Сер­ти­фикат мож­но при­об­рести в цент­ре сер­ти­фика­ции, ис­поль­зо­вать кор­по­ратив­ный сер­ти­фикат, под­пи­сан­ный до­верен­ным цент­ром сер­ти­фика­ции ли­бо ис­поль­зо­вать са­мопод­пи­сан­ный сер­ти­фикат.

В це­лях за­щиты от атак на Soft­PI RA­DI­US сер­вер в нем пре­дус­мотре­на воз­можность бло­киро­вания поль­зо­вате­ля в слу­чае мно­гок­ратных не­удач­ных по­пыток аутен­ти­фика­ции.

TekRADIUS.

TekRADIUS является RADIUS сервер для Windows с встроенным сервером DHCP. TekRADIUS тестируется на Microsoft Windows XP, Vista, Windows 7 и Windows 2003-2008 сервере.

Основные характеристики:

− поддержка функции, описанные в RFC 2865 и RFC 2866 (RADIUS протокол);

− журналы системных сообщений, ошибок и информацию о сессии содержатся в лог-файлах;

− существует возможность ограничения числа одновременных сессий для пользователей;

− порты аутентификации и учета могут быть выбраны пользователем;

− существует возможность создания SQL базы данных и таблиц через TRManager GUI;

− существует возможность сопоставления атрибутов RADIUS Accounting к полям таблице учета;

− поддерживает следующие протоколы аутентификации: PAP, CHAP, MS-CHAP v1-v2, EAP-MD5, EAP-TLS, EAP-MS-CHAP v2, PEAP (PEAPv0-EAP-MS-CHAP v2) и Digest (проект-Стерман-AAA-SIP-00.txt);

− генерирует MS-MPPE ключи для соединений VPN;

− поддерживает OTP (One Time Password) аутентификацию на основе RFC 2289;

− имеет встроенный DHCP-сервер;

− существует возможность аутентификации пользователей домена Windows или Active Directory;

− утилита командной строки для добавления, удаления и редактирования пользователей;

− простой интерфейс для просмотра отчетности Бухгалтерский учет;

− существует возможность задания времени, в течение которого пользователю будет доступна информация после первого входа в систему, а так же можно указать разрешенные дни и часы для возможности использования услуги;

− отключение профиль пользователя после выхода настраивается пользователем количества неудачных попыток входа в систему;

− можно задать кредитные лимиты для ежедневных, еженедельных или ежемесячных периодов;

− можно запустить и проверить результат внешнего исполняемого как контрольно-пропускном пункте;

− быстрая и простая установка.

Clear Box.

ClearBox поддерживает богатые возможности аутентификации и может выполнять проверку подлинности с использованием:

− LDAP directories (MS Active Directory, OpenLDAP, Novell eDirectory, etc);

− Windows NT/2000/2003/2008 Active Directory домена и рабочих групп;

− MS SQL Server, MS Access, MySQL, Oracle, PostreSQL.

ClearBox RADIUS сервер поддерживает IEEE 802.1x аутентификации для обеспечения безопасных и надежных служб аутентификации в WEP/WPA/WPA2 защищенных беспроводных сетей. Он поддерживает все протоколы, поддерживаемые Windows. Работа с цифровыми сертификатами может стать слишком сложной, особенно для сотрудников, которые не имеют опыта работы с ними. ClearBox предоставляет простой в использовании мастер, который помогает создать сертификат или подготовить запрос на некоторых сертификации.

ClearBox Сервер является гибкой системой и может быть легко интегрирован практически во все биллинговые системы поддержки RADIUS сервера аутентификации. В настоящее время полная совместимость со следующими биллинг системами:

− DTH биллинга и управления по DTH программного обеспечения. Система подходит для VoIP провайдера и биллинга. Она может похвастаться большим количеством полезных возможностей, как настраиваемый отчетности, электронной почте или бумажных счетов, электронный перевод средств, веб-порталы, обработка коллекций, сервисные заказы и многое другое;

− расширенный ISP Billing по AdvancedISPBilling.com, эффективный и настраиваемый биллинговой системы для малых и крупных провайдеров;

− platypus Billing System, общее решение биллинга и управления клиентами создан специально для Интернет-провайдеров и хостинг-компаний;

− RADREP by RADIUS Reporting, простой в использовании графический интерфейс Windows приложение.

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

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

FreeRADIUS.

Это альтернатива для других коммерческих RADIUS серверов, поскольку он является самым функциональным и модульным на сегодняшний день. Кроме того, он входит в пятёрку RADIUS серверов мира с точки зрения развёртывания и количества пользователей, которых этот сервер авторизует ежедневно

Может работать на встраиваемых системах с небольшим количеством памяти, обслуживая несколько миллионов пользователей. FreeRADIUS быстрый, гибкий, настраиваемый, а также поддерживает больше протоколов аутентификации, чем многие коммерческие серверы. Сервер поставляется вместе с инструментом управления через веб-интерфейс dialup admin, который написан на PHP. В настоящее время FreeRADIUS используется как основа для разработки коммерческих RADIUS серверов.

Модули ядра сервера поддерживают LDAP, MySQL, PostgreSQL, Oracle и многие другие базы данных. Он поддерживает все популярные типы аутентификации EAP, включая PEAP и EAP-TTLS. Для обеспечения совместимости с широким спектром устройств NAS в него включены более 100 словарей поставщиков.

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

Для более привычного и удобного восприятия информации ниже находится таблица RADIUS-серверов.

Исходя из таблицы 2 можно сделать вывод, что сервер FreeRADIUS наиболее подходит к решению поставленной задачи, а именно к включению RADIUS-сервера в существующую систему NGN сети, на основе следующих характеристик:

− поддержка не только стандартной Windows платформы, но и альтернативных;

− использует не только все необходимые протоколы аутентификации, но и протоколы шифрования;

− поддержка баз данных Oracle, которую использует программа АСР «Старт» и SQL, которую использует Softswitch, возможность конвертирования их;

− бесплатный продукт, отсутствуют затраты на покупку системы;

− поддерживает производителя Huawei, на котором базируется вся существующая системa связи NGN.

С использованием RADIUS-сервера изменится структурная схема, изображенная на рисунке 21.

Рисунок 21 – Структурная схема предоставления услуги SIP телефонии с RADIUS-сервером

С момента включения RADIUS-сервера структура оказания услуги претерпевает изменение. Вместо отправки наряда в отдел АТС, для прописки SIP абонента во внутреннюю базу Softswitch, теперь данную функцию будет выполнять RADIUS-сервер. RADIUS-сервер будет синхронизироваться раз в день с базой программы АСР «Старт» для занесения абонента в свою локальную базу.

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

Теперь, если при физическом подключении абонента возникнет ошибка с авторизацией пользователя, то монтеру нет необходимости звонить на АТС, узнавать пришел на наряд к ним на обработку, или правильно ли менеджер указал настройки в программе АСР «Старт», что бы наряд попал в отдел электронных АТС и т.д.

Монтеру, при возникновении ошибки с авторизацией в настоящий момент, необходимо только проверить сторону СПД и настройки на клиентском оборудовании – это заметно ускорит темпы обслуживания клиентов.

Функциональная схема технологического процесса предоставления услуги SIP телефонии, с использованием RADIUS-сервера представлена в приложении Б.

На рисунке 22 изображен процесс синхронизации базы АСР «Старт» и базы данных Softswitch, с использованием RADIUS-сервера.

Рисунок 22 – Функциональная схема заведения SIP номера в базу Softswitch

При рассмотрении полученных схем с использованием RADIUS-сервера видно, что по сравнению, с используемой в текущий момент моделью прописки, были исключены, лишние, архаичные и избыточные связи тем самым оптимизировав процесс предоставления услуги создания SIP абонента.