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

[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

[Kuskow]

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

https://www.phpbbguru.net/community/viewtopic.php?p=572251&sid=df6bdddf6b10c994162313d5689e21d1#p572251
https://www.phpbbguru.net/community/viewtopic.php?p=572251&sid=888bbbbf6b10c994162313d5689e9876#p572251

Для кэша это две разные страницы, которые будут сохранены отдельно и отданы из кэша только при полном совпадении sid=. Но для форума и сайта это одна страница, содержимое и внешний вид которой не нужно генерировать заново, если другие пользователи запросят её. Если не чистить sid=, hilit=, view=, то кэш на стороне сервера будет бессмысленным и неэффективным, потому что не будет совпадений адреса страницы именно из-за этих sid=. И боты именно это и стараются сделать - максимально разнообразить запросы, чтобы движок phpBB напрягался. А кэш делается для того, чтобы повторяющиеся запросы не передавать для генерации в PHP, а выдавать сохранённую ранее сгенерированную копию. Так вот, чтобы повторения случались чаще, нужно очистить URL от параметров, не влияющих на отображение.

[волчара]

После того как я добавил блокировку согласно этой инструкции Re: Атака китайских ботов, количество гостей не доходит и до 200 за сутки, как то аж подозрительно. До того как мой форум стал долбить gptBot, у меня максимум 1,5 тысячи за сутки набегало, а тут тишь да гладь , ведать всех "паразитов" блокирует

[Vlad__]

Для кэша это две разные страницы

Я это понимаю, вопрос был в другом. Кэш у вас, как я понял, в nginx, а url "чистите" в php.
nginx стоит перед php, поэтому логичнее "чистить" url средствами nginx, потому что php бэкенд для него, и очистка там не совсем понятна.

Грубо говоря, nginx кеширует страницы с sid=aaa, sid=bbb, sid=ccc как разные, и ему по барабану, что дальше вырезается в самом php. Это второй для него уровень.

Или как вы это все увязали?

[Kuskow]

количество гостей не доходит и до 200 за сутки

Наконец-то Вы увидели, сколько их реально. А не то, что было раньше, даже до всех атак это число было неправильным.

До того как мой форум стал долбить gptBot

GPTBot хороший - пусть долбит, это недолго, он не агрессивный и можно отключать в robots.txt.
ChatGPT - плохой, потому что наивный - его используют плохие, и он именно долбит без разбору и без правил.

видать всех "паразитов" блокирует

Теперь действительно всех. В первой версии было не всех, потому что бывают боты, которые запоминают и передают куки phpBB. А начиная со второй версии внедрена кука, которая не используется в phpBB и формируется не сервером, а Java, поэтому она может быть только у людей.

[Kuskow]

Кэш у вас, как я понял, в nginx

Да, его там специально настраивал. Если нет доступа к root сервера, то настроить его невозможно. И провайдер web-хостинга не будет это делать.

а url "чистите" в php

Потому что такую "сложную" логику организовать в правилах Nginx невозможно - это задача только для языков более высокого уровня.

nginx стоит перед php, поэтому логичнее "чистить" url средствами nginx

1) Да, логичней, если можно было прописать в Nginx то, что написано в PHP.
2) Этот скрипт для всех, а не только для тех, кто имеет доступ к Nginx.

php бэкенд для него, и очистка там не совсем понятна

У меня и блокировка есть как в Nginx, так и в PHP. Первый больше для дела, второй для души и для сообщества. Чтобы всем.

nginx кеширует страницы с sid=aaa, sid=bbb, sid=ccc как разные, и ему по барабану

Да, только для того, чтобы из закешировать, нужно выполонить всё это три раза в phpBB. И толку в этом кэше нет, потому что повторно эти страницы запрошены не будут (ну может быть только пару раз). А суть кэша, чтобы страницы при повторе отдавались из кэша, а не из phpBB. Поэтому одинаковые страницы должны быть с одинаковым URI.

Или как вы это все увязали?

Кэш Nginx технически никак не связан с очисткой и с этим скриптом в config.php. Я их не увязывал. Переадресация в PHP должна сделать так, чтобы запросы одинаковых страниц, попавшие в phpBB, были с одинаковыми URI. Больше никакой связи и связки с Nginx нет. А уже кэш Nginx, который работает отдельно и не знает, что есть какой-то мой скрипт в PHP, только кэширует и всё.
То есть, Вы напрасно ищеме связь между этим скриптом PHP и настройками Nginx. Они друг другу помогают, но действуют совершенно отдельно самостоятельно.

[Vlad__]

Потому что такую "сложную" логику организовать в правилах Nginx невозможно

Без комментариев )

Они друг другу помогают, но действуют совершенно отдельно самостоятельно.

Ладно, проехали. Вы так и не поняли мою мысль.

[Kuskow]

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

[волчара]

GPTBot хороший - пусть долбит

Не не, очень даже нехороший, он то мне и положил форум судя по логам, а вот ChatGPT даже рядом не было, только GPTBot долбил.

[Kuskow]

74.7.242.1 - - [18/Jun/2026:21:56:03 +0300] "GET /viewforum.php?f=32&sid=03e566f3aa0df2a7e3c1590955fb380e HTTP/1.1" 404 153 "http://sibir-omsk.ru/viewforum.php?f=62 ... 98af13fabd" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; GPTBot/1.4; +https://openai.com/gptbot)"

Это не настоящий GPTBot. Перед нами классический спуфинг юзер-агента (User-Agent Spoofing). Злоумышленник или спам-бот намеренно маскируется под официального робота OpenAI, чтобы обойти блокировки или не привлекать к себе лишнего внимания. На то, что это фальшивый бот (Scraper/Exploit Scanner), указывают сразу несколько неопровержимых фактов:

## 1. Сканирование сессий (sid=)
Официальный краулер GPTBot ходит исключительно по «чистым», статическим URL-адресам, которые он находит в карте сайта (sitemap.xml) или в коде страниц. Он принципиально игнорирует динамические идентификаторы сессий (sid=) в ссылках.
А вот фальшивый бот просто бездумно «парсит» все ссылки подряд из HTML-кода вашего форума phpBB (где ссылки для гостей часто содержат sid) или пытается подобрать активную сессию. [1]

## 2. IP-адреса не принадлежат OpenAI
* 74.7.242.1: Этот IP-адрес принадлежит американскому провайдеру Charter Communications (коммерческий кабельный интернет Spectrum). Настоящие боты OpenAI работают только из специализированных дата-центров (в основном Microsoft Azure), а не со стандартных домашних или офисных IP-линий США. [2]

## 3. Версия GPTBot/1.4
Официальный робот OpenAI использует строку GPTBot/1.0. Появление в логах несуществующей версии GPTBot/1.4 — это явный признак того, что скрипт парсера написан сторонним разработчиком «на коленке».

[волчара]

О как

[Ne_Guru]

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

Черт знает что...
Похоже на DDOC-атаку


Завтра буду разбираться...

Я обратился в техподдержку форума.
Мне дословно сказали следующее:

Основная причина повышения нагрузки - множество запросов из подсетей ACEVILLEPTELTD-SG и Alibaba Cloud к сайту cubanos.ru:

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

[u-0][21/Jun/2026:00:32:27 +0300] 0.000 0.008 200 43.173.180.159 cubanos.ru GET /forum/rpquncls?validate_bot=600fce77c005b7dba78bc18fa660d105&validate_bot=a9945b693b84e4be50faa53a1bf813cf HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/131.0.0.0 Safari/537.36" "https://cubanos.ru/forum/rpquncls?validate_bot=600fce77c005b7dba78bc18fa660d105" 694 193.168.131.166 cubanos
[u-0][21/Jun/2026:00:32:27 +0300] 0.000 0.021 200 43.173.177.96 cubanos.ru GET /forum/lhjfdrbu?validate_bot=db8990cb4498afd56128974cdcc00600&validate_bot=509554367767862db16194d819b7803c HTTP/1.1 "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/105.0.0.0 Safari/537.3" "https://cubanos.ru/forum/lhjfdrbu?validate_bot=db8990cb4498afd56128974cdcc00600" 697 193.168.131.166 cubanos

Для фильтрации подобных запросов добавьте правило в файл .htaccess в директории сайта:

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

<RequireAll>
Require all granted
Require not ip 43.173.0.0/16
Require not ip 47.82.0.0/16
Require not ip 43.172.0.0/16
</RequireAll>

Я вставил этот фрагмент в файлы .htaccess в директории сайта и в директории форума (у меня всегда атаки почему-то идут исключительно на форум, не на сайт) и сейчас ситуация такая:

stat2.jpg

stat3.jpg

И защиту от DDOS-атак платную я тоже убрал, потому что она вообще никак в данном случае на ситуацию не влияла.

[Kuskow]

Без комментариев )

Есть ещё один момент. Обращения к / или /index.php с любыми параметрами надо не очищать, а отклонять. То есть, все отлупы должны идти до очистки.
Так что, всё же, очистка URI от мусорных параметров должна быть в PHP, а не в Apache/Nginx.

[Vlad__]

Kuskow, ну тогда вообще ничего очищать не нужно, параметры до php доходить не будут, раз nginx все такое отклонит.

[Kuskow]

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

$ua = $_SERVER['HTTP_USER_AGENT'] ?? '';

Тут, конечно, надо было написать так (включу в следующую версию):

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

$ua = $_SERVER['HTTP_USER_AGENT'] ?? 'python';

[Kuskow]

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

# 1. Шлагбаум закрыт для плохих ботов, методов и запросов
!preg_match('#/$|/(index|file)\.php|/view(forum|topic)\.php\?[ftp]=|webpush#i', $uri)
+preg_match('#ChatGPT|keys-so|python|Firefox\/72#i', $ua)
and exit(http_response_code(403));

Слегка надстроил забор, добавил пару плюсиков, теперь ещё больше ботов не могут перепрыгнуть. решение, как обычно, спорное. Требуется критика.

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

# 1. Шлагбаум закрыт для плохих ботов, методов и запросов
!preg_match('#/$|/(index|file)\.php|/view(forum|topic)\.php\?[ftp]=#i', $uri)
+preg_match('#ChatGPT|keys-so|python|Firefox\/72#i', $ua)
+preg_match('#/\?|/index\.php\?|sid=#i', $uri)
+(isset($_SERVER['HTTP_SEC_FETCH_SITE']) < isset($_SERVER['HTTP_REFERER']))
and exit(http_response_code(403));