DoS-атака

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

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

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

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

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

Анатомія DoS-атак[ред.ред. код]

DDoS-атака

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

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

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

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

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

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

Методи боротьби[ред.ред. код]

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

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

Боротьба з flood-атаками[ред.ред. код]

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

Icmp-флуд[ред.ред. код]

Дуже примітивний метод забивання смуги пропускання і створення навантажень на мережевий стек через монотонну посилку запитів 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

SYN-флуд[ред.ред. код]

Один з поширених способів не лише забити канал зв'язку, але і ввести мережевий стек операційної системи в такий стан, коли він вже не зможе приймати нові запити на підключення. Заснований на спробі ініціалізації великого числа одночасних 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-пакетів на порти різних udp-сервісів. Легко усувається за рахунок відрізання таких сервісів від зовнішнього світу і установки ліміту на кількість з'єднань в одиницю часу до dns-сервера на стороні шлюзу:

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

HTTP-флуд[ред.ред. код]

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

UDP та торенти[ред.ред. код]

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

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

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

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

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

І що виходить насправді? Додаток, відповідно, зменшує розмір пакету, тому що у нього зростає час між відсиланням пакету і приходом квитанції. Але зростає-то воно тому, що пакети стоять в переповненій черзі на «шейпері». І замість того що б спочатку зменшити кількість посланих, алгоритм … далі зменшує їх розмір. В результаті, при даному агресивному алгоритмі використання UDP-протоколу МікроТоррентом результуючий трафік (ємкість каналу) на клієнтові практично не змінюється. Тобто вихідна мрія творців даного ПЗ — завантажити канал «під зав'язку» від цього ближче не стає. Змінюється лише структура трафіку — з'являється більше дрібних пакетів, що для провайдера насправді небезпечніше, ніж зростання трафіку.

Давайте порахуємо: якщо в ходу пакети по 150 байт, то при швидкості 100 мегабіт операторові потрібно буде обробити в секунду … 87 тисяч пакетів! Не кожен провайдер зможе оперативно відреагувати на виниклу проблему: замінити ті ж сервери доступа/роутери на високопродуктивних не всім по кишені. В результаті, багато провайдерів вимушено було для своїх клієнтів ввести на додаток до обмежень по Mbps, ще і по pps.

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

Оскільки локальна ситуація моделюється досить нескладно, я провів невеликий експеримент з наявним ADSL-Wi-Fi-шлюзом, який можу запропонувати прогресивним користувачам µTorrenta. Особливо вражаючим тест виглядатиме на давніх роутерах з Wifi. У моєму циклі випробувань пристрій почав «сповільнюватися» приблизно вже при 30-40 активних сесіях «звичайного» закачування, але при агресивній роботі по UDP (всього 5 роздач) втратив відразу майже третину смуги. Поза сумнівом, причина — в перевищенні можливої кількості коректно оброблюваних пакетів за одиницю часу.

Універсальні поради[ред.ред. код]

Щоб не попасти в безвихідь під час 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). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.

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

Цікаву альтернативу рішенням Cisco випускає компанія Reactive Networks (www.reactivenetworks.com). Їхній продукт під назвою Floodguard є апаратним комплексом, що складається з детекторів і виконавчих модулів. Детектори, встановлені на брандмаузерах, маршрутизаторах і світчах, постійно займаються моніторингом трафіку і створюють його профіль на основі таких параметрів, як обсяг пакетів, джерело, напрям, тип тощо. У разі виникнення аномалій детектор посилає всі подробиці про подію виконавчим модулям, розташованим на маршрутизаторах в різних сегментах мережі. Отримавши повідомлення від детектора, виконавчі модулі починають діяти: вони відшукують паразитний трафік в пакетах і, в разі успіху, сповіщають про це передуючі в ході трафіку модулі і посилають їм інструкції щодо активації фільтрів на маршрутизаторах. В результаті, перед потоком флуд-трафіку повинен утворитися заслон, який буде швидко переміщатися в бік джерела.

Здається, почалося. Що робити?[ред.ред. код]

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

Наявність Syn-флуда встановлюється легко — через підрахунок числа «напіввідкритих» tcp-з'єднань:
# netstat -na | grep ":80\ " | grep Syn_rcvd
      У звичайній ситуації їх не повинно бути зовсім (або дуже невелика кількість: максимум 1-3). Якщо це не так — ти атакований, терміново переходь.
       З Http-флудом дещо складніше. Спершу потрібний підрахувати кількість процесів Apache і кількість з'єднань на 80-й порт (Http-флуд):
# ps aux | grep httpd | wc -l
# netstat -na | grep ":80\ " | wc -l
      Значення, у декілька разів вищі за середньостатистичні, дають підстави задуматися. Далі слід проглянути список ip-адрес, з яких йдуть запити на підключення:
# netstat -na | grep ":80\ " | sort | uniq -c | sort -nr | less
      Однозначно ідентифікувати DoS-атаку не можна, можна лише підтвердити свої припущення про наявність такої, якщо одна адреса повторюється в списку надто багато разів. Додатковим підтвердженням буде аналіз пакетів за допомогою tcpdump:
# tcpdump -n -i eth0 -s 0 -w output.txt dst port 80 and host ip-сервера
      Показником служить великий потік одноманітних (і що не містять корисної інформації) пакетів від різних IP, направлених на один порт/сервіс (наприклад, корінь web-сервера або певний cgi-скріпт). Остаточно визначившись, починаємо банити по ip-адресах (буде значно більше ефекту, якщо ти зробиш це на маршрутизаторі):
# iptables -A INPUT -s xxx.xxx.xxx.xxx -p tcp --destination-port http -j DROP
      Або відразу по підмережах:
# iptables -a INPUT -s xxx.xxx.0.0/16 -p tcp --destination-port http -j DROP

Це дасть тобі деяку фору, яку ти повинен використовувати для того, щоб звернутися до провайдера/хостера (з прикладеними до повідомлення балками web-сервера, ядра, брандмаузера і списком виявлених тобою ip-адрес). Більшість з них, звичайно, проігнорують це повідомлення (а хостинги з оплатою трафіку ще і порадіють — DoS-атака принесе їм прибуток) або просто відключать твій сервер. Але у будь-якому випадку це слід зробити обов'язково, — ефективний захист від DDoS можливий лише на магістральних каналах. Поодинці ти впораєшся з дрібними нападками, направленими на виснаження ресурсів сервера, але виявишся беззахисним перед більш-менш серйозним DDoS'ом.

Боротьба з DDoS в FreeBSD[ред.ред. код]

      Зменшуємо час чекання у відповідь пакету на запит SYN-ACK (захист від Syn-флуда):
# sysctl net.inet.tcp.msl=7500
      Перетворюємо сервер на чорну діру. Так ядро не слатиме у відповідь пакети при спробі підключитися до незайнятих портів (знижує навантаження на машину під час DDoS'а на випадкові порти):
# sysctl net.inet.tcp.blackhole=2
# sysctl net.inet.udp.blackhole=1
      Обмежуємо число відповідей на icmp-повідомлення 50 в секунду (захист від Icmp-флуда):
# sysctl net.inet.icmp.icmplim=50
      Збільшуємо максимальну кількість підключень до сервера (захист від всіх видів DDoS):
# sysctl kern.ipc.somaxconn=32768
      Включаємо Device_polling — самостійний опит мережевого драйвера ядром на високих навантаженнях (істотно знижує навантаження на систему під час DDoS'а):
           • Збираємо заново ядро з опцією «options Device_polling»;
           • Активуємо механізм полінгу: «sysctl kern.polling.enable=1»;
           • Додаємо запис «kern.polling.enable=1» у /etc/sysctl.conf.

Історія[ред.ред. код]

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

Див. також[ред.ред. код]

Примітки[ред.ред. код]

Посилання[ред.ред. код]