Nginx правильно настроить, чтобы сложнее было задудосить

jeka_coder

Участники
Сообщения
27
Реакции
4
Баллы
10
подскажите, как правильно настроить чтобы защититься от ddos-атак
 
Да не существует никакого универсального решения. Находите разбирающегося человека и нанимаете его делать свою работу. Либо платите специализированному сервису. Либо разбираетесь сами и крутите сервер, задавая вопросы по конкретным проблемам. Абстракция "как настроить чтоб было збс" тут не подходит
 
Matew, на одном из проектов стоит подготовленный "WAF Rule".
Который отрубает любой запрос если он не из СНГ.
На все остальные запросы - включон Under Attack.

Ну и странные User-Agent`ы тоже отправляются в блок/капчу.

На короткой дистанции работает норм. ¯\_(ツ)_/¯
Да и случается подобное раз в год - это если "повезёт".
 
подскажите, как правильно настроить чтобы защититься от ddos-атак
Самый более менее для тебя вариант это подключить Cloudflare и настроить гео-фильтр, например разрешить доступ только из стран СНГ.
Если хочется заморочиться, то заниматься оптимизацией nginx, ставить какой-нибудь fail2ban, который будет банить через iptables IP с которых идёт много запросов по твоим правилам. Но не всегда это поможет, лучше начать с Cloudflare.
 
Последнее редактирование:
Кто в теме - , подскажите!

Помогает от ddos?
Модуль может помочь в снижении флуд-атак или атак, направленных на исчерпание серверных ресурсов. Но он малоэффективен против крупных распределённых DDoS-атак, где тысячи IP. Все эти настройки работают только в комплексе с другими инструментами.
 
Silerio, упаси господь давать неуку такие статьи. Сейчас накопирует себе и всем селом будем разбирать что он наломал. Кусок статьи неактуален, а про что-то относящееся к защите от дудосов там, внезапно, написано не много.

Потому что, внезапно, это практически ручная работа, требующая анализа и принятия решений по каждой атаке отдельно, если у вас нет разработанных автоматизаций. Сделать «кнопку антидудос» стоит много денег.
 
Самый более менее для тебя вариант это подключить Cloudflare и настроить гео-фильтр, например разрешить доступ только из стран СНГ.
Если хочется заморочиться, то заниматься оптимизацией nginx, ставить какой-нибудь fail2ban, который будет банить через iptables IP с которых идёт много запросов по твоим правилам. Но не всегда это поможет, лучше начать с Cloudflare.
Дополню еще, что если клауд с бесплатным тарифом и включена проксимация (скрытие ip своего сервера), то iptables не поможет, как и локальный fail2ban. Нужен платный тариф на клауде, чтобы была возможность бана на стороне клауда ботовских ip через api, или извращаться на бесплатном тарифе со списками, там есть такая возможность создать список и работать с ним через токен.
 
Pudel, а чем списки не решение?
Я сам этим пользуюсь в связке с самим краудом, отсекает норм. Но бан на Фларе настроен как крайняя мера, первоначально сервер начинает отвечать через Флару капчёй, это хорошо снижает нагрузку.
 
Последнее редактирование:
а чем списки не решение?
Решение, но списки на бесплатном тарифе ограничены + надо писать сценарии для fail2ban на работу с этими списками, готовых решений же нет (как я понимаю), а из коробки есть сценарии только для платного api.
Про crowdsec не знал, интересный сервис, спс.
 
Последнее редактирование:

Отдавать 444 только. Остальное спасает только от DDoS атаки с прокси, но не более. Не нужно плодить еще и исходящий трафик при нагрузке, каналы не резиновые. Модификация сетевого стека - это отдельная большая тема. Вместо линейного iptables -> nftables + eBPF уже используется повсеместно.

и настроить гео-фильтр, например разрешить доступ только из стран СНГ.
По рукам ударить #1

По рукам ударить #2

А теперь подробнее: гео фильтр редко когда необходим, блокировка должна идти только по ASN зараженных сетей, такой список формируется только админами при наработке. Гео бан оправдан только если сервис предназначен для конкретной страны или для локальных пользователей. Блокировать тупо в iptables создавая кучу правил - он упадет, для этого есть ipset.

Нужен платный тариф на клауде, чтобы была возможность бана на стороне клауда ботовских ip через api

Не нужен, есть xtables-addons и модуль xt_HTTP для анализа HTTP-заголовков на уровне iptables, исходные коды открыты для модификации. Тут подробнее хочу сказать, xt_HTTP модифицируется просто и можно прокинуть CF-Connecting-IP или X-Forwarded-For, но только с HTTP трафиком (Flexible), то есть на CF нельзя использовать FULL SSL и так далее. Второй способ – связан с чтением логов на nginx или на iptables через правило string match:

Код:
iptables -t nat -A PREROUTING -p tcp --dport 80 \
    -m string --algo bm --string "CF-Connecting-IP: " \
    -j LOG --log-prefix "Real IP: "


Для блокировки также API открыт для внесения проблемных ASN/IPs.

Есть также и платные решения по типу Spectrum у CF, но кому интересно за деньги?

CrazyHackGUT, списки часто устаревают, но при локальном сборе и обработке - хорошее решение и минимум ложных срабатываний.

Решение, но списки на бесплатном тарифе ограничены + надо писать сценарии для fail2ban на работу с этими списками, готовых решений же нет (как я понимаю), а из коробки есть сценарии только для платного api.
Про crowdsec не знал, интересный сервис, спс.

Зачастую, атаки идут блоками из 2-5 ASN, самые активные IPs проще распарсить и эту нагрузку завернуть через блокировку по ASN. Что касается емкости списков - мне сложно сказать сейчас, если взглянуть на мою портянку в Security -> WAF -> Tools - там достаточно много и я ни разу не сталкивался с лимитами.


Хочу подитожить:
1. Для защиты требуется 2 сервера, принимающий нагрузку и backend приложения.
2. Оптимизация самого приложения, оно вполне может упасть от дуновения ветра без настройки: ограничить обращения к базе данных неавторизированным пользователям, кеши.
3. CF использовать исключительно как прокладку для мнимизации нагрузки на фильтрующий сервер. Он будет бесполезен, если первые 2 пункта не будут учтены. От него нам нужен лишь канал по факту.
4. Если нет никакого мониторинга активности трафика в реальном времени - все может стать бесполезным в один миг.
 
@CrazyHackGUT, списки часто устаревают, но при локальном сборе и обработке - хорошее решение и минимум ложных срабатываний.
Сторонними списками и не пользуюсь. Crowdsec анализирует активность с каждого адреса, и сам составляет их. Список у него правда один, но над каждым "источником вреда" в моём случае применяется или капча именно со стороны веб-сервера (как превентивная мера, чтобы разгрузить интерпретатор и MySQL), или полный блок на Фларе.

Зы: Я не спроста обернул "источник вреда" в кавычки. Crowdsec по каждому подозрительному адресу смотрит сразу размер префикса в базах RIPE, так и номер автономки (база лежит локально, я её эпизодически обновляю). Когда он видит явно, что вредит не один адрес из подсети, то группирует наказание в подсеть. Если и подсеть не одна, то улетает целая автономка.
 
тоже используем CrowdSec, правда в таком варианте
Не грузит сервер? Не банит легитивных пользователей? Никогда просто эту штуку не юзал. Как я понял она максимально юзерфрендли, настраивать ничего не надо достаточно выполнить пару команд?
curl -sL | sudo bash
sudo apt install crowdsec -y
filenames: - /var/log/nginx/access.log - /var/log/nginx/error.log labels: type: nginx sudo systemctl restart crowdsec sudo apt install crowdsec-firewall-bouncer-iptables -y sudo systemctl restart crowdsec-firewall-bouncer
 
Современный облачный хостинг провайдер | Aéza
Назад
Сверху Снизу