Как на лету изменять страницы, которые отдаются ботам, делающим слишком много запросов?

Question

[Андрей]

Сейчас слишком активные боты и парсеры отсекаются через limit_req_zone $binary_remote_addr zone=one:10m rate=2r/s;
Хочу сделать так, чтобы страницы им отдавались, но с искаженной информацией. Допустим, замена текста в определенном блоке на другой.
Или другой путь - может ли Nginx добавить специфичный HTTP-хедер в запросы от таких ботов? Тогда я изменю выдачу на уровне веб-приложения.

Comments

[#]

Хочу сделать так, чтобы страницы им отдавались, но с искаженной информацией.

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

[Андрей]

Это парсеры, боты поисковиков не делают таких частых запросов с одного айпи.

Answer 1

[dodo512]

limit_req_status + error_page

limit_req_status 403;
error_page 403 = /file.php?bot;

Comments

[Андрей]

Но как отдать ту же самую страницу, только слегка измененную? Страницы динамические.

[dodo512]

Андрей, добавить отдельный именованный location location @имя { ... } с нужными fastcgi_param или sub_filter.
Потом указать этот именованный location в error_page.
Но в sub_filter нет поддержки regex. Там только поиск и замена статичных строк.
А fastcgi_param позволит передать нужные заголовки чтоб менять выдачу на уровне веб-приложения.

[Андрей]

Спасибо, буду пробовать. Кстати, есть переменная $limit_req_status, ее можно как-то использовать? Сделать limit_req_status 200; и в зависимости от этой переменной добавлять хедер?

[dodo512]

Андрей, там есть ещё limit_req_dry_run
Включает режим пробного запуска. В данном режиме скорость обработки запросов не ограничивается, однако в зоне разделяемой памяти текущее число избыточных запросов учитывается как обычно.
Т.е. считает запросы, но не блокирует и можно сделать проще без отдельного location и error_page.
Добавить limit_req_dry_run on;.
А там где основной location ~ \.php$ добавить fastcgi_param limit_req_status $limit_req_status;.
В переменной $_SERVER['limit_req_status'] будет приходить PASSED или REJECTED_DRY_RUN.

[Андрей]

Вот, уже красиво получается, спасибо.

Answer 2

[ky0]

Или другой путь - может ли Nginx добавить специфичный HTTP-хедер в запросы от таких ботов? Тогда я изменю выдачу на уровне веб-приложения.

Конечно. Отправляйте ботов в другой локейшен, который при проксировании вовнутрь будет добавлять заголовок или вовсе - перенаправлять запросы на другой урл или порт. Директива proxy_set_header.

Answer 3

[Andrey_Dolg]

А в чём смысл обрабатывать запросы от ботов? Или это так сказать из разряда насолить?

Comments

[Dimonchik]

Bing так делает ))) может хочет типа он Микрософт

[#]

dimonchik2013, да ладно? бинг врет ботам??
вроде яндекс и гугл ставят капчи, а бинг врет? )))

ps до чего довел планету этот индус фигляр ПЖ! (c)

[Андрей]

Не боты, парсеры. Нужно отдавать им дезинформацию. Иногда.

[Andrey_Dolg]

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

Answer 4

[Алексей Сундуков]

rate=2r/s

С учетом того, что у вас не API сервис, а сайт, то указанного значение слишком мало. В среднем на сайте легитимный посетитель, не бот, может генерировать до 6-12 RPS.

Comments

[Андрей]

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

[Алексей Сундуков]

Андрей, не страниц. Это RPS с одного легитимного IP. Если у вас этот лимит прописан в location отвечающий за связь с бэком и только с ним, то еще как-то нормально. Но если это общий лимит на server, то могут возникнуть проблемы.

[Андрей]

Ну да, только для отдачи основных страниц, спасибо.