простое блокирование сканирования по IP

[grigori]

привет,
кто знает готовый скрипт, который позволяет определить для дальнейшего блокирования превышение количества запросов в период времени, с белым списком для поисковиков?

 

[Вурдалак]

http://nginx.org/en/docs/http/ngx_http_limit_req_module.html
http://serverfault.com/questions/450077/nginx-limit-req-zone-ip-exceptions

 

[grigori]

спасибо, КО
тогда можно еще вопрос: а где список IP поисковиков для exceptions взять?

я хотел на php чтобы фоном аналитику можно было прогнать и подсети увидеть

 

[Вурдалак]

Ты можешь по аналогии вместо geo {} из того примера выше сделать map $http_user_agent с regex -> 0/1. Списки regex'ов для большинства ботов наверняка найти можно.

UPD. Или можно rDNS использовать:
https://github.com/flant/nginx-http-rdns
https://support.google.com/webmasters/answer/80553?hl=en
http://help.yandex.com/search/robots/check-robot.xml
etc

 

[grigori]

спасибо, почитаю

 

[Активист]

спасибо, почитаю

Лучше всего дропать \ логировать на уровне iptables.

# пропускаем ботов (первые правила)
iptables -A INPUT -p tcp --dport 80 --syn -m string --string "yandex.net" --algo kmp -j ACCEPT
iptables -A INPUT -p tcp --dport 80 --syn -m string --string "googlebot.com" --algo kmp -j ACCEPT

# syn это и есть новые соединения. те что keep alive - не подходят под этот критерий
iptables -A INPUT -p tcp --dport 80 --syn -m limit --limit 1/s --limit-burst 3 -j RETURN

 

[Yoskaldyr]

@grigori, Если и использовать ngx_http_limit_req_module, то лучше использовать tengine-овский форк этого модуля - там есть возможность указывать несколько limit_req директив для одного location-а
Белые списки - это только списки ip (которые можно получить распарсив вывод whois), но точно не списки юзерагентов, которые не имеют смысла, т.к. поисковые боты частенько заходят с юзерагентом обычного браузера (проверка на клоакинг)

P.S. Да и вообще если нужна более сложная логика до пхп, но быстрая, то тут лучше использовать lua (tengine, openresty), которое как раз и использует тот же CloudFlare.

 

[fixxxer]

Китайские форки nginx стоит применять очень осторожно, по качеству кода они местами довольно стремные, надо быть готовым к неожиданностям.

Вообще, если не хватает limit_req, имеет смысл перейти на уровень iptables.

 

[Yoskaldyr]

Китайские форки nginx стоит применять очень осторожно, по качеству кода они местами довольно стремные, надо быть готовым к неожиданностям.

это да, но можно использовать только конкретный форкнутый модуль - там китайцы по коду не сильно наворотили, но зато функционал значительно расширяется за счет использования нескольких директив limit_req в одном location-е, что стандартный модуль не умеет (например для авторизированных пользователей одни лимиты, для поисковых ботов другие, а для обычных гостей третьи).

Вообще, если не хватает limit_req, имеет смысл перейти на уровень iptables.

iptables на большом количестве правил значительно тупит (понятно что есть ipset и другие модули, но простыми средствами белый список большого размера не сделать). Поэтому если стоит задача лимитировать только http трафик, то nginx + модули должно с головой хватить (быстро работает даже с огромными списками ip адреов)

 

[fixxxer]

А чего такого сложного в ipset?

 

[Yoskaldyr]

А чего такого сложного в ipset?

Да не совсем правильно написал - надо было "стандартными средствами iptables" + как мне кажется разбирать http трафик лучше более специализированными средствами заточенными под это, к тому же через iptables как мне кажется будет значительно геморройнее различать гостей и авторизированных пользователей если для них нужны будут различные лимиты в добавок к различным лимитам на различные location-ы (типичная задача связанная с лимитированием запросов).
Хотя да, в некоторых случаях iptables рулит.

 

[grigori]

а боты поисковиков считывают css и js?

 

[флоппик]

а боты поисковиков считывают css и js?

крупных - да, они смотрят в частности, на скрытие блоков с контентом стилями

 

[Yoskaldyr]

а боты поисковиков считывают css и js?

да, но только не каждый стандартный проход, а параллельно и значительно реже идет проверка на клоакинг и там практически с полной поддержкой js и css и как раз в таких случаях по юзерагенту бот выглядит как обычный пользователь. А простой js (типа onclick document.location) понимают уже большинство стандартных ботов

 

[Вурдалак]

Белые списки - это только списки ip (которые можно получить распарсив вывод whois), но точно не списки юзерагентов, которые не имеют смысла, т.к. поисковые боты частенько заходят с юзерагентом обычного браузера (проверка на клоакинг)

Yoskaldyr, из твоих слов выходит, что:

1. достаточно грепнуть whois $remote_addr и можно заниматься клоакингом сколько влезет, поисковики тупые, используют IP-шники с такими же данными в whois, что и для обычного бота;
2. бот для проверки на клоакинг делает такую же тучу запросов в секунду и не палится, поэтому для него тоже нужно делать исключение для limit_req.

 

[grigori]

Вурдалак, мне кажется, в его словах другой смысл, и мне они кажутся полезными.
Мне не клоакинг нужен, для поисковиков надо лишь не ставить лимиты на соединения.
Наоборот я хочу блокировать ботов, которые сканируют только страницы без JS, CSS и картинок, но пока не знаю как отследить отсутствие запроса.


Вообще, мне http://habrahabr.ru/post/84172/ понравилась, там идея через ngx_http_limit_conn_module писать лог подозрительных запросов, парсить его и банить top-50 ботов. Так и reverse lookup можно сделать, и geoip, и подсетку выделить.

 

[grigori]

Лучше всего дропать \ логировать на уровне iptables.

# пропускаем ботов (первые правила)
iptables -A INPUT -p tcp --dport 80 --syn -m string --string "yandex.net" --algo kmp -j ACCEPT
iptables -A INPUT -p tcp --dport 80 --syn -m string --string "googlebot.com" --algo kmp -j ACCEPT

# syn это и есть новые соединения. те что keep alive - не подходят под этот критерий
iptables -A INPUT -p tcp --dport 80 --syn -m limit --limit 1/s --limit-burst 3 -j RETURN

только надо статику на отдельный ip вынести