Руководство по портам SNMP: мониторинг сети на портах 161 и 162

SNMP выполняет две основные роли. Менеджер SNMP — это система мониторинга, которая задает вопросы или получает уведомления. Агент SNMP запускается на отслеживаемом устройстве и предоставляет значения через базу управляющей информации (MIB).

Для регулярного мониторинга менеджер отправляет запросы get, get-next, get-bulk или set агенту по UDP 161. Для мониторинга, управляемого событиями, устройство отправляет ловушки или сообщения менеджеру по UDP 162. Информирование подтверждается; ловушки обычно работают по принципу «выстрелил и забыл». <<<ПК2>>> Порты SNMP 161 и 162

UDP 161 — это порт, который большинство команд имеют в виду, когда спрашивают, открыт ли порт SNMP. Он должен быть доступен от коллектора мониторинга до каждого контролируемого устройства, если требуется опрос. UDP 162 — обратное направление ловушек и информации от устройств к коллектору.

Поскольку SNMP в основном использует UDP, простые проверки только TCP могут пропустить реальное поведение. Средство проверки портов TCP полезно для общих шаблонов достижимости, но проверка SNMP должна включать в себя команду с поддержкой SNMP или проверку сборщика мониторинга на соответствие конкретному сообществу, пользователю и объекту MIB. <<<ПК5>>> SNMPv1, SNMPv2c и SNMPv3

SNMPv1 и SNMPv2c используют строки сообщества, которые ведут себя как общие пароли. Они по-прежнему распространены, особенно в старых сетях, но не обеспечивают надежную аутентификацию или конфиденциальность. В случае утечки строки сообщества злоумышленник может прочитать конфиденциальные данные инвентаризации и топологии.

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

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

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

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

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

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

В Linux обычно используется net-snmp. Настройте snmpd для прослушивания нужного интерфейса, определите пользователей SNMPv3 или ограниченные сообщества и разрешите UDP 161 только от сборщиков мониторинга. Получателям ловушек, таким как snmptrapd, необходимо открыть UDP 162 на сборщике.

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

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

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

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

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

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

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