Антиспам для WordPress, часть 2: что успело поменяться

В прошлой статье я рассказывал, почему в какой-то момент пришлось делать собственный Анти Бот для WordPress: Cloudflare для части клиентов стал недоступен, а платные альтернативы вроде облачных WAF просят от 10 тысяч рублей в месяц за один сайт – и это при том, что задача у большинства клиентов скромная: отсеять спам-регистрации, спам в комментариях и мусор в формах обратной связи.

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

Про офлайн-базы геолокации

Один из первых вопросов был в лоб: зачем вообще зависеть от внешнего API определения страны по IP, если есть офлайн-базы в CSV или MMDB? Я тогда ответил осторожно – офлайн-базы есть, они бесплатны, но обновляются реже и для части форматов (тот же MaxMind) нужна отдельная PHP-библиотека, которой на shared-хостинге часто просто нет. @GoShaman в комментариях справедливо указал на базу dpip как на рабочую бесплатную альтернативу с ежемесячными обновлениями – и его личный опыт с ней в VPN-сервисе звучал убедительно.

Полемику закрыли сами цифры: точность бесплатных офлайн-баз (и dpip, и MaxMind Lite) объективно ниже платных версий, а Анти Бот для WordPress изначально задумывался как решение, которому клиент может доверять в вопросах гео- и ASN-блокировки без последующих «а почему у меня заблокировался живой посетитель из своего же города». Поэтому вместо того, чтобы тянуть в плагин еще одну стороннюю офлайн-базу с ее нюансами точности, мы сделали свою – и в итоге получилось даже ближе к тому, о чем спрашивал @alekssamos чем к 2ip.io из первой статьи. Офлайн-база геолокации физически лежит на нашей стороне, но при этом умеет храниться и обновляться прямо у клиента – определение страны в основном идет локально, без похода во внешний сервис на каждый чих. А вот с базой по ASN поступили иначе и сознательно: она курируется нами и остается только на нашей стороне, клиентским установкам отдается уже результат, а не сам файл базы – тут больше вопрос размеров базы, чаще всего на хостингах клиентов места впритык, а полноценная база весит 2-3 гига.

Честный ответ, почему не просто honeypot и чем это отличается от готовых плагинов

@init0 справедливо покритиковал ставку на геоблокировку и User-Agent как таковую и предложил смотреть в сторону поведенческих ловушек – honeypot-полей в формах, которые бот заполняет, а человек не видит. И отдельно посоветовал присмотреться к готовому бесплатному IP Location Block как к более функциональной альтернативе.

Тут я хочу быть честным: geo блокировка и User-Agent – это не вся защита, а первый рубеж, который отсекает самый дешевый и массовый мусорный трафик почти бесплатно по нагрузке на сервер. Ловушки в духе honeypot решают другую задачу – они хороши против ботов, которые уже добрались до формы и пытаются ее отправить. Идеологически это близко к тому, что мы в итоге сделали с JS Challenge: вместо жесткой блокировки по стране или подозрительному провайдеру подозрительному посетителю показывается интерактивная проверка – что-то вроде капчи, только без раздражающих текстовых полей. Живой человек, даже зашедший через VPN не из той страны, проходит ее за пару секунд, а автоматический скрипт – нет. Это мягче, чем голый бан по IP, и точнее, чем просто спам-ловушка в форме.

А сравнение с готовыми бесплатными плагинами вроде IP Location Block – оно справедливое, и я его не обхожу: Анти Бот для WordPress не пытается конкурировать по количеству переключателей в настройках. Смысл был и остается в том, чтобы для клиента, который никогда не разберется в ASN и подсетях, все работало «из коробки» и стоило разумных денег .

Что реально поменялось с мая

Не буду грузить техническими деталями реализации — сразу к сути того, что стало доступно клиентам.

Во-первых, добавилась блокировка по ASN – то есть по конкретному хостинг- или дата-центр-провайдеру, а не только по стране или отдельному IP. Это ощутимо точнее: спам-боты сидят пачками на одних и тех же облачных провайдерах вне зависимости от того, в какой стране формально зарегистрирован IP, и блокировка на уровне провайдера отсекает такие пачки одним правилом, а не тысячами отдельных адресов.

Во-вторых, для заблокированных по ASN или из черного списка IP теперь можно использовать тот самый мягкий JS Challenge вместо мгновенного бана – это заметно снизило количество ложных срабатываний на живых людях, которые заходят через мобильных операторов или корпоративные VPN с «плохих» на вид адресов.

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

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

Первые платящие клиенты и честное сравнение с «топовыми» плагинами

С мая изменилось еще кое-что важное: Анти Бот для WordPress перестал быть только моим внутренним инструментом для клиентов на обслуживании – появились первые самостоятельные коммерческие пользователи, которые поставили плагин на свои проекты и платят за него сами. А там, где есть живые платящие клиенты на разных хостингах и с разной аудиторией, накапливается уже не синтетическая, а настоящая аналитика: что реально пытаются сделать боты, какой трафик приходит на сайты, откуда и с какой периодичностью.

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

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

С Wordfence, если совсем честно, сравнение сложнее, чем может показаться. Топовые позиции в любом рейтинге он занимает не просто так: платная Pro-версия действительно эффективна, и держится она на том же принципе, на котором раньше стоял Cloudflare – собственная база известных вредоносных IP и паттернов трафика, которая обновляется централизованно сразу по всем установкам. Это объективно сильнее, чем ставка исключительно на honeypot-ловушки в формах, которые советовал @init0 в комментариях к первой статье. Honeypot неплохо ловит ботов, которые пытаются заполнить форму – но он бессилен там, где боту форма вообще не нужна: парсинг контента, перебор паролей в админку, прямые запросы к уязвимым эндпоинтам. Точки соприкосновения с такими атаками у него просто нет.

Бесплатная версия Wordfence при этом урезана именно в части базы – свежие сигнатуры и репутация IP доезжают до нее с задержкой, поэтому для бесплатного тарифа мой изначальный вывод остается в силе: с массовым низкоуровневым спам-трафиком и геоблокировкой она справляется хуже платной. И отдельно всплыл побочный момент: как сообщалось, Wordfence в какой-то момент попал в перечень сервисов с ограничениями от РКН из-за передачи данных за рубеж – для сайтов российского бизнеса это уже не вопрос эффективности защиты, а отдельный юридический риск сверху, независимо от того, насколько хорошо работает сам плагин.

Насколько ощутима на практике разница между «ловушкой в форме» и «блокировкой по базе плюс мягкая проверка трафика», показала недавняя волна массовых взломов сайтов через свежую уязвимость в ядре WordPress, которую в комьюнити быстро окрестили wp2shell. Особенность атаки в том, что она шла не через формы вообще – один прямой HTTP-запрос к уязвимому эндпоинту сразу давал исполнение кода. Honeypot тут бесполезен по определению: боту не нужна форма, зацепиться не за что. Капча в формах – мимо цели по той же причине. А вот блокировка по базе подозрительных IP/ASN и челлендж для трафика из нецелевых для конкретного сайта стран сработали иначе: массовые автоматические сканеры, которые ищут уязвимые установки по всему интернету, в основном шли именно оттуда и до уязвимого эндпоинта на защищенных сайтах просто не добирались. У клиентов с Анти Ботом, которых застала эта волна, сайты остались целы и невредимы.

Really Simple Security (бывший Really Simple SSL, который со временем оброс функциями безопасности) тоже пробовали – но там защита от нежелательного трафика фактически сводится к жесткой блокировке по IP, без промежуточных сценариев вроде мягкой проверки для сомнительного, но не однозначно бот-трафика. Работает, но топором, а не скальпелем.

Не хочу, чтобы это звучало как реклама самого себя, и Wordfence Pro честно признаю сильным конкурентом – база данных действительно решает многое, там, где она есть. Но у большинства решений, с которыми реально сравнивались клиенты (бесплатные тарифы, honeypot как единственная линия защиты, жесткий бан по IP без полутонов), обнаружилась одна и та же слепая зона – именно там, где атака не идет через форму и не совпадает с уже известной сигнатурой. А судя по wp2shell, именно туда в последнее время метят самые болезненные атаки.

Куда дальше

Расширенная аналитика и правила для форм, о которых упоминал в первой статье, никуда не делись, просто в очереди. А в работу параллельно пошла задача заметно интереснее – своя система оценки посетителя, которая смотрит не на один запрос, а на поведение в целом: куки, история обращений к сайту, поведенческие паттерны. Сейчас блокировка принимает решение по каждому запросу почти изолированно; хочется научить ее видеть закономерности на дистанции. Простой пример, чтобы было понятно, о чем речь, а не абстракция: если у визита на каждый запрос меняется User-Agent, а все остальное – IP, куки, прочие признаки – остается неизменным, это уже само по себе подозрительный сигнал, живой браузер так не работает. Естественно, хотелось бы это сделать так, чтобы функционал не нагружал сайт, хост и работал на стороне клиента, а не посылал все на наш сервер. Это и для клиентов безопаснее, и никому не надают по попе за какие-нибудь косяки с персональными данными.

Толчком послужили как раз сайты с преимущественно зарубежной аудиторией, которые сейчас в тесте. На них простая логика «капча всем, кроме РФ» просто не работает – целевая аудитория сама живет в десятках разных стран, и грубая гео-отсечка режет живых людей не хуже, чем ботов. Приходится настраивать точечно, отдельно под каждый сайт: больше опираться на IP и ASN конкретных источников трафика, аккуратнее работать с User-Agent, и уже сейчас закладывать место под поведенческие сигналы и дополнительную информацию о провайдере – это следующий, самый интересный шаг.

Если у вас есть свежий кейс с обходом текущей защиты – как и в прошлый раз, готов разбирать конкретные ситуации в комментариях, это оказалось самым полезным форматом обратной связи.

Спасибо @alekssamos @GoShaman и @init0 отдельно — без вашего скепсиса Анти Бот для WordPress остался бы просто геоблокировкой, а не тем, чем стал сейчас.