Створення програмного комплексу для автоматичного аудиту розрахункової техніки комп’ютерної мережі підприємства

МІНІСТЕРСТВО ОСВІТИ І НАУКИ, МОЛОДІ ТА СПОРТУ УКРАЇНИ

КРЕМЕНЧУЦЬКИЙ НАЦІОНАЛЬНИЙ УНІВЕРСИТЕТ

ІМЕНІ МИХАЙЛА ОСТРОГРАДСЬКОГО

ФАКУЛЬТЕТ ЕЛЕКТРОНІКИ ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ

КАФЕДРА ІНФОРМАТИКИ І ВИЩОЇ МАТЕМАТИКИ

ЗВІТ З ПРАКТИКИ

Тема “ Створення програмного комплексу для автоматичного аудиту розрахункової техніки комп’ютерної мережі підприємства ”

Виконала студентка групи І-07-1

Земляна Наталія Андріївна

Перевірив:

керівник практики від університету

Славко Г.В.

Кременчук 2011

Короткий опис кафедри ІВМ

Історія кафедри починається з 1972 року, коли Кременчуцький загально-технічний факультет Полтавського інженерно-будівельного інституту був реорганізований у філіал Харківського автодорожнього інституту і одночасно була створена кафедра «Вищої математики і теоретичної механіки». Очолив кафедру кавалер ордену «Знак пошани», к.т.н., доцент Овчарук Олександр Максимович, авітор однієї монографії та семи авторських свідоцтв СРСР на винахід.

У 1974 році завідувачем кафедри «Вищої математики» був обраний кандидат фізико-математичних наук, доцент Зінов’єв Анатолій Семенович, який очолював її на протязі 10 років. До складу кафедри увійшли кандидати фізико-математичних наук, доценти Кіба Станіслав Петрович, Семенов Валерій Олегович, Шевченко Володимир Митрофанович, старший викладач Погоріла Лариса Василівна, асистенти Голубецька Валентина Леонідівна, Карвацька Лідія Іванівна, Наумова Людмила Миколаївна, Русаловська Адель Валентинівна. Пізніше кафедру поповнили кандидат технічних наук, доцент Хабло Григорій Петрович, асистенти Дворцова Людмила Михайлівна, Дерієнко Іван Іванович, Ємець Тетяна Герардівна, Кашкан Василь Іванович, Наконечний Віктор Васильович, Шаблій В’ячеслав Петрович.

Основними задачами, що стояли перед колективом кафедри, були: створення матеріальної бази кафедри, підвищення науково-методичного рівня лекцій і практичних занять з математичних дисциплін, які викладались кафедрою, визначення основних напрямів науково-дослідницької роботи та підвищення кваліфікації молодих викладачів кафедри шляхом підготовки та захисту дисертацій. Розвиток науково-дослідної роботи у період з 1975 до 1990 року значно зріс після встановлення тісних зв’язків кафедри з Інститутом кібернетики АН УССР, відділом магнітної левітації, який очолював у той час д. т. н., професор Козоріз Василь Васильович. Результати спільних наукових досліджень були статті опубліковані у науковому журналі «Доклады АН УССР». Цей напрям досліджень став одним з найважливіших напрямів наукової роботи філіалу, якою керував доц. Зінов’єв А.С. За результатами цих розробок Славко Г.В., Шаблій В.П. та Кашкан В. І. захистили кандидатські дисертації. Згодом у1994 р. Шаблій В.П. захистив і докторську дисертацію, яка була продовженням цієї теми.

У 1986 році А.С. Зінов’єв був призначений деканом машинобудівного факультету, а на посаду завідуючого кафедрою вищої математики обраний доцент к. фіз.-мат. н. Валерій Олегович Семенов. На кафедрі продовжували працювати доценти Шевченко В.М., Наконечний В.В., Кіба С.П., Хабло Г.П. У цей же період на кафедрі стали працювати доценти Ляшенко В.П. та Зайцев Є.П. Крім згаданих осіб, викладачами та старшими викладачами кафедри працювали Погоріла Л.В., Наумова Л.М., Ємець Т.Г., Дерієнко І.І., Дворцова Л.М., Скапа І.В., а дещо пізніше (після 1992 року) – Галаган О.Г., Кирилаха Н.Г., Набок Т.А., Славко О.В. Таким чином, штатний склад кафедри за цей період коливався в межах 12-22 співробітників, у тому числі: викладачів – 12-16 осіб, наукових співробітників – 4-6 осіб, допоміжний персонал – 1-2 особи.

Викладачі кафедри продовжували удосконалювати науково-методичну роботу щодо забезпечення навчального процесу. Особливо інтенсивною ця робота стала після відкриття стаціонару за окремими спеціальностями та створення стаціонарного підготовчого відділення. В нових умовах виникла необхідність створення нових навчальних та робочих програм, методичних розробок, всього навчально-методичного комплексу дисциплін. Найбільш плідно у цьому напряму працювали доценти Шевченко В.М., Киба С.П., Зайцев Є.П., Ляшенко В.П. Паралельно виконувалась значна науково-дослідницька робота. Викладачами кафедри опублікована значна кількість наукових та науково-методичних праць у різних журналах та збірках, тезах конференцій тощо. Після захисту докторської дисертації в 1994 році, кафедру очолив д.т.н., професор В’ячеслав Петрович Шаблій. До цього він працював асистентом, потім після захисту у 1986 році у Ленінградському університеті кандидатської дисертації – доцентом, а потім і професором кафедри «Вищої математики». До цього були навчання в аспірантурі та докторантурі в Інституті кібернетики АН УРСР. У 1993 році В.П. Шаблій був обраний у Сполучених Штатах Америки дійсним членом Міжнародної транспортної академії САЄ.

Кістяк кафедри складали досвідчені викладачі, кандидати наук, доценти В.М. Шевченко, С.П. Киба, В.В. Наконечний, Є.П. Зайцев, В.І. Кашкан, В.П. Ляшенко, Г.В. Славко, старші викладачі І.І. Дерієнко , І.В. Скапа, асистенти Л.М. Наумова, Л.М. Дворцова. В цей же час на кафедру прийшли молоді та перспективні викладачі, серед них асистенти О.В. Славко, О.Г. Галаган, Н.Г. Кирилаха, Т.А. Набок, І.І. Киба, О.С. Грицюк, А.І. Дерієнко, Л.В. Дерієнко. На кафедрі була відкрита аспірантура за спеціальністю «Динаміка і міцність машин», у якій пізніше навчались та закінчили ряд викладачів кафедри. Після закінчення аспірантури у 2004 році асистент Кирилаха Н.Г. захистила дисертацію та отримала науковий ступінь кандидата фізико-математичних наук за спеціальністю «Математичне моделювання та чисельні методи», науковий керівник доц. В.П. Ляшенко.

З осені 2002 року кафедру очолив д.фіз.-мат. наук, професор Віктор Васильович Богобоящий. Одночасно він був призначений деканом економічного факультету. До цього часу кафедра не була випускаючою. Після приходу на кафедру проф. Богобоящого В.В. почалася робота щодо ліцензування підготовки бакалаврів за напрямом «Прикладна математика». Очолив роботу по ліцензуванню заступник завідувача кафедри доц. В.П. Ляшенко. Викладачами кафедри у цей час розроблялись навчальні та робочі програми нових дисциплін. У 2003 році кафедра була перейменована в кафедру «Інформатики і вищої математики» (наказом № 196-І від 17.11. 2003 р.). У березні 2005 року В.В. Богобоящий передчасно пішов із життя.

Влітку 2005 року кафедра отримала дозвіл МОН України на підготовку бакалаврів за напрямом «Прикладна математика», з ліцензійним обсягом 25 осіб. Після отримання ліцензії всі викладачі кафедри активно включились у розробку методичного забезпечення навчального процесу. Були створені методичні колективи, які очолили досвідчені викладачі, такі як Славко Г.В., Набок Т.А. На кафедру прийшли працювати доцентами кандидати фізико-математичних наук Глухов Юрій Петрович, Сапцін Володимир Михайлович (2005р.), Черненко Варвара Петрівна (2007р.), повернулися працювати на кафедру досвідчені доценти Зінов’єв А.С., Семенов В.О., асистентами Скотнікова Л.М., Кобильська О.Б., Григорова Т.А., Пузир М.С. Захистив кандидатську дисертацію асистент Дерієнко А.І. (2007р.). Вони активно включились у підготовку та проведення навчального процесу. За період з 2004 року до 2009 року за новими дисциплінами було підготовлено біля 100 навчально-методичних розробок, у яких були задіяні всі без виключення викладачі кафедри. У 2008 р. вийшов з грифом МОН перший навчальний посібник «Вища математика», підготовлений викладачами кафедри Ляшенко В.П. та Набок Т.А. У грудні 2008 року кафедра успішно пройшла акредитацію щодо підготовки фахівців за напрямом «Прикладна математика».

Ряд викладачів готують кандидатські дисертації. Вченими кафедри проводились та проводяться наукові розробки у різних галузях науки та виробництва. За останні 5 років кафедра проводила та виконала наукові договори з підприємствами Міністерства промислової політики України (ДІЦТС «Світкермет»), приймала участь у виконанні держбюджетного договору з МОН України та у спільному міжнародному проекті з Університетом м. Любляни (Словенія) .

Починаючи з 2005 року на кафедрі широко започаткована наукова робота студентів. Цю роботу очолив молодий к.т.н. Дерієнко А.І. В цьому йому плідно допомагають доц. Славко Г.В. та ас. Григорова Т.А. Студентами напряму «Прикладна математика» зроблено ряд доповідей на конференціях різного рівня, серед них конференція у Польщі (ст. гр. І-08-1м Настенко О.). Також студенти приймали участь у фіналах конкурсів наукових робіт (ст. гр. І-08-1м Настенко О., гр. І-05-1 Геращенко С., Коваль М., гр. І-06-1 Машкевич O., гр. І-07-1 Малахов С.), де стали переможцями.

В теперішній час кафедра є однією з провідних кафедр університету. Без залучення кафедри не відбувається ліцензування та акредитація жодного технічного напряму підготовки студентів.

ВСТУП

З розповсюдженням ЕОМ неважко передбачити зростання в потребі передачі даних. Деякі додатки, які потребують систем зв'язку, можуть допомогти зрозуміти основні проблемі, які пов'язані з мережами зв'язку.

Існує багато додатків, що вимагають віддаленого доступу до баз даних. Простими прикладами є інформаційні і фінансові служби, доступні користувачам персональних ЕОМ.

Також існує багато додатків, що вимагають дистанційного оновлення баз даних, яку може поєднуватися з доступом до даних. Система резервування авіаквитків, апаратурі автоматичного підрахунку голосів, системі управління інвентаризацією і т.д. є такими прикладами. У додатках подібного типу є безліч географічно розподілених пунктів, в яких потрібні вхідні дані.

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

У промисловості засобів зв'язку приділяється велика увага системам передачі даних на великі відстані. Індустрія глобальних мереж (далі ГМ) розвивається і займає міцні позиції. Локальні мережі (далі ЛМ) є відносно новою областю засобів передачі даних. У даній роботі розглядаються на достатньо загальному рівні топології ЛМ і протоколи.

Промисловість виробництва ЛМ розвивалася з вражаючою швидкістю за останні декілька років. Впровадження локальних мереж мотивується в основному підвищенням ефективності і продуктивності персоналу. Ця мета проголошується фірмами-постачальниками ЛМ, керівництвом установ і розробниками ЛМ.

Використання ЛМ дозволяє полегшити доступ до пристроїв крайового устаткування даних (далі КУД), встановленим в установі. Ці пристрої не тільки ЕОМ (персональні, міні- і великі ЕОМ), але і інші пристрої, звичайно використовувані в установах, такі, як принтери, графічні пристрої і все зростаюче число електронних пристроїв зберігання і обробки файлів і баз даних. Локальна мережа представляє канал і протоколи обміну даними для зв'язку робочих станцій і ЕОМ.

В наш час багато організацій прагнуть дотримуватися загальноприйнятих протоколів як результату міжнародних зусиль, направлених на ухвалення рекомендованих стандартів. Мета цієї роботі полягає в ознайомленні з цими протоколами, використовуваними в ЛМ.

1. МОНІТОРИНГ І АНАЛІЗ ЛОКАЛЬНИХ МЕРЕЖ

Постійний контроль за роботою локальної мережі, що становить основу будь-якої корпоративної мережі, необхідний для підтримки її в працездатному стані. Контроль - це необхідний перший етап, який повинен виконуватися при управлінні мережею. Зважаючи на важливість цієї функції її часто відокремлюють від інших функцій систем управління і реалізують спеціальними засобами. Таке розділення функцій контролю і власне управління корисно для невеликих і середніх мереж, для яких установка інтегрованої системи управління економічно недоцільна. Використання автономних засобів контролю допомагає адміністратору мережі виявити проблемні ділянки і пристрої мережі, а їх відключення або реконфігурацію він може виконувати в цьому випадку вручну. Процес контролю роботи мережі звичайно ділять на два етапи - моніторинг і аналіз.

На етапі моніторингу виконується простіша процедура - процедура збору первинних даних про роботу мережі: статистики про кількість циркулюючих в мережі кадрів і пакетів різних протоколів, стан портів концентраторів, комутаторів і маршрутизаторів і т.п.

Далі виконується етап аналізу, під яким розуміється складніший і інтелектуальний процес осмислення зібраної на етапі моніторингу інформації, зіставлення її з даними, одержаними раніше, і вироблення припущень про можливі причини сповільненої або ненадійної роботи мережі.

Завдання моніторингу розв'язуються програмними і апаратними вимірниками, тестерами, мережевими аналізаторами, вбудованими засобами моніторингу комунікаційних пристроїв, а також агентами систем управління. Завдання аналізу вимагає активнішої участі людини і використання таких складних засобів, як експертні системи, що акумулюють практичний досвід багатьох мережевих фахівців.

2. Класифікація засобів моніторингу і аналізу

Все різноманіття засобів, вживаних для аналізу і діагностики обчислювальних мереж, можна розділити на декілька крупних класів.

• Агенти систем управління, що підтримують функції однієї із стандартних MIB (MIB (Management Information Base) - база даних інформації управління, використовувана в процесі управління мережею як модель керованого об'єкту в архітектурі агент-менедже) і що поставляють інформацію по протоколу SNMP або CMIP. Для отримання даних від агентів звичайно потрібна наявність системи управління, що збирає дані від агентів в автоматичному режимі.

• Вбудовані системи діагностики і управління (Embedded systems). Ці системи виконуються у вигляді програмно-апаратних модулів, що встановлюються в комунікаційне устаткування, а також у вигляді програмних модулів, вбудованих в операційні системи. Вони виконують функції діагностики і управління тільки одним пристроєм, і в цьому їх основна відмінність від централізованих систем управління. Прикладом засобів цього класу може служити модуль управління багатосегментним повторенням Ethernet, що реалізовує функції автосегментації портів при виявленні несправностей, приписування портів внутрішнім сегментам повторення і деякі інші. Як правило, вбудовані модулі управління «за сумісництвом» виконують роль SNMP-агентів, що поставляють дані про стан пристрою для систем управління.

• Аналізатори протоколів (Protocol analyzers). Є програмні або апаратно-програмні системи, які обмежуються на відміну від систем управління лише функціями моніторингу і аналізу трафіку в мережах. Хороший аналізатор протоколів може захоплювати і декодувати пакети великої кількості протоколів, вживаних в мережах, - звичайно декілька десятків. Аналізатори протоколів дозволяють встановити деякі логічні умови для захоплення окремих пакетів і виконують повне декодування захоплених пакетів, тобто показують в зручній для фахівця формі вкладеність пакетів протоколів різних рівнів один в одного з розшифровкою змісту окремих полів кожного пакету.

• Експертні системи. Цей вид систем акумулює знання технічних фахівців про виявлення причин аномальної роботи мереж і можливі способи приведення мережі в працездатний стан. Експертні системи часто реалізуються у вигляді окремих підсистем різних засобів моніторингу і аналізу мереж: систем управління мережами, аналізаторів протоколів, мережевих аналізаторів. Простим варіантом експертної системи є контекстно-залежна система допомоги. Складніші експертні системи є, так звані бази знань, що володіють елементами штучного інтелекту. Прикладами таких систем є експертні системи, вбудовані в систему управління Spectrum компанії Cabletron і аналізатора протоколів Sniffer компанії Network General. Робота експертних систем полягає в аналізі великого числа подій для видачі користувачу короткого діагнозу про причину несправності мережі.

• Устаткування для діагностики і сертифікації кабельних систем. Умовно це устаткування можна поділити на чотири основні групи: мережеві монітори, прилади для сертифікації кабельних систем, кабельні сканери і тестери.

• Мережеві монітори (звані також мережевими аналізаторами) призначені тестування кабелів різних категорій. Мережеві монітори збирають також дані про статистичні показники трафіку - середньої інтенсивності загального трафіку мережі, середньої інтенсивності потоку пакетів з певним типом помилки і т.п. Ці пристрої є найбільш інтелектуальними пристроями зі всіх чотирьох груп пристроїв даного класу, оскільки працюють не тільки на фізичному, але і на канальному, а іноді і на мережевому рівнях.

• Пристрої для сертифікації кабельних систем виконують сертифікацію відповідно до вимог одного з міжнародних стандартів на кабельні системи.

• Кабельні сканери використовуються для діагностики мідних кабельних систем.

• Тестери призначені для перевірки кабелів на відсутність фізичного розриву. Багатофункціональні портативні пристрої аналізу і діагностики. У зв'язку з розвитком технології великих інтегральних схем з'явилася можливість виробництва портативних приладів, які суміщали б функції декількох пристроїв: кабельних сканерів, мережевих моніторів і аналізаторів протоколів.

2.1 Аналізатори протоколів

Аналізатор протоколів є або спеціалізованим пристроєм, або персональним комп'ютером, звичайно переносним, класу Notebook, оснащений спеціальною мережевою картою і відповідним програмним забезпеченням.

Вживані мережева карта і програмне забезпечення повинні відповідати технології мережі (Ethernet, Token Ring, FDDI, Fast Ethernet). Аналізатор підключається до мережі точно так, як і звичайний вузол. Відмінність полягає в тому, що аналізатор може приймати всі пакети даних, передаванні по мережі, тоді як звичайна станція - тільки адресовані їй. Для цього мережевий адаптер аналізатора протоколів переводиться в режим «безладного» захоплення - promiscuousmode.

Програмне забезпечення аналізатора складається з ядра, що підтримує роботу мережевого адаптера і програмного забезпечення, що декодує протокол канального рівня, з яким працює мережевий адаптер, а також найбільш поширені протоколи верхніх рівнів, наприклад IP, TCP, ftp, telnet, HTTP, IPX, NCP, NetBEUI, DECnet і т.п. До складу деяких аналізаторів може входити також експертна система, яка дозволяє видавати користувачу рекомендації про те, які експерименти слід проводити в даній ситуації, що можуть означати ті або інші результати вимірювань, як усунути деякі види несправності мережі.

Аналізатори протоколів мають деякі загальні властивості.

• Можливість (окрім захоплення пакетів) вимірювання середньостатистичних показників трафіку в сегменті локальної мережі, в якому встановлений мережевий адаптер аналізатора.

• Звичайно вимірюється коефіцієнт використання сегменту, матриці перехресного трафіку вузлів, кількість хороших і поганих кадрів, що пройшли через сегмент.

• Можливість роботи з декількома агентами, що поставляють захоплені пакети з різних сегментів локальної мережі. Ці агенти найчастіше взаємодіють з аналізатором протоколів по власному протоколу прикладного рівня, відмінному від SNMP або CMIP.

• Наявність розвиненого графічного інтерфейсу, що дозволяє представити результати декодування пакетів з різним ступенем деталізації.

• Фільтрація захоплюваних пакетів, що відображаються. Умови фільтрації задаються залежно від значення адрес призначення і джерела, типу протоколу або значення певних полів пакету. Пакет або ігнорується, або записується в буфер захоплення. Використання фільтрів значно прискорює і спрощує аналіз, оскільки виключає захоплення або проглядання непотрібних в даний момент пакетів.

• Використання тригерів. Тригери - це що задаються адміністратором деякі умови почала і припинення процесу захоплення даних з мережі. Такими умовами можуть бути: час доби, тривалість процесу захоплення, поява певних значень в кадрах даних. Трігери можуть використовуватися спільно з фільтрами, дозволяючи детальніше і тонко проводити аналіз, а також продуктивно витрачати обмежений об'єм буфера захоплення.

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

Можливості аналізу проблем мережі на фізичному рівні у аналізаторів протоколів мінімальні, оскільки всю інформацію вони одержують від стандартних мережевих адаптерів.

Тому вони передають і узагальнюють інформацію фізичного рівня, яку повідомляє їм мережевий адаптер, а вона багато в чому залежить від типу мережевого адаптера.

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

З розповсюдженням серверів Windows NT все більш популярним стає аналізатор Network Monitor фірми Microsoft. Він є частиною сервера управління системою SMS, а також входить в стандартне постачання Windows NT Server, починаючи з версії 4.0 (версія з усіченими функціями). Network Monitor у версії SMS є багатоканальним аналізатором протоколів, оскільки може одержувати дані від декількох агентів Network Monitor Agent, що працюють в середовищі Windows NT Server, проте в кожен момент часу аналізатор може працювати тільки з одним агентом, так що зіставити дані різних каналів з його допомогою не вдасться. Network Monitor підтримує фільтри захоплення (достатньо прості) і дисплейні фільтри, що відображають потрібні кадри після захоплення (складніші). Експертної системи Network Monitor не має в своєму розпорядженні.

2.2 Мережеві аналізатори

Мережеві аналізатори є еталонними вимірювальними приладами для діагностики і сертифікації кабелів і кабельних систем. Вони можуть з високою точністю зміряти всі електричні параметри кабельних систем, а також працюють на вищих рівнях стека протоколів. Мережеві аналізатори генерують синусоїдальні сигнали в широкому діапазоні частот, що дозволяє вимірювати на приймальній парі амплітудно-частотну характеристику і перехресні наведення, загасання і сумарне загасання. Мережевий аналізатор є лабораторним приладом великих розмірів, достатньо складним в обігу.

Багато виробників доповнюють мережеві аналізатори функціями статистичного аналізу трафіку - коефіцієнта використання сегменту, рівня широкомовного трафіку, відсотка помилкових кадрів, а також функціями аналізатора протоколів, які забезпечують захоплення пакетів різних протоколів відповідно до умов фільтрів і декодування пакетів.

Мережева статистика

У цій групі зібрані найбільш важливі статистичні показники - коефіцієнт використання сегменту (utilization), рівень колізій, рівень помилок і рівень широкомовного трафіку. Перевищення цими показниками певних порогів в першу чергу говорять про проблеми в тому сегменті мережі, до якого підключений багатофункціональний прилад.

Статистика помилкових кадрів

Ця функція дозволяє відстежувати всі типи помилкових кадрів для певної технології. Наприклад, для технології Ethernet характерні наступні типи помилкових кадрів.

• Укорочені кадри (Short frames). Це кадри, що мають довжину, менше допустимої, тобто менше 64 байт. Іноді цей тип кадрів диференціюють на два класи - просто короткі кадри (short), у яких є коректна контрольна сума, і «коротуни» (runts), що не мають коректної контрольної суми. Найбільш вірогідними причинами появи укорочених кадрів є несправні мережеві адаптери і їх драйвери.

• Подовжені кадри (Jabbers). Це кадри, що мають довжину, що перевищує допустиме значення в 1518 байт з хорошою або поганою контрольною сумою. Подовжені кадри є слідством тривалої передачі, яка з'являється із-за несправностей мережевих адаптерів.

• Кадри нормальних розмірів, але з поганою контрольною сумою (Bad FCS) і кадри з помилками вирівнювання по границі байта. Кадри з невірною контрольною сумою є слідством безлічі причин - поганих адаптерів, перешкод на кабелях, поганих контактів, некоректно працюючих портів повторювань, мостів, комутаторів і маршрутизаторів. Помилка вирівнювання завжди супроводжується помилкою по контрольній сумі, тому деякі засоби аналізу трафіку не роблять між ними відмінностей. Помилка вирівнювання може бути слідством припинення передачі кадру при розпізнаванні колізії передавальним адаптером.

• Кадри-примари (ghosts) є результатом електромагнітних наведень на кабелі. Вони сприймаються мережевими адаптерами як кадри, що не мають нормальної ознаки почала кадру - 10101011. Кадри-примари мають довжину більше 72 байт, інакше вони класифікуються як видалені колізії. Кількість виявлених кадрів-примар у великій мірі залежить від точки підключення мережевого аналізатора. Причинами їх виникнення є петлі заземлення і інші проблеми з кабельною системою.

Знання процентного розподілу загальної кількості помилкових кадрів по їх типах може багато що підказати адміністратору про можливі причини неполадок в мережі. Навіть невеликий відсоток помилкових кадрів може привести до значного зниження корисної пропускної спроможності мережі, якщо протоколи, поновлюючи спотворені кадри, працюють з великими тайм-аутами очікування квитанцій. Вважається, що в нормально працюючій мережі відсоток помилкових кадрів не повинен перевищувати 0,01 %, тобто не більше 1 помилкового кадру з 10 000.

Статистика по колізіях

Ця група характеристик дає інформацію про кількість і види колізій, відмічених на сегменті мережі, дозволяє визначити наявність і місцезнаходження проблеми. Аналізатори протоколів звичайно не можуть дати диференційованої картини розподілу загального числа колізій по їх окремих типах, в той же час знання переважаючого типа колізій може допомогти зрозуміти причину поганої роботи мережі.

Нижче приведені основні типи колізій мережі Ethernet.

• Локальна колізія (Local Collision). Є результатом одночасної передачі двох або більш вузлів, що належать до того сегменту, в якому проводяться вимірювання. Якщо багатофункціональний прилад не генерує кадри, то в мережі на витій парі або волоконно-оптичному кабелі локальні колізії не фіксуються. Дуже високий рівень локальних колізій є слідством проблем з кабельною системою.

• Видалена колізія (Remote Collision). Ці колізії відбуваються на іншій стороні повторення (по відношенню до того сегменту, в якому встановлений вимірювальний прилад). У мережах, побудованих на багатопортових повторювань (10Base-T, 10Base-FL/FB, 100Base-TX/FX/T4, Gigabit Ethernet), всі вимірювані колізії є видаленими (окрім тих випадків, коли аналізатор сам генерує кадри і може бути винуватцем колізії). Не всі аналізатори протоколів і засобу моніторингу однаковим чином фіксують видалені колізії. Це відбувається через те, що деякі вимірювальні засоби і системи не фіксують колізії, що відбуваються при передачі преамбули.

• Пізня колізія (Late Collision). Це колізія, яка відбувається після передачі перших 64 байт кадру (по протоколу Ethernet колізія повинна виявлятися при передачі перших 64 байт кадру). Результатом пізньої колізії буде кадр, який має довжину більше 64 байт і містить невірне значення контрольної суми. Найчастіше це указує на те, що мережевий адаптер, що є джерелом конфлікту, виявляється не в змозі правильно прослуховувати лінію і тому не може вчасно зупинити передачу. Іншою причиною пізньої колізії є дуже велика довжина кабельної системи або дуже велика кількість проміжних повторювань, що приводить до перевищення максимального значення часу подвійного обороту сигналу. Середня інтенсивність колізій в нормально працюючій мережі повинна бути менше 5 %. Великі сплески (більше 20 %) можуть бути індикатором кабельних проблем.

Розподіл використовуваних мережевих протоколів

Ця статистична група відноситься до протоколів мережевого рівня. На дисплеї відображається список основних протоколів в вбуваному порядку щодо процентного співвідношення кадрів, що містять пакети даного протоколу до загального числа кадрів в мережі.

Основні відправники (Top Sendes)

Функція дозволяє відстежувати найбільш активні передавальні вузли локальної мережі. Прилад можна набудувати на фільтрацію за єдиною адресою і виявити список основних відправників кадрів для даної станції. Дані відображаються на дисплеї у вигляді діаграми разом з переліком основних відправників кадрів.

Основні получотелі (Top Receivers)

Функція дозволяє стежити за найбільш активними вузлами-одержувачами мережі. Інформація відображається у вигляді, аналогічному приведеному вище.

Основні генератори широкомовного трафіку (Top Broadcasters)

Функція виявляє станції мережі, які більше за інших генерують кадри з широкомовними і груповими адресами.

Генерування трафіку (Traffic Generation)

Прилад може генерувати трафік для перевірки роботи мережі при підвищеному навантаженні. Трафік може генеруватися паралельно з активізованими функціями Мережева статистика, Статистика помилкових кадрів і Статистика по колізіях.

Користувач може задати параметри трафіку, що генерується, такі як інтенсивність і розмір кадрів. Для тестування мостів і маршрутизаторів прилад може автоматично створювати заголовки IP- і IPX-пакетів, і все що потрібний від оператора - це внести адреси джерела і призначення.

В ході випробувань користувач може збільшити на ходу розмір і частоту проходження кадрів за допомогою клавіш управління курсором. Це особливо цінно при пошуку джерела проблем продуктивності мережі і умов виникнення відмов.

3. ПРОТОКОЛ SNMP

Всю необхідну інформацію протокол SNMP одержує з бази інформації, що управляє (ManagementInformationBase, MIB). MIB є базою даних стандартизованої структури. База даних має деревовидну структуру, а всі змінні класифіковані з тематики. Кожне піддерево містить певну тематичну підгрупу змінних. Найбільш важливі компоненти, що відповідають за роботу мережевих вузлів, об'єднані в підгрупі MIB-II.

Існують два типу MIB: стандартні і фірмові. Стандартні MIB визначені комісією по діяльності Інтернет (Internet Activity Board, IAB), а фірмові - виробником пристрою.

У таблиці 1 приведений список найбільш поширених стандартів баз інформації, що управляє.

Таблиця 1

База	Призначення
MIB-II	Задає множину об’єктів, які можуть бути використані для управління інтерфейсами мережі.
MIB повторювання	Включена в подмножину MIB-II. Встановлює об’єкти, які можна використовувати для управління повтореннями.
MIB моста	Включена в подмножину MIB-II. Задає об’єкти даних, які можна викорстовувати для управління мостом.
RMON MIB	Вказує об’єкти даних, які можна використовувати для управління мережею в цілому, за допомогою протокола RMON.

У базах даних, вказаних в таблиці 1, присутня безліч змінних, які можуть бути корисні для діагностування мережі і мережевих пристроїв.

Наприклад, використовуючи MIB-II, можна одержати відомості про загальну кількість пакетів, переданих мережевим інтерфейсом, а за допомогою MIB повторювання можна дізнатися інформацію про кількість колізій в порту.

У MIB кожен об'єкт має ім'я і тип. Ім'я об'єкту характеризує його положення в дереві MIB. При цьому ім'я дочірнього вузла включає ім'я батьківського вузла і задається цілим числом.

3.1 Відмінності SNMPv3

SNMP - протокол прикладного рівня. Він призначений для обміну інформацією між мережевими пристроями. За допомогою цього протоколу, мережевий адміністратор може проводити аналіз мережевого устаткування, знаходити і вирішувати безліч мережевих проблем.

У Грудні 1997 року з виходом SNMPv3, користувачам сталі доступні нові служби, такі як: обмеження доступу, захист даних і аутентифікація користувача.

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

При створенні нової версії розробники керувалися наступними принципами:

1. необхідно забезпечити велику безпеку протоколу (особливо для операцій типу SET);

2. SNMPv3 повинен мати можливість подальшого розвитку і розширення;

3. протокол повинен залишитися простим і зрозумілим;

4. настройки параметрів безпеки SNMPv3 повинні бути максимально простими.

У SNMPv3 вже не застосовуються терміни «агент» і «менеджер», тепер використовуються терміни «суті». Як і раніше одна суть знаходиться на керованому пристрої, а друга займається опитом додатків.

У суті-агента і суті-менеджера тепер є ядро, яке виконує чотири основні функції (див. Рисунок 1):

1. функції диспетчера;

2. обробка повідомлень;

3. функції безпеки;

4. контроль доступу.

Диспетчер - це проста система управління вхідним і витікаючим трафіком. Для кожного витікаючого блоку даних (PDU) він визначає тип необхідної обробки (SNMPv1, SNMPv2, SNMPv3) і передає блок даних відповідному модулю в системі обробки повідомлень.

Після того, як система обробки повідомлень поверне повідомлення, яке містить цей блок даних, Диспетчер відправить його на транспортний рівень для подальшої передачі. Для вхідних повідомлень, Диспетчер проводить зворотну операцію.

Система обробки повідомлень одержує від Диспетчера витікаючі блоки даних (PDU), додає до ним відповідний заголовок і повертає їх назад Диспетчеру.

Система безпеки відповідає за шифрування і аутентифікацію. Всі витікаючі повідомлення перед відправкою спочатку передаються з системи обробки повідомлень в систему безпеки, де все шифруються поля в заголовку повідомлення, блок даних (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>) завдяки якій стало можливим додавання модулів аутентифікації і шифрування без зміни базової архітектури.

Рисунок 1. Схема роботи ядра SNMPv3

3.2 Безпека в SNMPv3

Модель 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):

Рисунок 3 - Формат SNMP-повідомлень, що вкладаються в UDP-датограмми

Поле версія містить значення, рівне номеру версії SNMP мінус один. Поле пароль (community - визначає групу доступу) містить послідовність символів, яка є пропуском при взаємодії менеджера і об'єкту управління. Звичайно це поле містить 6-байтовий рядок public, що означає загальнодоступність. Для запитів GET, GET-next і SET значення ідентифікатора запиту встановлюється менеджером і повертається об'єктом управління у відгуку GET, що дозволяє зв'язувати в пари запити і відгуки. Поле фірма (enterprise) = sysobjectid об'єкту. Поле статус помилки характеризується цілим числом, присланим об'єктом управління:

Таблиця 4. Номери і призначення використовуваних портів

Призначення	Порт	Пояснення
SNMP	161/TCP	Simple Network Management Protocol
SNMP	162/TCP	Trap
SMUX	199/TCP	SNMP Unix Multiplexer
SMUX	199/UDP	SNMP Unix Multiplexer
synoptics-relay	391/TCP	SynOptics SNMP Relay Port
synoptics-relay	391/UDP	SynOptics SNMP Relay Port
Agentx	705/TCP	AgentX
snmp-tcp-port	1993/TCP	cisco SNMP TCP port
snmp-tcp-port	1993/UDP	cisco SNMP TCP port

Таблиця 5 - Коди помилок

Статус о помилці	Ім’я помилки	Опис
0	Noerror	Все гаразд;
1	Toobig	Об'єкт не може укласти відгук в одне повідомлення;
2	Nosuchname	У операції вказана невідома змінна;
3	badvalue	У команді set використана неприпустима величина або неправильний синтаксис;
4	Readonly	Менеджер спробував змінити константу;
5	Generr	Інші помилки.

Якщо відбулася помилка, поле індекс помилки (error index) характеризує, до якої із змінних це відноситься. error index є покажчиком змінної і встановлюється об'єктом управління не рівним нулю для помилок badvalue, readonly і nosuchname. Для оператора TRAP (тип PDU=4) формат повідомлення міняється. Таблиця типів TRAP представлена нижче (рис. 4.4.13.4):

Таблиця 6 - Коди TRAP

Тип TRAP	Ім'я TRAP	Опис
0	Coldstart	Установка початкового стану об'єкту.
1	Warmstart	Відновлення початкового стану об'єкту.
2	Linkdown	Інтерфейс вимкнувся. Перша змінна в повідомленні ідентифікує інтерфейс.
3	Linkup	Інтерфейс включився. Перша змінна в повідомленні ідентифікує інтерфейс.
4	Authenticationfailure	Від менеджера одержано snmp-повідомлення з невірним паролем (community).
5	EGPneighborloss	R$GP-партнер відключився. Перша змінна в повідомленні визначає IP-адресу партнера.
6	Entrprisespecific	Інформація про TRAP міститься в полі спеціальний код.

Для тип TRAP 0-4 поле спеціальний код повинне бути рівне нулю. Поле тимчасова мітка містить число сотих доль секунди (число тиків) з моменту ініціалізації об'єкту управління. Так переривання coldstart видається об'єктом через 200 мс після ініціалізації.

Останнім часом широкого поширення набула ідеологія розподіленого протокольного інтерфейсу DPI (Distributed Protocol Interface). Для транспортування snmp-запитів може використовуватися не тільки UDP-, але і TCP-протокол. Це дає можливість застосовувати SNMP-протокол не тільки в локальних мережах. Формати SNMP-DPI-запитів (версія 2.0) описані в документі RFC-1592. Приклад заголовка snmp-запиту (зображені поля утворюють єдиний масив; див. мал. 4.4.13.3):

Рисунок 4 - Формат заголовка SNMP-запиту

Поле Флаг=0x30 є ознакою ASN.1-заголовка. Коди Ln - є довжинами полів, що починаються з байта, який слідує за кодом довжини, аж до кінця повідомлення-запиту (n - номер поля довжини), якщо не обумовлено інше. Так L1 - довжина пакету-запиту, починаючи з T1 і до кінця пакету, а L3 - довжина поля пароля. Субполя Tn - поля типу наступного за ними субполя запиту. Так T1=2 означає, що поле характеризується цілим числом, а T2=4 указує на те, що далі слідує пароль (поле community, в приведеному прикладі = public). Цифри під малюнками означають типові значення субполів. Код 0xA - є ознакою GET-запиту, за ним слідує поле коду PDU (=0-4, див. табл. 4.4.13.1)

Блок субполів ідентифікатора запиту служить для тих же цілей, що і інші ідентифікатори - для визначення пари запит-відгук. Власне ідентифікатор запиту може займати один або два байти, що визначається значенням Lиз. З - статус помилки (СО=0 - помилки немає); ТМ - тип MIB-змінної (у приведеному прикладі = 0x2B); ІО - індекс помилки. Цифровий код MIB-змінної відображається послідовністю цифрових субполів, що характеризують змінну, наприклад: змінна 1.3.6.1.2.1.5 (у символьному виразі iso.org.dod.internet.mgmt.mib.icmp) характеризується послідовністю кодів 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.

Починаючи з січня 1998 року, випущений набір документів, присвячених SNMPv3. У цій версії істотно розширена функціональність (див. таблицю 1 тип PDU=5-8), розроблена система безпеки.

У даній версії реалізована модель, що базується на процесорі SNMP (SNMP Engene) і містить декілька підсистем (діпетчер, система обробки повідомлень, безпеки і управління доступом, див. мал. 4.4.13.4).

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

Забезпечення безпеки моделі роботи SNMP спрощується звичайно тим, що обмін запитами-відгуками здійснюється в локальній мережі, а джерела запитів-відгуків легко ідентифікуються.

Рисунок 5 - Архітектура суті SNMP (SNMP-entity)

Компоненти процесора SNMP перераховані в таблиці 4.4.13.5 (дивися RFC 2571 і -2573)

Таблиця 7 - Компоненти процесора SNMP

Назва компоненту	Функція компоненту
Диспетчер	Дозволяє одночасну підтримку декількох версій SNMP-повідомлень в процесорі SNMP. Цей компонент відповідає за прийом протокольних блоків даних (PDU), за передачу PDU підсистемі обробки повідомлень, за передачу і прийом мережевих SNMP-повідомлень
Підсистема обробки повідомлень	Відповідає за підготовку повідомлень для відправки і за витягання даних з вхідних повідомлень
Підсистема безпеки	Надає послуги, що забезпечують безпеку: аутентифікацію і захищеність повідомлень від перехоплення і спотворення. Допускається реалізація декількох моделей безпеці
Підсистема управління доступом	Надає ряд послуг авторизації, які можуть використовуватися додатками для перевірки прав доступу.
Генератор команд	Ініціює SNMP-запити Get, GetNext, GetBulk або Set, призначені для локальної системи, які можуть використовуватися додатками для перевірки прав доступу.
Обробник команд	Сприймає SNMP-запити Get, GetNext, GetBulk або Set, призначені для локальної системи, це відображається тим, що contextEngeneID в одержаному запиті рівне відповідному значенню в процесорі SNMP. Додаток обробника команд виконує відповідні протокольні операції, генерує повідомлення відгуку і посилає їх відправника запиту.
Відправник повідомлень	Моніторує систему на предмет виявлення певних подій або умов і генерує повідомлення Trap або Inform. Джерело повідомлень повинне мати механізм визначення адресата таких повідомлень, а також параметрів безпеки
Одержувач повідомлень	Прослуховує повідомлення повідомлення і формує повідомлення-відгуки, коли приходить повідомлення з PDU Inform
Проксі-сервер	Переадресує SNMP-повідомлення. Реалізація цього модуля є опційною

На рис. 6 показаний формат повідомлень SNMPv3, що реалізовує модель безпеки UBM (User-Based Security Model).

Рисунок 6 - Формат повідомлень SNMPv3 з UBM

Перші п'ять полів формуються відправником в рамках моделі обробки повідомлень і обробляються одержувачем. Наступні шість полів несуть в собі параметри безпеки. Далі слідує PDU (блок поля даних) з contextEngeneID і contextName.

• msgVersion (для SNMPv3)=3

• msgID - унікальний ідентифікатор, використовуваний SNMP-суттю для встановлення відповідності між запитом і відгуком. Значення msgID лежить в діапазоні 0 - (231-1)

• msgMaxSize - визначає максимальний розмір повідомлення в октетах, підтримуваний відправником. Його значення лежить в діапазоні 484 - (231-1) і рівно максимальному розміру сегменту, який може сприйняти відправник.

• msgFlags - 1-октетний рядок, що містить три прапори в молодших бітах: reportableFlag, privFlag, authFlag. Якщо reportableFlag=1, повинно бути прислано повідомлення з PDU Report; коли прапор =0, Report посилати не слід. Прапор reportableFlag=1 встановлюється відправником у всіх повідомленнях запиту (Get, Set) або Inform. Прапор встановлюється рівним нулю у відгуках, повідомленнях Trap або повідомленнях Report. Прапори privFlag і authFlag встановлюються відправником для індикації рівня безпеки для даного повідомлення. Для privFlag=1 використовується шифрування, а для authFlag=0 - аутентифікація. Допустимі будь-які комбінації значень прапорів окрім privFlag=1 AND authFlag=0 (шифрування бех аутентифікації).

• msgSecurityModel - ідентифікатор із значенням в діапазоні 0 - (231-1), який указує на модель безпеки, використану при формуванні даного повідомлення. Зарезервовані значення 1 для SNMPv1,2 і 3 - для SNMPv3.

Модель безпеки USM (User-Based Security Model) використовує концепцію авторизованого сервера (authoritative Engene). При будь-якій передачі повідомлення одна або дві суть, передавач або приймач, розглядаються як авторизований SNMP-сервер. Це робиться згідно наступним правилам:

• Коли SNMP-повідомлення містить поле даних, яке припускає відгук (наприклад, Get, GetNext, GetBulk, Set або Inform), одержувач такого повідомлення вважається авторизованим.

• Коли SNMP-повідомлення містить поле даних, яке не припускає посилку відгуку (наприклад SNMPv2-Trap, Response або Report), тоді відправник такого повідомлення вважається авторизованим.

Таким чином, повідомлення, послані генератором команд, і повідомлення Inform, послані відправником повідомлень, одержувач є авторизованим. Для повідомлень, посланих обробником команд або відправником повідомлень Trap, відправник є авторизованим. Такий підхід має дві меті:

• Своєчасність повідомлення визначається з урахуванням свідчення годинника авторизованого сервера. Коли авторизований сервер посилає повідомлення (Trap, Response, Report), воно містить поточне свідчення годинника, так що неавторизований одержувач може синхронізувати свій годинник. Коли неавторизований сервер посилає повідомлення (Get, GetNext, GetBulk, Set, Inform), він поміщає туди поточну оцінку свідчення годинника місця призначення, дозволяючи одержувачу оцінити своєчасність приходу повідомлення.

• Процес локалізації ключа, описаний нижче, встановлює єдиного принципала, який може володіти ключем. Ключі можуть зберігатися тільки в авторизованому сервері, виключаючи зберігання декількох копій ключа в різних місцях.

Коли відправлене повідомлення передається процесором повідомлень в USM, USM заповнює поля параметрів безпеки в заголовку повідомлення. Коли вхідне повідомлення передається обробником повідомлень в USM, обробляються значення параметрів безпеки, що містяться в заголоке повідомлення. У параметрах безпеки містяться:

• msgAuthoritativeEngeneID - snmpEngeneID авторизованого сервера, що бере участь в обміні. Таким чином, це значення ідентифікатора відправника для Trap, Response або Report або адресата для Get, GetNext, GetBulk, Set або Inform.

• msgAuthoritativeEngeneBoots - snmpEngeneBoots авторизованого сервера, що бере участь в обміні. Об'єкт snmpEngeneBoots є цілим в діапазоні 0 - (231-1). Цей код характеризує число раз, яке SNMP-сервер був перезавантажений з моменту конфігурації.

• msgAuthoritativeEngeneTime - nmpEngeneTime авторизованого сервера, що бере участь в обміні. Значення цього коду лежить в діапазоні 0 - (231-1). Цей код характеризує число секунд, яке пройшло з моменту останнього перезавантаження. Кожен авторизований сервер повинен інкрементіровать цей код один раз в секунду.

• msgUserName - ідентифікатор користувача від імені якого послано повідомлення.

• msgAuthenticationParameters - нуль, якщо при обміні не використовується аутентифікація. Інакше - це аутентифікаційний параметр.

• msgPrivacyParameters - нуль - якщо не вимагається дотримання конфіденціальності. Інакше - це параметр безпеки. У діючій моделі USM використовується алгоритм шифрування DES.

Механізм аутентифікації в SNMPv3 припускає, що одержане повідомлення дійсно послане принципалом, ідентифікатор якого міститься в заголовку повідомлення, і він не був модифікований по дорозі. Для реалізації аутентифікації кожний з принципалів, що беруть участь в обміні повинен мати секретний ключ аутентифікації, загальний для всіх учасників (визначається на фазі конфігурації системи). У відправлене повідомлення відправник повинен включити код, який є функцією вмісту повідомлення і секретного ключа. Одним з принципів USM є перевірка своєчасності повідомлення (дивися вище), що робить маловірогідною атаку з використанням копій повідомлення.

Система конфігурації агентів дозволяє забезпечити різні рівні доступу до MIB для різних SNMP-менеджерів. Це робиться шляхом обмеження доступу деяким агентам до певних частин MIB, а також за допомогою обмеження переліку допустимих операцій для заданої частини MIB. Така схема управління доступом називається VACM (View-Based Access Control Model). В процесі управління доступом аналізується контекст (vacmContextTable), а також спеціалізовані таблиці vacmSecurityToGroupTable, vacmTreeFamilyTable і vacmAccessTable.

SNMP-протокол служить прикладом системи управління, де для досягнення потрібного результату видається не команда, а здійснюється обмін інформацією, рішення ж ухвалюється "на місці" відповідно до одержаних даних. Упроваджені підсистеми аутентифікації, інформаційної безпеки і управління доступом.

Структура SNMP MIB

Оброблюваний агентом список об'єктів і їх типів закладається в нього розробником, а станція управління одержує цю інформацію за допомогою MIB (Management Information Base). MIB - текстовий файл, що описує доступні об'єкти і їх типи на мові, визначуваній стандартом SMI (Structure and Identification of Management Information). Агент не використовує цей файл при роботі. MIB ділиться на модулі, деякі модулі приймаються у вигляді стандартів, деякі модулі створюються розробниками устаткування.

Розробник керованого устаткування (розробник агента) повинен надати список підтримуваних агентом модулів. При описі модуля указується які об'єкти обов'язкові для реалізації, а які - ні. При описі агента можна указувати які модулі він підтримує, в якому об'ємі і з якими модифікаціями.

Ha сьогодні існує декілька стандартів на бази даних інформації, що управляє, для протоколу SNMP. Основними є стандарти MIB-I і MIB-II, а також версія бази даних для видаленого управління RMON MIB.

Первинна специфікація MIB-I визначала тільки операції читання значень змінних. Операції зміни або установки значень об'єкту є частиною специфікацій MIB-II.

База даних MIB-II не дає детальної статистики по характерних помилках кадрів Ethernet, окрім цього, вона не відбиває зміну характеристик в часі, що часто цікавить мережевого адміністратора.

Ці обмеження були згодом зняті новим стандартом на MIB - RMON MIB, який спеціально орієнтований на збір детальної статистики по протоколу Ethernet, до того ж з підтримкою такої важливої функції, як побудова агентом залежностей статистичних характеристик від часу.

3.3 НЕДОЛІКИ ПРОТОКОЛУ SNMP

Протокол SNMP служить основою багатьох систем управління, хоча має декілька принципових недоліків, які перераховані нижче.

• Відсутність засобів взаємної аутентифікації агентів і менеджерів. Єдиним засобом, який можна було б віднести до засобів аутентифікації, є використання в повідомленнях так званого «рядка співтовариства» - «community string». Цей рядок передається по мережі у відкритій формі в повідомленні SNMP і служить основою для ділення агентів і менеджерів на «співтовариства», так що агент взаємодіє тільки з тими менеджерами, які указують в полі community string той же символьний рядок, що і рядок, що зберігається в пам'яті агента. Версія SNMP v.2 повинна була ліквідовувати цей недолік, але в результаті розбіжностей між розробниками стандарту нові засоби аутентифікації хоч і з'явилися в цій версії, але як необов'язкові.

• Робота через ненадійний протокол UDP (а саме так працюють переважна більшість реалізацій агентів SNMP) приводить до втрат аварійних повідомлень (повідомлень trap) від агентів до менеджерів, що може привести до неякісного управління. Виправлення ситуації шляхом переходу на надійний транспортний протокол зі встановленням з'єднань чревато втратою зв'язку з величезною кількістю вбудованих агентів SNMP, наявних у встановленому в мережах устаткуванні. (Протокол CMIP спочатку працює поверх надійного транспорту стека OSI і цим недоліком не страждає.) Розробники платформ управління прагнуть подолати ці недоліки. Наприклад, в платформі HP OV Telecom DM TMN, платформою, що є, для розробки багаторівневих систем управління відповідно до стандартів TMN і ISO, працює нова реалізація SNMP, організуюча надійний обмін повідомленнями між агентами і менеджерами за рахунок самостійної організації повторних передач повідомлень SNMP при їх втратах.

Календарний план

Збір інформації про кафедру.	01.02
Ознайомлення з темою та метою роботи.	03.02
Підбір літератури.	04.02
Оформлення звіту з практики.	06.02
Захист роботи.	15.02

ВИСНОВКИ

В даній роботі були проаналізовані та оцінені протоколи та топології, що використовуються в локальних мережах. В загальному виді було розглянуто, як обмінюються даними пристрої обладнання даних в локальній мережі.

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

Більшість локальних мереж використовують протоколи, що були детально описані в роботі. В опис були включені існуючі нормативні положення, які дозволяють використання будь-якої згоди або метода в якості обов’язкового або рекомендованого.