Здравствуй, Хабр!
Предлагаю твоему вниманию простой и в то же время эффективный метод борьбы с http DDoS. На основе сервера Xeon 2.5GHz / 4Gb RAM / SAS можно отражать атаку примерно до 300 Мбит/с (значение получено методом экстраполяции).

Способ реализация

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

Область применения

Борьба с Http DDoS на выделенном сервере или ВПС. Максимальная возможная мощность сдерживания DDoS атаки ограничивается физическими возможностями сервера и пропускной способностью канала.

SEO под DDoS-ом

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

Стоимость и эффективность

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

iptables — интерфейс к файрволу Linux (netfilter). При большом количестве правил iptables нагрузка может быть достаточно высокой и создавать проблемы. В этой заметке я постараюсь описать, что влияет на производительность iptables и как ее повысить.

За последнее время, наш сайт часто подвергается достаточно мощным DDOS атакам, к слову последняя атака была самой крупной за последнее время, размер ботнета по нашим оценкам — около 10 тысяч машин, мощность — 100 Mbits/s.

Атаку заметила даже Лаборатория Касперского, и предложила свою помощь в отражении, за что им спасибо. Правда к тому времени мы самостоятельно нашли решение, которое блокирует атаку. Собственно про это решение и пойдет речь.

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

Атака была типа HTTP Flood. Система на которой у нас работает сайт — Apache под Linux. Мы написали несколько скриптов, которые будут приведены в тексте статьи. В принципе аналогичный подход можно применять и для Windows/IIS.

Попытаюсь рассказать, какие основные шаги мы сделали для отражения атаки, и какие проблемы возникали по ходу:

Один юноша очень любил ругаться на тематическом ресурсе. И за это его регулярно банили. А один раз взяли, да и не разбанили.

Обиделся юноша, и решил отомстить. Поднакопил денег, взял да и заказал DDoS ресурса. Благо это в РФ не уголовно, к сожалению, наказуемое деяние.

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

Как водится, для придирчивых админов не нашлось удовлетворительно выглядящих решений, которые бы просто читали HTTP-лог и выдавали наружу те адреса, которые надо банить.
Поэтому пришлось построить свой лунапарк, с этим самым и этими самыми. Камрад metakey справился написать собственно логику отнесения айпи в бан, а ваш покорный слуга — настроить всю оставшуюся обвязку.

Тем, кто (предпо)читает Хемингуэя в подлиннике, можно сразу отправляться сюда. Там и код тоже можно найти.

Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100;

и скорость запросов на динамику (fastcgi_pass на php-fpm)

limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s;
limit_req zone=dynamic burst=10 nodelay;

Сильно полегчало, по логам видно, что в первую зону никто не попадает, зато вторая отрабатывает по полной.

Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго.

Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash.

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

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой

error_page 503 =429 @blacklist;

И соответствующий именованный location

location @blacklist {
    fastcgi_pass    localhost:1234;
    fastcgi_param   SCRIPT_FILENAME    /data/web/cgi/blacklist.sh;
    include         fastcgi_params;
}

Дальше интересней.
Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт

Хочу рассказать историю жизни сервера в кампусной сети Новосибирского университета, которая началась в далеком 2004 году, а так же этапы его оптимизации и даунгрейдинга.
Многие вещи в статье покажутся общеизвестными хотя бы по той причине, что речь пойдет о событиях почти десятилетней давности, хотя на тот момент это были передовые технологии. По той же причине кое что вообще потеряло актуальность, но далеко не все, так как сервер до сих пор живет и обслуживает сетку из 1000 машин.

Вкратце:

1. Защита сервисов и открытие портов по стуку криптографически стойким и не воспроизводимым Single Packet Authorization (SPA) с fwknop 2.6.9+.
2. Динамически настраиваемое обновление чёрных списков с All Cybercrime IP Feeds by FireHOL.
3. Полноценная поддержка ipset в cfnetwork.
4. Поддержка собственных чёрных списков.
5. Типичные варианты применения.