Присоединяюсь к 444, сам хотел написать.
Грубо говоря, всё остальное — сервер оправдывается, почему он не можут дать конент (нет на сайте, ушло, запрещено).
А 444 — просто нет и всё. Т.е. сервер молчит, пользователя в игнор.
«Пагинаторы» Без проблем работают в Wordpress к примеру, Не вижу проблемы. А вот поиск — согласен. Хотя если отрубать аргументы только при атаке, то оправдано, так как не до поиска будет, а лишь бы выстоять.
Если папки /foo/bar/123 не существует, то посетители — зомби будут просить 404 страницы, которые не жрут много ресурсов, а значит не создадут высокой нагрузки. Особенно если во время атаки правильно подкрутить nginx. Это не на всех сайтах, но на многих.
Сравните две ссылки: habrahabr.ru/foo/bar/123123/ habrahabr.ru/?=foobar=123123
Какая более нагружает сервер — очевидно.
А можно ли выделить список аргументов, которые должны пропускаться?
Если урлы преобразованы через htaccess c i.php?h=h.jpg -> /i/hjpg
эти урлы тоже будут резаться этим правилом?
Да, т.к. nginx работает до apache.
Такие преобразования стоит выкинуть, и статику (/i/h.jpg) отдавать nginx-ом. Но если у Вас много денег и 2 теребайта оперативной памяти, то необязательно.
Насколько я понимаю, данный метод добавления мусора эффективен когда на сервере кэшируются страницы по ключу URL. Таким образом, кэш очень быстро забивается и сайт падает.
Самое полезное в этой статье я узнал из коментов. Про код 444 =)
а обрезать всех кто с аргументами, это такая временная мера дабы главная страница работала несмотря на ддос.
Конечно, всё зависит от ресурса, но в некоторых случаях важнее, чтобы отправленный и дошедший до сервера клиентский запрос был обработан, пускай и ответа на него не будет.
Защита от DDOS атаки случайными аргументами при помощи Nginx