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