Защита сервера от ботов

[chesser]

люблю следить за чужими ботами в логах своих веб-серверов. Порой проскакивают интересные экземпляры и "темы". Но большинство ботов являются нежданными гостями, а порой и опасны для сайта или сервера. Далее я хочу поделиться своими мыслями на эту тему.
Тыкаем на смайлы

moreinfo

Опасности ботов:

1) бот создает нагрузку на сервер, расходуя его ресурсы и, как следствие, сайт/сервер тормозит. (например: все ж "любят" китайского бота от baidu.com, который ставит раком любой сервер, вне зависимости от директив в robots.txt. Его обычно банят первым делом)
2) угроза безопасности - некоторые боты ищут уязвимости на сайтах и, если найдут, хакер поимеет ваш сайт или сервер, а это печально
3) происки конкурентов и другой сбор информации о ваших проектах третьими лицами, например, hrefs/мажестик/etc. Если конкуренты узнают ваши секреты продвижения проекта, они могу получить преимущество.
4) схожие с предыдущим пунктом боты различных правовых организаций, которые выступают за чистоту контента и соблюдения интернет-законов, т.е. копирайт боты, анти-фарма боты, анти-плагиат и тд. Эти боты могут писать письма вашим хостерам и вам по поводу и без повода, создавая лишние неудобства

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

Хорошие: боты поисковых компаний(google, yandex, bing) или тех систем, которые осознанно использованы непосредственно в проекте. Например, пробую использовать партнерку от viglink, от них на каждую страницу сайта приходит бот-анализатор...ну пусть ходит, раз так надо. Тоже самое с share-кнопками от addthis.com и тд. Хотя бы я в курсе кто это такие.
Также к хорошим ботам можно отнести те, которые сами ставят dofollow линки на ваш сайт. Если бот ставит ссылки на все сайты подряд без разбору, то по заявлениям гугла, такие ссылки не учитываются в ранжировании, хоть они и dofollow.

Раз хороших ботов меньше, чем плохих, то при их фильтрации логичнее применить "политику белых списков", т.е. блокируем ВСЕХ ботов, кроме хороших из белого списка. Если заранее не знаем этот список, то его сначала надо собрать или взять у коллег.
Если существует риск заблокировать очень нужного бота, который еще не успел попасть в белый список, или если трудно решиться на тотальную блокировку, можно использовать "политику черных списков", т.е. разрешать ВСЕХ ботов, кроме плохих.
У меня пока используется второй вариант, но планирую переход к первому, т.к. статистика показала, что полезных ботов на несколько порядков меньше.

Определение термина "бот"

Кто такой бот? Если есть бот, значит есть небот? и как их различать?

Эти вопросы очень интересные и чем дальше прогресс, тем провести границу между ними сложнее.
Классификация трафика на бот/не_бот прежде всего имеет _цель_, согласно которой формируются признаки или образ "бота" (и небота). Если уходить в науку, то это задача распознавания образов, которая универсально решается методами Machine Learning. Но такие универсальные решения сложны и не всегда оправданы. Возможно, их используют какие-то сложные системы анализа трафика, типа гугл-аналитикс или адвордс. В ситуации с мелкими сайтиками/проектами проще применить эвристические алгоритмы, проверенные опытным путем и работающие в боевых условиях. Но цель фильтрации и образ бота все равно придется "рисовать".

Признаки бота

Признак - это набор фактов, или набор значений параметров исследуемого веб-клиента, по которым его можно классифицировать на бот/небот.

Я разделяю признаки на:
1) статические, или лучше называть state-признаки, т.е. набор фактов о клиенте без учета времени, без учета его прошлого, _состояние_ веб-клиента здесь и сейчас. Грубо говоря, это набор значений параметров, которые указаны в одной строке лога веб-сервера (nginx/apache). Например:

5.135.18.89 - - [12/Jun/2013:06:15:55 +0400] "GET /phpmyadmin/ HTTP/1.1" 200 13820 "-" "Googlebot/2.1 (+http://www.googlebot.com/bot.html)" "-"

часто достаточно одной такой строки, чтобы сделать вывод о том, что это бот. Например, когда об этом явно написано: "Googlebot/2.1....." (но не всегда, см. дальше)
2) динамические, которые учитывают серии запросов клиента, разделенных во времени, а также запросы других "соседних" веб-клиентов. Например, если веб-клиент по state-признакам классифицировался как небот, но он долбит сервер с частотой 100 запросов в секунду, то скорее всего он бот и простой классификатор ошибся. (Эта часть анализа бот/небот сложна и интересна и можно обсудить потом подробнее. Дальше пишу про первый пункт.)

Боты, путешествующие по сайтам, являются http-клиентами, т.е. речь идет именно о http(s)-протоколе, а раз так, то и факты о боте лежат в источнике (хост, IP-адрес) http-запроса и в его http-заголовке, которым он представляется каждый раз, стучась к нам на сервер. Рассматривая источник запроса и его возможные http-заголовки, можно выделить следующие параметры, из которых формируются state-признаки ботов:
- IP клиента
- http user agent
- http request uri
- http referer
- http cookie
- и другие

Это основные и их достаточно, чтобы обрубить 99% бот-трафика.

Степень наглости ботов.

Наглость №1. Чтобы боты не ходили по сайту и не грузили сервер, веб-программисты придумал файл robots.txt. Если там прописать UA бота, то он должен повиноваться и не ходить по сайту. По моим наблюдениям даже гугл нарушает эти правила, а самые наглые боты вообще чихать хотели на этот файл.
Наглость №2. Некоторые боты явно пишут: "я бот, парсящий сайт с целью набрать емейлов для спама", другие: "я хороший бот, не надо меня банить", третьи: "я не бот, я обычный юзер с файерфоксом", а четвертые и самые наглые: "я гугл, не баньте меня". Если присмотреться к примеру лог-строки выше, там с большой вероятностью не гугл, а "левый" бот, работающий от имени гугла. С такими тоже можно бороться.

Политика и цели филтрации бот-трафика

Перед тем, как начать фильтровать трафик, лучше определиться каких веб-клиентов считать за ботов, каких ботов пропускать на сервер, а каких блокировать.
Я пропускаю всех, кроме тех, кто по признакам похож на плохого бота, т.е. "политика черных списков". Плохие боты - те, от которых нет пользы для моих сайтов на мой субъективный взгляд. Например, теоретически, от ahrefs, мажестиков и других подобных ботов есть плюс при открытой оценки сайта, которая может помочь при продаже сайта, где-то будет написано, что мой сайт стоит не $10, а $10000 и другие подобные случаи...но мне такое не надо.

Маршрут ботов и компоненты их анализа

Путь следования запроса от клиента к серверу и обратно:

(1) клиент-хост -> (сквозь каналы и коммутаторы, сетевой уровень) -> (2) сетевой интерфейс сервера (транспортный уровень, tcp/ip) -> (3) ядро ОС (с участием firewall) -> (прикладной уровень, http) -> (4) фронтэнд веб-сервера -> (прикладной уровень, например fastcgi) -> (5) бекэнд веб-сервера -> (fastcgi) -> (6) фронтэнд веб-сервера -> (7) ядро ОС -> (8) сетевой интерфейс -> (9) клиент-хост

В точке (5) "бекэнд веб-сервера" обычно жарче всего. При хайлоад-оптимизациях, стараются минимизировать ее участие при общении с веб-клиентом. А при защите от ботов стараются допускать до сюда только тех, кому оно действительно надо: юзеры, использующие динамические части сайта и сверх-умные боты, которых лучше не обманывать, например, гуглобота можно пускать. Менее хорошим и более тупым ботам достаточно показать кеш из точки (4).

Все вопросы классификации трафика на бот/небот лучше решать в как можно более ранних точках:
(1) хост веб-клиента. Бан хоста будет хорошим решением, если вас долбит один и тот же бот или подсеть, пишите на них абузу, может и выйдет что-то
(2) на сетевом уровне обычно работают железячные анти-ддос защиты и прочее оборудование, недоступное рядовому сервер-арендателю. К тому же, этому оборудованию нужно передать политику классификации на бот/небот, иначе оно не узнает какие боты хорошие, какие плохие. При умной и тонкой фильтрации имхо такие способы не доступны, зато для анти-ддос самое то.
(3) точка приема трафика на сервер и обработка его ОСью. До этого уровня мы (админы) дотянуться можем - можем блокировать прохождение трафика дальше этой точки, т.е. обрубать поток, но для классификации на бот/небот нам доступен только IP, т.к. это транспортный уровень и HTTP-протокол еще не вступил в действие, мы не знаем http-хедеров, т.е. неизвестны ua, referer, request uri и тд. Если есть заранее подготовленные белые/черные списки IP, то в этом месте можно их применить. Один из вариантов фильтрации трафика - заранее готовить и постоянно обновлять эти списки.
(4) на веб-фронтэнде уже известно о веб-клиенте все, что нужно, осталось проанализировать значения параметров и соотнести их со state-признаками и классифицировать на бот/небот. Обычно, этот анализ происходит внутри конфига веб-фронтэнда, пропускать его в следующую точку (5) на бекэнд крайне не желательно, но при сложном бот-анализе можно. Самый просто пример анализа параметра Http User Agent: ищем с помощью regexp стоп слова: php, perl, python, baidu, ahrefs, ezooms, checkparams etc - если нашли, значит это плохой бот.

Можно в точках (4) и (5) подготовить черный список ip, принадлежащих плохим ботам, и отправить его на уровень (3) в файервол, который будет блокировать все последующие запросы с этих IP. Придется постоянно следить за базой IP, желательно автоматически и в реальном времени.

Отступление про апач.

Апач - это бекэнд и фронтэнд в одном флаконе. К его работе в качестве бекенда претензий особо нет, зато к фронтэнду есть. Фронтэнд настраивают с помощью .htaccess-файлов - это файлы динамического конфига. Динамический конфиг якобы удобнее(что очень спорно) и всегда менее эффективнее статического конфига. Причина - постоянно работает интерпретатор, который обязан в режиме реального времени следить за состоянием htaccess-ов и реагировать на их изменения. Использование .htaccess - это много-кратное зло, которое рекурсивно применяется по всему дереву директорий виртуального хоста. Также апачевские коннекты тяжелее по памяти, чем те же самые коннекты в nginx (сам не проверял). Рекомендую в качестве фронтэнда веб-сервера использовать nginx.

Что делать с обнаруженным ботом?

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

Варианты:
1) молча закрыть соединение и пусть думает, что хочет
2) показать ему картинку или надпись в виде или любой другой http-ответ: пустой или с контентом
3) частный случай предыдущего пункта: отправить 301-редирект на адрес http://google.com , пусть попарсит гугл.

Для сайтов использую только 1-ый вариант, маршрут следования бота обрубается в точке (3) или (4), т.о. не тратятся ресурсы на подготовку http-ответа и сам ответ.

2/3 варианты интересны в случае фильтрации трафика под клоакинг, либо при организации TDS. После анализа веб-клиенту отдается тот контент, который ему полагается согласно классификации. Например: гуглоботам - красивый и правильный сайт/html, юзерам - редирект на партнерку, левым ботам - бан сразу.

Профит от фильтрации ботов

1) если на сервере 90% трафика составляют боты (имхо такое вполне реально), то зафильтровав их, на сервере снизится нагрузка в 10 раз, а значит вместо 10 серверов, можно купить только один, а значит вместо $1000 заплатить $100 - профит!
2) сокращение ботов сокращает количество внешних проблем (спам, абузы, конкуренты, взлом)
3) фильтрация трафика - это интересно, хочу знать "в лицо" своих клиентов, а то устроили проходной двор в этих Интернетах

далее еще будет практическая часть.....

[chesser]

Мой опыт фильтрации веб-ботов средствами nginx.

На каждом сервере под веб-проекты установлен nginx, а его конфиг находится в git-репозитории, он общий для всех серверов. Индивидуальные настройки каждого хоста/домена хранятся в отдельно папке, которая не входит в git-репозиторий.

Структура примерно такая файлов:

nginx/.git/
nginx/conf.d/
nginx/conf.d/.gitignore
nginx/conf.d/123.123.123.123.conf
nginx/conf.d/default_server.conf
nginx/conf.d/localhost.conf
nginx/conf.d/domain1.com.conf
nginx/conf.d/domain2.com.conf
nginx/custom/
nginx/custom/bad_ip
nginx/custom/bad_location
nginx/custom/bad_referer
nginx/custom/bad_ua
nginx/custom/server_common
nginx/fastcgi.conf
nginx/fastcgi_params
nginx/koi-utf
nginx/koi-win
nginx/mime.types
nginx/nginx.conf
nginx/scgi_params
nginx/uwsgi_params
nginx/win-utf

Конфиг nginx начинается с файла nginx/nginx.conf:

PHP код:

user nginx;

worker_processes  4;
worker_rlimit_nofile 100000;

error_log  /var/log/nginx/error.log  notice;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
    use epoll;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    sendfile        on;
    tcp_nopush      on;
    tcp_nodelay     on;
    server_tokens   off;

    gzip            on;
    gzip_static     on;
    gzip_comp_level 5;
    gzip_min_length 1024;
    gzip_types      text/plain text/xml application/xml application/javascript text/javascript text/css text/json;
    gzip_disable     "msie6";
    gzip_vary on;

    # Timeout for keep-alive connections. Server will close connections after this time.
    keepalive_timeout  30;

    # Number of requests a client can make over the keep-alive connection.
    keepalive_requests 1000;

    # Allow the server to close the connection after a client stops responding.
    reset_timedout_connection on;

    # Send the client a "request timed out" if the body is not loaded by this time.
    # client_body_timeout 10;

    # If the client stops reading data, free up the stale client connection after this much time.
    # send_timeout 2;

    limit_req_zone $binary_remote_addr zone=myzone:10m rate=4r/s;
    charset utf-8;

    root /path_to_www/$host;
    index  index.html index.php;
    access_log /var/log/nginx/access.$host.log main;

    include custom/bad_ua;
    include custom/bad_referer;
    include custom/bad_ip;
    include custom/bad_location;


    include conf.d/*.conf;

} 


в этом файле сверху описаны общие настройки работы веб-сервера для всех виртуальных хостов. В конце файла строкой "include conf.d/*.conf;" подключаются индивидуальные настройки каждого вирт.хоста.

Строками "include custom/*" подключаются описания правил-признаков, по которым осуществляется фильтрация трафика:

custom/bad_ua:

PHP код:

map $http_user_agent $bad_ua {

  default 0;

  ""                       1;
  "~*Panopta"              1;
  "~*Baiduspider"          1;
  "~*AC-BaiduBot"          1;
  "~*TurnitinBot"          1;
  "~*pirst"                1;
  "~*FlightDeckReportsBot" 1;
  "~*Fuck"                 1;
  "~*DomainTools"          1;
  "~*ZmEu"                 1;
  "~*ezooms"               1;
  "~*solomono"             1;
  "~*360Spider"            1;
  "~*Ahrefs"               1;
  "~*Sogou"                1;
  "~*Java/1"               1;
  "~*nutch agent"          1;
  "~*Indy Library"         1;
  "~*Sogou"                1;
  "~*urllib"               1;
  "~*wget"                 1;
  "~*curl"                 1;
  "~*MJ12bot"              1;
  "~*majestic"             1;

} 


custom/bad_referer:

PHP код:

map $http_referer $bad_referer {

  default 0;

  "~*porn"            1;
  "~*prostitut"       1;
  "~*forex"           1;
  "~*casino"          1;
  "~*adult"           1;
} 


custom/bad_ip:

PHP код:

map $remote_addr $bad_ip {

  default 0;

  "144.76.13.77"      1; # Hetzner
  "~91.207.9."        1; # 
  "194.9.94.37"       1; # hackers
} 


custom/bad_location:

PHP код:

map $request_uri $bad_location {

  default 0;

  "~*^/+phpmyadmin"          1;
  "~*^/+myadmin"             1;
  "~*^/+pma"                 1;
  "~*^/+wp"                  1;
  "~*^/+wordpress"           1;
  "~*^/+joomla"              1;
  "~*^/+drupal"              1;
  "~*^/+blog"                1;
  "~*^/+PMA"                 1;
  "~*^/+FCK"                 1;
  "~*^/+admin/fck"           1;
  "~*^/+system/fckeditor"    1;
  "~*^/+w00t"                1;
  "~*^/+\."                  1;
  "~*^/+admin\.php"          1;
  "~*^/+wp-"                 1;
  "~*^/+administrator"       1;
  "~*^/+forum"               1;
  "~*^/+hostcmsfiles"        1;
  "~*^/+phpBB3"              1;
  "~*^/+bitrix"              1;
  "~*^/+wso\.php"            1;
  "~*^.*wp-login\.php$"      1;
  "~*\.sql$"                 1;
#  "~*^/+configuration\.php"  1;
  "~*^/+config"              1;
  "~*^/+netcat"              1;

  "~*%20union"               1; # sql injection
  "~*\(select"               1; # sql injection

  "~*^/+HNAP"                1;
  "~*^/+news\.asp"           1;
  "~*^/+article\.asp"        1;
} 


Это были сокращенные признаков плохих ботов. Выкладывать эти признаки целиком не буду, тем более у каждого они будут свои, как и цели/политики фильтрации.

Далее описанные переменные можно использовать либо для логгирования плохих IP и составления черных списков для файервола, либо сразу банить этих ботов на уровне фронтэнда так:
custom/server_common:

PHP код:

if ($bad_location) {
  return 444;
}

if ($bad_ua) {
  return 444;
}

if ($bad_referer) {
  return 444;
}

if ($bad_ip) {
  return 444;
} 


этот файл инклудится в индивидуальный конфиг каждого вирт. хоста, примерно так
conf.d/domain1.com.conf:

PHP код:

server {

  include custom/server_common;

  server_name domain1.com;

  include custom/drupal;
} 


return 444 в nginx означает оборвать соединение. Если хоть один из признаков совпал, обрубаем соединение. Аналогично можно писать IP в отдельный лог-файл.

Удобство использования git в том, что при ковырянии логов на каком-то из серверов, если возникает необходимость внести изменения в конфиги, я их вношу и делаю commit/push в удаленный общий bare-репозиторий, с которого потом конфиги подхватываются другими серверами. Мне так удобно. Есть более правильный путь: chef/puppet/ansible/etc

nginx-фильтрация трафика - это реалтайм фильтрация, без анализа серий запросов.

еще несколько заметок:
- некоторые боты перебирают http-параметры, пробуют подсунуть разный реферер. При анализе серии запросов такое легко ловится
- другие боты, как уже упоминал выше, выдают себя за авторитетного хорошего бота, например, за Googlebot. Таких можно ловить по информации о клиентском IP. Если бот представился Googlebot, а его IP принадлежит хостеру OVH - это как минимум подозрительно
- часто боты не запрашивают картинки. Если бот выдает себя за человека и не запросил ни одной картинки/css/js, то это бот на 99%
- если бот даже запросил ресурсы(img/css/js), то порядок их загрузки имеет определенные правила и он зависит от браузеров и их версий.
- моего бота(php-crawler) на одном сервере все равно ловили, потом я понял почему.

Они помещали в код css 2 класса:
.img1 { background-image:url(/image1.jpg) }
.img2 { background-image:url(/image2.jpg) }
и в html использовали только первый стиль img1.

правила на том хосте были примерно такие:
если клиент не подгружает из CSS image1.jpg, то он бот
если клиент подгружает из CSS image1.jpg и image2.jpg, то он тоже бот!! - вот эту загадку я долго не мог разгадать
если клиент подгружает только image1.jpg, тогда он не бот

А у вас есть какие-нибудь истории/вопросы про фильтрацию веб-трафика?

[sspy]

Сообщение от chesser

А у вас есть какие-нибудь истории/вопросы про фильтрацию веб-трафика?

для апача есть подобное решение ? nginx у меня банит всё четко, а вот апач только на уровне htccess, хочется на более низком уровне.

для нгинкса юзаю так

if ($http_user_agent ~* Baiduspider|MJ12bot|NerdyBot) {
return 403;
break;
}

какой более правильный, твой или этот?

[chesser]

Сообщение от sspy

для апача есть подобное решение ? nginx у меня банит всё четко, а вот апач только на уровне htccess, хочется на более низком уровне.

в апаче есть httpd.conf и все, что в него инклудится - это статическая часть апачевского конфига, в ней побольше возможностей, чем в htaccess, синтаксис такой же, но надо ребутать/релоадить сервер. Но все равно хрен редьки не слаще )

А зачем ты апачем банишь, если есть nginx? или это про разные серверы?
Буржуи в связке с апачем часто используют lighttpd, но в связи с усилением международного пиара nginx, соотношение nginx / lighttpd изменилось.

Можно даже апачем собирать IP и формировать из них черные списки для фаервола - самый низкий уровень, который тебе доступен на сервере.

Сообщение от sspy

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

принципиальной разницы нет, оба правильные.

Для описания признаков я использую map-переменные, они имхо удобнее в использовании, чем if (список) , особенно когда этот список длинный - с одной стороны. С другой стороны, мои regexp-ы в map-ах надо бы разбивать и компоновать в группы...

Еще у тебя return 403 - т.е. бот-трафик проходит всю цепочку полностью, от (1) до (9), потому что 403 ответ - это именно HTTP-ответ, а не обрыв. У меня return 444 и nginx обрубает соединение в районе точки (4).
Возможно, у тебя цель отдать боту 403. Как эффективнее отваживать ботов ходить на сервер - я не знаю, статистики нет на этот счет, не сравнивал.

[pepper]

Для блокировки по ip в nginx'е удобнее использовать директиву geo. Можно целые подсети добавлять в CIDR формате

PHP код:

geo $bad_ip {
  default        0;
  78.46.0.0/15      1; # bot  HETZNER
  178.63.0.0/16     1; # bot  HETZNER
} 


На одном из серверов пытался как-то отловить бота, который делал по несколько запросов в секунду на внутренние адреса сайта, причем с верным рефером. По ip не получалось блокировать, т.к. ip были из сетей интернет-провайдеров (видимо соксы), UA тоже были валидные. На тот момент ограничился limit_req_zone.

[chesser]

точно, забыл про geo написать, хотя сам его где-то использую.

такой детский вопрос, на который не знаю ответа:
на сколько актуальна информация, выдаваемая по команде: whois IP ?

Пример:

5.135.18.89 - - [12/Jun/2013:06:15:55 +0400] "GET /phpmyadmin/ HTTP/1.1" 200 13820 "-" "Googlebot/2.1 (+http://www.googlebot.com/bot.html)" "-"

[chesser@slon ~]$ whois 5.135.18.89
[Querying whois.arin.net]
[Redirected to whois.ripe.net:43]
[Querying whois.ripe.net]
[whois.ripe.net]
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to '5.135.18.64 - 5.135.18.95'

% Abuse contact for '5.135.18.64 - 5.135.18.95' is '[email protected]'

inetnum:        5.135.18.64 - 5.135.18.95
netname:        LEAKID7
descr:          LEAKID7
country:        FR
admin-c:        OTC2-RIPE
tech-c:         OTC2-RIPE
status:         ASSIGNED PA
mnt-by:         OVH-MNT
source:         RIPE # Filtered

role:           OVH Technical Contact
address:        OVH SAS
address:        2 rue Kellermann
address:        59100 Roubaix
address:        France
admin-c:        OK217-RIPE
tech-c:         GM84-RIPE
nic-hdl:        OTC2-RIPE
abuse-mailbox:  [email protected]
mnt-by:         OVH-MNT
source:         RIPE # Filtered

% Information related to '5.135.0.0/16AS16276'

route:          5.135.0.0/16
descr:          OVH
origin:         AS16276
mnt-by:         OVH-MNT
source:         RIPE # Filtered

% This query was served by the RIPE Database Query Service version 1.74.1 (DB-4)

Какова вероятность, что этот IP на самом деле принадлежит не хостеру OVH, а, например, компании Google ?
Какова вероятность, что гугл арендовал у OVH их IP ?

[pepper]

Сообщение от chesser

Какова вероятность, что этот IP на самом деле принадлежит не хостеру OVH, а, например, компании Google ?
Какова вероятность, что гугл арендовал у OVH их IP ?

Думаю, маловероятно, хотя кто их знает
Как вариант, можно проверить ip (и соседние в подсети) на наличие на нем/них сайтов (в бинге или в других сервисах). Если есть, то с большой долей вероятности можно сказать, что ip под хостинг используется.

[sspy]

Сообщение от chesser

такой детский вопрос, на который не знаю ответа:
на сколько актуальна информация, выдаваемая по команде: whois IP ?

актуальна, т.к. это real time базы

Сообщение от chesser

Какова вероятность, что этот IP на самом деле принадлежит не хостеру OVH, а, например, компании Google ?
Какова вероятность, что гугл арендовал у OVH их IP ?

вероятность крайне мала. если ip гугловский то он палится чрез rDNS, если ни через whois и не rDNS не палится, значит они или втихую арендуют, что маловероятно, или кто-то просто прикинулся гуглботом, что вероятнее всего

[Grut]

Сообщение от chesser

...
Какова вероятность, что этот IP на самом деле принадлежит не хостеру OVH, а, например, компании Google ?
Какова вероятность, что гугл арендовал у OVH их IP ?

В соседней ветке подсказывают, что в поле abuse-mailbox всегда будет google.com

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

[W84me]

http://bgp.he.net/ для поиска подсеток, диапазонов и овнеров