«Я не знала, как “защитить сайт от спама и брутфорса”, а потом получила 12 000 запросов за ночь: рассказываю, как закрыла слабые места и перестала терять время на чистку комментариев»

У меня был блог о здоровом питании: WordPress, 120 статей, комментарии под постами, форма подписки, личный кабинет для премиум‑пользователей, интеграция с рассылкой и CRM. Клиент сказал: «В комментариях сплошной спам, в админке кто‑то постоянно пытается подобрать пароль, а форма подписки заваливает меня фейковыми заявками. Сделай так, чтобы реальный пользователь спокойно оставлял комментарий или подписывался, а боты не проходили». Я кивнула, а внутри всё сжалось: «А если поставлю жёсткие фильтры — реальные подписчики не смогут подписаться? Если включу капчу везде — это отпугнёт людей? А если не сделаю ничего — завтра сайт улетит в спам‑фильтры почтовых сервисов из‑за фейковых email, а админку взломают?»

До этого я либо вообще не трогала защиту (думала: «Это не моя зона ответственности»), либо ставила «всё подряд»: капчу на каждую форму, блокировку по IP без анализа, отключала комментарии целиком. В одном проекте так и случилось: после агрессивной защиты форма подписки перестала работать у части пользователей на мобильных, а клиент получил шквал жалоб: «Не могу подписаться». Тогда я поняла: защита — это не «заблокировать всех», а точечные фильтры, понятные пользователю и незаметные для него, плюс постоянный контроль логов. Панель Timeweb с графиками нагрузки, логами и phpMyAdmin дала мне способ видеть атаки и реагировать, не ломая конверсии.

Чего я боялась больше всего

Перед тем как настраивать защиту, я честно выписала свои главные страхи:

Потерять реальных подписчиков. Что капча или фильтры будут слишком сложными, и люди просто уйдут, не подписавшись.
Сломать формы и комментарии. Что защита начнёт конфликтовать с плагинами форм, и заявки перестанут уходить в CRM.
Заблокировать реальных пользователей по IP. Что начну массово блокировать IP из‑за всплеска запросов, а вместе с ботами отрежу реальных посетителей.
Не заметить атаку вовремя. Что брутфорс на админку будет идти неделями, а я увижу это только по логам, когда уже поздно.
Ухудшить скорость и UX. Что тяжёлые плагины защиты будут тормозить сайт, а капча будет раздражать пользователей.

С этим списком я пошла в панель Timeweb и составила план: бэкап → аудит уязвимостей → точечная защита форм и админки → контроль логов → проверка конверсий.

Шаг 1: сделать бэкап и подготовить тестовую площадку

В панели Timeweb я:

Нажала «Создать резервную копию» для файлов и базы. Статус «Готов» — теперь я могла откатиться за 10–15 минут.
Создала поддомен test-food.site.ru и развернула туда копию сайта.
Настроила в wp-config.php новый домен и проверила, что формы подписки и комментарии работают.
Зафиксировала текущие метрики: количество подписок в сутки, процент ошибок отправки форм, среднюю нагрузку CPU.

Это была моя «песочница»: любые настройки защиты я сначала проверяла здесь, чтобы не потерять реальных подписчиков.

Шаг 2: провести аудит уязвимостей и понять, откуда идёт нагрузка

Я посмотрела, где именно сайт «теряет» ресурсы и где больше всего спама:

Комментарии. В админке WordPress я открыла список комментариев: 80 % — спам с ссылками на сомнительные сайты.
Форма подписки. В CRM я увидела, что часть email явно фейковые (одноразовые домены, опечатки).
Админка. В логах сервера (access.log) я заметила сотни попыток входа на /wp-login.php с разных IP, подбор паролей по словарю.
XML‑RPC. В error.log были частые запросы к /xmlrpc.php — это классический вектор атак.
Нагрузка. На графиках панели Timeweb было видно, что ночью CPU подскакивает из‑за массовых запросов, хотя трафика почти нет.

Так я поняла, что защита нужна точечно: комментарии, формы, админка и XML‑RPC.

Шаг 3: настроить защиту форм и комментариев без потери конверсий

Я действовала по такой схеме:

Защита форм подписки:

Honeypot‑поле. Добавила в форму скрытое поле, которое видно только ботам. Если оно заполнено — заявка отклоняется. Это почти не влияет на UX, но режет 70–80 % спама.
Проверка email. На стороне сервера я добавила простую валидацию домена и проверку на одноразовые почты. Это не блокирует пользователя, но сразу помечает подозрительные заявки.
Лимиты на отправку. Один email не может отправить больше 3 заявок за час. Это останавливает массовые рассылки.

Защита комментариев:

Капча только для новых пользователей. Для зарегистрированных пользователей капчу отключила: они и так проходят модерацию реже.
Автоматическая модерация по ключевым словам. Все комментарии со ссылками или стоп‑словами сразу уходят в «На проверку», а не публикуются.
Ограничение длины и частоты. Один IP не может оставить больше 5 комментариев в час.

Отключение XML‑RPC (если не используется):
В одном из проектов клиент не использовал Pingback и сторонние редакторы, поэтому я отключила XML‑RPC через плагин. Это сразу снизило количество атак и нагрузку на сервер. Если XML‑RPC нужен (например, для мобильного редактора), вместо полного отключения можно использовать плагины, которые блокируют только подозрительные запросы.

Шаг 4: защитить админку от брутфорса и подбора паролей

Я закрыла самые частые векторы атак:

Ограничение попыток входа. Плагин защиты админки блокировал IP после 5 неудачных попыток входа.
Переименование URL входа. Я изменила адрес страницы входа (например, с /wp-login.php на нестандартный). Это не даёт ботам быстро найти админку.
Двухфакторная аутентификация для всех админов. Даже если пароль подберут, без второго фактора вход невозможен.
Сильные пароли и ролевая модель. Я проверила, что у всех пользователей сложные пароли, а лишние аккаунты удалены. Роли были строго разграничены: редакторы не могут ставить плагины, авторы — не видят настройки.

Важно: все эти настройки я сначала тестировала на тестовой версии, проверяя, что реальный администратор может войти, а обычный пользователь — спокойно подписаться.

Шаг 5: настроить мониторинг и контроль логов

Даже с защитой я держала руку на пульсе:

Графики нагрузки в панели Timeweb. Если CPU ночью снова растёт — это сигнал, что идёт атака.
Access.log и error.log. В панели хостинга я смотрела всплески запросов к /wp-login.php, /xmlrpc.php, странные User‑Agent.
Отчёты по спаму. Раз в неделю я проверяла, сколько заявок отклонил honeypot и сколько комментариев ушло в модерацию.
Логи безопасности. Если плагин защиты фиксировал блокировки IP, я смотрела, не попадают ли туда реальные пользователи.

Только когда все сценарии работали стабильно, я переносила настройки на основной сайт.

Шаг 6: проверить конверсии и убедиться, что защита не мешает людям

На тестовой версии я прошла по чек‑листу:

Форма подписки. Заполнила с мобильного и десктопа, убедилась, что заявка уходит в CRM и нет ошибок.
Комментарии. Оставила комментарий как новый пользователь — появился запрос капчи, после прохождения комментарий ушёл на модерацию.
Личный кабинет. Проверила, что вход работает, двухфакторная аутентификация не блокирует реального пользователя.
Консоль браузера (F12 → Console). Не должно быть ошибок JS, связанных с капчей или формами.
Скорость страницы. Проверила PageSpeed Insights: капча и honeypot не должны сильно замедлять форму.

После этого я перенесла настройки на основной сайт и ещё неделю следила за метриками.

Где я чуть не ошиблась (и что панель подсказала)

Хотела заблокировать все подозрительные IP по списку. Думала: «Так быстрее». Поддержка подсказала: «Сначала посмотрите, кто именно атакует и не попадают ли в список реальные пользователи. Лучше точечные лимиты и honeypot».
Пыталась включить капчу на все формы сразу. Думала: «Чем больше защиты, тем лучше». Но на мобильных капча раздражала, и конверсия падала. Панель и практика подсказали: использовать honeypot + лимиты, а капчу — только для новых пользователей.
Игнорировала XML‑RPC. Думала: «Это стандартная функция, трогать не надо». Но именно через него шли массовые атаки. Панель с логами помогла быстро увидеть проблему.
Не проверяла форму подписки после настройки лимитов. Думала: «Лимиты нужны только против ботов». Но если пользователь случайно отправил форму дважды, второй раз она отклонялась. Пришлось добавить понятное сообщение об ошибке.
Не следила за нагрузкой после включения защиты. Думала: «Плагин лёгкий, не влияет». Но некоторые плагины сильно нагружают CPU. Панель с графиками помогла вовремя заметить и заменить плагин на более лёгкий.

Что реально помогло на Timeweb

Бэкапы в один клик. Я могла откатиться за минуты, если защита ломала формы или комментарии.
Поддомены для тестов. Развернула копию сайта и проверяла защиту без риска для конверсий.
Графики нагрузки (CPU, запросы). Сразу видно, даёт ли защита реальный эффект и не растёт ли нагрузка из‑за тяжёлых плагинов.
Логи (error.log, access.log). В них видно, какие запросы атакуют сайт, сколько блокировок происходит и не попадают ли под них реальные пользователи.
phpMyAdmin и файловый менеджер. Если нужно было поправить конфиги, проверить, не сломались ли интеграции после установки плагина защиты.
Поддержка. Когда сомневалась, какой плагин выбрать или как правильно настроить лимиты, в чате быстро подсказывали безопасный вариант.

Практические советы, чтобы защитить сайт от спама и брутфорса без потери конверсий

Если вы тоже настраиваете защиту:

Всегда делайте бэкап перед любыми действиями. На Timeweb это пара кликов, а откатиться можно за минуты.
Сначала тестируйте на копии сайта. Любые настройки защиты — только на тестовой версии.
Используйте honeypot вместо тотальной капчи. Это режет большую часть спама и почти не влияет на UX.
Ставьте лимиты на отправку форм и комментариев. Один IP или email не должен делать много действий подряд.
Защищайте админку: лимиты попыток входа, переименование URL, двухфакторная аутентификация.
Отключайте или защищайте XML‑RPC, если он не нужен для работы.
Проверяйте, что реальные пользователи могут спокойно подписаться и оставить комментарий. Тестируйте на мобильных и разных браузерах.
Контролируйте логи и метрики. Если нагрузка растёт или появляются ошибки — сразу разбирайтесь.
Держите реестр исключений. Какие IP или пользователи не должны попадать под лимиты (сотрудники, партнёры).
Регулярно пересматривайте настройки. После установки новых плагинов защита может начать конфликтовать — лучше проверять раз в месяц.

Сейчас я спокойно настраиваю защиту: знаю, что у меня есть бэкап, тестовая площадка, понятные инструменты контроля и чёткий план, чтобы не потерять подписчиков. А клиент получает чистый сайт без спама: комментарии модерируются автоматически, формы принимают только реальные заявки, админка надёжно закрыта, а конверсии не падают. И всё это благодаря тому, что я перестала надеяться на «одну волшебную галочку» и начала действовать системно. А Timeweb даёт для этого все нужные инструменты: бэкапы, поддомены, графики, логи, phpMyAdmin и поддержку, которая помогает не сломать конверсии в погоне за безопасностью.