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

[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]

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

если в nginx заблочить 4к ip через map или deny, на работоспособность не повлияет?

вряд ли

[editeur]

Смысл блочить nginx-ом когда есть iptables? Или на каждый домен свои IP блочите?

[digg]

самые прикольные фишки выкупания ботов - это по двум картинкам и по какому-нибудь непонятному заебу для человека типа бесконечных форм
но на последний нужно потратить живой траф с buy viagra
может лучше движения мышки ловить? или если мышка ховер над боди, но как тут быть тогда с моб?

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

[chesser]

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

может лучше движения мышки ловить?

мышку эмулируют. Вижу много ботов, похожих на полноценный браузер, но скорее всего они headless, потому что: 1) хост типа OVH или амазона 2) не качают картинки 3) делают неадекватные прямые заходы на внутряки, на которые люди не ходят и тд. В яндекс метрике показывается движение мышью, но малое время.

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

но это уже только на уровне фронтенда

угу, этот топик больше про server-side

[assasin]

самые прикольные фишки выкупания ботов - это по двум картинкам и по какому-нибудь непонятному заебу для человека типа бесконечных форм
но на последний нужно потратить живой траф с buy viagra
может лучше движения мышки ловить? или если мышка ховер над боди, но как тут быть тогда с моб?

Вот же есть старый, как говно мамонта, способ ловли ботов с невидимой ссылкой (пиксел 1x1), до сих пор работает неплохо http_//www.infonew.ru/bottrap/

[alter13]

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

Вот же есть старый, как говно мамонта, способ ловли ботов с невидимой ссылкой (пиксел 1x1), до сих пор работает неплохо http_//www.infonew.ru/bottrap/

Истину речешь!
Лежит у меня несколько таких в закладках http://www.webtlk.com/blacklist.dat
Да и на всех дорах моих так же сделано...
Все ипаки собираются... и в клоаку...

[chesser]

1) эта статья технически устарела, предложенные способы с php и htaccess будут замедлять сервер. Банить надо файерволом или в nginx (что хуже).
2) таким способом ловятся ну прям совсем простые боты, которые бездумно "тыкают" по всему, что движется. Сейчас 2014 год уже. Вы либо не видели нормальных ботов, либо они вас пока еще не парсят.
3) я видел, как гугл проходил сквозь Disallow

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

[Cttr]

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

гугл проходил сквозь Disallow

Запретный плод сладок

На днях решился почитать доступно про iptables. Не всё так страшно, как может показаться на первый взгляд. Советую

[editeur]

про iptables в данном контексте надо знать полторы команды

iptables -I INPUT -s  207.102.138.3 -j DROP #забанить IP 
iptables -I INPUT -s  207.102.138.0/24 -j DROP #забанить подсеть
iptables -I INPUT -p tcp -m iprange --src-range  207.102.138.0-207.102.138.25 -j DROP #забанить диапазон

[sspy]

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

про iptables в данном контексте надо знать полторы команды

чуть больше, учитывая что правила iptables слетают после перезагрузки