Как включить защиту DDoS?

DDoS (распределенные атаки отказа в обслуживании) обычно блокируются на уровне сервера, верно?

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

Если нет, то каков самый быстрый и наиболее распространенный способ остановить DDoS-атаки?

10 ответов


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

  • подключение хостингового центра к сети Интернет
  • внутренняя сеть и маршрутизаторы Хостинг-Центра
  • брандмауэр и балансировщики нагрузки
  • ваши веб-серверы, серверы приложений и базы данных.

прежде чем вы начнете строить свою защиту DDOS, подумайте, что такое наихудшее значение риска. Для некритическая, бесплатная в использовании услуга для небольшого сообщества, общая стоимость риска может быть арахисом. Для платной, ориентированной на общественность, критически важной системы для установленного многомиллиардного бизнеса ценность может быть стоимостью компании. В этом последнем случае вы не должны использовать StackExchange :) в любом случае, для защиты от DDOS вам нужен глубокий подход к защите:

  1. работа с вашим хостинг-центром чтобы понять услуги, которые они предлагают, включая фильтрацию IP и портов при их сетевых подключениях к интернету и брандмауэрам, которые они предлагают. Это критично: многие сайты вытягиваются из интернета хостинг-компании поскольку хостинговая компания имеет дело с нарушением работы центра обработки данных, вызванным DDOS для одного клиента. Кроме того, во время DDOS-атаки вы будете работать очень тесно с персоналом хостингового центра, поэтому знайте их номера экстренных служб и будьте с ними в хороших отношениях:) они должны иметь возможность блок целых международных регионов, полностью блокировать конкретные услуги или сетевые протоколы и другие меры защиты широкого спектра, или альтернативно разрешить только белый список IPs (в зависимости от вашей бизнес-модели)
  2. находясь в хостинговом центре-используйте Сеть Доставки Контента распространять (в основном статические) услуги близко к конечным пользователям и скрывать реальные серверы от архитекторов DDOS. Полный CDN слишком велик для DDOS, чтобы вынуть все узлы во всех странах; если DDOS ориентирован на одну страну, по крайней мере, другие пользователи все еще в порядке.
  3. сохранить все ваши системы и программные пакеты обновлено с последними исправлениями безопасности - и я имею в виду всех:

    • управляемые коммутаторы - да, они иногда нуждаются в обновлении
    • маршрутизаторы
    • файрволы
    • балансировщики нагрузки
    • операционные системы
    • Web серверы
    • языки и их библиотек
  4. убедитесь, что у вас есть хороший брандмауэр или устройство безопасности настройка и регулярно пересматривается квалифицированным экспертом по безопасности. Строгие правила на брандмауэре-хорошая защита от многих простых атак. Также полезно иметь возможность управлять пропускной способностью, доступной для каждой открытой службы.

  5. хорошие мониторинг сети инструменты на месте - это может помочь вам понять:

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

    • какие службы были вызваны и какие аргументы / данные отправлено (т. е. вход в приложение)
    • какие пользователи делают вызов и из которых IPs (т. е. вход в ваше приложение)
    • какие запросы и вставки / обновления / удаления выполняет БД
    • средняя загрузка, загрузка процессора, дисковый ввод - вывод, сетевой трафик на всех компьютерах (и VMs) в вашей системе
    • убедитесь, что вся эта информация легко извлекается и что вы можете сопоставлять журналы с разных компьютеров и служб (т. е. все компьютеры синхронизированы по времени с помощью ntp).
  7. разумные ограничения и ограничения в вашем приложении. Например, вы можете:

    • используйте функцию QoS в подсистеме балансировки нагрузки для отправки всех анонимных сеансов на отдельные серверы приложений в кластере, в то время как зарегистрированные пользователи используют другой набор. Это предотвращает анонимный DDOS уровня приложения, вынимая ценных клиентов
    • С помощью сильной, показанные на картинке, чтобы защита анонимных услуг
    • сессия тайм-ауты
    • есть ограничение сеанса или ограничение скорости для определенных типов запросов, таких как отчеты. Убедитесь, что при необходимости вы можете отключить анонимный доступ
    • убедитесь, что пользователь имеет ограничение на количество одновременных сеансов (для предотвращения взлома учетной записи входа в миллион раз)
    • имеют разные пользователи приложений базы данных для разных служб (например, транзакционное использование против использования отчетов) и используют базу данных управление ресурсами, чтобы предотвратить один тип веб-запроса от подавляющего всех других
    • Если возможно, сделайте эти ограничения динамическими или, по крайней мере, настраиваемыми. Таким образом, пока вы находитесь под атакой, вы можете установить агрессивные временные ограничения ("дросселирование" атаки), такие как только один сеанс на пользователя и отсутствие анонимного доступа. Это, конечно, не отлично подходит для ваших клиентов, но намного лучше, чем не иметь никакого обслуживания вообще.
  8. последние, но не по крайней мере, напишите план ответа DOS документ и получить это внутренне рассмотрены всеми соответствующими сторонами: Бизнес, Управление, команда разработчиков SW, ИТ-команда и эксперт по безопасности. Процесс написания документа заставит вас и вашу команду подумать над проблемами и поможет вам быть готовым, если худшее должно произойти в 3 утра в ваш выходной день. Документ должен охватывать (среди прочего):

    • что в опасности, и цена к дело
    • меры, принятые для защиты активов
    • как обнаружена атака
    • запланированная процедура реагирования и эскалации
    • процессы для поддержания системы и этого документа в актуальном состоянии

Итак, преамбула в сторону, вот некоторые конкретные ответы:

DDOS обычно блокируются на уровне сервера, верно?

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

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

некоторые DDOS-атаки направлены на само приложение, отправляя допустимые URIs и HTTP-запросы. Когда скорость запросов растет, ваш сервер(ы) начинают бороться, и у вас будет отключение SLA. В этом случае есть вещи, которые вы можете сделать в уровень PHP:

  • мониторинг уровня приложения: убедитесь, что каждая служба/страница регистрирует запросы таким образом, чтобы вы могли видеть, что происходит (так что вы можете принять меры для смягчения атаки). Некоторые идеи:

    • имеют формат журнала, который вы можете легко загрузить в инструмент журнала (или Excel или аналогичный), и анализировать с помощью инструментов командной строки (grep, sed, awk). Помните, что DDOS будет генерировать миллионы строк журнала. Вам, вероятно, понадобится slic'n'DICE ваш журналы (особенно в отношении URI, времени, IP и пользователя), чтобы понять, что происходит, и должны генерировать такие данные, как:

      • какие URI доступны
      • какие URIs терпят неудачу с высокой скоростью (вероятный показатель конкретных URIs атакующие атакуют)
      • какие пользователи получают доступ к сервису
      • сколько IP-адресов каждый пользователь получает доступ к службе из
      • какие URI являются анонимными пользователями доступ
      • какие аргументы используются для данной службы
      • аудит конкретных действий пользователей
    • войти IP-адрес каждого запроса. Не отменяйте DNS это-по иронии судьбы стоимость этого делает DDOS проще для злоумышленников

    • войти весь URI и метод HTTP, например " GET http://example.com/path/to/service?arg1=ddos"
    • войти ID пользователя, если присутствует
    • Log важные аргументы HTTP
  • разумные ограничения скорости: вы можете реализовать ограничения на количество запросов, которые данный IP или пользователь может сделать в данный период времени. Может ли законный клиент сделать более 10 запросов в секунду? Могут ли анонимные пользователи вообще получать доступ к дорогостоящим отчетам?

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

каков самый быстрый и распространенный способ остановить DDOS-атаки?

самый быстрый, вероятно, уступить шантажу, хотя это может быть нежелательно.

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

Если вы ожидаете DDOS, это очень хорошая идея, чтобы квалифицировать хостинг-провайдера на уровне защиты, которую они могут обеспечить. Они должны иметь DDOS опыт и инструменты для его смягчения-понять их инструменты, процессы и процедуры эскалации. Также спросите о том, какая поддержка у хостинг-провайдера от их upstream провайдеров. Эти услуги могут означать больше авансовых или ежемесячных затрат, но рассматривать это как страховой полис.

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

Если вам повезло и у вас есть небольшая фиксированная клиентская база, вы можете определить свои действительные IP-адреса клиентов. Если это так, вы можете переключиться на подход с белым списком на короткое время. Убедитесь, что все ваши клиенты знают, что это происходит, чтобы они могли позвонить, если им нужен доступ с нового IP:)


Даг Маклин есть некоторые большие советы по: https://stackoverflow.com/a/1029613/1395668


по 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;
?>

уровень 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 мы используем его для многих наших сайтов с высоким трафиком только для его возможностей кэширования. Это ужасно!


DDoS лучше всего обрабатывается очень дорогими, специально построенными сетевыми устройствами. Хосты, как правило, плохо справляются с защитой DDoS, поскольку они подвержены относительно низкой производительности, истощению состояния, ограниченной пропускной способности и т. д. Использование iptables, Apache mods и подобных сервисов может помочь в некоторых ситуациях, если у вас нет доступа к оборудованию для смягчения DDoS или службе смягчения DDoS, но это далеко не идеально и по-прежнему оставляет вас под угрозой атаки.


Как насчет чего-то подобного на стороне 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;
}

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

Если вы используете Apache, вот несколько советов от Apache: http://httpd.apache.org/docs/trunk/misc/security_tips.html


есть плагины, которые вы можете использовать в apache для ddos / dos. Хорошее начало здесь http://www.debianadmin.com/how-to-protect-apache-against-dosddos-or-brute-force-attacks.html

Если вы на LEMP, вы можете проверить здесь. http://nginx.org/en/docs/http/ngx_http_limit_conn_module.html

Это хорошие недорогие отправные точки.


Do не используйте защиту на основе PHP, это ужасно и вряд ли повлияет на все! Настройте свой веб-сервер на запросы ограничения скорости, например, в Nginx с помощью модуля limit_req (http://nginx.org/en/docs/http/ngx_http_limit_req_module.html)

хотя я бы рекомендовал использовать CloudFlare для борьбы с атаками уровня 4, но не на уровне 7, Если вы не готовы платить.


DDOS обычно блокируются на уровне сервера, пожалуйста, включите защиту DDOS на уровне сервера. Пожалуйста, проверьте ниже примечания для защиты DDOS.

параметры конфигурации HTTP-сервера Apache, которые могут помочь предотвратить проблемы 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-атакам. Некоторые сайты даже полностью отключают keepalives через KeepAlive, что, конечно, имеет и другие недостатки на выполнение. Следует проверить значения различных директив, связанных с таймаутом, предоставляемых другими модулями.

директивы LimitRequestBody, LimitRequestFields, LimitRequestFieldSize, LimitRequestLine и LimitXMLRequestBody должны быть тщательно настроены для ограничения потребления ресурсов, инициируемого клиентским вводом. Настройте директиву MaxRequestWorkers, чтобы позволить серверу обрабатывать максимальное количество одновременных подключений без исчерпания ресурсов.


анти DDOS действия:

  • самое первое, что важно, это идентифицировать DDoS-атаку в первую очередь. Более ранняя идентификация ddos-атаки означает более лучшее для вашего сервера .
  • получение лучшей пропускной способности для вашего сервера. Всегда держите более чем достаточно пропускной способности, которая требуется для вашего сервера. Это не предотвратит DDOS-атаку, но займет больше времени. Благодаря чему вы получите дополнительное время для действий.
  • если вы владеете собственный веб-сервер, то вы можете защитить на сетевом параметре по скорости ограничить маршрутизатор, добавить фильтры для сброса пакетов к различным источникам атак, тайм-аут половину открытых соединений более агрессивно. Также установите более низкие пороги падения потока SYN, ICMP и UDP.
  • если у вас нет большого представления об этих вещах, а затем пойти и связаться с хостинг-провайдеров быстро. Они могут сделать все возможное, чтобы предотвратить DDOS-атаки.
  • существуют также специальные ДДОС помощи Cloudflare и многих других компаний. С помощью которых они могут помочь вам предотвратить DDOS-атаки. Также многие компании предлагают дешевые защита от ddos и защита dos.