«Я думала, что “защитить сайт от DDoS и брутфорса” — это дорого и только для больших проектов, а потом за вечер настроила базовую защиту на Timeweb и перестала бояться ночных атак: рассказываю, как закрыла слабые места WordPress‑сайта»

У меня был сайт онлайн‑школы: WordPress, курсы, личный кабинет, формы регистрации, интеграция с платёжной системой. Клиент сказал: «В прошлом месяце ночью кто‑то пытался подобрать пароли к админке, а ещё сайт пару раз “зависал”. Поставь защиту, но так, чтобы не сломать формы и не заблокировать реальных пользователей». Я кивнула, а внутри всё сжалось: «А вдруг я включу защиту, и ученики не смогут войти в личный кабинет? Или поставлю плагин, который будет конфликтовать с платёжкой? Или защита окажется бесполезной, а я скажу клиенту, что всё ок?»

До этого я вообще не думала про безопасность: сайт работал, формы отправлялись, и казалось, что «если нет проблем — значит, всё хорошо». Но когда в логах я увидела сотни запросов к /wp-login.php с разных IP за одну минуту, стало не по себе. Тогда я поняла: даже небольшому проекту нужна базовая защита, и её можно сделать без сложных серверов и дорогих решений — через панель хостинга и точечные настройки.

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

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

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

С этим списком я пошла в панель Timeweb и в админку WordPress, чтобы действовать по шагам и с бэкапом.

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

Первое, что я сделала, — ручной бэкап в панели Timeweb. Нажала одну кнопку, подождала пару минут, убедилась, что статус «Готов». Если защита что‑то сломает, я смогу откатиться за 5 минут.

Плюс в файловом менеджере я скачала свежие логи доступа (access.log) и ошибок (error.log). Это нужно, чтобы потом сравнить: если после включения защиты нагрузка резко вырастет или появятся странные ошибки, я пойму, связано ли это с новыми настройками.

Шаг 2: закрыть самые очевидные уязвимости WordPress

Я начала с простых и безопасных действий, которые не требуют сложной настройки:

Скрыла путь к админке. Вместо стандартного /wp-admin/ и /wp-login.php поставила плагин, который меняет адрес входа (например, /secure-login/). Это сразу отсекает 90 % автоматических скриптов, которые просто перебирают стандартные пути.
Ограничила попытки входа. Настроила правило: после 3 неудачных попыток IP блокируется на 15 минут. Важно: это правило не применяется к моим IP и к IP техподдержки школы, чтобы мы могли спокойно работать.
Убрала версию WordPress из кода. В теме или через плагин отключила вывод generator в <head>. Это не защита сама по себе, но усложняет жизнь тем, кто ищет сайты на старых версиях.

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

Шаг 3: включить защиту на уровне хостинга в панели Timeweb

В панели хостинга я нашла встроенные инструменты защиты и включила их:

Защита от DDoS‑атак. Это уровень сети: хостер фильтрует заведомо вредоносный трафик ещё до того, как он попадёт на сервер. Включила опцию в карточке сайта — это не требует настройки правил и не ломает формы.
Файрвол/фильтрация по IP. Там можно блокировать диапазоны IP, которые уже известны как источники атак. Я не стала делать это вручную, но оставила опцию включённой: панель сама обновляет списки подозрительных IP.
Лимиты запросов (rate limiting). Настроила ограничение на количество запросов с одного IP за минуту. Важно: я выбрала щадящие значения, чтобы обычные пользователи могли спокойно листать страницы и заполнять формы, а боты — нет.

Поддержка подсказала: «Сначала включите сетевую защиту и лимиты, а правила по URL настраивайте точечно, если увидите конкретную атаку».

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

Для форм регистрации и входа я сделала:

Капча или hCaptcha. Добавила простую проверку «я не робот» на формы входа и регистрации. Это сильно режет автоматические попытки подбора паролей.
Двухфакторную аутентификацию для админов. Для себя и менеджеров школы я включила 2FA: вход по паролю + код из приложения. Даже если кто‑то подберёт пароль, без кода войти не получится.
Отключение XML‑RPC. В WordPress этот протокол часто используют для массовых атак. Если он не нужен для интеграции (например, с мобильным приложением), его лучше отключить. Я проверила: у нас XML‑RPC не использовался, поэтому выключила его через плагин.

Это не замедляет работу сайта, но закрывает популярные векторы атак.

Шаг 5: настроить мониторинг и оповещения

Чтобы не узнавать об атаке утром, я сделала простой контроль:

Слежу за нагрузкой в панели Timeweb. Там видно CPU, память, количество запросов в секунду. Если график резко скачет ночью — это повод проверить логи.
Настроила оповещения. В панели можно получать уведомления, если нагрузка или количество ошибок резко растёт. Я выбрала email и короткий Telegram‑бот: так я сразу вижу, если что‑то не так.
Регулярно проверяю логи. Раз в неделю просматриваю access.log и error.log: ищу повторяющиеся IP, массовые запросы к /xmlrpc.php, /wp-login.php, странные коды ошибок.

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

Шаг 6: проверить, что защита не ломает работу сайта

После включения всех правил я провела тесты:

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

Только после этого я сказала клиенту: «Базовая защита включена, реальные пользователи не пострадают, а автоматические атаки будут блокироваться».

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

Хотела заблокировать все неизвестные IP. Думала: «Чем строже, тем безопаснее». Поддержка объяснила: так можно случайно закрыть доступ ученикам из новых сетей. Лучше использовать лимиты и фильтрацию по поведению, а не сплошной блок.
Пыталась вручную писать сложные правила в .htaccess. Это легко сломать: одно неверное условие — и сайт отдаёт 500‑ю ошибку. Панель и здравый смысл подсказали: сначала используйте встроенные инструменты, а .htaccess — только для точечных исключений.
Забыла добавить свои IP в исключения. Хорошо, что перед включением лимитов я составила список IP для себя и техподдержки. Иначе могла сама себя заблокировать.
Не проверяла работу платёжной формы. Думала: «Защита на уровне сети не трогает POST‑запросы». Но лучше убедиться: я сделала тестовую покупку и убедилась, что платёж проходит.
Не настроила оповещения. Думала: «Если сайт упадёт, клиент напишет». Но ночью клиент может не заметить проблему. Оповещения в панели решают эту проблему.

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

Встроенная защита от DDoS. Работает на уровне сети, не требует сложной настройки и не ломает сайт.
Панель с метриками нагрузки. Видно CPU, память и количество запросов — это помогает вовремя заметить атаку.
Оповещения о росте нагрузки и ошибок. Я получаю сигнал, если что‑то идёт не так, и могу быстро среагировать.
Файловый менеджер и доступ к логам. Можно быстро скачать и посмотреть access.log/error.log, чтобы понять, откуда идёт атака.
Бэкапы в один клик. Если защита или правила сломают сайт, откатиться можно за минуты.
Поддержка. Когда сомневалась, можно ли включать лимиты запросов, в чате быстро подсказали безопасные значения и исключения для своих IP.

Практические советы, чтобы защитить небольшой WordPress‑проект без боли

Если вы тоже хотите добавить базовую защиту, вот что реально работает:

Всегда делайте бэкап перед любыми настройками. На Timeweb это пара кликов, а откатиться можно за минуты.
Начните с закрытия очевидных точек входа: скрытая админка, ограничение попыток входа, отключение XML‑RPC.
Используйте встроенную защиту хостинга. Сетевой DDoS‑фильтр и лимиты запросов — это уже сильный уровень безопасности.
Добавляйте капчу на формы входа и регистрации. Это дёшево и эффективно против автоматических атак.
Включайте 2FA для всех админов. Даже если пароль утечёт, аккаунт останется под защитой.
Не блокируйте все внешние IP. Лучше ограничивать частоту запросов и блокировать по подозрительному поведению.
Настройте оповещения и следите за метриками. Так вы узнаете об атаке сразу, а не утром.
Регулярно проверяйте логи. Повторяющиеся IP и массовые запросы к /wp-login.php или /xmlrpc.php — это сигнал, что нужна дополнительная защита.

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