Блокировка ботов и нежелательных пользователей на уровне вебсервера nginx

[@Roxis]

Зачем блокировать wget и curl?

и вместо if'ов есть location'ы
location ~* webadmin {}
location ~* /admin/main\.php {}

[@arty]

да вообще всё банить, кроме эксплорера! ишь, выдумали, в моём интернете чем попало ковыряться!; )

[@Neiro]

Билл? Гей? тсссс… :)

[@Neiro]

Минусующим: сорри за флуд, но данную статью считаю полной ерундой! заминусуйтесь!
Да, кстати, забыл перед своей первой фразой поставить (с)…

[@sadsanta]

Да, убивать надо таких параноиков.
Хорошо, что у wget есть флаг -U.

Да и в общем-то, когда мне надо сграбить какой-то сайт, первое что я делаю — это выставляю все заголовки курла аналогичными заголовкам IE.

В общем защита от дурака, помогающая админам-параноикам не наблюдать кучу ошибок 404 в логах, но усложняющая некоторым посетителям жизнь.

[@point]

kill –HUP `/var/log/nginx/nginx.pid`
как-то подозрительно выглядит. Может быть так
kill –HUP `cat /var/log/nginx/nginx.pid`

[@myiworm]

спасибо, опечатался

[@mstarrr]

Чтобы не опечатываться я nginx reload юзаю.
Эфект тот же.

[@elfxf]

в Mac'ах не работает, кажись :(

[@niksite]

Ещё бы для апача что-либо сходное :o\

[@syndicut]

mod_security?

[@mstarrr]

Банить нужно не хттп сервером, тем более не апачем. Ну какой смысл вместо 404 показывать forbidden тем же вебсервером?

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

[@greyhard]

этож сколько регекспов появится в nginx, вагон и маленькая тележка, и если там не один хост ) а десяток, тут уж и лог до мега вырастет

[@kns]

222.124.169.117 - - [07/Jun/2009:23:08:15 +0400] "GET /roundcube//bin/msgimport HTTP/1.1" 404 169 "-" "Toata dragostea mea pentru diavola"
86.34.172.222 - - [08/Jun/2009:14:31:27 +0400] "GET /user/soapCaller.bs HTTP/1.1" 404 169 "-" "Morfeus Fucking Scanner"

Вместо вгета с курлом я бы добавил вот этих. :)

[@ooprizrakoo]

Проблема в том, что если сканят из большой подсети, то можно слишком много юзверей заблокировать таким образом. У моего провайдера порядка 1000 юзверей на одном гейтовом ипе сидят. И один «какир» может таким образом многих «подставить» многих людей — и юзверей, и администрацию сайта, который потеряет пользователей.

Как бы «поумнее» сделать защиту?..

[@bullgare]

может на время блокировать (по времени последнего обращения к плохой страничке)?
минут на 5.
а лучше на полминуты.

[@sadsanta]

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

А если ресурс позволяет выкладывать картинки пользователям (например блоги), то зная о таких методах «обороны» можно вообще добрую часть посетителей загнать в черный список… например, так: <img src="/admin/main.php" />

[@bullgare]

я просто предложил ответ на заданный вопрос.
без рассуждений о том «зачем это надо».

[@sadsanta]

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

[@SCoon]

Запостил ниже свой комментарий, не заметив Вашего. Sorry.

[@myiworm]

Можно дописать модуль, который будет возвращать например хеш от IP+USERAGENT, этот хэш использовать при проверке, его же записывать в deny файл.
Раз в час очищать deny файл, а лучше брать последние X строк от deny файла, например даже 50% файла.

[@SCoon]

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

Признаться, я уже лет десять не видел роботов спорной этичности, которые бы использовали фиксированный USERAGENT. Такие еще остались в природе?

А при переменном USERAGENT хэш теряет практический смысл.

[@myiworm]

Вы знаете другой точечный способ различить одного клиента от другого с одного ip, если знаем о них только ip и юзерагент строку?

[@SCoon]

Такого способа не существует. Обращаю внимание: не я его не знаю. Его вообще нет.

[@myiworm]

Я знаю.
Поэтому в ситуации, когда не желательно банить целую сетку из-за одного бота, вариант с хешем хоть как то будет решением.

[@SovGVD]

Есть какой то более красивый способ блокировки «на лету» и/или по юзерагенту, определенным запросам?

[@brutaler]

помойму это больше подходит не для web-разработки, а для системного администрирования или же блога nginx

[@myiworm]

спасибо, перенёс

[@SCoon]

Коллега, я надеюсь, что Вы осознаете, что заделав довольно спорной опасности дыру Вы одновременно создали новую, причем более опасную. Фактически, Вы сделали свой сайт уязвимым к DOS. Механика атаки проста: злоумышленник заходит на насколько десятков/сотен/тысяч — в соответствии со своей зловредностью — форумов, посетители которых являются и вашими потенциальными посетителями, и на каждом размещает нейтральное, не нарушающее правил сообщение в которое вставляет картинку с адресом из вашего волшебного списка. Результат: все посетители этих сайтов, которые прочтут сообщение, автоматически попадут в Ваш отказный список. Зачастую — целыми сетями.

DOS в чистом виде. Просто. Красиво.

P.S. Сразу уточню, что бороться с этим анализом HTTP_REFERER — бесполезно.

[@myiworm]

Список можно очищать раз в 30 минут, можно оставлять последние N адресов в период времени, я бы не назвал этот способ атаки простым:)

[@SCoon]

Отлично. А вот теперь вопрос: ОТ ЧЕГО мы защитимся при этом? Исходное решение позволяло — если забыть про все drawbacks — опознать вредоносный скрипт ДО того, как он найдет нашу реальную — и пока неизвестную нам — уязвимость. В варианте с очисткой это достоинство исчезает.

Ok. А что у нас тогда остается?

[@myiworm]

Я не видел процессов сканирования, которые бы затягивались больше чем на полчаса. Достаточно выхватить бота, дать ему 403(500, 666) ответ в течении получаса, и он останет. Никакой панацеи, никаких революции я не предлагал.
Ещё один сраный способ забанить бота, не более.

[@recompileme]

В nginx есть возможность более простым способом защититься от сканеров, ботов и прочей нечисти.
1. В секции http прописываем зоны:

limit_zone na_xuy $binary_remote_addr 5m;
limit_req_zone $binary_remote_addr zone=v_pizdu:5m rate=30r/m;

2. В секции location — активируем нужные зоны:

limit_conn na_xuy 5;
limit_req zone=v_pizdu burst=5;

Только что мы поставили ограничение на 5 одновременно открытых сессий с одного айпи с лимитом ползапроса в секунду. При превышении пользователь будет временно заблокирован (регулируется параметром burst)
Параметры подробно описаны на сайте Сысоева.

[@recompileme]

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

[@Odes]

Не хочу вас расстраивать но у меня опера в данный момент поддерживает до 128 одновременных соединений (а значит и сессий с одного айпи)
А по умолчанию там стоит параметр 8.
В общем придёт человек с быстрым каналом и всё бан тебе родимый по айпи. Уйдёт на другой «неглючащий» сайт. Селя ви.

[@recompileme]

Описанным мною образом разумные люди не весь сайт закрывают, а определенную зону, описанную в секцию location. Например, location /mp3/ {… }
Если поставить на весь сайт — конечно можно навредить.

[@Newton]

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

[@myiworm]

да нет же, tail -n 100 deny > deny раз в 30 минут вполне достаточно

[@evil_random]

Какой-то корявый велосипедик получился.
Жалко вам что-ли 404 показать?

[@catap]

Чем вам мой is_bot не нравится? catap.ru/blog/2008/12/03/nginx-is_bot/

[@mobilz]

принцип расскажите, я слишком пьян, чтобы читать Си сейчас.

[@mobilz]

На личном опыте пришел к тому, что лишь боты и пользователи прокси не загружают картинок. + боты чаще юзают http 1.0, ибо он быстрее. А еще боты не видят JS, т.е. если все ссылки на странице имеют доп. параметр &bot=1, а JS его убирает, то лишь боты и пользователи без JS будут юзать этот параметр. А еще я пришел к выводу, что эффективнее всего «на лету» определять бота и блокировать его на время.

[@Odes]

А почему бы не использовать патерны?
«GET /admin/main.php HTTP/1.0»
«GET /phpmyadmin/main.php HTTP/1.0»
«GET /mysql/main.php HTTP/1.0»

[@Odes]

Хм что-то полкомента исчезло, как не было
Продолжим тут.
Если сканируют эти каталоги, то например можно при 1-2 такой попытке QoS для данного ip снизит до минимума.
При попытках более 10 — редирект на html страницу со всех страниц сервера «Вам ограничен доступ...» контактный e-mail, всё.
Вроде и железобетонно и никто кроме ботов не страдает.