Если у вас сайт на WordPress, файл wp-config.php — это, по сути, один из главных рычагов безопасности. Не самый заметный. Не самый «гламурный». Но очень полезный. И вот что забавно: большинство владельцев сайтов туда вообще не заглядывают после установки.
А зря.
В этом файле можно включить несколько простых вещей, которые реально уменьшают риск взлома, косяков после апдейтов и всякой странной возни в админке. Не надо покупать дорогой «enterprise security suite», честно. Для маленького магазина, сайта услуг или корпоративного сайта на 20 страниц это обычно перебор.
Сейчас покажу 5 констант, которые почти никто не задает — а стоило бы. И да, перед любыми правками сначала делайте бэкап файла. Это 2 минуты, зато потом не будет мучительно больно.
Сначала — где вообще находится wp-config.php
Обычно он лежит в корне сайта. Там же, где папки wp-admin, wp-content и wp-includes. Открыть его можно через файловый менеджер хостинга или по SFTP.
Если не уверены, лучше не редактировать файл прямо в браузере на скорую руку. Скачайте копию. Откройте в нормальном редакторе. Проверьте. Потом загрузите обратно. Одна пропущенная кавычка — и сайт ляжет. Да, вот так тупо.
Кстати, если у вас уже были странные редиректы, новые админы «сами появились» или хостинг ругался на вредоносный код, сначала прочитайте статью Как понять, что ваш сайт на WordPress взломали — 7 явных признаков. Потому что hardening хорош до взлома, а не вместо лечения после него.
1. DISALLOW_FILE_EDIT — отключаем редактор файлов в админке
Вот эта штука прям must-have:
define('DISALLOW_FILE_EDIT', true);Что она делает? Убирает встроенный редактор файлов из админки WordPress. То есть нельзя будет зайти в «Внешний вид — Редактор файлов темы» или в редактор плагинов и править PHP-код прямо оттуда.
Почему это важно:
- если кто-то получил доступ к админке, ему сложнее быстро вшить бэкдор;
- админ или менеджер сайта не сломает тему случайной правкой «на живом» сайте;
- меньше соблазна чинить код на проде как попало.
Честно говоря, встроенный редактор WordPress — это больше ловушка, чем удобство. Разработчику он не нужен, он и так работает через Git, SFTP или staging. Владельцу бизнеса — тем более.
Времени на настройку — минута. Стоимость — ноль.
2. DISALLOW_FILE_MODS — если не хотите, чтобы плагины и темы менялись из админки
Это уже чуть жестче:
define('DISALLOW_FILE_MODS', true);Эта константа отключает установку, обновление и удаление плагинов и тем из админки. А еще обновление самого WordPress через интерфейс.
Когда это полезно? Например, если сайт поддерживает подрядчик, а вы не хотите, чтобы менеджер магазина в пятницу вечером поставил «красивый слайдер со звездами», который не обновлялся с 2021 года. Видел такое. Не раз.
Но тут нюанс. Если вы включите эту константу, апдейты через админку тоже отрубятся. Значит, обновлять придется вручную или через внешнее обслуживание. Для части сайтов это отлично. Для части — неудобно.
Я бы советовал так:
- Для небольшого бизнес-сайта, где в админку заходят 2-3 человека — включать можно.
- Для магазина, где контентом управляет команда без технаря под рукой — лучше сначала продумать процесс апдейтов.
- Если сайт ведется на регулярной поддержке, это вообще нормальная практика.
Если у вас как раз такой случай и хочется чтобы сайт обновлялся без самодеятельности, посмотрите обслуживание WordPress. Для малого бизнеса это часто дешевле одного нормального инцидента после кривого плагина.
3. AUTOMATIC_UPDATER_DISABLED — не всегда хорошая идея, но иногда спасает
Константа такая:
define('AUTOMATIC_UPDATER_DISABLED', true);Она отключает автоматические обновления WordPress.
Сейчас кто-то скажет: «Стоп, разве обновления не нужны?» Нужны. Конечно. Но автоматические апдейты без контроля — не всегда подарок. Особенно если сайт старый, на кастомной теме, с 17 плагинами и одним «самописным» модулем от бывшего фрилансера, который пропал в 2022 году.
В таком случае ночью может прилететь обновление, а утром у вас не корзина работает, а белый экран. И привет, реклама встала, заказы не идут.
Но отключать автоапдейты всем подряд я бы не стал. Скорее так:
— если сайт простой и современный — автообновления часто ок;
— если сайт хрупкий, старый или завязан на бизнес-процессы — лучше обновлять вручную после проверки;
— если вы не следите за сайтом вообще, отключить автоапдейты и забыть — плохая идея.
Короче, тут не магия, а вопрос дисциплины. Отключили автоапдейты — значит у вас должен быть график ручных обновлений. Хотя бы раз в месяц. Лучше чаще.
Кстати, отдельно почитайте про заброшенные плагины. Вот где часто сидит реальная проблема, а не в самом WordPress.
4. WP_POST_REVISIONS — не совсем про безопасность, но косвенно помогает
Да, это не «защитная» константа в лоб. Но она влияет на размер базы и общую гигиену сайта:
define('WP_POST_REVISIONS', 5);WordPress хранит ревизии записей и страниц. Если сайт живой — новости, карточки товаров, описания услуг — этих ревизий со временем накапливается очень много. Сотни. Иногда тысячи.
Почему это вообще в статье про безопасность? Потому что захламленный сайт тяжелее обслуживать, дольше бэкапить, дольше восстанавливать после проблем. А когда случается взлом или сбой, лишний мусор только мешает.
Пять ревизий для большинства сайтов хватает с головой. Для блога — ок. Для сайта услуг — тоже. Для маленького магазина — обычно более чем.
Экономия тут не в рублях, а в нервах. И в скорости восстановления. А это, если сайт приносит заявки, уже деньги.
5. EMPTY_TRASH_DAYS — мусор тоже лучше выносить вовремя
Еще одна простая настройка:
define('EMPTY_TRASH_DAYS', 7);По умолчанию WordPress хранит удаленный контент в корзине 30 дней. Месяц. Долго. Для большинства сайтов это вообще без смысла.
Если поставить 7 дней, у вас будет неделя на «ой, случайно удалили страницу», а потом мусор очистится сам.
Опять же — это не защита от хакера напрямую. Но это нормальная кибергигиена. Чем меньше бардака в системе, тем проще заметить что-то подозрительное, быстрее сделать дамп, легче откатиться.
И да, когда на сайте бедлам — старые черновики, куча ревизий, неиспользуемые темы, 47 плагинов — любая диагностика занимает дольше. А время в инциденте решает.
Куда вставлять эти строки
Все эти define() обычно ставят в wp-config.php до строки:
/* That's all, stop editing! Happy publishing. */Примерно так:
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);
define('AUTOMATIC_UPDATER_DISABLED', true);
define('WP_POST_REVISIONS', 5);
define('EMPTY_TRASH_DAYS', 7);Но не надо просто слепо копировать весь набор. Особенно DISALLOW_FILE_MODS и AUTOMATIC_UPDATER_DISABLED. Сначала подумайте, кто и как будет обновлять сайт потом. Это важнее, чем «поставить все галочки».
А этого уже достаточно?
Не-а.
wp-config.php — это хороший старт, но не полноценная защита. Если пароль слабый, в админке один юзер на всех, хостинг дешевый до боли, а плагины не обновлялись полгода — эти константы не спасут. Ну правда.
Что еще стоит сделать вместе с этим:
- включить 2FA для админов;
- убрать неиспользуемые плагины и темы;
- проверить права доступа к файлам;
- настроить бэкапы и протестировать восстановление;
- поставить мониторинг входов и изменений файлов.
Если сайт уже заражен, не тяните. Тут не «почистим кеш и посмотрим». Тут нужен разбор файлов, базы, пользователей, cron-задач, скрытых бэкдоров. В таком случае лучше сразу смотреть помощь после взлома сайта, потому что полумеры часто заканчиваются повторным взломом через неделю-другую. Чо обидно, да.
Итог — что ставить в первую очередь
Если хочется короткую версию, вот она:
Сразу ставьте: DISALLOW_FILE_EDIT, WP_POST_REVISIONS, EMPTY_TRASH_DAYS.
С осторожностью: DISALLOW_FILE_MODS, AUTOMATIC_UPDATER_DISABLED.
Это все делается за 10-15 минут, даже с бэкапом. Денег — ноль, если делаете сами. Эффект не вау-маркетинговый, но реальный. Меньше лишних рисков, меньше хаоса, проще сопровождать сайт.
А для малого бизнеса это, по сути, и есть нормальная безопасность — не волшебная кнопка, а набор вменяемых мелочей которые вместе сильно снижают шанс проблем.
Мелочи. Но полезные.