Эксплуатация WordPress без сюрпризов: обновления, бэкапы и защита от взлома — регламент нашего аутсорсинга

Меня зовут Евгений Семёнов, я технический директор компании «АйТи Фреш». Пятнадцать с лишним лет мы занимаемся IT-аутсорсингом для московских компаний до 50 рабочих мест: серверы, сети, 1С — и корпоративные сайты, большинство из которых крутится на WordPress. В первой статье серии я объяснял, почему мы ставим клиентам именно эту CMS, во второй — как грамотно развернуть её в продакшен. Сегодня разговор о самом недооценённом этапе: о том, что происходит с сайтом после запуска. Именно здесь решается, проживёт он спокойно десять лет или окажется у нас на столе «полечите, пожалуйста, срочно».

Сайт — это не «сделали и забыли»: три истории из практики

История первая. Директор производственной компании звонит в панике: клиенты жалуются, что в Яндексе рядом с названием фирмы выдаются страницы с рекламой виагры и ставок. Сам сайт при этом выглядит нормально. Вскрываем: полгода назад через дырявый плагин галереи на сервер залили дорвей-генератор, который тихо наплодил двенадцать тысяч мусорных страниц в подпапке. Поисковик их проиндексировал, репутация домена — в труху, восстановление позиций заняло четыре месяца.

История вторая. Сайт юридической фирмы с компьютера открывается идеально, а со смартфона через мобильный интернет — редиректит на онлайн-казино. Классическая закладка в теме: вредоносный код срабатывал только для мобильных User-Agent и только для посетителей из поиска, поэтому владелец месяцами ничего не замечал — он-то заходил с рабочего компьютера напрямую.

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

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

Обновления: наш регламент

Минорные версии ядра — автообновление всегда включено

Свежий пример прямо из этой недели. 20 мая 2026 года вышел мажорный релиз WordPress 7.0 «Armstrong», а 9 июля — корректирующий 7.0.1: 31 исправление ошибок плюс три патча безопасности. На сайтах наших клиентов 7.0.1 установился сам, ночью, без участия человека — потому что автообновление минорных версий мы никогда не отключаем. Минорки (7.0.1, 7.0.2 и так далее) не меняют функциональность, они только чинят баги и закрывают дыры, и риск от их автоматической установки на порядок ниже риска ходить с открытой уязвимостью. Если подрядчик когда-то выключил вам автообновления «чтобы ничего не сломалось» — это первый пункт, который стоит проверить сегодня.

Плагины и темы — еженедельное окно, критические дыры — в день патча

Плагины мы обновляем не хаотично и не «когда вспомнили», а в фиксированное еженедельное окно — у нас это ночь с понедельника на вторник. Перед окном автоматически снимается резервная копия базы и файлов, после — прогоняется быстрая проверка: главная открывается, форма заявки отправляется, в логах нет свежих фаталов. Если обновление что-то сломало (бывает пару раз в год), откатываемся из копии за минуты.

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

Мажорные релизы — только через staging

Следующий мажорный релиз, WordPress 7.1, назначен на 19 августа 2026 года. На боевые сайты клиентов он в этот день не попадёт: сначала мы разворачиваем копию сайта на тестовом поддомене, накатываем обновление там и прогоняем чек-лист — формы, корзина и оплата (если магазин), поиск, личные кабинеты, ключевые плагины. Только после этого, обычно через две-три недели, когда сообщество уже вычистило первую волну детских болезней, обновляется продакшен. Мажор меняет поведение ядра, и совместимость старых плагинов с ним никто не гарантирует — проверять это на живом сайте с трафиком слишком дорого.

Как это выглядит в коде

Всё перечисленное автоматизируется штатным инструментом wp-cli. Упрощённая версия нашего еженедельного скрипта:

#!/bin/bash
# Еженедельное окно обновлений: бэкап -> обновление -> проверка целостности
WP="wp --path=/var/www/site"

$WP db export /backup/db-pre-update-$(date +%F).sql
tar -czf /backup/wp-content-$(date +%F).tar.gz /var/www/site/wp-content

$WP plugin update --all
$WP theme update --all
$WP core verify-checksums || echo "ALERT: контрольные суммы ядра не сошлись!"

И строка в cron, которая запускает его каждый понедельник в 04:30 и пишет лог:

30 4 * * 1 /usr/local/bin/wp-weekly-update.sh >> /var/log/wp-update.log 2>&1

Команда wp core verify-checksums заслуживает отдельного абзаца: она сверяет каждый файл ядра с эталонными контрольными суммами WordPress.org. Если злоумышленник дописал свой код в системный файл — команда это покажет. Дешёвый и очень эффективный детектор заражения, о котором почему-то мало кто знает.

Бэкапы по схеме 3-2-1

Правило 3-2-1 родом из энтерпрайза, но для сайта малого бизнеса оно работает точно так же: три копии данных, на двух разных типах носителей, одна — вне основной площадки. Копия в соседней папке на том же хостинге не считается: при взломе сервера шифруются или затираются и сайт, и его «бэкап», при аварии хостера — исчезают оба.

Что бэкапим и как часто

База данных — ежедневно: в ней живёт всё, что меняется каждый день, — заказы, заявки, статьи, комментарии. Файлы wp-content (темы, плагины, загруженные картинки) — еженедельно плюс обязательно перед любым обновлением: файлы меняются реже, но весят больше. Само ядро WordPress бэкапить смысла нет — оно скачивается с WordPress.org за минуту, важно лишь помнить его версию.

Куда: копия на хостинге — не бэкап

Наш стандарт — выгрузка на независимое хранилище в другом дата-центре: у нас это собственные серверы в дата-центре МТС, физически и административно не связанные с хостингом сайтов. Если вы сопровождаете сайт сами, подойдёт любой вариант «вне площадки»: S3-совместимое объектное хранилище российского облака, второй дешёвый VPS у другого провайдера, в крайнем случае — регулярная выгрузка на офисный NAS. Ключевое требование: у хостинга сайта не должно быть доступа к хранилищу копий, а у сайта — прав на удаление старых копий (иначе взломщик удалит и их).

Бэкап не существует, пока не проверено восстановление

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

Сколько хранить

Наша глубина — 30 ежедневных копий плюс 6 ежемесячных. Длинный хвост нужен не из перестраховки: взлом часто обнаруживают через недели после проникновения, и свежие копии уже содержат закладку. Именно месячные архивы позволяют откатиться к гарантированно чистому состоянию и перенести оттуда «здоровые» файлы.

Харднинг: 10 мер, которые закрывают 90% атак

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

1. Уникальный логин администратора. Не admin, не название компании, не домен. Автоматический брутфорс перебирает пароли к предсказуемым логинам; нестандартный логин отсекает эти попытки ещё до проверки пароля.
2. Пароль из менеджера паролей плюс двухфакторная аутентификация. Сгенерированные 20+ символов, нигде больше не используемые, и 2FA-плагин с одноразовыми кодами. Украденный или подобранный пароль без второго фактора бесполезен.
3. Лимит попыток входа. Плагин, который после пяти неверных паролей блокирует IP на час. Превращает перебор из тысяч попыток в минуту в бессмысленное занятие.
4. Защита самой страницы входа. Перенос wp-login.php на нестандартный адрес, базовая HTTP-авторизация поверх неё или доступ только с IP офиса. Сканер, который не нашёл дверь, не будет её ломать.
5. Отключение XML-RPC, если он не используется. Этот старый интерфейс удалённого управления нужен единицам, а брутфорсеры любят его за возможность проверять сотни паролей одним запросом. Не пользуетесь мобильным приложением и внешними сервисами публикации — закрывайте.
6. Константа DISALLOW_FILE_EDIT в wp-config.php. Отключает встроенный редактор кода в админке. Если злоумышленник всё же получит доступ к панели, он не сможет одним кликом дописать бэкдор в файлы темы.
7. Актуальный PHP. Версия 8.3 и новее; EOL-версии (7.4, 8.0), не получающие патчей безопасности, — самостоятельная дыра независимо от состояния самого WordPress. Заодно свежий PHP заметно быстрее.
8. Полное удаление неиспользуемых плагинов и тем. Именно удаление, не деактивация: файлы деактивированного плагина остаются на диске, и уязвимость в них зачастую эксплуатируется напрямую, минуя WordPress.
9. Корректные права на файлы. Каталоги 755, файлы 644, wp-config.php — 600, и никогда никаких 777 «чтобы заработало». Правильные права не дают залитому скрипту переписать соседние файлы.
10. WAF — файрвол уровня приложения. Плагин-файрвол или защита на уровне хостинга/CDN, которая режет типовые атаки (SQL-инъекции, попытки залить файл) до того, как они дойдут до кода сайта. Последний рубеж, страхующий все предыдущие.

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

Плагины: гигиена выбора

Как читать карточку плагина в каталоге

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

Nulled-плагины: бесплатный сыр с бэкдором

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

Аудит раз в полгода: список сокращаем, а не наращиваем

Каждые полгода проходим по списку плагинов клиентского сайта с одним вопросом к каждому: «зачем ты здесь?» Слайдер, которым никто не пользуется, дублирующие друг друга SEO-плагины, «временный» плагин импорта, забытый после переезда, — под удаление. Каждый плагин — это чужой код с правами вашего сайта и потенциальная точка входа. Здоровая динамика — когда со временем список сокращается: типовому корпоративному сайту достаточно 10–15 живых, обновляемых плагинов.

Мониторинг: как узнать о проблеме раньше клиентов

Хуже взлома только взлом, о котором вы узнали от клиента. Или от хостера. Или из выдачи Яндекса. Наш минимальный контур мониторинга — четыре пункта:

• Доступность. Внешний сервис проверяет сайт каждые 1–5 минут и шлёт алерт в Telegram, если сайт лёг или отдаёт ошибку. Бесплатных инструментов достаточно; важно проверять не «пинг сервера», а конкретную страницу с контрольной фразой — заражённый сайт часто «работает», но отдаёт не то.
• Целостность файлов ядра. Тот самый wp core verify-checksums, запускаемый по cron ежедневно с уведомлением при расхождениях. Изменённый системный файл — почти всегда признак заражения, и лучше узнать о нём через сутки, чем через полгода.
• Контроль поисковой выдачи. Раз в неделю — запрос site:вашдомен.ru в Яндексе и Google: нет ли в индексе страниц, которых вы не создавали. Плюс панели Яндекс Вебмастера и Google Search Console — обе присылают уведомления, если находят на сайте вредоносный код или странные страницы. Дорвеи из первой истории этой статьи владелец увидел бы за месяцы до звонков клиентов.
• Сроки домена и SSL-сертификата. Банально, но просроченный домен — это потеря сайта и почты разом, а просроченный сертификат — красная страшилка браузера для каждого посетителя. Автопродление плюс независимое напоминание за 30 дней.

Настройка всего контура занимает минут пятнадцать. Эти пятнадцать минут — самая выгодная инвестиция в сайте: они конвертируются в недели сэкономленного восстановления репутации и позиций.

Если взлом всё-таки случился: план действий по шагам

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

1. Изолировать. Закрыть сайт технической заглушкой «ведутся работы». Пока сайт открыт, он заражает посетителей, рассылает спам и копает себе яму в поисковиках — каждый час на счету.
2. Сменить все пароли. Все — значит все: админка WordPress (всем пользователям), база данных, панель хостинга, FTP/SSH, почта, привязанная к аккаунту хостинга. Меняете что-то одно — злоумышленник возвращается через оставшееся.
3. Найти точку входа. По логам веб-сервера и датам изменения файлов установить, когда и через что зашли. Без этого шага любое «лечение» — гадание: вернутся через ту же дверь.
4. Восстановиться из чистого бэкапа. Взять копию, снятую заведомо ДО заражения (вот зачем месячная глубина хранения), развернуть её, закрыть найденную на шаге 3 дыру и только потом аккуратно перенести свежий контент — руками, а не копированием файлов из заражённой версии.
5. Просканировать результат. Антивирусное сканирование файлов и базы, wp core verify-checksums, проверка списка администраторов и запланированных задач WordPress — взломщики любят оставлять «спящие» точки возврата.
6. Подать на пересмотр. Если Яндекс или Google успели пометить сайт как опасный — запросить перепроверку в Вебмастере и Search Console, приложив описание сделанного. Снятие метки занимает от пары дней до пары недель.

Сколько стоит спокойствие

Сведу экономику вопроса в таблицу — по опыту наших «лечений» и обслуживания. Цифры усреднённые, для типового корпоративного сайта компании до 50 рабочих мест.

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

Чек-лист владельца сайта на одну страницу

Сводка всей статьи — распечатайте или сохраните. Если сайт обслуживает подрядчик, этот же список превращается в вопросы к нему: пусть покажет, как выполняется каждый пункт.

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

Это третья статья WordPress-серии ITfresh: в первой — почему мы выбираем WordPress для компаний до 50 рабочих мест, во второй — как правильно развернуть его в продакшен на российском хостинге. Дальше в серии — живой кейс миграции с цифрами.