Стандартные настройки защиты от DDOS и cloudflare

Леонид Леонид добавил(а) 6 мес. назад
Известна

При добавлении нового домена у нас автоматически включается защита от ДДОС, через лимиты подключений с одного IP. Мало кто вообще обращается на это внимание, включено да включено. Защита же!

Далее, мы подключаем cloudflare НЕ через панель, а просто руками т.к. управление доменом у нас в другом месте и вообще мало кто знает про модуль встроенный. И DNS записи у нас могут быть другие, чем в панели указаны.

Теперь у нас ситуация когда все запросы к серверу идут с 1-2 IP cloudflare и мы из-за включенной защиты от ДДОС в панели получаем дичайшие тормоза сайта т.к. защита начинает работать.

Да, конечно надо вставить теперь set_real_ip_from в nginx, чтобы определялся реальный IP. Это уже ручная работа.

НО! Не слишком ли много телодвижений из-за стандартной воли разработчиков включить защиту от ДДОС по умолчанию?

Конечно, на это есть свои причины, я надеюсь, что включили это по умолчанию.

Тогда у меня предложение, чтобы и настройку set_real_ip_from включили по умолчанию в конфиг nginx при установки его. Так делает, например, fastpanel и ни у кого не возникает проблем. У cloudflare редко меняются IP внутренние.

Комментарии (3)

фото
1

Ещё есть проблемный момент с включением защиты по умолчанию. Это активация HTTP/2. В этом протоколе загрузка всех ресурсов идёт одновременно и нет лимитов по подключению. А эта "защита" по умолчанию физически ограничивает использование нового протокола и тормозит загрузку сайта.

фото
2

Основная проблема включения защиты от ddos в www-доменах - это вставка include не в той секции в конфиге nginx, описывающий виртуалхост www-домена. И этому багу лет 10. При чём о нём уже здесь и на форуме ispsystem уже кто-то писал.


Т.е это сейчас находится в секции

server {

include /etc/nginx/vhosts-resources/site.ru/*.conf;

... }

Тем самым включение защиты от ddos, создавая файл в /etc/nginx/vhosts-resources/site.ru/reqlimit.conf

Замедляет работу всего-сайта, так как лимиты начинают работать для ВСЕГО и ВСЕХ входящих HTTPs запросов, в том числе и для статики, которую раздаёт nginx.


Когда как это должно быть только в секции back-end'a или по другому в / но не секциях статики


 location / {
                location ~ [^/]\.ph(p\d*|tml)$ {
                        try_files /does_not_exists @fallback;
                        include /etc/nginx/vhosts-resources/site.ru/*.conf;
                }

                location / {
                        try_files /does_not_exists @fallback;
                        include /etc/nginx/vhosts-resources/site.ru/*.conf;
                }

                location ~* ^.+\.(jpg|jpeg|gif|png|webp|svg|js|css|mp3|ogg|mpe?g|avi|zip|gz|bz2?|rar|ttf|woff|woff2|ogv|mp4|webm)$ {
                        expires max;
                        try_files $uri $uri/ @fallback;
                }
}


Да, это можно исправить своими руками, редактируя файл конфигурации nginx или поправив шаблоны

/usr/local/mgr5/etc/templates/nginx-vhosts.template
/usr/local/mgr5/etc/templates/nginx-vhosts-ssl.template


Скопировав их из каталога /usr/local/mgr5/etc/templates/default/

И переместив секцию в location /

include {% $INCLUDE_RESOURCE_PATH %};
Но для чего тогда нужны разработчики панели ISPmanager, не совсем понятно.

фото
1

Спасибо за добавление информации. Возможно уже наконец-то разработчики обратят на это внимание и сделают всё как надо т.к. включение это защиты по умолчанию, это похоже на диверсию и многие, кто берёт те же VDS не могут понять почему у них сайты тормозят на пустом месте.