Моніторинг та аналіз локальних мереж

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Зміст:

1. Моніторинг та аналіз локальних мереж

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

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

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

3. Протокол SNMP

3.1 Відмінності SNMPv 3

3.2 Безпека в SNMPv 3

3.3 Недоліки протоколу SNMP

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

  • Дистанційна колізія (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 Відмінності SNMPv 3

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

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

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

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

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

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

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

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

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

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

1.Функция диспетчера;

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

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

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

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

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

Система обробки повідомлень отримує від Диспетчера вихідні блоки даних (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. А ще можна дізнатися про кількість помилок, які були виявлені під времяотправкі або отримання пакетів.

При розробці SNMPv 3 чимало уваги було приділено безпеці протоколу. Тепер стала підтримуватися модель, орієнтована на користувача (User - BasedSecurityModel скор. USM <* див. RFC 3414>) завдяки якій стало можливим додавання модулів аутентифікації і шіфрованіябез зміни базової архітектури.

3.2 Безпека в SNMPv 3

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

  Основні проблеми, які необхідно було вирішити за допомогою моделі USM:

  Зміна даних сутностями не пройшли аутентифікацію;

  1. Можливість відкладання яких-небудь дій на невизначений час або повторення одних і тих же дій з довільними інтервалами;

  2. Можливість заблокувати обмін даними між сутностями;

  3. Можливість перехоплення трафіку при передачі між сутностями;

  4. Можливість «маскараду», тобто сутність не пройшла аутентифікацію, могла прикинутися сутністю минулої аутентифікацію.

  Проблему вирішили наступним чином: для кожного мережевого пристрою пароль перетворюється в деякий унікальний ключ. Це забезпечує додаткову безпеку тому навіть у тому випадку, якщо ключ буде перехоплений, зловмисник отримає доступ тільки до одного мережного пристрою. Для шифрування пароля використовується алгоритм MD 5, але розробники мабуть вирішили, що це не забезпечить достатньої збереження пароля і тому блок 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 c UBM



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

  • msgVersion (для SNMPv3) = 3

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

  • msgMaxSize - визначає максимальний розмір повідомлення в октетах, підтримуваний відправником. Його значення лежить в діапазоні 484 - (31 лютого -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 - (31 лютого -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 - (31 Лютого -1). Цей код характеризує кількість разів, що SNMP-сервер був перезавантажений з моменту конфігурування.

    • msgAuthoritativeEngeneTime - nmpEngeneTime авторизованого сервера, який бере участь в обміні. Значення цього коду лежить в діапазоні 0 - (31 лютого -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 конкретного типу (наприклад, MIB для концентраторів або MIB для модемів), а також приватні 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 при їх втратах.

    Додати в блог або на сайт

    Цей текст може містити помилки.

    Програмування, комп'ютери, інформатика і кібернетика | Контрольна робота
    157кб. | скачати


    Схожі роботи:
    Топологія локальних мереж
    Особливості комутаторів локальних мереж
    Особливості функціонування локальних інформаційних мереж
    Обладнання для створення локальних мереж
    Апаратні та програмні компоненти локальних обчислювальних мереж
    Механізми управління виробничо господарською діяльністю локальних електричних мереж
    Сучасні засоби тестування і діагностики локальних обчислювальних мереж Тестове вимірювальне
    Основи організації локальних комп`ютерних мереж на основі технології Ethernet
    Розробка технічного рішення щодо утворення пари локальних обчислювальних мереж
    © Усі права захищені
    написати до нас