Как защитить административную часть WordPress

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

Разделите повседневную и административную работу

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

Снимите список пользователей и ролей через WP-CLI:

wp --path=/srv/www/example.com/current user list \
  --fields=ID,user_login,user_email,roles,registered --format=table

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

Включите HTTPS и 2FA

Административная сессия должна проходить только по HTTPS. В wp-config.php можно потребовать защищённый протокол для панели после того, как TLS и reverse proxy настроены правильно:

define( 'FORCE_SSL_ADMIN', true );

После изменения откройте вход в новом приватном окне и проверьте отсутствие redirect loop. За proxy WordPress должен корректно получать исходную схему запроса; иначе сначала исправьте доверенные заголовки.

2FA добавляйте поддерживаемым плагином, который предлагает резервные коды и понятное восстановление. Сначала включите для одного администратора, сохраните коды вне VPS и проверьте вход. Затем распространите правило на остальных привилегированных пользователей.

Ограничьте перебор без блокировки владельца

Ограничение попыток ставят на уровне приложения, Nginx или внешнего proxy, но учитывают реальный IP клиента. За балансировщиком нельзя доверять любому X-Forwarded-For: иначе атакующий подставит адрес или все посетители будут выглядеть одним IP.

Начните с наблюдения за кодами ответа и не делайте вечную блокировку после пары ошибок. Всегда сохраняйте консоль хостера и WP-CLI как независимый путь восстановления.

Запретите редактирование PHP из панели

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

Права самого файла и секретов подробно разобраны в отдельной главе. PHP-FPM не должен владеть всем деревом приложения.

Проверяйте целостность и обновления

Для ядра и плагинов из официального каталога WP-CLI сравнивает файлы с опубликованными checksum:

wp --path=/srv/www/example.com/current core verify-checksums
wp --path=/srv/www/example.com/current plugin verify-checksums --all --strict
wp --path=/srv/www/example.com/current core check-update
wp --path=/srv/www/example.com/current plugin list --update=available

Изменённый файл требует объяснения. Коммерческий плагин может не иметь checksum WordPress.org, поэтому отсутствие эталона не равно заражению. Обновления сначала проверяйте по процедуре staging.

Проверьте восстановление доступа

До аварии запишите команды деактивации неисправного 2FA-плагина через WP-CLI, местонахождение резервных кодов и способ сброса пароля. Не храните всё только на самом VPS.

После настройки попробуйте войти редактором и убедитесь, что он не видит установку плагинов. Затем войдите администратором с 2FA, проверьте журнал входов и уведомление о тестовом событии. Защита считается рабочей, когда законный пользователь входит, лишние права отсутствуют, а восстановление проверено.

Источники

• WordPress: hardening
• WordPress: two-step authentication
• WordPress: roles and capabilities
• WordPress: HTTPS administration