Чей антибот лучше? Обзор алгоритмов защиты поисковых систем Рунета от парсинга

В далеких 90-х, когда только появлялись первые поисковые системы, начали проявляться основные проблемы, среди которых была и чрезмерная нагрузка. Нагрузка создавалась как обычными пользователями, так и автоматическими средствами.
Вначале поисковые системы были практически беззащитны, но с ростом популярности и увеличением количества пользователей им пришлось учиться защищаться.

Мы провели небольшое исследование — как и при каких условиях популярные поисковые системы в Рунете ограничивают доступ к поиску. Результаты читайте ниже.

Основные способы защиты

Итак, прежде чем описывать способы защиты каждой поисковой системы в отдельности, хотелось бы отметить известные на данный момент способы защиты:

1. Ограничение на выполнение 1 запроса с одного IP адреса в одну единицу времени (по умолчанию).
2. Предложение ввода капчи при подозрительном трафике (превышение лимита запросов, некорректный формат запроса и т.п.).
3. Увеличение времени ответа сервера (задержка) при большом количестве последовательных (один за другим) запросов.
4. Сохранение файлов cookies для хранения ID пользователя, истории запросов и ввода капч, настроек и многого другого.
5. Полное блокирование на некоторый промежуток времени а-ля “Сервис недоступен”.
6. Еще 1 способ защиты Google, который был открыт нами опытным путем — учет группы IP адресов как 1 IP по каким-либо признакам.

CAPTCHA

Одно из знаменательных событий в борьбе против автоматических запросов – появление небольшой “картинки”, которая получила название CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart – полностью автоматизированный публичный тест Тьюринга для различия компьютеров и людей).
Маленькая картинка сразу же обрела большую популярность, стала применяться поисковыми системами (и не только), так как очень сильно усложняла жизнь разработчикам различных инструментов, которые брали данные из поисковиков.
Человеку довольно просто разгадать то, что нарисовано на ней (за исключением слабовидящих), но для программы – это непосильная задача, особенно если используется множество скрытых слоев и генератор случайных чисел (т.е. не готовый набор капч).
Множество ресурсов в своем стремлении сделать “непобедимую” капчу дошли до крайностей, и даже люди с трудом могут ее расшифровать.

Теперь подробнее о способах защиты каждой поисковой системы:

Яндекс

Яндекс – самая популярная поисковая система Рунета.
Если ваш IP адрес не был замечен в “подозрительной деятельности”, либо прошел достаточно большой срок с последнего момента “подозрительной деятельности”, то ваш IP чист, и Яндекс не предлагает пользователю ввод капчи.

Если предыдущие “запросы, поступившие с вашего IP адреса, похожи на автоматические” (т.е. слишком много и очень часто), Яндекс предложит ввести 1 капчу для получения результатов по первому запросу.

После изменения вашего региона на любой регион из другой страны (через настройки) Яндекс предложит ввести еще 1 капчу. Почему Яндекс предлагает ввести первую капчу – ясно, но зачем вводить вторую – не совсем.

Есть предположение, что это контрольная капча либо своего рода “заглушка”, которая возникла в результате уязвимости (например, возможность обойти ввод первой капчи через изменение региона в настройках).

Оперируя фактами, можно сделать логичный вывод, что в базе данных Яндекса хранится список IP адресов и количество запросов с каждого IP. Так как после ~5000 последовательных запросов на тестовом IP не появлялось капчи даже после удаления всех фалов cookies, можно сделать вывод, что существует некий “черный список”, который обновляется спустя некоторое время.

Если ваш IP адрес уже находится в “черном” списке, избежать ввода хотя бы одной капчи не получится никак.
Яндекс позволяет  получить результаты с полностью отключенными cookies для обычных пользователей, но если вы уже в “черном” списке, вам придется включить cookies для сохранения cookie: spravka c очень длинным ключом после ввода капчи.

Даже если cookie: spravka уже сохранена, вам все равно необходимо включить сохранение файлов cookies.

Время жизни cookie: spravka составляет ровно 1 месяц, т.е. в течение месяца вы – подтвержденный пользователь Яндекса. Было замечено, что в течение месяца тестовый IP адрес был исключен из “черного” списка, т.е. время вывода вашего IP адреса – до месяца.

Еще один способ защиты Яндекса — “увеличение времени ответа сервера (задержка) при большом количестве последовательных (один за другим) запросов”. При продолжительном тесте задержка на некоторых запросах достигала 30-60 секунд.

Очень хороший способ, который никак не отражается на реальных пользователях, но в то же время позволяет существенно снизить нагрузку на сервера.

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

Достаточно интересно выглядит текст на странице капчи:

“Если автоматические запросы действительно поступают с вашего компьютера и вы об этом знаете (например, вам по роду деятельности необходимо отправлять Яндексу подобные запросы), рекомендуем воспользоваться специально разработанным для этих целей сервисом Яндекс.XML”.

Очень радует то, что Яндекс заботится не только об обычных пользователях, но и о тех, кто не приносит им прибыли. Четко прослеживается политика компании “Если не клиент, тогда партнер”.

Rambler

Самый старый поисковик Рунета (из ныне известных), на данный момент – партнер поисковой системы Яндекс. По некоторым признакам видно, что для защиты от автоматизированных запросов используются технологии Яндекса, но с небольшими отличиями.

У Яндекса и Рамблера один и тот же “черный” список, поэтому если вы есть в одном из них, тогда и в другом также на 100%.

Внешний вид капчи Рамблера полностью совпадает с капчей Яндекса, но альтернативы пользователю не предлагаются, так как Рамблер сам является партнером.

Также требуется сохранение файлов cookies, но, в отличие от Яндекс, предупреждения на странице капчи мы не видим. После ввода символов сохраняется та же cookie: spravka c очень длинным ключом. Сохранение файлов cookies требуется даже после ввода капчи, а обычным пользователям (не в черном списке) можно cookies не включать, как и у Яндекс.

Иногда страница с результатами очень долго грузится. Количество последовательных запросов с одного IP в “черном” списке на данный момент равно ~1000. Для IP не в “черном” списке кол-во последовательных запросов не ограничено до тех пор, пока адрес не появится в данном списке.

Если делать небольшие задержки между запросами, есть возможность избежать попадания в “черный” список и увеличения ответа сервера. Даже если Вы в него попали, алгоритм с задержками все равно работает.

Mail.ru

Вначале был почтовым сервисом, сейчас – крупный интернет-портал. В своем стремлении охватить всё и вся, портал Mail.ru добрался и до поисковой системы. В качестве движка использовал результаты сторонних поисковиков (Яндекс, Google) + немного своих. Крайне отрицательно относится к “роботам”, о чем четко сказано на странице капчи.

Не требуется сохранение файлов cookies как до, так и после ввода капчи. Если сохранение включено, то сохраняется cookie: ARCID с ключом. Даже при отключении cookies, ввод капчи разблокирует поиск в Mail.ru на некоторое время, чего нет в других поисковиках. Можно даже удалить сохраненнный cookie: ARCID с ключом, и это никак не повлияет на поиск.
Была замечена интересная особенность поведения капчи – если сделать задержку ~5 мин, страница капчи исчезнет и появится возможность сделать еще некоторое количество запросов до следующей капчи.

Google

Лучший поисковик в мире для пользователей и худший для тех, кто по роду своей деятельности вынужден отправлять большое количество автоматических запросов. По разнообразию и запутанности алгоритмов защиты он по праву занимает первое место в мире.
Вначале Google не требует сохранения файлов cookies, и если пользователь не превысил лимит запросов за единицу времени, тогда все хорошо.

На данный момент, чтобы добиться капчи, необходимо отправить последовательно 100-200 запросов, причем при отключенном JavaScript  в браузере это количество пропорционально уменьшается примерно в 2 раза.

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

Если у вас появилась первая капча, сохранение файлов cookies становится обязательным.

После ввода капчи сохраняется cookie: GDSESS с ключом (скорее всего, GoodSession). Удалять ее нельзя, в противном случае придется вводить еще 1 капчу. Время жизни данной cookie – ровно час. В течение данного периода времени можно отправить стандартное количество запросов, при превышении которого выводится следующая капча и т.д.

Google никак не различает формат запроса и то, на какой хост он был отправлен (.ru, .com.ua, .by, .com).
Имеет значение только количество запросов за определенный промежуток времени. Кроме того, cookie: GDSESS сохраняется  только для конкретного хоста, но все равно учитывается общее количество запросов для 1 IP адреса. Если в течение 1 часа с Вашего IP адреса не был превышен лимит запросов, данная cookie становится неактивной, ее можно удалить и снова отключить сохранение файлов cookies

К слову, в результате многочисленных тестов мы заметили, что временной  интервал зачастую составляет ~1 час.

Если сохранение cookies отключено, то в ответ на разгаданную капчу Google покажет еще одну капчу, и так будет продолжаться, пока после ~15-25 капчи Google не вернет страницу Sorry…

Никаких предупреждений о необходимости включения cookies на странице капчи Вы не увидите (в отличие от Яндекс).
Этот же принцип действует и при сохранении сookies после ввода капч.

Для Google имеет значение именно количество капч для одного IP, которое он вернул пользователю за определенный промежуток времени, и если оно превышает ранее озвученный лимит (~15-25), тогда возвращается страница Sorry…, вне зависимости от корректности ввода капч.

Страница Sorry… — это полное блокирование IP адреса, но на короткий срок. Возможности ввода капчи уже нет. Временной интервал отображения данной страницы составляет ~20-60 мин. После снятия временного блокирования ввод капчи не предлагается, наличие cookie: GDSESS не имеет абсолютно никакого значения, ее можно удалить, сохранение файлов cookies также уже не требуется.

Кажется, что Google полностью разблокировал IP адрес, но это не так. После ввода совсем небольшого количества запросов (10-50), мы снова видим страницу Sorry…, и чем чаще мы видим данную страницу, тем больше приходится ждать снятия временного блокирования, и тем меньше запросов можно отправить.

Отличие Google от других поисковых систем в том, что он не прибегает к увеличению времени ответа сервера (к задержке) и всегда возвращает страницу с результатами максимально быстро, но, к сожалению, компенсирует это временным блокированием и частым вводом капчи.
Совсем недавно был замечен еще один способ защиты, о существовании которого мы уже давно подозревали, но, к счастью, нам не приходилось с ним сталкиваться, до недавнего времени. Это объединение группы IP адресов по общему признаку и учет количества отравленных запросов с данных IP, как с одного IP.

Например, у Вас есть в наличии 4 подсети по 255 IP, т.е. ~1000 IP адресов. Если отправить множество запросов с первых двух подсетей и Google как-то сможет определить общий признак данных IP, неестественный для реального пользователя, то первые две подсети будут объединены в общий список, и после ~50-100 общих запросов с любого из IP будет предложен ввод капчи. После ввода ~15-25 капч для разных IP, каждый из них будет временно заблокирован.

Причем, если проделать аналогичные действия с 3-ей и 4-ой подсетями (например), но объединяющий признак будет уже другим, тогда эти подсети также будут считаться одним IP, но они никак не будут связаны с 1-ой и 2-ой подсетями. Временное блокирование первой группы не влияет на вторую и блокирование второй не влияет на первую.
Так что же может стать общим признаком, неестественным для обычного пользователя?
Рассмотрим на примере общего файла cookies c уникальным ID. Возможна ситуация, когда разные IP могут иметь одинаковые cookies (например, пользователь с динамическим IP), но никак не возможна ситуация, когда отправляются параллельно 15 запросов с наличием уникальной cookie. После таких явных признаков срабатывает настоящий бан группы IP, который не снимается очень долго, но так как Google понимает, что эти IP могут в дальнейшем использоваться обычными пользователями, в конечном случае он снимет бан с данных IP спустя некоторое время.

Защита Google хоть и впечатляет, но оставляет неприятный осадок. В отличие от Яндекс на странице капчи нет предложения включить cookies (если отключены), также нет никаких альтернатив для тех, кто по роду своей деятельности вынужден отправлять большое количество автоматических запросов.
Четко прослеживается политика компании “Если не клиент, тогда будешь клиентом”.

Хотелось бы отметить, что на данный момент цена за 1000 запросов через API Google составляет 5$, а если необходимо сделать 1 млн запросов — 5000$. Может для Google это и “капля в море”, но не каждый сможет позволить себе потратить такую сумму, особенно в странах третьего мира.

Заключение: Вопросы-Ответы

Почему в статье нет точных данных о количестве запросов и временных интервалах?

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

Почему поисковые системы защищаются от автоматических запросов?

1. Уменьшение нагрузки на сервера.
2. Желание сделать потребителей партнерами (Яндекс).
3. Желание сделать потребителей  клиентами (Google).
Может быть еще много вариантов, которые даже пока не поддаются логичному объяснению.

Примечание:
Все исследования проводились в браузере “Mozilla Firefox”, необходимые действия пользователя полностью иммитировались с помощью плагина “Selenium IDE” и инъекций JаvaScript. Также использовался плагин “Web Developer” для удобства оперирования файлами cookies, кэшем браузера и многими другими настройками браузера.

______________________________________________________________________

Автор: Виталий Гаврилюк,

QA Test Engineer SeoLib.ru

vitaliy.gavriliuk@gmail.com


Администрация SEOlib.ru

Администрация SEOlib.ru

Администрация сервиса для мониторинга позиций и аналитики SEOlib.ru


  • Константин

    Спасибо за обзор.

  • Александр

    Инфа по поводу банов Гугла из разных IP подсетей достоверная? Когда это было замечено?

  • Vitaliy Gavrilyuk

    Это было замечено больше месяца назад. Скорее всего этот алгоритм защиты у Google уже очень давно, но столкнулись мы с ним совсем недавно. В начале февраля интегрировался новый функционал, который подразумевал активное манипулирование cookies файлами Google. Возможно, не осторожные действия с нашей стороны и спровоцировали такую реакцию.

  • Виталий, спасибо, у нас тоже где то месяц назад была подобная история, используем API гугла.

  • Nano

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

  • Илья

    Виталий, огромное спасибо за исследование!

  • Vitaliy Gavrilyuk

    Всем пожалуйста. Кстати, можно еще добавить то, что Google в последнее время уменьшил лимит запросов в 1.5-2 раза. Еще пол года назад можно было свободно отправить 200-300 запросов до отображения капчи.

  • > Ограничение на выполнение 1 запроса с одного IP адреса в одну единицу времени

    слишком просто и, в принципе, в таком простом решении уже не используется по причине того, что на больших фирмах / организациях используются прокси-сервера. Т.е. 1000 комп./пользователей на выходе имеют один IP. Как минимальный базис сейчас используется комбинация IP/UserAgent и уже потом остальные составляющие по нарастающей

    > … учет группы IP адресов как 1 IP по каким-либо признакам.

    Одним из таких признаков также может являться UserAgent, анализируя который также можно из «сабсетки IP-адресов» выделить один «общий IP»

  • Иван

    Виталий! Нужно наверное делать свой поисковик.

  • Den

    У Mail.ru не все так просто. После ввода капчи, юзера бросает на некую промежуточную страницу, где выполняется некий JS, который и проставляет ARCID куку и потом редиректит на поиск.
    Если попытаться роботом просто засабмитить капчу, а затем повторно выполнить поиск (в отличии от браузера — не отрабатывается JS на промежуточной странице), то в ответе снова будет капча.

  • интересный обзор часто на капчу попадаю при скане сайтов по позициям, но до бана не доходило)

  • Vitaliy Gavrilyuk

    to slanet.ru

    > Ограничение на выполнение 1 запроса с одного IP адреса в одну единицу времени

    Отчасти Вы правы, сейчас используется более сложная защита от DDos-атак, но если бы такой защиты не было, тогда можно было бы легко провести атаку и повесить любой поисковик.
    Как пример: Запустили 10 одновременных тестов, которые без остановки делали запросы к Яндексу с разных версий Mozilla Firefox. Скорость по конкретному потоку хоть и не упала ровно в 10 раз, но все же заметно снизилась.
    Даже если в организации более 1000 человек и 1 внешний IP, то вероятность что пользователи сделают одновременный запрос, крайне мала и даже если сделают, то запросы выполняются так быстро, что увеличение на долю секунды никто даже и не заметит.

    > Одним из таких признаков также может являться UserAgent, анализируя который также можно из «сабсетки IP-адресов» выделить один «общий IP»

    UserAgent — это просто название браузера, которое может быть одинаковое у 1000 пользователей из одной и той же компании. Чтобы идентифицировать каждого пользователя, поисковики все же используют cookies файлы. Кстати, кроме user-agent еще передается и имя компьютера, которое имеет большую уникальность чем user-agent (см. 2ip.ru).

  • Я думаю, Вы сами несколько в технических терминах запутались 🙂

    > UserAgent — это просто название браузера
    Нет, это не «просто» Firefox, Opera или IE.
    В UserAgent «задано» гораздо больше параметров, например, «Opera/9.80 (Windows NT 6.1; WOW64; U; MRA 5.9 (build 4871); ru) Presto/2.10.289 Version/12.01» или «Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.60 Safari/537.1»

    > передается и имя компьютера
    в случае одной и той же компании «имя компьютера» — это не имя вашего компьютера, под которым вы работаете, а HostName прокси-сервера и оно имеет такую же «уникальность», как и IP прокси 😉

    А в остальном полностью с Вами согласен 🙂

  • Vitaliy Gavrilyuk

    > У Mail.ru не все так просто. После ввода капчи, юзера бросает на некую промежуточную страницу, где выполняется некий JS, который и проставляет ARCID куку и потом редиректит на поиск.
    Если попытаться роботом просто засабмитить капчу, а затем повторно выполнить поиск (в отличии от браузера — не отрабатывается JS на промежуточной странице), то в ответе снова будет капча.

    По Mail.ru все запросы делались хоть и через браузер, но с полностью выключенным JavaScript, сохранием cookies и кэша. Моделировалось максимально похожее поведение бота. После ввода некорректной капчи, редиректит на страницу http://go.mail.ru/ar, скорее всего об этой странице и шла речь. Вообще, по Mail.ru есть замечания в плане внутренней верстки — уж слишком гиганские у них пробелы!

  • Виталий, получается если есть контроль по куки, вариант использования прокси не работает, т.к. IP будет меняться, но те же user-ageте и cookies остается….?

  • Vitaliy Gavrilyuk

    Сергей, вариант использования прокси работает и будет работать еще долго. Главное подойти к делу с умом, можно хранить cookies для каждого IP и user-agent.

    В Selenium Webdriver, который используется Userator(ом) и мной тоже, можно создать отдельные профили в Firefox для каждого IP и навсегда забыть о подобной проблеме просто переключаясь между ними.