[Технічний аналіз] Детально та легко зрозуміло: Вступ до атаки мережевої атаки та захисту

DDoS (Distributed Denial of Service) атаки є одними з найпотужніших і найскладніших для захисту, оскільки основна мета DDoS-атак — запобігти наданню звичайних послуг або навіть зникнути з Інтернету призначеною ціллю.

DDoS можна просто поділити на три категорії залежно від способу їх ініціації.

Перша категорія перемагає силоюВеличезні пакети даних рою з усіх куточків Інтернету, блокуючи вхід до IDC, роблячи різні потужні апаратні системи захисту та швидкі й ефективні аварійні процеси марними. Типовими прикладами такого типу атак є ICMP Flood і UDP Flood, які зараз рідкісні.

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

Третя категорія є сумішшю двох вищезазначенихВін не лише використовує недоліки протоколу та системи, а й має великий обсяг трафіку, такий як атака SYN Flood і DNS Query Flood, що є нині основним методом атаки.

У цій статті ми опишемо ці найпоширеніші та репрезентативні методи атаки один за одним і представимо їхні захисні варіанти.

SYN Flood — одна з найкласичніших DDoS-атак в Інтернеті, вперше з'явилася близько 1999 року, і найвідомішою жертвою того часу був Yahoo. Атаки SYN Flood використовують недоліки TCP triple handshake, які можуть зробити цільовий сервер нечутливим і важким для відстеження за невеликі витрати.

Стандартний процес тристороннього рукостискання TCP виглядає так:

• Клієнт надсилає TCP-пакет із прапорцем SYN, SYN синхронізується, а пакет синхронізації вказує порт, який використовує клієнт, і початковий серійний номер TCP-з'єднання.
• Після отримання пакета SYN від клієнта сервер повертає пакет SYN+ACK (тобто підтвердження підтвердження), що означає, що запит клієнта прийнято, а початковий серійний номер TCP автоматично додається на 1.
• Клієнт також повертає серверу повідомлення підтвердження ACK, а серійний номер TCP додається на 1.
  

Після цих трьох кроків встановлюється TCP-з'єднання. Для забезпечення надійної передачі протокол TCP встановив деякі механізми обробки винятків під час трьох рукостискань. На третьому етапі, якщо сервер не отримає остаточний пакет підтвердження ACK від клієнта, сервер залишиться у стані SYN_RECV, додасть IP-адресу клієнта до списку очікування і повторно надішле пакет SYN+ACK на другому кроці. Повторні пости зазвичай виконуються 3-5 разів, а лист очікування опитується раз із інтервалом близько 30 секунд, щоб повторно спробувати всіх клієнтів. З іншого боку, після відправлення пакета SYN+ACK сервер попередньо виділяє ресурси для зберігання інформації про майбутнє TCP-з'єднання, яке зберігається під час очікування повторного спробування. Ще важливіше, якщо ресурси сервера обмежені, SYN_RECV стан, який можна підтримувати, більше не прийматиме нові SYN-пакети після перевищення ліміту, тобто нові TCP-з'єднання будуть відхилені.

SYN Flood використовує наведені вище налаштування протоколу TCP для досягнення мети атаки. Зловмисники маскують велику кількість IP-адрес, щоб надсилати SYN-пакети на сервер, і оскільки підроблені IP-адреси майже неможливі для існування, майже жоден пристрій не повертає відповідь на сервер. Внаслідок цього сервер підтримує величезний список очікування і постійно намагається надіслати пакети SYN+ACK, що споживає багато ресурсів і не може бути випущене. Ще важливіше, що черга SYN_RECV атакованого сервера заповнена шкідливими пакетами, нові SYN-запити більше не приймаються, а легітимні користувачі не можуть виконати три рукостискання для встановлення TCP-з'єднань. Іншими словами, сервер був відмовлений у обслуговуванні через SYN Flood.

Якщо вас цікавить SYN Flood, можете ознайомитися з http://www.icylife.net/yunshu/show.php?id=367, який я написав у 2006 році, пізніше вніс кілька змін, виправив баги та зменшив агресивність, і використовувався виключно для тестування.

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

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

DNS Query Flood — це коли зловмисник маніпулює великою кількістю машин-іменів, щоб запустити велику кількість запитів доменних іменів до цілі. Щоб запобігти фільтрації на основі ACL, необхідно покращити випадковість пакетів. Поширена практика — випадково підробляти IP-адресу джерела, випадково підробляти вихідний порт та інші параметри на рівні UDP. На рівні протоколу DNS ідентифікатор запиту випадково підробляється разом із доменним ім'ям, яке потрібно розв'язати. Окрім запобігання фільтрації, випадково підроблені доменні імена, які потрібно вирішити, також можуть зменшити ймовірність потрапити в кеш DNS і споживати якомога більше ресурсів процесора DNS-сервера.

Щодо коду для DNS Query Flood, я написав код у липні 2011 року для тестування продуктивності сервера, і посилання http://www.icylife.net/yunshu/show.php?id=832. Аналогічно, цей код штучно менш агресивний і призначений лише для тестування.

SYN Flood і DNS Query Flood, описані вище, можна ефективно захистити на цьому етапі, а справжньою проблемою для великих виробників і інтернет-компаній є атаки HTTP Flood. HTTP Flood — це атака на веб-сервіс протоколу сьомого рівня. Його велика шкода проявляється головним чином у трьох аспектах: зручна ініціація, складна фільтрація та далекосяжний вплив.

І SYN Flood, і DNS Query Flood вимагають від зловмисників контролювати велику кількість ботів із root privileges. Збирати велику кількість кореневих привілеїв потребує часу та зусиль, а під час атаки лялькова машина повільно поповнюється через швидку втрату ресурсів зловмисником через аномальний трафік, виявлений адміністратором, що призводить до значного зниження інтенсивності атаки і не може підтримувати її тривалий час. Атаки HTTP Flood відрізняються від того, що зловмисникам не потрібно керувати великою кількістю ботів, а натомість використовують порт-сканери для пошуку анонімних HTTP-проксі або SOCKS проксі в Інтернеті, через які зловмисник ініціює HTTP-запити до цілі атаки. Анонімні проксі — це досить багатий ресурс, і отримати їх за кілька днів нескладно, тому атаки легко ініціювати і вони можуть тривати довго.

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

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

Цікаво, що HTTP Flood також має історичне прізвисько під назвою CC attack. CC — це скорочення від Challenge Collapsar, пристрою захисту від DDoS від відомої китайської компанії з безпеки. Судячи з поточної ситуації, не лише Collapsar, а й усе обладнання для захисту апаратного забезпечення досі піддається виклику, і ризик не зник.

Коли йдеться про атаки, перша реакція — це величезний трафік і величезні пакети. Але є атака, яка робить протилежне — відома своєю повільною повільністю, коли деякі цілі атаки гине, не знаючи, як вони загинуть, це атака повільного з'єднання, найрепрезентативніша — це Slowloris, винайдений rsnake.

Протокол HTTP передбачає, що HTTP-запити закінчуються на \r\n\r\n, що означає, що клієнт завершив надсилання, а сервер почав обробку. То що буде, якщо ти ніколи не надішлиш \r\n\r\n? Slowloris використовує це на свою користь у DDoS-атаках. Зловмисник встановлює З'єднання на Keep-Alive у заголовку HTTP-запиту, просить веб-сервер зберегти TCP-з'єднання не роз'єднаним, а потім повільно кожні кілька хвилин надсилає формат ключ-значення серверу, наприклад a:b\r\n, змушуючи сервер думати, що HTTP-заголовок не отримано, і чекає. Якщо зловмисник використовує багатопотокність або маріонетку для цього, веб-контейнер сервера швидко буде перевантажений зловмисником і більше не прийматиме нові запити.

Незабаром почали з'являтися різні варіанти Slowloris. Наприклад, метод POST передає дані на веб-сервер, заповнює великий обсяг довжини контенту, але повільний байт за байтом POST реальний вміст даних тощо. Щодо атаки Slowloris, rsnake також дає тестовий код, див. http://ha.ckers.org/slowloris/slowloris.pl.

Вищезазначене вводить кілька базових методів атаки, будь-який із яких може бути використаний для атаки на мережу та навіть для знищення гігантських сайтів, таких як Alibaba, Baidu та Tencent. Але це ще не все: різні рівні атаки можуть запускати зовсім різні DDoS-атаки, і їх використання — це те саме.

Просунуті атакувальники ніколи не використовують один вектор для атаки, а гнучко комбінують їх залежно від цілі. Звичайний SYN Flood легко відфільтрувати пристроями для очищення трафіку за допомогою зворотного виявлення, SYN-cookes та інших технічних засобів, але якщо пакети SYN+ACK змішуються в SYN Flood, щоб кожен підроблений SYN-пакет мав відповідний підроблений клієнтський підтверджувальний пакет, відповідний тут стосується IP-адреси джерела, порту джерела, IP призначення, порту призначення, порту призначення, розміру вікна TCP, TTL тощо, які відповідають характеристикам одного й того ж хоста та одного й того ж потоку TCP. Тиск на продуктивність зворотного виявлення та SYN-cook-файлів обладнання для очищення потоків значно зросте. Насправді пакети даних SYN та різні інші біти прапорців мають спеціальні ефекти атаки, які тут не представлені. Існують також унікальні техніки для DNS Query Flood.

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

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

По-друге, атаки на DNS не повинні зосереджуватися лише на UDP-портах, які також є стандартними сервісами згідно з протоколом DNS. У разі атаки одночасно можуть здійснюватися як UDP, так і TCP-атаки.

Мета HTTP Flood — зламати кеш на фронтенді та безпосередньо дістатися безпосередньо до веб-сервера через налаштування полів у HTTP-заголовку. Крім того, HTTP Flood дуже важливий для вибору цілей, і звичайні зловмисники обирають сторінки, які потребують великої кількості запитів до даних, наприклад, пошук як ціль атаки, що дуже правильно і може споживати якомога більше ресурсів сервера. Але цю атаку легко ідентифікувати за допомогою очищення обладнання за допомогою ідентифікації людини-машина, тож як вирішити цю проблему? Все дуже просто: спробуйте обрати сторінки, до яких звичайні користувачі також мають доступ через додаток, загалом різні веб-API. Звичайні користувачі та шкідливий трафік надходять із APP, і різниця між людиною та машиною дуже мала, і важко розрізнити базову інтеграцію.

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

Попередні описи — це технічні покращення атаки. З людського боку є й інші способи. Якщо SYN Flood надсилає велику кількість пакетів і супроводжується повільними з'єднаннями Slowloris, скільки людей дізнаються секрет? Навіть якщо сервер виходить з ладу, залишаться лише SYN-атаки, які намагаються посилити очищення TCP-шарів і ігнорують поведінку прикладного рівня. Усі види атак можуть працювати разом для досягнення максимального ефекту. Вибір часу атаки також є ключовим моментом, наприклад, вибір технічного персоналу під час обіду, коли технічний персонал застряг на дорозі після роботи або коли немає сигналу на бездротовій карті в метро, а також коли цільове підприємство проводить масштабний захід і трафік зростає на трафіку.

Це чиста атака, тому код чи детальне пояснення не надається.

Попередні методи атаки більш-менш вимагали деяких ботів, навіть HTTP Flood вимагав пошуку великої кількості анонімних проксі. Якщо відбувається атака, достатньо дати кілька інструкцій, і машина автоматично підніметься, щоб виконати її, що є ідеальним рішенням. Ця атака вже відбулася, і це з P2P-мереж.

Як усім відомо, P2P-користувачі та трафік в Інтернеті — це надзвичайно велика кількість. Якщо всі вони йдуть у визначене місце для завантаження даних і підключення тисяч реальних IP-адрес, жоден пристрій не зможе це підтримувати. Візьмемо, наприклад, завантаження BT: підробка торрентів деяких популярних відео та публікація їх у пошукових системах достатньо, щоб обдурити багатьох користувачів і трафік, але це лише базова атака.

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

Ось і все, що є у знайомстві з DDoS-атаками, і я не хочу йти далі — достатньо розуміти, що достатньо захисту.

Загалом, DDoS-атаки можуть бути спритними та граціозними. Краса застосування полягає в єдності розуму.