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

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО

ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

ТОМСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ СИСТЕМ

УПРАВЛЕНИЯ И РАДИОЭЛЕКТРОНИКИ (ТУСУР)

Кафедра комплексной информационной безопасности электронно-

вычислительных систем (КИБЭВС)

ОТЧЕТ

по преддипломной практике

Предотвращение несанкционированного доступа в ЛВС предприятия с применением защитной архитектуры на базе протоколов ААА

Выполнил: студент гр. З-78-1

П. А. Козлов

Руководитель практики:

Начальник ОИТиС

М. В. Парамошин

Томск 2014



ЗАДАНИЕ

по дипломному проектированию студенту Козлову Павлу Андреевичу группа з-78-1 институт системной интеграции и безопасности

1. Тема проекта (работы): Предотвращение несанкционированного доступа ЛВС предприятия с применением защитной архитектуры на базе протоколов ААА

2. Срок сдачи студентом законченного проекта: 17 марта 2014 года

3. Исходные данные к проекту: ЛВС предприятия КБ-81 (КДЦ №1) и тестовое оборудование

4. Содержание расчетно-пояснительной записи (перечень подлежащих разработке вопросов): обзор проблемы исследования и постановка задачи, предотвращение не санкционированного доступа в ЛВС предприятия на базе протоколов ААА

5. Дата выдачи задания: 17 февраля 2014 года

Начальник ОИТиС _____________________

Начальник ОИТиС Максим Викторович Парамошин

Задание принял к исполнению: 17 февраля 2014 года_____________



СОДЕРЖАНИЕ

Введение

1. Цели производственной практики

1.1 Изучение и анализ информационной сети предприятия

2. Исследование сети и выявление угроз (несанкционированный доступ к сети)

2.1 Сравнительный анализ ПО для решения поставленной задачи

3. Технические особенности

3.1 Сервера TACACS

3.2 Сервер RADIUS

3.3 Сервер DIAMETER

4. Программная реализация сервера RADIUS

4.1 Настройка сервера

4.2 Настройка активного сетевого оборудования

4.3 Тестирование защиты от несанкционированного доступа

Заключение

Список используемой литературы



ВВЕДЕНИЕ

В настоящее время существуют различные технологии, направленные на обеспечение безопасности данных, в котором выделяются 3 важнейших компонента:

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

2. сохранение целостности данных (их неизменность и конфиденциальность обеспечивается безопасностью инфраструктуры сети)

3. активная проверка установленной политики безопасности

В данной курсовой работе все внимание обращено на первый компонент - аутентификацию.

Первым и наиболее распространенным до сих пор средством проведения аутентификации было использование паролей. Для обеспечения высокого уровня безопасности пароли необходимо часто менять, а криптографически стойкие пароли неудобны для запоминания пользователями, что в итоге привело к формированию методики использования одноразовых паролей. Среди них: аутентификация по протоколу S/Key или при помощи специальных аппаратных средств: смарт-карт, USB-токенов и т.д. Для модемного доступа наиболее распространен механизм аутентификации по протоколу PPP с использованием протоколов PAP, CHAP и EAP. Протокол EAP продолжают усовершенствовать с целью расширения его функциональности, но в настоящее время он уже позволяет более гибко использовать как существующие, так и будущие технологий аутентификации в каналах PPP. А в среде корпоративного удаленного доступа большое распространение получили протоколы, которые поддерживают масштабируемые решения в области аутентификации - Remote Access Dial-In User Service (RADIUS) и TACACS.



1. ЦЕЛИ ПРОИЗВОДСТВЕННОЙ ПРАКТИКИ

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

Необходимо обеспечить:

Общие

Создание и хранение учётных записей пользователей (абонентов)

Управление учётной записью пользователя (абонента) из персонального интерфейса (например веб-кабинета)

Ручная и автоматическая блокировка учётной записи абонента по достижению заданного критерия или лимита

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

Создание отчётов по различным статистическим параметрам

Создание, печать и отправка счетов к оплате

Аутентификация

Проверка учётных данных пользователя (в том числе шифрованных) по запросу обслуживаемой системы

Авторизация

Выдача состояния блокировки учётной записи пользователя

Выдача разрешения к той или иной услуге

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

Учёт (Accounting)

Онлайн-учёт средств абонента: уведомления о начале и конце сессии со стороны обслуживаемой системы

Промежуточные сообщения о продолжении сессии

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

BOOT message -- специальный пакет, который отправляется телекоммуникационной системой на RADIUS-сервер при запуске (перезапуске) системы, с целью принудительного завершения всех сессий

1.1 Изучение и анализ информационной сети предприятия

сеть сервер защита доступ

Предприятие: в КБ-81 входит 16 медицинских учреждений, 11 находятся в г. Северске, остальные за её пределами.

Сервера и рабочие станции: физических серверов во всех медучреждениях входящих в состав КБ-81 насчитывается более 40, виртуальных более 120, рабочих станций более 1400 ПК,

Сеть: работу сети обеспечивают более 100 коммутаторов, 30 медиа-конвертеров, имеет доменную структуру, связывающие медицинские учреждения “туннелями” имеющих скорость 10ГБит/сек (которая обеспечивается медиа-конвертерами 10G).



2. ИССЛЕДОВАНИЕ СЕТИ И ВЫЯВЛЕНИЕ УГРОЗ (НЕСАНКЦИОНИРОВАННЫЙ ДОСТУП К СЕТИ)

Угрозы и уязвимые места

Идентификация угроз предполагает рассмотрение воздействий и последствий реализации угроз. Воздействие угрозы, которое обычно включает в себя проблемы, возникшие непосредственно после реализации угрозы, приводит к раскрытию, модификации, разрушению или отказу в обслуживании. Более значительные долговременные последствия реализации угрозы приводят к потере бизнеса, нарушению тайны, гражданских прав, потере адекватности данных, потере человеческой жизни или иным долговременным эффектам. Последствия угроз будут обсуждаться в разделе 3, Управление риском. Подход, описываемый здесь, состоит в классификации типов воздействий, которые могут иметь место в ЛВС, так чтобы специфические технические угрозы могли быть сгруппированы по своим воздействиям и изучены некоторым образом. Например, такие технические угрозы, реализация которых влечет воздействие “Компрометация трафика ЛВС”, могут быть отделены от тех угроз, которые влекут воздействие “Нарушение функционирования ЛВС”. Следует понимать, что реализация многих угроз приводит к более чем одному воздействию, однако в рамках этого обсуждения каждая угроза будет рассматриваться в связи только с одним воздействием. Воздействия, которые будут использоваться для классификации и обсуждения угроз среде ЛВС:

Неавторизованный доступ к ЛВС - происходит в результате получения неавторизованным человеком доступа к ЛВС.

Несоответствующий доступ к ресурсам ЛВС- происходит в результате получения доступа к ресурсам ЛВС авторизованным или неавторизованным человеком неавторизованным способом.

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

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

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

Подмена трафика ЛВС - происходит в результате появлений сообщений, которые имеет такой вид, как будто они посланы законным заявленным отправителем, а на самом деле сообщения посланы не им.

Неработоспособность ЛВС - происходит в результате реализации угроз, которые не позволяют ресурсам ЛВС быть своевременно доступными.

Неавторизованный доступ к ЛВС

ЛВС обеспечивает совместное использование файлов, принтеров, файловой памяти и т.п. Поскольку ресурсы разделяемы и не используются монопольно одним пользователем, необходимо управление ресурсами и учет использования ресурсов. Неавторизованный доступ к ЛВС имеет место, когда кто-то, не уполномоченный на использование ЛВС, получает доступ к ней (действуя обычно как законный пользователь ЛВС). Три общих метода используются, чтобы получить неавторизованный доступ: общие пароли, угадывание пароля и перехват пароля. Общие пароли позволяют неавторизованному пользователю получить доступ к ЛВС и привилегии законного пользователя; это делается с одобрения какого-либо законного пользователя, под чьим именем осуществляется доступ . Угадывание пароля является традиционным способом неавторизованного доступа. Перехват пароля является процессом, в ходе которого законный пользователь, не зная того, раскрывает учетный идентификатор пользователя и пароль. Это может быть выполнено с помощью программы троянского коня, которая имеет для пользователя вид нормальной программы входа в ЛВС; однако программа - троянский конь предназначена для перехвата пароля. Другим методом, обычно используемым для перехвата пароля, является перехват пароля и идентификатора пользователя, передаваемых по ЛВС в незашифрованном виде. Методы перехвата открытого трафика ЛВС, включая пароли, широко доступны сегодня. Неавторизованный доступ к ЛВС может происходить с использованием следующих типов уязвимых мест:

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

2.1 Сравнительный анализ ПО для решения поставленной задачи

В данный момент на рынке присутствует несколько протоколов типа “ААА”

AAA (от англ. Authentication, Authorization, Accounting) -- используется для описания процесса предоставления доступа и контроля за ним.

RADIUS

DIAMETER

TACACS

TACACS+



3. ТЕХНИЧЕСКИЕ ОСОБЕННОСТИ

3.1 Сервера TACACS

Имеется три версии приложений сервера защиты TACACS.

TACACS (Terminal Access Controller Access Control System - система управления доступом к контроллеру терминального доступа). Описанный в документе RFC 1492 промышленный стандарт протокола, предполагающий передачу имени пользователя и пароля централизованному серверу. Централизованный сервер может представлять собой либо базу данных TACACS, либо базу данных типа файла паролей UNIX с поддержкой протокола TACACS. Например, сервер UNIX с поддержкой TACACS может передавать запросы базе данных UNIX и возвращать сообщения подтверждения или отказа серверу доступа.

XTACACS. Определяет расширения, добавленные Cisco к протоколу TACACS для поддержки новых и расширенных возможностей. Стандарт XTACACS является многопротокольным; он поддерживает авторизацию соединений, использующих SLIP, режим enable, PPP (IP или IPX), ARA, EXEC и Telnet.

XTACACS поддерживает отправку информации аудита хосту UNIX от множества серверов TACACS и syslog, соединяет пользователя с "оболочкой" сервера доступа в соответствии с результатами аутентификации, а также может инициализировать соединения Telnet, SLIP, PPP или ARA после начальной аутентификации.

XTACACS был вытеснен TACACS+

TACACS+. Улучшенная и постоянно совершенствуемая версия TACACS позволяет серверу TACACS+ обеспечивать независимое использование сервисов AAA. Поддержка AAA является модульной, так что каждая из возможностей по существу является отдельным сервером. Каждый сервис может связываться со своей базой данных либо использовать другие сервисы сервера или сети. Поддержка TACACS+ появилась в Cisco IOS Release 10.3 (В настоящее время в ходу Release 12. x).

TACACS+ представляет собой совершенно новую версию протокола TACACS, ссылающуюся на документ RFC 1492 и разрабатываемую Cisco. Он несовместим с XTACACS. TACACS+ был представлен на рассмотрение IETF (Internet Engineering Task Force - проблемная группа проектирования Internet) в качестве проекта стандарта.

TACACS и XTACACS в программном обеспечении Cisco IOS официально представлены как протоколы, дальнейшее сопровождение и совершенствование которых компания Cisco прекращает. Кроме того, сопровождение бесплатно предлагаемого Cisco программного кода сервера TACACS и XTACACS тоже официально прекращено. Дальнейшее совершенствование и сопровождение этих продуктов компанией Cisco не планируется. Однако активное независимое сообщество пользователей уже предлагает некоторые усовершенствования этих протоколов.

Принцип работы

TACACS+ - это протокол третьего поколения в семействе протоколов TACACS (RFC 1492). TACACS (Terminal Access Controller Access Control System) - это протокол удаленной аутентификации, который применяется в процессе предоставления доступа к информационным серверам, серверам удаленного доступа и другим активным сетевым устройствам. Он был разработан U. S. Department of Defense и BBN Planet corp. (Bolt, Beranek and Newman, Inc). В дальнейшем он несколько раз дорабатывался компанией Cisco Systems Inc.

TACACS+ представляет собой приложение сервера защиты, позволяющее на основе соответствующего протокола реализовать централизованное управление доступом пользователей к серверу сетевого доступа, маршрутизатору или другому сетевому оборудованию, поддерживающему TACACS+. Информация о сервисах TACACS+ и пользователях хранится в базе данных, обычно размещаемой на компьютере под управлением UNIX или Windows NT (Windows 2000/2003).

Рис.1. Поддержка TACACS+ или RADIUS сервером сетевого доступа, маршрутизатором и удаленной базой данных защиты

В своей работе протоколы семейства TACACS используют порт 49, который выделило для них Internet Assigned Numbers Authority (IANA). Предыдущие версии TACACS (как и аналогичный протокол RADIUS) в качестве средства доставки использовали протокол UDP. В отличие от них, TACACS+ полагается на TCP, что позволяет за счет несколько больших накладных расходов обеспечить более простую реализацию и расширить функциональность (например, поддерживается множественная обработка запросов).

TACACS+ - это протокол, реализованный по технологии клиент-сервер, причем почти всегда клиент - это NAS (Network Access Server - сервер сетевого доступа; например, Cisco AS5300 и Shiva Corp. 's Access Manager 3.0), а сервер - некоторая программа, запущенная на хост-машине (UNIX, NT или другая, необходимо отметить что UNIX системы наиболее распространены в роли серверов TACACS+). Примером таких серверов являются CiscoSecure Access Control Server (ACS) и Shiva's LAN Rover/E Plus.

Протокол TACACS+ позволяет объединить несколько NAS в общую систему обеспечения аутентификации в рамках системы обеспечения сетевой безопасности, функционируя в 2 режимах:

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

2. посредничество для внешних систем аутентификации (т. н. proxy-режим).

Благодаря этому он может использоваться и в глобальных системах предоставления безопасного сетевого доступа, таких как CiscoSecure Global Roaming Server (GRS).

Принципиально важной особенностью протокола TACACS+ является то, что он позволяет разделить аутентификацию, авторизацию и учет (AAA - Authentication, Authorization, Accounting) и реализовать их на отдельных серверах. Это является существенным прогрессом по сравнению как с исходным протоколом TACACS, в который понятие учета вообще не входило, так и с протоколом RADIUS, в котором аутентификация и авторизация совмещены.

Свойства TACACS+

TACACS+ поддерживает следующие возможности сервера защиты.

Пакеты TCP для надежной передачи данных. Использование TCP в качестве протокола связи для соединений TACACS+ между сервером сетевого доступа и сервером защиты. Для TACACS+ резервируется ТСР-порт 49.

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

Канальное шифрование. Часть TCP-пакета, содержащая данные протокола TACACS+, шифруется с целью защиты трафика между сервером сетевого доступа и сервером защиты.

Каждый пакет TACACS+ имеет 12-байтовый заголовок, пересылаемый в виде открытого текста, и тело переменной длины, содержащее параметры TACACS+. Тело пакета шифруется с помощью алгоритма, использующего псевдослучайный заполнитель, получаемый посредством MD5. Пакеты TACACS+ передаются по сети и хранятся сервером TACACS+ в шифрованном виде. Когда это необходимо, пакет дешифруется сервером сетевого доступа или приложением TACACS+ путем обращения алгоритма шифрования.

Аутентификация РАР и CHAP. Обеспечивает полный контроль аутентификации с помощью средств вызова/ответа РАР и CHAP, а также посредством использования диалоговых окон ввода пароля доступа и поддержки сообщений интерактивной процедуры начала сеанса.

Защита локальных и глобальных сетей. Поддержка средств AAA удаленного и локального сетевого доступа для серверов сетевого доступа, маршрутизаторов и другого сетевого оборудования, поддерживающего TACACS+. Дает возможность осуществлять централизованное управление сетевым оборудованием.

Протоколы инкапсуляции для удаленного доступа. Поддерживают использование SLIP, РРР и ARAP, а также адресацию TN3270 и X.121 в рамках Х.25.

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

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

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

Процесс аутентификации TACACS+

Заголовок пакета TACACS+ содержит поле типа, являющееся признаком того, что пакет представляет собой часть процесса ААА. Аутентификация TACACS+ различает три типа пакетов: START (начало), CONTINUE (продолжение) и REPLY (ответ). Рассмотрим процесс аутентификации TACACS+, в котором сервер сетевого доступа обменивается пакетами аутентификации с сервером TACACS+ (рис. 2).

Рис. 2. Процесс аутентификации TACACS+

Сервер сетевого доступа посылает пакет START серверу защиты TACACS+, чтобы начать процесс аутентификации.

Процесс аутентификации на сервере защиты TACACS+ обычно возвращает серверу сетевого доступа пакет GETUSER, содержащий запрос имени пользователя.

Сервер сетевого доступа запрашивает имя пользователя и посылает введенное имя серверу защиты TACACS+ в пакете CONTINUE.

Сервер защиты TACACS+ посылает серверу сетевого доступа пакет GETPASS, содержащий запрос пароля. Сервер сетевого доступа выдает запрос пароля пользователю.

Сервер сетевого доступа посылает серверу защиты TACACS+ пакет CONTINUE, содержащий пароль, введенный пользователем.

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

Процесс авторизации TACACS+

В процессе авторизации TACACS+ используется два типа пакетов: REQUEST (запрос) и RESPONSE (ответ). Данный процесс авторизации пользователя контролируется посредством обмена парами "атрибут/значение" между сервером защиты TACACS+ и сервером сетевого доступа. Рассмотрим процесс авторизации TACACS+, в котором сервер сетевого доступа обменивается пакетами авторизации с сервером TACACS+ (рис. 3).

Рис. 3. Процесс авторизации TACACS+

Сервер сетевого доступа посылает пакет REQUEST серверу защиты TACACS+. Данный пакет содержит фиксированный набор полей, идентифицирующих пользователя или процесс, а также переменный набор аргументов, описывающих сервисы и параметры, необходимые для авторизации.

Сервер защиты TACACS+ возвращает серверу сетевого доступа пакет RESPONSE, содержащий переменный набор аргументов ответа (пары "атрибут/значение"). Эти пары строятся на основе ранее заданных разрешений для данного пользователя, хранимых в файле конфигурации TACACS+. Вот несколько примеров таких пар.

service = ррр - исходно доступный сервис

protocol = ip - протокол, доступный для использования с указанным сервисом

addr = 172.16.10.1 - авторизованный сетевой адрес

timeout = 12 - абсолютный таймер, ограничивающий длительность соединения в минутах

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

Процесс аудита TACACS+

В процессе аудита TACACS+ используется два типа пакетов - REQUEST (запрос) и RESPONSE (ответ). Данный процесс во многом подобен процессу авторизации. В процессе аудита создаются записи с информацией об активности пользователя в отношении заданных сервисов. Записи, регистрирующие выполненные сетевым оборудованием действия, могут сохраняться в некотором стандартном формате, например в файле. csv (comma-separated value - разделенные запятыми значения), на сервере защиты с целью дальнейшего анализа.

В рамках TACACS+ аудит ААА не является средством надежной защиты и обычно используется только для учета или управления. Однако с помощью аудита ААА можно контролировать действия пользователя, чтобы, например, вовремя заметить его необычное поведение при работе с сетевым оборудованием. Рассмотрим процесс аудита TACACS+, в котором сервер сетевого доступа обменивается пакетами аудита с сервером TACACS+ (рис.4).

Рис. 4. Процесс аудита TACACS+

Сервер сетевого доступа посылает серверу защиты TACACS+ пакет REQUEST аудита, содержащий фиксированный набор полей, идентифицирующих пользователя или процесс.

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

Сервер защиты TACACS+ посылает серверу доступа пакет RESPONSE и подтверждает получение контрольной записи. Этот пакет указывает, что функция аудита на сервере защиты TACACS+ выполнена и что запись создана и сохранена.

3.2 Сервер RADIUS

Название RADIUS является аббревиатурой от Remote Authentication Dial In User Service и представляет собой сетевой протокол, обеспечивающий централизованную Аутентификацию (Authentication), Авторизацию (Authorization) и Учет используемых сетевых ресурсов (Accounting). В англоязычной литературе для этих трех функций (Authentication, Authorization, Accounting)используется аббревиатура ААА.

Под Аутентификацией понимается процесс, позволяющий идентифицировать пользователя по его данным, например, по логину (имя пользователя, номер телефона и т.д.) и паролю.

Авторизация - процесс, в течение которого определяются полномочия идентифицированного пользователя на доступ к определённым сетевым ресурсам.

Термин Учет использованных сетевых ресурсов уже сам по себе достаточно информативен. Первичными данными, которые передаются по протоколу RADIUS, являются объемы входящего и исходящего трафиков при передаче данных, и длительность разговора и набранный номер при использовании IP телефонии. Кроме определенных в протоколе стандартных атрибутов (параметров), протокол предусматривает возможность использования производителем оборудования (вендором) собственных атрибутов. В англоязычной литературе они называются Vendor Specific Attributes или VSA.

Протокол RADIUS был разработан компанией Livingston Enterprises (конкретно Карлом Ригней/Carl Rigney) для удаленного коммутируемого доступа через сетевые сервера доступа (Network Access Server - NAS) этой компании серии PortMaster к сети internet. Позже, в 1997, протокол RADIUS был опубликован как RFC 2058 и RFC 2059. Текущие версии RFC 2865 (Remote Authentication Dial In User Service (RADIUS)) и RFC 2866 (RADIUS Accounting). Иногда вместо понятия "сетевой сервер доступа" используется другой: "удаленный сервер доступа" (Remote Access Server - RAS).

В настоящее время протокол RADIUS используется для доступа к виртуальным частным сетям (VPN), точкам беспроводного (Wi-Fi) доступа, Ethernet коммутаторам, DSL и другим типам сетевого доступа. Благодаря открытости, простоте внедрения, постоянному усовершенствованию, протокол RADIUS сейчас является фактически стандартом для удаленной аутентификации.

Аутентификация и авторизация

Для выяснения работы RADIUS протокола рассмотрим рисунок 5.



Рисунок 5

Ноутбуки и IP телефон, представляют устройства пользователя, с которых необходимо выполнить аутентификации и авторизации на сетевых серверах доступа (NAS):

точке Wi-Fi доступа,

маршрутизаторе,

VPN сервере и

IP АТС.

На рисунке показаны не все возможные варианты NAS. Существуют и другие сетевые устройства доступа.

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

Пользователь посылает запрос на сетевой сервер доступа для получения доступа к определенному сетевому ресурсу, используя сертификат доступа. Сертификат посылается на сетевой сервер доступа через сетевой протокол канального уровня (Link Layer), например, Point-to-Point Protocol (PPP) в случае выполнения коммутируемого доступа, Digital Subscriber Line (DLS) - в случае использования соответствующих модемов и т.п. NAS после этого, в свою очередь, посылает сообщение запроса доступа на RADIUS сервер, так называемый RADIUS Access Request. Этот запрос включает сертификаты доступа, которые обычно представлены в виде имени пользователя и пароля или сертификата безопасности, полученных от пользователя. Кроме этого запрос может содержать дополнительные параметры, такие как сетевой адрес устройства пользователя, его телефонный номер, информацию о физическом адресе, с которого пользователь взаимодействует с NAS.

RADIUS сервер проверяет эту информацию на корректность, используя такие схемы аутентификации, как PAP, CHAP, EAP и т.п.

Кратко опишем эти протоколы.

PAP (Password Authentication Protocol) (RFC1334)- простой аутентификационный протокол, который используется для аутентификации пользователя по отношению к сетевому серверу доступа (NAS). РАР используется РРР протоколом. Практически все сервера доступа поддерживают РАР. РАР передает незашифрованный пароль через сеть и, следовательно, является незащищенным протоколом. Поэтому РАР, обычно, используется в том случае, когда сервер не поддерживает защищенные протоколы, такие как СНАР, ЕАР и т.п.

CHAP (англ. Challenge Handshake Authentication Protocol) (RFC 1994) -- широко распространённый алгоритм проверки подлинности, предусматривающий передачу не самого пароля пользователя, а косвенных сведений о нём. При использовании CHAP сервер удаленного доступа отправляет клиенту строку запроса. На основе этой строки и пароля пользователя клиент вычисляет хеш-код MD5 (Message Digest-5) и передает его серверу. Хеш-функция является алгоритмом одностороннего (необратимого) шифрования, поскольку значение хеш-функции для блока данных вычислить легко, а определить исходный блок по хеш-коду с математической точки зрения невозможно за приемлемое время. (По хешированию существует много литературы, например, можно прочесть: Хеширование). Сервер, которому доступен пароль пользователя, выполняет те же самые вычисления и сравнивает результат с хеш-кодом, полученным от клиента. В случае совпадения учётные данные клиента удалённого доступа считаются подлинными.

MD5 (Message-Digest algorithm 5) (RFC 1321) -- широко используемая криптографическая функция с 128 битовым хешем. Найден ряд уязвимостей в алгоритме MD5, в силу чего в США департамент U. S. Department of Homeland Security не рекомендует использование MD5 в будущем, и для большинства правительственных приложений c 2010 года США требуется перейти на семейство алгоритма SHA-2.

Протокол EAP (Extensible Authentication Protocol) (RFC 3748) позволяет проверять подлинность при подключениях удаленного доступа с помощью различных механизмов проверки подлинности. Точная схема проверки подлинности согласовывается клиентом удаленного доступа и сервером, выполняющим проверку подлинности (им может быть сервер удаленного доступа или RADIUS сервер). По умолчанию в маршрутизацию и удаленный доступ включена поддержка протоколов EAP-TLS и MD5-Challenge (MD5-задача). Подключение других модулей ЕАР к серверу, использующему маршрутизацию и удаленный доступ, обеспечивает поддержку других методов ЕАР.

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

Схемы проверки подлинности, использующие протокол EAP, называются типами EAP. Для успешной проверки подлинности клиент удаленного доступа и сервер, выполняющий проверку подлинности, должны поддерживать один и тот же тип EAP.

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

По результатам проверки RADIUS сервер посылает NAS один из трех типов откликов:

Access-Reject показывает, что данный пользовательский запрос неверный. При желании сервер может включить текстовое сообщение в Access-Reject, которое может быть передано клиентом пользователю. Никакие другие атрибуты (кроме Proxy-State) не разрешены в Access-Reject.

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

Access Accept. Пользователю разрешен доступ. Поскольку пользователь аутентифицирован, то RADIUS сервер проверяет авторизацию на использование запрошенных пользователем ресурсов. Например, пользователю может быть доступ через беспроводную сеть, но запрещен доступ к VPN сети.

Таким образом, работа RADIUS протокола может в общем случае быть представлена, как показано на таблице ниже.

Сервер доступа	Направление	RADIUS сервер
Access-Request: NAS-Identifier, NAS-Port, User-Name, User-Password (пароль может быть проигнорирован)	>
	<	Access-Challenge: State (0 или 1) и Reply-Message (Например: "Challenge 12345678, enter your response at the prompt")
Access-Request: с новым ID, NAS-Identifier, NAS-Port, User-Name, User-Password (пароль криптографируется). State (тот же, что и в Access-Challenge)	>
	<	Access-Challenge: State (0 или 1) и Reply-Message (Например: "Challenge 12345678, enter your response at the prompt")

Учет использования сетевых ресурсов

После того, как NAS разрешил пользователю доступ, NAS посылает RADIUS серверу сообщение о начале учета сетевого доступа - пакет Accounting Request, который содержит атрибут Acct-Status-Type со значением "start". Это сообщение обычно содержит идентификатор пользователя, его сетевой адрес, порт подключения и уникальный идентификатор сессии.

NAS может периодически посылать RADIUS серверу пакет Accounting Request, содержащий атрибут Acct-Status-Type со значением "interim-update". Подобная информация предназначена для обновления статуса пользователя во время активной сессии. Обычно подобная информация сопровождается информацией о текущей дате и продолжительности сессии.

После прекращения пользователем доступа к сети NAS посылает RADIUS серверу последний пакет Accounting Request, который содержит атрибут Acct-Status-Type со значением "stop". Также передается информация о времени сессии, количестве переданных пакетов, количестве переданных байтов, причине окончания соединения и другая информация, связанная с сетевым доступом.

Обычно, RADIUS клиент посылает пакет Accounting Request с возможным повтором через некоторый интервал времени, пока не получит в ответ от RADIUS сервера подтверждение приема - пакет Accounting-Response.

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

Обычно, для аутентификации и авторизации RADIUS сервером используется 1812 UDP порт, а для учета услуг - 1813 UDP порт. Однако, в ряде случаев могут использоваться и другие порты. В частности, устройства Cisco Systems по умолчанию используют 1645 и 1646 порты соответственно.

В настоящее время существует целый ряд реализаций RADIUS серверов различными фирмами. Мы рекомендуем использовать SoftPI RADIUS сервер.

3.3 Сервер DIAMETER

Перед погружением в детали протокола, давайте посмотрим, зачем необходим AAA-протокол. В прежние времена люди дозванивались к своим провайдерам Интернет-служб(Internet Service provider - ISP), предоставляя свой ID и пароль для доступа к серверу, который затем выполнял аутентификацию пользователя перед предоставлением Интернет-доступа. В большинстве случаев информация, удостоверяющая личность пользователя, хранилась на сервере доступа не в открытом виде, а в более защищенных местах, например, на LDAP-сервере (Lightweight Directory Access Protocol) за брандмауэром. Следовательно, был необходим стандартизованный протокол между сервером доступа и репозиторием с пользовательской информацией для обмена ею с целью аутентификации, авторизации и учета. Для обеспечения простого, но эффективного способа предоставления этих AAA-возможностей, был разработан протокол RADIUS.

С развитием сетевых приложений и протоколов для аутентификации пользователей необходимы новые требования и механизмы. Эти требования суммируются в документе RFC2989 (см. раздел "Ресурсы"), который включает такие темы как восстановление после сбоев, безопасность и возможности аудита. Хотя существует несколько вспомогательных протоколов, предназначенных для расширения возможностей протокола RADIUS, ожидался более гибкий и общий протокол. На основе RADIUS был создан протокол Diameter, предназначенный для того, чтобы стать общей структурной основой для последующих AAA-приложений.

Протокол Diameter не является совершенно новым протоколом для AAA, а, как следует из его имени, является расширенной версией протокола RADIUS. Он включает многочисленные улучшения всех аспектов, например, обработки ошибок и надежности доставки сообщений. Он извлекает суть AAA-протокола из RADIUS и определяет набор сообщений, являющихся достаточно общими, для того чтобы служить ядром базового протокола Diameter. Различные приложения, нуждающиеся в AAA-функциях, могут определять свои собственные расширения на основе базового протокола Diameter. На рисунке 6 изображена взаимосвязь между базовым протоколом Diameter и различными Diameter-приложениями.

Рисунок 6. Взаимосвязь между базовым протоколом Diameter и различными Diameter-приложениями

Узлы и агенты протокола Diameter

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

Хотя только что описанная архитектура выглядит традиционной архитектурой клиент-сервер, узел, выступающий в роли Diameter-сервера, для некоторых запросов может, на самом деле, в некоторых ситуациях выступать как Diameter-клиент; протокол Diameter является, в действительности, одноранговым протоколом в более широком смысле. Кроме того, в протоколе четко определен специальный Diameter-узел, называемый Diameter-агентом. Обычно существует три типа Diameter-агентов:

Relay Agent (агент-ретранслятор)

Relay Agent используется для перенаправления сообщения соответствующему адресату в зависимости от информации, содержащейся в сообщении. Relay Agent является полезным, поскольку он может объединять запросы от различных областей (или регионов) в определенную область, что устраняет обременительную настройку серверов сетевого доступа при каждом изменении Diameter-сервера.

Proxy Agent (прокси-агент)

Proxy Agent может также использоваться для перенаправления сообщений, но, в отличие от Relay Agent, Proxy Agent может изменить содержимое сообщения и, следовательно, предоставлять дополнительные службы, применять правила для различных сообщений или выполнять задачи администрирования для различных областей. На рисунке 2 показано, как используется Proxy Agent для перенаправления сообщения в другой домен. Если Proxy Agent не изменяет содержимое оригинального запроса, в этом сценарии достаточно было бы использования Relay Agent.

Рисунок 7. Diameter Proxy Agent

Redirect Agent (агент перенаправления)

Redirect Agent выступает в роли централизованного репозитория конфигураций для других Diameter-узлов. Принимая сообщение, он проверяет свою таблицу маршрутизации и возвращает ответное сообщение вместе с информацией о перенаправлении оригинальному отправителю сообщения. Это могло бы быть очень полезно для других Diameter-узлов, поскольку им не нужно хранить список записей о маршрутизации локально, и они могли бы, при необходимости, искать Redirect Agent. На рисунке 8 изображена работа Redirect Agent. Сценарий, показанный на рисунке 8, в основном идентичен сценарию, показанному на рисунке 7, но в этот раз Proxy Agent не знает адреса связанного Diameter-узла в example.com. Следовательно, он ищет информацию в Redirect Agent своей собственной области для получения адреса.

Рисунок 8. Diameter Redirect Agent

Или доставки уведомления другим Diameter-узлам. Для различных целей протокол Diameter имеет различные типы Diameter-сообщений, которые определяются их кодом команды. Например, сообщение Accounting-Request распознает, что сообщение содержит информацию об учетной записи, а сообщение Capability-Exchange-Request распознает, что сообщение содержит информацию о возможностях Diameter-узла, передающего сообщение.

Поскольку тип обмена сообщениями в Diameter является синхронным, каждое сообщение имеет своего соответствующего двойника, который использует такой же код команды. В обоих предыдущих примерах приемник сообщения Accounting-Request подготавливает сообщение Account-Answer и передает его оригинальному отправителю.

Код команды используется для идентификации намерения сообщения, но реальные данные передаются в виде набора пар атрибут-значение (Attribute-Value-Pair - AVP). Протокол Diameter имеет предопределенный набор общих атрибутов и назначает каждому атрибуту соответствующую семантику. Эти AVP передают подробности AAA (такую информацию как маршрутизация, безопасность и возможности) между двумя Diameter-узлами. Кроме того, каждая пара AVP ассоциируется с форматом AVP Data Format, который определен в протоколе Diameter (например, OctetString, Integer32), поэтому значение каждого атрибута должно следовать формату данных.

На рисунке 9 изображена взаимосвязь между Diameter-сообщениями и их AVP. Дополнительные подробности по каждой части рисунка 5 можно найти в главе 3 и главе 4 базового протокола Diameter.

Рисунок 9. Diameter Packet Format

AAA в Diameter

Аутентификация и авторизация

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

Например, сообщение AA-Request используется для передачи информации об аутентификации и авторизации в NAS-приложение, в то время как в SIP-приложении (см. раздел "Ресурсы") сообщение называется User-Authorization-Request.

Учет

В отличие от аутентификации и авторизации, поведение и сообщение для учета четко определено. Учет в Diameter, по существу, следует модели управления сервером. Это означает, что устройство, генерирующее учетные записи, следует указаниям сервера авторизации.

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

Вообще говоря, в зависимости от предоставляемой службы существует два типа учетных записей: Для служб, основанных на единовременном инициировании, используется EVENT_RECORD. Однако если служба предоставляется в течение измеримого периода, могут применяться типы учетных записей START_RECORD, INTERIM_RECORD и STOP_RECORD для отметки начала, обновления и конца сессии.

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

Сравнение протоколов TACACS+ , RADIUS и DIAMETER

А теперь хотелось бы поподробнее сравнить возможности протоколов TACACS+, RADIUS и DIAMETER.

Протокол RADIUS (Remote Authentication Dial In User Service), в отличие от TACACS+, был разработан независимой группой разработчиков (на данный момент протокол не модифицируется) и поэтому получил широкое распространение у сторонних разработчиков.

Как правило, все производители программных и аппаратных клиентов поддерживают данный протокол.

Кратко о протоколе можно сказать следующее: использует в своей основе протокол UDP (а поэтому относительно быстр), процесс авторизации происходит в контексте процесса аутентификации (т.е. авторизация как таковая отсутствует), реализация RADIUS-сервера ориентирована на однопроцессное обслуживание клиентов (хотя возможно многопроцессное - вопрос до сих пор открытый), поддерживает довольно ограниченное число типов аутентификации (Clear text и CHAP), имеет среднюю степень защищености.

Приведем сравнительную таблицу возможностей обоих протоколов:

	RADIUS	TACACS+
Базовый протокол	UDP	TCP
Поддерживаемые сервисы	Autentication, Authorization	Authentication, Authorization, Accounting
Безопасность	Шифруется пароль	Шифруется все тело пакета

Протокол TACACS+ использует протокол TCP, т.е. он потенциально медленнее протокола RADIUS, но TACACS+ способен в каждый момент времени обслуживать несколько пользователей.

Radius шифрует только пароль в передаваемом пакете, при этом оставшаяся часть пакета (имя пользователя, авторизованные сервисы, информация учета) не зашифрована и доступна для захвата злоумышленником. TACACS+ шифрует все тело пакета. Таким образом, степень защищенности протокола TACACS+ выше, чем у RADIUS.

RADIUS поддерживает аутентификацию и авторизацию. TACACS+ использует архитектуру AAA (Authentication, Authorization, Accounting). Возможно выполнение аутентификации отдельно (например, на сервере Kerberos), а авторизации и учета - с использованием TACACS+. И наконец перейдем к: DIAMETER - это наследник RADIUS, который включил большую часть функциональности TACACS+. Но в то же время компания Cisco Systems продолжит поддерживать свой протокол TACACS+, который остается непревзойденным для управления предоставлением доступа к сетевым устройствам (а не к сети через PPP,VPN), т.к он единственный поддерживает такие дополнительные возможности, как фильтрация команд. Детальное сопоставление с протоколом Diameter можно будет произвести, когда он станет более распространен и поддержан производителями решений в AAA-области.



4. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ СЕРВЕРА RADIUS

Произведен анализ активного сетевого оборудования, выявлено следующее:

Что около 80% оборудования имеют поддержку сервера RADIUS. 10% - TACACS и DIAMETER, оставшиеся оборудование морально остарело и не поддерживает не один из серверов.

4.1 Настройка сервера

Добавление роли сервера: служба политики сети и доступа

Настройка RADIUS сервера:



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

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

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

4.2 Настройка активного сетевого оборудования

В настройке активного сетевого оборудования должны прописываться IP адреса и Shared Key (общий секрет) для подключения к RADIUS серверу.

4.3 Тестирование защиты от несанкционированного доступа

Реализация сервера RADIUS проходила на гипервизоре VMware ESXi 5.1 на котором было создано 4 виртуальных машины, на одной был установлен Windows Server 2008 R2, на остальных 3х Windows 7 Pro (для тестирования).

На данном скриншоте видно, что аутентификация между сервером RADIUS и клиентскими машинами пройдена успешно.



ЗАКЛЮЧЕНИЕ

За время прохождения преддипломной практики мною были изучены методы защиты от несанкционированного доступа с использованием протоколом на базе архитектуры ААА в ЛВС. В тестовой среде был реализован сервер RADIUS.



СПИСОК ЛИТЕРАТУРЫ

1. Описание технологии аутентификации TACACS+, Cisco System Inc., 2003 http://www.cisco.com/russian_win/warp/public/3/ru/solutions/sec/mer_tech_ident-tacacs.html

2. Технологии идентификации - Обеспечение безопасности в сети, Cisco Systems Inc. www.cisco.com/global/RU/win/solutions/sec/mer_tech_ident. shtml

3. http://www.softpiua.com/ru/main/86-what-is-radius.html - описание сервера радиус

4. http://www.ibm.com/developerworks/ru/library/wi-diameter/index.html - описание сервера диаметр

5. http://emanual.ru/download/3793.html - внедрение сервера радиус

6. Протоколы RADIUS и TACACS+: сравнение и принципы функционирования, Владислав Пинженин, Максим Мокроусов, Сетевые решения, 2003

Размещено на Allbest.ru

...