Як увімкнути захист DDoS?

85

DDoS (розподілені атаки на відмову в обслуговуванні) зазвичай блокуються на рівні сервера, чи не так?

Чи є спосіб заблокувати його на рівні PHP або, принаймні, зменшити?

Якщо ні, то який найшвидший і найпоширеніший спосіб зупинити DDoS-атаки?

php  security  ddos  denial-of-service 
— кодерама
джерело
Оскільки у нас немає нічого кращого, ось список модулів Apache, які потенційно можуть допомогти. Однак це здається не надто багатим, і два проекти з чотирьох (як їх шукають за „dos”), здається, вказують нікуди.
— Аудріус Мескаускас
Щось на зразок цього? mod-antiloris.sourceforge.net
— K-Gun
DDOS є успішним, коли система більше не може обробляти всі запити, які йому накидає атака. Якщо ви додаєте код у свою програму, яка перевіряє кожен запит на "Чи є це DDOS-атака", тоді цей код насправді завдає більше шкоди, ніж користі, оскільки для кожного запиту потрібно лише трохи більше ресурсів. Це могло б працювати лише в дуже обмеженому середовищі, де анонімний запит у будь-якому випадку не дозволений.
— Hugo Delsing

Відповіді:

188

DDOS - це сімейство атак, які переповнюють ключові системи в центрі обробки даних, включаючи:

  • Мережеве підключення центру хостингу до Інтернету
  • Внутрішня мережа хостинг-центру та маршрутизатори
  • Ваш брандмауер та балансири навантаження
  • Ваші веб-сервери, сервери додатків та бази даних.

Перш ніж почати будувати захист від DDOS, подумайте, яке найгірше значення ризику. Для некритичної безкоштовної послуги для невеликої громади загальне значення ризику може становити арахіс. Для платної, орієнтованої на публіку, критично важливої ​​системи для усталеного багатомільярдного бізнесу цінність може бути вартістю компанії. В останньому випадку вам не слід використовувати StackExchange :) У будь-якому випадку для захисту від DDOS вам потрібен поглиблений захист:

  1. Співпрацюйте з вашим хостинговим центром, щоб зрозуміти послуги, які вони пропонують, включаючи фільтрацію IP та портів при їх мережевих підключеннях до Інтернету та службах брандмауера, які вони пропонують. Це критично: хостингова компанія витягує з Інтернету багато веб-сайтів, оскільки хостинг-компанія займається проблемами в центрі обробки даних, спричиненими DDOS для одного клієнта. Крім того, під час DDOS-атаки ви будете дуже тісно співпрацювати зі співробітниками хостинг-центру, тому знайте їх екстрені номери та підтримуйте з ними добрі стосунки :) Вони повинні мати можливість блокувати цілі міжнародні регіони, повністю блокувати певні служби чи мережі. протоколи та інші захисні заходи широкого спектра, або альтернативно дозволяють лише ІР з білого списку (залежно від вашої бізнес-моделі)
  2. Перебуваючи в хостинговому центрі - використовуйте Мережу доставки вмісту, щоб розповсюджувати (в основному статичні) послуги, близькі до ваших кінцевих користувачів, і приховувати свої справжні сервери від архітекторів DDOS. Повний CDN занадто великий, щоб DDOS міг видалити всі вузли у всіх країнах; якщо DDOS орієнтований на одну країну, принаймні інші користувачі все ще в порядку.

  3. Постійно оновлюйте всі свої системи та програмні пакети останніми виправленнями безпеки - і я маю на увазі всі:

    • Керовані комутатори - так, іноді їх потрібно оновити
    • Маршрутизатори
    • Брандмауери
    • Балансери навантаження
    • Операційні системи
    • Веб-сервери
    • Мови та їх бібліотеки

  4. Переконайтеся , що у вас є хороший брандмауер або безпеки приладу встановити і регулярно переглядатися кваліфікованим експертом безпеки . Чіткі правила щодо брандмауера є хорошим захистом від багатьох простих атак. Також корисно мати можливість керувати пропускною здатністю, доступною для кожної відкритої служби.

  5. Створіть хороші інструменти моніторингу мережі - це може допомогти вам зрозуміти:

    • Що ви піддані нападу, а не просто під великим навантаженням
    • Звідки відбувається атака (яка може включати країни, з якими ти зазвичай не ведеш бізнес) та
    • Що таке атака насправді (порти, служби, протоколи, IP-адреси та вміст пакетів)

  6. Атака може бути просто інтенсивним використанням законних служб веб-сайтів (наприклад, зачіпати "легальні" URI, що виконують запити або вставляти / оновлювати / видаляти дані) - тисячі або мільйони запитів, що надходять від десятків до мільйонів різних IP-адрес, приведуть сайт до його коліна. Як варіант, деякі послуги можуть бути настільки дорогими, щоб запустити DOS - лише кілька запитів - подумайте про справді дорогий звіт. Тож вам потрібен хороший моніторинг рівня додатків того, що відбувається:

    • Які служби були викликані та які аргументи / дані надсилаються (тобто вхід у вашу програму)
    • Які користувачі здійснюють виклик та з яких IP-адрес (тобто вхід у вашу програму)
    • Які запити та вставки / оновлення / видалення БД виконує
    • Середнє завантаження, завантаження процесора, введення / виведення диска, мережевий трафік на всіх комп’ютерах (і віртуальних машинах) у вашій системі
    • Переконайтесь, що всю цю інформацію легко отримати та що ви можете співвідносити журнали з різних комп’ютерів та служб (тобто забезпечити синхронізацію всіх комп’ютерів за допомогою ntp).

  7. Помітні обмеження та обмеження у вашій заявці . Наприклад, ви можете:

    • Використовуйте функцію QoS в балансаторі навантаження, щоб надсилати всі анонімні сеанси на окремі сервери додатків у вашому кластері, тоді як зареєстровані користувачі використовують інший набір. Це запобігає анонімному DDOS на рівні програми, який виводить цінних клієнтів
    • Використання потужного CAPCHA для захисту анонімних служб
    • Час очікування сеансу
    • Встановіть обмеження сеансу або обмеження швидкості для певних типів запитів, таких як звіти. Переконайтеся, що ви можете вимкнути анонімний доступ, якщо це необхідно
    • Переконайтеся, що користувач має обмеження на кількість одночасних сеансів (щоб запобігти входу в систему зламаного облікового запису мільйон разів)
    • Майте різних користувачів додатків баз даних для різних служб (наприклад, транзакційне використання проти використання звітів) і використовуйте управління ресурсами бази даних, щоб запобігти тому, щоб один тип веб-запитів переважав усі інші
    • Якщо можливо, зробіть ці обмеження динамічними або, принаймні, налаштованими. Таким чином, поки ви перебуваєте під атакою, ви можете встановити агресивні тимчасові обмеження («зменшення» атаки), наприклад, лише один сеанс на користувача та відсутність анонімного доступу. Це, звичайно, не найкраще для ваших клієнтів, але набагато краще, ніж взагалі не мати жодного сервісу.

  8. Нарешті, але не менш важливо, напишіть документ Плану реагування DOS і отримайте його на внутрішній перегляд усіх відповідних сторін: бізнесу, менеджменту, команди розробників SW, ІТ-команди та експерта з безпеки. Процес написання документа змусить вас та вашу команду продумати питання та допоможе вам бути готовими, якщо найгірше може статися о 3 ранку у вихідний день. Документ повинен охоплювати (серед іншого):

    • Що ризикує, і які витрати на бізнес
    • Заходи, вжиті для захисту активів
    • Як виявляється напад
    • Запланована процедура реагування та ескалації
    • Процеси постійного оновлення системи та цього документа

Отже, преамбула в сторону, ось кілька конкретних відповідей:

DDOS зазвичай блокуються на рівні сервера, так?

Не зовсім так - більшість найгірших DDOS-атак мають низький рівень (на рівні пакетів IP) і обробляються правилами маршрутизації, брандмауерами та пристроями безпеки, розробленими для обробки DDOS-атак.

Чи є спосіб заблокувати його на рівні PHP або, принаймні, зменшити?

Деякі DDOS-атаки спрямовані на саму програму, надсилаючи дійсні URI та HTTP-запити. Коли швидкість запитів зростає, ваш сервер (и) починає боротися, і у вас буде відключення SLA. У цьому випадку є щось, що ви можете зробити на рівні PHP:

  • Моніторинг рівня додатків: Переконайтеся, що кожна служба / сторінка реєструє запити так, щоб ви могли бачити, що відбувається (щоб ви могли вжити заходів для пом’якшення атаки). Деякі ідеї:

    • Майте формат журналу, який ви можете легко завантажити в інструмент журналу (або Excel або подібний), та проаналізувати інструменти командного рядка (grep, sed, awk). Пам'ятайте, що DDOS генерує мільйони рядків журналу. Ймовірно, вам доведеться нарізати ваші журнали (особливо щодо URI, часу, IP-адреси та користувача), щоб зрозуміти, що відбувається, і потрібно згенерувати такі дані, як:

      • Які URI доступні
      • Які URI швидко відмовляються (вірогідний показник конкретних URI, які атакують зловмисники)
      • Які користувачі отримують доступ до послуги
      • Скільки IP-адрес отримує кожен користувач до послуги
      • До яких URI мають доступ анонімні користувачі
      • Які аргументи використовуються для даної послуги
      • Аудит конкретних дій користувачів

    • Запишіть IP-адресу кожного запиту. НЕ ЗМІНЮЙТЕ DNS-це - як не дивно, вартість цього робить DDOS простішим для зловмисників

    • Зафіксуйте весь метод URI та HTTP, наприклад "ОТРИМАТИ http://example.com/path/to/service?arg1=ddos "
    • Запишіть ідентифікатор користувача, якщо він присутній
    • Записуйте важливі аргументи HTTP

  • Помітні обмеження швидкості: Ви можете застосувати обмеження щодо кількості запитів, які може зробити певний IP або Користувач за певний проміжок часу. Чи міг законний клієнт зробити більше 10 запитів на секунду? Чи можуть анонімні користувачі взагалі отримувати доступ до дорогих звітів?

  • CAPTCHA для анонімного доступу: Внесіть CAPTCHA для всіх анонімних запитів, щоб перевірити, що користувач є особою, а не ботом DDOS.

Який найшвидший і найпоширеніший спосіб зупинити DDOS-атаки?

Найшвидший - це, мабуть, поступитися шантажу, хоча це може бути небажаним.

В іншому випадку, перше, що вам потрібно зробити, це зв’язатися зі своїм хостингом та / або провайдером CDN і співпрацювати з ними (якщо вони вже не зв’язалися з вами, вже запитуючи, що, біса, відбувається ...). Коли DDOS трапляється, це, ймовірно, побічно вплине на інших клієнтів хостинг-провайдера, і постачальник може зазнати значного тиску, щоб закрити ваш сайт просто для захисту своїх ресурсів. Будьте готові поділитися своїми журналами (будь-якою та всією інформацією) з постачальником; ці журнали в поєднанні з їх мережевими моніторами можуть разом надавати достатньо інформації для блокування / пом'якшення атаки.

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

Перебуваючи під атакою, вам потрібно буде захопити свої журнали та видобути їх - спробуйте розробити схему атаки. Вам слід розглянути можливість вимкнення анонімного доступу та регулювання сервісів, що перебувають під атакою (тобто зменшити обмеження швидкості програми для послуги).

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

Дуг МакКлін має кілька чудових порад за адресою: https://stackoverflow.com/a/1029613/1395668

— Ендрю Алкок
джерело
20

Відповідно до PHP-частини запитання;

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

  1. Зловмисник може змінювати IP-адреси для кожного запиту
  2. Зловмисник може передавати параметри (параметри) до URI, що цільовому сайту не цікаві ці параметри
  3. Зловмисник може перезапустити сеанс до закінчення терміну дії ...

Просте псевдо;

<?php
// Assuming session is already started
$uri = md5($_SERVER['REQUEST_URI']);
$exp = 3; // 3 seconds
$hash = $uri .'|'. time();
if (!isset($_SESSION['ddos'])) {
    $_SESSION['ddos'] = $hash;
}

list($_uri, $_exp) = explode('|', $_SESSION['ddos']);
if ($_uri == $uri && time() - $_exp < $exp) {
    header('HTTP/1.1 503 Service Unavailable');
    // die('Easy!');
    die;
}

// Save last request
$_SESSION['ddos'] = $hash;
?>
— K-Gun
джерело
8

Рівень php занадто пізній у ланцюжку запитів.

Розміщення сервера Apache за пристроєм з відкритим кодом може бути хорошим варіантом для вас.

http://tengine.taobao.org/ містить деяку документацію та додаткові модулі, спрямовані на запобігання DDOS. Це розширення nginx, тому ви можете легко встановити його як зворотний проксі для вашого екземпляра apache.

Дивіться: http://blog.zhuzhaoyuan.com/2012/01/a-mechanism-to-help-write-web-application-firewalls-for-nginx/ про те, як боротися зі зіткненнями з DoS-атаками.

Зовсім забув теж, http://www.cloudflare.com - один із найкращих безкоштовних брандмауерів веб-додатків, вони мають безкоштовні та платні плани, і вони врятують вашу дупу від DDOS. . Це приголомшливо!

— j_mcnally
джерело
5

Ви не можете зробити це на рівні PHP. DDOS - це свого роду атака, яка надсилає занадто багато запитів на ваш веб-сервер. Ваш веб-сервер відхилить запит, перш ніж викликати ваш PHP-скрипт.

Якщо ви використовуєте Apache, ось кілька порад від Apache: http://httpd.apache.org/docs/trunk/misc/security_tips.html

— ndlinh
джерело
5

DDoS найкраще обробляти дуже дорогими спеціальними мережевими пристроями. Хости, як правило, не вміють захищати DDoS, оскільки вони піддаються відносно низькій продуктивності, виснаженню стану, обмеженій пропускній здатності тощо. Використання iptables, модів apache та подібних служб може допомогти в деяких ситуаціях, якщо у вас немає доступу до обладнання для пом'якшення DDoS або службу пом'якшення DDoS, але це далеко не ідеально, і все ще створює ризик нападу.

— райан
джерело
8
Нам потрібне рішення, а якщо ідеального рішення немає, потрібні були часткові рішення. Нікому не потрібна порада типу "ви просто не можете цього зробити".
— Аудріус Мескаускас
5

Як щодо чогось подібного на стороні PHP:

//if user does not change IP, then ban the IP when more than 10 requests per second are detected in 1 second
$limitps = 10;
if (!isset($_SESSION['first_request'])){
    $_SESSION['requests'] = 0;
    $_SESSION['first_request'] = $_SERVER['REQUEST_TIME'];
}
$_SESSION['requests']++;
if ($_SESSION['requests']>=10 && strtotime($_SERVER['REQUEST_TIME'])-strtotime($_SESSION['first_request'])<=1){
    //write the IP to a banned_ips.log file and configure your server to retrieve the banned ips from there - now you will be handling this IP outside of PHP
    $_SESSION['banip']==1;
}elseif(strtotime($_SERVER['REQUEST_TIME'])-strtotime($_SESSION['first_request']) > 2){
    $_SESSION['requests'] = 0;
    $_SESSION['first_request'] = $_SERVER['REQUEST_TIME'];
}

if ($_SESSION['banip']==1) {
    header('HTTP/1.1 503 Service Unavailable');
    die;
}
— NVG
джерело
1
У цьому коді є деякі помилки: 10 жорстко закодовано, strtotime не потрібен у змінних сервера та сеансу, а $ _SESSION ['ban_up'] == 1 має бути = 1.
— Джейсон Сільвер
2

Як НЕ використовувати захист PHP на основі, це жахливо , і навряд чи буде мати вплив на все! Налаштуйте веб-сервер на обмеження запитів, наприклад у Nginx, використовуючи модуль limit_req ( http://nginx.org/en/docs/http/ngx_http_limit_req_module.html )

Хоча, я б рекомендував використовувати CloudFlare для боротьби з рівнем 4 - однак, не за атаками на рівні 7, якщо ви не готові платити.

— JustLloyd
джерело
так, чудово працював і для мене, мій досвід роботи тут softwareengineeringsolutions.co.uk/…
— Елвіс Кіотті,
2

DDOS зазвичай блокується на рівні сервера. Будь ласка, увімкніть захист DDOS на своєму рівні сервера. Будь ласка, перевірте наведені нижче примітки щодо захисту DDOS.

Налаштування конфігурації сервера Apache HTTP, які можуть допомогти запобігти проблемам DDOS:

Директива RequestReadTimeout дозволяє обмежити час, протягом якого клієнт може відправити запит.

Дозвольте 10 секунд отримати запит, включаючи заголовки, і 30 секунд для отримання тіла запиту:

RequestReadTimeout header=10 body=30

Залиште принаймні 10 секунд, щоб отримати тіло запиту. Якщо клієнт надсилає дані, збільште час очікування на 1 секунду на кожні 1000 отриманих байтів, без верхнього обмеження часу очікування (за винятком обмеження, вказаного опосередковано LimitRequestBody):

RequestReadTimeout body=10,MinRate=1000

RequestReadTimeout header=10-30,MinRate=500
RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500

Директиву KeepAliveTimeout також можна знизити на сайтах, які піддаються атакам DoS. Деякі сайти навіть повністю вимикають програми Keepalive за допомогою KeepAlive, що, звичайно, має інші недоліки в роботі. Слід перевіряти значення різних директив, пов'язаних з таймаутом, що надаються іншими модулями.

Директиви LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine та LimitXMLRequestBody повинні бути ретельно налаштовані для обмеження споживання ресурсів, викликаних введенням клієнта. Налаштуйте директиву MaxRequestWorkers, щоб дозволити серверу обробляти максимальну кількість одночасних з'єднань без закінчення ресурсів.

— Раджа Рама Мохан Тавалам
джерело
2

Кроки проти DDOS :

  • Найперше, що важливо - визначити атаку ddos ​​першою. Більш рання ідентифікація атаки ddos ​​означає кращий результат для вашого сервера.
  • Отримання кращої пропускної здатності, доступної для вашого сервера. Завжди зберігайте більше, ніж достатню пропускну здатність, необхідну для вашого сервера. Це не запобіжить DDOS-атаці, але це займе більше часу. Завдяки чому ви отримаєте додатковий час для дії.
  • Якщо у вас є власний веб-сервер, ви можете захищати параметри мережі за обмеженням швидкості вашого маршрутизатора, додавати фільтри для скидання пакетів до різних джерел атак, таймаут наполовину відкритих з'єднань більш агресивно. Також встановіть нижчі пороги падіння SYN, ICMP та UDP.
  • Якщо у вас немає особливих уявлень про ці речі, тоді швидше зверніться до свого хостинг-провайдера. Вони можуть спробувати якнайкраще запобігти DDOS-атакам.
  • Також є спеціальна послуга зменшення наслідків DDOS, яку надає Cloudflare та багато інших компаній. За допомогою чого вони можуть допомогти вам запобігти DDOS-атакам. Також багато компаній пропонують дешевий ddos-захист та захист dos .
— IamNOOB
джерело
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.