На прошлой неделе я получил письмо от клиента — владельца интернет-магазина промышленных масел на WooCommerce. Тема была лаконичной: «Нас взломали». Через полчаса созвона я узнал, что история банальная до зубовного скрежета. Кто-то подобрал пароль к аккаунту менеджера, зашёл в админку, экспортировал базу клиентов — имена, телефоны, адреса доставки, историю заказов — и исчез. Никто не заметил вторжения двое суток. Менеджер использовал пароль «company2024», двухфакторной аутентификации не было, стандартный wp-login.php висел на виду у всего интернета, а единственной «защитой» был Wordfence, который три месяца назад перестал обновляться из-за просроченной лицензии. Знакомая картина? Я видел такое десятки раз за последние пять лет, и каждый раз испытываю одинаковое чувство — смесь досады и понимания, что этого можно было избежать.

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

Я занимаюсь разработкой и маркетингом для B2B и промышленных компаний уже много лет, и за это время насмотрелся на последствия взломов достаточно, чтобы понять одну вещь: безопасность WooCommerce-магазина — это не опция, это фундамент. Без него всё остальное — красивый сайт, отлаженная воронка продаж, настроенная CRM — рассыпается в момент. Именно поэтому, когда мы проектировали модуль безопасности для COS WP Woo, мы подошли к этому не как к «ещё одной фиче», а как к системе, которая должна закрывать все основные векторы атак на WooCommerce. И сегодня я хочу рассказать, как устроена эта система — не абстрактно, а на конкретных примерах и с объяснением, зачем нужен каждый уровень защиты.

Почему WooCommerce-магазин — лакомая цель

Давайте для начала разберёмся, почему именно WooCommerce-магазины так часто взламывают. Причин несколько, и они все работают одновременно. WordPress — самая популярная CMS в мире, на ней работает больше 40% всех сайтов. WooCommerce — самый популярный плагин для электронной коммерции, который превращает WordPress в полноценный интернет-магазин. Это означает, что любая найденная уязвимость мгновенно становится применимой к миллионам сайтов. Хакеры не ищут уязвимость в вашем конкретном магазине — они находят дыру в версии WordPress 6.4.2 или в плагине Contact Form 7 версии 5.8, а потом автоматизированный скрипт обходит сотни тысяч сайтов и пытается эту дыру эксплуатировать. Вы просто попадаете под каток. Никакой персональной ненависти.

Но есть и другая сторона. В отличие от обычного блога, WooCommerce хранит данные, которые представляют реальную ценность. Таблица wp_postmeta на среднем магазине — это сотни мегабайт информации, включающей адреса доставки, телефоны, email-адреса, иногда даже частичные данные карт. Таблица wp_users содержит хеши паролей, а если кто-то из админов использует одинаковый пароль на нескольких сервисах — считай, вся цепочка скомпрометирована. Я работал с одним магазином, где таблица wp_postmeta весила почти гигабайт — почти 17 000 товаров, десятки тысяч заказов за семь лет. Утечка такой базы — это не просто неприятность, это потенциальный штраф по 152-ФЗ и репутационный удар, от которого мелкий бизнес может не оправиться.

И вот ещё что я заметил: среди владельцев интернет-магазинов распространено заблуждение, что если у них настроен SSL-сертификат и стоит какой-нибудь плагин безопасности, то они защищены. SSL — это шифрование соединения между браузером и сервером, замечательная штука, но она не защищает от SQL-инъекций, от подбора пароля, от вредоносного скрипта в чужом плагине. А «какой-нибудь плагин безопасности» зачастую оказывается бесплатной версией Wordfence или iThemes Security, которую установили два года назад и с тех пор ни разу не открывали. Реальная защита — это не один инструмент, это комплекс мер, которые работают на разных уровнях. И я хочу пройтись по каждому из этих уровней.

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

WAF — первая линия обороны, которая работает до того, как беда случилась

Я долго думал, с чего начать рассказ о конкретных инструментах, и решил начать с WAF — Web Application Firewall. Потому что это тот самый компонент, который отсекает 80% мусорного трафика ещё до того, как запрос долетит до вашего PHP-кода. По сути, WAF — это фильтр, который анализирует каждый входящий HTTP-запрос и сравнивает его с набором правил. Если запрос выглядит как попытка SQL-инъекции — заблокировать. Если в URL торчит конструкция типа ../../../etc/passwd — это path traversal, заблокировать. Если в параметрах запроса едет JavaScript-код — это XSS-атака, заблокировать.

Звучит просто, но реализация — это дьявол в деталях. Я помню, как на одном проекте мы поставили ModSecurity на сервер, и он тут же начал блокировать легитимные запросы от WooCommerce. Потому что WooCommerce при оформлении заказа отправляет такие формы, что ModSecurity с правилами OWASP CRS начинает подозревать SQL-инъекцию в каждом втором POST-запросе. Итог — клиенты не могли оформить заказ, конверсия упала в ноль, мы потратили два дня на тюнинг правил. Именно поэтому WAF, который работает на уровне приложения и понимает контекст WordPress и WooCommerce, — это не то же самое, что WAF на уровне сервера.

В нашем модуле WAF работает как middleware, который перехватывает запрос на самом раннем этапе, ещё до того как WordPress начинает обрабатывать маршрутизацию. Он проверяет GET-параметры, POST-тело, cookies, заголовки — всё, что приходит от клиента. И он знает, что такое WooCommerce. Он понимает, что POST-запрос на checkout с полем billing_address_1 — это нормально, а GET-запрос с параметром ?id=1 UNION SELECT * FROM wp_users — это не нормально. Это важное отличие от универсальных решений: наш WAF заточен под WordPress и WooCommerce, поэтому количество ложных срабатываний минимально.

Честно говоря, когда я смотрю на логи WAF после первой недели работы на любом более-менее посещаемом WooCommerce-магазине, у меня каждый раз округляются глаза. Десятки тысяч заблокированных запросов. SQL-инъекции, попытки обхода директорий, XSS-пробы, сканирование известных уязвимостей в популярных плагинах — это происходит 24/7, без перерывов и выходных. На одном из наших клиентских проектов WAF за первый месяц заблокировал 47 000 вредоносных запросов. Сорок семь тысяч. И владелец магазина до установки нашего модуля был уверен, что его «никому не нужный сайт» никто не атакует.

Но WAF — это первая линия. Он останавливает массовые автоматизированные атаки. Против целенаправленного взлома с использованием украденных учётных данных WAF не поможет. Для этого нужны другие инструменты.

Кастомный URL входа и блокировка XML-RPC: убираем мишени с видного места

А что если посмотреть на проблему с другой стороны? Вместо того чтобы строить стены, можно просто убрать то, во что стреляют. Каждый, кто хоть раз смотрел логи доступа WordPress-сайта, видел бесконечные запросы к /wp-login.php и /xmlrpc.php. Это два адреса, которые боты знают наизусть. Они прописаны в каждом скрипте для брутфорса, в каждом автоматизированном сканере. Уберите эти адреса — и 90% автоматизированных атак просто упрутся в 404-ошибку и пойдут искать следующую жертву.

Кастомный URL для страницы входа — это идея, которую я раньше считал «security through obscurity» и немного снобистски отвергал. Мол, настоящая безопасность должна быть основана на сильных паролях и правильной аутентификации, а не на том, что мы прячем дверь. Но практика показала, что я заблуждался. Нет, конечно, кастомный URL — это не замена сильным паролям и двухфакторке. Но это потрясающе эффективный способ снизить нагрузку от ботов и убрать 99% автоматизированного мусора из логов. Когда мы на одном из продовых сайтов сменили /wp-login.php на кастомный URL, количество попыток входа в сутки упало с 3 000 до 12. Двенадцать! Это реальные люди, которые знали адрес — администраторы и менеджеры магазина. Все остальные три тысячи — это были боты, которые тупо долбились в стандартный адрес.

В нашем модуле это реализовано через компонент LoginUrl. Вы задаёте произвольный адрес — хоть /my-secret-door, хоть /academic, хоть /вход-в-систему-1234. Стандартные /wp-login.php и /wp-admin (для незалогиненных) перестают работать, возвращая 404. Бот приходит на /wp-login.php, получает «страница не найдена», делает пометку «тут WordPress нет» и уходит. Элегантно и эффективно.

Теперь про XML-RPC. Это древний протокол, который WordPress унаследовал из своего прошлого движка — b2/cafelog. Он позволяет удалённо управлять сайтом через XML-запросы. Когда-то это было полезно для мобильных приложений и внешних редакторов, но с появлением REST API потребность в XML-RPC практически исчезла. А вот атакующие XML-RPC очень любят. Почему? Потому что метод system.multicall позволяет в одном HTTP-запросе отправить сотни попыток аутентификации. То есть вместо того чтобы делать 500 запросов к wp-login.php (что легко заметить и заблокировать), атакующий делает один запрос к xmlrpc.php с 500 комбинациями логин-пароль внутри. Некоторые плагины защиты от брутфорса даже не замечают этот вектор, потому что считают попытки входа только через стандартную форму.

Мы просто закрываем xmlrpc.php полностью. Один переключатель в настройках — и протокол блокируется. Никаких XML-RPC, никаких multicall. Если вам нужен доступ из внешних приложений — для этого есть REST API с нормальной аутентификацией и rate limiting. Я не встречал ни одного реального бизнес-сценария в 2025-2026 году, где XML-RPC был бы необходим. А вот сценариев, где через него ломали сайты — встречал достаточно.

Здесь стоит сделать важное уточнение. Некоторые скажут: «Ну, Jetpack использует XML-RPC для связи с WordPress.com». Да, использует. Но если вы перешли на наш модуль безопасности, вам Jetpack для этих целей уже не нужен. К тому же Jetpack давно начал миграцию на REST API. Короче, закрывайте XML-RPC и не оглядывайтесь.

Двухфакторная аутентификация и защита от брутфорса: два замка лучше одного

Давайте поговорим об аутентификации — самом, казалось бы, простом и при этом самом уязвимом месте любого WooCommerce-магазина. Я могу поставить самый мощный WAF, закрыть XML-RPC, спрятать URL логина, но если администратор сайта использует пароль «admin123» — вся моя оборона рассыпается, как карточный домик. И не надо думать, что я утрирую. По статистике, которую я видел в реальных проектах, примерно каждый четвёртый WooCommerce-магазин имеет хотя бы одного пользователя с административными правами и паролем из десяти символов без спецсимволов. Это не халатность — это реальность, в которой менеджер по продажам должен помнить пароли от двадцати систем и выбирает то, что легче запомнить.

Двухфакторная аутентификация решает эту проблему радикально. Даже если злоумышленник узнал пароль — украл, подобрал, перехватил, нашёл в утёкшей базе — он не сможет войти без второго фактора. В нашем модуле мы реализовали TOTP — Time-based One-Time Password, тот самый стандарт, который использует Google Authenticator, Microsoft Authenticator и десятки других приложений. Администратор сканирует QR-код, приложение начинает генерировать шестизначные коды, которые меняются каждые 30 секунд. При входе нужно ввести логин, пароль и текущий код из приложения. Три фактора? Нет, два — пароль это «что ты знаешь», код из приложения это «что ты имеешь» (телефон с приложением). Классическая двухфакторка.

Я настаиваю на том, чтобы 2FA была обязательной как минимум для всех администраторов и менеджеров магазина. Опционально — для всех пользователей. Знаете, какой аргумент я слышу чаще всего? «Это неудобно для сотрудников, они будут жаловаться». Отвечаю всегда одинаково: знаете что неудобно? Звонить клиентам и объяснять, что их персональные данные утекли, потому что Маша из отдела продаж решила, что «qwerty» — достаточно надёжный пароль. Одноразовый код добавляет три секунды к процессу входа. Три секунды против потенциальной утечки данных тысяч клиентов. Мне кажется, выбор очевиден.

Но 2FA — это второй замок. А что с первым? Тут вступает в игру защита от брутфорса. Наш модуль LoginProtection работает по принципу прогрессивной блокировки. Первые три неудачные попытки входа — предупреждение. После пятой — блокировка IP на 15 минут. После десятой — на час. После двадцатой — на сутки. Причём блокировка работает не только по IP, но и по имени пользователя. Это важно, потому что атакующие иногда используют распределённые ботнеты с тысячами IP-адресов, но целятся в один аккаунт — «admin» или «manager». Если по имени пользователя «admin» было 20 неудачных попыток с разных IP — мы блокируем вход для этого имени на определённое время, вне зависимости от IP.

И вот тут я хочу рассказать историю, которая отлично иллюстрирует, зачем нужны все эти механизмы вместе. Один из наших клиентов — производитель гидравлического оборудования с WooCommerce-магазином. У него работали три менеджера, каждый со своим аккаунтом. Одна из менеджеров уволилась, но её аккаунт никто не заблокировал. Через два месяца пароль от этого аккаунта всплыл в публичной утечке данных другого сервиса (где менеджер использовала тот же пароль). Бот нашёл этот пароль, попробовал на wp-login.php — и вошёл. Если бы стоял наш модуль — кастомный URL логина означал бы, что бот просто не нашёл бы страницу входа. Если бы каким-то чудом нашёл — 2FA потребовала бы код из приложения, которого у бота нет. А если бы и 2FA не было — мониторинг активности показал бы вход с незнакомого IP в 3 часа ночи, и администратор получил бы уведомление. Три линии обороны, каждая из которых могла бы предотвратить инцидент самостоятельно. А все три вместе — делают взлом практически невозможным.

Отдельно хочу сказать про CAPTCHA. Мы поддерживаем Google reCAPTCHA v2, reCAPTCHA v3 и hCaptcha — на выбор. CAPTCHA можно включить на форме входа, на форме регистрации, на странице оформления заказа, на форме восстановления пароля. reCAPTCHA v3 работает невидимо — пользователь ничего не замечает, а Google на основе поведенческого анализа решает, бот это или человек. Для большинства магазинов рекомендую именно v3 — она не раздражает покупателей и при этом эффективно отсекает ботов. На формах входа в админку — можно поставить v2 с классической галочкой «Я не робот», тут UX менее критичен, зато защита жёстче.

Геоблокировка: хирургический подход к фильтрации трафика

Знаете, я долго скептически относился к геоблокировке. Казалось, что блокировать целые страны — это слишком грубый инструмент, что-то из серии «бить молотком по комарам». Но потом я начал анализировать логи атак на клиентских сайтах и изменил мнение. Не на 180 градусов — скорее на 120. Геоблокировка — это не панацея, но это поразительно эффективный инструмент для определённых сценариев.

Вот конкретные цифры с одного из проектов. За месяц WAF заблокировал около 50 000 вредоносных запросов. Я разбил их по геолокации. 38% — из стран Юго-Восточной Азии, которые не входили в целевой рынок магазина. 22% — из Южной Америки, тоже мимо. 15% — из Африки. 12% — из Восточной Европы (но не из России и не из СНГ). Итого: 87% вредоносного трафика приходило из регионов, откуда у магазина не было ни одного реального клиента. Ноль заказов, ноль регистраций, ноль обращений. Чистый атакующий трафик.

Геоблокировка позволяет закрыть доступ к сайту (или к определённым его частям — например, только к wp-admin и REST API) для IP-адресов из выбранных стран. Это не замена WAF — это дополнение. WAF анализирует содержимое запроса, геоблокировка фильтрует по источнику. Вместе они создают двойной фильтр: сначала отсекается трафик из нецелевых регионов, а то, что осталось, проверяется WAF на вредоносность.

Но я хочу быть честным: геоблокировка подходит не всем. Если ваш магазин продаёт по всему миру, блокировать страны — плохая идея. Если у вас есть клиенты в Бразилии или Индии — блокировать эти регионы нельзя. Геоблокировка идеальна для магазинов с чётко определённым географическим рынком. Российский B2B-магазин, который продаёт только по России и СНГ? Можно смело закрыть доступ из стран, откуда точно не придут заказы, но точно придут атаки. Магазин, который работает на Россию и ЕС? Закройте те регионы, с которыми вы не работаете. Каждый заблокированный регион — это тысячи вредоносных запросов, которые просто не дойдут до вашего сервера. Это и безопасность, и экономия ресурсов сервера.

В нашем модуле геоблокировка настраивается через удобный интерфейс — выбираете страны, указываете, что блокировать (весь сайт или только админку), и включаете. Базы GeoIP обновляются автоматически. Можно задать whitelist для конкретных IP, которые не должны блокироваться вне зависимости от страны — это полезно, если у вас есть удалённый разработчик из заблокированного региона.

И ещё один момент, который стоит осветить. Геоблокировка на уровне приложения (нашего плагина) работает несколько иначе, чем геоблокировка на уровне CDN (Cloudflare) или сервера (CSF/iptables). На уровне приложения запрос уже дошёл до PHP, и мы его обрабатываем. Это означает минимальную нагрузку на сервер, но запрос всё-таки обрабатывается. Если у вас стоит Cloudflare — идеально включить геоблокировку и там, и у нас. Cloudflare отсечёт трафик до того, как он дойдёт до сервера, а наш модуль поймает то, что проскочило через Cloudflare (например, запросы напрямую к IP сервера, минуя CDN). Эшелонированная оборона — помните?

IP-менеджмент: чёрные и белые списки, автоматическая блокировка по паттернам

IP-менеджмент — это инструмент, который на первый взгляд кажется примитивным. Чёрный список, белый список — что тут сложного? Но при правильном использовании он становится мощным тактическим средством. Я расскажу, как мы его применяем и почему он важен в комплексе с другими мерами.

Белый список — это священная территория. IP-адреса, которые никогда не блокируются, ни при каких обстоятельствах. Сюда попадают адреса вашего офиса, домашние IP администраторов, IP-адреса доверенных сервисов — платёжных систем, 1С, API-партнёров. Я видел ситуацию, когда сервис мониторинга начал слать запросы, которые WAF интерпретировал как сканирование уязвимостей, и заблокировал их. Результат — мониторинг показывал, что сайт лежит, хотя он работал прекрасно. Белый список решает такие проблемы.

Чёрный список — это жёсткая блокировка. Адрес в чёрном списке получает отказ немедленно, без какой-либо обработки. Чёрный список удобен для ручной блокировки конкретных источников атак, которые вы обнаружили в логах. Увидели, что с конкретного IP идёт подозрительная активность — в чёрный список, разберёмся потом.

Но самое интересное — автоматическая блокировка по паттернам. Наш модуль может автоматически отправлять IP в чёрный список, если с этого адреса фиксируется определённый паттерн поведения: слишком много 404-ошибок за короткое время (признак сканирования), слишком много попыток входа, попытки доступа к несуществующим PHP-файлам, обращения к типичным бэкдорам (wp-config.php.bak, .env, debug.log). Это работает в связке с WAF и LoginProtection, создавая автоматическую систему реагирования: обнаружил подозрительную активность — заблокировал, записал в лог, уведомил администратора.

Знаете, что мне нравится в этом подходе? Он самообучающийся. Не в смысле машинного обучения — в смысле, что каждая атака делает систему сильнее. Каждый заблокированный IP пополняет базу, каждый паттерн атаки уточняет правила. Через месяц работы ваш модуль безопасности знает конкретные IP-диапазоны, с которых чаще всего атакуют именно ваш сайт, и блокирует их проактивно.

Мониторинг целостности файлов: ваш тихий сторож

А теперь давайте поговорим о том, что происходит, когда все предыдущие линии обороны не сработали. Допустим, злоумышленник всё-таки получил доступ. Пусть через уязвимость в стороннем плагине, через скомпрометированный FTP-аккаунт хостинга, через SQL-инъекцию, которую WAF не распознал. Что он делает первым делом? Он модифицирует файлы. Добавляет бэкдор в functions.php темы, подкладывает PHP-шелл в директорию uploads, изменяет файлы ядра WordPress, чтобы перехватывать учётные данные.

Мониторинг целостности файлов (File Integrity Monitoring, FIM) — это система, которая отслеживает изменения в файлах ядра WordPress, плагинов и тем. Она делает «снимок» файловой системы — хеш каждого файла — и регулярно сравнивает текущее состояние с этим снимком. Если какой-то файл изменился, появился новый файл там, где его быть не должно, или исчез файл, который должен быть — администратор получает уведомление.

Я расскажу реальную историю. На одном из проектов мы обнаружили, что кто-то изменил файл wp-includes/version.php. Этот файл содержит номер версии WordPress и обычно не меняется между обновлениями. Изменение было незаметным: в конец файла была добавлена строка кода, которая при определённых условиях загружала и выполняла скрипт с внешнего сервера. Без мониторинга целостности это изменение можно было бы не заметить месяцами. С мониторингом — мы получили уведомление в течение часа.

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

Важный нюанс: при обновлении WordPress, плагинов или тем файлы, естественно, меняются. Хороший FIM должен уметь отличать легитимные изменения от подозрительных. Наш модуль знает, какие файлы входят в стандартную поставку WordPress определённой версии, и может сравнить ваши файлы с эталонными. Если файл wp-login.php на вашем сервере отличается от того, что поставляется в официальном релизе WordPress — это повод для тревоги.

И тут я хочу сделать философское отступление. Мониторинг целостности файлов — это не инструмент предотвращения. Это инструмент обнаружения. Он не остановит взлом, но он позволит узнать о нём быстро. А в кибербезопасности скорость обнаружения — это всё. По статистике, среднее время между взломом и его обнаружением составляет 197 дней для малого бизнеса. Почти семь месяцев злоумышленник может хозяйничать на вашем сайте, красть данные, использовать сервер для рассылки спама, подкладывать вредоносные ссылки — и вы даже не будете знать об этом. Мониторинг целостности сокращает это окно до часов.

Лог активности: полная картина происходящего

Лог активности — это функция, значение которой люди начинают понимать только после инцидента. Когда всё хорошо, лог кажется бесполезным шумом: «Пользователь admin вошёл в систему», «Пользователь manager изменил товар #15748», «Пользователь admin обновил настройки плагина». Скучно, неинтересно, зачем это хранить? А потом происходит инцидент, и первый вопрос: «Кто это сделал? Когда? Что именно изменил?» И без лога активности ответить на эти вопросы невозможно.

Наш модуль ActivityLog записывает все значимые действия в административной панели WordPress и WooCommerce. Входы и выходы пользователей (с IP-адресами и user-agent). Создание, редактирование и удаление контента — постов, страниц, товаров, заказов. Изменение настроек — любых настроек, включая настройки плагинов. Установка, активация и деактивация плагинов и тем. Действия с пользователями — создание, удаление, изменение ролей. Работа с медиафайлами. И ещё десятки типов событий.

Я использую логи активности не только для расследования инцидентов, но и для повседневного управления. Когда в команде работают три-четыре человека с доступом к админке магазина, лог — это ваш инструмент контроля. Кто изменил цену на этот товар? Кто удалил ту категорию? Кто установил непонятный плагин? Без лога — обвинения, непонимание, конфликты. С логом — факты, даты, время. Ничего личного, просто данные.

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

Логи хранятся в отдельной таблице базы данных с контекстами, что позволяет фильтровать по пользователю, по типу действия, по дате. Можно настроить автоматическую очистку старых записей — например, хранить логи за последние 90 дней. Для большинства магазинов этого достаточно. Если нужна долгосрочная архивация — можно экспортировать в CSV.

Особенно ценной я считаю связку лога активности с другими модулями безопасности. Когда WAF блокирует запрос — это попадает в лог. Когда LoginProtection блокирует IP — это попадает в лог. Когда FIM обнаруживает изменение файла — это попадает в лог. В итоге у вас есть единая хронология всех событий безопасности, которую можно просмотреть в одном интерфейсе. Не нужно переключаться между десятью экранами разных плагинов — всё в одном месте.

Почему мы не используем Wordfence и почему, возможно, не стоит и вам

И вот тут начинается самое интересное — сравнение с тем, что уже есть на рынке. Wordfence — самый популярный плагин безопасности для WordPress, более 4 миллионов активных установок. Он хороший, серьёзный, заслуженный. Я сам использовал его несколько лет на разных проектах. И у меня накопился список претензий, которые в итоге привели к решению разработать собственный модуль.

Первая и главная проблема — размер и производительность. Wordfence — это монстр. Бесплатная версия занимает около 30 MB дискового пространства, Premium — ещё больше. Но размер на диске — полбеды. Wordfence запускает свой собственный файрвол на каждом запросе к сайту, проводит сканирование базы данных, проверяет файлы, обращается к внешнему API для обновления сигнатур. На shared-хостинге это может увеличить время загрузки страницы на 200-300 миллисекунд. На нагруженном WooCommerce-магазине с тысячами товаров и активным трафиком — это ощутимо.

Наш модуль безопасности — это часть COS WP Woo, которая весит... ну, он часть плагина, не отдельная сущность. Он не тащит за собой свой собственный файрвол на уровне PHP, который перехватывает каждый запрос через auto_prepend_file. Он работает через стандартные хуки WordPress, что означает лучшую совместимость и предсказуемость.

Вторая проблема — конфликты с кешированием. Я сталкивался с этим на каждом втором проекте с Wordfence. LiteSpeed Cache, WP Super Cache, W3 Total Cache — Wordfence с ними конфликтует с завидной регулярностью. То он не может сканировать файлы, потому что кеш отдаёт страницу раньше, чем Wordfence успевает её проверить. То его файрвол блокирует запросы от кеш-плагина. То live traffic monitoring начинает показывать кешированные запросы как «подозрительные». На одном проекте с LiteSpeed мы потратили два рабочих дня на то, чтобы заставить Wordfence и LiteSpeed Cache работать вместе без конфликтов. Два дня работы разработчика — это реальные деньги.

Третья проблема — цена. Wordfence Premium стоит 119 долларов в год за один сайт. Если у вас пять магазинов — 595 долларов в год. За десять лет — шесть тысяч долларов только на безопасность. И это при том, что бесплатная версия имеет существенные ограничения: сигнатуры файрвола обновляются с задержкой в 30 дней (тридцать дней, Карл! — за это время уязвимость успеет стать достоянием каждого script kiddie), нет real-time IP blacklist, ограниченное сканирование. То есть бесплатная версия — это, по сути, маркетинговый инструмент для продажи Premium.

У нашего модуля безопасности нет разделения на бесплатную и платную версии. Все функции — WAF, 2FA, геоблокировка, FIM, лог активности, CAPTCHA, IP-менеджмент, кастомный URL, блокировка XML-RPC, защита от брутфорса — доступны в составе COS WP Woo. Один плагин, одна лицензия, полный набор инструментов. Вы не платите отдельно за безопасность, отдельно за B2B, отдельно за поиск, отдельно за интеграцию с 1С. Всё вместе.

Четвёртая проблема — интеграция. Wordfence — изолированный плагин. Он ничего не знает о вашем B2B-модуле, о вашем поиске, о вашей CRM. Наш модуль безопасности — часть единой экосистемы. Он знает о B2B-пользователях и может применять разные политики безопасности для разных групп клиентов. Он интегрирован с модулем email-уведомлений. Он использует общую систему настроек и общий административный интерфейс. Это не лоскутное одеяло из десяти разных плагинов от десяти разных разработчиков — это единая система, где все компоненты спроектированы для работы вместе.

Я не хочу сказать, что Wordfence — плохой продукт. Для обычного WordPress-блога, где нет WooCommerce и не критична производительность, Wordfence Premium — отличный выбор. Но для WooCommerce-магазина с тысячами товаров, B2B-функционалом, интеграцией с 1С и требованиями к производительности — встроенный модуль безопасности работает лучше, потому что он спроектирован для этого контекста.

Комплексный подход: как все элементы работают вместе

Я специально не описывал каждый компонент модуля безопасности как изолированную функцию — потому что они и не работают изолированно. Вся идея в том, что каждый компонент усиливает остальные. Давайте пройдём по типичному сценарию атаки и посмотрим, как система реагирует на каждом этапе.

Бот из Вьетнама пытается обратиться к сайту. Геоблокировка проверяет IP — Вьетнам не в списке разрешённых стран. Запрос заблокирован. Инцидент записан в лог активности. Готово, история закончилась, даже до WAF дело не дошло.

Другой бот, из разрешённой страны, пытается обратиться к /wp-login.php. Модуль LoginUrl перехватывает запрос — URL не совпадает с кастомным. Возвращается 404. Бот думает, что на сайте нет WordPress. Идёт дальше.

Третий бот, более продвинутый, каким-то образом узнал реальный URL входа. Пытается подобрать пароль. После пятой попытки LoginProtection блокирует IP. Запись в лог, уведомление администратору. IP автоматически попадает в чёрный список через IpManagement.

Четвёртый сценарий — атакующий не пытается войти, а пробует SQL-инъекцию через параметр поиска. WAF распознаёт паттерн, блокирует запрос, записывает в лог. IP отправляется на карантин.

Пятый сценарий — злоумышленник нашёл уязвимость в стороннем плагине (не в нашем) и сумел загрузить PHP-шелл в директорию uploads. FIM обнаруживает новый PHP-файл там, где должны быть только изображения. Администратор получает уведомление, удаляет файл, обновляет уязвимый плагин.

Шестой сценарий — бот пытается атаковать через xmlrpc.php. Запрос заблокирован на уровне модуля XmlRpc. Даже не обрабатывается.

Видите паттерн? На каждом уровне стоит свой фильтр. Чтобы добраться до ваших данных, атакующий должен пройти все уровни. Каждый уровень независим и самодостаточен, но вместе они создают систему, которую чрезвычайно трудно обойти. Это не один замок, который можно взломать — это десять замков, и каждый следующий сложнее предыдущего.

Я часто слышу вопрос: «А не замедлит ли всё это мой сайт?» Справедливый вопрос. Ответ: нет, если реализовано правильно. Геоблокировка — это одна проверка IP по базе в памяти, микросекунды. Проверка URL логина — сравнение строк, наносекунды. WAF — набор regex-проверок на входящий запрос, пара миллисекунд. CAPTCHA — клиентская проверка, вообще не нагружает сервер. FIM работает по расписанию, в фоне. Лог активности — одна вставка в базу при событии. Суммарная нагрузка на обработку одного запроса — порядка 5-10 миллисекунд. Это в разы меньше, чем Wordfence с его полным сканированием каждого запроса.

Есть ещё один момент, о котором я хочу сказать отдельно, потому что его часто упускают из виду. Безопасность — это не разовая настройка, это процесс. Вы можете сегодня идеально сконфигурировать все модули, но через три месяца появится новый вектор атаки, новая уязвимость в WordPress или в одном из ваших плагинов, новая техника обхода CAPTCHA. Именно поэтому наш модуль обновляется вместе с плагином — правила WAF пополняются, базы GeoIP обновляются, алгоритмы обнаружения совершенствуются. Вам не нужно следить за этим — обновления приходят автоматически. Это принципиальное отличие от подхода «поставил и забыл», который заканчивается тем, что через полгода ваша «защита» работает по правилам полугодовой давности, а атакующие уже используют методы, о которых ваш плагин ещё не знает.

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

Наш подход — не продавать безопасность как отдельный дорогой продукт, а сделать её неотъемлемой частью инструмента, которым вы и так пользуетесь для управления магазином. Не нужно устанавливать отдельный плагин, не нужно покупать отдельную лицензию, не нужно разбираться в интерфейсе ещё одного продукта. Открыли настройки COS WP Woo, перешли в раздел Security, включили нужные модули — и ваш магазин защищён. WAF работает, 2FA настроена, геоблокировка фильтрует мусорный трафик, мониторинг следит за файлами, лог записывает каждое действие. Не один инструмент, а десять — и все работают слаженно, как части одного механизма.

А что если посмотреть на это с точки зрения бизнеса? Стоимость одного инцидента безопасности для среднего интернет-магазина — от 200 000 до 2 000 000 рублей, если считать прямые убытки (восстановление, аудит, юристы) и косвенные (потеря клиентов, репутационный ущерб, простой бизнеса). Стоимость предотвращения — ноль дополнительных рублей, если у вас уже стоит COS WP Woo. Я не знаю более выгодной инвестиции в бизнесе. Математика простая: потратить полчаса на настройку сейчас или потратить недели на восстановление потом. Мне кажется, выбор очевиден. И тот клиент, который позвонил мне с фразой «нас взломали», сейчас бы с этим согласился.

Попробуйте COS WP Woo бесплатно — установите плагин и получите 14 дней полного доступа ко всем модулям, включая Security. WAF, двухфакторная аутентификация, геоблокировка, мониторинг файлов, лог активности — всё это начнёт защищать ваш магазин с первой минуты. Без ограничений, без скрытых платежей, без необходимости покупать пять разных плагинов. Один инструмент — полная защита.