Как защитить WordPress без плагинов-комбайнов: настройки, которые не тормозят сайт

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

Ниже — что из мер безопасности действительно работает, что стоит времени загрузки и не даёт ничего, и какие популярные советы прямо вредны. Порядок выстроен от самого результативного к косметике: если сделать первые три пункта, остальные можно откладывать спокойно. В SEO с 2005 года, и взломанные сайты приходят на разбор регулярно — с установленным комбайном не реже, чем без него.

Чем «всё-в-одном» плагины платят за удобство

У тяжёлых плагинов безопасности есть три вида цены, и владелец сайта обычно видит только третью.

Первая — время ответа сервера. Файрвол уровня приложения подключается раньше ядра WordPress и прогоняет каждый запрос через набор регулярных выражений. На простом хостинге это добавляет к времени до первого байта заметную величину, и добавляет её ко всем страницам, включая закэшированные, потому что проверка идёт до кэша. Как это отражается на ранжировании, разобрано в материале про медленный сайт и низкие позиции.

Вторая — рост базы. Журнал событий, таблица заблокированных адресов и история сканирований за полгода набирают сотни мегабайт: запросы замедляются, бэкапы становятся неподъёмными. Отдельная неприятность — автозагружаемые опции, которые читаются при каждом обращении к сайту.

Третья — ложное спокойствие. Зелёная галочка «сайт защищён» в панели плагина закрывает вопрос в голове владельца, и после этого плагины не обновляются годами. При этом сам комбайн — тоже код, и в нём тоже находят уязвимости; у крупных решений это происходит регулярно. Плагин безопасности с дырой опаснее его отсутствия, потому что он работает с максимальными правами.

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

Что реально закрывает дыры, а что имитирует защиту

Полезно один раз развести меры по критерию: закрывает ли она конкретный сценарий проникновения или только усложняет автоматическому сканеру распознавание сайта.

Мера	Какой сценарий закрывает	Цена в скорости
Обновление ядра, тем и плагинов	Эксплуатацию известных уязвимостей — источник большинства массовых взломов	Нулевая
Удаление неиспользуемых плагинов и тем	Уязвимости в коде, который лежит на диске и остаётся исполняемым при отключённом плагине	Отрицательная: сайт становится быстрее
Запрет исполнения PHP в каталоге загрузок	Закрепление через залитый шелл — самый частый способ вернуться после чистки	Нулевая, правило веб-сервера
Права на файлы и защита wp-config.php	Чтение доступов к базе с соседнего сайта на том же аккаунте	Нулевая
Ограничение попыток входа	Перебор паролей — второй по массовости сценарий	Низкая при лёгкой реализации, высокая у комбайна с журналом в базе
Отключение редактора файлов в админке	Правку кода тем, если доступ к админке уже получен	Нулевая, одна константа
Скрытие версии WordPress из мета-тега	Ничего: версия определяется по путям к файлам ядра	Нулевая, но и пользы нет
Переименование страницы входа	Ничего: адрес всплывает в заголовках ответов и в перенаправлениях	Ломает интеграции и восстановление доступа

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

Обновления: единственная мера, которая работает всегда

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

• Автообновления безопасности ядра — включены. WordPress по умолчанию сам ставит минорные выпуски, и отключать это без веской причины не стоит. Именно они закрывают уязвимости.
• Мажорные версии — вручную, но в пределах месяца. Сначала на копии сайта, потом на бою. Задержка в год превращает обновление в проект с переделкой темы.
• Плагины — раз в неделю, руками, с проверкой сайта после. Автообновление плагинов допустимо для проверенных и простых, но для тех, что участвуют в выводе шаблона и форм, лучше держать контроль.
• Ревизия раз в квартал. Плагин, у которого последнее обновление больше года назад, а в описании висит отметка о несовместимости с текущей версией, подлежит замене. Заброшенные плагины — источник большинства дыр.

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

Права на файлы и wp-config

Права доступа — скучная тема, на которой ломается больше сайтов, чем на любых хакерских техниках. Стандартная схема простая: каталоги 755, файлы 644, конфигурационный файл 600 или 400. Права 777 не нужны никогда: если загрузка картинок не работает без них, проблема во владельце файлов, и решается она на стороне хостинга, а не расширением прав для всех.

Отдельно про wp-config.php: в нём доступы к базе, и на хостинге с несколькими сайтами это самая ценная цель — взломав соседний домен, злоумышленник читает конфиг вашего. Меры две: вынести файл на уровень выше корня (WordPress ищет его и там) и запретить его отдачу правилом веб-сервера.

Там же запрещается исполнение PHP в каталоге wp-content/uploads: легальных сценариев для скрипта в папке с картинками не существует, а закрепиться через неё пытаются в первую очередь.

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

Отключение редактора файлов и лишних точек входа

Встроенный редактор тем и плагинов в админке — прямой путь от украденного пароля администратора к исполняемому коду на сервере. Никакой практической необходимости в нём нет: правки удобнее вносить через дочернюю тему и файловый доступ. Отключается одной строкой в wp-config.php:

define('DISALLOW_FILE_EDIT', true);

Рядом стоит константа DISALLOW_FILE_MODS — она запрещает не только редактирование, но и установку с обновлением плагинов из админки. Мера жёсткая и подходит только тем, кто обновляется через файловый доступ или систему развёртывания; для обычного сайта она вредна, потому что мешает ставить обновления безопасности вовремя.

Дальше — регистрация. Если пользовательских аккаунтов на сайте нет, открытая регистрация выключается в настройках, роль по умолчанию — «Подписчик» и ничего выше: при роли «Автор» спамные записи появляются в первую же неделю. Комментарии — та же история: не нужны, значит отключаются для новых записей и закрываются для старых; нужны — включается премодерация и проверка почты.

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

Перебор паролей — второй по массовости сценарий после уязвимостей плагинов, и работает он тупо: бот стучится в форму входа со списком популярных комбинаций. Защита от него состоит из двух вещей.

Нормальные пароли. Длинный случайный пароль у каждого администратора и запрет на общий аккаунт «admin» для нескольких человек. Логин admin сам по себе не смертелен, но он есть в каждом словаре, поэтому имя пользователя лучше сделать другим, а отображаемое имя в записях — отличным от логина.

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

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

• Ломается восстановление доступа: ссылка из письма ведёт на стандартный адрес, который теперь отдаёт 404.
• Перестают работать интеграции, которые авторизуются через стандартную форму — от мобильного приложения до сервисов мониторинга и переноса.
• HTTP-авторизация поверх админки ломает загрузку файлов, асинхронные запросы админки и часть плагинов, которые обращаются к сайту по внутреннему адресу.
• При смене подрядчика или потере записи нестандартный адрес входа превращается в отдельную проблему, а иногда и в потерю доступа к сайту.

Вход должен оставаться на стандартном адресе /wp-login.php. Защищается он ограничением попыток, нормальным паролем и двухфакторной проверкой для администраторов — этого достаточно, а перебор всё равно упирается в счётчик, а не в незнание адреса.

Префикс таблиц, база и резервные копии

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

Резервные копии — единственная мера, которая работает после того, как всё остальное не сработало. Требований к ним три: хранение вне того же сервера, глубина не меньше тридцати дней и регулярная проверка развёртыванием. Копия за вчера бесполезна, если заражение произошло месяц назад и всё это время лежало тихо. Непроверенная копия бесполезна вдвойне: битые дампы обнаруживаются ровно в тот момент, когда они нужны.

Что делать	Как часто	Где выполняется
Обновление плагинов и тем с проверкой сайта после	Раз в неделю	Админка, раздел «Обновления»
Ревизия списка плагинов, удаление неиспользуемых	Раз в квартал	Админка плюс файловый доступ
Проверка списка пользователей и ролей	Раз в месяц	Админка, раздел «Пользователи»
Проверка прав на файлы и наличия PHP в загрузках	Раз в квартал	SSH или файловый менеджер хостинга
Тестовое развёртывание резервной копии	Раз в квартал	Тестовый поддомен или локальная копия
Проверка размера базы и автозагружаемых опций	Раз в квартал	phpMyAdmin или консольная утилита
Контроль доступности сайта и времени ответа	Постоянно, автоматически	Внешний сервис мониторинга

Последний пункт часто недооценивают, а он про безопасность не меньше, чем про скорость: резкий рост времени ответа или всплеск нагрузки — типичный ранний признак того, что на сайте что-то запустилось. Как выстроить наблюдение за сервером, описано в материале про контроль работы хостинга и сервера.

Когда лёгкой схемы не хватит

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

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

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

Несколько сайтов на одном аккаунте хостинга. Самая частая причина повторного заражения: сайты видят файлы друг друга. Правильное решение — разнести проекты по разным аккаунтам или пользователям, а не наращивать защиту внутри одного из них. Влияние площадки на устойчивость проекта отдельно разобрано в статье о том, влияет ли скорость сайта на продвижение — там же видно, почему дешёвый общий хостинг создаёт сразу два риска.

Старый сайт с самописной темой. Если тему делали десять лет назад и в ней есть свои обработчики форм и загрузки файлов, дыра почти наверняка в ней, а не в WordPress. Такой случай закрывается только чтением кода; типовые точки входа перечислены в разборе про способы взлома сайта, а приводить старую тему в порядок обычно проще в рамках общей доработки сайта, чем точечными заплатками.

Частые вопросы

Плагин безопасности уже стоит. Удалять?
Не обязательно удалять, достаточно разобрать по модулям. Отключите файрвол уровня приложения, журналирование в базу и постоянное сканирование по расписанию, оставьте проверку целостности файлов и уведомления. Затем измерьте время ответа сервера до и после — разница обычно видна сразу. Если она нулевая, плагин можно оставить как есть.

Насколько на самом деле опасен логин admin?
Сам по себе он не даёт доступа, но сокращает работу перебору вдвое: остаётся угадать только пароль. Практический вред невелик при нормальном пароле и ограничении попыток, но менять его всё равно стоит — заодно проверьте, что отображаемое имя в записях не совпадает с логином, иначе он публикуется в каждой статье.

Стоит ли закрывать админку по IP-адресу?
Это рабочая мера, но только при статическом адресе. С динамическим адресом от домашнего провайдера вы рано или поздно потеряете доступ в неудобный момент. Если хостинг позволяет — лучше ограничивать не саму админку, а доступ к панели управления сервером и к базе.

Двухфакторная проверка не замедлит вход?
Вход — да, на несколько секунд. Скорость сайта для посетителей она не меняет вообще: код проверяется только на форме авторизации и не выполняется на публичных страницах. Для сайта с одним-двумя администраторами это лучшее соотношение пользы к затратам.

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

Как понять, что защита настроена достаточно?
По трём проверкам: все компоненты обновлены, в каталоге загрузок нет ни одного PHP-файла, а из резервной копии сайт разворачивается за час. Если все три выполняются, вы надёжнее большинства сайтов на WordPress. Дальше вопрос переходит из безопасности в развитие, и здесь уже другая задача — заказать продвижение сайта и получать из поиска заявки, а не только спокойно спать.

Коротко

• Комбайн безопасности платит временем ответа, ростом базы и ложным спокойствием, а закрывает те же сценарии, что и пять бесплатных настроек.
• Первое по значимости — обновления: ядро автоматически, плагины еженедельно, ревизия заброшенных раз в квартал. Меньше плагинов — меньше поверхность атаки.
• Права 755/644, wp-config.php с правами 600 и запретом отдачи, запрет исполнения PHP в загрузках, отключённый листинг каталогов — всё это ничего не стоит по скорости.
• Редактор файлов в админке отключается константой DISALLOW_FILE_EDIT; открытая регистрация и роль выше «Подписчика» на обычном сайте не нужны.
• Вход остаётся на /wp-login.php: переименование страницы и HTTP-авторизация не защищают, но ломают восстановление доступа и интеграции.
• Резервные копии вне сервера, глубина от тридцати дней и проверка развёртыванием — единственное, что работает, когда всё остальное не сработало.