Checking your project for vulnerability to Ddos

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

TOOLS FOR FIND VULNERABILITY

Логин Свят

1/4/20232 min read

Основною метою для зловмисників, ddos застосовую для усунення конкуренції в тій чи іншій галузі шляхом повного припинення роботи атакованого сервера за рахунок подачі на нього великої кількості помилкових запитів, з якими не справлятиметься ваш сайт.

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

Хто може зробити такі атаки?

Раніше, у колишніх 90-x можна було сайти класти за допомогою викрутки))) Так-так, саме викрутки, якою можна було затиснути кнопку F5 на клавіатурі. Через часті оновлення сторінки, яка робила часті запити на сервер. Сервер просто не справлявся з таким навантаженням із слабкості. Зараз атаки організовують за допомогою БОТ-мереж. Це сукупність заражених вірусом комп'ютерів, які здатні синхронно виконувати команди, передані з керуючого сервера. Наприклад, якщо бот-сети з тисячі комп'ютерів дати команду відкрити сайт, то цільовому сайті різко зростає навантаження і сайт отримує ДДОС атаку.

Методи DDOS атак

Принаймні існує три різні методи організації ддос атак.

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

2) На основі протоколу сервера - цей вид атаки направлений на конкретні сервіси сервера. І може виконуватися за допомогою TCP, UDP та ICMP. Часто такі атаки називають SYN-флуд, зміст яких у посиланні на веб-сервер великої кількості SYN запитів на які сервер повинен відповісти запитом ASK. Через велику повінь таких запитів, сервер часто не справляється з навантаженням і падає.

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

Інструменти

1) Linux

Як захиститься?

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

Практика підказує, що сайт, який працює на вінді, у разі DDoS приречений. Причина невдачі криється в винтовому мережевому стеку: коли з'єднань стає дуже багато, то сервер неодмінно починає погано відповідати. Я не знаю, чому Windows Server у таких ситуаціях працює настільки огидно, факт є фактом.

2. Відмова від Apache

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

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

Відсіч для DDOS, може стати модуль testcookie-nginx. Ідея проста. Модуль може захистити тільки від ботів які досить тупі, тобто не мають механізмів HTTP cookie і редиректу. Іноді звичайно трапляються більш просунуті-такі можуть використовувати cookies і обробляти редиректи. Testcookie-nginx працює як швидкий фільтр між ботами та бекендом під час DDoS-атаки, що дозволяє відсіювати сміттєві запити.

Перевірка відбувається на такі речі:

- Чи вміє клієнт виконувати HTTP Redirect,

- Чи підтримує JavaScript,

- Чи той він браузер, за який себе видає

Перевірка реалізована за допомогою кукісів з використанням різних методів:

- "Set-Cookie" + редирект за допомогою 301 HTTP Location;

- "Set-Cookie" + редирект за допомогою HTML meta refresh;

- Довільним шаблоном, причому можна використовувати JavaScript.

Щоб уникнути автоматичного парсингу, перевіряюча кукіса може бути зашифрована за допомогою AES-128 і пізніше розшифрована на клієнтській стороні JavaScript. Великий мінус правда, він блокує доступ для багатьох легітимних користувачів (фактично всіх мобільних пристроїв), також до недоліку відносимо всіх роботів, у тому числі Googlebot. Якщо ви плануєте залишити testcookie на постійній основі, переконайтеся, що ви не пропадете з пошукової видачі; створює проблеми користувачам з браузерами Links, w3m та їм подібними; не рятує від роботів, оснащених повноцінним браузерним двигуном з JavaScript. Словом, testcookie_module не є універсальним.

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

Беремо нейронну мережу PyBrain, запихаємо в неї логи та проаналізуємо запити, докладніше тут. В цьому випадку дуже корисно мати access.log до початку DDoS'а, тому що він описує практично 100% легітимних клієнтів, а отже, відмінний dataset для тренування нейронної мережі. Тим більше, очима в лозі боти видно не завжди.

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

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

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

echo $(($(fgrep -c “$(env LC_ALL=C date — date=@$(($(date \ +%s)-60)) +%d/%b/%Y:%H:% M) "$ACCESS_LOG")/60))

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

7. tcpdump

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

8. Розміри буферів у 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).

9. Налаштовуємо тайм-аути в 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 Задає тайм-аут під час передачі відповіді клієнту. Якщо після цього клієнт нічого не прийме, з'єднання буде закрито.

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

- Виставляємо математично мінімальне значення параметра.

- Запускаємо прогін тестів сайту.

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

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

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

- не хочемо, щоб боти (або люди з надто ретивими рекурсивними download-менеджерами) забили нам таблицю TCP-з'єднань своїми закачуваннями;

- не хочемо, щоб боти (або залітні краулери пошукових систем) вичерпали обчислювальні ресурси СУБД безліччю пошукових запитів.

І наостанок Тренди в DDoS

- Безперервно зростає потужність атак мережного та транспортного рівня. Потенціал середньостатистичної атаки типу SYN-флуд досяг.

- Особливий попит останнім часом мають атаки на DNS. UDP-флуд валідними DNS-запитами зі spoof'ленними IP-адресами джерела - це одна з найбільш простих у реалізації і складних у плані протидії атак. Багато великих компаній (у тому числі хостингів) відчували останнім часом проблеми внаслідок атак на їхні DNS-сервери. Чим далі, тим таких атак буде більше, а їхня потужність зростатиме.

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

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

Ресурси на яких краще не світити своїми адресами -http://viewdns.info/

- Качаємо фреймворк metasploit-framework

- Дивимося зміст директорії:

root@slogin:~ cd metasploit-framework/embedded/framework/modules/auxiliary/dos

Це всі можливі інструменти для перевірки на вразливість проекту до ddos

Також існує безліч програм в Exploit Database

2) Windows

- LOIC

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

Як перевірити новинку свій проект на DDOS

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