![](/user_photo/_userpic.png)
Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012
.pdf272Глава 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»).
Описание административных идентификаторов. Для адми нистративных идентификаторов используются нулевые значения:
z e ro D o tZ e ro |
O B J E C T -ID E N T IT Y |
||
|
S T A T U S |
current |
|
|
D E S C R IP T IO N |
||
|
"A valu e |
used |
for null identifiers." |
|
::= { 0 0 |
} |
|
17.7. Модули управляющей информации
Термин «информационный модуль» представляет собой мо дуль в ASN.1-формате, определяющий информацию, которая свя зана с сетевым управлением. Структура управляющей информации (SMIv2) описывает порядок использования адаптированного подмножества ASN.l-кода (1988г.) для определения информационного
Раздел II. |
273 |
модуля. Более того, «для стандартных» модулей существуют допол нительные ограничения. Существует жесткое требование к инфор мационным модулям, разработанным частными компаниями (фирмами), - строго придерживаться этих ограничений.
Обычно, существует три разновидности информационных модулей:
о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»)-
раздел II. |
275 |
Другие субоператоры представляют собой двоичные или шестна дцатеричные последовательности (в любом разряде, где допускается неотрицательное число).
Последовательность символов начинается и завершается сим волом «двойная кавычка» («««), и состоит из произвольного числа (возможно и нулевого):
олюбых 7-битовых экранных ASCII-символов, за исключением «двойной кавычки» («««);
осимволов табуляции;
осимволов «пробел» («space»);
осимволов «конец строки» («line terminator»), «\п» или «\г\п». Значение символьной последовательности интерпретируется в
соответствии с ASCII-кодом.
Бинарная последовательность состоит из произвольного числа (возможно и нулевого) нулей и единиц, которая начинается с сим вола «одинарная кавычка» («'«), а заканчивается парой символов «'В» или «Ъ». Число двоичных символов - кратно восьми.
Шестнадцатеричная последовательность состоит из четного числа (возможно нулевого) шестнадцатеричных чисел, которая на чинается с символа «одинарная кавычка» («'«), а заканчивается па рой символов «'Н» или «Ъ».
Цифры представлены с помощью символов, которые могут быть в верхнем или нижнем регистре.
(.Примечание. Комментарии в ASN.l-коде не могут размещать ся внутри любых этих типов последовательностей.)
Импортирование («IMPORTing») символов. Для указа ния/ссылки на внешний объект должна использоваться процедура «IMPORTS», в которой указывается определитель и требуемый MIBмодуль, содержащий этот определитель. В этом определителе со держится имя запрашиваемого модуля в ASN.l-коде.
Необходимо отметить, что когда в информационных модулях, созданных частными организациями и компаниями («enterprisespecific»), имеется ссылки на специфические символы (например, в определителе), то тогда имеется вероятность коллизий. По сущест ву, если запрашиваются различные MIB-объекты с одинаковыми определителями, то тогда такая неоднозначность разрешается пу тем установки префикса (приставки) и символа «точка» («.») к име ни информационного модуля, т.е.: «module.descriptor».
(Примечание. Все определители в рамках одного любого ин формационного модуля должны быть уникальными.)
Естественно, что такая рекомендация может быть использова на при ссылке и на те MIB-объекты, даже когда не существует не штатных ситуаций при импортировании символов.
276 |
Глава 17. П рот окол сет ево го у п р а вл ен и я SNMP т рет ьей версии |
Если любой из типов поименованных объектов и макроопре делений в ASN.l-коде, представленных в данном стандарте, и в ча стности: «Counter32», «Counter64», «Gauge32», «Integer32», «IpAddress», «MODULE-IDENTITY», «NOTIFICATION-TYPE», «Opaque», «OBJECT-TYPE», «OBJECT-IDENTITY», «TimeTicks» и «Unsigned32», a также любые другие, представленные в стандартах RFC-2580 и RFC2579, используются в информационных модулях, то тогда они должны импортироваться с использованием процедуры «IMPORTS».
Однако следующие типы данных не должны запрашиваться с помощью процедуры «IMPORTS»:
•поименованные типы данных в ASN.l-коде, в частности: «INTEGER», «OCTET STRING», «OBJECT IDENTIFIER», «SEQUENCE» и «SEQUENCE OF»;
обитовые конструкции («BITS»).
Комментарии в ASN .l-коде. Информационные модули могут
содержать ASN.l-комментарии. Однако, рекомендуется, чтобы все независимые определения размещались в рамках соответствующих субоператоров «DESCRIPTION».
Комментарии в ASN.l-коде начинаются с пары смежных де фисов («—») и завершаются следующей парой смежных дефисов или знаком окончания строки, в зависимости использования первого символа. Комментарии завершающиеся парой смежных дефисов имеют смысл одиночного знака пробела.
Значения идентификаторов объектов («OBJECT IDENTIFIER») представляют собой упорядоченные последовательности неотрица тельных чисел. С точки зрения SMIv2-CTpyKTypbi каждое число в по следовательности представляется как субидентификатор. Максималь ное число субидентификаторов в значении идентификатора составля ет «128», а каждый субидентификатор может принимать максималь ное значение, равное «232-1» (в десятичной форме «4294967295»).
Все значения идентификаторов объектов имеют, по крайней мере, два субидентификатора, в которых значение первого суби дентификатора может принимать следующие «хорошо известные» названия:
Значение Название
0ccitt
1iso
2
joint-iso- ccitt.
(Примечание. Данная SMIv2-CTpyKTypa не распознает «новые хорошо известные имена», например, ITU - новое название CCITT.)
раздел II. |
277 |
Идентификаторы объектов используются в информационных модулях в двух случаях:
орегистрация. Определение соответствующего объекта регист рируется как соответствующее значение идентификатора объ екта и связанный с ним соответствующий определитель. После такой регистрации любые семантические изменения значения идентификатора объекта не допускаются, а этот идентифика тор объекта не может использовать при любой другой регист рации объектов. Вместе с этим, определитель также не может быть изменен или не может использоваться при любой другой регистрации объектов. При регистрации объектов фиксиру ются следующие макроопределения: «OBJECT-TYPE», «MODULE-IDENTITY», «NOTIFICATION-TYPE», «OBJECTGROUP», «OBJECT-IDENTITY», «NOTIFICATION-GROUP», «MODULE-COMPLIANCE» и «AGENT-CAPABILITIES»;
оназначение. Определитель может назначаться для соответст вующего значения идентификатора объекта. В случае такого применения, любые семантические изменения в рамках зна чения идентификатора объекта не допускаются, а определи тель, назначенный для соответствующего значения идентифи катора объекта, соответственно, не может быть присвоен дру гому объекту. Однако одному и тому же значению идентифи катора объекта может быть присвоено несколько определите лей. Далее приведены указанные варианты назначения не скольких определителей:
mib |
O B J E C T |
ID E N T IF IE R |
::= { m gm t 1 } |
(R F C -1 1 5 6 ) |
|
m ib-2 |
O B J E C T |
ID E N T IF IE R : - { m gm t 1 } |
(R F C -1 2 1 3 ) |
||
fredR ou ter |
O B J E C T |
ID E N T IF IE R |
::= { flintS tones |
1 1 } |
|
barneySw itch |
O B J E C T |
ID E N T IF IE R |
::= { flintS tones b ed ro ck(2) 1 } . |
Все представленные выше примеры являются допустимыми, а вот следующий - нет:
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):
Intern et |
O B J E C T ID E N T IF IE R : = { iso 3 6 1 } . |
To есть, Internet-субдерево идентификаторов объектов начина ется с префикса «1.З.6.1.». Несколько нисходящих ветвей этого суб дерева Internet-объектов используются для сетевого управления:
m gm t |
O B J E C T ID E N T IF IE R |
::= { internet 2 |
} |
|
exp erim ental |
O B J E C T |
ID E N T IF IE R |
::= { internet 3 |
} |
private |
O B J E C T |
ID E N T IF IE R |
::= { internet 4 |
} |
enterprises O B J E C T |
ID E N T IF IE R ::= { private 1 } |
|
Однако ЭМ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-серверы управляют двумя типами данных. К первому типу относятся данные, объединенные в определенные множества (груп пы), называемые «зонами». Каждая такая зона представляет собой полную БД для соответствующего «вырезанного» подмножества («субдерево») иерархической древовидной структуры пространства
280 |
Глава 18. Система именования сегментов/областей |
сегментов/областей. Такие данные называются авторизованными. DNS-сервер периодически проводит проверку того, что его зоны своевременно пополняются новыми данными, и если это не происхо дит, то тогда он запрашивает новую копию информации о зонах, ко торая извлекается из мастер-файлов, хранящихся локально или в других DNS-серверах. Ко второму типу данных относятся данные, хранящиеся в кэш-памяти, которые были получены локальным DNSклиентом. Эти данные могут быть не полными, но они позволяют ус корить процесс обновления данных, когда осуществляется повторное обращение к удаленным данным. Данные, хранящиеся в кэш-памяти, в конце концов, уничтожаются по истечении времени тайм-аута.
Такая функциональная структура изолирована от проблем, связанных с функционированием интерфейса пользователя, восста новлением системы после сбоев при функционировании про граммных модулей DNS-клиентов, пополнением и обновлением БД
вDNS-серверах.
18.2.Общая конфигурация системы
Сервер может использоваться в DNS-системе в разных качест вах, а именно, либо в качестве сервера с программным обеспечени ем, которое запрашивает и получает необходимую информацию от DNS-системы, либо в качестве DNS-серверов, которые отвечают на запросы, поступившие от других серверов, либо в каком-либо ком бинированном (исходя из двух предшествующих качеств) качестве. В простейшем случае, и возможно наиболее типичном, конфигура ция системы может быть такой, как это представлено на рис. 18.1.
Локальный сервер |
Удаленная |
|
|
|
зона |
Запросы от |
|
|
пользователя |
|
Запросы |
Программа |
DNS-клиент |
Удаленный |
пользователя |
|
DNS-сервер |
Ответыдля |
|
Ответы |
пользователя |
75 |
|
Новые и |
|
|
|
правочныв |
|
дополнительные^ |
данные |
|
данные — |
|
|
Кэшпамять
Рис. 18.1. Простейший вариант конфигурации DNS-системы (ее ча<CTtf)
раздел II. |
281 |
Программные модули пользователей взаимодействуют с DNSсистемой через DNS-клиентов. Формат пользовательских запросов и ответов на них определяется прикладным программным обеспече нием сервера и его операционной системой. Запросы пользовате лей, как правило, будут обращаться к операционной системе, а DNS-клиент со своей кэш-памятью будет частью операционной сис темы сервера. Менее производительные серверы могут использо ваться для загрузки в них DNS-клиента в качестве подпрограммы, которая будет взаимодействовать с каждой программой, необходи мой для его обслуживания. DNS-клиенты отвечают на запросы пользователей и в своих ответных сообщения они размещают ин формацию, которую они получили с помощью собственных запро сов от удаленных DNS-серверов и из локальной кэш-памяти.
В зависимости от собственной производительности, DNS-сервер может быть просто стандартной одиночной программой, загруженной в специализированную машину или процессом(ами) на большом вы числительном комплексе. На рис. 18.2 представлен вариант простой конфигурации. В этом случае, первичный DNS-сервер получает ин формацию об одной или более зон путем прочтения мастер-файлов из своей локальной файловой системы, и отвечает на запросы (относи тельно этих зон) удаленных DNS-клиентов.
Одним из требований, предъявляемых к DNS-системе, являет ся то, что все зоны должны обслуживаться с избыточностью путем задействования для этого более одного сервера. Конфигурация сис темы с использованием двух серверов представлена на рис. 18.3.
Рис. 18.2. Вариант простой конфигурации DNS-сервера
В такой конфигурации (см. рис. 18.3), DNS-сервер периодиче ски формирует виртуальное соединение с удаленным DNSсервером с целью копирования зональных данных и проверки того, что существующая копия не изменилась. Сообщения, передаваемые