Использование протокола SNMP предполагает отправку запросов и получение откликов, следовательно, управляющая станция должна непрерывно опрашивать сеть для выявления проблем (см. Рисунок 1).

Рисунок 1. Использование протокола SNMP для удаленного опроса сетевых устройств.

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

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

Поскольку коммутаторы не транслируют ошибки, использование SNMP — наилучший метод для выявления портов, на которых эти ошибки происходят. Коммутатор не может передать ошибку дальше, но ему известно о ее появлении. Для коммутаторов, поддерживающих SNMP, существует много различных баз управляющей информации (Management Information Base, MIB). По сути, эти базы представляют собой словари-справочники, где перечислены разрешенные запросы с возможными откликами на них и соответствующим описанием. Каждая поддерживаемая производителем база MIB позволяет консоли управления получить более или менее подробное описание текущего состояния сети поблизости от устройства, за которым ведется наблюдение, включая и его самого.

В отличие от частных MIB, обычно предназначенных для поддержки определенного типа коммутатора и программного кода, стандартные базы MIB (т.е. опирающиеся на документы RFC) позволяют эффективно следить за всей коммутируемой сетью. Для обеспечения диагностики наиболее полезны приведенные ниже базы MIB (хотя существует еще и масса других); они перечислены
в порядке возрастающей детализации данных:

  • RFC 1213 — MIB II;
  • RFC 1643 — Ethernet-Like Interface MIB;
  • RFC 2021 — RMON 2;
  • RFC 2819 — RMON Ethernet.

Материалы RFC могут обновляться и совершенствоваться после их опубликования, поэтому всегда используйте самое последнее обновление согласно индексу RFC. Например, RFC 1213 обновлялся не менее пяти раз (RFC 2011, 2012, 2013, 2358 и 2665). Кроме баз MIB, указанных в документах RFC (где содержится подробнейшая информация об использовании и ошибках), для диагнос-тики очень полезна база MIB по мостам (RFC 1493, 1525 и 2674).

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

Необходимо, как минимум, сразу же изменить пароль, заданный по умолчанию. Агенты SNMP можно настроить таким образом, чтобы разным пользователям предоставлялись разные уровни доступа, они откликались бы на запросы от конкретной подсети и игнорировали запросы от других подсетей, отвечали бы на запросы только с конкретных IP-адресов. Помимо перечисленных, возможны и другие настройки. Маршрутизаторы, через которые пролегает путь к агентам SNMP, способны накладывать на использование SNMP дополнительные ограничения. Брандмауэры (firewall) могут полностью блокировать работу SNMP. Но получения доступа к агенту с помощью SNMP недостаточно — агент должен поддерживать базу MIB, к которой обращен ваш запрос. Большинство производителей реализуют поддержку стандартных баз MIB в нужном объеме, однако некоторые этого не делают. В отдельных случаях необходимо обновить операционную систему коммутатора, чтобы он мог поддерживать желаемую общую или частную базу MIB.

Если коммутатор не отвечает на запрос SNMP, тому может быть масса причин. При наличии соответствующей базы MIB и устранении всех проблем с доступом SNMP становится очень полезным инструментом для мониторинга состояния сети и выявления общих закономерностей ее работы.

Плюсы. Использование систем управления сетью для автоматического мониторинга сетей — отличный способ выявления изменений в трафике в зависимости от времени суток и событий
в сети. С помощью SNMP можно получить любую информацию о вашей сети, если агент поддерживает соответствующую базу MIB.

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

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

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

Минусы. При использовании SNMP появляется множество возможностей, включая запись пакетов в файл, если агент это допускает. Но, к сожалению, эту функциональность поддерживают далеко не все агенты. В таком случае самое большое, что вы можете узнать, — кто с кем общался и по какому протоколу. Если возникнут проблемы с протоколом либо с синхронизацией, без сбора пакетов диагностику провести нельзя. Многие устройства, которые, согласно документации, должны поддерживать дистанционное управление RMON, на самом деле реализуют только четыре из девяти групп. Поддерживаемые подмножества называются по-разно-му — например, облегченная версия
RMON Lite.

Команды SNMP имеют меньший приоритет, чем маршрутизируемый трафик. Если агент занят, то сбор статистики SNMP может быть отложен до тех пор, пока пиковый трафик не сойдет на нет. С точки зрения статистики это эквивалентно отклонению пакетов. Во многих новых маршрутизаторах весь обычный трафик обрабатывают входные интегральные микросхемы ASIC, а центральный процессор маршрутизатора занимается только нетипичными событиями. Использование консоли SNMP для опроса маршрутизатора порой приводит к повышению загруженности центрального процессора с 10% до 100%, причем скачкообразно. Увидев это, сетевые инженеры иногда теряются. Если же к такому устройству будут одновременно обращаться несколько консолей SNMP, то оно может вообще выйти из строя (это зависит от его схемы и настроек).

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

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

НЕОБХОДИМЫЕ ЗНАНИЯ ДЛЯ МОНИТОРИНГА С ПОМОЩЬЮ SNMP

Примеры обнаружения сетевой атаки с помощью SNMP. Системы обнаружения вторжения можно настроить так, чтобы они отслеживали симптомы, наличие которых свидетельствует о том, что кто-то предпринял сетевую атаку (причем как снаружи, так и изнутри). Для отслеживания доступны следующие события:

  • сбои ipReasmFails (1.3.6.1.2.1.4.16) — количество сбоев алгоритма сборки IP. Мониторинг осуществляется на хостах, что позволяет вовремя обнаруживать сетевые атаки или проблемы с доставкой данных по сети;
  • сбои tcpAttemptFails (1.3.6.1.2.1.6.7) — количество случаев, когда соединения TCP из состояний SYN-SENT или SYN-RCVD переходили в состояние CLOSED и когда соединения TCP переводилось из состояния SYN-RCVD в состояние LISTEN. Этот показатель может быть индикатором атаки извне;
  • количество udpNoPorts (1.3.6.1.2.1.7.2) — суммарное число полученных датаграмм UDP, для которых на порту назначения нет соответствующего приложения. Данный счетчик может служить индикатором «прощупывания» вашей сети.

Определение базы MIB, используемой протоколом SNMP. Некоторые базы MIB опираются на документы RFC, другие зависят от производителя и модели оборудования. Если не понимать, что именно вы запрашиваете, то невозможно интерпретировать отклик. Например, на Рисунке 2 сервер получает запросы с использованием трех разных баз MIB. В каждом случае суть запроса одна и та же — степень занятости устройства.

Рисунок 2. Различные запросы о текущем уровне использования.

В первом запросе спрашивается, высок ли уровень загрузки центрального процессора сервера. Загрузка зависит от того, какие приложения выполняются на сервере в данный момент, причем на сетевой активности это никак не сказывается.

  • RFC 2790 [Host Resources]: hrProcessorLoad (1.3.6.1.2.1.25.3.3.1.2). Процент времени, когда процессор был занят — среднее значение за последнюю минуту.

Второй запрос касается объема трафика, прошедшего через сетевую карту на данном сервере. Этот показатель полностью зависит от трафика, адресованного серверу (включая широковещательные рассылки), а загруженность сети может влиять, а может и не влиять на него. Например, сеть загружена на 35%, в то время как сервер принимает только 7% из указанного трафика. Отклик SNMP будет содержать значение 7%. Обратите внимание: запрос не учитывает исходящий трафик, поскольку для него в базе MIB используется другой идентификатор.

  • RFC 1213 [MIB II]: ifInOctets (1.3.6.1.2.1.2.2.1.10). Суммарное количество октетов, полученных через интерфейс, включая обрамляющие символы (framing character).

Третий запрос направлен на выявление занятости сетевого сегмента, к которому подключена сетевая карта сервера. Объект интереса — активность сети, причем трафик может предназначаться и серверу, и другим устройствам. Используя предыдущий пример, можно сказать, что уровень загруженности сети составляет 35%, в то время как сервер принимает только 7% из них. В этом случае отклик SNMP будет содержать значение 35%. Если в сервере установлен стандартный сетевой драйвер NDIS, то, возможно, он «видит» только «хороший» трафик и не распознает ошибок, даже если запрос отправлен в соответствии с базой MIB, которая выдает информацию об ошибках. Большая часть зондов RMON устанавливается на обычный персональный компьютер с типовой сетевой картой под управлением стандартного сетевого драйвера NDIS. В результате они либо вовсе не видят ошибок, либо им доступна только их малая часть.

  • RFC 2819 [RMON]: etherStatsOctets (1.3.6.1.2.1.16.1.1.1.4). Суммарное количество октетов данных (включая те, что находятся в «плохих» пакетах), полученных по сети (за исключением обрамляющих битов, но с учетом октетов контрольной последовательности FCS).

Если не знать точного смысла каждого параметра, то можно сделать неправильные выводы. Это особенно верно в отношении пользовательского интерфейса систем управления сетью, где часто применяется цветовая индикация состояния — красный, желтый, зеленый. Однако цвет не поможет различить типы «занятости». Для правильной интерпретации предупреждений, получаемых от системы, необходимо знать их источники.

Точность баз MIB. Иногда конкретная база MIB реализуется агентом MIB не так, как положено, и выдаются неправильные отклики на запросы. Значительно реже программное обес-печение SNMP Manager некорректно интерпретирует отклик или существует несоответствие между версиями базы MIB в агенте SNMP и в программном обеспечении SNMP Manager. Такие программные ошибки приводят к получению неверных откликов. Отклик может быть верным, но версии на контролируемом устройстве и управляющей станции могут не совпадать. В результате у отклика может быть другое значение. Это можно проиллюстрировать на бытовом примере. Представьте себе, что вы приобрели бывший в употреблении тостер, который можно подключить к компьютерной сети. Вы принесли его домой и загрузили с сайта производителя новейшую базу MIB. Затем положили в тостер первый кусочек хлеба и со станции управления SNMP отправили ему запрос, относительно установленной в нем настройки поджаривания. Тостер выдает отклик «3».

При этом в старой MIB-базе было всего три вариантов отклика: 1=«слегка подрумянить», 2=«хорошо поджарить», 3=«готовить до обугливания». А в новой базе MIB, которая рассчитана на тостеры самых последних моделей, вариантов отклика уже 7, от 1=«слегка подрумянить» до 7=«готовить до обугливания». Из-за несоответствия в базах MIB вы будете ожидать, что прибор сделает хорошо поджаренный тост, а на самом деле получите головешку.

Игорь Панов — региональный менеджер по продукции и поддержке партнеров Fluke Networks в России и СНГ. С ним можно связаться по адресу: igor.panov@flukenetworks.com.