WordPress — самая популярная CMS в мире, и именно поэтому она же самая частая цель автоматизированных атак: злоумышленникам не нужно взламывать конкретно ваш сайт, достаточно массово сканировать миллионы установок на известные уязвимости в устаревших плагинах и темах. Базовая защита, которая закрывает 90% реальных угроз, не требует дорогих решений — только дисциплины в нескольких направлениях.
Подавляющее большинство взломов происходит не через «гениальный эксплойт», а через давно известную и публично задокументированную уязвимость в плагине или теме, которую владелец сайта не обновил. WordPress поддерживает автоматические обновления минорных версий ядра из коробки — их не стоит отключать. Для плагинов и тем автообновления стоит включать выборочно: для проверенных, стабильных решений — да, для кастомных или редко используемых — только после проверки на тестовой копии, чтобы обновление не сломало сайт в момент, когда никто не следит за логами.
Брутфорс-атаки на wp-login.php — фоновый шум интернета, они идут на любой сайт постоянно, независимо от его популярности. Сложный пароль администратора — минимум, но не единственная мера: плагин или серверное правило, ограничивающее число попыток входа с одного IP, снижает эффективность брутфорса на порядки. Там, где это возможно, стоит включить двухфакторную аутентификация для учётных записей с правами администратора — она нейтрализует брутфорс и утечку пароля одновременно.
Неправильные права на файлы — частая причина, по которой безобидная уязвимость в одном плагине превращается в компрометацию всего сайта. Рекомендуемые значения — 644 для файлов и 755 для директорий, wp-config.php стоит делать ещё строже (600, где это поддерживается хостингом). Отдельная мера — смена стандартного префикса таблиц базы данных wp_ на случайный: это не останавливает целенаправленную атаку, но исключает из игры автоматические SQL-инъекции, которые рассчитаны на дефолтный префикс.
Бэкап, который никогда не тестировали на восстановление, — это не бэкап, а иллюзия защищённости. Правило 3-2-1 означает: минимум 3 копии данных, на 2 разных носителях, одна из которых — вне основного сервера. Резервные копии базы данных и файлов сайта, которые физически хранятся на том же сервере, что и сам сайт, не защищают от взлома или аварии хостинга — при компрометации сервера атакующий получает доступ и к бэкапам тоже.
Для WordPress есть встроенный способ проверить, что файлы ядра и официальных плагинов не были изменены со времени установки — команда WP-CLI wp core verify-checksums сверяет хэши файлов с эталонным репозиторием и показывает расхождения. Регулярный, хотя бы еженедельный прогон этой команды (вручную или по расписанию через cron) — один из самых надёжных способов заметить взлом на раннем этапе, до того как заражение успеет распространиться или сайт попадёт в чёрные списки поисковых систем.
Если ресурсы ограничены и закрыть всё сразу не получается, порядок внедрения стоит выстраивать от вероятности реальной атаки к редкости сценария: сначала обновления и ограничение попыток входа — они блокируют массовое автоматическое сканирование, которое идёт на любой сайт постоянно. Следом — права доступа к файлам и смена префикса таблиц, которые нейтрализуют автоматизированные инъекции. Резервное копирование и мониторинг целостности — третий эшелон, который не предотвращает атаку, но минимизирует её последствия и сокращает время обнаружения, если первые два рубежа всё же будут пройдены.
Отключение автообновлений «на всякий случай» и последующее забывание обновлять сайт вручную — пожалуй, самая массовая ошибка: отключить проще, чем выстроить процесс регулярной проверки, поэтому сайт остаётся на уязвимой версии годами. Вторая ошибка — хранение единственного администратора сайта с общим на всех паролем, который используется и для других сервисов: утечка пароля с любого стороннего сайта автоматически компрометирует WordPress. Третья — бэкапы «для галочки», создаваемые плагином, но ни разу не проверенные на то, что из них реально можно восстановить сайт: обнаруживать нерабочий бэкап стоит до инцидента, а не во время него. Четвёртая — открытый для публичного доступа файл xmlrpc.php, который исторически использовался для удалённой публикации, но на большинстве современных сайтов не нужен вообще и остаётся популярным вектором для DDoS через pingback-механизм и для брутфорса в обход штатных ограничений на wp-login.php.
