У меня большой многопользовательский сайт WordPress. У меня есть лаковый кеш перед сервером приложений WordPress. Поскольку нет смысла кэшировать POST-запросы, я уязвим для DDoS-атак с использованием большого количества POST-запросов к серверу кеширования лака.
Я попытался установить правила брандмауэра, которые принимали только 20 одновременных подключений от каждого клиента, но это повлияло на пользователей, сидящих за общими прокси-серверами, и на школы с большим количеством пользователей за одним и тем же шлюзом.
Varnish не имеет возможности ограничивать количество запросов POST, и я хочу установить ограничение ДО того, как он попадет на сервер приложений. Есть небольшой прозрачный прокси, который бы справился с этой задачей?
В настоящее время Varnish получает около 100-150 обращений в секунду, прокси должен, по крайней мере, справиться с этой нагрузкой.
Я собираюсь записать это как ответ только потому, что это будет долго. Как вы совершенно точно сказали, блокировка более 20 одновременных запросов с 1 IP-адреса не поможет. Вы должны установить более «умные» критерии. Я пойду дальше и скажу, что установка другого прокси-сервера между прокси-сервером и сервером приложений не является ни элегантным, ни полезным.
Я не знаю, почему вы хотите установить ограничение скорости перед запуском apache, потому что вы упускаете fail2ban, mod_qos, mod-antiloris (весьма специфичные) и другие решения. Более того, я не знаю, являются ли запросы POST вашей единственной проблемой с точки зрения DDoS.
Кэширование ответов на запросы POST возможно и тоже имеет смысл. Если только вы не обслуживаете динамический контент каждый раз. Это, конечно, не означает, что вы можете кэшировать аутентифицированные страницы.
Вы можете применить тайм-аут запроса для POST, если запрос занял более 5 секунд. Хотя пользователи с медленным подключением не смогут ничего отправлять. Вы также можете применить правило для каждого URL-адреса в сочетании с указанным выше правилом. Это имеет смысл, поскольку для пользователя целесообразно выполнить POST 1000 КБ на странице загрузки файла, но не на странице входа. Как я уже сказал, создайте «более умные» критерии. Они могут быть длинными, и на их формулирование может уйти некоторое время, но они предоставят вам устойчивое решение, поскольку я не знаю универсального решения, подходящего для всех в подобной ситуации.
Еще одно решение, которое вы можете комбинировать, - это брандмауэр приложений. Может быть, больше, чем вам нужно, но это также может уберечь вас от многих других вещей. Вот страница owasp с рекомендациями и соответствующая вики
РЕДАКТИРОВАТЬ: Должен признать, у меня нет опыта работы с этой конфигурацией (varnish и antiloris). Рано или поздно лак может кэшироваться (хотя он очень «программируемый»). Главное, что вы можете сделать, это знать схему использования и когда она отклоняется от нормы. Если вы просто хотите предотвратить этот очень специфический тип атаки, то лучше напишите правила для Varnish. Однако запросы, попадающие в apache, - это неплохо, если у вас есть соответствующие моды / конфигурации, Apache может определить, когда запрос является законным, и, таким образом, обработать его, а когда нет. Блокирование X соединений от каждого клиента НЕ является хорошим делом, если только вы не можете внести этот IP-адрес в черный список. Вы можете сделать это на apache либо через fail2ban (регулярное выражение), либо mod_qos
Думаю, правильно настроенный Varnish с этим справится.
Я мало что знаю о wordpress, но полагаю, что действительный пост будет иметь переменную сеанса либо в файле cookie, либо в параметрах формы. Если да, то вы хотите ограничить либо повторяющиеся POST для одного и того же значения, либо POST без такого значения.
Я сделал здесь сообщение в блоге: http://blog.dansingerman.com/post/4604532761/how-to-block-rate-limited-traffic-with-varnish об ограничении скорости на основе IP-адреса или параметра URL; его должно быть просто настроить для POST и основываться на переменной формы или переменной cookie.