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

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

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

Nginx установил из коробки ispmanager lite

ispmanager предоставляет немного дубовую интеграцию nginx, но для начала и этого обычно хватает снизить нагрузку со статики. Тем не менее для защиты от DOS надо вмешиваться ручками.

У тебя сейчас веб-сервер состоит из 2-х компонентов:
- фронтэнд (это nginx), который принимает все HTTP запросы от юзеров и далее решает, что с ними делать: отдать файл сразу или отправить на обработку апачу или заблокировать юзера или ... - т.е. nginx типа метрдотеля, который встречает на входе гостей и определяет их куда-нибудь )
- бекэнд (у тебя это апач, хотя вместо него можно использовать php-fpm), который выполняет php/perl/python/...-скрипты и выдает их результат.

Как оно у тебя работает для статики:
http-клиент -> nginx -> отдаем сразу файл (картинка, css, js)

для php:
http-клиент -> nginx -> apache -> выполнение php -> nginx -> отдаем ответ апача

Основная проблема с нагрузкой заключается в запуске php...просто потому, что это сложные манипуляции с памятью, процессором, диском, да если еще php-код кривой, то совсем все будет плохо. Поэтому надо стараться допустить к апачу/php только хороших http-клиентов, а плохих банить в nginx еще на подступах.

тебе надо в http{} определить зоны блокировки, а в server {} или в location{} от нужного домена использовать эти зоны. Например, применить зону в том месте, где nginx передает запрос апачу на исполнение, т.о. при запросе php файла более N-раз nginx прекратит передачу запросов апачу для этого IP юзера. Как-то так.

Вообще, я бы советовал изучать это без панелей. Возьми дешевую впску за 5-10 баксов и потренируйся....без панелей и без апача )) nginx + php-fpm - инструкции по настройки - окей гугл

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

Еще вопрос, я несовсем понимаю, если я захочю свою ОС поставить как ето нада сделать?

обычно, при заказе vps/vds хостер спрашивает желаемую ОС и часто это все автоматизированно, т.е. клиент сам может (пере-)устанавливать ОСы как ему угодно, а хостер только обеспечивает стандартными образами популярных ОС. Ну или напиши тикет своему хостеру, что хочешь сделать реинстал системы и хочешь такую-то ОС.