блокировка ботов в nginx

52

mirrustam

28 июня 2013, 06:01

9376

Блокирую наглых ботов в файле nginx.conf в секции server прописано:

if ($http_user_agent ~* msnbot|bingot) {
		return 444;
}

В логах следов заблокированных ботов нет.

Но, команда netstat показывает, соединение с ними в состоянии TIME_WAIT

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 hosts.net:www msnbot-157-55-35-:34649 TIME_WAIT
tcp        0      0 hosts.net:www msnbot-157-55-35-:34910 TIME_WAIT
tcp        0      0 hosts.net:www msnbot-157-56-92-:16763 TIME_WAIT
tcp        0      0 hosts.net:www msnbot-157-55-35-:34673 TIME_WAIT

Эти соединения висят долго. Хотелось бы, что бы блокировка была такая, что бы ресурсы освобождались сразу.

Как это можно сделать?

Может какой то другой код ответа давать вместо этого return 444; ?

Какая настройка nginx отвечает за время нахождения в состоянии TIME_WAIT?

Не эти?:

   proxy_connect_timeout       120;
    keepalive_timeout 30 15;

Если что вот все настройки :

#    access_log  /var/log/nginx/access.log  main;
     access_log off;
#    sendfile        on;
    #tcp_nopush     on;
 #   keepalive_timeout  65;
    #gzip  on;
#    limit_req_zone $binary_remote_addr zone=one:30m rate=2r/s;
#    limit_req zone=one burst=10;
   reset_timedout_connection on;
    client_header_timeout 15;
    client_body_timeout 15;
    send_timeout 5;
    client_max_body_size 100m;
    server_names_hash_max_size 4096;
    server_names_hash_bucket_size 128;
    connection_pool_size 256;
    client_header_buffer_size 1k;
    large_client_header_buffers 8 8k;
    request_pool_size 4k;
    limit_req_zone  $binary_remote_addr  zone=one:10m   rate=10r/s;
    gzip on;
    gzip_static on;
    gzip_min_length 1000;
    gzip_buffers 4 8k;
    gzip_comp_level 9;
    gzip_http_version 1.0;
    gzip_proxied any;
    gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript image/x-icon;
    output_buffers 1 32k;
    postpone_output 1460;
    proxy_set_header    Host    $host;
    proxy_set_header    X-Real-IP       $remote_addr;
    proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
    proxy_max_temp_file_size    0;
    proxy_connect_timeout       120;
    proxy_send_timeout  120;
    proxy_read_timeout  300;
    proxy_buffering     on;
    proxy_buffer_size   256k;
    proxy_buffers       4 256k;
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    keepalive_timeout 30 15;
    ignore_invalid_headers on;
    server_tokens off;

37

Poliarnik

28 июня 2013, 07:29

#1

Попробуйте заблокировать Ip бота через .htaccess

1

134

esetnod

28 июня 2013, 08:15

#2

include/net/tcp.h

#define TCP_TIMEWAIT_LEN (60*HZ)

1

Быстрый хостинг на SSD от $0.99 (http://just-hosting.ru/) | OpenVZ (http://just-hosting.ru/vds.html) и KVM (http://just-hosting.ru/vds-kvm.html) VDS от $7.95

L

132

Logger

28 июня 2013, 08:22

#3

в логах nginx надо смотреть отдает ли 444 указаным ботам - если нет - значит неправильно правило написано - неточно

1

Контакты-icq 535609 ()

115

iamsens

28 июня 2013, 08:55

#4

нужно проверить все боты msn, имеют user-agent "msnbot|bingot" ?

1

M

52

mirrustam

28 июня 2013, 09:20

#5

Poliarnik:
Попробуйте заблокировать Ip бота через .htaccess

не пойдёт.

Блокировка идёт до того как запрос дойдёт до апачи и .htaccess.

---------- Добавлено 28.06.2013 в 12:26 ----------

iamsens:
нужно проверить все боты msn, имеют user-agent "msnbot|bingot" ?

если бы у msn были другие боты, то я бы их видел в аксес логе. но их там уже нет так как блокировка сама по себе работает.

Я это вижу через уменьшения нагрузки

в аксесс лог этих ботов уже нет. Если я например, уберу эту блокировку и сделаю в htaccess 503 или 404, то в аксесс логе боты появятся как посланные на 503 или 404.

в общем, названия юзер agent тут не причём я думаю

---------- Добавлено 28.06.2013 в 12:35 ----------

esetnod:
include/net/tcp.h
#define TCP_TIMEWAIT_LEN (60*HZ)

нет такого файла на сервере

find / -name 'tcp.h' -print

-bash: include/net/tcp.h: No such file or directory

linux debian

или надо как то по особенному искать ?

сильная нагрузка на БД 404-й редирект Боты создают нагрузку на

115

iamsens

28 июня 2013, 09:44

#6

если бы у msn были другие боты, то я бы их видел в аксес логе. но их там уже нет так как блокировка сама по себе работает.

боту не обязательно иметь юзер-агент, в котором указывать что он бот

нужно посмотреть вышеуказаные ипы (через netstat) и посмотреть как они себя называют в accesslog

еще вариант, что залипли процессы веб-сервера, посмотреть pid через server-status, убить эти процессы и руками сбросить коннект через tcpdrop(тогда и ресурсы освободятся)

1

Как определить тип Ддоса? Помогите убить сервис Ошибка при рестарте Апача

396

Оптимизайка

28 июня 2013, 09:50

#7

return 444 в nginx означает, что не передавая ни байта, закрыть соединение. В логах вы не увидите ничего, верно.

1

⭐ BotGuard (https://botguard.net) ⭐ — защита вашего сайта от вредоносных ботов, воровства контента, клонирования, спама и хакерских атак!

M

52

mirrustam

28 июня 2013, 09:51

#8

Logger:
в логах nginx надо смотреть отдает ли 444 указаным ботам - если нет - значит неправильно правило написано - неточно

логе ошибок?

/var/log/nginx/error.log

пустой

этот тоже пустой

/var/log/nginx/access.log

(правда у access.log нет даже за прошлые дни. Где то отключён ? )

---------- Добавлено 28.06.2013 в 13:06 ----------

Logger:
в логах nginx надо смотреть отдает ли 444 указаным ботам - если нет - значит неправильно правило написано - неточно

лог включил.

Вижу например это:

199.30.20.128 - - [28/Jun/2013:14:03:40 +0400] "GET /robots.txt HTTP/1.1" 444 0 "-" "msnbot-media/1.1 (+http://search.msn.com/msnbot.htm)" "-"

значит правило написано точно?

---------- Добавлено 28.06.2013 в 13:07 ----------

Оптимизайка:
return 444 в nginx означает, что не передавая ни байта, закрыть соединение. В логах вы не увидите ничего, верно.

ну, в лог nginx вижу, что сервер отдаёт 0 байт

---------- Добавлено 28.06.2013 в 13:22 ----------

iamsens:
боту не обязательно иметь юзер-агент, в котором указывать что он бот
нужно посмотреть вышеуказаные ипы (через netstat) и посмотреть как они себя называют в accesslog

в netstat пишет

hosts.net:www msnbot-157-55-35-:52675 TIME_WAIT

Как отсюда узнать ip ?

iamsens:

еще вариант, что залипли процессы веб-сервера, посмотреть pid через server-status, убить эти процессы и руками сбросить коннект через tcpdrop(тогда и ресурсы освободятся)

Вы имеете в виду server-status подключаемы в httpd.conf строчкой

LoadModule status_module modules/mod_status.so

?

он сейчас не включён.

а другого способа нет?

Nginx -> Varnish -> Сервер вернул код ошибки Общая тема о борьбе

822

Andreyka

28 июня 2013, 10:34

#9

Эти "ресурсы" весят копейки по сравнению с генерацией страниц в CMS

1

Не стоит плодить сущности без необходимости

M

52

mirrustam

28 июня 2013, 10:52

#10

и вот кстати.

В лог nginx нашлась такая строчка

157.55.35.52 - - [28/Jun/2013:14:22:40 +0400] "GET /robots.txt HTTP/1.1" 444 0 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" "-"

а в netstate вот так

hosts.net:www msnbot-157-55-35-:34649 TIME_WAIT

получается он получил свои ноль байт, но всё равно висит?

Сообщение от iamsens Посмотреть сообщение
еще вариант, что залипли процессы веб-сервера, посмотреть pid через server-status, убить эти процессы и руками сбросить коннект через tcpdrop(тогда и ресурсы освободятся)

это наверное тоже не вариант вручную убирать.

---------- Добавлено 28.06.2013 в 14:26 ----------

Кажется разобрался:

Все коннекты в нетстате показывают тех, кто стоит в приёмной кабинета директора нашего завода в очереди к секретарше (TIME_WAIT) , или уже находятся в кабинете директора (ESTABLISHED).

Т.к. директору бингбот уже надоел своими завышенными требованиями, он говорит секретарше, что бы она не пускала бингбота( return 444). Но, о том, что его послали на 3 цифры он узнает только тогда, когда дождётся своей очереди.

Постоянное нахождение бингботов в списке, связано с тем, что он всё равно приходит и приходит в секунду от 3 до 5 раз. Т.е. зависания нет, есть только частое обращение. И бинг(msn)бота мы можем видеть только в состоянии TIME_WAIT.

Здесь всё понятно. Или чего то я упустил?

Выходит, что для уменьшения времени ожидания надо увеличить число допустимых коннетов к nginx (или apache ?).

В apache2.conf есть переменная MaxClients – это не она ?

BingBot получает ошибку 404 Хочу спросить про лог-файлы Проблемы с отдачей файлов

В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи

Что делать, чтобы попасть в ответы Google Bard