Мельников Д. А. - Организация и обеспечение безопасности информационно-технологических сетей и систем - 2012
.pdf252 |
Глава 17. Протокол сетевого управления SNMP третьей версии |
Примитивы подсистемы управления доступом. Прикладные модули являются типичными пользователями услуг, предоставляе мых подсистемой управления доступом.
Подсистема управления доступом формирует следующий примитив для проверки условий доступа (разрешен или нет):
statuslnfo rm ation = |
« ус п еш н о » или «о ш и б ка» |
isA ccessA llow ed( |
|
IN securityM odel |
испол ь зуем ая м о дель о б есп еч ен и я б езопасности |
IN s ec u rityN a m e |
пользователь, которы й хо ч ет получить д оступ |
IN securityLevel |
тр еб уе м ы й уровень б езопа снос ти |
IN v ie w T y p e |
тип просм о тр а (с целью чтени я, записи или |
|
уп рав л я ю щ е й о п е р а ц и и ) |
IN co n te x tN a m e |
группа уп р ав л я ю щ е й и нф о рм ац ии , с о д ер ж ащ ая |
|
« v a ria b le N a m e » |
IN v a ria b le N a m e |
0 1 D д л я об ъ е кта уп рав лени я |
). |
|
Примитивы подсистемы обеспечения безопасности. Под система обработки сообщений является типичным пользователем услуг, предоставляемых системой обеспечения безопасности.
Система обеспечения безопасности для генерации сообщений, содержащих запросы или управляющие операции/процедуры, формирует следующие примитивы:
statuslnform ation =
g e n e ra te R e q u e s tM s g (
IN m e s s a g eP ro ce ssin g M o d el IN glo b alD ata
IN m a x M e s s a g e S iz e
IN securityM odel
IN sec u rityE n g in e lD
IN sec u rityN a m e
IN securityLevel
IN s c o p e d P D U
O U T s e c u rityP aram eters
O U T w h o leM sg
O U T w ho leM sg L en g th
обы чно, S N M P -версия
загол ов ок соо б щ ен и я, ад м и ни страти в ны е данны е из со о б щ ен и я, п е р ед ан н о го базовы м S N M P -блоком для и сход ящ его соо б щ ен и я
ав торизованны й базовы й S N M P -б л о к по им ени этого по л ьзов ател я тр еб уе м ы й уровень б езопа снос ти
п о л езн ая н агр узка со о б щ ен и я (откры ты й текст) п а рам е тр ы защ иты (зап ол ня ю тся моделью б езо п а сн о с ти )
полностью сф о р м и р о в ан н о е с о о б щ ен и е д л и н а сф о р м и ров анн ого со о б щ ен и я
Система обеспечения безопасности для обработки входящих сообщений формирует следующие примитивы:
statuslnfo rm ation = |
« ус п еш н о » или « о ш и б ка» (ука за те л ь /зн а ч е н и е |
|
ош иб ки ) |
proce ssln co m in g M s g ( |
|
IN m e s s a g e P ro c e s s in g M o d e l |
обы чно, S N M P -вер сия |
IN m a x M e s s a g e S iz e |
из со о б щ ен и я , п е р ед ан н о го базовы м S N M P -блоком |
IN sec u rityP aram eters |
д л я принятого соо б щ ен и я |
IN securityM odel |
д л я принятого соо б щ ен и я |
IN securityLevel |
уровень б езо па сно с ти |
IN w h o leM sg |
ц ел о е с о о б щ ен и е, п р ин ятое по кан ал у связи |
IN w ho leM sg L en g th |
р азм е р ц ел ого со о б щ ен и я, принятого по каналу |
|
связи |
раздел II. |
253 |
O U T s ec urityE ng ine lD |
и д е нти ф ика ци я пол ьзов ател я |
O U T s e c u rityN a m e |
и д е нти ф икаци я пол ьзовател я |
O U T s c o p e d P D U |
по л езн ая нагр узка со о б щ ен и я (откры ты й текст) |
O U T m a x S iz e R e s p o n s e S c o |
возм ож ны й м аксим альны й р азм е р P D U -б л о ка |
ped P D U |
|
O U T sec u rity S ta te R e fe re n c e |
ссылка на степень защ иты (необходим а для ответа) |
Система обеспечения безопасности для генерации ответных сообщений формирует следующие примитивы:
statuslnform ation =
g en erate R e s p o n s e M s g (
IN m essa g eP ro ce ssin g M o d el IN g lobalD ata
IN m a x M e s s a g e S iz e IN securityM odel
IN securityE ng inelD IN sec urityN a m e
IN securityLevel IN sco p ed P D U
IN s ec u rityS tateR eferen c e O U T s e c u rityP aram eters
O U T w holeM sg
O U T w h oleM sg Length
обы чно, S N M P -вер сия
загол ов ок со о б щ ен и я , ад м и ни страти в ны е д ан н ы е из соо б щ ен и я, п е р ед ан н о го базовы м S N M P -б ло ком д л я и сход ящ его соо б щ ен и я
автори зо ван ны й базовы й S N M P -б л о к по и м ени этого пол ьзов ател я
уровень б езо па сно с ти д л я и сход ящ его со о б щ ен и я п о л езн ая нагр узка со о б щ ен и я (откры ты й те кс т) ссылка на степень защ иты (из поступившего запроса) п а рам етр ы защ иты (устана вл и ва ю тс я м оделью б езо п а сн о с ти )
полностью сф о р м и р о в ан н о е с о о б щ ен и е д л и н а сф о р м и ров анн ого соо б щ ен и я
)
Общефункциональные примитивы. Эти примитивы фор мируются несколькими подсистемами. Все подсистемы, передаю щие информацию (ссылку) о текущем состоянии с целью «обнуле ния» памяти, в которой содержались данные о текущем состоянии, и целью получения новых, формируют следующий примитив:
s tateR elease ( |
IN s ta te R e fe re n c e -- ука за н и е на ссы лку, которая б уд ет у д а л е н а ) |
17.4. Логическая характеристика SNMPv3-npoTOK(^a
Протокол обмена БЫМРуЗ-сообщениями предусматривает следующие типы сообщений (протокольные блоки данных):
1)«GetRequest-PDU» (имеет кодировку «О») - сообщение-запрос;
2)«GetNextRequest-PDU» (имеет кодировку «1») - сообщениезапрос для последовательного просмотра М1В-таблиц;
3)«GetBulkRequest-PDU» (имеет кодировку «5») - сообщение - расширенный запрос;
4)«Response-PDU « (имеет кодировку «2») - сообщение ответ;
5)«SetRequest-PDU « (имеет кодировку «3») - сообщение - уста новочный запрос (запрос на установку параметров);
6)«InformRequest-PDU» (имеет кодировку «6») - сообщение - информационный запрос;
254Глава 17. Протокол сетевого управления SNMP третьей версии
7)«SNMPv2-Trap-PDU» (имеет кодировку «7») - сообщениепрерывание;
Рис. 17.9. Формат SNMP/PDU-блока (запроса)
8) «Report-PDU» (имеет кодировку «8») - ответное сообщениеотчет. В настоящее время функциональное применение и се мантика этого сообщения не определены и не стандартизова ны. Поэтому любой администратор сетевого правления при использовании этого сообщения должен определить его функциональное применение и точную семантику.
Структура SNMP/PDU-блока (запроса) приведена на рис. 17.9. На рис. 17.10 приведена структура расширенного SNMP/PDU-запроса. Кодирование полей:12
Идентификатор |
Параметр |
Параметр |
Изменяемые (запрашиваемые) значения параметров |
|
запроса |
расширения |
расширения |
|
управления (данные управления) |
(request-id) “non-repeaters’1 |
“max-repetitions" |
|
(variable-bindings) |
|
Рис. 17.10. Формат расширенного SNMP/PDU-запроса |
||||
1. «request-id» - |
идентификатор |
SNMP/ PDU-блока (запро |
||
са/ ответа). Это 32-битовое целое число;
2.«error-status» - указатель ошибки (может игнорироваться), оп ределяющий характер ошибки. Это целое число, которое мо жет принимать следующие значения:
1)«поЕггог(О)» - отсутствие ошибок (используется в запро сах);
раздел II |
255 |
2)«tooBig(l)» - слишком большое сообщение;
3)«noSuchName(2)» - отсутствует такое название (для совмес тимости уполномоченных SNMP-серверов);
4)«badValue(3)» - неправильное значение переменного па раметра (для совместимости уполномоченных SNMPсерверов);
5)«readonly(4)» - только чтение (для совместимости уполно моченных SNMP-серверов);
6)«genErr(5)» - ошибка при обработке (формировании) со общения;
7)«поAccess(6)» - доступ невозможен;
8)«wrongType(7)» - неправильный тип запроса;
9)«wrongLength(8)» - недопустимый размер;
10)«wrongEncoding(9)» - некорректное кодирование;
11)«wrongValue(lO)» - недопустимое значение переменного параметра;
12)«noCreation(ll)» - недопустимая процедура формирова ния;
13)«inconsistentValue(12)» - несовместимое значение пере менного параметра;
14)«resourceUnavailable(13)» - недопустимый источник;
15)«commitFailed(14)» - одно из значений переменного пара метра ошибочно;
16)«undoFailed(15)» - аннулирование всех значений перемен ного параметра;
17)«authorizationError(16)» - ошибка авторизации;
18)«notWritable(17)» - запись недопустима/невыполнима;
19)«inconsistentName(18)» - несовместимое наименование;
3.«error-index» - индекс ошибочного параметра управления (может игнорироваться), указывающий на номер (индекс) это го переменного параметра в списке параметров управления. Это целое число в диапазоне «0...2147483647» (в запросах имеет нулевое значение);
4.«variable-bindings» - последовательность переменных пара метров (может игнорироваться), размер которой может быть в диапазоне «0...2147483647»;
5.«поп-repeaters» - специальный параметр. Это целое число в диапазоне «0...2147483647»;
6.«max-repetitions» - специальный параметр. Это целое число в диапазоне «0...2147483647».
256 |
Глава 17. Протокол сетевого управления SNMP третьей версии |
||
|
Диспетчер |
М о д у л ь , |
МОДУЛЬ |
|
S S S S E gS * |
безопасности |
|
Рис. 17.11. Временная диаграмма передачи SNMP-сообщения
сзапросом и получения ответа на этот запрос
17.5.Процедурная характеристика
5ММРуЗ-протокола
Доступ к управляющей информации. Существуют три типа доступа к управляющей информации, обеспечиваемых SNMPv3-npo- токолом:
1)первый тип - процедура информационного обмена (ПИнО) типа «запрос/ответ» («request-response»). В этом случае одна сторона ПИнО, выступающая в роли SNMP-менеджера, пере дает запрос другой стороне ПИнО, выступающей в роли SNMP-агента. В дальнейшем, SNMP-агент отвечает на полу ченный запрос. Данный тип ПИнО используется для восста
раздел II. |
257 |
новления или изменения данных управления, которые связа ны с объектом управления (сетевым устройством);
2)второй тип - тоже ПИнО типа «запрос/ответ» («requestresponse»). В этом случае одна сторона ПИнО, выступающая в роли SNMP-менеджера, передает запрос другой стороне ПИ нО, также выступающей в роли SNMP-менеджера, которая в дальнейшем отвечает на полученный запрос. Данный тип ПИнО используется для оповещения (уведомления) одной стороны ПИнО (принимающей данные уведомления), высту пающей в роли SNMP-менеджера, другой стороной ПИнО (передающей данные уведомления), также выступающей в ро ли SNMP-менеджера;
3)третий тип - ПИнО без подтверждения. В этом случае одна сторона ПИнО, выступающая в роли SNMP-агента, передает сообщение, именуемое «прерывание» («trap») и не требующее ответа, другой стороне ПИнО, выступающей в роли SNMPменеджера, которая в дальнейшем не отвечает на это сообще ние «trap» (после его получения). Данный тип ПИнО исполь зуется для оповещения одной стороны ПИнО, выступающей в роли SNMP-менеджера, об исключительной ситуации, которая явилась результатом изменений управляющих данных, свя занных с объектом управления (сетевым устройством).
На рис. 17.11 представлена временная диаграмма процедурной характеристики, при которой прикладные субмодули, реализую щие функции генератора команд или источника управляющих операций/процедур, запрашивают передачу SNMP/PDU-блока и как возвращается (асинхронно) ответ в эти субмодули.
На рис. 17.12 представлена временная диаграмма процедурной характеристики, при которой прикладные субмодули, реализующие функции приемника команд или приемника управляющих опера ций/процедур, регистрируются для управления определенным ти пом SNMP/ PDU-блоков, как SNMP/ PDU-блок обрабатывается дис петчером в интересах прикладного субмодуля после приема SNMPсообщения, и как передается обратно в сеть ответное сообщение.
Обработка PDU-блоков. Подавляющее большинство всех ба зовых программных SNMPv3-6noKOB, выступающих в роли SNMPv3агента, должно быть способно формировать следующие типы PDUблоков: «Response-PDU» и «SNMPv3-Trap-PDU». Кроме этого, они должны быть способны принимать следующие типы PDU-блоков: «GetRequest-PDU», «GetNextRequest-PDU», «GetBulkRequest-PDU» и «SetRequest-PDU».
258 |
Глава 17. Протокол сетевого управления SNMP третьей версии |
||
Генератор |
Диспетчер |
М о д у л ь |
Модуль |
об р аб о тки |
|||
команд |
со о б щ ен и й |
безопасности |
|
Рис. 17.12. Временная диаграмма приёма SNMP-сообщения
с запросом и ответа на этот запрос
Подавляющее большинство всех базовых программных SN M PV3-6HOKOB, выступающих в роли БЫМРуЗ-менеджера, должно быть способно формировать следующие типы PDU-блоков: «GetRe- quest-PDU», «GetNextRequest-PDU», «GetBulkRequest-PDU», «Infor- mRequest-PDU», «SetRequest-PDU» и «Response-PDU». Кроме этого, они
раздел II. |
259 |
должны быть способны принимать следующие типы PDU-блоков: «Re- sponse-PDU», «SNMPv3-Trap-PDU» и «InformRequest-PDU».
С точки зрения процедурной характеристики SNMPv3-npoTO- кола, любое поле PDU-блока, которое не имеет указателя на соответ ствующую процедуру, будет игнорироваться приёмным базовым БЫМРуЗ-блоком. Тем не менее, все компоненты PDU-блока, вклю чающие такие параметры, которые будут игнорироваться приёмным базовым SNMPv3-6noKOM, должны быть представлены в ASN.l-коде и иметь соответствующий синтаксис.
Например, некоторые PDU-блоки («GetRequest-PDU») связаны только и наименованием (именем) переменного параметра, а не с его значением. В таком случае, некоторые значения параметров из перечня переменных величин будут просто игнорироваться приём ным базовым SNMPv3-6noKOM. Указатель «unspecified» как раз и предназначен для обозначения таких параметров.
При установлении управляющего соединения, PDU-блок фор мируется в соответствии с процедурной характеристикой («Elements of Procedure») из Руководства администратора по управлению сетью. Не смотря на то, что определение «max-bindings» (максимальное количе ство переменных параметров управления) вводит верхнюю предель ную границу количества переменных параметров, на практике же, размер сообщения ограничивается только конструктивными предела ми (сетевыми ограничениями), а не количеством переменных.
На приемной стороне управляющего соединения процедур ная характеристика определяет, что обработка принятого сообще ния основывается на его содержательной части, в которой указыва ются все необходимые параметры для выполнения управляющих операций.
PDU-блок «GetRequest-PDU» формируется прикладным БЫМРуЗ-модулем и транслируется в его запросе. Назначение этого запроса - получение данных о запрашиваемых параметрах управ ления (то есть значений параметров управления).
При получении «GetRequest-PDU», принимающий базовый SNMPV3-6HOK обрабатывает каждый переменный параметр в переч не изменяемых параметров в целях выработки ответного PDU-блока «Response-PDU». Все поля этого PDU-блока «Response-PDU» имеют точно такие же значения, как и в соответствующих полях принятого запроса, за некоторым исключением.
PDU-блок «GetNextRequest-PDU» формируется прикладным ЗЫМРуЗ-модулем и транслируется в его запросе. Назначение этого запроса - получение данных о параметрах управления (то есть зна чений параметров управления), которые следуют лексикографиче ском порядке после названия параметра, указанного в этом запросе.
260 |
Глава 17. Протокол сетевого управления SNMP третьей версии |
|
При получении «GetNextRequest-PDU», принимающий базо |
вый SNMPv3-6noK обрабатывает каждый переменный параметр в перечне изменяемых параметров в целях выработки ответного PDUблока «Response-PDU». Все поля этого PDU-блока «Response-PDU» имеют точно такие же значения, как и в соответствующих полях принятого запроса, за некоторым исключением.
Основным предназначением запроса «GetNextRequest-PDU» является реализация функции последовательного просмотра таб лиц данных в рамках MIB-модулей. Семантика этого типа запросов, а также метод идентификации конкретных элементов в MIBобъектах обеспечивают доступ к взаимосвязанным М1В-объектам, как если бы они были представлены в табличной форме.
На рис. 17.13 представлена процедура информационного об мена (ПИнО) с использованием запроса «GetNextRequest-PDU». В рассматриваемом примере (рис. 17.13) прикладной SNMPv3модуль осуществляет поиск физического адреса (в зависимости от среды передачи) и типа отображения адреса каждого объекта с по мощью таблицы преобразования IP-адресов в физические адреса в интересах соответствующего сетевого объекта управления. Кроме этого, SNMPvB-модуль определяет значение текущего системного времени, в течение которого осуществляется отображение адресов.
Положим, что SNMPv3-areHT для решения указанной выше цели содержит следующую таблицу, включающую три записи:
In te rfa c e -N u m b e r |
N e tw o rk -A d dress |
P h ysic al-A d dress |
T yp e |
|
(н о м е р и н те р ф е й с а ) |
(с етев о й (IP ) а д р е с ) |
(ф и зи чески й а д р е с ) |
(тип отображ ения) |
|
1 |
10.0.0.51 |
00:00:10:01:23:45 |
static |
|
1 |
9.2.3 |
.4 |
00:00:10:54:32:10 |
dynamic |
2 |
10.0.0 |
.15 |
00:00:10:98:76:54 |
dynamic |
Базовый SNMPv3-6noK, выступающий в роли SNMPv3-MeHeA- жера, начинает передавать запрос «GetNextRequest-PDU», содержащий параметры, которые обозначены своими идентификаторами «OBJECT IDENTIFIER», как имена запрашиваемых переменных:
G e tN e x tR e q u e s t |
( s y s lIp T im e , |
|
ip N e tT o M e d iaP h y sA d d re ss, |
|
ip N e tT o M e d ia T y p e ). |
Базовый SN M Pv3-6noK, выступающий в роли SNMPv3-areHTa,
направляет ответ «Response-PDU»:
R e s p o n s e (( sysU pTim e .O = " 1 2 3 4 5 6 " ),
( ip N e tT o M e d ia P h y s A d d re s s .1 .9 .2 .3 .4 = " 0 0 0 0 1 0 5 4 3 2 1 0 " ), ( ip N e tT o M e d ia T y p e 1 .9 .2 .3 .4 = "d y n a m ic ")).
раздел II. |
261 |
Базовый SNMPv3-6noK, выступающий в роли БЫМРуЗ-менеджера, Продолжает передачу:
G e tN e x tR e q u e s t |
( sys U p T im e, |
|
ip N e tT o M e d ia P h y s A d d re s s .1 .9 .2 .3 .4 , |
|
ip N e tT o M e d ia T y p e 1 .9 .2 .3 .4 ) |
|
Инициатор соединения |
! INTERNET |
Отвечающая сторона |
|
|
(ЗЫМРуЗ-менеджер)_______ |
(SNMPv3-areHT) |
|
|
, |
Содержание PDU-блока |
|
Содержание PDU-блока |
Раунд |
|
"GetNextRequest-PDU‘' |
|
’‘Response-PDU'' |
|
|
|
|
||
|
sysUpTime, |
|
|
|
<0 |
ipNetToMediaPhysAddress, |
|
|
|
|
ipNetToMediaType |
|
|
|
|
|
(sysUpTime 0 = "123456") |
|
|
|
|
(ipNetToMediaPhysAddress 1 9 2 3 4 |
|
|
|
|
= "000010543210‘T |
|
|
|
|
(ipNetToMediaType 1 9.2 3 4 |
|
|
|
|
= |
"dynamic") |
|
|
sysUpTime, |
|
|
|
|
ipNetToMediaPhysAdress.1.9.2 3.4, |
|
|
|
|
ipNetToMediaType 1 9.2 3 4 |
|
|
|
|
|
(sysUpTime.O = "123461"). |
|
|
|
|
(ipNetToMediaPhysAddress.1 10 0 0 51 |
|
|
|
|
= "000010012345"), |
|
|
|
|
(ipNetToMediaType 1 10.0 0 51 |
|
|
|
|
= |
"static”) |
|
|
sysUpTime, |
|
|
|
|
ipNetToMediaPhysAddress 1 10 0 0 51, |
|
|
|
|
ipNetToMediaType 1 10 0 0 51 |
|
|
|
|
|
(sysUpTime 0 = "123466"), |
|
|
|
|
(ipNetToMediaPhysAddress 2 10 0 0 15 |
|
|
|
|
= "000010987654"), |
|
|
|
|
(ipNetToMediaType 210 0 0 15 |
|
|
|
|
= |
"dynamic") |
|
|
sysUpTime, |
|
|
|
|
ipNetToMediaPhysAddress 2 10 0 015, |
|
|
|
|
ipNetToMediaType 210 0 015 |
|
|
|
|
|
(sysUpTime 0 = "123471"), |
|
|
|
|
(ipNetToMediaNetAddress 1 9 2 3 4 |
|
|
|
|
: "9 2 3 4" ), |
|
|
|
|
(ipRoutingDiscards 0 = "2') |
|
|
Puc. 17.13. ПИнО с использованием запроса «GetNextRequest-PDU»
Базовый SNMPv3-6noK, выступающий в роли SNMPv3-areHTa, отвечает:
R esponse (( sysU pTim e.O = " 1 2 3 4 6 1 " ),
( ip N e tT o M e d ia P h y s A d d re s s .1 .1 0 .0 .0 .5 1 = " 0 0 0 0 1 0 0 1 2 3 4 5 " ), ( ip N e tT o M e d ia T y p e .1 .1 0 .0 .0 .5 1 = "sta tic "))
Базовый SNMPv3-6noK, выступающий в роли SNMPv3менеджера, продолжает передачу:
G etN e x tR e q u e s t |
( sys U p T im e, |
|
ip N e tT o M ed iaP h ysA d d ress .1 1 0 .0 .0 .5 1 , |
|
ip N e tT o M e d ia T y p e .1 .1 0 .0 .0 .5 1 ). |