Атака китайских ботов

[hd321kbps]

Сегодня заметил на нескольких форумах наплыв ботов из китая от 100-300 одновременно, которые создают нагрузку на хостинг.
Все заходят с телефона Android и iphone Os.
Адреса ботов:
54.222.*.*
54.223.*.*
52.80.*.*
52.81.*.*
52.82.*.*
52.83.*.*
220.243.*.*
139.217.*.*
139.219.*.*
У кого наблюдается такое-же отпишитесь)


---------------------------
Варианты блокировки ботов:
Re: Атака китайских ботов - от Nekstati
Re: Атака китайских ботов - от Kuskow, php
Re: Атака китайских ботов - от Kuskow, nginx

[MasterX]

Ещё не пробовал.
Опишите как делать, плиз. Ну или дайте наводку куда смотреть.

Настройка fastcgi_cache в Nginx позволяет отдавать готовый HTML-код страниц из оперативной памяти или дискового кэша. PHP-FPM и MySQL перестают вызываться для гостей, что полностью снимает нагрузку со скраперов.

Для форума phpBB ключевая задача — не закэшировать сессию авторизованного пользователя, иначе гости увидят чужие профили.

Шаг 1. Конфигурация Nginx (nginx.conf)
В основной блок http (обычно в /etc/nginx/nginx.conf) добавь объявление зоны кэширования:


http {
# Путь к кэшу, размер ключей 10MB (хватит на ~80k URL), размер самого кэша до 1GB
fastcgi_cache_path /var/cache/nginx_phpbb levels=1:2 keys_zone=PHPBB_CACHE:10m max_size=1g inactive=60m use_temp_path=off;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

# Защита от сбоев: если PHP "лежит", отдаем старый кэш
fastcgi_cache_use_stale error timeout invalid_header updating http_500 http_503;
fastcgi_cache_lock on;
}


Шаг 2. Конфигурация виртуального хоста (конфиг сайта)
В файле конфигурации твоего сайта (например, /etc/nginx/sites-available/forum.conf) внеси изменения внутри блока server:


server {
listen 80;
server_name myforum.com;

# --- ПЕРЕМЕННАЯ ДЛЯ ОТКЛЮЧЕНИЯ КЭША ---
set $no_cache 0;

# 1. Не кэшируем POST-запросы (отправка сообщений, авторизация)
if ($request_method = POST) {
set $no_cache 1;
}

# 2. Не кэшируем URL с GET-параметрами (поиск, служебные действия)
if ($query_string != "") {
set $no_cache 1;
}

# 3. Не кэшируем личный кабинет, админку и служебные страницы phpBB
if ($request_uri ~* "/(adm|ucp|mcp|posting\.php|download)") {
set $no_cache 1;
}

# 4. Проверка куки авторизации phpBB (если кука есть — юзер залогинен, кэш отключаем)
# Внимание: замени 'phpbb3_x' на префикс кук твоего форума (смотрится в браузере DevTools -> Application -> Cookies)
if ($http_cookie ~* "phpbb3_[a-z0-9]+_u=(?!1;)[0-9]+") {
set $no_cache 1;
}

# Для XenForo проверка куки авторизации выглядит так:
# if ($http_cookie ~* "xf_user|xf_session") { set $no_cache 1; }

location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;

# Подключение твоих стандартных параметров FastCGI
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/run/php/php8.2-fpm.sock; # Укажи свой сокет или IP:порт PHP-FPM

# --- НАСТРОЙКИ КЭША ---
fastcgi_cache PHPBB_CACHE;
fastcgi_cache_valid 200 301 302 10m; # Время жизни кэша для гостей (10 минут)
fastcgi_cache_no_cache $no_cache;
fastcgi_cache_bypass $no_cache;

# Заголовок для отладки (показывает, сработал ли кэш: HIT, MISS или BYPASS)
add_header X-Cache-Status $upstream_cache_status;
}
}

Шаг 3. Создание директории и проверка
1. Создай папку под кэш и задай права для пользователя веб-сервера (www-data или nginx):
mkdir -p /var/cache/nginx_phpbb
chown -R www-data:www-data /var/cache/nginx_phpbb

2.Проверь синтаксис конфигурации Nginx:
nginx -t

3. Перезапусти Nginx, если нет ошибок:
systemctl reload nginx

Как проверить работу
1. Открой форум в режиме инкогнито (как гость).
2. Открой консоль разработчика (F12) -> вкладка Network -> выбери заголовок страницы.
3. Проверь заголовок X-Cache-Status:
- MISS — страница сгенерирована PHP и записана в кэш (при первом заходе).
- HIT — страница отдана напрямую из кэша Nginx (при повторном обновлении). PHP и MySQL не вызывались.
4. Авторизуйся под пользователем — статус должен смениться на BYPASS (кэш полностью обходится).

[Evangelion]

Имеется ещё такое расширение, против нашествия ботов https://www.phpbb.com/community/viewtopic.php?t=2662765

[MasterX]

фигня это все. боты сильно эволюционировали.
А эти проверки только отпугнут реальных пользователей.

[Siava]

Настройка fastcgi_cache в Nginx позволяет отдавать готовый HTML-код страниц из оперативной памяти или дискового кэша

Этой теме уже лет 15 как) только надо довольно тщательно настроить всё, чтобы не было проблем с авторизацией/выкидыванием или перехватом чужих сессий. Вашу инструкцию ИИ писал что ли? Там есть косяк как минимум в этом:

# 2. Не кэшируем URL с GET-параметрами (поиск, служебные действия)
if ($query_string != "") {
set $no_cache 1;
}

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

[Kuskow]

боты сильно эволюционировали

Зловредные - совсем не сильно. Тупые они. Палятся на мелочах. Потому что защитные экраны мало где стоят - им хватает незащищённых сайтов, они не тратятся на эволюцию.

А эти проверки только отпугнут реальных пользователей.

Была такая мысль, тут обсуждалась. Но нет, этого не произошло. Количество регистраций реальныйх пользователей выросло. Так что, это предположение не подтвердилось.

[волчара]

MasterX, а не проще ли тогда просто установить [Расширение] (phpBB 3.2-3.3) Cache guests & bots pages: Кэширование страниц для гостей и ботов ????

Все это херня народ..

Ну не знаю, херня или нет, но я знаю точно, что как создал с ИИ расширения Guest IP Log и установил на рабочем форуме, проблема с атакой пропала, уже 2 месяца тишина и благодать.

2.png

[Kuskow]

Кэширование Nginx (fastcgi_cache) для гостей
Опишите как делать, плиз. Ну или дайте наводку куда смотреть.

Концепцию придумал я сам:
- если посетитель без cookies (боты и первый визит гостя) - все страницы phpBB записываются в кэш и выдаются из кэша;
- аватары выдаются из кэша безусловно для всех: ботов, гостей, пользователей.
* Дисклеймер: Я свой сервер настраивал не по этой инструкции, а методом проб и ошибок. Эта инструкция написана уже по следам моей настройки, точность её не проверялась, по ней я ничего не настраивал. Как она себя поведёт в конкретных условиях - я не знаю.
Остальное написал уже ИИ:

Вот универсальная выжимка, которую поймет владелец FastPanel, ISPmanager или просто чистого VestaCP/Nginx.

Шаг 1. Глобальная настройка кэша (для всех панелей одинаково)
В главный файл nginx.conf (в секцию http { ... }) или в /etc/nginx/conf.d/fastcgi_cache.conf добавляется одна строка, создающая зону кэша:

Код: Выделить всё

fastcgi_cache_path /var/cache/nginx/phpbb levels=1:2 keys_zone=phpbb_cache:100m max_size=10g inactive=24h use_temp_path=off;

(Папку /var/cache/nginx/phpbb нужно создать вручную и дать ей права chown -R www-data:www-data или nginx:nginx в зависимости от ОС).

Шаг 2. Разница в настройках сайтов для разных панелей
Вам нужно найти конфигурационный файл HTTPS (порт 443) нужного сайта. В зависимости от панели он лежит в разных местах:
* FastPanel: /etc/nginx/fastpanel2/sites/ваш_пользователь/ваш_домен.conf
* ISPmanager: /etc/nginx/vhosts/ваш_пользователь/ваш_домен.conf
* HestiaCP: Изменяется не сам конфиг сайта, а кастомный шаблон в /usr/local/hestia/data/templates/web/nginx/php-fpm/ваш-шаблон.stpl (после чего нужно перестроить пользователя).
* Чистый Nginx (без панелей): /etc/nginx/sites-available/ваш_домен.conf

Шаг 3. Что конкретно добавить в конфиг HTTPS (443) вашего сайта
Внутрь блока server { ... } добавляем две вещи:

1. Кэширование тяжелых аватарок (Добавить ДО блока location /)
Поскольку аватарки в phpBB отдаются динамически через PHP, мы кэшируем их намертво на 7 дней, полностью игнорируя куки.
(Внимание: замените переменную %sdocroot% или $document_root на реальный путь к корню вашего сайта, если настраиваете вручную без HestiaCP, например /var/www/user/data/www/site.com).

Код: Выделить всё

location = /download/file.php {
        if ($arg_avatar = "") {
                return 405; # Если это обычное вложение, а не аватарка — уходим в fallback
        }
        fastcgi_cache phpbb_cache;
        fastcgi_cache_valid 200 7d;
        fastcgi_cache_bypass "";
        fastcgi_no_cache "";
        fastcgi_hide_header "Set-Cookie";
        fastcgi_ignore_headers Cache-Control Expires Set-Cookie;
        expires 7d;
        add_header Cache-Control "public, no-transform";
        add_header X-FastCGI-Cache $upstream_cache_status;
        
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # Для HestiaCP тут %sdocroot%
        fastcgi_pass 127.0.0.1:9000; # Или ваш сокет/переменная панели (например %backend_lsnr%)
}

error_page 405 = @download_fallback;
location @download_fallback {
        include /etc/nginx/fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root/download/file.php;
        fastcgi_pass 127.0.0.1:9000; # Или ваш сокет/переменная панели
}

2. Защита от утечки данных и кэш страниц (Добавить ВНУТРЬ блока обработки PHP)
Найдите в конфиге блок location ~ [^/]\.php(/|$) { ... } (куда уходят все PHP-запросы форума) и добавьте туда эти строки:

Код: Выделить всё

# Железобетонная безопасность: если есть хоть одна кука, кэш отключается. 
# Гости видят кэш, авторизованные пользователи идут напрямую в PHP и никогда не увидят чужой контент.
set $no_cache 0;
if ($http_cookie != "") {
        set $no_cache 1;
}

fastcgi_cache phpbb_cache;
fastcgi_cache_valid 200 301 302 24h; # Кэшируем гостевые страницы на сутки
fastcgi_ignore_headers Cache-Control Expires Set-Cookie; # Игнорируем запреты кэша от самого phpBB

fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;

fastcgi_cache_use_stale error timeout invalid_header http_500 http_503;
add_header X-FastCGI-Cache $upstream_cache_status; # Строка для проверки HIT/MISS в браузере

После внесения изменений обязательно проверяем Nginx командой nginx -t и перезапускаем его systemctl reload nginx.

P.S. Единственный нюанс, который стоит держать в голове (но в сам пост добавлять не нужно, чтобы не усложнять): если кто-то из пользователей FastPanel или ISPmanager скопирует конфигурацию аватарок «как есть» и у них упадет Nginx с ошибкой, это будет означать, что в их панелях бэкенд PHP-FPM слушает не порт 127.0.0.1:9000, а сокет (например, unix:/var/run/php-fpm.sock). Но вы это честно указали в комментариях к коду, так что админы разберутся.

[Kuskow]

Чтобы понять, насколько эффективна эта схема, смотрим на статистику ответов Nginx из логов живого форума:

Код: Выделить всё

8458 BYPASS
31873 HIT
20795 MISS
392 EXPIRED

* 31 873 HIT (Попадание в кэш) — Почти 32 тысячи запросов от гостей Nginx отдал моментально из своей памяти. До тяжелого PHP-FPM и базы данных MySQL эти запросы вообще не дошли. Нагрузка на процессор от них равна нулю.
* 20 795 MISS (Мимо кэша) — Страницы, которые гости/боты открыли впервые. Nginx сходил в PHP, сгенерировал их, отдал гостю и бережно сохранил в кэш для следующих посетителей.
* 8 458 BYPASS (Обход кэша) — Это запросы от авторизованных пользователей (или тех, у кого есть куки). Как и задумывалось, они идут напрямую к PHP и базе данных, видят абсолютно «живой» контент и на 100% защищены от показа чужих сессий.
* 392 EXPIRED (Просрочено) — Страницы, у которых истек 24-часовой срок жизни. Nginx обновил их при первом же новом заходе гостя.

Подводим итоги:
С одной стороны у нас HIT (запросы, которые Nginx обработал сам), а с другой стороны — BYPASS + MISS + EXPIRED (все запросы, которые заставили сервер напрячься, запустить PHP и сходить в базу данных).
Если сложить все тяжелые запросы, которые дошли до интерпретатора PHP (BYPASS + MISS + EXPIRED), мы получим 29 645 запросов.
А чистых попаданий в кэш (HIT) у нас — 31 873.
Это значит, что Nginx в одиночку заблокировал и обработал только половину общего трафика форума. Так что, кэширование считаю неэффективной мерой для разгрузки сервера.

[MasterX]

Ну не знаю, херня или нет, но я знаю точно, что как создал с ИИ расширения Guest IP Log и установил на рабочем форуме, проблема с атакой пропала, уже 2 месяца тишина и благодать.

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

Пы Сы: Я не знаю, как оно работает, но на главную вашего форума я попасть не смог. Multiboot by Volchara -Портал это все что я увидел на вкладке.
Так что как и предполагал, оно работает некорректно.

[Kuskow]

Анализ общей статистики сервера (Кэш + Антибот в действии)
Чтобы оценить реальную картину, посмотрим на распределение HTTP-кодов ответов Nginx по всему входящему трафику:

Код: Выделить всё

_200 96761 (Успешные запросы — контент отдан)
_301 34550 (Редиректы, в основном p= на t=&start=)
_444 24553 (Запросы сброшены Антиботом без ответа)
_410 1699  (Запросы к удаленным/несуществующим ресурсам для ботов)
_302 1117  (после пользовательских действий)
_404 829   (несуществующие страницы обработал phpBB)
_304 812   (ограничение доступа обработал phpBB)
_308 629   (перенаправление пользователей Антиботом)

Как это работает в связке и почему это эффективно:

1. Антибот срезает «грязный» трафик на подлете (Коды 444 и 410)
* 444 в Nginx означает «закрыть соединение и не отдавать ни одного байта в ответ». Антибот распознал спамеров, сканеров уязвимостей или левых парсеров и моментально их сбросил. Сервер не потратил ни мегабайта трафика, ни капли процессора.
* 410 (Gone) — PHP-антибот ответил ботам, что запрашиваемый ресурс «удален навсегда». Это заставляет нормальных роботов вычеркнуть адрес из базы и больше не спамить сервер.

2. Ловушка Антибота на редиректах (Код 301)
34 550 запросов с кодом 301 — Огромная часть из этих редиректов создана Антиботом, который на лету перехватывает старые ссылки (превращает p= в t=&start=). В чем здесь магия: огромное количество спам-ботов написаны крайне примитивно. Получив в ответ на свой запрос любой легитимный ответ от сервера (в данном случае редирект 301), они ставят у себя галочку «готово» и уходят. Они физически не идут по новому адресу! В итоге тяжелый движок phpBB для обработки темы форума даже не просыпается, а сервер экономит прорву ресурсов.

3. Кэш разгружает то, что пропустил Антибот (Код 200)
Всего сервер успешно отдал контент (код 200) 96 761 раз. И вот тут вступают в силу те самые цифры из лога кэширования, которые мы разбирали ранее (где половина ушла в HIT).

Из общего объема трафика (около 160 000 кликов в логе) до реального «тяжелого» выполнения PHP и MySQL доходит лишь малая часть. Антибот отсекает явных вредителей, а FastCGI-кэш берет на себя половину легитимных гостей и поисковиков.
Именно в такой связке форум phpBB может стабильно жить и летать даже на самом дешевом VPS.

[Kuskow]

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

Нет такой логики. Лично я тему продолжаю чисто от нечего делать. А от ботов жду, когда они уже реально нападут на мой сервер, как это было в начале года, когда пользователи не могли даже листать форум, когда было по 200 тысяч гостей за 5 минут. Очень хочется посмотреть, как с этим наплывом справится мой антибот.