В посте Защита от DDOS — первые шаги я закончил фразой «Теперь вот жду второго пришествия» — собственно, второе пришествие недавно заглянуло в виде очень дохленького DDOSa который все же забил канал так, что провайдерам пришлось отрубили порт.
Кэширование nging вообще тут не участвовало т.к. ддосили POST запросами.
Ограничение зоны на количество запросов с одного IP NGINX — защита от DDOS с одного IP. Параметры limit_zone и limit_req тоже не спасли!

Принял решение — полностью задействовать фаервол в связке с nginx, в моём случае фаервол ipfw т.к. операционная система FreeBSD, но это не суть, т.к. смысл остаётся тем же:
Анализируем логи, вычисляем злодеев, загоняем IP злодеев в blacklist который кушает фаервол.

Соответственно, аккуратно пересобираем ядро с поддержкой фаервлоа (по умолчанию я поставил политику можно всё, чтобы потом ручками уже переделать как нужно мне) — тут инфы много в сети.
Далее ещё раз прошелся по настройке сервера:
FreeBSD для обслуживания 100-200 тысяч соединений (freebsd tcp optimization tune speed socket mbuf sendfile sysctl)
Некоторые способы защиты от флуда и DDoS атак во FreeBSD
Кому интересно — мой sysctl.conf

Следующая задача — настройка фаервола.
Пишем правила по статьям
FreeBSD. Боремся с HTTP-флудом средствами IPFW
Настройка простого firewall на ipfw и NAT через natd во FreeBSD
Получилось у меня такой фаервол с поддержкой whitelist и blacklist
Оставил только самое необходимое — остальное DENY.
SSH и FTP только для админов по whitelist!

проверка листов
# ipfw table 1 list
# ipfw table 2 list

очистка
#/sbin/ipfw table 1 flush
#/sbin/ipfw table 2 flush

# добавляем в таблицу список забанненых IP

cat /etc/fw_black_list | awk '{ if ($1!="") {system("/sbin/ipfw table 2 add "$1"")} }' > /dev/null


Проверив работоспособность белого и чёрного списка IP можно приступать к довольно творческому моменту — поиску и отсеву злодеев.
Тут тоже небольшая подготовка — в nginx статику я вообще отключил (не вижу смысла логировать её), оставив только логирование динамических запросов (то что отправляем аппачу или pgp-fpm).
Ну и limit_req_zone, limit_zone в nginx я так же задействовал, чтобы встретить первый удар ДДОСа.

Далее, повторю, вопрос вычисления уже творческий — никаких точных правил нет, каждый определяет правила самостоятельно, подбирая, тестируя.
В этих ветках форума, можно подчерпнуть идеи для фильтров.
http://searchengines.guru/showthread.php?t=763177&page=2
http://searchengines.guru/showthread.php?t=763177&page=3
Я же знаю какое правило я сделаю первым! 🙂
Поиск запросов вида «POST / » и отсев этих IP в blacklist ! (пост запросы к морде в виде «POST / » вообще в живую не встречаются)
Получился вот такой скриптик

Ещё из идей для блокировки мне понравились такие правила:
* анализ лога ошибок error.lo по ошибке lteq — всех у кого больше 10 ошибок — в сад
* анализ лога на предмет 503 и других ошибочных страниц — больше 10 в сад

Полезный скрипт «на заметку»
grep 'text' /path/to/access.log | cut -d' ' -f1 | sort | uniq -c | sort -r
— анализ лога APACHE, На выходе отсортированный по убыванию пары IP и количество обращений. В grep помещаем любую интересующую фразу (HTTP Client, URL и тд)

Ещё неплохая статья на похожую тему
Активная защита FreeBSD на основе логов, sh и cron

не могу не процитировать, zexis-а одного из вышеуказанных постов

По поводу фальшивых срабатываний .
У меня написан анализатор логов access.log, который, на мой взгляд очень эффективно обнаруживает аномальную активность.
В нем задаются лимиты для алгоритмов поиска ботов под трафик конкретного сайта.
Пример лимитов.
1) Забанить всех кто сделал более 20 одинаковых запросов к страницам за 60 секунд и к другим страницам не обращался.
2) Забанить всех кто сделал более 30 одинаковых запросов к страницам за 120 секунд, но мог обращаться и к другим страницам.
3) Забанить всех кто сделал более 100 любых запросов к страницам за 120 секунд.
4) Забанить всех кто сделал более 130 любых запросов к страницам за 180 секунд.
5) Вычислить страницы сайта, которые имели за последние 3 минуты более 1000 обращений и забанить все IP которые обращались только к этим страницам.
6) Найти все юзер агенты используемые более 3000 раз, для них лимиты уменьшить на 30%
7) Найти все реферреры используемы суммарно более 1000 раз, для них лимиты уменьшить на 40%
8) Если суммарная нагрузка выше 500 запросов в минуту, но ботов алгоритмами не найдено, то начать бан тех кто не возвращает куки и не включен в белый список.
Для этого в код сайта вставляется джаваскрипит, который ставит куки. И в лог access.log добавляется поле значения этого куки, что бы анализатор логов мог их прочитать.

Цифры выше даны лишь как пример, а не те реальные лимиты которые я обычно ставлю.

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

Анализатор написан на С и обрабатывает лог длиной 10 000 строк 10 алгоритмами около 2 секунд.
Количество анализируемых строк вычисляется автоматически, что бы в анализ попало последние 3 минуты, но не более 50 000 строк.

Вопрос вероятности ложных банов решается настройкой лимитов под трафик каждого сайта. Да это бывает трудоемко, если сайтов много.
Если же на сервере 1-2 сайта, то настроить под них лимиты дело 20 минут.
Конечно нужно потом в течении нескольких дней наблюдать за работой защиты, и корректировать лимиты, если есть ложные баны.

Случаются и проблемы с настройкой лимитов, которые приводят к ложным банам.
Вот примеры проблем.
1) На сайте работает PHP чат, который генерирует много одинаковых запросов.
2) Картинки сайта грузятся не как статические файлы, а генерируются динамически скриптом PHP, это приводит к большому количеству запросов с одного клиента.

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

А вообще, конечно, DDOS нужно останавливать не на сервере, а на подходах к нему — т.к. при большом ботнете канал всё равно забъют и DDOS случится!
И тут остаётся только один способ Защита от DDOS атак средствами BGP но он на сколько я понял может быть реализован только силами провайдера.