|
|
| (Не показані 6 проміжних версій ще одного користувача) |
| Рядок 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). Ресурсоємні скрипти можна захистити від ботів за допомогою затримок, кнопок "Натискуй мене", виставляння кукисів і інших прийомів, направлених на перевірку "людяності".
| |
| − |
| |
| − | == Застосування кластера для вирішення проблеми атак на відмову ==
| |
| − | Рішення прийшло само-собою - у нас в том-же ДЦ що і веб-сервер-сервер коштують ще і файлові сервера, в яких дуже навантажені гвинти, але проц і пам'ять практично гуляє. Серед таких серверів знайшовся двохядерний оптерон з 4Гб оператіви, вирішили сайт перенести туди. Щоб не міняти запису в ДНС, не юзати забиті канали, які служать для роздачі файлів і т.д. ми зробили наступне: оптерон був налагоджений для праці backend сервером, на основному сервері в конфіге nginx прописали для домена fileshare.in.ua цей backend, а останні сайти (їх на тому сервері всього біля десятка, окрім файлшари, сумарною відвідуваністю порядку 15К хостів і 70К хітів в добу) залишити як є.
| |
| − | <br> Рішення допомогло на якийсь час, сайт став нормально працювати і інші сайти теж пожвавіше стали відгукуватися. Десь через годин 6 після такого ось нововведення атака посилилася у декілька разів. Оптерон не витримав, файлшара знову просіла, проте останні сайти, які працювали не на оптероне, а на основному веб-сервері-сервері відмінно відгукувалися.
| |
| − | <br> Цього разу я вирішив що файлшара важливіше і зробив кластер: файлшара працювала на обох серверах, балансування робив nginx, а останні сайти крутилися на основному. При чому для файлшари веб-сервер-сервер був прописаний як резервний (тобто на основному сервері скрипти файлшари виконувалися лише якщо оптерон помер), і, щоб довго не чекати, я встановив параметр чекання відповіді від backend 2 секунди. Все налагодилося, отперон не завжди витримував, був постійно завантажений на 100%, але другий сервер підхоплював сайт якщо оптерон падав і все більш-менш працювало.
| |
| − | <br> Мабуть зловмисники стежили за розвитком подій тому, що буквально за годину, після того, як я розвів навантаження з файлшари на 2 сервери на атаку були кинута велика частина ресурсів. Вхідний трафік підріс в 3 рази в порівнянні із звичайним (далі йому просто вже нікуди зростати із-за обмежень провайдера), сайт впав і не піднімався, завантаження сервера (будь-якого) було на 100% вже відразу після рестарту апача, a на основному сервері підскочив до 60%, все було в ступорі небуло жодних шансів піднятися. Атака йшла не лише на файлшару але і останні сайти, навіть по ssh зайти було проблемою (не дивлячись на підвищений пріоритет) і я загасив nginx, щоб мати можливість щось зробити. Мабуть по маштабам атака була порівнянна з тими, від яких лежав 0day і progs не так давно. Не знаю вже кому ми так жити заважаємо, але думати про цей небуло часу, через 20 хвилин атака була повністю відбита;). Насамперед я додав в кластер ще 3 машини. По-друге залив на всі машини по nfs ісходники сайтів, подрехтовал конфіги апача і php і перевів сесію на mysql. Тепер всі сервера могли працювати як backend’и. Після цього я поставив на все сервера APC (php-акселератор), перевірив працездатність сайтів на кожному з серверів, прописав їх в конфіге nginx і знову його запустив. Атака, яка легко посадила 2 сервери, цього разу спасувала. Вхідний трафік не зменшився, атака йшла до ранку, але всім сайтам на хостингу це вже було по барабану. Навіть ab в 200 потоків, який я запустив паралельно з атакою нічого не змінив. Я боявся за базу - вона хоч і на потужній машині, але на одній, проте, мабуть за рахунок агресивного кешированія, база впоралася. А на веб-сервері-сервері опустився до 3, на сервері з'явився idle і тут-же взявся за справу антидос-скрипт. Запити валили шквалом, проте антидос знаходила час їх аналізувати і забанити найактивніших, тим самим понизивши навантаження десь на 40%. Підсумок: під час атаки сервера були завантажені не більше ніж на 60% (багато ресурсів віджирала роздача файлів), всі сайти (навіть на Вордпресі) відгукувалися швидко, атака йшла лісом. Сьогодні півдня довелося витратити на пошук багов, які з'явилися у зв'язку з такою зміною архітектури, проте в цілому результат хороший. Сподіватимемося, що сайт тепер захищений від ДДОС повністю. Чому повністю? тому що в ua-ix не буде достатньої кількості комп'ютерів, щоб його покласти, а ширина вхідного світу така, що сама стримає великий наплив ботів. Максимум, чого можна буде добитися, так це того, що сайт не буде доступний зі світу, проте і для цього треба буде сильно постаратися.
| |
| − | <br> Принаймні це мій оптимістичний прогноз, думаю, що організатори атак не зупиняться на досягнутому і сайт ще не раз перевірять на міцність (та в і нас є ще гуляючі сервера+можно зібрати mysql кластер), проте те що якась кількість грошей вони вже спустили в унітаз (10 годин безрезультатної досить масованої атаки), це радує.
| |
| − |
| |
| − | == UDP та торенти ==
| |
| − | Очима фахівця, суть того, що відбувається така: з кінця січня (стабільна µTorrent версія 2.0 з µTP вийшла якраз 25 січня, офіційно доступна з 3 лютого) в статистичних звітах операторів зв'язку виявлено безперервне зростання UDP-трафіку і одночасне зменшення середньої величини пакетів, які істотно збільшували навантаження на мережеве устаткування. Спостереження показали, що чим сильніше завантажений канал клієнта, тим дрібніші пакети, довша черга і вище навантаження на роутерах.
| |
| − | <br> У всіх випадках причиною що відбувається був названий МікроТоррент (µTorrent), з версії 1.8.1 що почав освоювати протокол обміну µTP (Micro Transport Protocol, до речі, що так не дістав схвалення IETF). І провайдерам просто повезло, що через низку обставин клієнти до версії µTorrent v2.0 не оновилися одномоментно. (У ній, за умовчанням, udp-завантаження стартує першим, а якщо не вийде, то лише тоді – по TCP). Інакше наростання проблем в мережі замість плавного носило б миттєвий характер і, можливо, відразу «повалило» до третини вітчизняних провайдерів. Останні могли б трактувати поведінку як ddos-атаки на провайдерське устаткування з відповідним недемократичним «закручуванням гайок» в аварійному порядку.
| |
| − | <br> Остаточний аналіз ситуації був ускладнений тим, що у відкритому доступі повного опису протоколу, який став займати значну долю UDP трафіку, немає: цей опис застарілий і не дає повної картини, а стаття у Вікіпедії досить поверхневий описує характер проблем.
| |
| − | <br> Реінженеринг дозволив не лише переконатися, що згідно з алгоритмами µTP в процесі обміну зменшується довжина пакету із зростанням завантаження каналу, але і передбачити, що для підтвердження використовуються udp-пакети квитування (з функцією, типа ACK) розміром в 2 десятки байт.
| |
| − | <br> Логіка розробників протоколу і алгоритмів µTorrent може виправдовуватися тим, що вони не вважають розумними чекати TCP-ACK від доставки пакету. Адже tcp-потік формується послідовно, і якщо в стеку, наприклад, вже знаходиться 50 пакетів, але немає два, то передачу вони не здійснюватимуть, поки втрачені не прийдуть. А ось пірінгове застосування за своєю суттю якраз і не критично до строгої послідовності у вступі інформації, адже воно запрошує і збирає файли по шматочках.
| |
| − | <br> І що виходить насправді? Додаток, відповідно, зменшує розмір пакету, тому що у нього зростає час між відсиланням пакету і приходом квитанції. Але зростає-то воно тому, що пакети стоять в переповненій черзі на «шейпері». І замість того що б спочатку зменшити кількість посланих, алгоритм ... далі зменшує їх розмір. В результаті, при даному агресивному алгоритмі використання udp-протоколу МікроТоррентом результуючий трафік (ємкість каналу) на клієнтові практично не міняється. Тобто вихідна мрія творців даного ПЗ – завантажити канал «під зав'язку» від цього ближче не стає. Міняється лише структура трафіку – з'являється більше дрібних пакетів, що для провайдера насправді небезпечніше чим зростання трафіку.
| |
| − | <br> Давайте порахуємо: якщо в ходу пакети по 150 байт, то при швидкості 100 мегабіт операторові потрібно буде обробити в секунду ... 87 тисяч пакетів! Не всякий провайдер зможе оперативно відреагувати на виниклу проблему: замінити ті ж сервери доступа/роутери на високопродуктивних не всім по кишені. В результаті, багато провайдерів вимушено було для своїх клієнтів ввести на додаток до обмежень по Mbps, ще і по pps.
| |
| − | <br> Але, навіть якщо провайдерське устаткування зможе впоратися з цим алогічним алгоритмом обміну, замість вичавлених з провайдера декількох зайвих відсотків смуги, клієнт ризикує втратити значно більше завдяки збільшеному пакетному навантаженню . на свій домашній шлюз і, можливо навіть – на свій не дуже сучасний ПК! А що він зробить, побачивши, що швидкість закачування знизилася? Правильно, без тіні сумніву звернеться в технічну підтримку і звалить свої проблеми на провайдера.
| |
| − | <br> Оскільки локальна ситуація моделюється досить нескладно, я провів невеликий експеримент з наявним adsl-wifi-шлюзом, який можу запропонувати просунутим користувачам µTorrenta. Особливо вражаючим тест виглядатиме на древніх роутерах з Wifi. У моєму циклі випробувань пристрій почав «притормажувати» приблизно вже при 30-40 активних сесіях «звичайного» закачування, але при агресивній роботі по UDP (всього 5 роздач) втратило відразу майже третина смуги. Поза сумнівом, причина – в перевищення можливої кількості коректно оброблюваних пакетів за одиницю часу.
| |
| − |
| |
| − | == Універсальні поради ==
| |
| − | Щоб не попасти в безвихідь під час обвалення DDoS-штурму на системи, необхідно ретельно підготувати їх до такої ситуації:
| |
| − | <br> 1. Всі сервера, що мають прямий доступ в зовнішню мережу, мають бути підготовлені до простої і швидкої віддаленої. Великим плюсом буде наявність другого, адміністративного, мережевого інтерфейсу, через який можна дістати доступ до сервера в разі затурканості основного каналу.
| |
| − | <br> 2. ПЗ, використовуване на сервері, завжди повинно знаходитися в актуальному стані. Всі дірки - пропатчені, оновлення встановлені. Це захистить тебе від DoS-атак, експлуатуючих баги в сервісах.
| |
| − | <br> 3. Всі слухаючі мережеві сервіси, призначені для адміністративного використання, мають бути заховані брандмаузером від всіх, хто не повинен мати до них доступу. Тоді той, що атакує не зможе використовувати їх для проведення DoS-атаки або брутфорса.
| |
| − | <br> 4. На підходах до сервера (найближчому маршрутизаторі) має бути встановлена система аналізу трафіку (Netflow в допомогу), яка дозволить своєчасно дізнатися про атаку, що починається, і вчасно прийняти заходи по її запобіганню.
| |
| − | Додай в /etc/sysctl.conf наступні рядки:
| |
| − | <br># vi /etc/sysctl.conf
| |
| − | <br># Захист від спуфінга
| |
| − | <br>net.ipv4.conf.default.rp_filter = 1
| |
| − | <br># Перевіряти TCP-з’єднання кожну хвилину. Якщо на іншій стороні - легальна машина, вона зразу відповість. Значення по замовчуванні - 2 години.
| |
| − | <br>net.ipv4.tcp_keepalive_time = 60
| |
| − | <br># Повторити попитку через десять секунд
| |
| − | net.ipv4.tcp_keepalive_intvl = 10
| |
| − | <br># Кількість повірок перед закриттям з’єднання
| |
| − | <br>net.ipv4.tcp_keepalive_probes = 5
| |
| − | <br> Слід зазначити, що всі прийоми, приведені у минулому і цьому розділах, направлені на зниження ефективності DDoS-атак, що ставлять своєю метою витратити ресурси машини. Від флуда, що забиває канал сміттям, захиститися практично неможливо, і єдино правильний, але не завжди здійсненний спосіб боротьби полягає в тому, щоб "позбавити атаку сенсу". Якщо ти отримаєш в своє розпорядження дійсно широкий канал, який легко пропустить трафік невеликого ботнета, вважай, що від 90% атак твій сервер захищений. Є витонченіший спосіб захисту. Він заснований на організації розподіленої обчислювальної мережі, що включає безліч дублюючих серверів, які підключені до різних магістральних каналів. Коли обчислювальні потужності або пропускна спроможність каналу закінчуються, все нові клієнти перенаправляються на інший сервер (або ж поступово "розмазуються" по серверах за принципом round-robin). Це неймовірно дорога, але дуже стійка структура, завалити яку практично нереально.
| |
| − | <br> Інше більш-менш ефективне рішення полягає в покупці дорогих хардварних систем Cisco Traffic Anomaly Detector і Cisco Guard. Працюючи у в'язці, вони можуть подавити атаку, що починається, але, як і більшість інших рішень, заснованих на вченні і аналізі станів, дають збої. Тому слід гарненько подумати перед тим, як вибивати з начальства десятки тисячі доларів на такий захист.
| |
