Comments 45
Зачем блокировать wget и curl?
и вместо if'ов есть location'ы
location ~* webadmin {}
location ~* /admin/main\.php {}
и вместо if'ов есть location'ы
location ~* webadmin {}
location ~* /admin/main\.php {}
да вообще всё банить, кроме эксплорера! ишь, выдумали, в моём интернете чем попало ковыряться!; )
Да, убивать надо таких параноиков.
Хорошо, что у wget есть флаг -U.
Да и в общем-то, когда мне надо сграбить какой-то сайт, первое что я делаю — это выставляю все заголовки курла аналогичными заголовкам IE.
В общем защита от дурака, помогающая админам-параноикам не наблюдать кучу ошибок 404 в логах, но усложняющая некоторым посетителям жизнь.
Хорошо, что у wget есть флаг -U.
Да и в общем-то, когда мне надо сграбить какой-то сайт, первое что я делаю — это выставляю все заголовки курла аналогичными заголовкам IE.
В общем защита от дурака, помогающая админам-параноикам не наблюдать кучу ошибок 404 в логах, но усложняющая некоторым посетителям жизнь.
kill –HUP `/var/log/nginx/nginx.pid`
как-то подозрительно выглядит. Может быть так
kill –HUP `cat /var/log/nginx/nginx.pid`
как-то подозрительно выглядит. Может быть так
kill –HUP `cat /var/log/nginx/nginx.pid`
Ещё бы для апача что-либо сходное :o\
этож сколько регекспов появится в nginx, вагон и маленькая тележка, и если там не один хост ) а десяток, тут уж и лог до мега вырастет
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"
Вместо вгета с курлом я бы добавил вот этих. :)
Проблема в том, что если сканят из большой подсети, то можно слишком много юзверей заблокировать таким образом. У моего провайдера порядка 1000 юзверей на одном гейтовом ипе сидят. И один «какир» может таким образом многих «подставить» многих людей — и юзверей, и администрацию сайта, который потеряет пользователей.
Как бы «поумнее» сделать защиту?..
Как бы «поумнее» сделать защиту?..
может на время блокировать (по времени последнего обращения к плохой страничке)?
минут на 5.
а лучше на полминуты.
минут на 5.
а лучше на полминуты.
А нафига вообще блокировать?
Если это сканер обращающийся к несуществующим в большинстве своем страницам, то нагрузка на сервер должна быть минимальна.
Если это хакер, то он и без сканера дыры найдет.
А если ресурс позволяет выкладывать картинки пользователям (например блоги), то зная о таких методах «обороны» можно вообще добрую часть посетителей загнать в черный список… например, так: <img src="/admin/main.php" />
Если это сканер обращающийся к несуществующим в большинстве своем страницам, то нагрузка на сервер должна быть минимальна.
Если это хакер, то он и без сканера дыры найдет.
А если ресурс позволяет выкладывать картинки пользователям (например блоги), то зная о таких методах «обороны» можно вообще добрую часть посетителей загнать в черный список… например, так: <img src="/admin/main.php" />
Можно дописать модуль, который будет возвращать например хеш от IP+USERAGENT, этот хэш использовать при проверке, его же записывать в deny файл.
Раз в час очищать deny файл, а лучше брать последние X строк от deny файла, например даже 50% файла.
Раз в час очищать deny файл, а лучше брать последние X строк от deny файла, например даже 50% файла.
Вы полагаете, для научения робота отдавать на каждый запрос уникальный USERAGENT требуется более 10 минут?
Признаться, я уже лет десять не видел роботов спорной этичности, которые бы использовали фиксированный USERAGENT. Такие еще остались в природе?
А при переменном USERAGENT хэш теряет практический смысл.
Признаться, я уже лет десять не видел роботов спорной этичности, которые бы использовали фиксированный USERAGENT. Такие еще остались в природе?
А при переменном USERAGENT хэш теряет практический смысл.
Есть какой то более красивый способ блокировки «на лету» и/или по юзерагенту, определенным запросам?
помойму это больше подходит не для web-разработки, а для системного администрирования или же блога nginx
Коллега, я надеюсь, что Вы осознаете, что заделав довольно спорной опасности дыру Вы одновременно создали новую, причем более опасную. Фактически, Вы сделали свой сайт уязвимым к DOS. Механика атаки проста: злоумышленник заходит на насколько десятков/сотен/тысяч — в соответствии со своей зловредностью — форумов, посетители которых являются и вашими потенциальными посетителями, и на каждом размещает нейтральное, не нарушающее правил сообщение в которое вставляет картинку с адресом из вашего волшебного списка. Результат: все посетители этих сайтов, которые прочтут сообщение, автоматически попадут в Ваш отказный список. Зачастую — целыми сетями.
DOS в чистом виде. Просто. Красиво.
P.S. Сразу уточню, что бороться с этим анализом HTTP_REFERER — бесполезно.
DOS в чистом виде. Просто. Красиво.
P.S. Сразу уточню, что бороться с этим анализом HTTP_REFERER — бесполезно.
Список можно очищать раз в 30 минут, можно оставлять последние N адресов в период времени, я бы не назвал этот способ атаки простым:)
Отлично. А вот теперь вопрос: ОТ ЧЕГО мы защитимся при этом? Исходное решение позволяло — если забыть про все drawbacks — опознать вредоносный скрипт ДО того, как он найдет нашу реальную — и пока неизвестную нам — уязвимость. В варианте с очисткой это достоинство исчезает.
Ok. А что у нас тогда остается?
Ok. А что у нас тогда остается?
В 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)
Параметры подробно описаны на сайте Сысоева.
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)
Параметры подробно описаны на сайте Сысоева.
Ломается сканом через список анонимных проксей кстати. Я просто с другой стороны барикад смотрю, и могу ответственно заявить что такую защиту ломать геморней всего.
Не хочу вас расстраивать но у меня опера в данный момент поддерживает до 128 одновременных соединений (а значит и сессий с одного айпи)
А по умолчанию там стоит параметр 8.
В общем придёт человек с быстрым каналом и всё бан тебе родимый по айпи. Уйдёт на другой «неглючащий» сайт. Селя ви.
А по умолчанию там стоит параметр 8.
В общем придёт человек с быстрым каналом и всё бан тебе родимый по айпи. Уйдёт на другой «неглючащий» сайт. Селя ви.
Я правильно понял, что айпишники у вас блокируются навсегда, и потом другие пользователи того же провайдера с динамическим айпи долго гадают, чего же они не могут попасть на ваш замечтательный сайт?
Какой-то корявый велосипедик получился.
Жалко вам что-ли 404 показать?
Жалко вам что-ли 404 показать?
Чем вам мой is_bot не нравится? catap.ru/blog/2008/12/03/nginx-is_bot/
На личном опыте пришел к тому, что лишь боты и пользователи прокси не загружают картинок. + боты чаще юзают http 1.0, ибо он быстрее. А еще боты не видят JS, т.е. если все ссылки на странице имеют доп. параметр &bot=1, а JS его убирает, то лишь боты и пользователи без JS будут юзать этот параметр. А еще я пришел к выводу, что эффективнее всего «на лету» определять бота и блокировать его на время.
А почему бы не использовать патерны?
«GET /admin/main.php HTTP/1.0»
«GET /phpmyadmin/main.php HTTP/1.0»
«GET /mysql/main.php HTTP/1.0»
«GET /admin/main.php HTTP/1.0»
«GET /phpmyadmin/main.php HTTP/1.0»
«GET /mysql/main.php HTTP/1.0»
Хм что-то полкомента исчезло, как не было
Продолжим тут.
Если сканируют эти каталоги, то например можно при 1-2 такой попытке QoS для данного ip снизит до минимума.
При попытках более 10 — редирект на html страницу со всех страниц сервера «Вам ограничен доступ...» контактный e-mail, всё.
Вроде и железобетонно и никто кроме ботов не страдает.
Продолжим тут.
Если сканируют эти каталоги, то например можно при 1-2 такой попытке QoS для данного ip снизит до минимума.
При попытках более 10 — редирект на html страницу со всех страниц сервера «Вам ограничен доступ...» контактный e-mail, всё.
Вроде и железобетонно и никто кроме ботов не страдает.
Sign up to leave a comment.
Блокировка ботов и нежелательных пользователей на уровне вебсервера nginx