DoS-атака — Вікіпедія

DoS-атака
Мета проєкту або місії	downtimed
DoS-атака у Вікісховищі

Атака на відмову в обслуговуванні, розподілена атака на відмову в обслуговуванні (англ. DoS attack, DDoS attack, (distributed) denial-of-service attack) — напад на комп'ютерну систему з наміром зробити комп'ютерні ресурси недоступними користувачам, для яких комп'ютерна система була призначена.

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

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

Якщо атака відбувається одночасно з великої кількості IP-адрес, то її називають розподіленою (англ. distributed denial-of-service — DDoS).

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

Розглянемо віддалені DoS-атаки. Вони поділяються на два види:

1. Віддалена експлуатація помилок в ПЗ з метою довести його до неробочого стану.
2. Flood (UDP-флуд, ICMP-флуд, MAC-флуд)^[1] — надсилання на адресу жертви величезної кількості безглуздих (рідше — осмислених) пакетів. Метою флуду може бути канал зв'язку або ресурси машини. У першому випадку потік пакетів займає весь пропускний канал і не дає машині, що атакується, можливості обробляти легальні запити. У другому — ресурси машини захоплюються за допомогою багаторазового і дуже частого звернення до якого-небудь сервісу, що виконує складну, ресурсоємну операцію. Це може бути, наприклад, тривале звернення до одного з активних компонентів (скрипту) web-сервера. Сервер витрачає всі ресурси машини на обробку запитів, що атакують, а користувачам доводиться чекати.

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

Є два варіанти організації DDoS атак:

• Ботнет — зараження певного числа комп'ютерів програмами, які в певний момент починають здійснювати запити до атакованого сервера.
• Флешмоб — домовленість великого числа користувачів інтернету почати здійснювати певні типи запитів до атакованого сервера.

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

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

Є кілька методів боротьби, один із них полягає використання фільтрувальної мережі. Мережа приймає трафік на себе, фільтрує його і до цільового сервера доходить тільки перевірений і якісний трафік від реальних користувачів^[2].

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

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

# ping -i 0 -s 10000 -l 100 -q ya.ru 

-i задає інтервал надсилання пакетів. Інтервал менше 200 мс дозволений тільки суперкористувачу. -s задає розмір пакету. Стандартний 54, найбільший 65507 байт. -l задає кількість пакетів що відправляються без очікування на відповідь, і -q робить так щоб утиліта вивела лише підсумки.

Майже безболісний спосіб абсолютного захисту заснований на відключенні відповідей на запити ICMP ECHO:

# sysctl net.ipv4.icmp_echo_ignore_all=1 

Або за допомогою брандмауера:

# iptables -A INPUT -p icmp -j DROP --icmp-type 8 

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

# sysctl -w net.ipv4.tcp_max_syn_backlog=1024 

Зменшення часу утримання «напіввідкритих» з'єднань:

# sysctl -w net.ipv4.tcp_synack_retries=1 

Включення механізму TCP syncookies:

# sysctl -w net.ipv4.tcp_syncookies=1 

Обмеження максимального числа «напіввідкритих» з'єднань з одного IP до конкретного порту:

# iptables -i INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above 10 -j DROP 

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

# iptables -i INPUT -p udp --dport 53 -j DROP -m iplimit --iplimit-above 1 

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

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

# vi /etc/nginx/nginx.conf # Збільшує максимальну кількість використовуваних файлів worker_rlimit_nofile 80000; events { # Збільшує максимальну кількість з'єднань worker_connections 65536; # Використовувати ефективний метод метод epoll для обробки з'єднань use epoll; } http { gzip off; # Відключаємо таймаут на закриття keep-alive з'єднань keepalive_timeout 0; # Не віддавати версію nginx в заголовку відповіді server_tokens off; # Скидати з'єднання після таймауту reset_timedout_connection on; } # Стандартні налаштування для роботи як проксі server { listen 111.111.111.111 default deferred; server_name host.com www.host.com; log_format IP $remote_addr; location / { proxy_pass http://127.0.0.1/; } location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ { root /home/www/host.com/httpdocs; } } 

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

Винятком є використання для атаки фреймів (тег frame) або посилань (тег link, або script), що розміщуються на одному або декількох web-ресурсах з великою кількістю користувачів та посилаються на web-сервер, що атакується.

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

Розставимо види HTTP DDoS атак в залежності від ступеня складності захисту від них (від найменшого до найбільшого): атака з використанням фреймів та посилань; атака з використанням мережі ботів; атака, що організована чисельною групою користувачів.

Вразливим місцем атаки з використанням фреймів або посилань є обов'язкова наявність в HTTP запиті заголовка referer, що встановлюється браузером користувача і містить URL ресурсу, з котрого перейшов по посиланню користувач. Сформувавши на основі статистики за кількістю переходів перелік і виключивши з нього сайти, на котрих офіційно розміщені рекламні або інші посилання на ресурс (каталоги, прайс агрегатори) можна відфільтрувати та заблоковувати шкідливий трафік.

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

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

У разі потреби можна задіювати nginx-модуль ngx_http_limit_req_module [Архівовано 7 квітня 2010 у Wayback Machine.], що обмежує кількість одночасних підключень з однієї адреси.

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

1. Всі сервери, які мають прямий доступ в зовнішню мережу, мають бути підготовлені до простої і швидкої віддаленої роботи. Великим плюсом буде наявність другого, адміністративного, мережевого інтерфейсу, через який можна отримати доступ до сервера при зайнятому основному каналі.
2. Програмне забезпечення, використовуване на сервері, завжди повинно знаходитися в актуальному стані. Всі дірки — пропатчені, оновлення встановлені. Це захистить вас від DoS-атак, багів у сервісах.
3. Всі слухаючі мережеві сервіси, призначені для адміністративного використання, мають бути заховані брандмаузером від всіх, хто не повинен мати до них доступу. Тоді той, що атакує не зможе використовувати їх для проведення DoS-атаки або брутфорса.
4. На підходах до сервера (найближчому маршрутизаторі) має бути встановлена система аналізу трафіку (Netflow в допомогу), яка дозволить своєчасно дізнатися про атаку, що починається, і вчасно виконати заходи з її запобігання.

Потрібно додати в /etc/sysctl.conf такі рядки:

# vi /etc/sysctl.conf # Захист від спуфінгу net.ipv4.conf.default.rp_filter = 1 # Перевіряти TCP-з'єднання кожну хвилину. Якщо на іншій стороні — легальна машина, вона зразу відповість.  # Значення за замовчуванням — 2 години. net.ipv4.tcp_keepalive_time = 60 <# Повторити спробу через десять секунд net.ipv4.tcp_keepalive_intvl = 10 # Кількість повірок перед закриттям з'єднання net.ipv4.tcp_keepalive_probes = 5 

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

• 1997 рік — DDoS-атака на web-сайт Microsoft. Один день мовчання.
• 1999 рік — «поза зоною дії» виявилися web-сайти Yahoo, CNN, ebay і ін.
• Жовтень 2002 — атака на кореневі DNS-сервери інтернету. На деякий час були виведені з ладу 7 з 13 серверів.
• 21 лютого 2003 року — DDoS-напад на Livejournal.com. Два дні сервіс знаходився в паралізованому стані, лише інколи подаючи ознаки життя.
• Квітень-травень 2007 року — на тлі погіршення міждержавних відносин російські хакери влаштували масивні кібератаки проти Естонії.
• Лютий 2012 року — В Україні після закриття міліцією популярного файлообмінника EX.ua було виведено з ладу сайт МВС. Деякий час був недієздатним сайт Президента України. За два дні невідомим хакерам вдалося вивести з ладу сайт адміністрації президента, МВС, СБУ та офіційний сайт Партії регіонів та Компартії України. З перебоями працювали сайти Кабінету Міністрів і Податкової адміністрації.
• Листопад — грудень 2013 року — ЗМІ України заявляють про DDoS-атаки на їхні вебсайти^{[3][4][5][6][7][8]}. Атак зазнали сайти: pravda.com.ua, zik.ua, zaxid.net, hromadske.tv, ukr.net, censor.net, zn.ua, lb.ua, 5.ua, tyzhden.ua, bykvu.com.
• Вересень 2016 — після публікації статті про угрупування, які продають послуги ботнетів для здійснення DDoS-атак, вебсайт журналіста Брайана Кребса (англ. Brian Krebs) сам став жертвою DDoS-атаки, трафік якої на піку досягав 665 Гб/с, що робить її однією з найпотужніших відомих DDoS-атак. Оскільки хостер сайту відмовився надалі безоплатно надавати свої послуги, сайт довелось на деякий час закрити поки не був знайдений новий хостер. Атака була здійснена ботнетом з інфікованих «розумних» відео-камер (так званий інтернет речей). В жовтні того ж року зловмисники оприлюднили вихідні тексти використаного шкідливого ПЗ (відоме під назвою Mirai), чим створили ризики неконтрольованого відтворення атак іншими зловмисниками^[9][10].

  Ботнет Mirai став можливим завдяки використанню вразливості, яка полягала у використанні однакового, незмінного, встановленого виробником пароля для доступу до облікового запису адміністратора на «розумних» пристроях. Всього мав відомості про 61 різних комбінацій логін-пароль для отримання доступу до облікового запису методом перебирання^[11]. Дослідження показали, що значна частина вразливих пристроїв була виготовлена з використанням складових виробництва фірми XiongMai Technologies з офісом в Ханчжоу, та фірми Dahua, Китай. Також дослідження показали, що станом на 23 вересня, коли атака сягнула піку інтенсивності, в інтернеті можна було знайти понад 560 000 пристроїв вразливих до подібного типу атак^[12].

• Наприкінці лютого, початку березня 2018 року — було зафіксовано дві надпотужні D-DoS атаки з піковою потужністю 1,3 Тб/с проти Github та 1,7 Тб/c проти не названого вебресурсу в США. Зловмисники скористались особливістю протоколу системи Memcached для мультиплікації UDP-трафіку.^[13]. Відсутність автентифікації в системі memcached дозволяє зловмисникам використовувати «відкриті» сервери (за оцінками дослідників станом на початок 2018 року було зафіксовано близько 50 тисяч) спочатку для завантаження власних даних, а потім надсилаючи запити на їхнє отримання із підробленою (так званий спуфінг) IP-адресою скеровувати відповіді на адресу жертви^[14].

Спроби закриття в лютому 2012 року файлообмінного сервісу ex.ua спричинили хвилю протестів, що переросли в масовані DDoS-атаки^[15].

Масовані DDoS-атаки на ресурси органів державної влади, здійснювані різноманітними суб'єктами, переважно громадянами України стали першим масованим випадком хактивізму, з яким зіткнулася Україна. Після спроб правоохоронних органів втрутитися в роботу файлообмінного сервісу було здійснено DDoS-атаки на понад 10 інтернет-сайтів органів державної влади, зокрема на сайт Президента України та сайт Міністерства внутрішніх справ України^[15].

Атака розпочалася після того, як правоохоронні органи за позовом компаній Microsoft, Adobe, а також телеканалу «1+1» спочатку заблокували домен, а потім заарештували частину серверів компанії. Уже ввечері того ж дня внаслідок масштабних DDoS-атак було заблоковано роботу офіційних сайтів Президента України, уряду, Верховної Ради, СБУ, Національного банку України, Антимонопольного комітету, Державної податкової служби, Партії регіонів, Міністерства внутрішніх справ України. Певний час МВС було навіть змушене публікувати новини про свою діяльність на сторінках у соцмережах — ВКонтакте та Facebook^[15].

В Інтернеті (а також соціальних мережах) активно поширювались інструкції про те, як саме можна здійснювати DDoS-атаки. Водночас, крім пересічних користувачів, які брали участь в атаці, в мережі було запущено спеціальний проект «Низькоорбітальна іонна гармата» (англ. Low Orbit Ion Cannon), який мав полегшити проведення DDoS-атак. Через сайт Low Orbit Ion Cannon активувався скрипт, який починав серію звернень до визначених сайтів з метою виведення їх з ладу за рахунок дуже значної кількості відвідувань^[15].

Уже 3 лютого ex.ua знов став доступним для користувачів, а згодом (у червні 2012 року) компанії повернули більшу частину вилученої техніки. Розслідування, проведене фахівцями СБУ засвідчило, що більшість атак здійснювали пересічні користувачі, з найбільш активними з яких було проведено «роботу». Водночас кримінальних справ чи інших процесуальних дій за результатами цих атак так і не було порушено, оскільки, по-перше, до МВС із відповідними заявами ніхто з постраждалих так і не звернувся, а по-друге, особливістю DDoS-атак щодо урядових ресурсів є те, що прямого економічного збитку державні органи від них не зазнають^[15].

Події довкола ex.ua вперше наочно продемонстрували, наскільки Українська держава не готова ані ідеологічно, ані технічно до подібних атак, що далось взнаки під час Російсько-української кібервійни, яка відбувалась на тлі збройного протистояння^[15].

• Кібервійна
• Безпека мережі
• Вірус комп'ютерний
• Спам
• Ботнет
• LOIC
• BlackEnergy — троян з DDoS функціоналом
• Ping-флуд

• Soltanian, Mohammad Reza Khalifeh (10 листопада 2015). Theoretical and Experimental Methods for Defending Against DDoS Attacks. ISBN 978-0-12-805399-7. OCLC 1162249290.

• Матеріал взято з wiki.tntu.edu.ua [Архівовано 11 квітня 2022 у Wayback Machine.]
• http://systemnews.com.ru/?mod=art&part=other&id=020 [Архівовано 30 січня 2009 у Wayback Machine.]
• http://www.xakep.ru/post/49752/ [Архівовано 28 березня 2010 у Wayback Machine.]

Цю статтю треба вікіфікувати для відповідності стандартам якості Вікіпедії. Будь ласка, допоможіть додаванням доречних внутрішніх посилань або вдосконаленням розмітки статті. (лютий 2016)

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

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