Проблеми безпеки протоколу SNMP v1/2

Один з найбільш помітних недоліків SNMP v1 - відсутність розвиненої системи захисту даних на рівні, необхідному для мереж масштабу підприємства.

Як сказав Mike Warfield: " SNMP stands for Security Not My Problem ".

У SNMPv1 захист адміністративної інформації трактувалася занадто спрощено: вона базувалася на використанні колективного імені (Community Name), яке, перебуваючи в заголовку SNMP, несло в собі всі можливості захисту повідомлень. Даний засіб (відоме під назвою тривіальний протокол) вимагало, щоб програма-агент і менеджер впізнали одне і те ж колективне ім'я, перш ніж продовжити виконання операцій мережевого адміністрування. У результаті багато адміністраторів мереж обмежувалися у своїй роботі тільки функціями моніторингу, забороняючи видачу команди SET, здатною змінювати параметри конфігурації віддаленого пристрою. Це призвело до того, що користувачі уникали команд SET: таке примітивне засіб захисту, як колективне ім'я, могло дати можливість особам, не наділеним відповідними повноваженнями, змінювати параметри, про що користувачі могли навіть і не дізнатися. До того ж вся критично важлива інформація передавалася у відкритому вигляді.

У зв'язку з цим були розроблені пропозиції щодо вдосконалення захисту в рамках SNMPv1, представлені в липні 1992 р.; вони склали основу структури захисту для SNMPv2. Протягом 1993 року було опубліковано 11 RFC, які визначали нові стандарти SNMP. Перший з них, RFC 1441, є введенням в SNMP версії 2 (SNMPv2).

Стандартами захисту SNMPv2 визначаються методи аутентифікації (DAP - Digest Authentication Protocol) і забезпечення конфіденційності (SPP-Symmetric Privacy Protocol) інформації адміністративного характеру. В основі лежить концепція учасника (party) - унікального набору параметрів захисту, який може включати розташування мережі, протоколи аутентифікації і забезпечення конфіденційності, використовувані між агентом і менеджером.

Новий тип пакетів get-bulk-request дозволяє менеджеру ефективно обробляти великі блоки даних. Ще один новий тип пакетів inform-request дозволяє одному менеджеру надсилати інформацію іншому менеджерові. Визначено два нових MIB: MIB SNMPv2 і MIB SNMPv2-M2M (менеджер-менеджер). SNMPv2 надає поліпшену секретність в порівнянні з SNMPv1. У SNMPv1 ім'я спільноти передається від менеджера до агента у вигляді відкритого пароля. SNMPv2 надає аутентифікацію і розширену секретність.

Однак друга версія SNMP не була підтримана виробниками мережного устаткування і поширення не отримала. Але останнім часом розробники стандартів з IETF намагаються переломити ситуацію, запропонувавши специфікацію третьої версії SNMP. Істотні поліпшення протоколу, що забезпечують гнучке адміністрування агентів систем управління та захист керуючої інформації, зворотна сумісність із системами на основі базової версії SNMPv1, а також відкрита архітектура дозволяють авторам SNMPv3 сподіватися на успішне практичне втілення свого дітища. Успіх буде залежати від багатьох факторів і, зокрема, від того, наскільки широко інформація про його достоїнства проникне в маси.

Можна відзначити наступні принципово нові властивості протоколу SNMPv3:

· Можливість управління фільтрацією повідомлень, що генеруються агентом SNMP;

· Забезпечення безпеки управління за рахунок аутентифікації пристроїв та користувачів, а також шифрування повідомлень;

· Виборчий контроль доступу користувачів до груп об'єктів MIB.

Атака на Windows SNMP.

Cервіс працює на наступних UDP портах:

snmp 161/udp snmp

snmp-trap 162/udp snmp

Цікаві SMI Network Management Private Enterprise Codes:

Prefix: 1.3.6.1.4.1.

2 IBM

4 Unix

9 cisco

32 Santa Cruz Operation

42 Sun Microsystems

Невелике розповсюдження сканерів UDP портів під Windows, SNMP менеджерів, а також відсутність знань про самому протоколі є, по всій видимості, єдиною причиною нечисленності атак на пристрої під управління SNMP v1, так як в реалізаціях цього протоколу в деяких операційні системи допущені серйозні помилки.

Уразливість в стандартній конфіругаціі Windows NT SNMP Сервісу.

Дозволяє віддалено конфігурувати мережеві парамерти, які впливають на безпеку і правильне функціонування системи (якщо адміністратор сам запустив SNMP Service).

При конфігурації за замовчуванням, SNMP service відповідає на стандартне community (ім'я) "public", яке володіє права на читання і запис. Community - це ім'я, яке володіє такими ж функціями, як логін і пароль у системах.

Протокол SNMP надає два рівня повноважень: read-only and read-write, проте до виходу SP4 Windows NT SNMP Service не дозволяв конфігурувати communities по доступу, відмінному від read-write!

Якщо спробувати убезпечити SNMP Service шляхом перейменування community для доступу, то система залишиться незахищеною від крякери, що має акаунт на машині, так як параметри SNMP Service знаходяться в регистри і доступні всім користувачам на читання. Також Windows NT SNMP Service володіє можливістю обмежити доступ для списків IP-адрес. На перший погляд це дозволяє захиститися від атак невідомих систем, проте це не є проблемою для крякери (що необхідно розуміти будь-якому адміністратору), так як протокол SNMP використовує UDP протокол для обміну інформацією, а він є протоколом без встановлення з'єднання, тому можлива підміна вихідного адреси (але для цього доведеться переробити исходники SNMP менеджерів під Unix і вивчити UDP spoofing)

SNMP "set" операції (дозволяють змінювати значення змінних) можуть бути зроблені з підміною зворотної адреси на будь-який, так як відповідь не потрібен. Однак якщо включено обмеження довірених IP адрес, але доведеться знайти акаунт на атакується системі і витягти довірену інформацію з регістра.

Завдяки сконфігуровані за замовчуванням Windows NT SNMP Сервісу ми можемо витягти за допомогою SNMP менеджера наступну інформацію:

- The LAN Manager domain name

- A list of users

- A list of shares

- A list of running services

Як рекомендувалося в ISS сканері, можна вимкнути цю порцію SNMP mibs таким способом:

Відкрити ключ

HKLM \ System \ CurrentControlSet \ Services \ SNMP \ Parameters \ ExtensionAgents

знайти значення, яке містить

SOFTWARE \ Microsoft \ LANManagerMIB2Agent \ CurrentVersion

і видалити його.

- A list of active TCP connections

- A list of active UDP connections

- A list of network interfaces and their associated IP and

hardware addresses

- The IP routing table and the ARP table as well as a number of

networking performance statistics.

Встановлюючи змінні, крякери може модифікувати таблицю роумінгу, ARP таблицю, вимкнути мережеві інтерфейси, збити істотні мережеві параметри типу default IP, час життя пакетів (TTL), IP forwarding (дозволить крякери перенаправляти мережевий трафік). Це особливо небезпечно, якщо атакують машина є фаєрволом.

За прикладами далеко ходити не треба, наприклад, якщо машина є domain controller або server, але отримати список всіх користувачів у домені можна командою C: \ NTRESKIT> snmputil walk public.1.3.6.1.4.1.77.1.2.25

Якщо вам хочеться видалити всі записи в базі даних WINS (що призведе до повної відмови WinNT), то для цього необхідно виконати

~ $ Snmpset-v 1192.178.16.2 public.1.3.6.1.4.1.311.1.2.5.3.0 a 192.178.16.2

з набору CMU SNMP development kit under Unix.

Також є дуже цікава деталь при установки SNMP community names в Windows NT 4.0 (SP3). Якщо сервіс включений, а імена не сконфігуровані, то будь-яке ім'я буде давати read / write привілеї. Як виявилося, це зазначено ще в специфікації SNMP (RFC 1157)!

Четвертий сервіспак (SP4) надає наступне рішення проблеми: додавання контролю доступу community як READ ONLY, READ WRITE або READE CREATE. Однак за замовчуванням SP4 встановлює READ CREATE доступ, який все ще дозволяє атакувати машини. Мікрософт явно піклуватися про зручність WinNT для хакерів:)

Кращий спосіб захисту за рекомендацією M $: заблокувати SNMP на firewall.