1. Введение
Тема DDoS атак “сетевого” уровня (L4 и ниже) заезжена и раскрыта. Обычно эти атаки такой мощности, что справиться с ними server-side невозможно — они забивают канал на 100%.
Но есть атаки, которые влезают в канал и наносят не меньший урон. Это DDoS атаки на приложение, http flood. В случае атак на приложение сайт/сервер обычно ложится значительно раньше, чем будет забит канал. Такая атака тоже может забить канал, например, с помощью worpress xml rpc amplification (https://blog.sucuri.net/2015/10/brute-force-amplification-attacks-against-wordpress-xmlrpc.html). В этом случае меры борьбы такие же, как с атаками сетевого уровня.
Даже если вы используете сервис, который вас проксированием защищает от DDoS, этот материал будет полезен — сервисы часто пропускают флуд в количествах, достаточных чтобы вы испытывали трудности.

2. КАК ПОНЯТЬ, ЧТО ПРИШЕЛ DDoS
Так как этот доклад я читаю на конференции Highload, предполагаю что у вас есть мониторинг.
Полезные метрики, по которым можно предположить, что вас атакуют:
- Внешний мониторинг: проблемы с доступностью, ошибки, значительное замедление отдачи страниц, потери пакетов.
- “Внутренний” мониторинг: количество запросов в секунду, загрузка CPU, LA, количество запущенных процессов (если бэкенд форкается), загрузка сетевого интерфейса.

3. ЧТО ДЕЛАТЬ, ЕСЛИ ОНО СЛУЧИЛОСЬ
Обычная практика — анализ логов самописными скриптами или, например, fail2ban. Далее iptables/ipset. Недостатки — ресурсоемко, трудоемко, много ложноположительных срабатываний, трудно поддерживать списки.
Я использую возможности nginx. Это geoip, лимиты, модуль test_cookie.

3.1 ЧТО НУЖНО СДЕЛАТЬ ЗАРАНЕЕ
Чем быстрее работает ваш сайт, тем сложнее его заддосить http флудом. Первое действие — ускорение отдачи страниц. Особое внимание уделить скорости генерации 404 ошибки и формам.
Запретите методы, отличные от HEAD, GET. Разрешите POST (PUT и т.д.) только там, где он должен быть.
Настройте geoip. Добавьте в лог запись страны. Предусмотрите в конфиге map для блокирования по странам.
Выделите в конфиге nginx location, которые отдают статику и динамику. Расставьте разумные лимиты на число коннектов с одного ip, на число запросов к статике и динамике. Выделите “тяжелые” страницы в отдельные location. Добавьте отдельный лог на динамику, сэкономите время на grep в случае проблем.
Сделайте настройки для кэширования средствами nginx. Можно и нужно кэшировать POST. Кэширование можно не включать, но настроить. Лимиты, кстати, тоже.

3.2 ЧТО ДЕЛАТЬ, ЕСЛИ ПРИШЕЛ DDoS
Если сервер нагружен так, что вы ничего не в состоянии делать — отключайте веб. Вы все равно практически лежите, но на еле работающем сервере вы будете разбираться намного дольше. Отключайте бэкенд — апач/php-fpm/unicorn и т. д. — то, что создает нагрузку.
Далее беглый взгляд на логи. Если вы не ФБ — в логах еще можно разбираться “глазом” и грепом. Вам нужно либо отгрепать запросы на динамику, либо посмотреть в тот самый отдельный лог. Иногда сразу видно флуд, особенно, если вы представляете, как выглядит ваш обычный лог. Иногда не видно, тогда просто смотрите, каких запросов прибавилось. Возможно это не DDoS, а хабраэффект). Далее можно резать по странам, включать (или уменьшать) лимиты, запрещать часть функционала, включать кэширование (на часть функционала).
Отдельно стоит test_cookie. Это последний рубеж обороны, если вы уверены, что вас атакуют боты, но атаку вы выявить не в состоянии — шаблон постоянно меняется или ботнет слишком велик, лимиты не спасают, geoip тоже.
В каком объеме рассказывать про него — буду смотреть по времени. Скорее всего, совсем обзорно.