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

Половина владельцев сайтов на WordPress считает, что взлом - это что-то из разряда «не со мной», пока не получает от хостера письмо с требованием почистить сайт от вредоносного кода. В моей практике встречались проекты, где владелец узнавал о заражении только после того, как Google выкидывал сайт из выдачи с пометкой о безопасности.

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

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

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

Почему WordPress становится мишенью для взлома

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

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

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

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

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

Число попыток автоматических атак на типовые точки входа CMS - формы логина, XML-RPC, известные пути плагинов - идёт непрерывно, боты сканируют интернет постоянно, а не выборочно. Поэтому вопрос не «взломают ли меня», а «готов ли сайт к моменту, когда его просканируют».

Надёжные пароли и двухфакторная аутентификация

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

Первое, что я меняю на любом новом проекте студии - логин администратора. Стандартный admin в связке с логин пароль от коробки - это подарок для брутфорс-скрипта (brute force, автоматический перебор паролей), который перебирает пароли к известному имени пользователя. Создаю отдельного администратора с непредсказуемым логином, а старую учётную запись admin удаляю или понижаю в правах.

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

Google Authenticator реализует двухфакторную аутентификацию через мобильное приложение (mobile application, программа для смартфона) - привязываешь его к аккаунту WordPress один раз через QR-код, дальше коды генерируются автономно без интернета. Из плагинов для подключения 2FA на WordPress я использую Wordfence Login Security или Two Factor Authentication - оба ставятся за пять минут.

Менеджер паролей помогает создавать и хранить уникальные сложные пароли для каждого сайта, не держа их в голове или в текстовом файле на рабочем столе. Из российских решений - Kaspersky Password Manager или встроенное хранилище паролей в Яндекс Браузере, оба генерируют случайные комбинации и синхронизируются между устройствами. Правило простое: один сайт - один уникальный пароль, никогда не переиспользуйте пароль от почты для входа в админку WordPress.

Защита страницы входа и админ-панели

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

Первый шаг - изменить стандартный URL страницы входа. По умолчанию WordPress отдаёт форму логина по адресу wp-admin или wp-login.php, и боты сканируют именно эти пути на любом сайте на CMS. Плагин WPS Hide Login скрывает стандартный URL страницы входа и позволяет задать собственный адрес - без правки кода, буквально пять минут настройки. После установки старый wp-admin отдаёт 404, и автоматические сканеры отваливаются на первом же запросе.

В одном из проектов студии мы вели интернет-магазин запчастей для спецтехники, и лог-файл сервера показывал больше 300 обращений к wp-login.php в сутки - причём с разных IP, явно ботнет. После установки WPS Hide Login это число упало до нуля, а нагрузка на сервер заметно снизилась: боты переставали дёргать PHP-обработчик впустую.

Стандартный логин admin повышает риск успешного подбора учётных данных - об этом уже говорили в блоке про пароли, но здесь это работает в связке со скрытием URL. Даже если адрес входа найден, без правильного логина и пароля атака упирается в стену.

Второй уровень защиты - ограничение доступа по IP через файл .htaccess. Если вы администрируете сайт с одного-двух статичных адресов (офис, дом), можно прописать директивы Deny и Allow from, разрешив доступ к wp-admin только с этих IP. Перед правкой обязательно сделайте резервную копию текущего .htaccess и впишите свой актуальный IP - ошибка в адресе заблокирует доступ в админку вам самим:

Такая настройка добавляется в отдельный .htaccess внутри папки wp-admin. Минус метода - если у вас динамический IP от провайдера или вы часто работаете с разных мест, придётся постоянно обновлять список разрешённых адресов, поэтому такой подход подходит не всем.

Капча на форме входа снижает количество автоматизированных атак ботов - плагины вроде Google Captcha (reCAPTCHA) добавляют проверку «я не робот» прямо на форму логина. Боты, заточенные под массовый перебор паролей, обычно не умеют проходить капчу, и это отсекает большую часть автоматических попыток без ручной настройки IP-фильтров.

Дополнительно стоит скрыть версию WordPress, которая по умолчанию торчит в мета-тегах и в коде страницы. Скрытие версии WordPress затрудняет подбор эксплойтов под конкретную версию CMS - злоумышленник, зная точную версию, ищет готовые уязвимости именно под неё. Уберите строку generator из head либо через код в functions.php, либо через плагин безопасности, о которых расскажу в следующих блоках.

Регулярные обновления ядра, плагинов и тем

Автоматические обновления ядра устраняют известные уязвимости системы - и это, пожалуй, самая простая и при этом самая часто игнорируемая мера защиты. Каждая новая версия WordPress закрывает конкретные дыры, о которых команда разработки уже знает, а значит, знают и потенциальные атакующие, изучающие changelog (список изменений в новой версии).

WordPress с версии 3.7 умеет ставить мелкие обновления безопасности автоматически - установите автообновления для мелких релизов и оставьте их включёнными без исключений, это тот самый минимальный уровень защиты. Крупные обновления версии (например, переход с 6.4 на 6.5) лучше проверять вручную на тестовой копии сайта, потому что они иногда конфликтуют с плагинами или темой.

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

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

Отдельный риск - неиспользуемые темы и плагины, которые просто лежат в системе неактивными. Даже отключённый плагин с уязвимостью может быть использован для атаки, если его файлы физически остаются на сервере. Правило простое: если плагином не пользуетесь полгода - удаляйте, а не просто деактивируйте.

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

Настройка файлов, базы данных и прав доступа

Изменение префикса таблиц базы данных усложняет проведение SQL-инъекций - по умолчанию WordPress называет таблицы с префиксом wp_, и это первое, что пробует автоматизированный скрипт при попытке инъекции. Смена префикса на случайный набор символов (например, wp_a8f3_) - штатная опция большинства плагинов безопасности или ручная правка при установке через wp-config.php. Стандартный префикс таблиц знают все автоматизированные скрипты, поэтому его смена - простая, но полезная мера.

Файл wp-config.php хранит данные доступа к базе данных, и это самый чувствительный файл во всей установке WordPress. Права доступа к нему стоит выставить строже стандартных - 440 или 400 вместо привычных 644, чтобы прочитать файл мог только владелец процесса на сервере. Дополнительно можно перенести wp-config.php на уровень выше корневой папки сайта - WordPress найдёт его автоматически, а прямой доступ через URL станет невозможен. После любых изменений в структуре базы стоит сразу проверить, что сайт открывается корректно и подключение не сломалось.

В этом же файле стоит добавить константу DISALLOW_FILE_EDIT, которая блокирует редактирование файлов тем и плагинов из админки. Штатный редактор кода в WordPress - удобная лазейка для злоумышленника: получив доступ к админке, он может прямо через браузер вписать вредоносный код в файл темы. Одна строка define('DISALLOW_FILE_EDIT', true); в wp-config.php полностью убирает эту возможность и не даёт изменить файлы тем и плагинов без доступа по FTP.

Отключение XML-RPC снижает риск брутфорс-атак через xmlrpc.php - этот файл существует для внешних приложений и старых мобильных клиентов WordPress, но на практике на большинстве проектов студии не используется вообще, а служит лишь ещё одной точкой для перебора паролей. Отключить можно через .htaccess или плагин безопасности, если XML-RPC вам не нужен для внешних интеграций.

Мы восстанавливали сайт поставщика промышленного оборудования, где база разрослась до трёх лишних служебных таблиц, оставшихся от старого плагина форм - в них через уязвимость в самом плагине заливались тестовые SQL-записи. После смены префикса таблиц и удаления неиспользуемых плагинов повторных попыток инъекций в логах не фиксировалось.

Настройка SSL-сертификата обеспечивает шифрование соединения между браузером и сервером - без него логин и пароль администратора при входе в админку передаются в открытом виде, и их можно перехватить на незащищённой сети. Сегодня SSL-сертификат - это база, которую бесплатно выдаёт Let's Encrypt почти любой хостинг, и отказа от него сегодня быть не должно.

Для передачи файлов на сервер используйте SFTP-протокол - он безопаснее обычного FTP при передаче файлов, потому что шифрует и данные, и учётные данные для входа. Обычный FTP передаёт пароль открытым текстом, и в общей сети Wi-Fi его можно перехватить тем же способом, что и пароль от админки без SSL.

Права доступа 644 для файлов и 755 для папок считаются базовой нормой безопасности WordPress - более широкие права (например, 777) открывают возможность записи файлов посторонним процессам на сервере. Изменить права доступа можно через FTP/SFTP-клиент или панель хостинга - для защиты вашего сайта этого обычно достаточно, и делается это один раз при настройке, без постоянного внимания в дальнейшем.

Плагины и инструменты для защиты от взлома

Web Application Firewall (WAF, файрвол - фильтр, отсекающий вредоносные запросы до того, как они дойдут до сайта) блокирует подозрительный вредоносный трафик ещё до того, как он доберётся до движка WordPress. Ставить такой мощный фильтр вручную долго, поэтому в 90% проектов студии мы используем готовые плагины безопасности - они закрывают несколько функций защиты сразу: файрвол, лимит попыток входа, сканирование файлов, 2FA.

Wordfence Security - по моему опыту, один из самых популярных бесплатных плагинов, выполняет сканирование файлов и мониторинг трафика в реальном времени. Интерфейс перегружен настройками для новичка, но разобраться можно за час. Бесплатного тарифа хватает малому бизнесу, платный добавляет проверку по свежей базе угроз без задержки в 30 дней.

Sucuri SiteCheck используется для сканирования сайта на вредоносный код и на наличие вредоносных программ без установки плагина - просто вбиваете домен на сайте сервиса и получаете отчёт. Платный Sucuri Firewall работает на уровне DNS, то есть трафик фильтруется ещё до хостинга - удобно для интернет-магазинов с высокой посещаемостью.

All In One WP Security - более простой и лёгкий по нагрузке на сервер вариант, подходит для блогов и визиток без больших объёмов трафика. Из коробки закрывает базовые вещи: смену префикса таблиц БД, лимит попыток входа, базовый файрвол. И ещё одно правило, о котором часто забывают: регулярно обновляйте плагины темы наравне с ядром, иначе вся остальная защита теряет смысл.

Все три инструмента - международные проекты с открытым кодом (open source) или облачные сервисы по подписке (SaaS), работы с РФ у них не ограничены: ни блокировок по региону, ни требований к серверам я в своей практике не встречал. Ставить два плагина безопасности одновременно не стоит - они конфликтуют на уровне правил файрвола и замедляют сайт. На новых проектах студии обычно хватает одного плагина безопасности, настроенного правильно с самого начала.

Отдельно упомяну Clearfy Pro - он стоит на этом самом блоге. Это не полноценный плагин безопасности, но базовую гигиену он закрывает: умеет менять адрес страницы входа, ограничивать попытки авторизации и скрывать ошибки входа, а заодно отключает REST API для неавторизованных и убирает лишние следы WordPress из кода страниц. Для лёгкого блога или сайта-визитки такой набор в связке с надёжным паролем часто закрывает вопрос без тяжёлого файрвола, а бонусом идут чистка мусора WordPress и ускорение сайта. Разработчик российский, оплата в рублях без посредников.

Резервное копирование, мониторинг и защита от DDoS атак

Резервное копирование позволяет восстановить сайт после взлома за 20-30 минут вместо недели переписки со специалистами по восстановлению. Плагин UpdraftPlus - в моей практике один из самых надёжных вариантов: настраиваете расписание (для магазина с ежедневными заказами - раз в сутки, для блога с редкими публикациями хватит раза в неделю) и место хранения - Google Drive, Яндекс.Диск, отдельное S3-хранилище.

Резервные копии вне публичной директории сайта защищают от доступа злоумышленников к бэкапам - если хранить архивы в папке /wp-content/backups/, при взломе их найдут и удалят или используют против вас же. Правило простое: копия должна лежать там, куда веб-сервер не даёт прямого доступа по ссылке.

Мониторинг и уведомления о подозрительной активности - вторая обязательная привычка. Wordfence и Sucuri присылают письмо при каждой попытке входа с неверным паролем сверх лимита, при изменении файлов ядра, при появлении нового администратора. В моей практике именно такое уведомление один раз позволило клиенту заметить взлом через 40 минут после атаки, а не через три дня.

Cloudflare защищает сайт от DDoS-атак на уровне сети - трафик проходит через их дата-центры, и аномальные всплески запросов фильтруются до того, как долетят до хостинга. Бесплатного тарифа достаточно для 90% проектов малого и среднего бизнеса, платный нужен только при регулярных целевых атаках на крупный интернет магазин или другой нагруженный проект.

Выбор тарифа хостинга напрямую влияет на устойчивость к взлому. Для простого блога хватает виртуального хостинга, где техническая поддержка провайдера реагирует на инциденты быстро. Для интернет-магазина с высокой нагрузкой и платёжными данными нужен VPS или VDS с изоляцией аккаунтов - такой формат снижает риск заражения через соседние сайты на том же сервере, что критично при работе на shared-хостинге (виртуальный хостинг, где один сервер делят десятки чужих сайтов) - там подобной защиты нет вообще.

Что делать, если сайт уже взломан

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

Первое - смените все пароли: от WordPress, от FTP/SSH, от базы данных, от личного кабинета хостинга. Взломщик мог получить доступ через любую из этих точек, и пока пароли старые, он вернётся снова.

Второе - проверьте список пользователей и удалите неизвестные учётные записи с правами администратора: создание нового пользователя без вашего ведома - самый частый способ закрепиться на взломанном сайте. Заодно проверьте, не появились ли удалённые страницы или записи - а заодно и добавленные без вашего ведома: взломщики часто вставляют скрытый JS-код в существующие публикации, а не только создают новые.

Третье - если есть чистая резервная копия до момента взлома, откатитесь на неё и восстановите базу и файлы. Это быстрее и надёжнее, чем вычищать вредоносный код вручную. Если бэкапа нет - просканируйте сайт через Wordfence или Sucuri SiteCheck и обращайтесь к специалистам: самостоятельная чистка без опыта - типичная ошибка, которая часто оставляет скрытые бэкдоры (backdoor, замаскированная лазейка для повторного доступа злоумышленника), и через месяц сайт взламывают повторно.

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

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

Данная статья основана на личном опыте автора и актуальна на момент публикации. Интерфейсы сервисов и алгоритмы поисковых систем регулярно меняются - рекомендую проверять актуальность инструкций на официальных ресурсах. Если у вас остались вопросы - задайте их в комментариях.

Список литературы

1. WordPress Foundation - Hardening WordPress // Advanced Administration Handbook // developer.wordpress.org
2. Wordfence - WordPress Security Learning Center // Wordfence Blog
3. Sucuri - WordPress Security Guide // Sucuri Blog
4. Google - Security issues report // Search Console Help // support.google.com