Мережеві DоS та DDоS-атаки

rate = (C 1 * W 1+ C 2 * W 2 + ... + Cn * Wn) / track _ period,

Ci - кількість запитів одного класу,

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

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

Ados - система недорогий, але універсальний метод боротьби з атаками DDoS.

3.3 Пропозиції захисту від DoS та DDoS-атак

Небезпека більшості DDoS-атак - в їх абсолютній прозорості і "нормальності". Адже якщо помилка в ПЗ завжди може бути виправлена, то повне зжирання ресурсів - явище майже буденне. З ними стикаються багато адміністраторів, коли ресурсів машини (ширина каналу) стає недостатньо, або web-сайт піддається слешдот-ефекту. І якщо різати трафік і ресурси для всіх підряд, то врятуєшся від DDoS, но втратиш велику половину клієнтів.

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

1. Способи розпізнавання DDoS-атаки, що починається;

2. Методи боротьби з конкретними типами DDoS-атак;

3. Універсальні поради, які допоможуть підготуватися до DoS-атаки і понизити її ефективність.

В самому кінці буде дана відповідь на питання: що робити, коли почалася DDoS-атака.

Боротьба з flood-атаками

Отже, існує два типи DoS/DDoS-атак, і найбільш поширена з них заснована на ідеї флуда, тобто завалення жертви величезною кількістю пакетів. Флуд буває різним: ICMP-флуд, SYN-флуд, UDP-флуд і HTTP-флуд. Сучасні DoS-боти можуть використовувати всі ці види атак одночасно, тому слід заздалегідь поклопотатися про адекватний захист від кожної з них.

Icmp-флуд.

Дуже примітивний метод забивання смуги пропускання і створення навантажень на мережевий стек через монотонну посилку запитів ICMP ECHO (пінг). Легко виявляється за допомогою аналізу потоків трафіку в обидві сторони: під час атаки типа Icmp-флуд вони практично ідентичні. Майже безболісний спосіб абсолютного захисту заснований на відключенні відповідей

SYN-флуд.

Один з поширених способів не лише забити канал зв'язку, але і ввести мережевий стек операційної системи в такий стан, коли він вже не зможе приймати нові запити на підключення. Заснований на спробі ініціалізації великого числа одночасних TCP-з'єднань через посилку SYN-пакету з неіснуючою зворотньою адресою. Після декількох спроб відіслати у відповідь ACK-пакет на недоступну адресу більшість операційок ставлять невстановлене з'єднання в чергу. І лише після n-ої спроби закривають з'єднання. Оскільки потік ACK-пакетів дуже великий, незабаром черга виявляється заповненою, і ядро дає відмову на спроби відкрити нове з'єднання. Найбільш розумні DoS-боти ще і аналізують систему перед початком атаки, щоб слати запити лише на відкриті життєво важливі порти. Ідентифікувати таку атаку просто: досить спробувати підключитися до одного з сервісів. UDP-флуд.

Типовий метод захаращення смуги пропускання. Заснований на безконечній посилці udp-пакетів на порти різних udp-сервісів. Легко усувається за рахунок відрізання таких сервісів від зовнішнього світу і установки ліміту на кількість з'єднань в одиницю часу до dns-сервера на стороні шлюзу.

HTTP-флуд.

Один з найпоширеніших на сьогоднішній день способів флуда. Заснований на безконечній посилці http-повідомлень GET на 80-й порт з метою завантажити web-сервер настільки, щоб він виявився не в змозі обробляти всі останні запити. Часто метою флуда стає не корінь web-сервера, а один із скриптів, що виконують ресурсоємні завдання або що працює з базою даних. У будь-якому випадку, індикатором атаки, що почалася, служитиме аномально швидке зростання лігв web-сервера.

Методи боротьби з Http-флудом включають тюнинг web-сервера і бази даних з метою понизити ефект від атаки, а також відсіювання DoS-ботів за допомогою різних прийомів. По-перше, слід збільшити максимальне число з'єднань до бази даних одночасно. По-друге, встановити перед web-сервером Apache легкий і продуктивний nginx - він кешуватиме запити і видавати статику. Це рішення із списку "Must have", яке не лише понизить ефект DoS-атак, але і дозволить серверу витримати величезні навантаження. Ресурсоємні скрипти можна захистити від ботів за допомогою затримок, кнопок "Натискуй мене", виставляння кукисів і інших прийомів, направлених на перевірку "людяності".

UDP та торенти.

Очима фахівця, суть того, що відбувається така: з кінця січня (стабільна µTorrent версія 2.0 з µTP вийшла якраз 25 січня, офіційно доступна з 3 лютого) в статистичних звітах операторів зв'язку виявлено безперервне зростання UDP-трафіку і одночасне зменшення середньої величини пакетів, які істотно збільшували навантаження на мережеве устаткування. Спостереження показали, що чим сильніше завантажений канал клієнта, тим дрібніші пакети, довша черга і вище навантаження на роутерах.

У всіх випадках причиною що відбувається був названий МікроТоррент (µTorrent), з версії 1.8.1 що почав освоювати протокол обміну µTP (Micro Transport Protocol, до речі, що так не дістав схвалення IETF). І провайдерам просто повезло, що через низку обставин клієнти до версії µTorrent v2.0 не оновилися одномоментно. (У ній, за умовчанням, udp-завантаження стартує першим, а якщо не вийде, то лише тоді - по TCP). Інакше наростання проблем в мережі замість плавного носило б миттєвий характер і, можливо, відразу «повалило» до третини вітчизняних провайдерів..

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

Реінженеринг дозволив не лише переконатися, що згідно з алгоритмами µTP в процесі обміну зменшується довжина пакету із зростанням завантаження каналу, але і передбачити, що для підтвердження використовуються udp-пакети квитування (з функцією, типа ACK) розміром в 2 десятки байт.

Логіка розробників протоколу і алгоритмів µTorrent може виправдовуватися тим, що вони не вважають розумними чекати TCP-ACK від доставки пакету. Адже tcp-потік формується послідовно, і якщо в стеку, наприклад, вже знаходиться 50 пакетів, але немає два, то передачу вони не здійснюватимуть, поки втрачені не прийдуть. А ось пірінгове застосування за своєю суттю якраз і не критично до строгої послідовності у вступі інформації, адже воно запрошує і збирає файли по шматочках.

І що виходить насправді? Додаток, відповідно, зменшує розмір пакету, тому що у нього зростає час між відсиланням пакету і приходом квитанції. Але зростає - то воно тому, що пакети стоять в переповненій черзі на «шейпері». І замість того що б спочатку зменшити кількість посланих, алгоритм ... далі зменшує їх розмір. В результаті, при даному агресивному алгоритмі використання udp-протоколу МікроТоррентом результуючий трафік (ємкість каналу) на клієнтові практично не міняється. Тобто вихідна мрія творців даного ПЗ - завантажити канал «під зав'язку» від цього ближче не стає. Міняється лише структура трафіку - з'являється більше дрібних пакетів, що для провайдера насправді небезпечніше чим зростання трафіку. Давайте порахуємо: якщо в ходу пакети по 150 байт, то при швидкості 100 мегабіт операторові потрібно буде обробити в секунду ... 87 тисяч пакетів! Не всякий провайдер зможе оперативно відреагувати на виниклу проблему: замінити ті ж сервери доступа/роутери на високопродуктивних не всім по кишені. В результаті, багато провайдерів вимушено було для своїх клієнтів ввести на додаток до обмежень по Mbps, ще і по pps.

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

Універсальні поради

Щоб не попасти в безвихідь під час обвалення DDoS-штурму на системи, необхідно ретельно підготувати їх до такої ситуації:

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

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

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

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

Слід зазначити, що всі прийоми, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо отримати в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.

Інше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.

Висновки

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

У рамках проведених досліджень виконано:

Досліджено класифікація методів DoS та DDoS-атак. Розглянуто існуючі рішення як програмні так і апаратні.

1. Розглянуто причини виникнення та структура атак.

2. Розглянуто існуючі рішення і проведено аналіз їх роботи.

А що робити з законом: дотримуватися, обходити або порушувати хай кожен для себе вирішує сам.

Всі способи захисту сайтів мають свої плюси і мінуси. Деякі з них забезпечують менше, а інші більше користі для захисту сайту. Але, ні один із способів не може захистити сайт на 100%. У користувачів, що мають певний досвід роботи в інтернеті, і створення сайту, не буде великою проблемою обійти їх всіх. Наприклад, для обходу блокування правої кнопки миші, достатньо тільки відключити підтримку джава-скрипт в настройках браузера, а при використанні шифрування у користувачів з відключеним джава не буде відображатися сторінка. Адже, ніхто зараз не може сто відсотків захистити і вберегти свій сайт від плагіату, і крадіжки матеріалу з нього. Але, більш надійним є флеш-сайт, його досить складно скопіювати. Рядовий «юзер» інтернету не зможе цього зробити. Але такі сайту вантажаться довше них звичайні, і працюють вони гірше. У людей з тарифікованим інтернетом, і малою швидкістю такі сайти не відкриваються зовсім.

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

Список використаних джерел

1. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. 4 издание, 2010, 943с.

2. Щерба М.В. Система аналізу стійкості розподілених комп'ютерних мереж до атак на «відмова в обслуговуванні» / М.В. Щерба // Омський науковий вісник. Серія «Прилади, машини та технології ». - 2012. - №1 (106). - С. 282-286.

3. Борисов Д.Н. Энтропия как индикатор возникновения аномалий сетевого трафика

4. Брич С.А. Интегрированная модель противодействия атакам в социотехнических системах

5. Домарев Д.В. Математическое описание процессов атак на компьютерные сети

6. Ігнатенко О. Атаки на відмову: виникнення проблеми, огляд атак, класифікація

7. Кадыров М., Труфанов А., Умеров Р. Внедрение облачных вычислений как метод предотвращения DDoS-атак

8. Котенко И.В., Степашкин М.В., Богданов В.С. Модели и методика интеллектуальной оценки уровня защищенности компьютерной сети

9. Михайлюта С.Л., Степанушко И.В., Бабич Б.А., Ткаченко В.Ю, Лавринович В.С. Исследование сетевых DOS-атак, основанных на использовании протокола ICMP

10. Михайлюта С.Л. Математическое описание процессов атак на компьютерные сети

11. Михайлюта С.Л., Степанушко І.В., Бабич Б.О. Захист інтрамереж від DOS- та DDOS-атак

12. Приходько T.А. Исследование вопросов безопасности локальных сетей на канальном уровне модели OSI

13. Сайт Лабораторії Касперского

14. Статистика глобальной сетевой активности

15. Цирульник С.М., Кисюк Д.В., Говорущенко Т.О. DDoS-атаки й методи боротьби з ними

16. Филенко М.С. Распределенные атаки типа «отказ в обслуживании»

17. Яциковская У.О., Карпинский Н.П. Моделирование сетевого трафика компьютерной сети при реализации атак типа DoS/DDoS

18. Abliz M. Internet Denial of Service Attacks and Defense // Pittsburgh: University of Pittsburgh Technical Report

19. DDoS and Security Reports: The Arbor Networks Security Blog

20. Ioannidis J., Bellovin S. Implementing Pushback: Router-Based Defense Against DDoS Attacks // AT&T Labs Research

21. Keromytis A., Misra V., Rubenstein D. SOS: Secure Overlay Services // SIGCOMM'02

22. Worldwide Infrastructure Security Report // Arbor Networks

23. J. Mirkovic, P. Reiher, G. Prier Attacking DDoS at the Source

24. Mirkovic J., Reiher P. A Taxonomy of DDoS Attack

25. Park K., Lee H. On the Effectiveness of Route-Based Packet Filtering for Distributed DoS Attack Prevention in Power-Law Internets // West Lafayette : SIGCOMM'01

26. Yaar A., Perrig A., Song D. Pi A Path Identi?cation Mechanism to Defend // Carnegie Mellon University Research Showcase

27. Feinstein L., Schnackenberg D., Balupari R., Kindred D. Statistical Approaches to DDoS Attack Detection and Response. // DARPA Information Survivability Conference and Exposition

Размещено на Allbest.ru