Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012

272Глава 17. Протокол сетевого управления SNMP третьей версии

-описание элементов, связанных с этим типом объекта («UnitsPart») в текстовом формате. Этот компонент может отсут­ ствовать («empty»);

-максимальный уровень доступа («МАХ-ACCESS»). Опреде­ ляет вид разрешенного доступа («Access ::=«);

-статус объекта («STATUS ::=«):

>действующий («current»);

>опротестованный («deprecated»);

>вышедший из употребления («obsolete»);

-определение типа объекта («DESCRIPTION») в текстовом формате;

-ссылки («ReferPart ::=«):

>ссылка («REFERENCE») в текстовом формате;

>отсутствие ссылки («empty»);

осодержательная часть описания SNMPv3-onepan;nn/про­ цедуры («VALUE NOTATION ::=«), включающая наименова­ ние этого типа процедуры («VALUE NotificationName»);

•формат текста («Text ::=«). Текст представляет собой последо­ вательность символов пятизначного международного алфави­ та (International Alphabet 5 - IA5).

Объекты БЫМРуЗ-операции/процедуры. Компонент «ObjectsPart ::=« состоит из следующих элементов (но может отсутствовать «empty»):

•определение объектов («Objects ::=«):

-собственно объект («Object ::=«). Представляет собой имя объ­ екта («ObjectName»), при этом синтаксис объекта определяется запрашиваемым типом SNMPv3-onepa4nn/процедуры («NOTIFICATION-TYPE»).

Описание административных идентификаторов. Для адми­ нистративных идентификаторов используются нулевые значения:

17.7. Модули управляющей информации

Термин «информационный модуль» представляет собой мо­ дуль в ASN.1-формате, определяющий информацию, которая свя­ зана с сетевым управлением. Структура управляющей информации (SMIv2) описывает порядок использования адаптированного подмножества ASN.l-кода (1988г.) для определения информационного

модуля. Более того, «для стандартных» модулей существуют допол­ нительные ограничения. Существует жесткое требование к инфор­ мационным модулям, разработанным частными компаниями (фирмами), - строго придерживаться этих ограничений.

Обычно, существует три разновидности информационных модулей:

оMIB-модули, содержащие описание внутренних связей между объектами управления, и обеспечивающие применение ко­ манд-запросов типа «OBJECT-TYPE» и «NOTIFICATION-TYPE»;

®операторы согласования для MIB-модулей, которые обеспечи­ вают применение команд-запросов типа «MODULECOMPLIANCE» и «OBJECT-GROUP»;

ооператоры функциональности для SNMP-агентов, которые обеспечивают применение команд-запросов типа «AGENTCAPABILITIES».

Такая схема классификации не подразумевает жесткой систе­ матики. Например, «стандартный» информационный модуль бу­ дет, как правило, включать описание объектов управления и опера­ тор согласования. Таким же образом, информационные модули, разработанные частными компаниями (фирмами), могут включать описание объектов управления и оператор согласования. Естествен­ но, что «стандартный» информационный модуль может не вклю­ чать операторы функциональности.

Конструктивные особенности ASN.l-кода позволяют включать в информационные БМ1у2-модули следующие компоненты: оператор «IMPORTS» (запрос внешней информации), описания параметров для идентификаторов объектов «OBJECT IDENTIFIER», описания типов для последовательностей данных «SEQUENCE» (с ограничениями), ограничения на использование в БМ1у2-модулях некоторых типов данных ASN.l-кода, а также элементы ASN.l-запросов/команд, ука­ занные в данном стандарте и других аналогичных документах.

Любые дополнительные ASN.l-запросы/команды не должны описываться в информационных SMIV2-MOдулях. Кроме этого, в информационных 5М1у2-модулях не должны указываться SMIvlзапросы/команды. Наименования всех стандартных информаци­ онных 5М1у2-модулей должны быть уникальны (но различным вер­ сиям одинаковых информационных модулей целесообразно давать одно и то же имя).

Корпоративным разработчикам информационных модулей ре­ комендуется присваивать такие имена своим модулям, которые бы не «конфликтовали» со стандартными модулями или модулями других частных компаний (организаций). При формировании информаци­ онного модуля можно не использовать ASN.l-конструкцию, в которой

274 Глава 17. П рот окол сет ево го у п р а вл ен и я SNMP т рет ьей версии

идентификатор объекта «OBJECT IDENTIFIER» размещается между наименованием модуля и ключевым словом «DEFINITIONS».

В 5М1у2-стандарте имя ASN.l-модуля начинается с буквы в верхнем регистре и продолжается строкой, состоящей из букв, цифр или дефисов, за исключением случаев, когда строка не может закан­ чиваться дефисом, или когда в строке не могут использоваться два подряд идущих дефиса.

Все информационные модули начинаются точно с одного оператора обращения к процедуре в макроопределении «MODULEIDENTITY», который обеспечивает доступ к информации, а также к истории ревизий данных, позволяющие разделять версии данных в одном и том же информационном модуле. Такой оператор проце­ дуры должен быть сразу обнаруживаемым после любого состояния запроса внешних данных («IMPORT»).

Оператор обращения к процедуре в макроопределении. В рамках информационного модуля каждый оператор обращения к процедуре в макроопределении (macro invocation) имеет следую­ щий вид:

< de scrip tor> <m a c ro > <cla u s e s > ::= < v a lu e > ,

где «<descriptor>« (определитель) соответствует идентификатору в ASN.l-коде, «<тасго>« именует макроопределение, к которому происходит обращение, a «<clauses>« (субоператоры) и «<value>« зависят от определения в макроопределении.

Идентификатор в ASN.l-коде состоит из одного или большего числа букв или цифр, а первый символ идентификатора должен быть в нижнем регистре.

Для всех определителей, используемых в информационных модулях, существует следующее правило: определитель должен быть уникальным и мнемоническим и не должен превышать размер из 64 символов. (Примечание. Однако использование определителей длиной более 32 символов не рекомендуется.)

Набор определителей, представленный во всех стандартных информационных модулях, должен быть уникальным.

И в заключении, по стандартному соглашению, если опреде­ литель указывает на объект, в котором оператор синтаксиса «SYNTAX», в свою очередь, указывает на один из счетчиков «Counter32» или «Counter64», то определитель такого объекта дол­ жен указывать максимальное количество.

Текстовые величины и последовательности. Некоторые субопера­ торы (clauses) в операторах обращения к процедуре в макроопреде­ лениях могут использовать последовательность символов в к а ч е с т в е текстовой величины (например, субоператор «DESCRIPTION»)-

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

Последовательность символов начинается и завершается сим­ волом «двойная кавычка» («««), и состоит из произвольного числа (возможно и нулевого):

олюбых 7-битовых экранных ASCII-символов, за исключением «двойной кавычки» («««);

осимволов табуляции;

осимволов «пробел» («space»);

осимволов «конец строки» («line terminator»), «\п» или «\г\п». Значение символьной последовательности интерпретируется в

соответствии с ASCII-кодом.

Бинарная последовательность состоит из произвольного числа (возможно и нулевого) нулей и единиц, которая начинается с сим­ вола «одинарная кавычка» («'«), а заканчивается парой символов «'В» или «Ъ». Число двоичных символов - кратно восьми.

Шестнадцатеричная последовательность состоит из четного числа (возможно нулевого) шестнадцатеричных чисел, которая на­ чинается с символа «одинарная кавычка» («'«), а заканчивается па­ рой символов «'Н» или «Ъ».

Цифры представлены с помощью символов, которые могут быть в верхнем или нижнем регистре.

(.Примечание. Комментарии в ASN.l-коде не могут размещать­ ся внутри любых этих типов последовательностей.)

Импортирование («IMPORTing») символов. Для указа­ ния/ссылки на внешний объект должна использоваться процедура «IMPORTS», в которой указывается определитель и требуемый MIBмодуль, содержащий этот определитель. В этом определителе со­ держится имя запрашиваемого модуля в ASN.l-коде.

Необходимо отметить, что когда в информационных модулях, созданных частными организациями и компаниями («enterprisespecific»), имеется ссылки на специфические символы (например, в определителе), то тогда имеется вероятность коллизий. По сущест­ ву, если запрашиваются различные MIB-объекты с одинаковыми определителями, то тогда такая неоднозначность разрешается пу­ тем установки префикса (приставки) и символа «точка» («.») к име­ ни информационного модуля, т.е.: «module.descriptor».

(Примечание. Все определители в рамках одного любого ин­ формационного модуля должны быть уникальными.)

Естественно, что такая рекомендация может быть использова­ на при ссылке и на те MIB-объекты, даже когда не существует не­ штатных ситуаций при импортировании символов.

Идентификаторы объектов используются в информационных модулях в двух случаях:

орегистрация. Определение соответствующего объекта регист­ рируется как соответствующее значение идентификатора объ­ екта и связанный с ним соответствующий определитель. После такой регистрации любые семантические изменения значения идентификатора объекта не допускаются, а этот идентифика­ тор объекта не может использовать при любой другой регист­ рации объектов. Вместе с этим, определитель также не может быть изменен или не может использоваться при любой другой регистрации объектов. При регистрации объектов фиксиру­ ются следующие макроопределения: «OBJECT-TYPE», «MODULE-IDENTITY», «NOTIFICATION-TYPE», «OBJECTGROUP», «OBJECT-IDENTITY», «NOTIFICATION-GROUP», «MODULE-COMPLIANCE» и «AGENT-CAPABILITIES»;

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

Все представленные выше примеры являются допустимыми, а вот следующий - нет:

dinoH ost O B J E C T ID E N T IF IE R ::= { flintS tones bedrock 2 } .

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

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

A B S E N T A C C E S S A G E N T -C A P A B IL IT IE S A N Y A P P L IC A T IO N A U G M E N T S B E G IN BIT B ITS B O O L E A N B Y C H O IC E C O M P O N E N T C O M P O N E N T S C O N T A C T -IN F O C R E A T IO N -R E Q U IR E S C o u n te r3 2 C o u n te r6 4 D E F A U L T D E F IN E D

D E F IN IT IO N S D E F V A L D E S C R IP T IO N D IS P L A Y -H IN T E N D E N U M E R A T E D

E N T E R P R IS E E X P L IC IT E X P O R T S E X T E R N A L F A L S E F R O M G R O U P G a u g e 3 2 ID E N T IF IE R IM P L IC IT IM P L IE D IM P O R T S IN C L U D E S IN D E X IN T E G E R

278 Глава 17. Протокол сетевого управления SNMP третьей версии

In te g er32 IpA ddress L A S T -U P D A T E D M A N D A T O R Y -G R O U P S M A X M A X -A C C E S S M IN M IN -A C C E S S M IN U S -IN F IN IT Y M O D U L E M O D U L E -C O M P L IA N C E M O D U L E - ID E N T IT Y N O T IF IC A T IO N -G R O U P N O T IF IC A T IO N -T Y P E N O T IF IC A T IO N S N U L L

O B J E C T O B J E C T -G R O U P O B J E C T -ID E N T IT Y O B J E C T -T Y P E O B J E C T S O C T E T O F O P T IO N A L O R G A N IZ A T IO N O p a q u e P L U S -IN F IN IT Y P R E S E N T P R IV A T E

P R O D U C T -R E L E A S E R E A L R E F E R E N C E R E V IS IO N S E Q U E N C E S E T S IZ E S T A T U S S T R IN G S U P P O R T S S Y N T A X T A G S T E X T U A L -C O N V E N T IO N T R A P -T Y P E T R U E

Tim eTicks U N IT S U N IV E R S A L U nsigned32 V A R IA B L E S V A R IA T IO N W IT H W R IT E -S Y N T A X .

17.8. Иерархия имен

Корневой узел субдерева Internet-объектов, администрирова­ нием которого занимается IANA (Internet Assigned Numbers Authori­ ty) следующий (рис. 17.15):

To есть, Internet-субдерево идентификаторов объектов начина­ ется с префикса «1.З.6.1.». Несколько нисходящих ветвей этого суб­ дерева Internet-объектов используются для сетевого управления:

Однако ЭМ1у2-структура не запрещает описание объектов и в других частях дерева Internet-объектов.

Субдерево «mgmt(2)» используется для идентификации «стандартных» объектов.

Субдерево «experimental(3)» используется для идентифика­ ции Internet-объектов, разработанных рабочими IETF-группами по стандартизации. Если созданный рабочей IETF-группой информа­ ционный модуль переходит в «стандартный» информационный модуль, то тогда он преобразуется в категорию «стандарт» и пере­ мещается в субдерево «mgmt(2)».

Субдерево «private(4)» используется для идентификации In­ ternet-объектов, представленных в одностороннем порядке. Субде­ рево «enterprises^)» используется для частного/корпоративного сектора, и в отличие от других объектов используется в подсистемах Internet-провайдеров с целью регистрации различных версий их се­ тевых компонентов.

Глава 18. Система именования

сегментов/областей

В главе 15 были затронуты некоторые аспекты организации DNS-системы (Domain Name System, RFC-1034, RFC-1035) при её взаи­ модействии с электронной почтовой службой в Internet-сети. В дан­ ной главе представлено детальное рассмотрение DNS-системы и её структуры, которая используется прикладными Internet-службами и IP-узлами, а также протоколов и серверов, используемых в качестве средств её реализации.

18.1. Обзор системы

Главная цель системы именования сегментов/областей - реа­ лизация такого метода именования информационных ресурсов, при котором DNS-имена были приемлемы для различных IP-узлов, се­ тей, протоколов, интерсетей и административных организаций.

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

Сточки зрения DNS-клиента, база данных (БД), которая опреде­ ляет пространство сегментов/областей (DNS-БД) распределена среди различных DNS-серверов. Различные части DNS-БД размещены в различных DNS-серверах, несмотря на то, что каждый блок конкрет­ ных данных будет резервироваться и, следовательно, размещаться в двух или более DNS-серверах. DNS-клиент имеет информационную связь, по крайней мере, с одним DNS-сервером. Когда от пользовате­ ля поступает запрос, DNS-клиент обрабатывает его и запрашивает известный DNS-сервер на предмет получения необходимых данных.

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

DNS-серверы управляют двумя типами данных. К первому типу относятся данные, объединенные в определенные множества (груп­ пы), называемые «зонами». Каждая такая зона представляет собой полную БД для соответствующего «вырезанного» подмножества («субдерево») иерархической древовидной структуры пространства

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

В зависимости от собственной производительности, DNS-сервер может быть просто стандартной одиночной программой, загруженной в специализированную машину или процессом(ами) на большом вы­ числительном комплексе. На рис. 18.2 представлен вариант простой конфигурации. В этом случае, первичный DNS-сервер получает ин­ формацию об одной или более зон путем прочтения мастер-файлов из своей локальной файловой системы, и отвечает на запросы (относи­ тельно этих зон) удаленных DNS-клиентов.

Одним из требований, предъявляемых к DNS-системе, являет­ ся то, что все зоны должны обслуживаться с избыточностью путем задействования для этого более одного сервера. Конфигурация сис­ темы с использованием двух серверов представлена на рис. 18.3.

Рис. 18.2. Вариант простой конфигурации DNS-сервера

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