Ж у р н а л   о   к о м п ь ю т е р н ы х   с е т я х   и   т е л е к о м м у н и к а ц и о н н ы х   т е х н о л о г и я х
СЕТИ И СИСТЕМЫ СВЯЗИ on-line
  ПОИСК: ПОДПИСКА НА НОВОСТИ: НОМЕР:
    ДОМОЙ • Архив: Новостей | Конференций | НомеровПодписка
 
   
 
   
    
РЕДАКЦИЯ
 
Все о журнале
Подписка
Как проехать
Где купить
Отдел рекламы
График выхода журнала
Адреса в Интернет

РУБРИКАТОР
   
• Инфраструктура
• Информационные
   системы

• Сети связи
• Защита данных
• Кабельные системы
• Бизнес
• Колонка редактора
• Электронная
   коммерция

• Только на сервере
• Системы
   учрежденческой
   связи

• Новые продукты


Rambler's Top100

  

Защита флангов с помощью RADIUS и TACACS+

Дэн Бэкман

Организация корпоративной службы удаленного доступа - это разумный компромисс между возможностью удаленного доступа к корпоративным данным и обеспечением их безопасности. При этом для доступа по коммутируемой линии пользователям вовсе не надо запоминать дополнительные учетные имена и пароли. Серверы удаленного доступа выполняют аутентификацию пользователей, обращаясь к дереву NDS, доменной службе Windows NT или службе NIS (см.: Дэн Бэкман. Обеспечение безопасности посредством удаленной аутентификации//Сети и системы связи. 1997. № 5. С. 138). Системы доступа по коммутируемым линиям должны одновременно поддерживать несколько средств аутентификации на серверной стороне. И наконец, для обеспечения внутрикорпоративных расчетов требуется тщательное ведение всех учетных записей, что в свою очередь означает необходимость эффективной поддержки централизованной учетной БД.

Со всеми этими проблемами мы столкнулись в лаборатории журнала Network Computing, которая находится в Сиракузском университете и где в течение прошлого года проводилось тестирование нескольких продуктов удаленного доступа. А совсем недавно мы испытали ряд служб RADIUS (Remote Access Dial-In User Service) и TACACS+ (Terminal Access Controller Access Control System Plus). В перечень протестированных нами продуктов вошли следующие: CiscoSecure ACS 2.0 для ОС Windows NT и CiscoSecure ACS 2.1.2 для ОС Solaris фирмы Cisco Systems; Steel-Belted Radius 1.3 для ОС Windows NT фирмы Funk Software; RADIUS 2.0.1 для ОС Solaris фирмы Livingston Enterprises; RADIUS для NDS 1.0 фирмы Novell; Access Manager 3.0 фирмы Shiva. Продукты фирм Funk Software, Livingston Enterprises и Novell обеспечивают поддержку только RADIUS, а продукты Shiva Access Manager и CiscoSecure поддерживают RADIUS и TACACS+. В нашу тестовую конфигурацию были включены три сервера удаленного доступа: MAX 4004 фирмы Ascend Communications, AS5300 фирмы Cisco и LANRover/E Plus фирмы Shiva.

Стой! Кто идет?

Использование протоколов аутентификации коммутируемых соединений, подобных RADIUS и TACACS+ и предназначенных для связи серверов удаленного доступа с вашей внутренней сетевой инфраструктурой, позволяет снизить накладные расходы на управление корпоративными службами удаленного доступа. Хотя по своим функциональным возможностям оба протокола практически эквивалентны, как нам удалось выяснить, почти все серверы удаленного доступа поддерживают RADIUS, принятый в качестве стандарта группой IETF, что делает его надежным и стратегически правильным выбором. Однако выбор сервера аутентификации не менее важен, чем выбор протокола. Если масштабируемость и гибкость для вас являются критически важными параметрами, мы настоятельно рекомендуем приобрести продукт, поддерживающий аутентификацию на основе сервера-посредника RADIUS, учетную БД и правила контроля доступа на серверной стороне.

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

RADIUS и TACACS+ - это значительный шаг вперед по сравнению с более старыми протоколами TACACS и XTACACS. При аутентификации в них используются симметричные ключи шифрования паролей для передачи последних между серверами удаленного доступа и аутентификации (RADIUS шифрует только пароль, а TACACS+ - весь пакет в целом). Для дополнительной безопасности оба протокола поддерживают еще и протокол аутентификации по квитированию вызова CHAP (Challenge Handshake Authentication Protocol), препятствующий прохождению паролей по всей линии связи.

Однако эта модель не годится для аутентификации с использованием дерева NDS или доменной службы Windows NT. Для проверки ответа на вызов сервера, поступившего от проходящего аутентификацию пользователя, протокол CHAP применяет незашифрованную копию пароля в простой текстовой форме. К сожалению, большинство сетевых операционных систем и служб справочника сохраняют пароли пользователей с односторонним хэш-кодированием, что не позволяет серверам RADIUS и TACACS+ извлечь подлинный пароль для проверки ответа. При использовании стандартного регистрационного интерфейса службы сетевого доступа или протокола PAP (Password Access Protocol) пароль вводится в незашифрованном текстовом виде и проверяется на серверной стороне.

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

В зависимости от специфики вашей сети вы можете использовать простую аутентификацию по имени и паролю пользователя, но, возможно, этого будет не достаточно и потребуются одноразовые пароли и жетоны типа SecurID. В любом случае, протокол аутентификации коммутируемых соединений позволяет объединить несколько серверов сетевого доступа в единую безопасную систему аутентификации. RADIUS и TACACS+ могут функционировать как службы аутентификации, используя центральную БД учетных записей, или служить посредниками для внешних систем аутентификации. С этими протоколами сервер удаленного доступа может аутентифицировать пользователей либо на основании информации, полученной от корпоративных служб NDS, Windows NT Domain и NIS, либо с помощью разработанных независимыми фирмами систем безопасности, подобных системе Defender фирмы AXENT Technologies или ACE/Server фирмы Security Dynamics.

Даже при наличии одного-единственного сервера удаленного доступа, целесообразно применять централизованную систему аутентификации. Зачем поддерживать системы аутентификации первого звена со списками пользователей, если сервер сетевого доступа может запрашивать информацию, необходимую для системы аутентификации второго звена, непосредственно у сервера IntranetWare или Windows NT? Более того, малые и средние по размерам центры удаленного доступа, где установлено несколько серверов доступа, могут использовать RADIUS или TACACS+ для поддержки служб аутентификации третьего звена. И наконец, система аутентификации на основе сервера-посредника (или четвертое звено) гарантирует гибкость в управлении доступом.

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

Аутентификация с помощью сервера-посредника RADIUS

Сервер-посредник

Более крупные корпоративные центры удаленного доступа и поставщики услуг доступа по коммутируемым линиям сталкиваются с проблемой. При наличии нескольких сетевых операционных систем, не известно, как поступить, когда одна часть ваших пользователей "находится" в дереве NDS, другая - "охвачена" доменной службой Windows NT, а остальные пользователи "хранятся" в БД NIS? Например, должны ли вы обеспечивать аутентификацию на основе собственных учетных служб ваших клиентов? Даже если ваш центр и поддерживает RADIUS или TACACS+, серверы удаленного доступа не могут выбирать различные серверы аутентификации для каждого пользователя. Можно сконфигурировать серверы удаленного доступа таким образом, чтобы они запрашивали несколько серверов аутентификации, однако в этом случае нельзя запросить следующий сервер, если предыдущий не ответил.

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

Сохраняя централизованную модель аутентификации в соответствии со стандартом RADIUS, серверы типа Steel-Belted Radius фирмы Funk Software и Access Manager фирмы Shiva могут служить в качестве серверов-посредников по отношению к внешним (целевым) RADIUS-серверам. По умолчанию сервер-посредник RADIUS отделяет имя пользователя от идентификатора соответствующей области аутентификации с помощью символа "@". Обращение к серверу сетевого доступа, которое сопровождается вводом типа "chuck@nds" перенаправляется RADIUS-серверу, ответственному за область "nds", где и происходит аутентификация пользователя "chuck". При успешной аутентификации на целевом сервере сервер-посредник RADIUS направляет соответствующее подтверждение серверу удаленного доступа. В дополнение к этому, центральный RADIUS-сервер сохраняет за собой право устанавливать параметры сеанса и назначать другие правила авторизации. Пользователи из области "nds", как правило, работают на базе протокола PPP (Point-to-Point - "точка-точка") с трехчасовым лимитом времени; пользователи же из области "Unix" работают в режиме текстового терминала и автоматически подключаются к хост-машине Unix по протоколу Telnet.

Мы были удивлены, обнаружив некоторую несогласованность в поддержке функций сервера-посредника поставщиками RADIUS-продуктов. Например, пытаясь аутентифицировать пользователей на основе Windows NT Domain, NDS и NIS через единственный сервер-посредник RADIUS, мы не смогли передавать запросы на аутентификацию от сервера Steel-Belted Radius фирмы Funk Software к серверу RADIUS фирмы Livingston Enterprises на платформе Solaris, а также к серверу RADIUS фирмы Novell. Но в происходящем не было вины фирмы Funk Software, которая скрупулезно следовала стандарту RFC 2138. Дело в том, что сервер-посредник ожидает от целевого сервера (в данном случае, от серверов фирм Livingston Enterprises и Novell), что тот возвратит ему переменную Proxy-State в том виде, в каком она была представлена в первичном запросе. Однако ни один из целевых серверов не делал этого (что является нарушением указанного стандарта). Таким образом, сервер-посредник фирмы Funk Software совершенно правильно отклонял все запросы.

По иронии судьбы нам на помощь пришел сервер Access Manager фирмы Shiva. У него не возникало проблем при аутентификации в соответствии со стандартом RADIUS, так как он не требовал возвращения переменной Proxy-State. Определив четыре области аутентификации в конфигурации Access Manager, мы построили систему с пятью альтернативными службами аутентификации, где используется всего один сервер-посредник RADIUS. При аутентификации на основе служб Windows NT Domain, NDS и NIS, а также БД Access Manager и домена Сиракузского университета пользователи коммутируемых соединений во время подключения могли определять службу аутентификации с помощью добавления к своему имени соответствующего идентификатора области.

Аутентификация на основе сервера-посредника часто используется поставщиками услуг передачи данных национального или глобального масштаба. Она дает возможность серверам удаленного доступа, находящимся в любом месте, обращаться к БД, которые поддерживаются их пользователями независимо друг от друга. Однако при передаче пакетов, содержащих необходимую для аутентификации информацию, по сетям общего пользования риск нарушения безопасности возрастает. Шифрование в соответствии со стандартами RADIUS и TACACS+ основано на симметричных статических ключах, а имена пользователей, пароли и информация сервера аутентификации для удобства помещаются в один пакет.

TACACS+ также обеспечивает аутентификацию на основе сервера-посредника. Так, фирма Cisco поддерживает аутентификацию на основе сервера-посредника RADIUS и TACACS+ и предлагает для этого свой продукт CiscoSecure GRS, предназначенный главным образом для поставщиков сетевых услуг и глобальных корпоративных сетей.

Авторизация

При каждой успешной аутентификации и RADIUS и TACACS+ возвращают переменные сеансовой конфигурации, что является важным моментом при реализации стратегии управления центральным сервером удаленного доступа. В отличие от службы TACACS+, где для определения протокола и назначения параметров используется фиксированный набор пар атрибут/значение, а также 16 уровней полномочий, RADIUS рассчитан на набор стандартизированных переменных, но в нем содержится словарь для поддержки специфических атрибутов поставщика, который может быть расширен. Стандартные атрибуты RADIUS, утвержденные IETF, определяют элементарные типы сервисов, например такие, как пакетные протоколы, автоматические TCP-сеансы, а также наличие командного процессора сервера удаленного доступа, администрирования, типы протоколов и адресную информацию.

Однако в централизованном управлении авторизацией основное значение имеют вовсе не параметры сеанса в протоколах RADIUS или TACACS+. Так как управление осуществляется централизованно, то существуют возможности интеллектуально управлять правами доступа и динамически регулировать атрибуты, такие, как адреса и значения тайм-аута. Эти элементы управления доступом являются внутренними по отношению к серверу аутентификации и не зависят от используемого протокола. Продукты CiscoSecure и Shiva Access Manager позволяют устанавливать ограничения доступа в определенные часы. Кроме того, Access Manager отслеживает индивидуальное время доступа и назначает пользователям временныўе квоты на каждый день, неделю или месяц. И наконец, весьма полезная особенность этих продуктов - их способность временно блокировать учетное имя пользователя, если он превысил предельное число неудачных попыток входа в сеть.

Учет

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

Первоначально продукт XTACACS для учета статистики коммутируемых соединений отслеживал записи типа "stop"; сегодняшние продукты TACACS+ и RADIUS предлагают самые разнообразные функции учета.

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

Серверы RADIUS и TACACS+ осуществляют ведение журналов регистрации в виде простых текстовых файлов. Тем не менее одно из главных преимуществ коммерческих серверов аутентификации (в отличие от серверов, распространяемых бесплатно) - это наличие поддержки доступа к базам данных посредством SQL или ODBC-интерфейса. Если приоритетными для вас являются обеспечение масштабируемости и учет доступа, то мы рекомендуем выбрать сервер аутентификации, поддерживающий имеющуюся у вас СУБД.





  
5 '1998
СОДЕРЖАНИЕ

колонка редактора

• IP-телефония: битва еще впереди

локальные сети

• Коммутаторы с автоматической установкой скорости портов

• Построение отказоустойчивых локальных сетей

• Дороги, которые мы выбираем

• Абонентский оптоволоконный канал

• Кабельные системы для скоростной передачи данных

• Интеграция с Unix: клиенты и серверы NFS для Windows NT

• Windows NT: взлет или падение?

• Технология Fibre Channel: возможности и проблемы внедрения

корпоративные сети

• Работа с персоналом при внедрении корпоративных информационных систем

• Определение масштаба систем удаленного доступа

• RMON2: сетевой уровень и выше

интернет и интрасети

• Интернет-магазины на CeBIT'98

услуги сетей связи

• Услуги сетей VSAT в России

• TMN в конце туннеля

• Возрождение интереса к аналоговым измерениям в абонентских каналах

• Новые технологии для новых сетей

• Практические аспекты построения корпоративных сетей Frame Relay (часть I)

• Устройства FRAD: данные и речь по одному каналу

• Защита от перегрузок в сетях АТМ

системы учрежденческой связи

• Принципы выбора УПАТС (часть I)

защита данных

• Защита флангов с помощью RADIUS и TACACS+

бизнес

• О русских терминах в области СКС

новые продукты

• Эффективность Frame Relay и качество TDM - в одном канале; WebTracker как средство кадровой политики; Весенние модели Allied Telesyn; Новинки от SMC на CeBIT'98;

только на сервере

• Серверы удаленного доступа масштаба предприятия



 Copyright © 1997-2007 ООО "Сети и Системы Связи". Тел. (495) 234-53-21. Факс (495) 974-7110. вверх