Как остановить брутфорс и ботов на WooCommerce без Wordfence

Мне на прошлой неделе написал знакомый — владелец интернет-магазина автозапчастей на WooCommerce. Пишет: «Олег, у меня сайт тормозит, хостинг ругается на нагрузку, а я ничего не менял». Я захожу смотреть — и вижу классическую картину. За последние сутки в лог access.log напихано шестьдесят тысяч запросов к wp-login.php. Шестьдесят тысяч. С двухсот разных IP-адресов. Кто-то методично перебирает пароли — admin, administrator, shop, manager, test, 123456 — по кругу, без остановки. Боты работают как швейцарские часы: три-четыре запроса в секунду, ровно столько, чтобы не попасть под примитивную rate-limit защиту хостинга, но достаточно, чтобы сервер задыхался от обработки PHP-запросов.

Мой первый инстинктивный совет был — «ставь Wordfence». Это же рефлекс, правда? Безопасность WordPress — значит Wordfence. Я сам годами так думал. Но потом я остановился и задал себе вопрос, который стоило задать давно: а действительно ли Wordfence — единственный способ защититься от брутфорса? И действительно ли он — лучший способ для WooCommerce-магазина с его специфическими нагрузками и требованиями? Честно говоря, чем глубже я копал, тем больше убеждался, что для коммерческих сайтов на WooCommerce Wordfence — это примерно как стрелять из пушки по воробьям. Да, попадёшь. Но заодно разнесёшь полстены.

Давайте я расскажу, к чему я пришёл после нескольких лет борьбы с ботами и брутфорсом на реальных WooCommerce-проектах — и почему в какой-то момент отказался от тяжёлых универсальных плагинов безопасности в пользу точечных, встроенных решений. Это не теоретическое сравнение «десять лучших плагинов безопасности» — это опыт работы с промышленными магазинами, у которых шестнадцать тысяч товаров, две тысячи посетителей в день и нулевая толерантность к простою.

Почему Wordfence перестал быть моим выбором по умолчанию

Я не собираюсь говорить, что Wordfence — плохой продукт. Это было бы несправедливо. Wordfence — мощный, зрелый, хорошо поддерживаемый инструмент с огромной базой сигнатур. Проблема в другом: он проектировался как универсальное решение для любого WordPress-сайта, от блога домохозяйки до корпоративного портала. А WooCommerce — это не «любой сайт». Это магазин с динамическими страницами, AJAX-корзиной, чекаутом, API-запросами от платёжных систем, вебхуками от служб доставки и синхронизацией с 1С. И когда посреди всего этого стоит плагин размером больше ста мегабайт, который при каждом запросе проверяет его против базы из нескольких миллионов сигнатур — начинается самое интересное.

Я впервые столкнулся с этим на проекте для клиента, который торгует промышленными смазочными материалами. У него магазин на WooCommerce, шестнадцать тысяч позиций, синхронизация с 1С:Управление Торговлей через OData, поиск на Typesense, мега-меню с трёхуровневой навигацией, B2B-ценообразование с группами клиентов. Нормальный рабочий магазин. Стоял Wordfence Premium — сто девятнадцать долларов в год, всё как положено. И вот однажды мы заметили, что страницы каталога стали грузиться на полторы секунды дольше после обновления Wordfence. Полторы секунды — это вечность для интернет-магазина. Мы стали копать и обнаружили, что Wordfence конфликтует с LiteSpeed Cache. Оба плагина пытаются контролировать HTTP-заголовки, оба лезут в обработку запросов на раннем этапе, и в результате кеширование работает через раз. Часть страниц отдаётся из кеша, часть — нет, и пользователь видит то быстрый, то медленный сайт. Inconsistency — худшее, что может быть в e-commerce.

Мы потратили два дня на настройку исключений. Добавили URL паттерны для чекаута, корзины, API-эндпоинтов, AJAX-хендлеров WooCommerce. Вроде заработало. Через месяц Wordfence обновился — и часть исключений перестала работать, потому что формат конфига немного изменился. Снова тратим время. И в какой-то момент я подумал: стоп, а что конкретно Wordfence делает для нас такого, чего мы не можем добиться проще?

Оказалось, что из всего огромного арсенала Wordfence мы реально использовали четыре функции: защиту от брутфорса, блокировку подозрительных IP, CAPTCHA на формах и мониторинг файлов. Файервол с его WAF-правилами — да, полезно. Но у нас на хостинге уже стоит ModSecurity с набором правил OWASP. Сканер малвари — запускали раз в месяц, ни разу ничего не нашёл (потому что мы не ставим левые плагины и темы). Двухфакторная аутентификация — настроена только у администратора. Получается, мы платим сто девятнадцать долларов в год и терпим конфликты с кешированием ради функционала, который можно реализовать значительно легче.

Знаете, что меня окончательно убедило? Я посмотрел на размер плагина. Wordfence с его базой сигнатур, файерволом, сканером и админкой — это больше ста мегабайт. Сто мегабайт PHP-кода, который так или иначе загружается при каждом запросе к сайту. Для сравнения, весь WooCommerce — около сорока мегабайт. То есть плагин безопасности больше, чем платформа, которую он защищает. Для блога это терпимо. Для магазина с тысячами одновременных сессий — нет.

И ещё один момент, который редко обсуждают. Wordfence хранит логи, статистику, данные сканирования и таблицы файервола в базе данных WordPress. В той самой базе данных, которая у WooCommerce-магазина и так перегружена — wp_postmeta на нашем проекте весит 937 мегабайт. Добавлять к этому ещё несколько таблиц с миллионами строк от Wordfence — значит усугублять и без того нетривиальную ситуацию с производительностью MySQL.

Я не говорю, что все должны срочно удалить Wordfence. Для многих сайтов это отличный выбор. Но если у вас WooCommerce-магазин с серьёзной нагрузкой, кешированием на уровне сервера и специфическими интеграциями — стоит задуматься, нет ли способа получить нужную защиту без этого тяжеловеса. Спойлер: есть. И сейчас я расскажу, как мы это сделали.

Анатомия атаки: что именно делают боты и чего они хотят

Прежде чем защищаться, стоит понять, от чего конкретно мы защищаемся. Я заметил, что многие владельцы магазинов воспринимают «атаку на сайт» как нечто из голливудских фильмов — хакер в капюшоне яростно стучит по клавиатуре, на экране бегут зелёные символы. В реальности девяносто процентов атак на WordPress/WooCommerce-сайты — это полностью автоматизированные процессы. Боты. Скрипты. Никакого человека за экраном нет. Есть бот-сеть из нескольких тысяч скомпрометированных серверов и IoT-устройств, которая методично обходит миллионы WordPress-сайтов и пробует стандартные логины с паролями из утёкших баз данных.

Основная цель — получить доступ к админке. Не для того, чтобы украсть ваши товары или базу клиентов (хотя и это случается). Чаще всего взломанный WordPress используют как промежуточное звено: размещают фишинговые страницы, рассылают спам через вашу почту, устанавливают майнеры криптовалюты, редиректят ваших посетителей на сторонние сайты. Для WooCommerce-магазина последствия катастрофические: Google в течение часов помечает сайт как опасный, покупатели видят красный экран предупреждения в браузере, продажи падают до нуля. Восстановление репутации в поисковых системах может занять недели.

Вектор атаки номер один — это брутфорс через wp-login.php. Стандартная страница входа WordPress, которая по умолчанию доступна всему миру. Бот отправляет POST-запрос с парой логин-пароль, получает ответ, отправляет следующий запрос. При скорости три-пять запросов в секунду бот может перебрать десятки тысяч комбинаций за день. Если у вас пароль «shop2024» — вопрос не в том, взломают ли вас, а когда. Причём даже если бот не угадает пароль, он всё равно наносит вред: каждый запрос к wp-login.php — это полноценная PHP-сессия с подключением к базе данных, проверкой учётных данных, записью в лог. Шестьдесят тысяч таких запросов в сутки — это серьёзная нагрузка даже для хорошего сервера.

Вектор номер два — XML-RPC. Это протокол удалённого взаимодействия с WordPress, который был придуман в те времена, когда люди публиковали посты в блоге через десктопные приложения. В 2026 году XML-RPC использует примерно ноль процентов владельцев WooCommerce-магазинов. Зато его активно используют боты, потому что через XML-RPC можно отправить метод system.multicall с сотнями пар логин-пароль в одном запросе. То есть вместо того чтобы стучаться в дверь сто раз, бот стучится один раз и передаёт сто ключей одновременно. Многие плагины безопасности ограничивают попытки входа через wp-login.php, но забывают про XML-RPC — и боты просто переключаются на этот канал.

Вектор номер три — формы регистрации и чекаута. На WooCommerce-магазине, в отличие от обычного блога, есть открытые формы, которые доступны неавторизованным пользователям: регистрация аккаунта, оформление заказа, форма обратной связи, иногда запрос коммерческого предложения. Боты используют эти формы для двух целей — спам-регистрации (создание тысяч фейковых аккаунтов) и проверки валидности email-адресов из утёкших баз. Форма чекаута особенно уязвима, потому что через неё можно проверять украденные банковские карты мелкими транзакциями — так называемый card testing. PayPal, Stripe, YooKassa — все они борются с этим, но если у вас нет CAPTCHA на чекауте, вы фактически предоставляете ботам бесплатный инструмент для проверки карт.

Понимание этих трёх векторов определяет стратегию защиты. Нам не нужен универсальный файервол с миллионами правил. Нам нужно закрыть три конкретные двери — и закрыть их надёжно.

Защита от брутфорса: умная блокировка вместо грубой силы

Когда я начал проектировать модуль защиты от брутфорса, я первым делом изучил, как это делает Wordfence. И знаете, что понял? Подход на самом деле простой. Считаешь количество неудачных попыток входа с одного IP-адреса за определённый период. Превысил лимит — блокируешь IP на время. Это не rocket science. Но дьявол, как всегда, в деталях, и именно детали отличают хорошую реализацию от плохой.

Первая деталь — прогрессивная блокировка. Наивная реализация «пять попыток — блокировка на пятнадцать минут» не работает против серьёзных бот-сетей. Бот просто ждёт пятнадцать минут и начинает снова. Или переключается на другой IP. Мы реализовали экспоненциальную блокировку: первая серия неудачных попыток — блокировка на пятнадцать минут, вторая — на час, третья — на четыре часа, четвёртая — на сутки. IP, который стабильно пытается подобрать пароль, через несколько циклов оказывается заблокированным на двадцать четыре часа. За это время бот-сеть обычно переключается на другие цели.

Вторая деталь — подсчёт попыток не только по IP, но и по имени пользователя. Если кто-то перебирает пароли к аккаунту admin с тысячи разных IP-адресов — это всё равно атака, даже если с каждого IP было всего по одному запросу. Мы считаем отдельно: попытки с одного IP и попытки к одному логину. Превышение любого из лимитов активирует блокировку. Для IP — блокируется адрес. Для логина — блокируется возможность входа под этим именем на определённый период, независимо от IP.

Третья деталь — мгновенные уведомления. Когда срабатывает блокировка, администратор получает email. Не через час, не в ежедневном дайджесте — сразу. В письме указан заблокированный IP, страна, количество попыток и логин, который пытались подобрать. Это важно не только для реагирования, но и для понимания паттернов. Когда ты видишь, что в течение недели идут попытки входа под логином «manager» с IP-адресов из одного блока — ты понимаешь, что кто-то целенаправленно атакует именно твой сайт, а не ведёт массовый скан. И тогда уже принимаешь другие меры.

Четвёртая деталь — белый список. Если у вас фиксированный IP в офисе, его нужно добавить в белый список, чтобы случайно не заблокировать самого себя. Звучит очевидно, но я знаю два случая, когда администратор магазина заблокировал свой собственный IP неудачными попытками входа (забыл пароль, попробовал пять раз) и потом не мог зайти в админку. С белым списком этого не произойдёт. А ещё мы добавили автоматическое определение IP-адреса администратора при первой настройке — чтобы он не забыл добавить себя вручную.

Всё это работает на уровне PHP, без внешних зависимостей, без обращений к облачным API, без гигабайтных баз сигнатур. Данные о попытках входа хранятся в таблице лога активности, которая и так нужна для аудита. Никакой дополнительной нагрузки на базу данных — запись одной строки при каждой попытке входа. По сравнению с Wordfence, который при каждом запросе проверяет IP против облачной базы репутации (а это DNS-запрос или HTTP-запрос к их API) — разница в производительности существенная.

Я долго думал, стоит ли добавлять интеграцию с внешними базами репутации IP-адресов, как это делает Wordfence с его Threat Intelligence Feed. Решил, что нет. На практике девяносто пять процентов атак отсекаются уже на этапе ограничения попыток входа. Оставшиеся пять процентов — это целевые атаки, от которых база репутации IP всё равно не спасёт, потому что атакующий использует чистые прокси, которых нет ни в одной базе. А плата за интеграцию с внешним сервисом — зависимость от стороннего API, дополнительная латентность на каждом запросе и потенциальные проблемы, если API недоступен.

Скрытый URL и CAPTCHA: два простых приёма, которые решают восемьдесят процентов проблем

Знаете, какой самый простой способ остановить автоматизированные атаки на wp-login.php? Убрать wp-login.php. Точнее, не убрать — а спрятать за другим URL. Вместо стандартного example.com/wp-login.php ваша страница входа будет доступна по адресу, скажем, example.com/my-secret-door. А при обращении к wp-login.php бот получит 404. Это настолько простой приём, что многие его недооценивают. А зря.

Дело в том, что абсолютное большинство ботов, которые атакуют WordPress — это тупые скрипты, которые жёстко запрограммированы на обращение к wp-login.php и xmlrpc.php. Они не парсят вашу страницу в поисках формы входа, не анализируют JavaScript, не ищут ссылку «Войти» в меню. Они просто отправляют POST-запрос на wp-login.php — и всё. Если по этому адресу возвращается 404 — бот переходит к следующему сайту из списка. Всё, атака закончилась, не начавшись.

Мы реализовали кастомный URL логина довольно элегантно. При активации функции администратор задаёт свой собственный slug — например, academic, entrance, my-login, что угодно. Плагин перехватывает все запросы к wp-login.php и wp-admin (для неавторизованных пользователей) и возвращает 404. При этом все внутренние ссылки WordPress — кнопка «Выйти», ссылки в письмах о смене пароля, редирект после истечения сессии — автоматически перезаписываются на новый URL. Пользователь ничего не замечает, для него всё работает как раньше, только адрес входа другой.

На нашем боевом проекте — магазине промышленных масел — мы включили кастомный URL логина и в течение суток увидели, что количество запросов к wp-login.php упало с шестидесяти тысяч до нуля. Буквально до нуля. Боты продолжали стучаться в wp-login.php, получали 404 и уходили. Нагрузка на сервер снизилась заметно — те самые полторы секунды задержки, которые мы наблюдали раньше, исчезли. И это без единого правила файервола, без базы сигнатур, без облачного сервиса.

Но скрытый URL — это защита от автоматизированных ботов. А что делать с полуавтоматизированными атаками, когда человек находит вашу страницу входа и запускает направленный перебор? Или со спам-регистрациями через форму WooCommerce? Или с card testing через чекаут? Тут на сцену выходит CAPTCHA.

Мы поддерживаем три варианта: Google reCAPTCHA v2 (классическая «я не робот» с картинками), Google reCAPTCHA v3 (невидимая, оценивает поведение пользователя) и hCaptcha (альтернатива от Cloudflare, без Google-зависимости). У каждого варианта свои сильные и слабые стороны, и выбор зависит от специфики магазина.

reCAPTCHA v2 — самая надёжная с точки зрения отсечения ботов. Если бот не может кликнуть по картинкам с автобусами — он не пройдёт. Минус — она раздражает живых пользователей. На чекауте WooCommerce-магазина это может стоить вам конверсии. Покупатель уже ввёл адрес доставки, выбрал способ оплаты, а тут ему показывают десять размытых фотографий с вопросом «выберите все картинки с пожарными гидрантами». Кто-то решит, что сайт сломался, кто-то просто уйдёт к конкурентам.

reCAPTCHA v3 решает эту проблему — она невидимая. Пользователь ничего не нажимает, никаких картинок не разгадывает. Google анализирует поведение пользователя на странице — движения мыши, скорость заполнения формы, историю браузера — и присваивает score от нуля до единицы. Выше 0.5 — скорее всего, человек. Ниже — скорее всего, бот. Мы позволяем настроить порог score в админке, потому что для разных форм нужны разные уровни строгости. Для входа в админку можно поставить порог 0.7 — пусть лучше перестрахуется. Для чекаута — 0.3, чтобы не терять легитимных покупателей с нестандартным поведением (например, тех, кто заполняет форму с клавиатуры без мыши).

hCaptcha — интересная альтернатива для тех, кто принципиально не хочет отдавать данные пользователей Google. Работает похожим образом, но данные обрабатываются Cloudflare. Для европейских клиентов с GDPR-требованиями — может быть критически важно.

Ключевой момент — куда именно ставить CAPTCHA. Многие плагины безопасности ставят её только на wp-login.php и на этом считают задачу выполненной. Но на WooCommerce-магазине есть ещё три критические формы, о которых часто забывают. Форма регистрации — через неё боты создают тысячи фейковых аккаунтов. Форма восстановления пароля — через неё можно проверять, существует ли конкретный email в базе (форма отвечает по-разному для существующих и несуществующих адресов). И форма чекаута — card testing, о котором я уже говорил. Мы ставим CAPTCHA на все четыре точки: вход, регистрация, восстановление пароля, чекаут. Настраивается отдельно для каждой формы — можно включить v3 на чекауте (невидимую) и v2 на входе (явную).

Вот тут я хочу сделать важное замечание. CAPTCHA — не серебряная пуля. Продвинутые ботнеты умеют обходить reCAPTCHA v2 с помощью сервисов вроде 2Captcha или Anti-Captcha, где живые люди за копейки кликают по картинкам. reCAPTCHA v3 можно обмануть, эмулируя поведение человека в headless-браузере. Но всё это требует от атакующего значительных усилий и ресурсов. Массовый бот, который сканирует миллионы сайтов, не будет тратить на вашу CAPTCHA ни цента — он просто перейдёт к следующему сайту без защиты. А целевая атака — это уже совсем другой уровень угрозы, и от неё нужно защищаться другими средствами. CAPTCHA в данном случае — это первый рубеж, который отсекает девяносто девять процентов автоматизированного мусора.

Два этих приёма вместе — скрытый URL логина и CAPTCHA на формах — решают подавляющее большинство проблем с ботами на WooCommerce-магазине. Без единой строчки конфигурации файервола, без облачных подписок, без стомегабайтного плагина. Просто чистая, точечная защита на конкретных уязвимых точках.

XML-RPC: самая недооценённая дыра в WordPress

Я помню момент, когда узнал про XML-RPC amplification attack. Это было лет пять назад, и я был искренне удивлён — как такое вообще возможно в современном мире? XML-RPC — это legacy-протокол WordPress, который позволяет удалённо управлять сайтом через XML-запросы. Публикация постов, управление комментариями, загрузка файлов — всё это можно делать через xmlrpc.php. Проблема в том, что этот файл поддерживает метод system.multicall, который позволяет объединить несколько вызовов в один запрос. И атакующие быстро сообразили, как это использовать.

Вместо того чтобы отправлять тысячу отдельных запросов с разными паролями (что легко отследить и заблокировать), бот отправляет один запрос с методом system.multicall, внутри которого — тысяча вызовов wp.getUsersBlogs, каждый с уникальной парой логин-пароль. WordPress честно обрабатывает все тысячу вызовов и возвращает результат. Один HTTP-запрос — тысяча проверок пароля. Ни один счётчик попыток входа на wp-login.php этого не увидит, потому что атака идёт через совершенно другой канал.

Но брутфорс — это ещё полбеды. XML-RPC используется и для другого типа атак — DDoS amplification. Бот отправляет XML-RPC pingback-запрос на ваш сайт с поддельным обратным адресом жертвы. Ваш WordPress честно отправляет pingback-запрос на адрес жертвы. Если бот делает это одновременно с тысяч скомпрометированных WordPress-сайтов — жертва получает DDoS-атаку, а ваш сайт становится невольным участником бот-сети. Приятная перспектива, правда? Ваш домен попадает в чёрные списки, хостинг получает abuse-жалобы, и вы даже не знаете, что происходит, пока вам не напишет разгневанный хостер.

Решение? Полное отключение XML-RPC. В 2026 году ни один WooCommerce-магазин не нуждается в этом протоколе. WordPress REST API давно заменил все функции XML-RPC — и делает это безопаснее, быстрее и с нормальной аутентификацией. Мобильное приложение WordPress? Работает через REST API с версии 5.0. Jetpack? Давно перешёл на REST. Публикация через сторонние приложения? REST API. Нет ни одной легитимной причины держать xmlrpc.php открытым.

Мы отключаем XML-RPC на двух уровнях. На уровне WordPress — через фильтр xmlrpc_enabled, который возвращает false. Это отключает обработку XML-RPC запросов внутри WordPress. И на уровне HTTP — перехватываем запросы к xmlrpc.php и возвращаем 403 ещё до того, как WordPress начнёт их обрабатывать. Второй уровень важен, потому что даже после отключения через фильтр сам файл xmlrpc.php остаётся доступным и может обрабатывать некоторые запросы до того, как фильтр сработает. Двойная защита — надёжнее.

После отключения XML-RPC на боевом проекте я посмотрел логи и увидел, что количество заблокированных запросов к xmlrpc.php составляет в среднем три-пять тысяч в сутки. Три-пять тысяч запросов, которые раньше обрабатывались WordPress целиком — парсинг XML, подключение к базе данных, проверка учётных данных — теперь отсекаются на самом раннем этапе с минимальным потреблением ресурсов. Это не просто безопасность — это оптимизация производительности.

IP-менеджмент: когда нужна тяжёлая артиллерия

Скрытый URL, CAPTCHA и отключение XML-RPC — это три базовых рубежа, которые решают девяносто процентов проблем с ботами. Но иногда нужно действовать жёстче. Иногда ты видишь в логах, что с определённого диапазона IP-адресов идут не просто попытки входа, а систематическое сканирование уязвимостей — запросы к wp-config.php.bak, .env, .git/HEAD, debug.log. Или видишь, что конкретная подсеть генерирует аномальный трафик на страницы каталога — не ботов, которые пытаются войти, а скраперов, которые копируют ваш каталог товаров с ценами. В таких случаях нужен IP-менеджмент.

Мы реализовали его в виде двух списков — чёрного и белого. Чёрный список блокирует IP-адреса или целые подсети (в формате CIDR) полностью — сервер возвращает 403 на любой запрос. Белый список, наоборот, освобождает указанные адреса от любых проверок — никаких ограничений на попытки входа, никакой CAPTCHA, никаких задержек. Белый список обычно содержит IP-адреса офиса, домашних подключений администраторов и адреса доверенных сервисов (серверы 1С, платёжные системы, сервисы доставки).

Но ручное ведение чёрного списка — это сизифов труд. Сегодня вы заблокируете десять адресов, завтра атака пойдёт с другого ботнета, и придётся блокировать ещё двадцать. Поэтому мы добавили автоматическую блокировку по паттернам поведения. Если IP-адрес в течение часа генерирует больше определённого количества запросов 404 (что говорит о сканировании уязвимостей), он автоматически попадает в чёрный список. Если IP трижды превышает лимит попыток входа — автоматическая блокировка. Если с IP приходят запросы, содержащие типичные payload-строки SQL-инъекций или XSS — моментальная блокировка. Всё это можно настроить, пороги можно менять, потому что для разных магазинов нормальное поведение выглядит по-разному.

Здесь я хочу предупредить о подводном камне, на который сам наступал. Автоматическая блокировка IP может заблокировать легитимных пользователей, которые сидят за NAT или корпоративным прокси. В крупной компании сотни сотрудников могут выходить в интернет через один IP-адрес. Если кто-то из них несколько раз неудачно попытается войти в ваш магазин — весь офис окажется заблокированным. Поэтому автоматическую блокировку нужно настраивать осторожно: высокие пороги, короткое время блокировки для первого срабатывания, обязательные уведомления администратору. И белый список для IP-адресов крупных клиентов, если вы их знаете.

Отдельная тема — гео-блокировка. Если ваш магазин работает только на Россию и СНГ, есть ли смысл принимать трафик из Индонезии, Нигерии или Бразилии? Статистика показывает, что значительная часть ботнетов базируется в странах Юго-Восточной Азии, Африки и Южной Америки. Блокировка целых стран — грубый, но эффективный инструмент. Мы поддерживаем блокировку по странам на основе GeoIP-базы MaxMind. Можно заблокировать конкретные страны, можно инвертировать — разрешить только определённые страны и заблокировать все остальные. Для B2B-магазина, который работает исключительно с российскими юрлицами, вариант «разрешить только Россию и Беларусь» отсекает огромное количество мусорного трафика.

Но я должен сказать честно: гео-блокировка — это не про безопасность в чистом виде. Это скорее про гигиену. Серьёзный атакующий арендует VPS в нужной стране за пять долларов и обойдёт вашу гео-блокировку за минуту. Гео-блокировка хороша против массовых ботнетов, которые не адаптируются под конкретный сайт. А таких — большинство.

Лог активности: знать всё, что происходит на сайте

Есть одна вещь, которую я считаю даже более важной, чем все перечисленные механизмы защиты. Это лог активности. Полная аудиторская запись всего, что происходит на сайте. Кто вошёл, когда, с какого IP. Кто изменил настройки. Кто обновил плагин. Кто отредактировал товар. Кто изменил цену. Кто удалил пользователя.

Почему это так важно? Потому что безопасность — это не только предотвращение атак. Это ещё и обнаружение. И расследование. Если вас всё-таки взломали (а стопроцентной защиты не существует), лог активности позволяет понять: когда именно произошло проникновение, через какой вектор, что атакующий успел сделать, какие данные скомпрометированы. Без лога вы будете действовать вслепую — менять все пароли, переустанавливать все плагины, проверять все файлы. С логом — точечно исправляете то, что было затронуто.

Я расскажу реальный пример из практики. На одном проекте мы обнаружили, что кто-то изменил email получателя заказов в настройках WooCommerce. Заказы продолжали приходить на сайт, но уведомления уходили на сторонний email — кто-то буквально перехватывал заказы с контактными данными клиентов. Без лога активности мы бы, возможно, месяцами не заметили проблему. С логом — увидели запись об изменении настройки, время, IP-адрес и даже user-agent браузера, из которого это было сделано. Выяснилось, что один из сотрудников использовал слабый пароль, его аккаунт был скомпрометирован, и через него изменили настройку. Мы сбросили пароль, включили двухфакторную аутентификацию, вернули правильный email — и всё это заняло час, а не неделю.

Наш модуль лога активности записывает события в отдельные кастомные таблицы — wpaic_activity_log и wpaic_activity_log_contexts. Отдельные таблицы, а не wp_options или wp_postmeta, которые и так перегружены. Каждая запись содержит тип действия, объект действия (пост, товар, пользователь, настройка), старое и новое значение, IP-адрес, user-agent и метку времени. Логируются все критически важные действия: входы и выходы из системы, изменения пользователей и ролей, обновления плагинов и тем, изменения настроек WooCommerce, изменения товаров и цен, действия с заказами, изменения файлов.

Важная деталь — хранение логов. Если логировать всё и вечно, таблица разрастётся до неприличных размеров. Мы храним логи за настраиваемый период — по умолчанию девяносто дней. Записи старше этого периода автоматически удаляются через Action Scheduler. Можно увеличить до года, можно уменьшить до тридцати дней — зависит от ваших требований к аудиту. Для компаний, которые работают с персональными данными (а это любой интернет-магазин), девяносто дней — разумный баланс между требованиями безопасности и экономией ресурсов.

И ещё один момент, который я хочу подчеркнуть. Лог активности — это не только про безопасность. Это ещё и про управление. Когда у вас несколько менеджеров работают с магазином, вы хотите знать, кто и что изменил. Менеджер случайно обнулил цену на популярный товар? Видно в логе. Стажёр удалил важную страницу? Видно в логе. Подрядчик обновил плагин, который сломал чекаут? Видно в логе. Это инструмент не паранойи, а нормального управления бизнес-процессами.

Когда я показываю владельцам магазинов лог активности за первые сутки после включения, реакция обычно одна и та же: «Я и не знал, что столько всего происходит на сайте». И это правда — большинство людей даже не представляют, сколько автоматических процессов WordPress и WooCommerce запускают в фоне. Обновления транзиентов, cron-задачи, Action Scheduler, вебхуки — всё это генерирует события, которые без лога остаются невидимыми.

Всё без отдельного плагина: почему встроенная защита лучше

Теперь давайте поговорим о том, что объединяет все перечисленные механизмы и что делает этот подход принципиально отличным от установки Wordfence. Все эти функции — защита от брутфорса, скрытый URL, CAPTCHA, отключение XML-RPC, IP-менеджмент, гео-блокировка, лог активности — реализованы как модули одного плагина, который одновременно управляет вашим каталогом, B2B-ценообразованием, поиском, доставкой и синхронизацией с 1С. Это не «ещё один плагин безопасности в дополнение к десяти другим». Это встроенная защита, которая знает о вашем магазине всё.

Почему это важно? Потому что модули одного плагина не конфликтуют друг с другом. Модуль безопасности знает про модуль кеширования CSS и не мешает ему работать. Модуль CAPTCHA знает про формы Quote Request и автоматически добавляет проверку. Модуль лога активности знает про действия B2B-модуля и логирует изменения групп клиентов, тиров цен, субаккаунтов. Это единая экосистема, а не набор разнородных инструментов, которые нужно отдельно настраивать и надеяться, что они не подерутся.

Второй плюс — размер и производительность. Модуль безопасности — это несколько PHP-классов общим объёмом около ста килобайт. Не мегабайт — килобайт. Он не тащит с собой базу сигнатур размером с энциклопедию, не сканирует файловую систему при каждом запросе, не отправляет данные в облако. Он делает ровно то, что нужно, и ни грамма больше. На WooCommerce-магазине с LiteSpeed Cache, Redis и Typesense каждый мегабайт и каждая миллисекунда на счету. Модуль безопасности, который добавляет к обработке запроса одну-две миллисекунды — это категорически другая история, чем Wordfence с его двадцатью-тридцатью миллисекундами.

Третий плюс — стоимость. Wordfence Premium стоит сто девятнадцать долларов в год за один сайт. Sucuri Firewall — двести долларов. iThemes Security Pro — около ста долларов. Если у вас несколько магазинов — умножайте. Встроенная защита уже включена в стоимость плагина, который вы и так используете для управления магазином. Никаких дополнительных подписок, никаких отдельных лицензий.

Четвёртый плюс — единая точка настройки. Вместо того чтобы прыгать между админкой Wordfence, панелью Cloudflare, настройками .htaccess и конфигом сервера — вы настраиваете всё в одном месте. Вкладка «Безопасность» в уже знакомой админке плагина. Защита от брутфорса, CAPTCHA, кастомный URL, XML-RPC, IP-списки, лог активности — всё под одной крышей, с единым стилем интерфейса и единой документацией.

Я слышу возражение: «Но Wordfence имеет WAF с тысячами правил для защиты от SQL-инъекций, XSS и других атак уровня приложения!» Верно. И у нас тоже есть WAF — модуль Web Application Firewall с правилами для обнаружения SQL-инъекций, XSS, path traversal и других распространённых атак. Но мы не пытаемся заменить ModSecurity или конкурировать с Cloudflare WAF. Мы закрываем уровень приложения — тот, который видит WordPress-специфичные атаки, которые серверный WAF может пропустить. Это комплементарная защита, а не замена серверного файервола.

А ещё я хочу сказать про один аспект, о котором почти никто не говорит. Когда у вас на сайте стоит Wordfence — вы, по сути, доверяете безопасность своего магазина сторонней компании Defiant Inc. Если завтра они решат поднять цену до трёхсот долларов в год — вы заплатите, потому что вся ваша конфигурация безопасности привязана к их плагину. Если они закроют бесплатную версию — вы заплатите. Если они допустят уязвимость в своём плагине (а такое бывало) — пострадает ваш магазин. Встроенная защита в составе вашего основного плагина управления магазином — это контроль. Вы знаете, что стоит, как это работает, и вы не зависите от ценовой политики отдельного вендора.

Мне нравится аналогия с автомобилем. Wordfence — это как установить на машину отдельную, навесную систему безопасности: стороннюю сигнализацию, отдельный иммобилайзер, внешний GPS-трекер, дополнительные замки на двери. Каждый компонент сам по себе хорош, но вместе они иногда конфликтуют — сигнализация срабатывает от иммобилайзера, GPS-трекер разряжает аккумулятор, дополнительный замок заклинивает штатный. Встроенная безопасность — это как заводская система: ABS, ESP, подушки безопасности, иммобилайзер — всё спроектировано вместе, всё работает как единое целое, ничего не конфликтует. Не такая навороченная? Может быть. Но для девяноста пяти процентов ситуаций на дороге — более чем достаточно. А для оставшихся пяти процентов есть специализированные решения уровня Cloudflare Enterprise, которые работают на другом уровне и не конфликтуют ни с чем.

Я не хочу, чтобы вы восприняли эту статью как «Wordfence — зло, удаляйте немедленно». Нет. Wordfence — хороший инструмент для определённых сценариев. Но если у вас серьёзный WooCommerce-магазин с высокой нагрузкой, кешированием на уровне сервера и необходимостью экономить каждую миллисекунду — задумайтесь, не платите ли вы слишком высокую цену (и в деньгах, и в производительности) за функционал, который можно получить значительно дешевле и легче. Точечная защита на уровне конкретных векторов атаки — брутфорс, XML-RPC, спам-регистрации, card testing — в сочетании с полным аудитом действий даёт реальную безопасность без побочных эффектов.

Попробуйте включить модуль безопасности, настроить кастомный URL логина, добавить CAPTCHA на формы, отключить XML-RPC — и посмотрите на логи через сутки. Готов поспорить, вы увидите десятки тысяч заблокированных ботов и ощутимое снижение нагрузки на сервер. А потом откройте лог активности и посмотрите, что реально происходит на вашем сайте. Это будет одновременно страшно и полезно. Страшно — потому что вы увидите, сколько всего вы раньше не замечали. Полезно — потому что теперь вы это контролируете.

И напоследок — один совет, который не связан с плагинами. Самая надёжная защита от брутфорса — это сильный пароль. Двадцать символов, буквы в обоих регистрах, цифры, спецсимволы, никаких словарных слов. Звучит банально, но я регулярно вижу магазины с оборотом в десятки миллионов рублей, где пароль администратора — название компании с годом основания. Все технические меры защиты, которые я описал — это барьеры, которые замедляют атакующего и отсеивают ботов. Но если ваш пароль — «admin2024», никакой скрытый URL и никакая CAPTCHA вас не спасут, потому что он будет подобран за первые сто попыток. Сильный пароль плюс двухфакторная аутентификация плюс кастомный URL логина плюс ограничение попыток входа — это четыре слоя защиты, каждый из которых многократно усложняет задачу атакующего. Пробить все четыре одновременно — это задача, на которую ни один массовый ботнет не будет тратить ресурсы. Он просто пойдёт к следующему сайту, где стоит пароль «123456» и открыт xmlrpc.php. Не будьте этим сайтом.