Сегодня мы стали мишенью DDoS-атаки. На нашем балансировщике нагрузки (HAProxy) было в 20 раз больше подключений, чем обычно, и все внутренние узлы продолжали выходить из строя во время этой атаки.
System structure: HAProxy > Squid > Apache (for ModSecurity) > IIS app layer.
Во время нападения я заметил, что был Достигнуто максимальное количество клиентов ошибка в Apache, поэтому я увеличил настройку со 150 до 250, и, похоже, это в какой-то степени помогло. Однако казалось, что мне приходилось перезапускать Apache вручную, чтобы серверные части могли восстановиться. Атака длилась около 50 минут.
После того, как атака начала утихать, окончательный перезапуск Apache на каждом узле вывел нас в «зеленую зону», но теперь я выясняю, почему это произошло в первую очередь. В журналах ошибок в Apache я вижу много таких:
[Wed Jun 22 11:46:12 2011] [error] [client 10.x.x.x] proxy: Error reading from remote server returned by /favicon.ico
[Wed Jun 22 11:46:13 2011] [error] [client 10.x.x.x] (70007)The timeout specified has expired: proxy: error reading status line from remote server www.example.com
Apache использует настройки проверки активности по умолчанию (проверки активности включены, а время ожидания установлено на 15 секунд). После дополнительного чтения о HAProxy + keep-alives, Разумно ли полагать, что DDoS-атака была усугублена включением поддержки активности?
Хотя максимальное количество подключений HAProxy намного ниже максимума, установленного в Apache, возможно, с подключениями 20x слишком много подключений открывалось в стиле старой DOS, но тогда Apache оставил их открытыми.
Я думаю, вы ищете неправильное возможное исправление для этого сценария. Если вы подвергаетесь DDoS-атаке, то единственный реальный путь смягчения последствий, который у вас есть, - это поговорить со своими вышестоящими провайдерами и заставить их обнулить / скрыть трафик до того, как он попадет в вашу сеть. В противном случае, что бы вы ни делали, он все равно будет достигать границы вашей сети и потенциально (возможно) насыщать соединение на вашем конце.
Единственное, что нужно сделать, - это заблокировать его до того, как он достигнет границы вашей сети. Любой сценарий предотвращения DDoS-атак вряд ли будет столь же полезным, поскольку трафик должен попасть в вашу сеть, прежде чем его можно будет проигнорировать / заблокировать / отбросить. В результате он по-прежнему будет съедать вашу пропускную способность.
Кроме того, простое увеличение числа доступных воркеров может усугубить проблему, если у вас на самом деле недостаточно памяти для всех этих дочерних процессов. Вы начнете переключаться на диск, и ваша машина остановится. Удивлен, что никто не упомянул mod_evasive или mod_security; наличие некоторой автоматической эвристики для блокировки доступа к ресурсам, требующим больших вычислительных ресурсов, очень помогает в случае, когда вы не будете или не можете выполнять нулевой маршрут.
РЕДАКТИРОВАТЬ: это был комментарий, но я превратил его в ответ на предложение @Tom O'Connor.
После того, как проблема возникла еще несколько раз в течение нескольких недель после первоначальной «атаки», мне пришлось копнуть глубже, поскольку я думал, что, возможно, использовал DDoS в качестве отговорки.
Хотя журналы доступа и моментальные снимки netstat (получение первых N IP-адресов, упорядоченных по количеству подключений, добавленных к файлу журнала) определенно показали очень распределенное количество IP-адресов, я смог идентифицировать конкретную страницу в журналах доступа, которая показалась подозрительной.
По-видимому, команда разработчиков создала «прокси-страницу» для обслуживания сторонних запросов API через AJAX. Проблема, по-видимому, в том, что эта прокси-страница использовала ценные слоты для подключения на HAProxy, и когда у сторонней службы возникали проблемы с обслуживанием запросов API, она очень долго ждала тайм-аута. В конце концов, долгие запросы прокси довели наш бэкэнд HAProxy до максимального предела (так что все новые запросы были поставлены в очередь). С этого момента количество подключений начало расти в нашей сети, и наш общедоступный веб-сайт начал отсеивать обычные запросы, не относящиеся к AJAX.
В нашем случае решение заключалось в создании дополнительного бэкенда в HAProxy специально для этих вызовов AJAX. В следующий раз, когда у сторонней службы возникнут проблемы, она отключит только вызовы прокси-страницы AJAX, а остальная часть сайта продолжит работу.
Спасибо за ответы. Я думаю, что большинство из вас были на высоте, чтобы смягчить «настоящую» DDoS-атаку, но я думаю, что другим читателям полезно знать, что стоит посмотреть изнутри, чтобы убедиться, что вы не стреляете себе в ногу.
@Tom O'Connor, это не тип DDoS-атак с пропускной способностью / числом пакетов в секунду. Для меня это звучит как простой отказ в обслуживании.
Keep alive усугубит ситуацию, ваша проблема в том, что Apache не может обрабатывать запросы так быстро, как должен, и порождает множество рабочих, которые не могут справиться с запросами. По мере роста шансы на выздоровление практически равны нулю, если атака продолжается.
Очевидно, вы можете увеличить директиву MaxClients, но из того, что вы описали, она просто заставит вас спуститься через минуту или две.
Я не уверен, какой стек у вас запущен, но ваша цель - просто улучшить ответ Apache на один запрос (вы используете PHP? Он подключается к MySQL? Вы не кэшируете?), Страница, загружаемая в течение 0,010 секунды, будет в 100 раз лучше реагировать на отказ в обслуживании .vs-страницу, которая просматривает тонны информации в MySQL и завершается за 2 секунды на запрос.
Если кто-то делает 100 запросов, ваш сервер должен проработать 200 секунд, но поскольку он делает все сразу, 2 секунды на запрос теперь составляют 40 секунд на запрос * 100. Больше запросов, больше нагрузка.
Другой способ решить эту проблему - определить верхние соединения xyz и просто заблокировать их, но это будет немного сложнее и потребует немного больше знаний для правильной попытки.