Контрольная работа: Мониторинг и анализ локальных сетей
Система безопасности отвечает за шифрование и аутентификацию. Все исходящие сообщения перед отправкой сначала передаются из системы обработки сообщений в систему безопасности, где все шифруются поля в заголовке сообщения, блок данных (PDU), генерируется код аутентификации и добавляется к заголовку сообщения.
После этого сообщение передается обратно в систему обработки сообщений. Точно такая же операция, но в обратном порядке производится для всех входящих сообщений.
Система контроля доступа управляет службами аутентификации для контроля доступа к MIB исходя из содержимого блоков данных. (PDU). Теоретически, система контроля доступа может работать с самыми разными моделями контроля доступа, но на данный момент в RFC 2275 описана только одна модель – VACM (View-BasedAccessControlModel)
Таблица 2 - Основные методы SNMP
| Метод | Для чего применяется | Поддерживается |
| GET | Используется менеджером для получения данных из MIB. Размер сообщения ограничен возможностями агента. | SNMPv1-3 |
| GET-NEXT | Метод позволяет последовательно выполнить набор команд иполучить набор значений из MIB | SNMPv1-3 |
| GET-BULK | Используется менеджером для получения сразу большого количества данных из MIB. Размер сообщения отсылаемого агентом не ограничен. | SNMPv2, SNMPv3 |
| SET | Используется менеджером для установки значений в MIB агента | SNMPv1-3 |
| GET-RESPONSE | SNMPv1-3 | |
| TRAP | Используется агентом чтобы послать сигнал менеджеру | SNMPv1-3 |
| NOTIFICATION | SNMPv2, SNMPv3 | |
| INFORM | Используется менеджером для отсылки сигнала другому менеджеру | SNMPv2, SNMPv3 |
| REPORT | SNMPv2, SNMPv3 |
При помощи этих команд и стандартной базы MIB можно получить самую разнообразную информацию.
Например: количество принятых и отправленных пакетов по TCP, IP, UDP или ICMP. А еще можно узнать о количестве ошибок, которые были обнаружены во времяотправки или получения пакетов.
При разработке SNMPv3 немало внимания было уделено безопасности протокола. Теперь стала поддерживаться модель, ориентированная на пользователя (User-BasedSecurityModel сокр. USM<* см. RFC 3414> ) благодаря которой стало возможным добавление модулей аутентификации и шифрованиябез смены базовой архитектуры.
3.2 Безопасность в SNMPv 3
Модель USM включает в себя модуль аутентификации, модуль шифрования и модуль контроля времени. При этом, модуль аутентификации и шифрования занимаются защитой данных, а модуль контроля времени синхронизирует время между сущностями SNMP.
Основные проблемы, которые необходимо было решить при помощи модели USM:
Изменение данных сущностями не прошедшими аутентификацию;
1. Возможность откладывания каких-либо действий на неопределенное время или повторение одних и тех же действий с произвольными интервалами;
2. Возможность заблокировать обмен данными между сущностями;
3. Возможность перехвата трафика при передаче между сущностями;
4. Возможность «маскарада», т.е. сущность не прошедшая аутентификацию, могла прикинуться сущностью прошедшей аутентификацию.
Проблему решили следующим образом: для каждого сетевого устройства пароль преобразуется в некоторый уникальный ключ. Это обеспечивает дополнительную безопасность т.к. даже в том случае, если ключ будет перехвачен, злоумышленник получит доступ только к одному сетевому устройству. Для шифрования пароля используется алгоритм MD5, но разработчики видимо решили, что это не обеспечит достаточной сохранности пароля и поэтому блок PDU дважды хэшируется при помощи двух разных ключей, которые в свою очередь генерируются из закрытого ключа. Позже, первые 12 октетов используются как код аутентификации сообщения, который добавляется к сообщению. Такой же процесс приходится производить на другой стороне, но только в обратном порядке. Несмотря на всю сложность и энергоемкость процесса передачи данных между сущностями SNMP, по мнению разработчиков, алгоритм шифрования (DES) на самом деле не обеспечивает достаточной защиты информации, поэтому в дальнейшем предполагается использовать другие алгоритмы. Например, алгоритм Диффи-Хиллмана (Diffie-Hillman)
Разработчиками предусмотрено 3 уровня безопасности:
1. noAuthNoPriv – пароли передаются в открытом виде, конфиденциальность данных отсутствует.
2. authNoPriv – аутентификация без конфиденциальности. Большинство пользователейиспользует именно этот уровень т.к уровень защищенности в нем уже достаточно высок, а сетевые устройства не перегружаются шифрованием данных.
3. authPriv – аутентификация и шифрование. Максимальный уровень защищенности.
Как правило, покупатели сначала выбирают второй уровень безопасности и лишь немногие из них, потом начинают использовать третий. Одной из причин, по которой не используется третий уровень, является то, что он перегружает сетевые устройства.
На данный момент закончена разработка новой спецификации DataOverCableServiceInterfaceSpecification<см. стандарт RFC 3256> , а для управления ключами многие пользователи уже используют алгоритмы Диффи-Хиллмана (Diffie-Hillman) и Kerberosвместо DES.Скорее всего, это означает, что скоро можно будет ожидать выход новой версии протокола SNMP.
Интернет - гигантская сеть. Напрашивается вопрос, как она сохраняет свою целостность и функциональность без единого управления? Если же учесть разнородность ЭВМ, маршрутизаторов и программного обеспечения, используемых в сети, само существование Интернет представится просто чудом. Так как же решаются проблемы управления в Интернет? Отчасти на этот вопрос уже дан ответ - сеть сохраняет работоспособность за счет жесткой протокольной регламентации. "Запас прочности" заложен в самих протоколах. Функции диагностики возложены, как было сказано выше, на протокол ICMP. Учитывая важность функции управления, для этих целей создано два протокола SNMP (Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089, std-15 разработан в 1988 году) и CMOT (Common Management Information services and protocol over TCP/IP, RFC-1095, в последнее время применение этого протокола ограничено). Обычно управляющая прикладная программа воздействует на сеть по цепочке SNMP-UDP-IP-Ethernet. Наиболее важным объектом управления обычно является внешний порт сети (gateway) или маршрутизатор сети. Каждому управляемому объекту присваивается уникальный идентификатор.
Протокол SNMP работает на базе транспортных возможностей UDP (возможны реализации и на основе ТСР) и предназначен для использования сетевыми управляющими станциями. Он позволяет управляющим станциям собирать информацию о положении в сети Интернет. Протокол определяет формат данных, а их обработка и интерпретация остаются на усмотрение управляющих станций или менеджера сети. SNMP-сообщения не имеют фиксированного формата и фиксированных полей. При своей работе SNMP использует управляющую базу данных (MIB - management information base, RFC-1213, -1212, std-17 ).
Алгоритмы управления в Интернет обычно описывают в нотации ASN.1 (Abstract Syntax Notation). Все объекты в Интернет разделены на 10 групп и описаны в MIB: система, интерфейсы, обмены, трансляция адресов, IP, ICMP, TCP, UDP, EGP, SNMP. В группу "система" входит название и версия оборудования, операционной системы, сетевого программного обеспечения и пр.. В группу "интерфейсы" входит число поддерживаемых интерфейсов, тип интерфейса, работающего под IP (Ethernet, LAPB etc.), размер дейтограмм, скорость обмена, адрес интерфейса. IP-группа включает в себя время жизни дейтограмм, информация о фрагментации, маски субсетей и т.д. В TCP-группу входит алгоритм повторной пересылки, максимальное число повторных пересылок и пр.. Ниже приведена таблица (3) команд (pdu - protocol data unit) SNMP:
Таблица 3 - Команды SNMP
| Команда SNMP | Тип PDU | Назначение |
| GET-request | 0 | Получить значение указанной переменной или информацию о состоянии сетевого элемента; |
| GET_next_request | 1 | Получить значение переменной, не зная точного ее имени (следующий логический идентификатор на дереве MIB); |
| SET-request | 2 | Присвоить переменной соответствующее значение. Используется для описания действия, которое должно быть выполнено; |
| GET response | 3 | Отклик на GET-request, GET_next_request и SET-request. Содержит также информацию о состоянии (коды ошибок и другие данные); |
| TRAP | 4 | Отклик сетевого объекта на событие или на изменение состояния. |
| GetBulkRequest | 5 | Запрос пересылки больших объемов данных, например, таблиц. |
| InformRequest | 6 | Менеджер обращает внимание партнера на определенную информацию в MIB. |
| SNMPv3-Trap | 7 | Отклик на событие (расширение по отношению v1 и v2). |
| Report | 8 | Отчет (функция пока не задана). |
Рис. 2 - Схема запросов/откликов SNMP
Формат SNMP-сообщений, вкладываемых в UDP-дейтограммы, имеет вид (рис. 4.4.13.2):