на каком участке используется механизм инкапсуляции eap over lan или eapol

802.1X и RADIUS

Материал из Xgu.ru

Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.

Автор: Наташа Самойленко
Автор: Игорь Чубин
Короткий URL: 802.1X_RADIUS

На этой странице рассматривается как организовать аутентификацию при доступе к порту коммутатора, поддерживающего стандарт 802.1X. Описываются настройки коммутаторов, а также собственно клиентских машин, которые будут осуществлять доступ в сеть. Рассмотрены случаи, когда аутентификация выполняется для хоста под управлением Windows XP, Linux, на котором запущен Xsupplicant, и Mac OS X.

Протокол RADIUS, его устройство, а также процедура инсталляции и конфигурирования RADIUS-сервера рассматривается на другой странице.

Содержание

[править] Задачи

[править] Основные понятия

AAA (authentication, authorization, accounting) — это набор сервисов сетевой безопасности, которые определяют подход для организации контроля доступа к сети.

Authentication (аутентификация) — процеcс подтверждения пользователем своей подлиности, подтверждения того, что пользователь запрашивающий сервис легитимный пользователь системы (в системе существует учетная запись для этого пользователя). Аутентификация может осуществляться по паролю, смарт-карте, сертификату и др.

Authorization (авторизация) — определяет какие сервисы будут доступны или какие сервисы будут запрещены пользователю прошедшему аутентификацию.

Accounting (учёт) — слежение за потреблением сетевых ресурсов пользователем.

EAP (Extensible Authentication Protocol) — протокол определяющий подход к процедуре аутентификации (не определяет конкретный механизм аутентификации). На основе этого подхода могут быть реализованы различные механизмы аутентификации, называемые методы EAP. EAP определяет формат сообщений, а каждый протокол использующий EAP определяет способ инкапсуляции сообщений EAP в свой формат.

EAPOL (EAP over LANs) — протокол определяющий способ инкапсуляции, который позволяет передавать пакеты EAP между supplicant и аутентификатором в локальных проводных сетях.

PAE (Port Access Entity) — отвечает за выполнение алгоритмов и протоколов.

[править] Настройка коммутатора Cisco для работы аутентификатором

Базовая настройка 802.1X на интерфейсе fa0/1 и настройка параметров RADIUS-сервера:

[править] Настройка коммутатора HP ProCurve для работы аутентификатором

Базовая настройка 802.1X на портах 1-12 и настройка параметров RADIUS-сервера:

Источник

Cisco Secure Access Solutions 03 EAP Over LAN или 802.1X

EAP over LAN (802.1X)

IEEE 802.1X (или Dot1x) является стандартом для port-based network access control для local area and metropolitan area networks.

802.1X работает с тремя основными компонентами:

Ещё раз подчеркнём: Authenticator работает лишь как посредник. Сама операция Authentication происходит между Supplicant и Authentication Server.
Switch или WLC не имеет никакого отношения ни к EAP Type, ни к Credentials. Authenticator тупо берет EAP Frame, инкапсулирует его в RADIUS и отсылает его на Authentication Server.

EAP Types

Существует множество различных EAP Types, каждое из которых имеет свои преимущества и недостатки.
EAP Type определяет authentication mechanism, который будет работать с EAP.
EAP Types могут быть разделены на две категории:
— Native EAP types
— Tunneled EAP types
Tunneled EAP types попросту использует Native EAP types внутри туннеля Transport Layer Security (TLS), который поднимается между supplicant и authenticator.

Native EAP Types (Nontunneled EAP)

Tunneled EAP Types

Мы рассмотрели native EAP types, которые немедленно отсылают Credentials.
Важно понимать, что Tunneled EAP Types сначала формируют туннель, и только после этого отсылают Credentials.

— EAP-FAST способен работать с EAP-TLS в качестве inner method. Что стало весьма популярно.

Источник

WPA2-Enterprise, или правильный подход к безопасности Wi-Fi сети

В последнее время появилось много «разоблачающих» публикаций о взломе какого-либо очередного протокола или технологии, компрометирующего безопасность беспроводных сетей. Так ли это на самом деле, чего стоит бояться, и как сделать, чтобы доступ в вашу сеть был максимально защищен? Слова WEP, WPA, 802.1x, EAP, PKI для вас мало что значат? Этот небольшой обзор поможет свести воедино все применяющиеся технологии шифрования и авторизации радио-доступа. Я попробую показать, что правильно настроенная беспроводная сеть представляет собой непреодолимый барьер для злоумышленника (до известного предела, конечно).

Основы

Любое взаимодействие точки доступа (сети), и беспроводного клиента, построено на:

Параметры беспроводной сети, в первую очередь ее имя (SSID), регулярно анонсируются точкой доступа в широковещательных beacon пакетах. Помимо ожидаемых настроек безопасности, передаются пожелания по QoS, по параметрам 802.11n, поддерживаемых скорости, сведения о других соседях и прочее. Аутентификация определяет, как клиент представляется точке. Возможные варианты:

Комбинация Open Authentication, No Encryption широко используется в системах гостевого доступа вроде предоставления Интернета в кафе или гостинице. Для подключения нужно знать только имя беспроводной сети. Зачастую такое подключение комбинируется с дополнительной проверкой на Captive Portal путем редиректа пользовательского HTTP-запроса на дополнительную страницу, на которой можно запросить подтверждение (логин-пароль, согласие с правилами и т.п).

Шифрование WEP скомпрометировано, и использовать его нельзя (даже в случае динамических ключей).

Широко встречающиеся термины WPA и WPA2 определяют, фактически, алгоритм шифрования (TKIP либо AES). В силу того, что уже довольно давно клиентские адаптеры поддерживают WPA2 (AES), применять шифрование по алгоритму TKIP нет смысла.

Разница между WPA2 Personal и WPA2 Enterprise состоит в том, откуда берутся ключи шифрования, используемые в механике алгоритма AES. Для частных (домашних, мелких) применений используется статический ключ (пароль, кодовое слово, PSK (Pre-Shared Key)) минимальной длиной 8 символов, которое задается в настройках точки доступа, и у всех клиентов данной беспроводной сети одинаковым. Компрометация такого ключа (проболтались соседу, уволен сотрудник, украден ноутбук) требует немедленной смены пароля у всех оставшихся пользователей, что реалистично только в случае небольшого их числа. Для корпоративных применений, как следует из названия, используется динамический ключ, индивидуальный для каждого работающего клиента в данный момент. Этот ключ может периодический обновляться по ходу работы без разрыва соединения, и за его генерацию отвечает дополнительный компонент — сервер авторизации, и почти всегда это RADIUS-сервер.

Все возможные параметры безопасности сведены в этой табличке:

Если с WPA2 Personal (WPA2 PSK) всё ясно, корпоративное решение требует дополнительного рассмотрения.

WPA2 Enterprise

Здесь мы имеем дело с дополнительным набором различных протоколов. На стороне клиента специальный компонент программного обеспечения, supplicant (обычно часть ОС) взаимодействует с авторизующей частью, AAA сервером. В данном примере отображена работа унифицированной радиосети, построенной на легковесных точках доступа и контроллере. В случае использования точек доступа «с мозгами» всю роль посредника между клиентов и сервером может на себя взять сама точка. При этом данные клиентского суппликанта по радио передаются сформированными в протокол 802.1x (EAPOL), а на стороне контроллера они оборачиваются в RADIUS-пакеты.

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

При этом контроллер внимательно наблюдает за происходящим обменом информацией, и дожидается успешной авторизации, либо отказа в ней. При успехе RADIUS-сервер способен передать точке доступа дополнительные параметры (например, в какой VLAN поместить абонента, какой ему присвоить IP-адрес, QoS профиль и т.п.). В завершении обмена RADIUS-сервер дает возможность клиенту и точке доступа сгенерировать и обменяться ключами шифрования (индивидуальными, валидными только для данной сеcсии):

Все эти методы (кроме EAP-FAST) требуют наличия сертификата сервера (на RADIUS-сервере), выписанного удостоверяющим центром (CA). При этом сам сертификат CA должен присутствовать на устройстве клиента в группе доверенных (что нетрудно реализовать средствами групповой политики в Windows). Дополнительно, EAP-TLS требует индивидуального клиентского сертификата. Проверка подлинности клиента осуществляется как по цифровой подписи, так (опционально) по сравнению предоставленного клиентом RADIUS-серверу сертификата с тем, что сервер извлек из PKI-инфраструктуры (Active Directory).

Поддержка любого из EAP методов должна обеспечиваться суппликантом на стороне клиента. Стандартный, встроенный в Windows XP/Vista/7, iOS, Android обеспечивает как минимум EAP-TLS, и EAP-MSCHAPv2, что обуславливает популярность этих методов. С клиентскими адаптерами Intel под Windows поставляется утилита ProSet, расширяющая доступный список. Это же делает Cisco AnyConnect Client.

Насколько это надежно

В конце концов, что нужно злоумышленнику, чтобы взломать вашу сеть?

Для Open Authentication, No Encryption — ничего. Подключился к сети, и всё. Поскольку радиосреда открыта, сигнал распространяется в разные стороны, заблокировать его непросто. При наличии соответствующих клиентских адаптеров, позволяющих прослушивать эфир, сетевой трафик виден так же, будто атакующий подключился в провод, в хаб, в SPAN-порт коммутатора.
Для шифрования, основанного на WEP, требуется только время на перебор IV, и одна из многих свободно доступных утилит сканирования.
Для шифрования, основанного на TKIP либо AES прямое дешифрование возможно в теории, но на практике случаи взлома не встречались.

Конечно, можно попробовать подобрать ключ PSK, либо пароль к одному из EAP-методов. Распространенные атаки на данные методы не известны. Можно пробовать применить методы социальной инженерии, либо терморектальный криптоанализ.

Получить доступ к сети, защищенной EAP-FAST, EAP-TTLS, PEAP-MSCHAPv2 можно, только зная логин-пароль пользователя (взлом как таковой невозможен). Атаки типа перебора пароля, или направленные на уязвимости в MSCHAP также не возможны либо затруднены из-за того, что EAP-канал «клиент-сервер» защищен шифрованным туннелем.

Доступ к сети, закрытой PEAP-GTC возможен либо при взломе сервера токенов, либо при краже токена вместе с его паролем.

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

Поскольку все вышеозначенные методы (кроме PEAP-GTC) допускают сохранение (кэширование) паролей/сертификатов, то при краже мобильного устройства атакующий получает полный доступ без лишних вопросов со стороны сети. В качестве меры предотвращения может служить полное шифрование жесткого диска с запросом пароля при включении устройства.

Запомните: при грамотном проектировании беспроводную сеть можно очень хорошо защитить; средств взлома такой сети не существует (до известного предела)

Источник

Защита беспроводных сетей, WPA: теория и практика (часть первая)

Тема безопасности беспроводных сетей по-прежнему остается актуальной, хотя уже достаточно давно существуют надежные (на сегодняшний момент, конечно же) методы защиты этих сетей. Разумеется, речь идет о технологии WPA (Wi-Fi Protected Access).

Большинство существующего на данный момент Wi-Fi оборудования имеет поддержку данной технологии, но, к сожалению, до сих пор в нашей лаборатории попадаются экземпляры, не знающие о WPA. Это более чем странно — заканчивается 2005 год, а некоторые производители до сих пор считают, что технология WEP спасет пользователей беспроводной сети от утечки информации. WEP уже давно устарела. На смену этой технологии пришел WPA, а также на горизонте виднеется новый стандарт 802.11i (некоторые производители преподносят его, как WPA2).

За шифрование данных в WPA отвечает протокол TKIP, который, хотя и использует тот же алгоритм шифрования — RC4 — что и в WEP, но в отличие от последнего, использует динамические ключи (то есть ключи часто меняются). Он применяет более длинный вектор инициализации и использует криптографическую контрольную сумму (MIC) для подтверждения целостности пакетов (последняя является функцией от адреса источника и назначения, а также поля данных).

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

Если в сети отсутствует RADIUS-сервер, то роль сервера аутентификации выполняет сама точка доступа — так называемый режим WPA-PSK (pre-shared key, общий ключ). В этом режиме в настройках всех точек доступа заранее прописывается общий ключ. Он же прописывается и на клиентских беспроводных устройствах. Такой метод защиты тоже довольно секьюрен (относительно WEP), очень не удобен с точки зрения управления. PSK-ключ требуется прописывать на всех беспроводных устройствах, пользователи беспроводных устройств его могут видеть. Если потребуется заблокировать доступ какому-то клиенту в сеть, придется заново прописывать новый PSK на всех устройствах сети и так далее. Другими словами, режим WPA-PSK подходит для домашней сети и, возможно, небольшого офиса, но не более того.

В этой серии статей будет рассмотрена работа WPA совместно с внешним RADIUS-сервером. Но прежде чем перейти к ней, немного подробнее остановимся на механизмах работы WPA. А перед этим рассмотрим технологию WPA2.

Технология WPA являлась временной мерой до ввода в эксплуатацию стандарта 802.11i. Часть производителей до официального принятия этого стандарта ввели в обращение технологию WPA2, в которой в той или иной степени используются технологии из 802.11i. Такие как использование протокола CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol), взамен TKIP, в качестве алгоритма шифрования там применяется усовершенствованный стандарт шифрования AES (Advanced Encryption Standard). А для управления и распределения ключей по-прежнему применяется протокол 802.1x.

Как уже было сказано выше, протокол 802.1x может выполнять несколько функций. В данном случае нас интересуют функции аутентификации пользователя и распределение ключей шифрования. Необходимо отметить, что аутентификация происходит «на уровне порта» — то есть пока пользователь не будет аутентифицирован, ему разрешено посылать/принимать пакеты, касающиеся только процесса его аутентификации (учетных данных) и не более того. И только после успешной аутентификации порт устройства (будь то точка доступа или умный коммутатор) будет открыт и пользователь получит доступ к ресурсам сети.

Кроме вышеперечисленных, следует отметить следующие два метода, EAP-TTLS и EAP-PEAP. В отличие от предыдущих, эти два метода перед непосредственной аутентификацией пользователя сначала образуют TLS-туннель между клиентом и сервером аутентификации. А уже внутри этого туннеля осуществляется сама аутентификация, с использованием как стандартного EAP (MD5, TLS), или старых не-EAP методов (PAP, CHAP, MS-CHAP, MS-CHAP v2), последние работают только с EAP-TTLS (PEAP используется только совместно с EAP методами). Предварительное туннелирование повышает безопасность аутентификации, защищая от атак типа «man-in-middle», «session hihacking» или атаки по словарю.

На рис.1 показана структура EAP кадра. Протокол PPP засветился там потому, что изначально EAP планировался к использованию поверх PPP туннелей. Но так как использование этого протокола только для аутентификации по локальной сети — излишняя избыточность, EAP-сообщения упаковываются в «EAP over LAN» (EAPOL) пакеты, которые и используются для обмена информацией между клиентом и аутентификатором (точкой доступа).

Описанный процесс проиллюстрирован на рис.3 (там показан один из простейших методов EAP):

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

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

Первоначальная аутентификация производится на основе общих данных, о которых знают и клиент, и сервер аутентификации (как то логин/пароль, сертификат и т.д.) — на этом этапе генерируется Master Key. Используя Master Key, сервер аутентификации и клиент генерируют Pairwise Master Key (парный мастер ключ), который передается аутентификатору со стороны сервера аутентификации. А уже на основе Pairwise Master Key и генерируются все остальные динамические ключи, которым и закрывается передаваемый трафик. Необходимо отметить, что сам Pairwise Master Key тоже подлежит динамической смене.

Теперь перейдем от сухой теории к реальности, а именно реализации WPA в Windows XP. Нормальная поддержка WPA (с поддержкой AES) появилась, только начиная с windows service pack 2.

Во второй части статьи будет рассмотрена настройка Windows-клиентов (Windows XP SP2), RADIUS-сервера (FreeRadius), и PKI на основе OpenSSL. Последние два компонента работают в операционной системе Gentoo Linux.

Источник

Управление компонентами на базе правил

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

Отдельные составные части инфраструктуры аутентификации, авторизации и учета (Authentication, Authorisation, Accounting, AAA) находятся на разных стадиях стандартизации. Аутентификация осуществляется под контролем протокола IEEE 802.1х и соответствующих реализаций открытого протокола аутентификации (Extensible Authentication Protocol, EAP). Функции учета обычно реализуются при помощи протокола RADIUS в соответствии с RFC 2866, RFC 2867 и RFC 2869, дополненных RFC 3580. Однако в области авторизации и управления правилами реализации разных производителей сильно отличаются по концепции и функциональному охвату. Универсальное сетевое решение на базе правил (см. Рисунок 1) должно предоставлять следующие функции:

АУТЕНТИФИКАЦИЯ И EAP

ЕАР и его варианты (см. Таблицу 1) приобретают все большую известность и признание. Толчком стал пока еще достаточно новый стандарт на аутентификацию в сети на базе портов — IEEE 802.1х. Среди прочего он описывает вариант ЕАР для аутентификации по локальной сети (EAP over LAN, EAPoL; EAP в формате Ethernet). Интерес к EAP возник в связи с требованиями стандартов беспроводных локальных сетей 802.11 a/b/g/h к аутентификации, шифрованию и управлению ключами для TKIP (802.11i и WPA). Однако 802.1х с ЕАР привлекает внимание и применительно к традиционным сетям Ethernet. Кроме того, EAP позволяет реализовать единую идентификацию пользователей в локальных, беспроводных и глобальных инфраструктурах в поддерживаемом Microsoft варианте VPN в рамках IPSec/L2TP.

Посредством открытой коммуникации на базе запросов и ответов EAP позволяет осуществить аутентификацию обеих сторон. Например, аутентифицирующая сторона при использовании карт с маркерами доступа (Security Token Card) может по отдельности запрашивать имя, идентификационный номер и значение маркера. Аутентифицируемая сторона получает всякий раз иной статус аутентификации. Собственно аутентификация происходит при помощи EAP RADIUS (RFC 2869) путем эстафетной передачи пакета EAP серверу RADIUS. Он в свою очередь обращается к службам каталогов (в зависимости от производителя интерфейса это может быть Active Directory от Microsoft, eDirectory от Novell и т. п.) посредством LDAP или XML, а также подключаемых модулей для интеграции карт с маркерами доступа. С учетом требований и приложения предлагается множество вариантов EAP.

EAP TLS

Традиционная аутентификация по протоколу защищенных сокетов (Secure Sockets Layer, SSL) — к примеру при построении соединения HTTPS — ограничивается в большинстве случаев лишь односторонней аутентификацией, или аутентификацией сервера. При этом клиент проверяет идентичность сервера и его сертификата по локальному списку так называемых доверенных сертификационных центров (Trusted Root СА). Указанный список, о котором при соединении HTTP-S обычно заботится браузер клиента, также называется доверительным списком сертификатов (Сertificate Trust List, CTL). «Квитирование» SSL происходит посредством TCP.

В случае безопасности EAP на транспортном уровне (EAP Transport Level Security, EAP TLS) «квитирование» осуществляется при помощи EAP или EAPoL. В отличие от «квитирования» SSL, EAP TLS проводит аутентификацию как клиента, так и сервера, для чего используют следующие обозначения:

После успешной аутентификации происходит — в зависимости от используемой архитектуры — назначение правил доступа к сети и параметров качества услуг (Quality of Services, QoS). Число возможностей при этом достаточно велико:

Типы сетевой политики также могут варьироваться:

COPS-PR

В 1999 г. в IETF появилась рабочая группа по разработке инфраструктуры правил (Policy Framework Working Group). Рабочая группа по правилам допуска к ресурсам (Resource Admission Policy Working Group) тогда занималась стандартизацией общей открытой службы правил (COPS). IETF готовила COPS в расчете на взаимодействие со средой поддержки интегрированных услуг (Integrated Services, IntServ) и протоколом резервирования ресурсов (Resource Reservation Protocol, RSVP). Взаимодействие между точкой выбора правила (Policy Decision Point, PDP) и точкой применения правила (Policy Enforcement Point, PEP) происходит путем передачи и одобрения запросов (см. Рисунок 2). Эта концепция, как и RSVP, не масштабируется на крупные сети, поэтому реализации COPS встречаются очень редко.

Рисунок 2. Примеры концепций применения правил.

С выпуском COPS-PR появился новый протокол на базе COPS — сначала только для сред DiffServ. Причем PDP постоянно выписывает правила для PEP, а не только по запросу, как в случае с COPS. COPS-PR стандартизирован в полном объеме, чего, однако, нельзя сказать о передаваемых правилах.

Используемая в COPS-PR концепция информационной базы правил (Policy Information Base, PIB) очень схожа с основанной на SNMP концепцией базы управляющей информации (Management Information Base, MIB), а также с ее структурным описанием — структурой управляющей информации (Structure of Management Information, SMIv2). Поэтому COPS-PR можно применять для самых различных правил: от IPSec PIB до MPLS RFC 2547bis PIB.

Тогда почему наряду с уже введенным протоколом SNMP необходим еще один протокол, делающий, в принципе, то же самое? Дело в том, что SNMP ориентирован на транзакции, он не учитывает состояние и базируется на UDP, а COPS-PR — напротив — предполагает активное соединение между PDP и PEP. Но оправдывает ли это дополнительные затраты с учетом стабильности сегодняшних сетей? Большинство провайдеров услуг отвечают на этот вопрос отрицательно.

SNMPCONF

Snmpconf находится в процессе стандартизации. Он создавался с целью интеграции MIB и PIB. Но разработчики пошли дальше и предложили абсолютно новый язык сценариев для описания правил, а также относящихся к ним условий и операций. Однако концепция, как и прежде, остается слишком изменчивой, чтобы найти применение в качестве независимого от производителей языка управления правилами: как и сценарии CLI, snmpconf пригоден лишь для отдельных систем. Эта изменчивость усложняет проверку установленных правил на соответствие спецификации snmpconf. До сих пор неизвестно ни об одном производителе, кто поддерживал бы snmpconf.

RADIUS И 802.1X

Стандарт RFC 3580 описывает поведение аутентификатора 802.1x (обычно это точка доступа к беспроводной локальной сети или коммутатор) как ААА-клиента RADIUS. Кроме того, он включает расширение атрибутов учета RADIUS из RFC 2866, RFC 2867 и RFC 2869 со специфическими атрибутами 802.1x. Можно ожидать, что многие простые реализации RADIUS 802.1x будут опираться на этот стандарт. Кроме того, в атрибуте туннеля ответа RADIUS специфицирован так называемый «тип», он используется в качестве идентификатора виртуальной локальной сети стандарта 802.1Q. С его помощью можно реализовать простые правила. Атрибуты туннеля выглядят следующим образом:

Эта концепция могла бы стать наименьшим общим знаменателем — пусть ограниченным по функциям, но для начала и это хорошо. Однако и сегодня, и в ближайшем будущем для более сложных правил предприятия предпочтут статичные правила и/или SNMP, а через некоторое время, возможно, перейдут на Netconf.

DMTF DEN

Специальная группа по разработке стандарта на каталого-ориентированные сетевые технологии была создана еще в 1997 г. В 1998 г. спецификацию DEN заимствовала DMTF и интегрировала ее в общую информационную модель. Это была первая волна сетевых технологий с поддержкой каталога или на базе правил. Она не получила широкого применения прежде всего потому, что схемы DEN очень сложны и исповедуют слишком уж теоретический подход. Недавно рабочая группа правил IETF подготовила ряд документов, уже представленных для стандартизации. Все они базируются на схемах LDAP, которые, в свою очередь, очень схожи с DMTF CIM. Несмотря на то что некоторые производители, в частности Sun и HP, реализовали схожие с CIM решения, ее широкое распространение в сетевом мире маловероятно.

NETCONF

Многие провайдеры услуг заинтресованы в деятельности этой относительно новой рабочей группы IETF. Ее появление в мае 2003 г. стало результатом диалога между IETF и провайдерами. Группа отвечает за описание и распределение правил посредством XML и рассматривает следующие проекты стандартов:

Цель — стандартизация среды для написания сценариев CLI, а также создание формата XML для описания всей конфигурации сетевого компонента. Участники группы делают ставку на существующие стандарты, уже используемые большинством организаций ИТ, к примеру SSH, TLS, SOAP и язык описания служб Web (Web Services Description Language, WSDL). В качестве преимуществ обещается снижение затрат при реализации. Этому должен способствовать текстовый подход на базе XML, который пользователь может интерпретировать гораздо проще, чем кодировку ASN.1 или SMIv2, что облегчает проверку соответствия конфигурации компонента желаемой. Netconf очень похож на статичные правила при конфигурации посредством CLI или SNMP. В отличие от динамических протоколов правил, в нем значительно улучшена предсказуемость поведения сетевых компонентов.

ДИНАМИЧЕСКОЕ НАЗНАЧЕНИЕ ПРАВИЛ

В большинстве случаев администратор распределяет правила при помощи CLI или SNMP (см. Рисунок 3). Эта статичная конфигурация предлагает наибольшую безопасность при предсказуемом поведении сетевых компонентов. Пользовательская персонифицированная сетевая архитектура от Enterasys, например, опирается на разделение управления аутентификацией и правилами: при успешной аутентификации стандартный сервер RADIUS передает внутри атрибута идентификатора фильтра так называемую роль (пользовательскую роль), аналогичную параметру туннеля в RFC 3580.

Однако в данном случае роль представляет собой не просто идентификатор виртуальной сети, она описывает комбинацию специфичных для каждой сети правил, которые администратор статично передал всем сетевым компонентам посредством CLI или SNMPv3 (использование SNMPv3 предпочтительнее для лучшего и более надежного масштабирования решения при распределении и проверке правил). Локально на сетевых компонентах задаются соответствующие настройки MIB, опять же посредством языка CLI. Таким образом, администратор получает еще одну возможность для проверки.

В зависимости от значения идентификатора фильтра в ответе RADIUS роль динамически резервирует порт пользователя. Она может содержать следующие параметры:

Уровень абстракций позволяет комбинировать различные сетевые правила для отдельной службы. Например, VOIP = DSCP EF, т. е. срочная доставка данных и минимальное время задержки при наивысшем приоритете, однако максимальная пропускная способность ограничена величиной 360 Кбит/с (что соответствует ведению трех разговоров одновременно).

Подчеркнем, что применяемый подход по принципу работы очень схож с Netconf.

ЗАКЛЮЧЕНИЕ

Такие концепции, как COPS-PR, snmpconf и DMTF DEN, скорее всего, не получат широкого признания по причине своей сложности. Простые стандарты, наподобие RFC 3580, позволяют дополнить статичные правила CLI и SNMP, которые еще долго будут доминировать на рынке управления на базе правил.

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

Источник