|
|
| (Не показані 9 проміжних версій ще одного користувача) |
| Рядок 1: |
Рядок 1: |
| − | == Анатомія DoS-атак ==
| |
| − | DoS-атаки поділяються на локальні і віддаленні. До локальних відносяться різні експлойти, форк-бомби і програми, що відкривають по мільйону файлів або запускають якийсь циклічний алгоритм, який зжирає пам'ять і процесорні ресурси. На всьому цьому ми зупинятися не будемо. А ось віддалені DoS-атаки розглянемо детальніше. Вони діляться на два види:
| |
| − | <br> 1.Віддалена експлуатація помилок в ПЗ з метою привести його в неробочий стан.
| |
| − | <br> 2.Flood - посилка на адресу жертви величезної кількості безглуздих (рідше – осмислених) пакетів. Метою флуда може бути канал зв'язку або ресурси машини. У першому випадку потік пакетів займає весь пропускний канал і не дає машині, що атакується, можливість обробляти легальні запити. У другому - ресурси машини захоплюються за допомогою багатократного і дуже частого звернення до якого-небудь сервісу, що виконує складну, ресурсоємну операцію. Це може бути, наприклад, тривале звернення до одного з активних компонентів (скрипту) web-сервера. Сервер витрачає всі ресурси машини на обробку запитів що атакує, а користувачам доводиться чекати.
| |
| − | <br> У традиційного виконання (один атакуючий - одна жертва) зараз залишається ефективним лише перший вигляд атак. Класичний флуд даремний. Просто тому що при сьогоднішній ширині каналу серверів, рівні обчислювальних потужностей і повсюдному використанні різних анті-DoS прийомів в ПЗ (наприклад, затримки при багатократному виконанні одних і тих же дій одним клієнтом), що атакує перетворюється на докучливого комара, не здатного завдати якого б то не було збитку. Але якщо цих комарів наберуться сотні, тисячі або навіть сотні тисяч, вони легко покладуть сервер на лопатки. Натовп - страшна сила не лише в житті, але і на комп'ютерному світі. Розподілена атака типа "відмова в обслуговуванні" (DDoS), зазвичай здійснювана за допомогою безлічі зомбіфіціруваних хостів, може відрізувати від зовнішнього світу навіть найстійкіший сервер, і єдиний ефективний захист - організація розподіленої системи серверів (але це по кишені далеко не всім).
| |
| | | | |
| − |
| |
| − |
| |
| − | == Методи боротьби ==
| |
| − | Небезпека більшості DDoS-атак – в їх абсолютній прозорості і "нормальності". Адже якщо помилка в ПЗ завжди може бути виправлена, то повне зжирання ресурсів - явище майже буденне. З ними стикаються багато адміністраторів, коли ресурсів машини (ширина каналу) стає недостатньо, або web-сайт піддається слешдот-ефекту. І якщо різати трафік і ресурси для всіх підряд, то врятуєшся від DDoS, но втратиш велику половину клієнтів.
| |
| − | <br> Виходу з цієї ситуації фактично немає, проте наслідки DDoS-атак і їх ефективність можна істотно понизити за рахунок правильного налаштування маршрутизатора, брандмаузера і постійного аналізу аномалій в мережевому трафіку. У наступній частині статті ми послідовно розглянемо:
| |
| − | <br> 1. способи розпізнавання DDoS-атаки, що починається;
| |
| − | <br> 2. методи боротьби з конкретними типами DDoS-атак;
| |
| − | <br> 3. універсальні поради, які допоможуть підготуватися до DoS-атаки і понизити її ефективність.
| |
| − | <br> В самому кінці буде дана відповідь на питання: що робити, коли почалася DDoS-атака.
| |
| − |
| |
| − |
| |
| − | == Боротьба з flood-атаками ==
| |
| − | Отже, існує два типи DoS/DDoS-атак, і найбільш поширена з них заснована на ідеї флуда, тобто завалення жертви величезною кількістю пакетів. Флуд буває різним: ICMP-флуд, SYN-флуд, UDP-флуд і HTTP-флуд. Сучасні DoS-боти можуть використовувати всі ці види атак одночасно, тому слід заздалегідь поклопотатися про адекватний захист від кожної з них.
| |
| − |
| |
| − | '''1. Icmp-флуд.'''
| |
| − | <br> Дуже примітивний метод забивання смуги пропускання і створення навантажень на мережевий стек через монотонну посилку запитів ICMP ECHO (пінг). Легко виявляється за допомогою аналізу потоків трафіку в обидві сторони: під час атаки типа Icmp-флуд вони практично ідентичні. Майже безболісний спосіб абсолютного захисту заснований на відключенні відповідей на запити ICMP ECHO:
| |
| − | <br>''#sysctl net.ipv4.icmp_echo_ignore_all=1''
| |
| − | <br>Або за допомогою брандмаузера:
| |
| − | <br>''#iptables -A INPUT -p icmp -j DROP --icmp-type 8''
| |
| − |
| |
| − | <br> '''2. SYN-флуд.'''
| |
| − | <br> Один з поширених способів не лише забити канал зв'язку, але і ввести мережевий стек операційної системи в такий стан, коли він вже не зможе приймати нові запити на підключення. Заснований на спробі ініціалізації великого числа одночасних TCP-з'єднань через посилку SYN-пакету з неіснуючою зворотньою адресою. Після декількох спроб відіслати у відповідь ACK-пакет на недоступну адресу більшість операційок ставлять невстановлене з'єднання в чергу. І лише після n-ої спроби закривають з'єднання. Оскільки потік ACK-пакетів дуже великий, незабаром черга виявляється заповненою, і ядро дає відмову на спроби відкрити нове з'єднання. Найбільш розумні DoS-боти ще і аналізують систему перед початком атаки, щоб слати запити лише на відкриті життєво важливі порти. Ідентифікувати таку атаку просто: досить спробувати підключитися до одного з сервісів. Оборонні заходи зазвичай включають:
| |
| − | <br>Збільшення черги "напіввідкритих" tcp-з'єднань:
| |
| − | <br>'' # sysctl -w net.ipv4.tcp_max_syn_backlog=1024''
| |
| − | <br>Зменшення часу утримання "напіввідкритих" з'єднань:
| |
| − | <br>''# sysctl -w net.ipv4.tcp_synack_retries=1 ''
| |
| − | <br>Включення механізму TCP syncookies:
| |
| − | <br>''# sysctl -w net.ipv4.tcp_syncookies=1''
| |
| − | <br>Обмеження максимального числа "напіввідкритих" з'єднань з одного IP до конкретного порту:
| |
| − | <br>''# iptables -i INPUT -p tcp --syn --dport 80 -m iplimit --iplimit-above 10 -j DROP''
| |
| − |
| |
| − | '''3. UDP-флуд.'''
| |
| − | <br> Типовий метод захаращення смуги пропускання. Заснований на безконечній посилці udp-пакетів на порти різних udp-сервісів. Легко усувається за рахунок відрізання таких сервісів від зовнішнього світу і установки ліміту на кількість з'єднань в одиницю часу до dns-сервера на стороні шлюзу:
| |
| − | <br>''# iptables -i INPUT -p udp --dport 53 -j DROP -m iplimit --iplimit-above 1''
| |
| − |
| |
| − | <br> '''4. HTTP-флуд.'''
| |
| − | <br> Один з найпоширеніших на сьогоднішній день способів флуда. Заснований на безконечній посилці http-повідомлень GET на 80-й порт з метою завантажити web-сервер настільки, щоб він виявився не в змозі обробляти всі останні запити. Часто метою флуда стає не корінь web-сервера, а один із скриптів, що виконують ресурсоємні завдання або що працює з базою даних. У будь-якому випадку, індикатором атаки, що почалася, служитиме аномально швидке зростання лігв web-сервера.
| |
| − | <br> Методи боротьби з Http-флудом включають тюнинг web-сервера і бази даних з метою понизити ефект від атаки, а також відсіювання DoS-ботів за допомогою різних прийомів. По-перше, слід збільшити максимальне число з’єднань до бази даних одночасно. По-друге, встановити перед web-сервером Apache легкий і продуктивний nginx – він кешуватиме запити і видавати статику. Це рішення із списку "Must have", яке не лише понизить ефект DoS-атак, але і дозволить серверу витримати величезні нагрузки. Невеликий приклад:
| |
| − | <br>''# vi /etc/nginx/nginx.conf
| |
| − | <br># Збільшує максимальну кількість використовуваних файлів worker_rlimit_nofile 80000;
| |
| − | <br>events {
| |
| − | <br># Збільшує максимальну кількість з’єднань
| |
| − | <br>worker_connections 65536;
| |
| − | <br># Використовувати ефективний метод метод epoll для обробки з’єднань
| |
| − | <br>use epoll;
| |
| − | <br>}
| |
| − | <br>http {
| |
| − | <br>gzip off;
| |
| − | <br># Відключаеєм таймаут на закриття keep-alive з’єднань
| |
| − | <br>keepalive_timeout 0;
| |
| − | <br># Не віддавати версію nginx в заголовку відповіді
| |
| − | <br>server_tokens off;
| |
| − | <br># Зкидати з’єднання по таймауту
| |
| − | <br>reset_timedout_connection on;
| |
| − | <br>}
| |
| − | <br># Стандартні настройки для роботи в якості проксі
| |
| − | <br>server {
| |
| − | <br>listen 111.111.111.111 default deferred;
| |
| − | <br>server_name host.com www.host.com;
| |
| − | <br>log_format IP $remote_addr;
| |
| − | <br>location / {
| |
| − | <br>proxy_pass http://127.0.0.1/;
| |
| − | <br>}
| |
| − | <br>location ~* \.(jpeg|jpg|gif|png|css|js|pdf|txt|tar)$ {
| |
| − | <br>root /home/www/host.com/httpdocs;
| |
| − | <br>}
| |
| − | <br>}''
| |
| − | <br>У разі потреби можна задіювати nginx-модуль ngx_http_limit_req_module, що обмежує кількість одночасних підключень з однієї адреси <br>(http://sysoev.ru/nginx/docs/http/ngx_http_limit_req_module.html). Ресурсоємні скрипти можна захистити від ботів за допомогою затримок, кнопок "Натискуй мене", виставляння кукисів і інших прийомів, направлених на перевірку "людяності".
| |
