Вступ 4
1. Опис протоколу SNMP 6
2. Версії протоколу SNMP 10
3. Реалізація програмної частини утиліти 14
3.1.Модуль управління процесами на віддаленій ЕОМ 17
3.2.Модуль виведення інформації про систему віддаленої ЕОМ 27
3.3.Модуль формування графіків MRTG 28
4. Тестування та результати роботи утиліти 30
Висновки 35
Список використаної літератури 36
ВСТУП
Протокол SNMP був розроблений з метою перевірки функціонування мережевих маршрутизаторів і мостів. Згодом сфера дії протоколу охопила і інші мережеві пристрої, такі як хаби, шлюзи, термінальні сервера, LAN Manager сервера, машини під управлінням Windows NT і т.д. Крім того, протокол допускає можливість внесення змін у функціонування зазначених пристроїв.
Основними взаємодіючими особами протоколу є агенти і системи управління. Якщо розглядати ці два поняття на мові "клієнт- сервер", то роль сервера виконують агенти, тобто ті самі пристрої, для опитування стану яких і був розроблений розглянутий нами протокол. Відповідно, роль клієнтів відводиться системам управління - мережним додаткам, необхідним для збору інформації про функціонування агентів. Крім цих двох суб'єктів в моделі протоколу можна виділити також ще два: керуючу інформацію і сам протокол обміну даними.
Для чого взагалі потрібно виробляти опитування обладнання? Іноді в процесі функціонування мережі виникає необхідність визначити певні параметри деякого пристрою, такі як, наприклад, розмір MTU, кількість прийнятих пакетів, відкриті порти, встановлену на машині операційну систему і її версію, дізнатися чи включена опція форвардинга на машині і багато іншого. Для здійснення цього якнайкраще підходять SNMP клієнти.
Крім сказаного вище розглянутий протокол володіє ще однією вельми важливою особливістю, а саме можливістю модифікувати дані на агентах. Безумовно, було б дурістю дозволити модифікацію абсолютно будь-якого параметра, але, не дивлячись на це, і кількість тих параметрів, для яких допускається операція запису просто лякає. З першого погляду це повністю спростовує всю теорію мережевої безпеки, але, якщо заглибитися в питання, то стає ясно, що не все так запущено, як здається з першого погляду. Адже при невеликих зусиллях адміністратора мережі можна звести ризик успішного завершення атаки до мінімуму. Але цей аспект ми обговоримо пізніше.
Зупинимося на тому, яку ж все-таки інформацію може отримати система управління з надр SNMP. Вся інформація про об'єкти системи - агента потримається в так званій MIB ( management information base ) - базі керуючої інформації, іншими словами MIB являє собою сукупність об'єктів, доступних для операцій запису-читання для кожного конкретного клієнта, залежно від структури і призначення самого клієнта. Адже не має сенсу питати у термінального сервера кількість відкинутих пакетів, так як ці дані не мають жодного відношення до його роботи, так як і інформація про адміністратора для маршрутизатора. Тому керуюча система повинна точно уявляти собі, що і у кого запитувати.
На даний момент існує чотири бази MIB :
Internet MIB - база даних об'єктів для забезпечення діагностики помилок і конфігурацій. Включає в себе 171 об'єкт (у тому числі і об'єкти MIB I ).
LAN manager MIB - база з 90 об'єктів - паролі, сесії, користувачі, загальні ресурси.
WINS MIB - база об'єктів, необхідних для функціонування WINS сервера ( WINSMIB.DLL ).
DHCP MIB - база об'єктів, необхідних для функціонування DHCP сервера ( DHCPMIB.DLL ), для динамічного виділення IP адрес в мережі.
Опис протоколу snmp
За допомогою протоколу SNMP, програмне забезпечення для управління мережевими пристроями може отримувати доступ до інформації, яка зберігається на керованих пристроях (наприклад, на комутаторі). На керованих пристроях SNMP зберігає інформацію про пристрій, на якому він працює, в базі даних, яка називається MIB.
Всі імена MIB мають ієрархічну структуру. Існує десять кореневих аліасів : 1 ) System - дана група MIB II містить у собі сім об'єктів, кожен з яких служить для зберігання інформації про систему (версія ОС, час роботи і т.д.). 2 ) Interfaces - містить 23 об'єкта, необхідних для ведення статистики мережевих інтерфейсів агентів ( кількість інтерфейсів, розмір MTU, швидкість передачі, фізичні адреси і т.д.). 3 ) AT ( 3 об'єкта) - відповідають за трансляцію адрес. Більш не використовується. Була включена в MIB I. Прикладом використання об'єктів AT може послужити проста ARP таблиця,відповідності фізичних ( MAC ) адрес мережевих карт IP адресами машин. У SNMP v2 ця інформація була перенесена в MIB для відповідних протоколів. 4 ) IP ( 42 об'єкта) - дані про проходять IP пакетах (кількість запитів, відповідей, відкинутих пакетів). 5 ) ICMP ( 26 об'єктів ) - інформація про контрольні повідомленнях (вхідні / вихідні повідомлення, помилки і т.д.). 6 ) TCP ( 19 ) - все, що стосується однойменного транспортного протоколу (алгоритми, константи, з'єднання, відкриті порти тощо). 7 ) UDP ( 6 ) - аналогічно, тільки для UDP протоколу ( вхідні / вихідні датаграми, порти, помилки). 8 ) EGP ( 20 ) - дані про трафік Exterior Gateway Protocol (використовується маршрутизаторами, об'єкти зберігають інформацію про прийнятих / відісланих / відкинутих кард). 9 ) Transmission - зарезервована для специфічних MIB. 10 ) SNMP (29) - статистика по SNMP - вхідні / вихідні пакети, обмеження пакетів за розміром, помилки, дані про оброблені запитах і багато іншого.
Кожен з них представимо у вигляді дерева, що росте вниз, (система до болю нагадує організацію DNS). Наприклад, до адреси адміністратора ми можемо звернутися за допомогою такого шляху : system.sysContact.0, до часу роботи системи system.sysUpTime.0, до опису системи (версія, ядро та інша інформація про ОС) : system.sysDescr.0. З іншого боку ті ж дані можуть задаватися і в точковій нотації. Так system.sysUpTime.0 відповідає значення 1.3.0, так як system має індекс "1" в групах MIB II, а sysUpTime - 3 в ієрархії групи system. Нуль в кінці шляху говорить про скалярному типі збережених даних. Посилання на повний список ( 256 об'єктів MIB II ). У процесі роботи символьні імена об'єктів не використовуються, тобто якщо менеджер запитує у агента вміст параметра system.sysDescr.0, то в рядку запиту посилання на об'єкт буде перетворена в " 1.1.0 ", а не буде передана " як є". Далі ми розглянемо BULK -запит і тоді стане ясно, чому це настільки важливо. На цьому ми завершимо огляд структури MIB II і перейдемо безпосередньо до опису взаємодії менеджерів ( систем управління) та агентів.
Traps
Traps - це повідомлення, які попереджають про події, що відбулися при роботі комутатора. Події можуть бути як серйозними типу перезавантаження ( хтось випадково відключив живлення комутатора ), так і менш серйозними типу зміни стану порту. Комутатор генерує traps і посилає їх станції мережевого управління.
Адміністраторами traps є особливі користувачі локальної мережі, яким представляються деякі права і доступ до перегляду та підтримки мережі. Адміністратори отримують відправлені комутатором traps і повинні зробити деякі дії для запобігання збоїв в майбутньому або відключення мережі.
Ви можете визначити станції управління, які можуть отримувати traps від комутатора. Це можна зробити шляхом введення списку IP- адрес авторизованих станцій мережевого управління. Ви також можете вказати версію SNMP, використовувану для авторизації. Можна ввести до чотирьох IP- адрес адміністраторів traps і чотири відповідних SNMP сommunity strings.
Нижче наводяться типи повідомлень traps, які можуть отримувати адміністратори.
Cold Start Дане повідомлення означає, що комутатор був включений і инициализирован так, що всі програмні налаштування були відновлені, а апаратні компоненти перезавантажувались. " Холодний " старт відрізняється скидання комутатора до заводських установок тим, що налаштування зберігаються в незалежній пам'яті, використовуваної для відновлення конфігурації комутатора.
Warm Start Дане повідомлення означає, що комутатор був перезавантажений (тільки програмно ), але тест з самодіагностиці при включенні живлення (Power - On Self - Test - POST ) був пропущений.
Authentication Failure Дане повідомлення означає, що хтось намагається підключитися до комутатора, використовуючи невірну " рядок співтовариства" SNMP - Community string. Комутатор автоматично запам'ятовує IP -адреса неавторизованого користувача.
Topology Change Повідомлення Topology Change (зміна топології ) надсилається комутатором, коли будь-який з його сконфигурированних портів переходить зі стану Learning в Forwarding, або зі стану Forwarding в Blocking. Даний trap не генерується, якщо при тому ж зміні стану порту був посланий new root trap.
Link Change Event Дане повідомлення посилається кожен раз, коли стан порту змінюється з link up на link down або з link down на link up.
Port Partition Дане повідомлення посилається кожен раз, коли стан порту змінюється на partition (порт блокується ) в результаті виникнення більш ніж 32 колізій на ньому при роботі на швидкості 10 Мбіт / с або більше ніж 64 колізій при роботі на швидкості 100 Мбіт / с.
Broadcast \ Multicast Storm Дане повідомлення посилається кожен раз, коли на порту долається порогове значення пакетів широкомовної / групового розсилання. (кількість пакетів в секунду), встановлене глобально для комутатора. На кожному порту підтримуються роздільні лічильники для широкомовних пакетів і для пакетів групової розсилки. Порогове значення за замовчуванням дорівнює 128 тисяч пакетів / с як для широкомовного розсилання, і так і для групового розсилання.