Snmp курсовая работа

Протокол управления сетями SNMP

Курсовая
работа

Протокол
управления сетями SNMP

Выполнил

Студент гр. 10 -БАС

Бобрихин З.А.

Брянск
2014 г.

СОДЕРЖАНИЕ

ВВЕДЕНИЕ

.Теоретические
основы протокола SNMP

.1 История развития
протокола SNMP

.2 Основы SNMP
управления

.3 Структура
управляющей информации

.4 Защита в SNMP

. База управляющей
информации (MIB)

.1 Структура SNMP
MIВ

.2 Форматы и имена
объектов SNMP MIB

.3 Недостатки
протокола SNMP

Заключение

Список используемой
литературы

ВВЕДЕНИЕ

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

Основными проблемами,
связанными с увеличением сетей, являются каждодневное управление работой сети и
стратегическое планирование роста сети. Характерным является то, что каждая
новая технология сети требует свою собственную группу экспертов для ее работы и
поддержки. В начале 1980гг. стратегическое планирование роста этих сетей
превратилось в какой-то кошмар. Одни только требования к числу персонала для управления
крупными гетерогенными сетями привели многие организации на грань кризиса.
Насущной необходимостью стало автоматизированное управление сетями (включая то,
что обычно называется «планированием возможностей сети»),
интегрированное по всем различным окружениям.(англ. Simple Network Management
Protocol — простой протокол сетевого управления) — стандартный
интернет-протокол для управления устройствами в IP-сетях на основе архитектур
UDP/TCP. К поддерживающим SNMP устройствам относятся маршрутизаторы, коммутаторы,
серверы, рабочие станции, принтеры, модемные стойки и другие. Протокол обычно
используется в системах сетевого управления для контроля, подключенных к сети
устройств на предмет условий, которые требуют внимания администратора. SNMP
определен Инженерным советом интернета (IETF) как компонент TCP/IP. Он состоит
из набора стандартов для сетевого управления, включая протокол прикладного
уровня, схему баз данных и набор объектов данных.это простой протокол,
основанный на запросах и откликах, предназначенный для обмена между SNMP
менеджером и SNMP агентом. Информационная база данных управления (MIB)
определяет переменные, которые обслуживаются агентом, которые, в свою очередь,
менеджер может либо запросить, либо установить. Для определения переменных используется
ограниченное количество типов данных.

Все переменные идентифицируются
идентификаторами объекта, используется иерархическая схема присвоения имен,
которая состоит из длинных строк чисел, которые обычно сокращаются в простые
имена, для простоты чтения. Конкретные переменные строятся с помощью добавления
переменной к идентификатору объекта.

Большинство SNMP переменных
содержится в таблицах, с фиксированными номерами колонок, однако с переменными
номерами строк. Фундаментальным для SNMP является схема идентификации,
используемая для того, чтобы идентифицировать каждую строку в таблице (в том
случае, когда мы не знаем, сколько строк содержится в таблице), и
лексикографический порядок (порядок колонка-строка). SNMP оператор get-next
является основным для любого SNMP менеджера.

1.Теоретические основы
протокола SNMP

.1 История развития
протокола SNMP

В создание протокола SNMP
внесли свой вклад разработки по трем направлениям:

1.      High-level
Entity Management System (HEMS)

Система управления объектами высшего
уровня. Определяет систему управления с рядом интересных технических
характеристик. К сожалению, HEMS использовалась только в местах ее разработки,
что в конечном итоге привело к прекращению ее действия.

2.      Simple
Gateway Monitoring Protocol (SGMP)

Протокол управления простым
роутером. Разработка была начата группой сетевых инженеров для решения проблем,
связанных с управлением быстрорастущей Internet; результатом их усилий стал
протокол, предназначенный для управления роутерами Internet. SGMP был реализован
во многих региональных ветвях Internet.

.        CMIP over TCP
(CMOT)над ТСР. Пропагандирует сетевое управление, базирующееся на OSI, в
частности, применение Common Management Information Protocol (CMIP) (Протокол
информации общего управления) для облегчения управления объединенных сетей,
базирующихся на ТСР [3].

Достоинства и недостатки этих
трех методов (HEMS, SGMP и CMOT) часто и горячо обсуждались в течение второй
половины 1987 г. К началу 1988 года стало ясно, что необходим некоторый общий
набор средств управления сетевыми устройствами различных производителей,
которые до сих пор создавали собственные продукты мониторинга и
конфигурирования для своих же сетевых устройств, поддерживающие уникальные
механизмы взаимодействия с ними.

После многих заседаний IAB
(Internet Architecture Board, Группа, ответственная за техническую разработку
протоколов Интернет) опубликовал в апреле 1988 года эпохальный RFC 1052: IAB
Recommendations for the Development of Internet Network Management Standards, в
котором призвал к скорейшему созданию элементов Простого Сетевого Управления
(Simple Network Management). Были организованы две рабочие группы.

Одна группа стала заниматься
спецификацией и разработкой элементов Информационной Базы Управления — MIB
(Management Information Base). В дальнейшем работа по этому направлению
вылилась в создание Структуры Управления Объектами — SMI (Structure for
Management Information).

Другая группа, занимавшаяся
развитием протокола управления, пришла к соглашению, что временным решением
проблемы управления может стать улучшенная версия SGMP, которая позже была
названа SNMP. Для долгосрочного применения, после глубоких и обстоятельных
доработок, должна была использоваться одна из технологий, базирующихся на OSI
(либо CMOT, либо сам CMIP) [6].

Кроме того, было решено во всех
системах управления сетями использовать спецификацию ASN.1 (Abstract Syntax
Notation One, Спецификация синтаксиса номер один), которая является чем-то
вроде универсального языка (наподобие эсперанто) для представления форматов
структур управления. Эта спецификация в настоящее время используется для
описания структур и элементов MIB.

В августе 1988 появились три
основополагающих документа:

—       RFC
1065: Structure and Identification of Management Information for TCP/IP-based
internets.

—       RFC
1066: Management Information Base for Network Management of TCP/IP-based
internets.

—       RFC
1067: A Simple Network Management Protocol.

Впоследствии эти документы были
переизданы и дополнены до определения следующего поколения SNMP: RFC 1155, 1156
и 1157, которые в свою очередь, также подверглись переработкам.

В конце концов, в мае 1991 года
была закончена работа по созданию первой версии протокола SNMP, которая нашла
свое отражение в своде следующих документов:

1. RFC 1155: (SIM)
Structure and Identification of Management Information for TCP/IP-based
internets (Май, 1990)

— Определяет структуру
управляющей информации в виде глобального дерева.

Представляет синтаксис
определения имен переменных управления.

2. RFC 1212: (MIB)
Concise MIB (Management Information Base) Definitions (Март,
1991)

— Дополняет RFC 1155 в части
синтаксиса определения имен переменных.

3. RFC 1213:
(MIB-II) Management Information Base for Network Management of TCP/IP-based
internets: MIB-II (Март,
1991)

— Содержит список более ста
наиболее необходимых переменных, отвечающих за конфигурацию, статус и
статистику систем, входящих в TCP/IP сеть.

4. RFC 1157: (SNMP)
A Simple Network Management Protocol (Май,
1990)

— Определяет сообщения, которыми
обмениваются управляющая станция и объект управления для получения и обновления
значения переменных.

Определяет
trap(alarm)-сообщения, посылаемые системой при значительных изменениях в ее
конфигурации [3].

Сегодня SNMP является самым
популярным протоколом управления различными коммерческими, университетскими и
исследовательскими объединенными сетями. Деятельность по стандартизации,
связанная с SNMP, продолжается по мере того, как поставщики разрабатывают и
выпускают современные прикладные программы управления, базирующиеся на SNMP.
SNMP относительно простой протокол, однако набор его характеристик является
достаточно мощным для решения трудных проблем, возникающих при управлении
гетерогенных сетей [4].

1.2 Основы SNMP
управления

определяет всего пять типов
сообщений, которыми обмениваются менеджер и клиент.

Получить значение одной или
нескольких переменных: оператор get-request. Получить следующую переменную
после этой или несколько указанных переменных: оператор get-next-request. (Мы
опишем то, что имеем в виду под словом «следующий» позже в этой
главе.) Установить значение одной или нескольких переменных: оператор
set-request. Выдать значение одной или нескольких переменных: оператор
get-response. Это сообщение возвращается агентом менеджеру в ответ на операторы
get-request, get-next-request и set-request. Уведомить менеджера, когда
что-либо произошло с агентом: оператор trap.

Первые три сообщения
отправляются от менеджера к агенту, а последние два от агента к менеджеру. (Мы
будем называть первые три оператора как get, get-next и set.) На рисунке 1
приведены все пять операторов.

Так как четыре из пяти SNMP
сообщений реализуются простой последовательностью запрос-отклик (менеджер
отправляет запрос, а агент возвращает отклик), SNMP используют UDP. Это означает,
что запрос от менеджера может не прибыть к агенту, а отклик от агента может не
прибыть к менеджеру. В этом случае менеджер, возможно, отработает тайм-аут и
осуществит повторную передачу.

Рисунок 1. Пять операторов
SNMP.

Менеджер отправляет эти три
запроса на UDP порт 161. Агент отправляет ловушки (trap) на UDP порт 162. Так
как используются два разных порта, одна система может выступать в роли
менеджера и агента одновременно.

На рисунке 2 показан формат
пяти SNMP сообщений, инкапсулированных в UDP датаграмму.

Рисунок 2. Формат пяти SNMP
сообщений.

Значение поля version равно 0.
Это значение в действительности равно номеру версии минус единица [5].

На рисунке 3 показано значение
для типа блока данных протокола (PDU type). (PDU — это блок данных протокола —
Protocol Data Unit, обычно называемый «пакет».)

PDU type	Имя
0	get-request
1
2	set-request
3	get-response
4	trap

Рисунок 3. Типы PDU сообщений
SNMP.

Сообщество (community) это
строка символов, в которой содержится пароль в открытом виде. Пароль
используется при общении между менеджером и агентом. Обычное значение —
6-символьная строка public.

В операторах get, get-next и
set менеджер устанавливает идентификатор запроса (request ID), который
возвращается агентом в сообщении get-response. Мы видели этот тип переменной в
других UDP приложениях. Это позволяет клиенту (менеджеру в данном случае)
сопоставить отклики от сервера (агент) с запросами, которые были отправлены
клиентом. Это поле также позволяет менеджеру выдать несколько запросов одному
или нескольким агентам, а затем отсортировать полученные отклики [1].

Статус ошибки (error status)
это целое число, которое возвращается агентам и указывает на ошибку. На рисунке
4 показаны значения, имена и описания ошибок.

статус ошибки	Имя	Описание
0	noError	все в порядке
1	tooBig	клиент не может поместить отклик в одно SNMP сообщение
2	noSuchName	оператор указывает на несуществующую переменную
3	badValue	в операции установки использовано недопустимое значение или сделана ошибка в синтаксисе
4	readOnly	менеджер попытался изменить переменную, которая помечена как «только для чтения»
5	genErr	неопознанная ошибка

Рисунок 4. Значения статуса
ошибки SNMP.

Если возникла ошибка, индекс
ошибки (error index) это целое смещение, указывающее на то, в какой переменной
произошла ошибка. Это значение устанавливается агентом только для ошибок
noSuchName (нет такого имени), badValue (неверное значение) и readOnly (только
для чтения).

Список имен переменных и
значений следует в get, get-next и set запросах. Раздел значений игнорируется в
операторах get и get-next.

Для оператора trap (PDU type
равен 4) формат SNMP сообщения изменяется.

1.3 Структура
управляющей информации

использует небольшое количество
различных типов данных. В этой главе мы рассмотрим эти типы, однако не будем
рассматривать то, как эти данные в действительности кодируются (для хранения
данных используются битовые шаблоны) [4].(целое число). Некоторые переменные
объявляются как целые без ограничений (например, MTU для интерфейса), некоторые
определены с конкретными значениями (например, флаг IP о перенаправлении
установлен в 1, если перенаправление включено, или в 2, если перенаправление
выключено), а другие определены с их минимальными и максимальными значениями
(например, номера портов TCP и UDP находятся в диапазоне от 0 до 65535).STRING
(восьмеричная строка). Строка из 0 или нескольких 8-битных байт. Каждый байт
имеет значение от 0 до 255. В кодировании BER, используемом для этих типов
данных и для следующего, счетчик количества байт в строке находится перед самой
строкой. Эти строки не заканчиваются нулевыми значениями.

DisplayString. Строка из 0 или
нескольких 8-битных байт, причем каждый байт должен быть символом из набора
ASCII NVT (глава 26, раздел «Протокол Telnet»
<#»723612.files/image004.gif»>

Рисунок 5. Таблица listener UDP
(udpTable), которая представлена как двумерный массив SNMP.

1.4 Защита в SNMP

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

В SNMPv1 простейшая
идентификация отправителя осуществляется посредством включения в сообщения
имени группы (community name), причем имя передается открытым текстом. После
проверки имени группы агент или менеджер проверяет наличие у отправителя с
данным адресом прав на выполнение запрошенной операции. Таким образом, проверка
прав осуществляется на основании имени группы и адреса отправителя [6].

В SNMPv2 сделана попытка
укрепить защиту SNMP за счет использования современных криптографических
методов, в частности DES. Однако это еще более усложнило протокол. Кроме того,
в такой реализации SNMPv2 оказался обратно несовместим с SNMPv1.

2. База управляющей информации
(MIB)

.1 Структура SNMP MIВ

На сегодня существует несколько
стандартов на базы данных управляющей информации для протокола SNMP. Основными
являются стандарты MIB-I и MIB-II, а также версия базы данных для удаленного
управления RMON MIB. Кроме этого существуют стандарты для специальных устройств
MIB конкретного типа (например, MIB для концентраторов или MIB для модемов), а
также частные MIB конкретных фирм-производителей оборудования.

Первоначальная спецификация
MIB-I определяла только операции чтения значений переменных. Операции изменения
или установки значений объекта являются частью спецификаций MIB-II [1].

Версия MIB-I (RFC 1156)
определяет 114 объектов, которые подразделяются на 8 групп.

—       System — общие
данные об устройстве (например, идентификатор поставщика, время последней
инициализации системы).

—       Interfaces —
параметры сетевых интерфейсов устройства (например, их количество, типы,
скорости обмена, максимальный размер пакета).

—       Address Translation
Table — описание соответствия между сетевыми и физическими адресами (например,
по протоколу ARP).

—       Internet Protocol —
данные, относящиеся к протоколу IP (адреса IP-шлюзов, хостов, статистика о
IP-пакетах).

—       ICMP — данные,
относящиеся к протоколу обмена управляющими сообщениями ICMP.

—       TCP — данные,
относящиеся к протоколу TCP.

—       UDP — данные,
относящиеся к протоколу UDP (число переданных, принятых и ошибочных
UPD-дейтаграмм).

—       EGP — данные,
относящиеся к протоколу обмена маршрутной информацией Exterior Gateway
Protocol, используемому в Internet (число принятых с ошибками и без ошибок
сообщений).

Из этого перечня групп
переменных видно, что стандарт MIB-I разрабатывался с жесткой ориентацией на
управление маршрутизаторами, поддерживающими протоколы стека TCP/IP.

В версии MIB-II (RFC 1213),
принятой в 1992 году, был существенно (до 185) расширен набор стандартных
объектов, а число групп увеличилось до 10 [2].

На рис. 6 приведен пример
древовидной структуры базы объектов MIB-II. На нем показаны две из 10 возможных
групп объектов — System (имена объектов начинаются с префикса Sys) иInterfaces
(префикс if). Объект SysUpTime содержит значение продолжительности времени
работы системы с момента последней перезагрузки, объект SysObjectID —
идентификатор устройства (например, маршрутизатора).

Рис. 6. Стандартное дерево
MIB-II (фрагмент)

Объект ifNumber определяет
количество сетевых интерфейсов устройства, а объект ifEntry является вершиной
поддерева, описывающего один из конкретных интерфейсов устройства. Входящие в
это поддерево объекты ifType и ifAdminStatus определяют соответственно тип и
состояние одного из интерфейсов, в данном случае интерфейса Ethernet.

В число объектов, описывающих
каждый конкретный интерфейс устройства, включены следующие [3]:

—       ifType- Тип
протокола, который поддерживает интерфейс. Этот объект принимает значения всех
стандартных протоколов канального уровня, например rfc877-x25, ethernet-csmacd,
iso88023-csmacd, iso88024-tokenBus, iso88025-tokenRing и т. д.

—       ifMtu- Максимальный
размер пакета сетевого уровня, который можно послать через этот интерфейс.

—       ifSpeed- Пропускная
способность интерфейса в битах в секунду (100 для Fast Ethernet).

—       ifPhysAddress-
Физический адрес порта, для Fast Ethernet им будет МАС-адрес.

—       ifAdminStatus

Желаемый статус порта:- готов
передавать пакеты;- не готов передавать пакеты;- находится в тестовом режиме.

—       ifOperStatus-
Фактический текущий статус порта, имеет те же значения, что и ifAdminStatus.

—       ifInOctets- Общее
количество байт, принятое данным портом, включая служебные, с момента последней
инициализации SNMP-агента.

—       ifInUcastPkts-
Количество пакетов с индивидуальным адресом интерфейса, доставленных протоколу
верхнего уровня.

—       ifInNUcastPkts-
Количество пакетов с широковещательным или мультивещательным адресом
интерфейса, доставленных протоколу верхнего уровня.

—       ifInDiscards-
Количество пакетов, которые были приняты интерфейсом, оказались корректными, но
не были доставлены протоколу верхнего уровня, скорее всего из-за переполнения
буфера пакетов или же по иной причине.

Кроме объектов, описывающих
статистику по входным пакетам, имеются аналогичные объекты, но относящиеся к
выходным пакетам. Как видно из описания объектов MIB-II, эта база данных не
дает детальной статистики по характерным ошибкам кадров Ethernet, кроме этого,
она не отражает изменение характеристик во времени, что часто интересует
сетевого администратора [5].

Эти ограничения были
впоследствии сняты новым стандартом на MIB — RMON MIB, который специально
ориентирован на сбор детальной статистики по протоколу Ethernet, к тому же с
поддержкой такой важной функции, как построение агентом зависимостей
статистических характеристик от времени.

2.2 Форматы и имена
объектов SNMP MIB

Для именования переменных базы
MIB и однозначного определения их форматов используется дополнительная
спецификация, называемая SMI — Structure of Management Information. Например,
спецификация SMI включает в качестве стандартного имя IpAddress и определяет
его формат как строку из 4 байт. Другой пример — имя Counter, для которого
определен формат в виде целого числа в диапазоне от 0 до 232-1.

При описании переменных MIB и
форматов протокола SNMP спецификация SMI опирается на формальный язык ASN.1,
принятый ISO в качестве нотации для описания терминов коммуникационных
протоколов (правда, многие коммуникационные протоколы, например IP, PPP или
Ethernet, обходятся без этой нотации). Нотация ASN.1 служит для установления
однозначного соответствия между терминами, взятыми из стандартов,
предназначенных для человеческого использования, и теми данными, которые
передаются в коммуникационных протоколах аппаратурой. Достигаемая однозначность
очень важна для гетерогенной среды, характерной для корпоративных сетей. Так,
вместо того чтобы указать, что некоторая переменная протокола представляет
собой целое число, разработчик протокола, использующий нотацию ASN.1, должен
точно определить формат и допустимый диапазон переменной. В результате
документация на MIB, написанная с помощью нотации ASN.1, может точно и
механически транслироваться в форму кодов, характерных для сообщений протоколов
[3].

Нотация ASN.1 похожа на другие
метаязыки, например нормальную Бэкусову форму, используемую при описании языков
программирования, в частности Алгола. Нотация ASN.1 поддерживает базовый набор
различных типов данных, таких как целое число, строка и т. п., а также
позволяет конструировать из этих базовых типов составные данные — массивы,
перечисления, структуры.

Существуют правила трансляции
структур данных, описанных на ASN.1, в структуры данных языков
программирования, например C++. Соответственно, имеются трансляторы,
выполняющие эту работу. Примеры описаний данных с помощью ASN.1 приведены ниже
при описании протокольных блоков данных SNMP. Нотация ASN.1 широко используется
при описании многих стандартов OSI, в частности моделей управляемых объектов и
структуры сообщений протокола CMIP [1].

Имена переменных MIB могут быть
записаны как в символьном, так и в числовом форматах. Символьный формат
используется для представления переменных в текстовых документах и на экране
дисплея, а числовые имена — в сообщениях протокола SNMP. Например, символьному
имени SysDescr соответствует числовое имя 1, а более точно 1.3.6.1.2.1.1.1.
Составное числовое имя объекта SNMP MIB соответствует полному имени этого
объекта в дереве регистрации объектов стандартизации ISO. Разработчики
протокола SNMP не стали использовать традиционный для стандартов Internet
способ фиксации численных параметров протокола в специальном RFC, называемом
«Assigned Numbers» (там описываются, например, численные значения, которые
может принимать поле Protocol пакета IP, и т. п.). Вместо этого они
зарегистрировали объекты баз MIB SNMP во всемирном дереве регистрации
стандартов ISO, показанном на рис. 7.

Рис. 7. Пространство имен
объектов ISO

Как и в любых сложных системах,
пространство имен объектов ISO имеет древовидную иерархическую структуру,
причем на рис. 6 показана только его верхняя часть. От корня этого дерева
отходят три ветви соответствующие стандартам, контролируемым ISO, ITU и
совместно ISO-ITU. В свою очередь, организация ISO создала ветвь для
стандартов, создаваемых национальными и международными организациями (ветвь
org). Стандарты Internet создавались под эгидой Министерства обороны США
(Departament of Defence, DoD), поэтому стандарты MIB попали в
поддеревоdod-internet, а далее, естественно, в группу стандартов управления сетью
— ветвь mgmt. Объекты любых стандартов, создаваемых под эгидой ISO, однозначно
идентифицируются составными символьными именами, начинающимися от корня этого
дерева. В сообщениях протоколов символьные имена не используются, а применяются
однозначно соответствующие им составные числовые имена. Каждая ветвь дерева
имен объектов нумеруется в дереве целыми числами слева направо, начиная с
единицы, и эти числа и заменяют символьные имена. Поэтому полное символьное имя
объекта MIB имеет вид: iso.org.dod.internet.mgmt.mib, a полное числовое имя:
1.3.6.1.2.1.

Группа объектов private (4)
зарезервирована за стандартами, создаваемыми частными компаниями, например
Cisco, Hewlett-Packard и т. п. Это же дерево регистрации используется для
именования классов объектов CMIP и TMN [4].

Соответственно, каждая группа
объектов MIB-I и MIB-II также имеет кроме кратких символьных имен, приведенных
выше, полные символьные имена и соответствующие им числовые имена. Например,
краткое символьное имя группы System имеет полную форму iso.org.dod.internet.mgmt.mib.system,
а ее соответствующее числовое имя — 1.3.6.1.2.1. Часть дерева имен ISO,
включающая группы объектов MIB, показана на рис. 8.

Рис. 8. Часть дерева имен ISO,
включающая группы объектов MIB-I

2.3 Недостатки
протокола SNMP

протокол
управляющий информация аутентификация

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

Отсутствие средств взаимной
аутентификации агентов и менеджеров. Единственным средством, которое можно было
бы отнести к средствам аутентификации, является использование в сообщениях так
называемой «строки сообщества» — «community string». Эта строка передается по
сети в открытой форме в сообщении SNMP и служит основой для деления агентов и
менеджеров на «сообщества», так что агент взаимодействует только с теми
менеджерами, которые указывают в поле community string ту же символьную строку,
что и строка, хранящаяся в памяти агента. Это, безусловно, не способ
аутентификации, а способ структурирования агентов и менеджеров. Версия SNMP v.2
должна была ликвидировать этот недостаток, но в результате разногласий между
разработчиками стандарта новые средства аутентификации хотя и появились в этой
версии, но как необязательные [1].

Работа через ненадежный
протокол UDP (а именно так работает подавляющее большинство реализаций агентов
SNMP) приводит к потерям аварийных сообщений (сообщений trap) от агентов к
менеджерам, что может привести к некачественному управлению. Исправление
ситуации путем перехода на надежный транспортный протокол с установлением
соединений чревато потерей связи с огромным количеством встроенных агентов
SNMP, имеющихся в установленном в сетях оборудовании. (Протокол CMIP изначально
работает поверх надежного транспорта стека OSI и этим недостатком не страдает.)
Разработчики платформ управления стараются преодолеть эти недостатки. Например,
в платформе HP OV Telecom DM TMN, являющейся платформой для разработки
многоуровневых систем управления в соответствии со стандартами TMN и ISO,
работает новая реализация SNMP, организующая надежный обмен сообщениями между
агентами и менеджерами за счет самостоятельной организации повторных передач
сообщений SNMP при их потерях [2].

Заключение

Протокол SNMP (Simple Network
Management Protocol) предназначен для облегчения работы администратора по
управлению устройствами сети. Однако огромной проблемой протокола SNMP версии 1
(SNMPvl) всегда была абсолютная незащищенность узла, на котором работали средства
поддержки этого протокола. В исходной версии использовался только один механизм
обеспечения безопасности, основанный на использовании специальных паролей,
называемых строками доступа (community string). В ответ на жалобы о наличии
слабых мест в системе обеспечения безопасности была быстро разработана
значительно улучшенная версия SNMP (SNMFV2). В этой версии для аутентификации
сообщений, передаваемых между серверами и клиентами SNMP, используется алгоритм
хэширования MD5. Это позволяет обеспечить как целостность пересылаемых данных,
так и возможность проверки их подлинности. Кроме того, SNMPv2 допускает
шифрование передаваемых данных. Это ограничивает возможности злоумышленников по
прослушиванию трафика сети и получению строк доступа. Однако в то же время
ничто не мешает администраторам использовать на маршрутизаторах простейшие
пароли.

Третья версия протокола SNMP
(SNMPv3) является текущим стандартом и позволяет достичь необходимого уровня
безопасности устройств, но его принятие, по-видимому, затянется на довольно
длительное время. Достаточно изучить типичную сеть, чтобы убедиться в том, что
большинство устройств работает под управлением даже не SNMPv2, a SNMPvl. Однако
ни одна из версий протокола SNMP не ограничивает возможности использования
администраторами строк доступа, предлагаемых разработчиками. Как правило, для
них устанавливаются легко угадываемые пароли, которые хорошо известны всем, кто
хоть немного интересуется подобными вопросами.

Еще хуже то, что во многих
организациях протокол SNMP практически не учитывается в реализуемой политике
безопасности. Возможно, это происходит из-за того, что протокол SNMP работает
поверх UDP (который, как правило, отсутствует в стеке протоколов), или потому,
что о его возможностях известно лишь немногим администраторам. В любом случае
необходимо констатировать, что вопросы обеспечения безопасности при
использовании протокола SNMP часто ускользают из поля зрения, что нередко дает
возможность взломщикам проникнуть в сеть.

Однако перед тем, как перейти к
подробному рассмотрению изъянов протокола SNMP, давайте кратко познакомимся с
основными понятиями, которые с ним связаны. Строки доступа могут быть одного из
двух типов — позволяющие только чтение (тип read) и позволяющие как чтение, так
и запись (read/write). При использовании строк доступа SNMP, позволяющих только
чтение, можно лишь просматривать сведения о конфигурации устройства, такие как
описание системы, TCP- и UDP-соединения, сетевые адаптеры и т.д. Строки
доступа, предоставляющие права чтения и записи, обеспечивают администратору (и,
конечно, злоумышленнику) возможность записывать информацию в устройство.
Например, с использованием всего одной команды SNMP администратор может
изменить контактную системную информацию, snmpset 10.12.45.2 private
.1.3.6.1.2.1.1 s Smith

Список используемой
литературы

.        Новиков Ю.В., Кондратенко С.В.-
Локальные сети: архитектура, алгоритмы, проектирование. М.: Издательство ЭКОМ,
2012.- 312 с.

.        Олифер В.Г., Олифер Н.А..- Компьютерные
сети и системы. Принципы, технологии, протоколы., СПб.: Питер, 2013.- 672
с.:ил.

.        Шмидт, Дуглас Кевин Дж., Мауро Р. —
Основы SNMP, 2-е издание, Символ-Плюс , 2012.-520 с.

4.      <http://ru.wikipedia.org/wiki/SNMP>

.        <http://www.citforum.ru/nets/lvs/glava_7.shtml>

.        <http://www.citforum.ru/nets/ito/32.shtml>

Федеральное агентство связи

Российской Федерации

Государственное образовательное учреждение

высшего профессионального образования

«СИБИРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

 ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ»

Кафедра БИСС

КУРСОВАЯ  РАБОТА

по дисциплине: «Эксплуатационное и техническое
обслуживание  телекоммуникационных сетей с программным обеспечением»

на тему  «Принципы обмена управляющей информацией по протоколу
SNMP»

Вариант4

Выполнила: студентка группы С –78

Проверил:

                                           
Новосибирск 2011

1. Задание:

Расшифровать
вышеприведенные сообщения управляющего протокола, в соответствии с
поставленными ниже в пп. 1…18 вопросами.

Определить из приведенных
сообщений:

2. Определить из приведенных сообщений:

1.  Фирму-поставщика
оборудования сетевых интерфейсов

2.  MAC-адреса
источника и назначения

3.  Тип
протокола, обслуживаемого данным Ethernet-кадром

4.  Версию
протокола сетевого уровня

5.  Приоритет
сетевого уровня для данной дейтаграммы

6.  Длину
пакета сетевого уровня (в байтах)

7.  Время
жизни данной дейтаграммы

8.  Протокол
транспортного уровня (Dec’код и
название)

9.  Сетевой
адрес отправителя

10. Сетевой адрес
назначения

11. Транспортный порт
отправителя

12. Транспортный порт получателя

13. Тип и версию
протокола прикладного уровня

14. Длину дейтаграммы
транспортного уровня (в байтах)

15. Тип и класс тэга
протокола прикладного уровня

16. Длину сообщения
протокола прикладного уровня

17. Длину и содержимое
поля Community

18. Тип PDU и его
длину (в байтах)

18.1. 
Для PDU типаGet-Request

18.1.1. 
Значение
идентификатора запроса —RequestID

18.1.2. 
Значения
полей ErrorStatusи Errorlndex

18.1.3. 
Длину
поля, содержащего набор запрашиваемых характеристик

18.1.4. 
Перечень
запрашиваемых характеристик (атрибутов) управляемого объекта*

18.2. 
Для PDU типаGetResponse

18.2.1. 
Значение
идентификатора запроса –RequestID

18.2.2. 
Значения
полей ErrorStatusи Errorlndex

18.2.3. 
Длину
поля, содержащего набор характеристик управляемого объекта

18.2.4. 
Перечень
характеристик (атрибутов) управляемого объекта*

18.2.5. 
Значения
характеристик (атрибутов) управляемого объекта*

Примечание: Ответы на
вопросы в пунктах, отмеченных (*), привести в виде отдельной таблицы, как
показано ниже.

Вариант
задания № 04

Расшифровка SNMP-сообщений.

Сообщение №1.

0000: 00 00 aa 90 04 20 00 20   af e8 04 8e 08 0045 80 

0010: 01 1a 0b 25 00 00 30 11   00 09 c0 15 95 cc c3 95 

0020: d3 68c0 7c 00
a1 01 06   4a 51 30 81 fb 02 01 00 

0030: 04 06 61 36 33 2d 30 34   a0 81 ed 02 04 35 97 ac 

0040: 55 02 01 00
02 01 00 30   81 de 30 0c 06 08 2b 06 

0050: 01 02 01 01
03 00 05 00   30 0e 06 0a 2b 06 01 02 

0060: 01 02 02 01
05 01 05 00   30 0e 06 0a 2b 06 01 02 

0070: 01 02 02 01
08 01 05 00   30 0e 06 0a 2b 06 01 02 

0080: 01 02 02 01
09 01 05 00   30 0e 06 0a 2b 06 01 02 

0090: 01 02 02 01
0a 01 05 00   30 0e 06 0a 2b 06 01 02 

00a0: 01 02 02 01
0b 01 05 00   30 0e 06 0a 2b 06 01 02 

00b0: 01 02 02 01
0c 01 05 00   30 0e 06 0a 2b 06 01 02 

00c0: 01 02 02 01
0d 01 05 00   30 0e 06 0a 2b 06 01 02 

00d0: 01 02 02 01
0e 01 05 00   30 0e 06 0a 2b 06 01 02 

00e0: 01 02 02 01
10 01 05 00   30 0e 06 0a 2b 06 01 02

00f0: 01 02 02 01
11 01 05 00   30 0e 06 0a 2b 06 01 02 

0100: 01 02 02 01
12 01 05 00   30 0e 06 0a 2b 06 01 02 

0110: 01 02 02 01
13 01 05 00   30 0e 06 0a 2b 06 01 02 

0120: 01 02 02 01
14 01 05 00     

Расшифровка SNMP-сообщений.

Сообщение №2.

0000: 00
80 c2 e8 04 8e 00 00   93 7c 04 f1 08 0045
40 

0010: 01 37 9c bf 00 00 60 11   70 56 c0 62 95 68 c1 58 

0020: d1 cc00 a1 c0 7a 01 23   7b 84
30 82 01 17 02 01 

0030: 00 04 05 36
33 2d 30
34  
a2 82 01 09 02 04 35 97 

0040: ac 59 02 01 00 02 01 00   30 81 fa
30 0f 06 08 2b 

0050: 06 01 02 01 01 03 00 43   03 73 d4 5c 30 11 06 0a 

0060: 2b 06 01 02 01 02 02 01   05 03 42
03 00 fa 00 30 

0070: 0f 06 0a 2b 06 01 02 01   02 02 01
08 03 02 01 01 

0080: 30 0f 06 0a 2b 06 01 02   01 02 02
01 09 03 43 01 

0090: 00 30 12 06 0a 2b 06 01   02 01 02
02 01 0a 03 41 

00a0: 04 04 12 5a 5d 30 11 06   0a 2b 06
01 02 01 02 02 

00b0: 01 0b 03 41 03 08 6f da   30 0f 06
0a 2b 06 01 02 

00c0: 01 02 02 01 0c 03 41 01   07 30 0f
06 0a 2b 06 01 

00d0: 02 01 02 02 01 0d 03 41   01 00 30
0f 06 0a 2b 06 

00e0: 01 02 01 02 02 01 0e 03   41 01 00
30 12 06 0a 2b 

00f0: 06 01 02 01 02 02 01 10   03 41 04 13 9c e5
1a
30 

0100: 11 06 0a 2b 06 01 02 01   02 02 01 11 03
41 03 08 

0110: 0d 32 30 0f 06 0a 2b 06   01 02 01 02 02
01 12 03 

0120: 41 01 00 30 0f 06 0a 2b   06 01 02 01 02
02 01 13 

0130: 03 41 01 00 30 0f 06 0a   2b 06 01 02 01
02 02 01 

0140: 14 03 41 01 74  

Часть 1

1.