Как защитить wp-config.php и другие важные файлы WordPress

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

Сразу оговорюсь: эти меры помогают снизить риск и ограничить ущерб, но не лечат уже заражённый сайт. Если вы уже видите подозрительные редиректы, неизвестных администраторов, изменённые файлы или странные задания в cron, сначала нужно изолировать инцидент, а потом заниматься укреплением файловой системы.

Какие файлы на WordPress действительно нужно беречь

На практике в первую очередь защищают не «все файлы подряд», а несколько точек, через которые атакующий может быстро получить контроль над сайтом или скрыть вмешательство:

• wp-config.php — содержит данные для подключения к базе, соли авторизации и часть служебных настроек;
• .htaccess на Apache или nginx-конфигурация на уровне сервера — через них можно менять правила доступа, редиректы и обработку запросов;
• .user.ini или php.ini в зависимости от хостинга — иногда через них меняют параметры PHP, включая загрузку вредоносных файлов или поведение интерпретатора;
• файлы темы и плагинов — особенно если сайт допускает запись в каталог wp-content;
• wp-cron.php и другие системные файлы ядра — их обычно не трогают вручную, но проверяют на подмену, если есть признаки взлома;
• файлы резервных копий, если они лежат рядом с сайтом и доступны из веба.

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

Что даёт защита wp-config.php на самом деле

wp-config.php обычно лежит в корне сайта или на уровень выше корня, если хостинг и структура проекта это позволяют. Такой перенос полезен, потому что файл становится менее доступным через веб, но это не универсальная защита: если атакующий уже получил права на запись в файловой системе, он всё равно сможет изменить файл.

Смысл защиты здесь в другом:

• ограничить прямой доступ из браузера;
• сделать так, чтобы случайная уязвимость в другом месте не позволила легко прочитать конфигурацию;
• уменьшить последствия, если злоумышленник получил доступ только к части каталога сайта.

Но важно понимать границу. Если на сервере есть уязвимый плагин с возможностью записи файлов, если скомпрометирован FTP/SFTP-аккаунт или если у атакующего уже есть shell-доступ, перенос wp-config.php сам по себе не спасёт. Это именно слой защиты, а не финальная линия обороны.

Права доступа: что ставить и почему

Самая частая ошибка — выставить слишком широкие права «чтобы точно работало». Для WordPress это обычно излишне. На большинстве хостингов безопаснее придерживаться принципа минимально необходимых прав:

• каталоги — 755;
• файлы — 644;
• wp-config.php — часто ставят 600 или 640, если владелец и группа настроены корректно;
• если сайт работает под отдельным пользователем, а не под общим аккаунтом хостинга, можно ужесточить права точнее, но это уже зависит от схемы запуска PHP и настроек сервера.

Смысл прост: веб-серверу обычно достаточно читать файлы, а не переписывать их. Если дать запись там, где она не нужна, любой уязвимый компонент или ошибочный скрипт получит лишнюю свободу.

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

Как проверить права без лишней теории

Если есть SSH-доступ, достаточно посмотреть права на ключевые файлы и каталоги:

ls -la

Для wp-config.php отдельно:

ls -l wp-config.php

Если вы работаете через панель хостинга или FTP-клиент, ищите в свойствах файла поля вроде «Права доступа», «Permissions» или «CHMOD». Проверяйте не только сам wp-config.php, но и каталоги wp-content, uploads, plugins, themes. Именно туда часто пытаются записать вредоносные файлы.

Как убрать конфиденциальные данные из веб-доступа

Если хостинг позволяет, лучший вариант — хранить wp-config.php выше корня сайта. Тогда файл не лежит в публичной директории и не может быть прочитан через HTTP-запрос напрямую. Это особенно полезно для сайтов на общем хостинге, где вы не контролируете весь сервер, но можете управлять структурой каталога.

Ещё один практический шаг — не держать рядом с сайтом резервные копии конфигурации, дампы базы и архивы с именами вроде backup.zip или site.sql в открытом каталоге. Такие файлы часто находят не через сложный взлом, а через обычный перебор имён. Если бэкап нужен на сервере временно, храните его вне веб-корня или хотя бы закрывайте доступ на уровне сервера.

Для секретов WordPress это особенно важно:

• ключи и соли авторизации в wp-config.php;
• доступы к базе данных;
• ключи API сторонних сервисов, если вы по ошибке храните их в конфиге;
• служебные токены интеграций, которые не должны быть доступны посетителям и ботам.

Если конфиг уже утёк, одной смены пароля администратора мало. Нужно менять и данные доступа к базе, и соли авторизации, чтобы сбросить активные сессии пользователей.

Ограничение записи в каталоги WordPress

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

Обычно WordPress действительно пишет в:

• wp-content/uploads — загрузка медиа;
• иногда в wp-content/cache или другие каталоги кэша;
• временные каталоги плагинов для обновлений и распаковки архивов.

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

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

Защита .htaccess, .user.ini и других служебных файлов

Если сайт работает на Apache, файл .htaccess влияет на маршрутизацию, редиректы и доступ к каталогам. Его подмена часто используется для скрытых редиректов и подгрузки вредоносных правил. На Nginx аналогичные риски связаны уже с конфигурацией сервера, а не с файлом в корне сайта.

Для .htaccess полезны два подхода:

• ограничить права на запись, чтобы веб-процесс не мог менять файл без необходимости;
• проверять его содержимое после инцидента и после установки подозрительных плагинов.

Файл .user.ini встречается на хостингах с PHP-FPM и CGI. Через него иногда меняют параметры PHP, например время выполнения скриптов или поведение загрузки файлов. Это не «вредоносный» файл сам по себе, но если он появился неожиданно или содержит странные директивы, его нужно проверить.

Если вы не уверены, какие служебные файлы используются на вашем хостинге, лучше уточнить это у поддержки. На одном сервере защита строится через .htaccess, на другом — через конфигурацию Nginx и отдельные правила для PHP. Универсального рецепта здесь нет.

Что делать, если сайт уже подозрительно себя ведёт

Когда есть признаки взлома, порядок действий важнее, чем отдельная настройка прав. Сначала нужно ограничить ущерб, а уже потом усиливать защиту.

1. Сделайте копию текущего состояния сайта и базы данных для анализа. Не перезаписывайте её «чистой» версией до проверки.
2. Смените пароли администраторов WordPress, FTP/SFTP, панели хостинга и базы данных.
3. Проверьте список пользователей WordPress, особенно администраторов.
4. Сравните wp-config.php, .htaccess и файлы темы с эталонной версией.
5. Проверьте каталог wp-content/uploads на PHP-файлы, которых там быть не должно.
6. Обновите ядро, плагины и темы только после того, как поймёте источник проблемы и убедитесь, что у вас есть резервная копия.

Если вы просто закроете доступ к файлам, не удалив вредоносный код и не сменив все доступы, атакующий может вернуться через уже созданную учётную запись, бэкдор в плагине или подменённый cron-задачу.

Когда одной защиты файлов недостаточно

Защита wp-config.php и служебных файлов особенно важна для:

• магазинов и сайтов с оплатой;
• проектов с несколькими редакторами и подрядчиками;
• сайтов на общем хостинге;
• проектов, где часто ставят плагины и темы от разных разработчиков;
• сайтов, где в конфиге хранятся чувствительные интеграции и API-ключи.

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

Если вы хотите уменьшить количество лишних служебных возможностей WordPress и убрать часть ненужной поверхности атаки, можно посмотреть в сторону Clearfy Pro: https://wpshop.ru/plugins/clearfy. Но такой инструмент не заменяет права доступа, настройку сервера и контроль файловой системы — он помогает только в тех задачах, где действительно нужен.

Минимальный практический набор, с которого стоит начать

Если нужен короткий и рабочий план без лишней теории, я бы начал так:

• перенести wp-config.php выше корня сайта, если это поддерживает хостинг;
• поставить разумные права на файлы и каталоги, не давая лишней записи;
• убрать из веб-доступа резервные копии, дампы базы и архивы;
• проверить, какие каталоги действительно должны быть доступны на запись;
• защитить .htaccess или серверную конфигурацию от несанкционированного изменения;
• сменить секреты и соли, если есть подозрение на утечку конфигурации;
• проверить сайт после изменений: не сломались ли обновления, загрузка медиа и авторизация.

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