Разобрали журнал за двое суток: движок стал мягче к людям и строже к прокси-сетям

На этой неделе мы выгрузили журнал визитов за 48 часов по всем подключённым сайтам и прошли его с одним вопросом: где движок ошибся. В обе стороны — и где остановил человека, и где пропустил бота. Ошибки нашлись. Ниже — что именно и что мы с этим сделали.

Адреса мобильных операторов больше не блокируются жёстко

В правилах у нас это было записано с первого дня: за одним адресом мобильного оператора сидят сотни абонентов, поэтому такому адресу положена максимум проверка. На деле правило опиралось на справочник подсетей, который на сервере оказался пустым. За двое суток 127 жёстких блокировок пришлись на адреса МТС, Билайна, МегаФона и Т2. Судя по признакам, это были боты: настольный Chrome без положенных заголовков, одна и та же строка с сотен адресов. Но правило потому и правило, что за тем же адресом в ту же минуту может сидеть живой человек.

Теперь запрет живёт в самом движке и определяется по сети оператора. Бот с мобильного адреса получит проверку браузера, которую не пройдёт, а человек за тем же адресом её просто не заметит. Память о нарушителях на операторских адресах больше не копится.

Cron сайта и robots.txt проходят без проверки

На одном из сайтов 40 % всех проверок достались… самому сайту: задание по расписанию каждые несколько минут дёргало свою же страницу через wget и получало вместо ответа страницу проверки. На другом так ломался ночной прогрев кэша.

Движок теперь сам узнаёт сервер сайта — по адресу, на который указывает домен, и по адресам, с которых модуль сайта приходит к нам за решением (на виртуальном хостинге cron уходит именно с них), — и запросы с него пропускает; в журнале они помечены «Запрос с сервера самого сайта». Вносить сервер в белый список не нужно. Поиск файлов с секретами блокируется и с этого адреса.

Заодно /robots.txt отдаётся всем без условий. Робот, которому вместо этого файла показали проверку, ваших запретов не узнает — и пойдёт по сайту так, как сочтёт нужным.

Браузеры приложений — не headless

Признак «браузер без окна» срабатывал на телефонах. У встроенных браузеров — в приложении Яндекса, в браузерах Samsung, Huawei, Xiaomi, в рекламных приложениях — действительно нет ни окна в привычном смысле, ни объекта window.chrome. Для настольного Chrome это след автоматизации, для телефона — норма. На боевом сайте из-за этого покупатель мог получить страницу проверки на запросе корзины.

Скрипт 1.1.3 эти два факта следом больше не считает, движок не учитывает признак для мобильных и встроенных браузеров, а его вес снижен с 45 до 25.

Ещё одна находка из той же серии: одна причина давала два-три признака в разных группах. Приложение с «замороженной» версией Chrome в строке получало штраф за несовпадение версии в заголовках, потом за то же несовпадение в скрипте — и набирало блок на ровном месте. Теперь одна причина — одна улика, а у группы браузерных признаков появился потолок.

Поисковики узнаются по адресу

Поисковые системы ходят не только под своим именем. Яндекс проверяет страницы «обычным» Chrome — сверяет, что роботу и людям показывают одно и то же. Google загружает страницы через прокси предзагрузки. В строке браузера у таких визитов нет ни слова о роботе, и часть из них получала проверку.

Перед любым решением строже пропуска движок теперь выясняет, не принадлежит ли адрес поисковой системе: по её опубликованным спискам и по обратной записи DNS. Если да — визит проходит с пометкой «Адрес поисковой системы».

Сети прокси-провайдеров считаются хостингом

Вторая волна ботнета на одном из сайтов шла с «домашних» на вид адресов. 61 % этой волны пришёл из сетей коммерческих прокси-провайдеров, которых не было в нашем списке хостингов. Мы проверили: за 48 часов из этих сетей не пришло ни одного российского посетителя и ни одного визита с признаками человека. Сети добавлены; трафик из них получает признак «сеть хостинга».

Модуль 1.4.2: пропущенный однажды перепроверяется

Самая неприятная находка — в клиентском модуле. Решение «пропустить» он хранил дольше положенного: срок выходил, а модуль продолжал пользоваться старым ответом и нас не спрашивал. Пара «адрес + браузер», пропущенная один раз, больше не проверялась, и частоту её запросов движок не видел. На сайте под атакой журнал показывал 3,7 тысячи строк в час, а модуль за тот же час пропускал 32 тысячи запросов.

Модуль 1.4.2 срок соблюдает. Просроченный пропуск остаётся запасным ответом на случай, когда мы недоступны, — сайт от нас по-прежнему не зависит. Чтобы перепроверки не замедляли страницы людям, посетителя без единого замечания модуль помнит пять минут, а не одну.

Что вы заметите: после обновления модуля строк в журнале и «визитов проверено» станет больше при том же трафике. Это не рост посещаемости, а перепроверки, которых раньше не было. Модуль обновится сам.

Сайты в наблюдении не портят репутацию адресам

Сайт в режиме наблюдения никого не блокирует, но его «виртуальные» блокировки шли в общую память о нарушителях — и ложное срабатывание там, где его никто не видит, могло стать настоящей блокировкой на соседнем сайте. Теперь память пополняют только исполненные блокировки. А вместо уведомления «Отражена атака», которое для сайта без защиты было неправдой, приходит «Замечена атака»: заметили, но не остановили — защита выключена.

Автооткат

Страховка, которая снимает защиту при аномальной доле блокировок, получила три правки. Она считает только исполненные блокировки. После ручного включения защиты у сайта есть пять минут, в которые старые счётчики его не откатят. На сайтах с редким трафиком окно растягивается до часа — раньше на них страховка не набирала выборку и не работала.