NGINX и анкорные ссылки (решетки)

Автор andreyzlat, 13-11-2018, 07:26:11

« назад - далее »

andreyzlatTopic starter

Заметил проблему прихода GET запроса с одной очень известной программы парсинга (не буду называть ее имени).
В спике парсинга имеется URL вида https://site.com/userpage/#go-to
Сейчас все гиперумы мне в одночасье кинут учебник и скажут, что такие запросы не проходят, это чисто браузерная фича.
А вот не тут то  было ребята, и главное ответа найти не могу, что делать.

Конфиг Nginx + php5-fpm.

Проблема с движком Wordpress. В этой тугодумной каракатице на приличном сервере сложно получить генерацию html более чем 3 страницы в секунду. Это бегемот. Поэтому задействую естственно кэш, попробовал WP Super Cache, норм, но не умеет кэшить GET запросы.
Узнал про W3 Total Cache - умеет. Но на деле только в режиме Basic - это когда кэш считывается не самим Nginx, а запрос приходит на php и считывается закэшенный php файл. (Может вообще кто-то научился сохранять GET в кэш для NGINX, например, используя md5 ?)

Так вот... в клочке лога NGINX вот такое чудо: "GET /userpage/?#go-to" т.е. мы видим как на NGINX поступил запрос с якорной ссылкой! Но, он перед якорем поставил вопросительный знак, как бы эмулируя GET запрос, изначально в запросе его не было. (возможно вопросительный знак поставила прога парсинга).

W3 такой запрос кэшит в режиме Basic (php кэш), и такой запрос абсолютно не равен запросу без якоря, т.е. под него создается отдельный кэш файл, как отдельного урла. Бред? Как понимаете абсолютно нет.

Кэшить в режиме Enchanced не получается, это режим когда файлы сохраняются в виде html, и считываются из кэша непосредственно NGINX без участия php. Так работает и WP Super Cache. В кэше создает один файл html равный урлу страницы, без учета корной ссылки. Соответственно корявый не по фэн шую запрос с якорной сылкой не попадает в такой кэш. Это для него абсолютно другой урл.

И вот здесь главная проблема: если на сайте таких ссылок много, а их там в разы больше чем нормальных, то при сканировании сайта (парсинге) сайт просто уходит в астрономический Load Average под 20, тормозя весь сервер. Это по сути для него DDos. Т.е. каждый такой запрос якорной ссылки заставляет каждый раз напрягаться php и генерировать страницу в обход кэша.
"GET /userpage/?#go-to"
"GET /userpage/?#go-to1"
"GET /userpage/?#go-to2"
Это всё будут разные страницы и для php.
Проверил на отдачу, что действительно php получает именно этот запрос, а не редиректит на главную или 404, он ее действительно получает запрос вместе с якорным анкором.
Что делать? Как отсеять такой мусор?

Конфиг NGINX не понимает запрос в виде решетки или ее аналоге %23. Ни в обычном режиме, не в режиме регулярных выражений.

Если бы NGINX выдавал не код 200 на подобную ерунду, может быть и проблемы не было или было меньше.

Подскажите заодно из своих логов, яндекс и прочие нормальные боты, они делают анкорные-якорные запросы?

Добавлено: 13-11-2018, 21:48:10


В общем справился простым решением.... fail2ban
Кому надо, правило filtrs.d, проверил, всё четко работает:

[Definition]
failregex = ^<HOST> -.*#.*HTTP.*
ignoreregex =


Тем не менее считаю это глюком NGINX... точнее небольшой недоработкой в области стандартов передачи

Подключать к ipset не стал, не велика беда. Тоже самое правило можно сделать на частые ответы 404 и т.п.., а также всплески запросов к ajax-admin.php.... эти штуки положат любой не подготовленный сайт.


Добавлено: 13-11-2018, 21:51:41


Сейчас подумываю над тем, как банить тех, кто скажем за 20 секунд совершил 5-10 медленных тяжелых запросов... понятно, что это не человек, а бот.
8)
Лог мускуля на fail2ban не айс, нужно ловить не запросы к БД, а запросы к php-fpm или nginx

:police: вoйна ботам, сканерам
  •