Предисловие
«Когда денег нет, то лучше еще, чем уже» подметил композитор Никита
Богословский. Определение границы между еще и уже для того или иного пользо-
вателя той или иной инфокоммуникационной услугой в современных сетях связи
осуществляется средствами ААА. Триединый термин AAA обозначает действия по
аутентификации, авторизации и учету (Authentication, Authorization, Accounting).
Важность ААА-операций все более возрастает по мере распространения сетей
NGN/IMS, хотя функции AAA обеспечивают управление доступом к любым сетям
связи и играют ключевую роль всюду, где требуется представить конечному поль-
зователю счет за предоставленные инфокоммуникационные услуги. Речь идет
обо всех сетевых услугах, включая традиционную телефонию, широкополосный
доступ, услуги маршрутизации, услуги шлюза и т.п.
Все три составляющие ААА тесно связаны. Например, учет использования
ресурса с целью выставления счета не имеет смысла, если субъект, которому
предоставляется услуга, не может быть достоверно идентифицирован, то есть ау-
тентифицирован. После того как субъект установлен, следует определить, доступ
к каким ресурсам и на каких условиях (параметры качества обслуживания, виды
услуг, виды носителей) может быть ему предоставлен. Процедура авторизации
позволяет применять правила доступа к ресурсам в соответствии с соглашением
с Оператором. Выставление счетов за услуги в большинстве случаев основыва-
ется на информации о количестве и типе потребленных абонентом ресурсов и
длительности этого потребления. Сбор такого рода информации осуществляется
в рамках процедур учета.
Настоящая книга посвящена двум протоколам, созданным и повсеместно
используемым для обеспечения функций ААА, – протоколам RADIUS и Diameter.
Главной телекоммуникационной услугой на протяжении большей части
XX века являлась традиционная телефонная связь, местная, междугородная и
международная.
2. Б.С. Гольдштейн
!AAA-rad-diam.indd 9 01.12.2010, 15:52:5810 Предисловие
Декадно-шаговые и координатные АТС, соединявшие абонентов с помощью
электромеханических контактов, практически исключали понятие мошенничест-
ва (фрода) в его сегодняшнем понимании, так как абонент идентифицировался
исключительно физической линией, подведенной к месту установки стационар-
ного телефонного аппарата. Таким образом, аутентификация при доступе к сети
выполнялась непосредственно подключением на кроссе АТС, а счет за услуги
выставлялся владельцу линии. Авторизация как таковая также была элементарна,
так как абоненту была доступна только услуга телефонной связи. Если абонент
не оплачивал услуги связи в соответствии с условиями договора, его линия фи-
зически блокировалась. Учет длительности разговоров осуществлялся первона-
чально только на междугородных станциях – АМТС – с помощью процедуры АОН,
а несколько позже – и на АТС – тоже с помощью дополнительно устанавливаемого
оборудования учета стоимости.
Появление цифровых АТС несколько усложнило ААА-процедуры в ТфОП.
Аутентификация, как и раньше, производилась на основе анализа номера або-
нентской линии, по которой поступал вызов. Однако, в отличие от предшест-
венников, в цифровых АТС действовала полноценная процедура авторизации.
Предоставление дополнительных услуг, таких как переадресация или автомати-
ческая побудка, требовало создания профиля абонента, в котором фиксировались
правила доступа к подобным услугам. При каждом запросе система обращалась к
профилю и выполняла проверку прав абонента, и дальнейшее обслуживание зави-
село от результатов проверки. Появилось и встроенное программное обеспечение
учета стоимости услуг связи, являющееся неотъемлемой частью программного
обеспечения цифровых АТС.
Ситуация радикально изменилась с появлением Интернет-технологий.
Первым популярным способом доступа в Интернет стал Dial-Up (коммутируемый
доступ через модем по двухпроводной телефонной линии). Заключая договор с
Интернет-провайдером, абонент получал логин и пароль, по которым система
могла аутентифицировать его запрос подключения к сети. Учитывая, что точек
доступа к сети, называемых также NAS (Network Access Server), могло быть много,
а хранить параметры абонентов удобнее в единой, а не распределенной базе дан-
ных, IETF специфицировала в RFC 2058 протокол RADIUS (Remote Authentication
Dial In User Service), определявший формат взаимодействия NAS и специально-
го сервера, который выполнял проверку параметров аутентификации по базе
данных Интернет-провайдера. Чуть позже, в середине 1997 года, спецификации
этого протокола были пересмотрены в RFC 2138, а затем еще раз – в 2000 году –
в RFC 2865 [67]. Простейший (и уже постепенно уходящий) пример использования
RADIUS при доступе dial-up в Интернет показан на рис. 1.
!AAA-rad-diam.indd 10 01.12.2010, 15:52:59Предисловие 11
Рис. 1. Функции AAA в доступе dial-up через ТфОП
Помимо аутентификации, появление Интернет привнесло необходимость
развития систем учета Интернет-провайдеров. Выставление счетов пользовате-
лям выполнялось на основе информации о продолжительности доступа к сети и
объема данных, переданных в рамках Интернет-сессии. Эту информацию было
целесообразно накапливать централизованно, что потребовало разработки про-
токола передачи такого рода информации от NAS на сервер учета. IETF дорабо-
тал существующую версию RADIUS, создав в январе 1997 года протокол RADIUS
Accounting RFC 2059 [66], который, как и RADIUS, был дважды переработан в RFC
2139 и RFC 2866 в середине 1997 и в 2000 годах, соответственно. Согласно этому
протоколу, в момент начала сессии NAS отправляет на сервер учета сообщение,
сигнализирующее о необходимости начала отсчета времени. В конце сессии NAS
отправляет еще одно сообщение, уведомляющее об окончании сессии и об объе-
ме переданной информации, предоставляя серверу учета необходимые данные
для формирования счетов. Протоколы RADIUS и RADIUS Accounting рассматрива-
ются подробно в главе 2.
Эволюция сетей связи, выражающаяся в усложнении сетевого и пользова-
тельского оборудования, в увеличении количества услуг, в новом уровне угроз за-
щите информации, а также в необходимости обеспечения согласованного качест-
ва обслуживания, привела к тому, что разработанный без учета всех этих факторов
протокол RADIUS в силу своих ограничений стал во многих случаях неприменимым
для решения задач ААА в рамках новых инфокоммуникационных реалий. Это по-
будило IETF стандартизировать новый ААА-протокол, что и было вскоре сделано:
!AAA-rad-diam.indd 11 01.12.2010, 15:52:5912 Предисловие
в RFC 3588 [25] в конце 2003 года появилась первая версия базового протокола
Diameter, рассматриваемого в главе 3.
Одним из отличий протокола Diameter от RADIUS является то, что стандар-
тизация практических приложений, работающих на основе базового протокола
Diameter, ведется в рамках отдельных RFC, каждый из которых, по сути, представ-
ляет собой отдельный стандарт. Глава 4 посвящена рассмотрению приложения
кредитного контроля Diameter [53] – одному из наиболее распространенных на се-
годня Diameter-приложений, которое позволяет на основе стандартизированных
механизмов выполнять контроль расходования ресурсов мультисервисной сети в
режиме реального времени по принципу предварительного резервирования.
Де-факто, последователем протокола RADIUS является не базовый прото-
кол Diameter, а рассматриваемое в главе 5 Diameter-приложение сервера доступа
к сети [38], так как именно оно описывает процедуры взаимодействия сервера
доступа к сети NAS и ААА-сервера при обслуживании пользователей, запраши-
вающих доступ к сетевым ресурсам. В силу того что, по понятным причинам, еди-
новременный переход на новый ААА-протокол невозможен, большое внимание
в главе 5 уделяется задачам преобразования протоколов RADIUS и Diameter для
обеспечения совместимости существующего и нового оборудования.
Традиционная для книг этой серии глава 6 охватывает вопросы реализации и
тестирования протоколов ААА, а в главе 7 рассматриваются вопросы реализации
законного перехвата сообщений – СОРМ (которым посвящена отдельная книга
этой же серии [8]) – для протоколов RADIUS и Diameter.
Обсуждение материала, содержащегося в главах 2-7, требует согласования
понятийного аппарата и краткого обзора процедур ААА без привязки к конкретной
реализации протокола. Основные определения и описание обобщенной ААА-ар-
хитектуры приводятся в главе 1.
Авторы пользуются случаем выразить благодарность за помощь в подготов-
ке этой книги сотрудникам Научно-технических центров НТЦ Протей, НТЦ Аргус и
НТЦ Севентест, профессорам и преподавателям, а также аспирантам и студентам
кафедры систем коммутации и распределения информации СПбГУТ им. проф.
М.А. Бонч-Бруевича, коллегам из отдела системных исследований НИИТС, специа-
листам сертификационного центра ЛО ЦНИИС и инженерам ведущих зарубежных
компаний, с которыми изучались, обсуждались и тестировались спецификации
протоколов, рассматриваемых в этой книге.
!AAA-rad-diam.indd 12 01.12.2010, 15:53:00
Актуальность проблемы
Значительная часть эволюционных изменений в сфере телекоммуникаций в наши дни проходит под знаком конвергенции фиксированных и мобильных сетей связи (.Fixed Mobile Convergence, FMC). Подтверждением этому служат конвергентные сети типа WLAN/UMTS {Wireless Local Area Network/Universal Mobile Telecommunications System), получающие сегодня все более широкое распространение в нашей стране и за ее пределами. Как правило, сеть WLAN/UMTS является продуктом присоединения домена WLAN к инфраструктуре UMTS, которое осуществляет Оператор UMTS с целью предоставления услуг по технологиям беспроводных локальных сетей. Одним из наиболее сложных аспектов такого присоединения является обеспечение работы системы аутентификации, авторизации и учета (Authentication, Authorization and Accounting, AAA) в домене WLAN сети WLAN/UMTS. В силу того, что существующие абоненты UMTS предоплатных тарифных планов требуют контроля средств на счете в режиме реального времени, система AAA домена WLAN неизбежно должна быть интегрирована с биллинговой системой сети UMTS. Возникающая в процессе учета в домене WLAN дополнительная сигнальная нагрузка повышает требования к производительности биллинговой системы, что в большинстве случаев сказывается на ее стоимости. Намеренное снижение интенсивности сигнальной нагрузки не является решением проблемы, так как особенности AAA - протоколов с резервированием средств в данном случае повлекут за собой уменьшение дохода Оператора. В силу того, что системы AAA конвергентных сетей типа WLAN/UMTS на сегодняшний день являются практически неизученными с точки зрения их вероятностно-временных характеристик, параметры функционирования систем AAA в процессе их эксплуатации выбираются! способами, не имеющими научного обоснования. Как результат, система AAA работает в режиме, не позволяющем Оператору получить максимальный доход от обслуживания абонентов. В- такой ситуации актуальной является задача исследования механизмов системы AAA в конвергентных сетях типа WLAN/UMTS и. создания математических моделей, позволяющих определить оптимальные параметры работы системы AAA.
Приведенная аргументация позволяет сформулировать цель и задачи работы.
Цель диссертационной работы заключается в разработке математической модели системы AAA конвергентной сети типа WLAN/UMTS, обслуживающей абонентов предоплатных тарифных планов в режиме реального времени, и поиске оптимальных параметров работы такой системы на основе данной модели.
Цель достигается путем решения следующих задач:
1. Исследование процесса формирования сигнальной нагрузки от системы AAA в сторону системы тарификации при обслуживании абонентов сети WLAN/UMTS в режиме реального времени. Разработка критериев оптимальности параметров работы системы AAA сети WLAN/UMTS.
2. Создание формализованного описания системы AAA сети WLAN/UMTS. Определение вероятностно-временных характеристик наиболее распространенных услуг, предоставляемых доменом WLAN.
3. Разработка математической модели- системы AAA сети WLAN/UMTS, обслуживающей- абонентов в режиме реального времени.
4. Синтез процессов системы AAA сети WLAN/UMTS. Поиск оптимальных параметров работы системы AAA на основе полученной математической модели.
5. Обоснование * методом имитационного моделирования корректности оптимума процессов системы AAA сети WLAN/UMTS
Состояние вопроса.
Относительная новизна предмета исследования является причиной практически полного отсутствия связанных с ним научных работ. Проблематика, схожая с рассматриваемой в настоящей работе, поднимается в [26, 32, 33, 34], однако предлагаемые авторами решения либо «обходят» проблему за счет введения дополнительных механизмов, снижающих ее негативное воздействие [32, 34], либо являются неприменимыми в рамках конвергентной сети [33].
Наиболее близкая к настоящей диссертационной работе задача была сформулирована и решена М. Ченгом (Cheng), В. Янгом (Yang) и И. Лином (Lin) для системы учета в сети мобильной связи, построенной по принципу узла услуг [35]. В данной работе авторы предлагают математическую модель узла услуг, на основе которой находят оптимальный режим работы системы учета при тарификации абонентов предоплатных тарифных планов. Критерием оптимальности в работе [35] является минимизация потерь Оператора, вызванных недостаточной точностью тарификации в режиме реального времени.
Математический аппарат, предложенный в [35], подходит для целей настоящей диссертационной работы лишь отчасти по следующим причинам.
• В домене WLAN сети WLAN/UMTS учет выполняется путем предварительного резервирования ресурсов на основе протокола кредитного контроля Diameter, в то время как система AAA, построенная по принципу узла услуг, подразумевает организацию учета при помощи периодической проверки остатка на счете, выполняемой в режиме постфактум.
• Различная природа потерь Оператора сети при использовании неоптимальных параметров работы системы AAA. Потери в сети с системой AAA, построенной в соответствии с архитектурой «узел услуг», у являются следствием перерасхода предоплаченных абонентами ресурсов, то есть, так называемого «ухода» абонента «в минус». Система AAA, организованная по принципу резервирования, не имеет этого недостатка, однако допускает возникновение ситуации, когда остаток средств на счете абонента слишком мал для выполнения резервирования. В таком случае эти средства не могут быть потрачены, и их можно считать недополученным доходом Оператора.
• В [35] рассматривается процесс учета речевых сеансов - по сути, единственной протяженной во времени услуги в мобильных сетях первого и второго поколения. В домене WLAN сети WLAN/UMTS помимо учета речевых сеансов необходимо выполнять учет IP сессий. Математический аппарат, используемый при работе с речевым трафиком, в данном случае неприменим.
• Задача оптимизации параметров работы системы учета, построенной по принципу узла услуг, была решена графическим способом. При этом не приводится доказательство существования оптимума и его единственности. То есть, фактически, авторы лишь иллюстрируют возможность решения поставленной задачи. Эксплуатация реальной сети требует более точного и технологичного метода поиска оптимального значения: визуально зафиксированная точка (а, точнее, группа точек, так как график является плавным, и четкий минимум прослеживается' не всегда) на графике не является надежной основой для конфигурирования параметров сети.
Научная новизна.
В настоящей диссертационной работе впервые предложена математическая модель системы AAA конвергентной сети типа WLAN/UMTS, обслуживающей абонентов предоплатных тарифных планов в. режиме* реального времени, а также сформулирована и решена задача поиска оптимальных параметров эксплуатации такой системы. Практическая ценность.
Аналитические модели, полученные в этой работе, а также метод решения задачи оптимизации, могут быть использованы для* определения оптимальных параметров работы системы AAA в реальном времени в конвергентной сети типа WLAN/UMTS, при которых минимизируются издержки Оператора в процессе эксплуатации.
Результаты диссертационной работы были использованы при построении конвергентных сетей типа WLAN/UMTS в Поволжском и Столичном филиалах ОАО «Мегафон», а также в проектной деятельности ОАО «ГИПРОСВЯЗЬ», что подтверждается соответствующими актами. Методы исследований.
Исследование, представленное в настоящей диссертационной работе, проведено на основе* методов математического анализа, теории вероятностей, теории массового обслуживания, теории восстановления, теории оптимизации, а также методов имитационного моделирования на ЭВМ.
Основные положения, выносимые на защиту.
1. Формализованное описание задачи оптимизации параметров системы AAA конвергентной сети типа WLAN/UMTS, обслуживающей абонентов в режиме реального времени.
2. Функциональная модель системы AAA конвергентной сети типа WLAN/UMTS.
3. Математическая модель системы AAA конвергентной сети типа WLAN/UMTS, обслуживающей, абонентов, в режиме реального времени.
4. Обоснование выбора метода решения задачи оптимизации и решение данной задачи на основе полученной математической модели системы AAA конвергентной сети типа WLAN/UMTS. 5. Результаты имитационного моделирования системы AAA конвергентной сети типа WLAN/UMTS, подтверждающие аналитические модели диссертационной работы.
Публикации.
По материалам диссертационной работы в научно-технических журналах и в трудах международных и всероссийских научных конференций опубликовано 14 печатных работ.
Структура работы.
Научная библиотека диссертаций и авторефератов disserCat http://www.dissercat.com/content/issledovanie-mekhanizmov-autentifikatsii-avtorizatsii-i-ucheta-v-rezhime-realnogo-vremeni-v-#ixzz2NYX31UG5
Заключение диссертации по теме "Вычислительная техника -- Вычислительные системы и сети -- Исследование", Сенченко, Юрий Леонидович
4.5 Выводы по разделу 4
1. Математическая модель системы AAA конвергентной сети WLAN/UMTS, разработанная в диссертационной работе, позволяет с достоверной точностью оценивать издержки Оператора на предоставление наиболее популярных услуг, таких как VoIP вызов или IP сессия. В диапазоне значений аргумента, где функция стоимости достигает минимума, разброс аналитических и эмпирических значений в среднем составляет четыре процента и не превышает семи процентов.
2. Метод поиска оптимальных параметров работы системы AAA позволяет найти наилучшее значение размера резервируемых за одно обращение к системе тарификации (OCS) ресурсов с высокой степенью достоверности: отклонение от данных эксперимента не превышает четырех процентов. С учетом того, что график функции стоимости (как эмпирической, так и аналитической) плавный, подобное отклонение аргумента рядом с точкой минимума практически не влияет на величину затрат оператора, то есть полученные аналитические результаты можно считать достоверными и годными к применению в реальных сетях связи.
3. Полученные в диссертационной работе аналитические модели могут быть использованы для оптимизации работы систем AAA сетей WLAN/UMTS в режиме реального времени, а также систем AAA других сетей, работающих по аналогичному принципу предварительного резервирования ресурсов.
5. Заключение
В диссертационной работе исследованы механизмы аутентификации, авторизации и учета (AAA) в реальном времени в конвергентных сетях типа WLAN/UMTS, а также сформулирована и решена задача оптимизации системы AAA по критерию издержек Оператора на предоставление услуг.
В работе получены следующие результаты:
1. Разработано формализованное описание объекта исследования - системы AAA конвергентной сети типа WLAN/UMTS.
2. Исследованы механизмы AAA в реальном времени во WLAN-домене конвергентной сети типа WLAN/UMTS.
3. Сформулирована задача оптимизации системы AAA по критерию издержек Оператора на предоставление услуг.
4. Предложена функциональная модель предмета исследования.
5. На основе функциональной модели разработана математическая модель системы AAA WLAN/UMTS-сети.
6. Создана имитационная модель объекта исследования, на ее основе разработана программа для ЭВМ, моделирующая процессы AAA. С помощью этой программы проведена серия экспериментов для проверки аналитических результатов диссертационной работы. Получено подтверждение годности разработанных моделей для оптимизации систем AAA конвергентных WLAN/UMTS-сетей.
7. Выбран и применен метод решения задачи оптимизации на основе предложенной математической модели. С использованием имитационного моделирования доказана корректность полученного решения.
Научная библиотека диссертаций и авторефератов disserCat http://www.dissercat.com/content/issledovanie-mekhanizmov-autentifikatsii-avtorizatsii-i-ucheta-v-rezhime-realnogo-vremeni-v-#ixzz2NYXCGqvV
Протоколы ААА: RADIUS и Diameter. Серия «Телекоммуникационные протоколы». Книга 9
Б. С. Гольдштейн, В. С. Елагин, Ю. Л. Сенченко.
СПб.: БХВ – Санкт-Петербург, 2011.
Девятая книга серии «Телекоммуникационные протоколы».
Рассматриваются протоколы и процедуры аутентификации, авторизации и учета AAA (Authentication, Authorization, Accounting) в современных сетях мобильной и фиксированной связи. AAA обеспечивают управление доступом к любым сетям связи и играют ключевую роль всюду, где требуется представить конечному пользователю счет за предоставленные инфокоммуникационные услуги, включая традиционную телефонию, широкополосный доступ, услуги маршрутизации, услуги шлюза и т.п. Важность ААА-операций все более возрастает по мере распространения сетей NGN/IMS. Книга содержит подробные сведения о двух наиболее распространенных сегодня AAA-протоколах.
Журнал «Вестник связи», №12, 2006
1
ПРОБЛЕМЫ И РЕШЕНИЯ
СОРМ-2
Б.С. ГОЛЬДШТЕЙН, заведующий кафедрой СПбГУТ,
Ю.А. КРЮКОВ, научный сотрудник ЛОНИИС,
В.И. ПОЛЯНЦЕВ, главный специалист ФАС
Информационная безопасность и инженерные проблемы СОРМ-2
Характерная для всех бурно развивающихся отраслей ситуация сложилась с
современными телекоммуникациями: их развитие происходит сегодня с заметным
опережением формирования необходимых стандартов и апробированных механизмов и
подходов. Это в полной мере справедливо для стандартизации функций СОРМ
(системы оперативно-розыскных мероприятий) или законного перехвата сообщений LI
(LawfulInterception) в терминах Европейского института стандартизацииETSI. И если
для традиционной телефонии с коммутацией каналов ситуация со стандартизацией
СОРМ [1] обстоит относительно благополучно (не без некоторого участия и авторов
этой статьи), то для СОРМ-2 в современных IP-сетях пока гораздо больше открытых
вопросов, чем стандартизованных решений. В статье рассмотрены некоторые
технические проблемы известных сегодня подходов к СОРМ-2 для IP-сетей, варианты
их решений, как апробированные на практике, например, в используемой
американским ФБР системе Carnivore/DCS1000 [2], так и предлагаемых пока
исключительно на идейном уровне.
Принцип функционирования систем законного перехвата сообщений СОРМ-2
заключается в обнаружении в реальном времени попыток контролируемого объекта
получить доступ к услугам своего Интернет-провайдера (ISP–InternetServiceProvider)
и последующем перехвате этой информации. Перехваченная таким образом
информация форматируется и передается правоохранительным органам – LEA(Law
EnforcementAgency) в терминахETSIили ПУ (пункт управления) в терминах
российского СОРМ. Во всех случаях фактическая процедура реализации функций
СОРМ-2 (как, впрочем, и СОРМ-1) определяется двумя составляющими –
организационным решением на осуществление перехвата информации от
уполномоченного органа и наличием технологии, делающей осуществимым этот
перехват.
Здесь, как и в телефонных сетях с коммутацией каналов, оператор и/или провайдер
услуг юридически обязан развертывать архитектуру СОРМ и рассматривать ее как
часть собственной сетевой инфраструктуры.
Процедуры законного перехвата сообщений СОРМ-2 начинаются с выделения логина
объекта наблюдения в динамически распределяемых IP-адресах.Для этого обычно
используется протокол RADIUS (Remote Authentication Dial In User Service),
выполняющий функции аутентификации, авторизации и учета ААА (Authentication,
AuthorizationandAccounting). После того, как становится известенIP-адрес
контролируемого объекта, механизм СОРМ-2 автоматически реконфигурируется для
захвата всего IP-трафика к/от контролируемогоIP-адреса так, чтобы иметь
возможность интерпретировать, трансформировать и передать перехваченные данные в
ПУ. Другой пример – протокол DIAMETER[3], поддерживающий функциональностьЖурнал «Вестник связи», №12, 2006
2
ААА как для существующих сетей, так и для сетей связи следующего поколения NGN
(NextGenerationNetwork).
Еще раз подчеркнем, что процедуры СОРМ-2 в IP-сетях пока не имеют
стандартизованных решений. Более того, IETF– организация, которая анализирует
развитие Интернета и выпускает соответствующие стандарты по используемым
протоколам, фактически отклонила идею включения функциональности СОРМ в свои
разработки. В то же время современный Интернет состоит из очень большого числа
протоколов, каждый из которых обеспечивает предоставление пользователям
разнообразных Интернет-услуг. К тому же стремительный, непрогнозируемый рост
популярности услуг Интернета еще более осложняет задачу, так как первоначальные
академические цели Интернета были весьма далеки от нынешней проблематики
глобальной сети общего пользования.
Кроме того, чрезвычайно важное для дальнейшего материала статьи понятие
информационной безопасности де-факто было внесено в архитектуру Интернета
значительно позже, а на начальном этапе развития, характеризующегося
университетской открытостью, ранние протоколы стека TCP/IPосновывались на
предположении о правильности информации IP-адреса вIP-заголовке и передаче
пользовательских имен и паролей в явном виде. Последующее развитие концепции
безопасности нашло выражение в принятии спецификации IPSecurity–IPsec,
представляющей собой комплект протоколов шифрования, аутентификации и
обеспечения защиты при транспортировке IP-пакетов.
Обеспечение безопасности актуально в IP-сетях в целом, а в контексте данной статьи
создает значительные проблемы для СОРМ-2. Дело в том, что защита пользовательских
соединений осуществляется, в частности, с помощью анонимности информации об
отправителе и получателе сообщений. При этом подходе не только злоумышленник, но
и система СОРМ-2 не смогут перехватывать пользовательский трафик. Не говоря уже о
случае перехвата пользовательской информации, когда она шифруется
непосредственно конечными пользователями.
Вместе с тем, новые Интернет-протоколы поддерживают новые возможности и
средства законного перехвата IP-трафика. Речь идет о протоколахRADIUSи
DIAMETER.
Возможности RADIUS
Критериями для законного перехвата IP-трафика, циркулирующего в Интернете, могут
выступать IP-адрес, МАС-адрес илиIDкабельного модема (по аналогии со списочным
номером абонента, используемым в качестве критерия в ТфОП). Кроме того, критерием
СОРМ-2 могут являться данные прикладного уровня, например, адреса электронной
почты или InstantMessagingID, пользовательские именаRADIUS.
Наиболее полными с точки зрения получаемых возможностей СОРМ-2 являются
системы, построенные на основе анализа протокола RADIUS(RemoteAuthentication
DialInUserService), с помощью которого происходит аутентификация, авторизация и
учет ААА (Authentication, Authorization and Accounting) пользователя при попытке
доступа в сеть. Журнал «Вестник связи», №12, 2006
3
Для доступа dial-upв роли пользовательского оборудования выступает компьютер и
модем, которые обеспечивают соединение с сетевым сервером доступа MAS(Network
AccessServer), используя его телефонный номер ТфОП, и получают доступ к ресурсам
сети провайдера услуг Интернета. После установления соединения с сетевым сервером
доступа пользователь проходит процедуру аутентификации, которая заключается в
предоставлении уникального пользовательского имени и пароля.
Прежде чем разрешить доступ пользователя к сети провайдера, NASпроверяет
правильность предоставленной пользователем информации. Эта процедура
аутентификации проводится RADIUS-сервером, который может взаимодействовать со
множеством NAS-серверов различных Интернет-провайдеров, использующих протокол
RADIUS.
Рис. 1. Диаграмма взаимодействия участников СОРМ-2 в IP-сети сRADIUS
Среди определенных протоколом RADIUSсообщений наибольший интерес с точки
зрения реализации функций СОРМ-2 представляют два – это сообщения запроса
доступа Access-Requestи разрешения доступаAccess-Accept. СообщениеAccessRequestпосылается от сетевого сервера доступа кRADIUS-серверу и содержит в своем
формате поля, соответствующие имени пользователя и его паролю. Информация о
пользовательском имени и пароле представляется в определенной форме – в атрибутах
RADIUS User-Name и User-Password.
В сети провайдера RADIUS-сервер, выступающий в роли централизованной службы
аутентификации, авторизации и учета, после получения от сетевого сервера доступа
сообщения Access-Requestпроверяет пользовательское имя и пользовательский пароль.
По результатам проверки пользователь либо получает доступ к сетевым ресурсам, либо
ему дается отказ. В первом случае RADIUS-сервер посылает в обратном направлении
сообщение Access-Accept, содержащее присвоенный пользователюIP-адрес (Framed-IPAddress), который указывает сетевому серверу доступаIP-адрес, присвоенный
пользователю для запрашиваемого доступа. Журнал «Вестник связи», №12, 2006
4
Процедура прохождения аутентификации предполагает, что специальное устройство –
медиатор СОРМ типа XSM– будет анализировать весь трафик, проходящий между
сетевым сервером доступа и RADIUS-сервером, с целью распознавания в поле имя
пользователя соответствующего критерия СОРМ – пользовательского имени объекта
контроля. В случае совпадения этих параметров медиатор СОРМ будет ожидать
сообщения Access-AcceptотRADIUS-сервера. Соответствие между сообщениями
Access-RequestиAccess-Acceptустанавливается с помощью служебных
идентификационных полей.
Как только медиатор СОРМ получает сообщение Access-Accept, соответствующее
критерию СОРМ, происходит процесс его реконфигурации с целью обеспечить
перехват всего пользовательского трафика к/от контролируемого объекта,
определяемого IP-адресом, указанным в сообщенииAccess-Accept. Получаемый таким
образом пользовательский трафик через соответствующие интерфейсы (в терминах
ETSIдля этих целей используется интерфейсHI3) передается к ПУ
правоохранительных органов. Информация, связанная с перехватом, формируется на
основе сообщений Access-RequestиAccess-Acceptи в специальном формате,
оговоренном национальным стандартом, через интерфейс HI2 также передается к ПУ.
На рис. 1 представлена упрощенная диаграмма взаимодействия всех участников
процесса реализации функции СОРМ-2 в сети провайдера Интернет-услуг. В качестве
сервера, реализующего функции аутентификации, авторизации и учета, используется
RADIUS-сервер. Применение других протоколов для аутентификации, авторизации и
учета не будет вносить серьезных изменений в представленный механизм,
определяющий общий порядок взаимодействия.
Механизм взаимодействия медиатора СОРМ и ПУ при вышеописанной организации
функций СОРМ в сети Интернет-провайдера в целом незначительно отличается от уже
функционирующего в сетях доступа. Основные отличия будут наблюдаться на участке
взаимодействия медиатор СОРМ – ПУ в форматах информации, передаваемой через
интерфейсы HI2 иHI3, что нисколько не нарушит сложившуюся практику и
методологию СОРМ.
Заметим, что текущая версия протокола RADIUSориентируется на аутентификацию
пользователей по версии Интернет-протокола IPv4. Для обеспечения процедуры
аутентификации пользователей Интернет-услугами следующей версии Интернет-
протокола IPv6 в протоколRADIUSдобавляются некоторые сообщения, например,
Framed-Interface-IdиFramed-IPv6-Prefix, определяющие для сетевого сервера доступа
идентификатор интерфейса и префикс, которые были предоставлены сервером RADIUS
пользователю, запрашивающему услугу IPv6. Помимо вышеупомянутых сообщений,
новая спецификация определяет, что если RADIUS-сервер полностью поддерживает
архитектуру аутентификации для IPv6, то он должен также поддерживать возможность
использования IPsec, о чем говорилось в предыдущем разделе статьи.
Из этого следует, что сообщение Access-Request, передаваемое от сетевого сервера
доступа к RADIUS-серверу, и сообщениеAccess-AcceptотRADIUS-сервера к сетевому
серверу доступа будут содержать информацию (имя пользователя и IP-адрес) в
зашифрованном виде. Таким образом, для медиатора СОРМ исключается возможность
определить IP-адрес контролируемого объекта. Журнал «Вестник связи», №12, 2006
5
Для решения этой проблемы возможно использование двух путей – доступность
медиатору СОРМ ключей шифрования или реализация сценария взаимодействия
пользователь – сетевой сервер доступа – RADIUS-сервер – медиатор СОРМ, при
котором последнему информация передается в незашифрованном виде.
Рис. 2. ESPрасширение заголовка дляIPv6
Возможности DIAMETER
Протокол DIAMETERбыл разработан рабочей группойIETF, занимающейся
вопросами аутентификации, авторизации и учета, для поддержания этой архитектуры в
сетях связи следующего поколения. Этот протокол предназначен для использования в
существующей инфраструктуре, а также мобильных IP-сетях, для поддержки роуминга
и пр. В добавление к этому отметим, что DIAMETERполностью поддерживает
вышеупомянутую функциональность RADIUS, также выполняя задачи
аутентификации, авторизации и учета.
Основной протокол обычно используется в соединении с прикладным приложением
DIAMETER, которое определяет специфические детали, используемые этим
приложением, например, приложение DIAMETERMobileIPv4 илиDIAMETERдля
сетей доступа. В этом случае DIAMETER-клиент, поддерживающий определенное
приложение DIAMETER, связывается сDIAMETER-сервером, который также
поддерживает определенную спецификацию приложения DIAMETER.
Для передачи в DIAMETER-сервер необходимой для аутентификации, авторизации и
учета информации протоколом DIAMETERиспользуется модель данныхAVP
(Attribute-Value Pair), т. е. представления вида <имя атрибута, величинах>. В данном
случае AVPсостоит из специальногоAVP-кода и идентификатора отправителя для
определения уникальных признаков, а также их оценки. Формат DIAMETER-
сообщений разрешает использование множества AVPв сообщении.
В качестве примера использования протокола DIAMETERрассмотримDIAMETER-
приложение для сетей доступа, которое используется ISPдля предоставления сервисов
доступа. Литература [4] определяет команды AA-RequestиAA-Answer, которые
посылаются к и от сервера DIAMETER, соответственно, и обеспечивают процедуру
аутентификации пользователя, запрашивающего доступ. Хотя [4] определяет оба этих
сообщения, тип данных, формат заголовка и механизмы безопасности, которые
используются этим частным приложением, полностью данные определяются базовым
протоколом DIAMETER[3]. Подобно числу сетей доступа в вышеупомянутыхЖурнал «Вестник связи», №12, 2006
6
сообщениях используются специфические AVRтакже отличающиеся на уровне
приложений.
Проблема ESP
Выше в статье уже упоминалась разработанная IETFархитектураIPsecдля безопасной
передачи IP-трафика, определяющая, в частности, контроль доступа, целостность
данных, аутентификацию и шифрование. Применение процедур IPsecна хосте или
маршрутизаторе призвано защитить принимаемый и передаваемый пользовательский
трафик и затрудняет осуществление мероприятий СОРМ-2.
Дело в том, что ключевым компонентом этой архитектуры, определяющим как
поддерживается шифрование, является расширение заголовка данных для безопасной
инкапсуляции данных ESP (Encapsulating Security Payload) [5]. РасширениеESP
определено как для трафика IPv4, так иIPv6. ПрименениеESPможет быть
осуществлено двумя способами: транспортным и туннельным.
Транспортный вариант осуществляет защиту информации на уровнях вышестоящих
уровню IP, но не защищает самIP-заголовок. Туннельный вариант защищает весьIP-
пакет и подразумевает инкапсуляцию зашифрованных данных, т. е. в этом случае
исходный зашифрованный IP-пакет находится внутри другого пакета.
На приведенном в качестве примера рис. 2 заголовок верхнего уровня и данные (в этом
случае TCP) могут быть зашифрованы и аутентифицированы с помощьюESP.
Расширение заголовка ESPразмещается до и после внутренних защищаемых полей.
Проблемы IPv6
Теперь рассмотрим сценарий развертывания сети, в которой ISPпредоставляет сервис
IPv6 с реализацией функций ААА на основе протоколаDIAMETER. Указанные
специальные приложения DIAMETER, расширяющие базовый протоколDIAMETER
для данного сценария, определены в [3, 4]. Например, после того, как пользователь
набирает номер к сетевому серверу доступа, NASпосылает серверуDIAMETERзапрос
аутентификации и/или авторизации AA-Request, а вAVPуказывает такую
информацию, как User-NameиUser-Password, соответствующие имени и паролю
пользователя. В этом случае сервер DIAMETERотвечает сетевому серверу доступа с
помощью сообщения AA-Answer, содержащего соответствующуюAVP.
В случае предоставления услуг IPv6 вAVPопределяютсяFramed-Interface-IdиFramedIPv6-Prefix, которые сообщают сетевому серверу доступа об идентификаторе
интерфейса IPv6 и префиксах, сформированных сервером для пользователя. ЭтиAVP
присутствуют в сообщении AA-Answer, посылаемом от сервера к сетевому серверу
доступа, и используются сетевым сервером доступа для информирования пользователя
о сформированном IPv6-адресе.
В этом случае применимы определенные в базовом протоколе DIAMETER
спецификации безопасности. Поэтому связь между сетевым сервером доступа и
сервером DIAMETERорганизуется с использованиемESPIPsecс "ненулевым"
алгоритмом шифрования. Журнал «Вестник связи», №12, 2006
7
Как и в случае использования сервисов IPv6 на основе аутентификацииRADIUS,
рассматриваемый случай не позволит системе СОРМ-2 определить попытку
контролируемого объекта получить доступ к сети Интернет-провайдера или
обнаружить, что пользователю были назначены идентификатор интерфейса IPv6 и
префикс. Все последующие действия контролируемого объекта, проводимые им на
основе выделенного адреса, также не смогут быть перехвачены.
Депонирование ключей шифрования
Возможным решением вышеизложенных проблем является предоставление системе
СОРМ-2 ключей шифрования, используемых ААА-инфраструктурой. Это вариант
предоставления ключей в виде их депонирования, т. е. сохранения ключей шифрования
в некоей доверенной системе, например, у того же ISP. Это решение депонирования
ключей отчасти противоречит желанию обеспечить конфиденциальность передаваемой
через IP-сеть информации.
Более того, для обеспечения конфиденциальности связи необходимо обеспечить и
защиту ISPот возможных внешних вторжений с целью доступа к ключам шифрования.
Внешние атаки могут быть инициированы как с целью получения доступа к ключам,
используемым для шифрования ААА-сообщений, так и получения ААА-информации,
например, такой как присвоенный пользователю IP-адрес, что позволит
злоумышленнику совершать несанкционированные перехваты.
Протокол законного перехвата информации
Другим возможным решением проблем СОРМ-2 в IP-сетях может служить создание
специального протокола прикладного уровня, который бы позволял ПУ СОРМ
определять моменты начала и окончания использования контролируемым
пользователем услуг сети и осуществлять перехват пользовательской информации,
циркулирующей к/от определенного IP-адреса.
Рис. 3. Диаграмма взаимодействия участников СОРМ-2 в IP-сети сDIAMETERЖурнал «Вестник связи», №12, 2006
8
С помощью такого протокола СОРМ может информировать ААА-сервер, что она
нуждается в перехвате пользовательского контента передаваемого/получаемого
контролируемым объектом с определенным идентификатором, например, <имя
пользователя>@<домен>. В этом случае ААА-сервер, используя тот же самый
протокол, информировал бы систему СОРМ о пользовательском логине и
используемом объектом контроля IP-адресе для перехвата информации.
По окончании пользовательской сессии ААА-сервер или устройство доступа сообщили
бы системе СОРМ об окончании сессии для прекращения процедуры перехвата. С
использованием такого протокола система законного перехвата могла бы также
информировать ААА-сервер об окончании необходимости перехвата информации
конкретного объекта контроля.
Рис. 3 иллюстрирует сообщения для описанного выше гипотетического случая,
представляющего возможное решение изложенной выше проблемы IPv6 и протокола
DIAMETER. Показанные на рис. 3 сообщенияDIAMETER(между сетевым сервером
доступа и ААА-сервером) определены в [3,4].
Вместо заключения
Появляющиеся в сетях Интернет-провайдеров системы законного перехвата IP-
сообщений строятся на основе медиаторов СОРМ, ориентированных на обработку
сообщений протокола RADIUSдля определения присвоенного объекту контроляIP-
адреса и последующего перехвата всей циркулирующей к нему/от него информации.
Такие медиаторы существуют и для российских стандартов СОРМ, но для будущих
сетевых структур СОРМ-2 сетей связи с IPv6 и мобильнымIPv6 с ориентированной на
DIAMETERархитектурой ААА и с использованием шифрования.
Причем, в соответствующем RFCоговаривается использованиеIPsecсESPи
"ненулевого" алгоритма шифрования. В этом случае критическим для реализации
СОРМ-2 будет точная идентификация адресов и местоположения объекта наблюдения,
а также использование шифрования информации объекта наблюдения при попытке
доступа в сеть. Эти факторы требуют расширения функциональности и сетевых
конфигураций систем СОРМ, описанных в этой статье. Разумеется, описанные в
качестве примеров возможные решения должны быть развиты и тщательно
проанализированы соответствующими специалистами.
В целом же выполнение функций СОРМ-2 для IP-сетей является сложной и
относительно новой задачей, требующей анализа и обсуждения спецификаций и
инженерных решений. Конечной целью посвященных данной тематике исследований
является нахождение компромисса между безопасностью связи и ее открытостью для
средств СОРМ-2, также обеспечивающих безопасность граждан и государства. Журнал «Вестник связи», №12, 2006
9
Литература
1. Гольдштейн Б.С., Крюков Ю.А., Хегай И.П. Инженерные аспекты СОРМ/ Вестник
связи. - 2005. № 9.
2. Lawful Interception for IP Networks. White Paper, Aqsacom Inc., Tech. Rep., 2004.
3. P. Calhoun, J. Loughney, E. Gutman, G. Zorn, J. Arkko. Diameter Base Protocol, RFC
3588, September 2003.
4. P. Calhoun, G. Zorn, D. Spence, D. Mitton. Diameter Network Access Server Application.
5. S. Kentand, R. Atkinson. IP Encapsulating Security Payload (ESP), RFC2406, November
1998.
6. Крюков Ю.С., Ярыгин А.Г. Процедура законного перехватаIPтрафика.
Международный опыт, INSIDE, № 6 2005.
7. D. Johnson, С. Perkins, J. Arkko. MobilitySupportinIPv6.
Bog BOS: IOS: AAA (authentication, authorization, accounting), tacacs+, RADIUS
Сервер доступа (tacacs+, RADIUS) - это программа, которая крутится на UNIX-компьютере и отвечает на запросы киски типа: есть ли такой пользователь, какие у него права и ведет журнал посещений. AAA расшифровывается как authentication (установление личности пользователя), authorization (проверка полномочий) и accounting (учет использования ресурсов). Для каждой из трех функций используется поименованный список методов, примененный к интерфейсу. При необходимости использования любой функции AAA IOS "пробегает" по этому списку пытаясь соединиться с соответствующим сервером. Если соединиться не удается (локальная БД отвечает всегда), то IOS переходит к следующему методу из списка. Если методов в списке не осталось, то регистрируется отказ. По умолчанию, к каждому интерфейсу применяется список методов по имени default. Если не требуется что-то необычное, то рекомендуется определить ровно один свой список методов с именем default и пусть он применяется ко всем интерфейсам.
Как конфигурировать сервер TACACS+ смотри отдельную главу, для конфигурирования RADIUS глава еще(?) не написана. Cisco позволяет использовать все атрибуты TACACS+ при работе с RADIUS при помощи vendor specific attribut (cisco-avpair= "shell:priv-lvl=15"). NAS привязывается к серверу так (надо включить AAA и определить параметры серверов, можно определить несколько TACACS+ или RADIUS серверов - в этом случае NAS будет пробовать их по очереди): ═ ═aaa new-model # будем использовать tacacs+, а не старые варианты ═ ═aaa processes число # количество параллельных процессов, обслуживающих AAA (количество одновременно заходящих пользователей). У меня загрузка второго процесса составляет 10% от загрузки 1го, так что, думаю, что двух достаточно. ═ ═show ppp queues # показывает, сколько AAA процессов запущено и их статистику (странное название и странные числа он показывает) ═ ═tacacs-server host IP-адрес-tacacs+-сервера [single-connection] [port порт(49)] [timeout секунд] [key ключ-шифровки] # tac_plus 4.0.2 не поддерживает single-connection; можно указывать несколько серверов, они будут пробоваться по очереди ═ ═tacacs-server key key <пароль> # ключ, с помощью которого шифруются сообщения между киской и tacacs+ сервером ═ tacacs-server retransmit retries # число попыток достучаться до сервера (по умолчанию - 2) ═ tacacs-server timeout seconds # сколько ждать, чтобы убедиться, что сервер не работает (по умолчанию - 5 секунд) ═ ip tacacs source-interface subinterface-name # задать исходный IP-адрес TACACS пакетов ═ tacacs-server directed-request # включен по умолчанию; управляет использованием имен пользователей в виде: имя@сервер; если включен, то на указанный сервер (проверяется, что он указан в конфигурации, иначе вся строка посылается на сервер по умолчанию) посылается короткое имя пользователя, если выключен - вся строка на сервер по умолчанию. В документации не описано действие ключа restricted. ═ radius-server host IP-address [auth-port порт] [acct-port порт] non-standard # non-standard означает реализацию cisco и обеспечивает работу ключей key и configure-nas ═ radius-server key ключ ═ radius-server configure-nas # радиус сервер будет снабжать информацией о статических маршрутах и пулах IP адресов ═ radius-server retransmit retries ═ radius-server timeout seconds ═ radius-server dead-time minutes ═ radius-server vsa send [accounting | authentication] # позволять использовать VSA (vendor specific attribut) ═ ip identd # поднять ident сервер
Authentication
Для установления личности определяется список методов идентификации и применяется к определенному интерфейсу.
Проверка при входе на линию: ═ ═aaa authentication login {имя-списка | default } метод1 [ метод2 ] ═...
Методы при проверке на входе бывают следующие:
tacacs+ - использовать сервер TACACS+
none - удостоверять личность без проверки
enable - использовать пароль администратора (enable password) для проверки личности
krb5 - использовать сервер Kerberos 5
krb5-telnet - использовать сервер Kerberos 5 соединяясь с ним через telnet
line - использовать пароль, привязанный к линии
local - использовать локальную БД имен
radius - использовать сервер RADIUS
Для использования сервера kerberos необходимо иметь версию IOS с поддержкой шифровки.
Применить список методов к линии(ям):
line тип-линии номер-линии [конечный-номер-линии-из-интервала]
login authentification { default | имя-списка-методов }
Пример: ═ ═aaa authentication login default tacacs+ enable # по-умолчанию проверяем каждый вход на линию с помощью tacacs+ сервера, а если он не отзывается, то спрашиваем пароль суперпользователя. Т.к. используется имя default, то он будет действовать на всех линиях.
Если пользователи подсоединяются с RAS по PPP, минуя интерфейс командной строки, то для проверки их личности необходимо определить список методов установления личности при соединении PPP, по умолчанию никакой проверки не производится (список default не используется): ═ ═aaa authentication ppp {имя-списка | default } метод1 [ метод2 ] ═...
Применить список методов к интерфейсам (if-needed только для TACACS и XTACACS, callin вызывает аутентификацию только для входных соединений, one-time позволяет вводить имя и пароль в одной строке; д.б. установлена encapsulation ppp на интерфейсе):
Interface тип-интерфейса номер-интерфейса
ppp authentication {chap | pap | chap pap | pap chap | ms-chap } [if-needed] {default | list-name} [callin] [one-time]
Методы при проверке личности во время установления PPP-соединения бывают следующие:
tacacs+ - использовать сервер TACACS+
radius - использовать сервер RADIUS
none - удостоверять личность без проверки
local - использовать локальную БД имен
krb5 - использовать сервер Kerberos 5
if-needed - не делать проверку, если она уже была произведена при входе на линию
Пример: ═ ═aaa authentication ppp default if-needed none # при включении PPP, производим фиктивную проверку пользователя, если не проверяли его раньше (может это уже можно выключить?), т.к. используется имя default, то сами интерфейсы конфигурировать не надо.
Проверка личности при переходе в привилегированный режим: ═ ═aaa authentication enable default метод1 [ метод2 ] ═...
Методы при проверке личности при входе в привилегированный режим:
enable - использовать пароль администратора (enable password) для проверки личности
line - использовать пароль, привязанный к линии
none - удостоверять личность без проверки
tacacs+ - использовать сервер TACACS+
radius - использовать сервер RADIUS
Бывает еще двойная проверка (access-profile, ip trigger-authentication, show ip trigger-authentication, clear ip trigger-authentication) и автоматическая двойная проверка, но это какакя-то муть.
Аутентификация без AAA (как только AAA сконфигурирован, то он имеет больший приоритет)
установление пароля на линию (в режиме конфигурации линии), до 80 букв и цифр (должен начинаться с буквы): password пароль login
проверка имени пользователя (в глобальном режиме конфигурации, password и autocommand д.б. последними в строке, можно использовать несколько строк на одно имя - информация будет накапливаться), используется также для CHAP (чтобы отвечать на CHAP-запросы имя должно соответствовать имени хоста, на удаленном хосте это имя тоже д.б. определено с тем же секретом): username имя [nopassword | password тип-шифровки пароль | password пароль] [callback-dialstring номер-телефона] ═[callback-rotary номер-группы-rotary] [callback-line [tty] line-number[ending-line-number]] [access-class номер-ACL] [privilege уровень ] [autocommand команда ] [noescape ] [nohangup ] Что касается длин имени и пароля: безопасным является использование имен и паролей длиной до 8 символов включительно. Более длинные имена и пароли (якобы до 25 символов, буквы и цифры и пробелы, первый символ - буква) обрабатываются по-разному в разных версиях IOS. CHAP секрет - до 11 символов. tac_plus пароль, шифрованный с помощью crypt - до 8 символов.
установка пароля на привилегированные команды enable [secret] [level уровень-привилегий ] {password | encryption-type encrypted-password} рекомендуется использовать опцию secret (пароль будет храниться в шифрованном виде). Первый уровень привилегий дается каждому пользователю при входе по умолчанию, 15 уровень - режим суперпользователя, команды изменения уровня (enable, disable, exit, help) находится на нулевом уровне. encryption-type:
7 (для enable без secret, собственный алгоритм шифрования, есть программа декодирования)
5 (для enable secret, необратимое шифрование)
0 (незашифрованный текст)
шифровать пароли (а также прочие ключи) service password-encryption
переместить определенную команду на другой уровень (очень удобно для clear line ;) privilege mode level level command (где mode - командный режим: exec, configure, interface, line и др.)
дать всем пользователям, входящим с определенной линии указанный уровень привилегий (в режиме конфигурации линии) privilege level level
посмотреть текущий уровень привилегий show privilege
перейти на другой уровень (в режиме EXEC) enable уровень
Тонкая настройка:
aaa authentication local-override # позволяет использовать локальную базу пользователей перед обращением к другим методам, но такие пользователи получаются абсолютно бесправными (даже EXEC не могут запустить, т.к. не проходят авторизацию).
timeout login response seconds # сколько секунд IOS будет ждать ввода имени или пароля (30 секунд, есть еще количество попыток)
aaa authentication password-prompt text-string (если он не заменен внешним сервером)
aaa authentication username-prompt text-string (если он не заменен внешним сервером)
aaa authentication banner delimiter string delimiter
aaa authentication fail-message delimiter string delimiter
аутентификация при выходных звонках или когда дозвонившийся тоже хочет убедиться, что попал куда хотел (PAP) ppp pap sent-username username password password
отказаться отвечать на запросы CHAP (но выдавать такие запросы самому) ppp chap refuse [callin]
отвечать на запросы CHAP только после того, как собеседник представится (действует по умолчанию) ppp chap wait secret
выдавать себя за указанный хост (по умолчанию посылается собственное имя NAS) для соседей, имя которых не найдено в списке пользователей ppp chap hostname hostname
определить секретное слово (до 11 символов) для CHAP для соседей, имя которых не найдено в списке пользователей ppp chap password secret
количество попыток (по умолчанию 3) tacacs-server attempts count