Как еще простой вариант - перед входом окошко от nginx, которое спрашивает хочет ли клиент зайти на форум. ответ ОК - отправляется в ответ положительный кукис, открывается форум дальше у данного клиента без проблем. Содержимое кукисов - уже на степень "умности" ботнета.
Еще вариант - js, который также создает кукис, но уже без окошек, мешающих пользователю. Что-то вроде майн страницы - index.htm с js-ом. Страничка загружается, js выполняется, делает кукис, редиректит на index.php. В index.php в начале кода php проверит наличие кукиса. Есть - отображается весь код форума. Нет - извиняйте. Статичная хтмлка готова к хайлоаду nginx. Форум не подключается для ботов. Минус - юзеры у которых noscript.
Плюс к этому - не поможет, если атака пойдет не на выведение из строя серверного-по от нагрузки а на сетевую подсистему (количество конкурентных запросов). Тогда уже необходимо будет ставить физический сервер или шейпер на маршрутизаторе. Это будет работать до момента, когда процессор маршрутизатора нагнется от листа забаненных или снова же, по числу к нему запросов. Или, что тоже вероятно, если шейпер поставлен сильный - просто кончится выделенный канал.
Логика банов адресов зависит от конкретной атаки. Если выделить ботнет можно на сетевом уровне (например, более 10 запросов в секунду с одного ип) - то маленький демон, мониторящий соединения и добавляющий в список иптэйблес или маршрутизатора правила - будет ок. Если ботнет большой, запросы раз в секунд 30 - то уже фиг выделить. Это понятно. Надо будет разрабатывать логику их определения уже по основанию их активности и целей. И самое успешное бы - добавлять в таблицы правила не конкретных адресов, а более общих. Разрастание этой таблицы тоже вызывает сильную нагрузку.
В качестве первоначальной диагностики хорошо бы иметь информацию, вроде: траффик в обычной активности, текущий трафик. Кол-во коннектов в секунду обычное и текущее. Идет атака на хостнэйм или на ип адрес. На одну страницу или на рандом. Хорошо бы убедиться, что на форуме нет инъекций. Тогда сами обычные пользователи могут сами участвовать в атаке. Тогда необходимо выключить это, разумеется и бороться с физическими остатками только после этого. В общем, много всего зависит от специфики.
Ну и, не так много, но интересного пишут на хабре по методикам борьбы с ддосом. Но статьи помогут лишь определять подход и что с ними делать. Идеального решения и панацеи против ддоса нет, кроме как тупо отвалить денег ребятам занимающимся этим. Иногда этот вариант правильней, когда страдают большие деньги и выркемени на самостоятельную борьбу нет. Ну или когда физической мощности не хватает.
