Только тогда не открываются некоторые отечественные сайты. Я так даже не могу зайти на сайт РКН, заявку оставить с блгодарностью за их работу.

Я чё это пишу-то. Просто для истории. А ну как кто-то пойдет искать отзывы - пусть останется в анналах истории, кучка подростков с дешевыми ВПСками положили целый провайдер.

Ну и как обычно вопрос - Роскомнадзор, а где ваши хвалёные ТСПУ? Вот блять, угроза. Где противодейтсвие ей? А параша ваша у них стоит, ютубик вы там стабильно режете.

ПС. Не, когда он работает - к нему, надо сказать, вопросов нет, свои 750 мегабит за сколько там, 600 рублей или около того он честно обеспечивает.

Это дало преимущество: множество повторяющихся POST-запросов с одного IP — именно то, что умеет отсекать fail2ban.

🛠 Создание фильтра

Создаём фильтр:
/etc/fail2ban/filter.d/wordpress.conf

[Definition]
failregex = ^ - - [.] "POST /login/ HTTP/." (200|403|404)

📌 Что делает фильтр?
Он отслеживает POST-запросы к /login/, которые получают коды ответа:

• 200 — успешный доступ (например, фальшивая регистрация)

• 403 — доступ запрещён

• 404 — страницы не существует (спамеры промахнулись)

⚙️ Настройка Jail

Открываем файл:
/etc/fail2ban/jail.local
и добавляем:

[wordpress-register]
enabled = true
filter = wordpress
logpath = /var/log/nginx/domains/site.log
maxretry = 5
findtime = 60
bantime = 36000000
action = iptables[name=wordpress-register, port="http,https", protocol=tcp]

📌 Объяснение параметров:

• enabled = true — включаем правило

• filter = wordpress — имя фильтра без .conf

• logpath — путь к nginx-логу

• maxretry = 5 — допустимое количество попыток до бана

• findtime = 60 — за какой период искать попытки (в секундах)

• bantime = 36000000 — сколько длится бан. Это ~68 лет 😄

• action — блокировка через iptables на порт 80 и 443 (HTTPS)

✅ Проверка фильтра

Перед применением можно протестировать фильтр:

fail2ban-regex /var/log/nginx/domains/site.log /etc/fail2ban/filter.d/wordpress.conf

🚀 Запускаем защиту

Применяем конфигурацию:

sudo fail2ban-client reload
sudo systemctl restart fail2ban (Перезапускать службу не всегда желательно, так как он забывает все заблокированные IP адреса, а это плохо при массированной атаке, поэтому рекомендую использовать только fail2ban-client reload, где обновляются правила)

📊 Проверяем результат

Проверка статуса:

fail2ban-client status wordpress-register

Пример:

Status for the jail: wordpress-register
|- Filter
| |- Currently failed: 138
| |- Total failed: 6038
| - File list: /var/log/nginx/domains/site.log - Actions
|- Currently banned: 821
|- Total banned: 821
`- Banned IP list: 1.20.227.66 101.126.80.238 ...

Если видите IP — значит, fail2ban работает.

Дополнительно можете проверить цепочку в iptables:

sudo iptables -L f2b-wordpress-register -n

После этого наш фанат решил проявить смекалку и нам пришлось создать еще несколько правил.

Открываем файл:
/etc/fail2ban/jail.local
и добавляем:

[wordpress-ddos]
enabled = true
filter = wordpress-ddos
logpath = /var/log/nginx/domains/site.log
maxretry = 5
findtime = 60
bantime = 36000
backend = auto
action = iptables[name=wordpress-ddos, port="http,https", protocol=tcp]

[hestia-ddos]
enabled = true
filter = hestia-ddos
logpath = /var/log/hestia/nginx-access.log
maxretry = 90
findtime = 60
bantime = 360
action = iptables[name=hestia-ddos, port=8027, protocol=tcp]

[site-ddos-param]
enabled = true
filter = site-ddos-param
logpath = /var/log/nginx/domains/site.log
findtime = 60
maxretry = 2
bantime = 360000
action = iptables[name=site-ddos-param, port="http,https", protocol=tcp]

[nginx-ddos-errorlog]
enabled = true
filter = nginx-ddos-errorlog
logpath = /var/log/nginx/domains/site.error.log
findtime = 60
maxretry = 3
bantime = 86400
action = iptables[name=nginx-ddos-errorlog, port="http,https", protocol=tcp]

[nginx-referrer-selfip]
enabled = true
filter = nginx-referrer-selfip
logpath = /var/log/nginx/domains/site.log
findtime = 60
maxretry = 1
bantime = 2592000 # 30 дней
action = iptables[name=referrer-selfip, port="http,https", protocol=tcp]

Все правила писали через регулярные выражения

/etc/fail2ban/filter.d/hestia-ddos.conf
[Definition]
failregex = ^ - - [.] "." [2-5][0-9]{2} .*

/etc/fail2ban/filter.d/site-ddos-param.conf
[Definition]
failregex = ^ - - [.] "GET /?\d{5,} HTTP/." [2-5][0-9]{2} .*

/etc/fail2ban/filter.d/nginx-ddos-errorlog.conf
[Definition]
failregex = ^\d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2} [error].access forbidden by rule, client: , server: ., request: "GET /?\d{6,} HTTP/1.1"

/etc/fail2ban/filter.d/nginx-referrer-selfip.conf
[Definition]
failregex = ^ - - [.] "GET ." \d+ \d+ "https?://.100.90.80.70."

🚀 Договариваемся с nginx

Так же часть запросов ?78698675876 грузили сервер, т.е. Fail2ban пропускал запросы к серверу из-за того, что трафика было много, но мы это решили делать пересылку на 403 запрос, что бы экономить ресурсы сервера

Открываем файл:
/etc/nginx/conf.d/domains/site.ssl.conf
и добавляем:

Между блоком

server {

...

#Slait
# Блокировать запросы с реферером, содержащим наш IP
if ($http_referer ~* "100\.90\.80\.70") {
return 403;
}

# Блокировать GET-запросы типа /?123456 (только цифры в query string)
if ($request_uri ~* "^/\?\d{9,}$") {
return 403;
}
#Slait

...
}

Применяем конфигурацию:
sudo systemctl restart nginx

🎉 Итог

Fail2ban помог нам перехватить атаку в реальном времени, за считанные минуты блокируя сотни IP-адресов. Простая настройка и мощный результат — рекомендуем!

На данный момент сайт yummy-anime.ru может быть недоступен у некоторых пользователей из-за DDoS-атаки.

Наша команда уже работает над устранением проблемы и делает всё возможное, чтобы как можно скорее восстановить стабильную работу сервиса.

Спасибо за ваше понимание и поддержку!

Есть разные виды DDoS, и каждый из них перегружает сервер по-своему. Атака на уровне L7 — это попытка заставить веб-сервер тратить ресурсы на обработку множества запросов. В результате страница загружается медленнее или вовсе перестает открываться. Именно с такими мы сталкиваемся чаще всего.

Дмитрий Никонов, руководитель направления защиты от DDoS-атак на уровне веб-приложений в DDoS-Guard:

Развитие ботнетов привело к колоссальному росту пиковой мощности вредоносных всплесков. Одна из крупнейших L7-атак, которую мы фиксировали, менее чем за 10 секунд своей длительности достигла почти 23 млн rps. Если раньше жертвами таких DDoS-атак становились только гиганты типа Youtube, теперь от них не застрахованы даже сайты небольших компаний в регионах.

L3-атака перегружает интернет-канал ресурса, засыпая его огромным количеством данных, как если бы тысячи людей одновременно начали звонить на один номер. L4-атака бьет по соединениям сервера, заставляет его тратить ресурсы на бесполезные запросы, словно толпа бесконечно стучит в дверь, но никто не заходит.

Как нас защищает DDoS-Guard (спойлер: мы даже не замечаем)

Для Пикабу тестировали много разных методов защиты, но остановились на отечественном сервисе DDoS-Guard. Мы подключили защиту сайта, которая включает постоянную фильтрацию как L7-трафика, так и L3-4.

Как работает защита «под капотом»:

• все запросы анализируются для выявления источников вредоносного трафика, таких как сети без контроля IP-адресов, уязвимых серверов и ботнетов;

• проанализированный трафик проходит через каскад фильтров на сетевых (L3-4) и прикладном (L7) уровнях. Вредоносные запросы блокируются до достижения серверов, оборудования клиентов и посетителей их веб-ресурсов;

Если запрос выглядит подозрительно, но может исходить от реального пользователя, система предлагает пройти CAPTCHA. Это финальный этап фильтрации, который позволяет настоящим посетителям зайти на сайт даже во время атаки и снижает вероятность ошибочной блокировки. Достаточно один раз подтвердить подлинность, чтобы продолжить пользоваться ресурсом без задержек. Так система постоянно обучается, чтобы точнее отличать пользователей от автоматизированных атак.

Единственное, что может понадобиться от читателя, — обратить внимание на экран с надписью «Подтвердите, что вы не робот».

В защиту DDoS-Guard входят инструменты для управления трафиком и возможность создания кастомного каскада правил для защиты от нелегитимных запросов.

• Правила защиты — ограничивают конкретные типы запросов или добавляют исключения.

• Сегментация сайта — разделение домена на сегменты по типу контента для более точного срабатывания алгоритмов защиты.

• Лимит запросов (rate limiter) — модуль ограничения частоты запросов с настройками параметров запроса и группировкой по источникам.

Пригодилась и функция «Активной балансировки». Например, недавно в основном дата-центре «Пикабу» были аварийные работы: сеть легла, все серверы стали недоступны. Системы DDoS-Guard мгновенно зафиксировали проблему и автоматически перевели весь трафик на резервный дата-центр. Для пользователей ничего не изменилось — сайт продолжал работать, мемы загружались, комментарии писались.

С переходом под защиту DDoS-Guard Пикабу повысил свою устойчивость к DDoS-атакам. Если несколько лет назад сайт мог «лежать» часами и доступ к нему приходилось отключать некоторым странам, то сейчас восстановление работы занимает секунды.

Теперь борьба с DDoS-атаками для Пикабу выглядит так: техническая команда увидела в отчете, что недавно была атака. Конец.

Не защитой единой живы

Кроме DDoS-защиты «Пикабу» были необходимы инструменты для диагностики и управления трафиком. Поэтому нужно было:

1. Предусмотреть сценарий, при котором пользователь может предоставить подробные данные о своем подключении, если с ним возникли проблемы. В этом случае команда поддержки сможет быстрее диагностировать и решить проблему.

2. Сделать систему анализа трафика более прозрачной, чтобы можно было самостоятельно изучать запросы в случае необходимости и корректировать правила фильтрации

Специалисты DDoS-Guard разработали и внедрили решение, которое упростило анализ трафика. В него вошли следующие компоненты:

1. Уникальный Request ID: каждому запросу, проходящему через нашу сеть, присваивается уникальный идентификатор, например, request ID: mwpt7a4coqKjiRxZ.

2. Сервисные страницы с деталями запроса: например, на страницы с капчей или ошибками добавляется информация о запросе:

• Request ID

• IP-адрес пользователя (например, IP: 185.178.209.197)

• Временная метка (например, Time: 2024-10-21 16:19:41 UTC)

Данные передаются через куки, чтобы JavaScript на странице мог их извлечь и отобразить пользователю. Теперь сервисные страницы с деталями запроса помогают пользователям передавать нужную информацию.

Диагностика проблем стала быстрее. Можно просто скопировать данные со страницы или сделать скриншот. Детальный анализ запросов позволил сократить число ложных срабатываний системы защиты.

Атаки с каждым годом все сложнее, но мы не сдаемся

Развитие технологий делает атаки сложнее, дешевле и доступнее. Злоумышленники даже могут организовывать их с целью разведки и проверки устойчивости защиты сервиса.

Важно не только обеспечить сайт надежной защитой от DDoS, но и взять под контроль трафик, чтобы отслеживать любые аномалии и всегда понимать, что происходит.

Поэтому на первый план выходят грамотное управление трафиком и гибкие настройки правил фильтрации:

Дмитрий Никонов, руководитель направления защиты от DDoS-атак на уровне веб-приложений в DDoS-Guard:

Если раньше потребности наших клиентов в основном составляла защита от DDoS-атак, то теперь в приоритете — многовекторное управление трафиком с возможностью создания правил, учитывающих специфику проекта. Это мотивирует нас развивать гибкость продукта и охватывать все больше направлений работы с трафиком.

Пикабу работает с высокой нагрузкой, но наши пользователи больше не замечают задержку в загрузке страниц или сбоев в работе сайта.

Узнайте больше о возможностях DDoS-Guard