Как защитить сайт от взлома

Защита сайта от взлома

Большинство взломов сайтов автоматизированы: боты сканируют миллионы доменов в поисках известных уязвимостей в конкретных версиях CMS и плагинов, а не атакуют вас лично. Закрыть типовые дыры до того, как их найдёт сканер, дешевле, чем восстанавливать сайт после заражения.

Как злоумышленники получают первоначальный доступ

Почти никогда взлом не начинается с подбора пароля администратора напрямую — это слишком медленно при включённой блокировке попыток входа. Реальные векторы чаще другие: украденные учётные данные FTP из заражённого компьютера разработчика, известная уязвимость в конкретной версии плагина, которую не обновили вовремя, или фишинговое письмо, из-за которого пароль от панели управления попал не в те руки. Защита от каждого из этих векторов разная, поэтому одной меры недостаточно — нужен набор барьеров.

Основные правила

• Используйте сложные пароли для cPanel, FTP и базы данных
• Регулярно обновляйте CMS, темы и плагины
• Удаляйте неиспользуемые плагины и темы
• Включите двухфакторную аутентификацию в биллинге

Как выглядит атака в логах сервера

Прежде чем что-то менять на сайте, боты сканируют его на типовые точки входа. В логе access.log это выглядит как серия запросов на файлы, которых у вас может даже не быть:

1.2.3.4 - - [30/Sep/2026:03:14:11] "GET /wp-config.php.bak HTTP/1.1" 404
1.2.3.4 - - [30/Sep/2026:03:14:12] "GET /.env HTTP/1.1" 404
1.2.3.4 - - [30/Sep/2026:03:14:13] "GET /xmlrpc.php HTTP/1.1" 200
1.2.3.4 - - [30/Sep/2026:03:14:14] "POST /wp-login.php HTTP/1.1" 200

Код 404 на первых двух строках — это нормально, файлы защищены отсутствием. А вот 200 на xmlrpc.php и wp-login.php означает, что эти точки входа доступны и по ним можно перебирать пароли — именно их нужно закрывать в первую очередь.

Защита WordPress

• Установите плагин Wordfence или Sucuri
• Смените стандартный URL входа /wp-admin
• Ограничьте количество попыток входа
• Отключите XML-RPC если не используете

Wordfence и Sucuri: чем отличаются

Wordfence работает внутри самого WordPress и не остановит атаку до того, как запрос дойдёт до PHP; полноценный WAF перед сервером, например ModSecurity или Cloudflare, фильтрует трафик раньше.

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

Защита файлов

# Запретить доступ к .htaccess
<Files .htaccess>
    Order allow,deny
    Deny from all
</Files>

Если подозреваете, что сайт уже заражён, первый практический шаг — найти файлы, изменённые за последние дни, когда обычно никто не вносил правки в код:

# Файлы, изменённые за последние 7 дней
find /var/www/site -type f -mtime -7 -name "*.php"

# Подозрительные конструкции в PHP-файлах (не приговор, но повод проверить руками)
grep -rl "eval(base64_decode" /var/www/site --include="*.php"

Совпадение по eval(base64_decode не всегда означает заражение — некоторые легитимные библиотеки используют похожие конструкции для лицензионных проверок, но в подавляющем большинстве случаев на реальном сайте это признак веб-шелла, оставленного после взлома.

Когда одних плагинов недостаточно

• Уязвимость нулевого дня в самой CMS — плагин безопасности обнаружит подозрительную активность постфактум, но не закроет дыру, для которой ещё нет сигнатуры.
• Скомпрометированный пароль администратора — двухфакторная аутентификация и сложные пароли важнее любого сканера файлов.
• Уязвимый код в самописной части сайта — антивирусные плагины ищут известные сигнатуры вредоносного кода, а не логические ошибки в вашем собственном PHP.

Проверка, что защита работает

1. Запросите curl -I https://ваш-домен/wp-config.php.bak — должен вернуться 404, а не 200.
2. Проверьте, что /wp-admin действительно перенаправляет на новый адрес входа, а не отвечает старой формой.
3. Попробуйте 5–6 раз ввести неверный пароль подряд — должна сработать блокировка по IP или задержка перед следующей попыткой.
4. Запросите curl -I https://ваш-домен/xmlrpc.php — если XML-RPC отключён, ответ должен быть 403 или 404, а не 200.

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