Защитите себя от атак Dos

Ответ 1

Нет панацеи, но вы можете сделать DoS-атаки более сложными, выполнив следующие действия:

• Не ограничивайте свою готовность выполнять дорогостоящие операции от имени клиентов, не прошедших проверку подлинности.
• попытки проверки дросселя
• Операции дроссельной заслонки выполняются от имени каждого аутентифицированного клиента и размещают свою учетную запись в временной блокировке, если они слишком много времени делают за слишком короткое время.
• У вас есть аналогичный глобальный дроссель для всех клиентов, не прошедших проверку подлинности, и будьте готовы снизить этот параметр, если вы обнаружите атаку в процессе.
• У вас есть флаг, который вы можете использовать во время атаки, чтобы отключить все неаутентифицированный доступ.
• Не храните вещи от имени клиентов, не прошедших проверку подлинности, и используйте квоту для ограничения хранения для каждого аутентифицированного клиента
• В целом, отклоните все искаженные, неоправданно сложные или необоснованно огромные запросы как можно быстрее (и запишите их, чтобы помочь в обнаружении атаки).
• Не используйте чистый кеш LRU, если запросы от неаутентифицированных клиентов могут привести к выселению вещей из этого кеша, потому что вы будете подвержены атакам отравления кешем (где вредоносный клиент запрашивает множество разных нечасто используемых вещей, вызывая выселить все полезные вещи из вашего кеша и сделать гораздо больше работы для обслуживания ваших законных клиентов)

Помните, что важно прямо отказаться от подавленных запросов (например, с ответом HTTP 503: Service Unavailable или аналогичным ответом, соответствующим любому протокол, который вы используете), а не очереди в подавленных запросах. Если вы их ставите в очередь, очередь будет просто съесть всю вашу память, и атака DoS будет по крайней мере столь же эффективной, как и без дросселирования.

Некоторые более конкретные рекомендации для HTTP-серверов:

• Убедитесь, что ваш веб-сервер настроен на отклонение POST сообщений без сопроводительного заголовка Content-Length и отклонения запросов (и дросселирования оскорбительного клиента), которые превышают указанный Content-Length, и отклонять запросы с помощью Content-Length, который необоснованно длинный для обслуживания, что POST (или PUT) нацелен на

Ответ 2

Для этой конкретной атаки (при условии, что запрос GET) основан на балансировщике нагрузки или WAF, который поддерживает только полные запросы к веб-серверу.

Проблемы начинаются, когда вместо GET POST используется (что легко), потому что вы не можете знать, является ли это вредоносной POST или просто очень медленной загрузкой от пользователя.

От DoS per se вы не можете действительно защитить свой webapp из-за простого факта. Ваши ресурсы ограничены, в то время как у злоумышленника потенциально неограниченное время и ресурсы для выполнения DoS. И большую часть времени это дешево для злоумышленника для выполнения необходимых шагов. например эта атака, упомянутая выше, несколько 100 медленных подключений → без проблем

Ответ 3

Асинхронные серверы, например, более или менее защищены от этой конкретной формы атаки. Например, я обслуживаю приложения Django с использованием обратного прокси Nginx, и атака, похоже, не влияет на ее работу. Другой популярный асинхронный сервер - lighttpd.

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

Ответ 4

Короткий ответ:

Вы не можете защитить себя от DoS.

И я не согласен, что он принадлежит серверному файлу, поскольку DoS классифицируется как проблема безопасности и определенно связана с программированием