Що таке ддос атаки. DDoS-атака: що таке, як працює і чи можна захиститися

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

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

Види DoS-атак

Існують різні причини, через які може виникнути умова DoS:

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

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

Експлуатація помилок

Експлойтомназивають програму, фрагмент програмного коду або послідовність програмних команд, що використовують уразливості у програмному забезпеченні та застосовуються для проведення атаки на кіберсистему. З експлойтів, що ведуть до DoS-атаки, але непридатних, наприклад, для захоплення контролю над «ворожою» системою, найбільш відомі WinNuke та Ping of death (Пінг смерті).

Флуд

Про флуд як порушення мережевого етикету див. Флуд.

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

Для створення флуду можуть застосовуватися як звичайні мережеві утиліти на кшталт ping (цім відомо, наприклад, інтернет-спільнота «Уп'ячка»), так і спеціальні програми. Можливість DDoS'а часто «зашивають» у ботнети. Якщо на сайті з високою відвідуваністю буде виявлена ​​вразливість типу «міжсайтовий скриптинг» або можливість включення картинок з інших ресурсів, цей сайт також можна застосувати для DDoS-атаки.

Флуд каналу зв'язку та TCP-підсистеми

Будь-який комп'ютер, що має зв'язок із зовнішнім світом за протоколом TCP/IP, схильний до таких типів флуду:

  • SYN-флуд - при даному виді флуд-атаки на вузол, що атакується, направляється велика кількість SYN-пакетів за протоколом TCP (запитів на відкриття з'єднання). При цьому на комп'ютері, що атакується, через короткий час вичерпується кількість доступних для відкриття сокетів (програмних мережевих гнізд, портів) і сервер перестає відповідати.
  • UDP-флуд - цей тип флуду атакує не комп'ютер-мету, яке канал зв'язку. Провайдери резонно припускають, що UDP пакети треба доставити першими, а TCP можуть почекати. Великою кількістю UDP-пакетів різного розміру забивають канал зв'язку, і сервер, який працює за протоколом TCP, перестає відповідати.
  • ICMP-флуд - те саме, але за допомогою ICMP-пакетів.

Флуд прикладного рівня

Багато служб влаштовані так, що невеликим запитом можна викликати велику витрату обчислювальних потужностей на сервері. У такому разі атакується не канал зв'язку або TCP-підсистема, а безпосередньо служба (сервіс) – флудом подібних «хворих» запитів. Наприклад, веб-сервери вразливі для HTTP-флуду, - для виведення веб-сервера з ладу може застосовуватися як найпростіше GET /, так і складний запит до бази даних на кшталт GET /index.php?search=<случайная строка> .

Виявлення DoS-атак

Існує думка, що спеціальні засоби виявлення DoS-атак не потрібні, оскільки факт DoS-атаки неможливо не помітити. У багатьох випадках це справді так. Однак досить часто спостерігалися вдалі DoS-атаки, які були помічені жертвами лише через 2-3 доби. Бувало, що негативні наслідки атаки ( флуд-Атаки) виливалися в зайві витрати на оплату надлишкового Internet-трафіку, що з'ясовувалося лише при отриманні рахунку від Internet-провайдера. Крім того, багато методів виявлення атак неефективні поблизу об'єкта атаки, але ефективні на мережевих магістральних каналах. У такому разі доцільно ставити системи виявлення саме там, а не чекати, поки користувач, який зазнав атаки, сам її помітить і звернеться за допомогою. До того ж, для ефективної протидії DoS-атакам необхідно знати тип, характер та інші характеристики DoS-атак, а оперативно отримати ці відомості таки дозволяють системи виявлення.

Методи виявлення DoS-атак можна розділити на кілька великих груп:

  • сигнатурні – засновані на якісному аналізі трафіку.
  • статистичні – засновані на кількісному аналізі трафіку.
  • гібридні (комбіновані) - поєднують у собі переваги обох вищезгаданих методів.

Захист від DoS-атак

Заходи протидії DoS-атакам можна розділити на пасивні та активні, а також на превентивні та реакційні.

Нижче наведено короткий перелік основних методів.

  • Запобігання.Профілактика причин, що спонукають тих чи інших осіб організовувати та вжити DoS-атаки. (Дуже часто кібератаки взагалі є наслідками особистих образ, політичних, релігійних та інших розбіжностей, що провокує поведінку жертви тощо)
  • Фільтрування та блекхолінг.Блокування трафіку, що походить від атакуючих машин. Ефективність цих методів знижується в міру наближення до об'єкта атаки і підвищується в міру наближення до атакуючої машини.
  • Зворотній DDOS- Перенаправлення трафіку, що використовується для атаки, на атакуючого.
  • Усунення вразливостей.Не працює проти флуд-атак, котрим «уразливістю» є кінцівка тих чи інших системних ресурсів.
  • Нарощування ресурсів.Абсолютного захисту природно не дає, але є гарним тлом для застосування інших видів захисту від DoS-атак.
  • Розосередження.Побудова розподілених та дублювання систем, які не припинять обслуговувати користувачів, навіть якщо деякі їх елементи стануть недоступними через DoS-атаку.
  • Ухиляння.Видалення безпосередньої мети атаки (доменного імені або IP-адреси) подалі від інших ресурсів, які часто також піддаються впливу разом з метою атаки.
  • Активні заходи у відповідь.Вплив на джерела, організатора або центр управління атакою як техногенними, так і організаційно-правовими засобами.
  • Використання обладнання для відображення DoS-атак.Наприклад DefensePro® (Radware), Периметр (МФІ Софт), Arbor Peakflow® та інших виробників.
  • Придбання сервісу захисту від DoS-атак.Актуально у разі перевищення флудом пропускної спроможності мережного каналу.

Див. також

Примітки

Література

  • Кріс КасперськийКомп'ютерні віруси зсередини та зовні. - Пітере. - СПб. : Пітер, 2006. - С. 527. - ISBN 5-469-00982-3
  • Stephen Northcutt, Mark Cooper, Matt Fearnow, Karen Frederik.Аналіз типових порушень безпеки в мережах = Intrusion Signatures and Analysis. - New Riders Publishing (англ.) СПб.: Видавничий дім "Вільямс" (російськ.), 2001. - С. 464. - ISBN 5-8459-0225-8 (російськ.), 0-7357-1063-5 ( англ.)
  • Morris, R.T= A Weakness in the 4.2BSD Unix TCP/IP Software. - Computing Scienece Technical Report No.117. - AT&T Bell Laborotories, Feb 1985.
  • Bellovin, S. M.= Security Problems у протоколі TCP/IP. - Computer Communication Review, Vol. 19, No.2. - AT&T Bell Laborotories, April 1989.
  • = daemon9 / route / infinity "IP-spooling Demystified: Trust Realationship Exploitation". - Phrack Magazine, Vol.7, Issue 48. - Guild Production, July 1996.
  • = daemon9 / route / infinity "Project Neptune". - Phrack Magazine, Vol.7, Issue 48. - Guild Production, July 1996.

Посилання

  • DoS-атакау каталозі посилань Open Directory Project (

Все частіше в офіційних повідомленнях хостинг-провайдерів то тут, то там мелькають згадки про відбиті DDoS-атаки. Все частіше користувачі, виявивши недоступність свого сайту, передбачають саме DDoS. І справді, на початку березня Рунет пережив цілу хвилю таких атак. При цьому експерти запевняють, що веселощі тільки розпочинаються. Обійти увагою явище настільки актуальне, грізне та інтригуюче просто не виходить. Тож сьогодні поговоримо про міфи та факти про DDoS. З погляду хостинг-провайдера, зрозуміло.

Пам'ятний день

20 листопада 2013 року вперше за 8-річну історію нашої компанії весь технічний майданчик виявився недоступним на кілька годин через безпрецедентну DDoS-атаку. Постраждали десятки тисяч наших клієнтів по всій Росії та в СНД, не кажучи вже про нас самих і нашого інтернет-провайдера. Останнє, що встиг зафіксувати провайдер, перш ніж біле світло померкло для всіх - що його вхідні канали забиті вхідним трафіком наглухо. Щоб уявити це наочно, уявіть собі вашу ванну зі звичайним зливом, в яку подався Ніагарський водоспад.

Навіть вищі в ланцюжку провайдери відчули відлуння цього цунамі. Графіки нижче наочно ілюструють, що відбувалося того дня з інтернет-трафіком у Петербурзі та Росії. Зверніть увагу на круті піки о 15 і 18 годині, саме в ті моменти, коли ми фіксували атаки. На ці раптові плюс 500-700 Гб.

Декілька годин пішло на те, щоб локалізувати атаку. Було обчислено сервер, на який вона велася. Потім було обчислено і мету інтернет-терористів. Знаєте, за ким била вся ця ворожа артилерія? По одному звичайному, скромному клієнтському сайту.

Міф номер один: «Об'єкт атаки – завжди хостинг-провайдер. Це підступи його конкурентів. Не моїх. Насправді, найбільш можлива мета інтернет-терористів - простий клієнтський сайт. Тобто сайт одного з ваших сусідів з хостингу. А може, і ваш.

Не все те DDoS…

Після подій на нашому техмайданчику 20 листопада 2013 року та їх часткового повторення 9 січня 2014 року деякі користувачі стали припускати DDoS у будь-якому приватному збою роботи власного сайту: «Це DDoS!» і "У вас знову DDoS?"

Важливо пам'ятати, що якщо нас осягає такий DDoS, що його відчувають навіть клієнти, ми одразу самі повідомляємо про це.

Хочемо заспокоїти тих, хто поспішає піддаватися паніці: якщо з вашим сайтом щось не так, то ймовірність того, що це саме DDoS становить менше 1%. Просто через те, що з сайтом дуже багато чого може статися і це «багато що» трапляється набагато частіше. Про методи самостійної швидкої діагностики, що саме відбувається з вашим сайтом, ми поговоримо в одному з наступних постів.

А поки що – заради точності слововживання – прояснимо терміни.

Про терміни

DoS-атака (від англійської Denial of Service) - це атака, покликана домогтися відмови сервера в обслуговуванні через його перевантаження.

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

Але насправді ми практично не спостерігаємо DoS-атак. Чому? Тому що об'єктами атак найчастіше виступають промислові об'єкти (наприклад, потужні продуктивні сервери хостинг-компаній). А щоб завдати помітної шкоди роботі такої машини, потрібні набагато більші потужності, ніж її власні. Це по-перше. А по-друге, ініціатора DoS-атаки досить легко вирахувати.

DDoS - по суті, те саме, що і DoS, тільки атака носить розподілений характер.Не п'ять, не десять, не двадцять, а сотні та тисячі комп'ютерів звертаються до одного сервера одночасно з різних місць. Така армія машин називається ботнетом. Обчислити замовника та організатора практично неможливо.

Співучасники

Що за комп'ютери включаються до ботнету?

Ви здивуєтеся, але найчастіше це звичайні домашні машини. Who knows?.. - цілком можливо, ваш домашній комп'ютер захоплений на бік зла.

Потрібно для цього небагато. Зловмисник знаходить вразливість у популярній операційній системі або додатку і з її допомогою заражає ваш комп'ютер трояном, який у певний день і годину дає вашому комп'ютеру команду почати робити певні дії. Наприклад, надсилати запити на певний IP-адресу. Без вашого відома та участі, звичайно.

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

Це справді відбувається. Навіть якщо ви про це не думаєте. Навіть якщо ви дуже далекі від ІТ (особливо якщо ви далекі від ІТ!).

Цікаве хакерство чи механіка DDoS

Явище DDoS неоднорідне. Це поняття поєднує безліч варіантів дій, які призводять до одного результату (відмову в обслуговуванні). Розглянемо варіанти неприємностей, які можуть зробити нам DDoS'ери.

Перевитрата обчислювальних ресурсів сервера

Робиться це шляхом надсилання на певний IP пакетів, обробка яких потребує великої кількості ресурсів. Наприклад, для завантаження якоїсь сторінки потрібно виконати велику кількість SQL-запитів. Всі атакуючі будуть вимагати саме цю сторінку, що викличе перевантаження сервера та відмову в обслуговуванні для звичайних, легітимних відвідувачів сайту.
Це атака рівня школяра, який присвятив кілька вечорів читання журналу «Хакер». Вона не є проблемою. Один і той же URL, що запитується, обчислюється моментально, після чого звернення до нього блокується на рівні вебсервера. І це лише один із варіантів рішення.

Перевантаження каналів зв'язку до сервера (на вихід)

Рівень складності цієї атаки приблизно такий самий, що й у попередньої. Зловмисник обчислює найважчу сторінку на сайті, і підконтрольний йому ботнет масово починає вимагати саме її.


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

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

Перевантаження каналів зв'язку до сервера (на вхід)

Це вже завдання для тих, хто читав журнал «Хакер» більше одного дня.


Фото із сайту радіо «Эхо Москвы». Не знайшли нічого наочнішого, щоб представити DDoS з перевантаженням каналів на вхід.
Щоб забити канал вхідним трафіком, потрібно мати ботнет, потужність якого дозволяє генерувати потрібну кількість трафіку. Але можливо, є спосіб віддати мало трафіку, а отримати багато?

Є і не один. Варіантів посилення атаки багато, але один із найпопулярніших прямо зараз - атака через громадські DNS-сервери.Фахівці називають цей метод посилення DNS-ампліфікацією(на випадок, якщо комусь більше до вподоби експертні терміни). А якщо простіше, то уявіть собі лавину: щоб зірвати її досить невеликого зусилля, а щоб зупинити - нелюдські ресурси.

Ми з вами знаємо, що публічний DNS-серверна запит повідомляє будь-якому бажаючому дані про будь-яке доменне ім'я. Наприклад, ми запитуємо такий сервер: розкажи мені про домен sprinthost.ru. І він, анітрохи не вагаючись, вивалює нам усе, що знає.

Запит до DNS-сервера - дуже проста операція. Звернутися до нього майже нічого не варте, запит буде мікроскопічним. Наприклад, ось таким:

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

Але як зробити так, щоб відповідь направлялася на потрібний IP? Як підробити IP джерела запиту, щоб DNS-сервер видавав свої відповіді у напрямку жертви, яка не запитувала жодних даних?

Справа в тому, що DNS-сервери працюють по протоколу обміну даними UDP, якому не потрібно підтвердження джерела запиту. Підробити вихідний IP у разі не становить досера великої праці. Ось чому такий тип атак зараз такий популярний.

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

Чого досер не може знати, то це ємності каналів атакованого. І якщо він не розрахує потужність своєї атаки вірно і не заб'є канал до сервера відразу на 100%, атака може бути досить швидко та нескладно відбита. За допомогою утиліт типу TCPdumpлегко з'ясувати, що вхідний трафік прилітає від DNS і на рівні Firewall заборонити його приймати. Цей варіант - відмова приймати трафік від DNS - пов'язаний з певною незручністю для всіх, однак і сервери, і сайти на них при цьому успішно працюватимуть.

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

Якщо атака потужна

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

І тоді це стає глобальною проблемою для всіх. І якщо стисло, це те, з чим нам довелося мати справу 20 листопада 2013 року. А коли відбуваються масштабні потрясіння, час включати особливу магію!


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

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

А коли вона повторюється, на IP, що атакується, вже не 500-1000 акаунтів, а який-небудь десяток-другий.

Коло підозрюваних звужується. Ці 10-20 акаунтів знову розносяться за різними IP-адресами. І знову інженери в засідці чекають на повторення атаки. Знову і знову розносять аккаунти, що залишилися під підозрою, по різних IP і так, поступовим наближенням, обчислюють об'єкт атаки. Всі інші облікові записи до цього моменту повертаються до нормальної роботи на колишньому IP.

Як відомо, це миттєва процедура, вона потребує часу реалізацію.

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

Чи є світло наприкінці тунелю?

Зараз бачимо, що DDoS-активність постійно зростає. Замовити атаку стало дуже доступно і потворно недорого. Щоб уникнути звинувачень у пропаганді, пруфлінків не буде. Але повірте нам на слово це так.

Міф номер п'ять: «DDoS-атака – дуже дорогий захід, і дозволити собі замовити таку можуть лише ділки бізнесу. У крайньому випадку, це підступи секретних служб!» Насправді подібні заходи стали вкрай доступними.

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

Правова сторона питання

Це зовсім непопулярний аспект обговорення DDoS-атак, оскільки ми рідко чуємо про випадки упіймання та покарання призвідників. Однак слід пам'ятати: DDoS-атака - це кримінальний злочин. У більшості країн світу, у тому числі в РФ.

Міф номер шість: « Тепер я знаю про DDoS достатньо, замовлю свято для конкурента - і нічого мені за це не буде! Не виключено, що буде. І якщо буде, то мало не здасться.

  • Зав'язка історії з DDoS платіжної системи Assist
  • Хвилююча розв'язка

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

PS:у нас не є достатньо теплих слів, щоб висловити всю нашу вдячність, тому ми просто говоримо"Дякую!" нашим терплячим клієнтам, які палко підтримали нас у важкий день 20 листопада 2013 року. Ви сказали багато підбадьорливих слів у нашу підтримку у

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

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

Правильні інгредієнти

Сувора правда така, що багато сайтів може покласти будь-хто, скориставшись атакою Slowloris, що наглухо вбиває Apache, або влаштувавши так званий SYN-флуд за допомогою ферми віртуальних серверів, піднятих за хвилину в хмарі Amazon EC2. Всі наші подальші поради щодо захисту від DDoS самотужки ґрунтуються на наступних важливих умовах.

1. Відмовитися від Windows Server

Практика підказує, що сайт, який працює на вінді (2003 або 2008 – неважливо), у разі DDoS приречений. Причина невдачі криється в винтовому мережевому стеку: коли з'єднань стає дуже багато, то сервер неодмінно починає погано відповідати. Ми не знаємо, чому Windows Server у таких ситуаціях працює настільки огидно, але стикалися з цим не раз і не два. З цієї причини мова в цій статті йтиме про засоби захисту від DDoS-атак у разі, коли сервер крутиться на Linux. Якщо ви щасливий власник щодо сучасного ядра (починаючи з 2.6), то як первинний інструментарій будуть виступати утиліти iptables та ipset (для швидкого додавання IP-адрес), за допомогою яких можна оперативно забанити ботів. Ще один ключ до успіху - правильно приготовлений мережевий стек, про що ми також говоритимемо далі.

2. Розлучитися з Apache

Друга важлива умова – відмова від Apache. Якщо у вас, не рівна година, стоїть Apache, то як мінімум поставте перед ним проксі, що кешує - nginx або lighttpd. Apache"вкрай важко віддавати файли, і, що ще гірше, він на фундаментальному рівні (тобто невиправно) вразливий для небезпечної атаки Slowloris, що дозволяє завалити сервер мало не з мобільного телефону. Для боротьби з різними видами Slowloris користувачі Apache придумали спочатку патч Anti-slowloris.diff, потім mod_noloris, потім mod_antiloris, mod_limitipconn, mod_reqtimeout... Але якщо ви хочете спокійно спати ночами, простіше взяти HTTP-сервер, невразливий для Slowloris на рівні архітектури коду, тому всі наші подальші рецепти ґрунтуються що на фронтенді використовується nginx.

Відбиваємось від DDoS

Що робити, коли прийшов DDoS? Традиційна техніка самооборони – почитати лог-файл HTTP-сервера, написати патерн для grep (що відловлює запити ботів) та забанити всіх, хто під нього підпаде. Ця методика спрацює... якщо пощастить. Ботнети бувають двох типів, обидва небезпечні, але по-різному. Один цілком приходить на сайт миттєво, інший поступово. Перший вбиває все й одразу, зате в логах з'являється весь повністю, і якщо ви їх проgrepаєте та забаните всі IP-адреси, то ви – переможець. Другий ботнет укладає сайт ніжно та обережно, але банити вам його доведеться, можливо, протягом доби. Будь-якому адміністратору важливо розуміти: якщо планується боротися grep'ом, то треба бути готовим присвятити боротьбі з атакою кілька днів. Нижче поради про те, куди можна заздалегідь підкласти соломки, щоб не так боляче було падати.

3. Використовувати модуль testcookie

Мабуть, найголовніший, найдієвіший і оперативніший рецепт цієї статті. Якщо на ваш сайт приходить DDoS, то максимально дієвим способом дати відсіч може стати модуль testcookie-nginx, розроблений хабракористувачем @kyprizel. Ідея проста. Найчастіше роботи, що реалізують HTTP-флуд, досить тупі і не мають механізмів HTTP cookie та редиректу. Іноді трапляються просунутіші - такі можуть використовувати cookies і обробляти редиректи, але майже ніколи DoS-бот не несе в собі повноцінного JavaScript-движка (хоча це зустрічається все частіше і частіше). Testcookie-nginx працює як швидкий фільтр між ботами та бекендом під час L7 DDoS-атаки, що дозволяє відсіювати сміттєві запити. Що входить до цих перевірок? Чи вміє клієнт виконувати HTTP Redirect, чи підтримує JavaScript, чи він браузер, за який себе видає (оскільки JavaScript скрізь різний і якщо клієнт каже, що він, скажімо, Firefox, то ми можемо це перевірити). Перевірка реалізована за допомогою кукісів з використанням різних методів:

  • "Set-Cookie" + редирект за допомогою 301 HTTP Location;
  • "Set-Cookie" + редирект за допомогою HTML meta refresh;
  • довільним шаблоном, причому можна використовувати JavaScript.

Щоб уникнути автоматичного парсингу, перевіряюча кукіса може бути зашифрована за допомогою AES-128 і пізніше розшифрована на клієнтській стороні JavaScript. У новій версії модуля з'явилася можливість встановлювати кукісу через Flash, що також дозволяє ефективно відсіяти ботів (які Flash, як правило, не підтримують), але, щоправда, блокує доступ для багатьох легітимних користувачів (фактично всіх мобільних пристроїв). Примітно, що використовувати testcookie-nginx вкрай просто. Розробник, зокрема, наводить кілька зрозумілих прикладів використання (на різні випадки атаки) із семплами конфігів для nginx.

Крім переваг, у testcookie є і недоліки:

  • ріже всіх роботів, у тому числі Googlebot. Якщо ви плануєте залишити testcookie на постійній основі, переконайтеся, що ви не пропадете з пошукової видачі;
  • створює проблеми користувачам з браузерами Links, w3m та їм подібними;
  • не рятує від роботів, оснащених повноцінним браузерним двигуном з JavaScript.

Словом, testcookie_module не є універсальним. Але від ряду речей, таких як, наприклад, примітивні інструментарії Java і C#, він допомагає. Таким чином ви відсікаєте частину загрози.

4. Код 444

Метою DDoS'єрів часто стає найбільш ресурсомістка частина сайту. Типовий приклад – пошук, який виконує складні запити до бази. Звичайно, цим можуть користуватися зловмисники, зарядивши відразу кілька десятків тисяч запитів до пошукового двигуна. Що ми можемо вдіяти? Час відключити пошук. Нехай клієнти не зможуть шукати потрібну інформацію вбудованими засобами, але весь основний сайт залишатиметься в працездатному стані доти, поки ви не знайдете корінь всіх проблем. Nginx підтримує нестандартний код 444, який дозволяє просто закрити з'єднання і нічого не віддавати у відповідь:

Location /search ( return 444; )

Таким чином, можна, наприклад, оперативно реалізувати фільтрацію по URL. Якщо ви впевнені, що запити до location /search приходять тільки від ботів (наприклад, ваша впевненість полягає в тому, що на вашому сайті взагалі немає розділу /search), ви можете встановити на сервер пакет ipset і забанити ботів простим shell-скриптом:

Ipset-N ban iphash tail-f access.log | while read LINE; do echo "$LINE" | \ cut -d "" -f3 | cut -d " " -f2 | grep -q 444 && ipset -A ban "$(L%% *)";

Якщо формат лог-файлів нестандартний (не combined) або потрібно банити за іншими ознаками, ніж статус відповіді, може знадобитися замінити cut на регулярне вираження.

5. Банім з геопризнаку

Нестандартний код відповіді 444 може стати у нагоді ще й для оперативного бана клієнтів з геоознаки. Ви можете жорстко обмежити окремі країни, від яких відчуваєте незручність. Скажімо, навряд чи інтернет-магазин фотоапаратів з Ростова-на-Дону має багато користувачів в Єгипті. Це не дуже хороший спосіб (прямо скажемо - огидний), оскільки дані GeoIP неточні, а лихварі іноді літають до Єгипту на відпочинок. Але якщо вам втрачати нічого, то дотримуйтесь інструкцій:

  1. Підключіть до nginx GeoIP-модуль (wiki.nginx.org/HttpGeoipModule).
  2. Виведіть інформацію про геоприв'язку в access log.
  3. Далі, модифікувавши наведений вище шелл-скрипт, проgrepайте accesslog nginx'а і додайте відфутболених за географічною ознакою клієнтів у бан.

Якщо, наприклад, боти здебільшого були з Китаю, це може допомогти.

6. Нейронна мережа (PoC)

Нарешті, ви можете повторити досвід хабракористувача @SaveTheRbtz, який взяв нейронну мережу PyBrain, запхав у неї лог і проаналізував запити (habrahabr.ru/post/136237). Метод робочий, хоч і не універсальний:). Але якщо ви дійсно знаєте нутрощі свого сайту – а ви, як системний адміністратор, повинні, – то у вас є шанси, що в найбільш трагічних ситуаціях такий інструментарій на основі нейронних мереж, навчання та заздалегідь зібраної інформації вам допоможе. У цьому випадку дуже корисно мати access.log до початку DDoS"а, тому що він описує практично 100% легітимних клієнтів, а отже, відмінний dataset для тренування нейронної мережі. Тим більше очима в лозі боти видно не завжди.

Діагностика проблеми

Сайт не працює – чому? Його DDoS'ят чи це баг движка, не помічений програмістом? Неважливо. Не шукайте відповіді це питання. Якщо ви вважаєте, що ваш сайт можуть атакувати, зверніться до компаній, що надають захист від атак - у ряду анти-DDoS-сервісів перша доба після підключення безкоштовна - і не витрачайте більше часу на пошук симптомів. Зосередьтеся на проблемі. Якщо сайт працює повільно або не відкривається взагалі, значить, у нього щось не в порядку з продуктивністю, і – незалежно від того, чи йде DDoS-атака чи ні – ви, як професіонал, зобов'язані зрозуміти, чим це викликано. Ми неодноразово були свідками того, як компанія, яка відчуває труднощі з роботою свого сайту через DDoS-атаки, замість пошуку слабких місць у движку сайту намагалася направляти заяви до МВС, щоб знайти та покарати зловмисників. Не допускайте таких помилок. Пошук кіберзлочинців - це важкий і тривалий процес, ускладнений структурою та принципами роботи мережі Інтернет, а проблему з роботою сайту потрібно вирішувати оперативно. Змусіть технічних фахівців знайти, у чому полягає причина падіння продуктивності сайту, а заяву зможуть написати юристи.

7. Юзайте профайлер та відладчик

Для найпоширенішої платформи створення веб-сайтів – PHP + MySQL – вузьке місце можна шукати за допомогою наступних інструментів:

  • профайлер Xdebug покаже, на які виклики програма витрачає найбільше часу;
  • вбудований налагоджувач APD та налагоджувальний висновок у лог помилок допоможуть з'ясувати, який саме код виконує ці виклики;
  • в більшості випадків собака заритий у складності та великоваговості запитів до бази даних. Тут допоможе вбудована в двигун бази даних SQL-директива explain.

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

Приклад наведено для PHP, але ідея є справедливою для будь-якої платформи. Розробник, що пише програмні продукти якою б то не було мовою програмування, повинен вміти оперативно застосовувати і відладчик, і профільник. Потренуйтеся заздалегідь!

8. Аналізуйте помилки

Проаналізуйте обсяг трафіку, час відповіді сервера кількість помилок. Для цього дивіться логі. У nginx час відповіді сервера фіксується у лозі двома змінними: request_time та upstream_response_time. Перша - це повний час виконання запиту, включаючи затримки мережі між користувачем і сервером; друга повідомляє, скільки бекенд (Apache, php_fpm, uwsgi...) виконував запит. Значення upstream_response_time надзвичайно важливе для сайтів з великою кількістю динамічного контенту та активним спілкуванням фронтенду з базою даних, їх не можна нехтувати. Як формат лога можна використовувати такий конфіг:

Log_format xakep_log "$remote_addr - $remote_user [$time_local] " ""$request" $status $body_bytes_sent " ""$http_referer" "$http_user_agent" $request_time \ $upstream_response_time";

Це combined-формат із доданими полями таймінгу.

9. Відстежуйте кількість запитів на секунду

Також подивіться на кількість запитів за секунду. У разі nginx ви можете приблизно оцінити цю величину наступною shell-командою (змінна ACCESS_LOG містить шлях до журналу запитів nginx у combined-форматі):

Echo $(($(fgrep -c "$(env LC_ALL=C date) [email protected]$(($(date \ +%s)-60)) +%d/%b/%Y:%H:%M)" "$ACCESS_LOG")/60))

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

10. Не забувайте про tcpdump

Багато хто забуває, що tcpdump - це шалений засіб діагностики. Я наведу кілька прикладів. У грудні 2011-го виявили баг в ядрі Linux, коли воно відкривало TCP-з'єднання при виставлених прапорах TCP-сегменту SYN і RST. Першим багрепорт відправив саме системний адміністратор з Росії, чий ресурс був атакований цим методом - атакуючі дізналися про вразливість раніше, ніж весь світ. Йому, мабуть, така діагностика допомогла. Інший приклад: у nginx є одна не дуже приємна властивість - він пише в балку тільки після повної відпрацювання запиту. Бувають ситуації, коли сайт лежить, нічого не працює і нічого немає. Все тому, що всі запити, які зараз завантажують сервер, ще не виконалися. Tcpdump допоможе тут.

Він настільки хороший, що я радив людям не використовувати бінарні протоколи до того, як вони переконаються, що все гаразд, - адже текстові протоколи налагоджувати tcpdump"ом легко, а бінарні - ні. Однак сніффер хороший як засіб діагностики - як засіб підтримки production"а він страшний. Він легко може втратити відразу кілька пакетів та зіпсувати вам історію користувача. Дивитися його висновок зручно, і він стане в нагоді для ручної діагностики та бана, але намагайтеся нічого критичного на ньому не засновувати. Інший улюблений багатьма засіб «погріпати запити» - ngrep - взагалі за замовчуванням намагається запросити в районі двох гігабайт пам'яті, що несвопується, і тільки потім починає зменшувати свої вимоги.

11. Атака чи ні?

Як відрізнити DDoS-атаку, наприклад, від ефекту рекламної кампанії? Це питання може здатися смішним, але ця тема не менш складна. Бувають досить курйозні випадки. В одних добрих хлопців, коли вони напружилися і ґрунтовно прикрутили кешування, сайт зліг на пару днів. З'ясувалося, що протягом кількох місяців цей сайт непомітно датамайнили якісь німці і до оптимізації кешування сторінки сайту у цих німців з усіма картинками вантажилися досить довго. Коли сторінка почала видаватися з кешу миттєво, бот, який не мав ніяких тайм-аутів, теж почав збирати їх миттєво. Тяжко довелося. Випадок особливо складний тому, що якщо ви самі змінили налаштування (включили кешування) і сайт після цього перестав працювати, то хто, на вашу і начальницьку думку, винен? Ось ось. Якщо ви спостерігаєте різке зростання кількості запитів, подивіться, наприклад, у Google Analytics, хто приходив на якісь сторінки.

Тюнінг веб-сервера

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

12. Лімітуємо ресурси (розміри буферів) у nginx

Про що треба пам'ятати насамперед? Кожен ресурс має ліміт. Насамперед це стосується оперативної пам'яті. Тому розміри заголовків і всіх буферів потрібно обмежити адекватними значеннями на клієнта і на сервер цілком. Їх обов'язково потрібно прописати у конфізі nginx.

  • client_header_buffer_size_ _ Задає розмір буфера для читання заголовка запиту клієнта. Якщо рядок запиту або поле заголовка запиту не поміщаються повністю в цей буфер, виділяються буфери більшого розміру, що задаються директивою large_client_header_buffers.
  • large_client_header_buffersЗадає максимальне число та розмір буферів для читання великого заголовка запиту клієнта.
  • client_body_buffer_sizeЗадає розмір буфера для читання запиту клієнта. Якщо тіло запиту більше заданого буфера, все тіло запиту чи лише його частина записується в тимчасовий файл.
  • client_max_body_sizeЗадає максимально допустимий розмір тіла запиту клієнта, що вказується в полі Content-Length заголовка запиту. Якщо розмір більше заданого, клієнту повертається помилка 413 (Request Entity Too Large).

13. Налаштовуємо тайм-аути в nginx

Ресурсом є час. Тому наступним важливим кроком має стати установка всіх тайм-аутів, які знову ж таки дуже важливо акуратно прописати в налаштуваннях nginx.

  • reset_timedout_connection on;Допомагає боротися із сокетами, що зависли у фазі FIN-WAIT.
  • client_header_timeoutЗадає тайм-аут під час читання заголовка запиту клієнта.
  • client_body_timeoutЗадає тайм-аут під час читання тіла запиту клієнта.
  • keepalive_timeoutЗадає тайм-аут, протягом якого keep-alive з'єднання з клієнтом не буде закрито сервером. Багато хто боїться задавати тут великі значення, але ми не впевнені, що цей страх виправданий. Опціонально можна виставити значення тайм-ауту в заголовку HTTP Keep-Alive, але Internet Explorer відомий тим, що ігнорує це значення
  • send_timeoutЗадає тайм-аут під час передачі відповіді клієнту. Якщо після цього клієнт нічого не прийме, з'єднання буде закрито.

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

  1. Виставляємо математично мінімальне значення параметра.
  2. Запускаємо прогін тестів сайту.
  3. Якщо весь функціонал сайту працює без проблем – параметр визначено. Якщо ні – збільшуємо значення параметра та переходимо до п. 2.
  4. Якщо значення параметра перевищило навіть значення за промовчанням, це привід для обговорення в команді розробників.

У ряді випадків ревізія даних параметрів повинна призводити до рефакторингу/редизайну сайту. Наприклад, якщо сайт не працює без трихвилинних AJAX long polling запитів, то потрібно не тайм-аут підвищувати, а long polling замінювати на щось інше - ботнет у 20 тисяч машин, що висить на запитах по три хвилини, легко вб'є дешевий середньостатистичний сервер.

14. Лімітуємо з'єднання в nginx (limit_conn та limit_req)

Nginx також має можливість лімітувати з'єднання, запити і так далі. Якщо ви не впевнені в тому, як поведеться певна частина вашого сайту, то в ідеалі вам потрібно протестувати її, зрозуміти скільки запитів вона витримає, і прописати це в конфігурації nginx. Одна річ, коли сайт лежить і ви здатні прийти та підняти його. І зовсім інша справа - коли він ліг настільки, що сервер пішов у swap. У цьому випадку найчастіше простіше перезавантажитись, ніж дочекатися його тріумфального повернення.

Припустимо, що на сайті є розділи з назвами /download і /search. При цьому ми:

  • не хочемо, щоб боти (або люди з надто ретивими рекурсивними download-менеджерами) забили нам таблицю TCP-з'єднань своїми закачуваннями;
  • не хочемо, щоб боти (або залітні краулери пошукових систем) вичерпали обчислювальні ресурси СУБД безліччю пошукових запитів.

Для цього пригодиться конфігурація такого виду:

Http ( limit_conn_zone $binary_remote_addr zone=download_c:10m; limit_req_zone $binary_remote_addr zone=search_r:10m \ rate=1r/s; server ( location /download/ ( limit_conn download_c 1; # Інша конфігурація search_r burst = 5; # Інша конфігурація location ) ) )

Зазвичай має пряме значення встановити обмеження limit_conn і limit_req для locations, у яких перебувають дорогі до виконання скрипти (у прикладі вказаний пошук, і це неспроста). Обмеження необхідно вибирати, керуючись результатами навантажувального та регресійного тестування, а також здоровим глуздом.

Зверніть увагу на параметр 10m у прикладі. Він означає, що на розрахунок даного ліміту буде виділено словник з буфером 10 мегабайт і ні мегабайтом більше. У цій конфігурації це дозволить відстежувати 320 000 TCP-сесій. Для оптимізації займаної пам'яті як ключ у словнику використовується змінна $binary_remote_addr, яка містить IP-адресу користувача в бінарному вигляді і займає менше пам'яті, ніж звичайна строкова змінна $remote_addr. Потрібно зауважити, що другим параметром до директиви limit_req_zone може бути не тільки IP, але й будь-яка інша змінна nginx, доступна в даному контексті, - наприклад, у випадку, коли ви не хочете забезпечити більш щадний режим для проксі, можна використовувати $binary_remote_addr$http_user_agent або $binary_remote_addr$http_cookie_myc00kiez - але використовувати такі конструкції потрібно з обережністю, оскільки, на відміну від 32-бітного $binary_remote_addr, ці змінні можуть бути істотно більшої довжини і декларовані вами «10m» можуть раптово закінчитися.

Тренди в DDoS

  1. Безперервно зростає потужність атак мережного та транспортного рівня. Потенціал середньостатистичної атаки типу SYN-флуд досяг уже 10 мільйонів пакетів на секунду.
  2. Особливий попит останнім часом мають атаки на DNS. UDP-флуд валідними DNS-запитами зі spoof'ленними IP-адресами джерела - це одна з найпростіших у реалізації та складних у плані протидії атак. Багато великих російських компаній (у тому числі хостингів) відчували останнім часом проблеми в результаті атак на їхні DNS-сервери. Чим далі, тим таких атак буде більше, а їхня потужність зростатиме.
  3. Судячи з зовнішніх ознак, більшість ботнетів управляється не централізовано, а у вигляді пірингової мережі. Це дає зловмисникам можливість синхронізувати дії ботнета в часі - якщо раніше керуючі команди поширювалися по ботнету в 5 тисяч машин за десятки хвилин, то тепер рахунок йде на секунди, а ваш сайт може несподівано випробувати миттєве зростання кількості запитів.
  4. Частка роботів, оснащених повноцінним браузерним двигуном з JavaScript, все ще невелика, але безперервно зростає. Таку атаку складніше відбити вбудованими підручними засобами, тому Саморобкіни повинні з побоюванням стежити за цим трендом.

готуємо ОС

Крім тонкого налаштування nginx, потрібно подбати про налаштування мережевого стека системи. Щонайменше - відразу включити net.ipv4.tcp_syncookies в sysctl, щоб разом захистити себе від атаки SYN-flood невеликого розміру.

15. Тюним ядро

Зверніть увагу на більш просунуті налаштування мережної частини (ядра) знову ж таки за тайм-аутами та пам'яті. Є більш важливі та менш важливі. Насамперед треба звернути увагу на:

  • net.ipv4.tcp_fin_timeoutЧас, який сокет проведе у TCP-фазі FIN-WAIT-2 (очікування FIN/ACK-сегмента).
  • net.ipv4.tcp_(,r,w)memРозмір приймального буфера сокетів TCP. Три значення: мінімум, значення за замовчуванням та максимум.
  • net.core.(r,w)mem_maxТе ж саме для не TCP буферів.

При каналі в 100 Мбіт/с значення за умовчанням якось годяться; але якщо у вас є хоча б гігабіт в секунду, то краще використовувати щось на кшталт:

Sysctl -w net.core.rmem_max=8388608 sysctl -w net.core.wmem_max=8388608 sysctl -w net.ipv4.tcp_rmem="4096 87380 8388608" sysctl4m6 w net.ipv4.tcp_fin_timeout=10

16. Ревізія /proc/sys/net/**

Ідеально вивчити всі параметри /proc/sys/net/**. Потрібно подивитися, наскільки вони відрізняються від дефолтних, і зрозуміти, наскільки вони адекватно виставлені. Linux-розробник (або системний адміністратор), який знається на роботі підвладного йому інтернет-сервісу і бажає його оптимізувати, повинен з цікавістю прочитати документацію всіх параметрів мережевого стека ядра. Можливо, він знайде там специфічні для свого сайту змінні, які допоможуть не лише захистити сайт від зловмисників, а й прискорити його роботу.

Не боятися!

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

Ми багато розповідаємо про атаки на сайт, злом і але тематика DDOS у нас не згадувалася. Сьогодні ми виправляємо це положення та пропонуємо вам повний огляд технологій організації ДДОС атак та відомих інструментів для виконання атак хакерів.


Переглянути листинг доступних інструментів для DDOS атак в KALI ви можете, виконавши команду:

kali > / usr / share / exploitdb / platforms / windows / dos

Ця команда показує базу даних експлоїтів для атаки систем Windows.

Для перегляду доступних інструментів ДДОС атаки Linux вводимо:

/usr/share/exploitdb/platforms/Linux/dos.

2. LOIC

The Low Orbit Ion Cannon (LOIC) Низько-орбітальна іонна гармата. Можливо найпопулярніша програма DDOS. Вона може розсилати масові запити за протоколами ICMP, UDP цим забиваючи канал до сервера жертви. Найвідоміша атака за допомогою LOIC була здійснена групою Anonymous у 2009 році і спрямована проти PayPal, Visa, MasterCard на помсту за відключення WikiLeaks від системи збору пожертвувань.

Атаки, організовані за допомогою LOIC, можуть утилізуватися за допомогою блокування UDP та ICMP пакетів на мережному обладнанні інтернет-провайдерів. Ви можете завантажити саму програму LOIC безкоштовно на сайті. Цей інструмент на базі Windows і робота з ним дуже проста, вказуєте сайти жертви і натискаєте одну кнопку.

2. HOIC

HOIC був розроблений у ході операції Payback by Praetox тією самою командою, що створила LOIC. Ключова відмінність у тому, що HOIC використовує протокол HTTP і з його допомогою посилає потік рандомізованих HTTP GET і POST запитів. Він здатний одночасно вести атаку на 256 доменів. Ви можете завантажити його з .


3. XOIC

XOIC є ще один дуже простий DDOS інструмент. Користувачеві необхідно просто встановити IP адресу жертви, вибрати протокол (HTTP, UDP, ICMP, or TCP), та натиснути на спусковий гачок! Завантажити його можна з

5. HULK

6. UDP Flooder

UDP Flooder відповідає своїй назві - інструмент призначений для відсилання множини UDP пакетів до мети. UDP Flooder часто використовується при атаках DDOS на ігрові сервери, для відключення гравців від сервера. Для завантаження програма доступна на .

7. RUDY

8. ToR's Hammer

ToR's Hammer був створений для роботи через мережу, з метою досягнення великої анонімності атакуючого. Проблема даного інструменту в тому, що мережа TOR є досить повільною і тим самим знижує ефективність ДДОС атаки. Завантажити цю програму DDOS ви можете з сайтів Packet Storm або .

9. Pyloris

Pyloris це ще один ддос інструмент використовуючий новий підхід. Він дозволяє атакуючій створити свій унікальний HTTP запит. Потім програма намагатиметься утримувати TCP з'єднання відкритим за допомогою таких запитів, тим самим зменшувати кількість доступних з'єднань на сервері. Коли ліміт з'єднань сервера добігає кінця, сервер більше не може обслуговувати з'єднання і сайт стає недоступним. Даний інструмент доступний безкоштовно для завантаження з сайту.

10. OWASP Switchblade

Open Web Application Security Project (OWASP) та ProactiveRISK розробили інструмент. Switchblade DoS toolдля тестування WEB додатків на стійкість до ДДОС атак.Він має три режими роботи: 1. SSL Half-Open, 2. HTTP Post, та 3. Slowloris. Завантажити для ознайомлення можна з сайту OWASP.

11. DAVOSET

12. GoldenEye HTTP DoS Tool

13. THC-SSL-DOS

Ця програма для ДДОС (іде в постачанні Kali) і відрізняється від більшості інструментів DDOS тим, що вона не використовує пропускну здатність інтернет каналу і може бути використана з одного комп'ютера. THC-SSL-DOS використовує вразливість протоколу SSL і здатна “покласти” цільовий сервер. Якщо, звичайно, ця вразливість на ньому є. Завантажити програму можна з сайту THC або використовувати KALI Linux де цей інструмент вже встановлений.

14. DDOSIM – Layer 7 DDoS емулятор

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

DDoS-атака (Distributed Denial of Service attack) – комплекс дій, здатний повністю або частково вивести з ладу інтернет-ресурс. Як жертва може виступати практично будь-який інтернет-ресурс, наприклад веб-сайт, ігровий сервер або державний ресурс. На даний момент практично неможлива ситуація, коли хакер поодинці організує DDoS-атаку. Найчастіше зловмисник використовує мережу з комп'ютерів, заражених вірусом. Вірус дозволяє отримувати необхідний та достатній віддалений доступ до зараженого комп'ютера. Мережа таких комп'ютерів називається ботнет. Як правило, в ботнетах є координуючий сервер. Вирішивши реалізувати атаку, зловмисник відправляє команду серверу, що координує, який у свою чергу дає сигнал кожному почати виконання шкідливих мережевих запитів.

Причини DDoS-атак

  • Особиста неприязнь

Ця причина трапляється досить часто. Якийсь час тому незалежний журналіст-дослідник Браян Кребс розкрив діяльність найбільшого сервісу по здійсненню замовлених DDoS-атак — vDOS. Інформація була подана у повних подробицях, що викликало арешт організаторів даного сервісу. У відповідь хакери організували атаку на блог журналіста, потужність якої сягнула 1 Тбіт/с. Ця атака стала найпотужнішою у світі за всі роки.

  • Розвага

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

  • Політичний протест (хактивізм)

Однією з перших атак, що мають соціальний ґрунт, є DDoS-атака, реалізована в 1996 році хакером Omega. Omega був членом хакерської коаліції "Cult of the Dead Crew" (cDc). Термін хактивізм став популярним у ЗМІ у зв'язку з почастішали кібератаками, що мають соціальний ґрунт. Типовими представниками хактивістів є групи Anonymous та LulzSec.

  • Недобросовісна конкуренція

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

  • Вимагання чи шантаж

І тут зловмисник вимагає з потенційної жертви грошову суму за недосконалість атаки. Або за її припинення. Часто жертвами таких атак стають великі організації, наприклад протягом 2014 року були атаковані банк "Тінькофф" та IT-ресурс Хабрахабр, найбільший торрент-трекер Rutracker.org (як це було?).

Наслідки DDoS-атак

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

Атаки, що увійшли до історії Інтернету

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

Пінг смерті (Ping Of Dead).Спосіб атаки, що базується на використанні команди ping. Ця атака набула популярності у 1990-х роках, завдяки недосконалості мережевого обладнання. Суть атаки полягає у відправленні на мережевий вузол одного запиту ping, при цьому в тіло пакету включаються не стандартні 64 байти даних, а 65535 байт. При отриманні такого пакета обладнання переповнювався мережевий стек і що викликало відмову в обслуговуванні.

Атака, що вплинула стабільність роботи Інтернет.У 2013 році компанія Spamhaus стала жертвою атаки потужністю понад 280 Гбіт/с. Найцікавіше те, що для атаки хакери використовували DNS-сервери з мережі інтернет, які, в свою чергу, були дуже завантажені великою кількістю запитів. Тієї доби мільйони користувачів скаржилися на сторінки , що повільно завантажуються , у зв'язку з перевантаженістю служби .

Рекордна атака з трафіком понад 1 Тбіт/с.У 2016 році хакери намагалися атакувати нас пакетною атакою зі швидкістю 360 Mpps та 1 Тбіт/с. Ця цифра стала рекордною за час існування Інтернету. Але й під такою атакою ми встояли і навантаження на мережу лише трохи обмежило вільні ресурси мережного обладнання.

Характеристика атак сьогодні

Виключаючи пікові атаки можна сказати, що потужність атак з кожним роком зростає більш ніж у 3-4 рази. Географія атакуючих з року в рік змінюється лише частково, адже це обумовлено максимальною кількістю комп'ютерів у певній країні. Як видно із квартального звіту за 2016 рік, підготовленого нашими фахівцями, країнами-рекордсменами за кількістю роботів виступають Росія, США та Китай.

Які бувають DDoS-атаки?

На даний момент типи атак можна розділити на 3 класи:

    Атаки, спрямовані на переповнення каналу

До цього типу атак можна віднести, і;

    Атаки, що використовують вразливість стека мережевих протоколів

Найбільш популярними та цікавими атаками цього типу є , / атака,

Чому варто вибрати саме нас? Наше обладнання розташоване в ключових дата-центрах світу і здатне відбивати атаки до 300 Гбіт/с або 360 мільйонів пакетів на секунду. Також у нас організована мережа доставки контенту () та є штат чергових інженерів на випадок нестандартної атаки або позаштатних ситуацій. Тому, вставши під захист до нас, Ви можете бути впевнені у доступності свого ресурсу 24/7. Нам довіряють: REG.RU, Аргументи та Факти, WebMoney, російський радіохолдинг ГПМ та інші корпорації.

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

mob_info