Сайт на WordPress взломали: что делать в первые 30 минут — пошаговое руководство

Утро понедельника. Открываете свой сайт — а там красный экран Яндекса «Сайт может угрожать безопасности вашего устройства». Или редирект на казино. Или хостер прислал письмо «Ваш сайт рассылает спам, аккаунт заблокирован». Если знакомо хотя бы одно — сайт взломали. Дышите. За первые 30 минут мы локализуем угрозу, за 1–2 дня вернём работу. Это решаемая задача — 90% сайтов восстанавливаются полностью без потери данных. Главное — не наделать новых ошибок в первые часы паники.

Как понять, что ваш сайт действительно взломали — 7 признаков

Иногда симптомы очевидны (редирект на казино), иногда сайт выглядит нормально, а проблема всплывает только в логах или поисковой выдаче. Я разобрал 7 главных индикаторов, по которым я диагностирую заражение в первые минуты обращения клиента.

Браузер показывает «Сайт может угрожать безопасности»

Самый громкий симптом. Chrome рисует красный экран с щитом, Яндекс.Браузер — оранжевый баннер «Сайт может угрожать безопасности вашего устройства». Это означает, что Yandex Safe Browsing или Google Safe Browsing уже занесли ваш домен в чёрный список — антивирусы автоматически перепроверили страницы и нашли вредоносный код или заражённые внешние скрипты. Посетители больше не увидят сайт, пока вы не вылечите и не подадите запрос на пересмотр.

Сайт перенаправляет на казино, аптеку или порно

Заходите на главную — а вас перебрасывает на 1xBet, фарма-магазин или казино. Иногда редирект работает только с мобильных, иногда только с поисковиков (cloaking — для бота сайт нормальный, для живого пользователя редирект). Это типичный casino-redirect или pharma-injection — классика. Технически работает либо через инжект в .htaccess, либо через JavaScript-сниппет в header.php темы или в wp_options.

В выдаче появились страницы на японском или китайском

Открываете Яндекс или Google, ищете свой сайт по бренду — а в выдаче рядом с настоящими страницами появились карточки на иероглифах. Это японский SEO-спам (или «Japanese keyword hack») — атакующие создают тысячи страниц со спам-контентом, чтобы Google проиндексировал их и поднял в выдаче. Главная цель — продажа поддельных товаров или ссылочный спам, ваш сайт используют как площадку.

Хостер прислал письмо «Ваш сайт рассылает спам»

Хостинг отправил уведомление о подозрительной активности с вашего IP, угрозу заблокировать аккаунт, или уже заблокировал сайт. Это означает, что бэкдор на сайте использует mail() или прямые SMTP-соединения для рассылки рекламы и фишинга с вашего домена. Хостер видит десятки тысяч исходящих писем за час и нажимает аварийную кнопку.

На страницах появилась чужая реклама

На сайте всплывают баннеры аптек, ставок, казино — те, которых вы никогда не размещали. Иногда просто новые ссылки в подвале или в боковой панели, иногда полноэкранные модалки. Технически это инжект через wp_options (поле siteurl, виджеты, активные плагины), реже — прямая правка functions.php темы.

Админка не пускает по правильному паролю

Заходите в /wp-admin/ по своему логину — а WordPress пишет «Неверный пароль». Сбрасываете через email — приходит ссылка восстановления, но и новый пароль не подходит. Это значит, что атакующий уже сменил пароль вашего админа, а возможно — поменял и email в профиле, чтобы вы не могли восстановить. Иногда они дополнительно создают своего «теневого» админа со случайным логином типа wp_8a7f2.

Резкий рост нагрузки на сервер

Хостинг ругается на превышение CPU или памяти. Сайт грузится в 5 раз медленнее обычного. В access.log — десятки тысяч запросов с разных IP за минуту. Это либо ваш сайт стал участником ботнета (рассылает спам, майнит криптовалюту, атакует чужие сервера), либо его используют как площадку для брутфорса других сайтов. В любом случае — серьёзная компрометация.

Первые 5 минут — что НЕ нужно делать

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

Не удаляйте сайт целиком — потеряете доказательства

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

Не меняйте пароли из заражённой сессии

Очень частая ошибка. Видите, что админка доступна → быстро меняете пароль → радуетесь. На самом деле, если на сервере есть бэкдор или JS-сниффер в админке, новый пароль сразу попадёт атакующим. Сначала убедитесь, что вы работаете из чистой среды — и менять пароли надо в правильной последовательности (об этом ниже).

Не звоните «специалистам с авито за 500 ₽»

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

Не пытайтесь «откатить» до диагностики

Кнопка «восстановить из бэкапа недельной давности» в панели хостинга кажется спасением. Но если бэкап уже содержит бэкдор (а так часто бывает — заражение могло случиться 2 недели назад, а проявиться вчера), вы откатитесь к той же скомпрометированной точке. Сначала диагностика: с какой даты появился вредоносный код. Только потом — откат.

Действия первых 30 минут — чек-лист

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

Шаг 1 — закройте сайт от посетителей через .htaccess

Пока на сайте вирус, каждый посетитель получает заражение или редирект. Yandex и Google за это понижают сайт в выдаче, а Safe Browsing помечает домен как опасный. Поэтому первое — закрыть сайт заглушкой для всех, кроме вас.

Создайте файл maintenance.html в корне сайта с текстом «Сайт временно на техническом обслуживании, скоро вернёмся». В .htaccess добавьте:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123.45.67.89$
RewriteCond %{REQUEST_URI} !^/maintenance.html$
RewriteRule .* /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html

Замените 123.45.67.89 на ваш IP (узнайте через 2ip.ru). Теперь все посетители видят заглушку, а вы свободно работаете с сайтом.

Шаг 2 — сделайте бэкап в текущем заражённом виде

Скопируйте файлы и базу данных «как есть» — это образец заражения для анализа. Через SSH:

cd ~/public_html
tar -czf ~/site-infected-$(date +%Y%m%d).tar.gz .
mysqldump -u DB_USER -p DB_NAME > ~/db-infected-$(date +%Y%m%d).sql

Сохраните оба архива на внешний диск. Не трогайте их — это улики и страховка. Если что-то пойдёт не так в процессе лечения, у вас всегда есть точка отката.

Шаг 3 — снимите скриншоты симптомов

Откройте сайт в браузере с включёнными DevTools (вкладка Network). Сделайте скриншоты:

• Самих симптомов (красный экран, редирект, японские страницы в выдаче)
• Сетевых запросов в DevTools — куда уходят запросы и ответы
• Письма от хостера или Яндекс.Вебмастера (если есть)

Это пригодится для запроса на пересмотр в Яндекс/Google и для общения с хостером.

Шаг 4 — сообщите хостеру и попросите не блокировать 24 часа

Откройте тикет в поддержку: «Сайт взломан, начал лечение, прошу не блокировать аккаунт в течение 24 часов, активность будет постепенно прекращаться». Большинство хостеров (Beget, Timeweb, Reg.ru) идут навстречу, если видят, что вы знаете о проблеме и работаете над ней.

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

Шаг 5 — смените пароли в правильном порядке: хостинг → FTP → БД → админка WP

Пароли меняются строго в этой последовательности — иначе атакующий, имеющий доступ через бэкдор, перехватит новый пароль. Между шагами очищайте сессии в браузере (Ctrl+Shift+Del → cookies для домена хостера и сайта).

1. Пароль панели хостинга. Через email или SMS-восстановление, не через активную сессию
2. FTP/SSH-пароли. В панели хостинга → раздел FTP → сменить пароль. Существующие SSH-ключи лучше удалить и создать заново
3. Пароль БД. Создайте нового MySQL-пользователя, обновите wp-config.php, после успешного теста удалите старого пользователя
4. Пароли админов WordPress. Через прямую правку в БД (UPDATE wp_users) или через сброс с email — после очистки functions.php от потенциальных перехватчиков

Где искать вирусы в WordPress

Атакующие обычно прячут код в нескольких типичных местах. Знание этих локаций экономит часы при ручной чистке. Я разобрал четыре основных направления, в которых стоит копать в первую очередь.

Папки-кандидаты: wp-content/uploads, plugins, themes

Самое популярное место для бэкдоров — wp-content/uploads/. По логике WordPress в эту папку должны попадать только медиафайлы (картинки, PDF, видео). Любой .php файл в uploads/ — стопроцентный признак заражения. Атакующие любят прятать webshell в подпапках вроде uploads/2024/03/ с безобидными именами типа thumb.php, cache.php, logo.php.

Найти все PHP-файлы в uploads через SSH:

find wp-content/uploads -type f -name "*.php"

Если вывод не пустой — каждый найденный файл подозрителен и должен быть проверен. Аналогично смотрите в wp-content/plugins/ на наличие папок плагинов, которые вы не устанавливали — особенно с короткими названиями вроде wpcfg, wp-system, seo-tools.

Файлы-маркеры: подозрительные .php в uploads, лишний код в wp-config.php

Корневые файлы WordPress — wp-config.php, index.php, .htaccess — должны выглядеть стандартно. Если в начале wp-config.php или в самом конце есть подозрительные include-конструкции, длинные base64-строки или вызовы eval() — это инжект.

Сравните размеры core-файлов с эталонными. Чистый wp-config-sample.php весит около 3 КБ. Если ваш wp-config.php вдруг 50 КБ — внутри лишний код. Аналогично wp-load.php, wp-blog-header.php — должны быть короткими.

Что такое webshell, бэкдор, c99, r57, FilesMan — простыми словами

Webshell — это PHP-файл, который даёт атакующему веб-интерфейс для управления сервером. Через браузер он может загружать новые файлы, редактировать существующие, выполнять команды операционной системы, читать базу данных. Знаменитые шеллы: c99, r57, FilesMan, WSO, b374k.

Бэкдор — это «потайная дверь». Часто это маленький PHP-сниппет, спрятанный в обычный плагин или тему, который при определённом GET-параметре выполняет произвольный код. Размер бэкдора может быть всего 50–100 байт — найти его глазами в гигабайтном WordPress практически невозможно. Поэтому используют сканеры.

Признаки в коде: eval(base64_decode(…)), обфусцированный JS

Типичные паттерны вредоносного PHP-кода, которые видны при ручном поиске:

• eval(base64_decode(…)) — выполняет произвольный код, упакованный в base64
• @assert(…) — выполняет PHP-выражение из HTTP-параметра (assert умеет принимать строку и интерпретировать её как код)
• create_function(…) — создаёт функцию из строки; в legacy-PHP это стандартный приём для динамической компиляции, в malware — способ запустить переданный код
• preg_replace с модификатором /e — устаревший флаг, который выполнял замену как PHP-код (удалён в PHP 7+, но всё ещё встречается в инжектах в старые сайты)

Все четыре конструкции принимают код из $_POST, $_GET или $_REQUEST и выполняют его — точные copy-paste-формы намеренно не привожу.

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

grep -rE "evals*(s*base64_decode|@assert|create_function|preg_replace.*/e" wp-content/ wp-includes/ *.php

Для JavaScript-инжектов признаки: длинные строки \x... или \u..., eval поверх обфусцированного кода, document.write со скрытыми iframe.

Сканеры — как проверить сайт на вирусы

Ручной поиск даёт понимание, где смотреть, но не покрывает всё. Сканеры за минуты прогоняют тысячи файлов по сигнатурам известных вирусов. Использую обычно несколько разных — у каждого свои сильные стороны.

AI-BOLIT — российский серверный сканер №1

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

cd ~/public_html
wget https://revisium.com/kb/aibolit.tar.gz
tar -xzf aibolit.tar.gz
cd ai-bolit
php ai-bolit.php --path=../public_html

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

ImunifyAV — встроен во многие хостинги

Серверный антивирус от CloudLinux. У Beget, Timeweb, Reg.ru обычно включён прямо в панели управления — проверка запускается одной кнопкой. Хорошо ловит шеллы и SEO-спам. Минус — иногда даёт false positive на легитимные плагины (особенно nulled-сборки).

Wordfence — сканер из админки WordPress

Самый популярный security-плагин для WordPress. Wordfence сканирует файлы на изменения относительно эталона из официального репозитория, ищет подозрительный код, проверяет обновления. Бесплатной версии достаточно для большинства задач. Установите, запустите Wordfence Scan и просмотрите отчёт.

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

VirusTotal и Yandex Safe Browsing — внешняя проверка домена

Внешние сервисы смотрят на сайт глазами браузера. На virustotal.com вводите URL — система прогоняет его через 70+ антивирусных движков. На yandex.ru/safety/ — проверка по базе Яндекс Safe Browsing. Если домен в чёрном списке — увидите сразу. Полезно ещё до начала лечения, чтобы понять масштаб.

Sucuri SiteCheck — бесплатный быстрый скан

Сервис sitecheck.sucuri.net — быстрая внешняя проверка сайта на признаки заражения. Анализирует исходный код, скрипты, статус в чёрных списках. Бесплатный, без регистрации. Хорошо подходит для первичной диагностики и для отчёта клиенту: «вот публичная проверка, видно проблему».

Удаление вируса — пошаговый план

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

Замена ядра WordPress на чистое

Самый надёжный способ вычистить заражённое ядро — заменить полностью. Скачайте свежую версию WordPress с ru.wordpress.org, распакуйте на локальном компьютере. Удалите с сервера все папки и файлы, кроме:

• wp-content/uploads/ — медиафайлы (предварительно проверенные)
• wp-content/themes/ — текущая тема (тоже под чисткой)
• wp-content/plugins/ — текущие плагины (под чисткой)
• wp-config.php — конфиг с доступами к БД
• .htaccess — правила сервера (под чисткой)

Залейте свежие файлы ядра вместо удалённых. Это гарантированно вычистит инжекты в core-файлах WordPress.

Переустановка плагинов из официального репозитория

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

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

Чистка темы или замена на дефолтную

Тема — второе по популярности место для бэкдоров. Если используете официальную тему из репозитория — переустановите свежую версию. Если ваша тема кастомная или платная — скачайте чистый вариант с git-репозитория или у разработчика.

Если есть подозрения, что тему могли модифицировать — временно переключитесь на дефолтную twentytwentyfour, пока не разберётесь. После лечения вернёте свою.

Проверка wp-config.php и .htaccess на инжекты

Откройте wp-config.php в редакторе и сравните с wp-config-sample.php. Должны быть только определения констант (DB_*, AUTH_KEY и т.п.) и стандартные require. Любые лишние include, base64-строки, вызовы create_function или eval — удаляйте.

В .htaccess в корне должны быть только стандартные правила WordPress (# BEGIN WordPress / # END WordPress). Любые лишние RewriteRule, особенно с редиректами на сторонние домены, condition по User-Agent (для cloaking) — удаляйте.

Сканирование БД: wp_options, wp_users, wp_posts на спам

Вирусы прячутся не только в файлах. В базе данных тоже стоит проверить:

-- Подозрительные значения в опциях (должны быть нормальные URL и настройки)
SELECT option_name, option_value FROM wp_options
WHERE option_value LIKE '%base64%' OR option_value LIKE '%eval%' OR option_value LIKE '%<script%';

-- Скрытые админы
SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%';

-- Спам в постах
SELECT ID, post_title FROM wp_posts
WHERE post_content LIKE '%<iframe%' OR post_content LIKE '%base64%';

Каждый подозрительный результат — проверять руками. Скрытых админов с непонятными логинами — удалять.

Удаление админов, которых вы не создавали

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

Также сбросьте все Application Passwords (если использовались) и проверьте список активных сессий — атакующий мог оставить долгоживущую сессию.

Восстановление из бэкапа — когда это правильно

Откат на бэкап — соблазнительный путь, но он работает не всегда. Ниже — три типичные ситуации и что в них делать.

Когда бэкап спасёт, а когда уже заражён

Бэкап «спасёт», только если он сделан до момента заражения. Проблема в том, что заражение часто происходит за 1–2 недели до видимых симптомов: атакующий ставит бэкдор, ждёт, потом активирует. За эти две недели все ваши автобэкапы успеют залить заражённую копию.

Поэтому: проверьте бэкапы старше 30 дней. Если есть архив на 2–3 месяца назад — он почти гарантированно чистый, но потеряете свежий контент. Решение: восстановить чистый бэкап в отдельную копию, прогнать через сканер, при чистоте — мигрировать актуальный контент (статьи, заказы, настройки) поверх.

Как проверить бэкап на чистоту

Не разворачивайте бэкап сразу на боевой сайт. Распакуйте локально или в тестовое окружение, прогоните AI-BOLIT и Wordfence по файлам. Сравните wp_options, wp_users, корневые файлы с эталонами. Только убедившись, что бэкап чистый, заливайте на боевой сервер.

Что делать, если бэкапа нет вообще

Чаще, чем хотелось бы. Если бэкапов нет, лечим то что есть: точечная чистка файлов и БД, замена ядра и плагинов на свежие, восстановление .htaccess и wp-config из эталона. В 95% случаев это работает — данные сохраняются, потерь нет.

Если контент частично потерян (например, бэкдор перезаписал посты), можно частично восстановить через Wayback Machine (web.archive.org) — он годами хранит снимки страниц. По одному вытаскиваете утерянный контент. Долго, но работает.

Снятие предупреждений Яндекса и Google

Если ваш сайт уже в чёрном списке Safe Browsing, недостаточно просто вылечить. Нужно сообщить поисковикам, что заражение устранено, и попросить пересмотр. Без этого красная плашка «Сайт может угрожать безопасности» останется ещё несколько недель.

Заявка на пересмотр в Яндекс.Вебмастер

Зайдите в webmaster.yandex.ru, выберите сайт, найдите раздел Безопасность и нарушения. Если есть отметка о заражении — там же будет кнопка «Я всё исправил». Нажимаете, описываете в свободной форме что было найдено и как очищено, отправляете запрос.

В описании укажите конкретику: какие файлы были заражены, какие сканеры использовали, что предприняли для предотвращения повторов (WAF, 2FA, обновления). Чем подробнее — тем быстрее робот примет решение.

Запрос проверки в Google Search Console

В Google Search Console: Безопасность и меры, принятые вручную → Проблемы безопасности. Там кнопка «Запросить проверку» с такой же формой описания. Google обычно отвечает быстрее Яндекса — за 2–3 дня против 5–7.

Сроки снятия — 3–7 дней

На практике Яндекс снимает метку за 3–7 дней после подачи запроса, Google — за 2–4 дня. Если за неделю реакции нет, написать повторно: возможно, проверка нашла остаточные следы (один пропущенный бэкдор) и не подтвердила очистку.

Что делать, если хостер уже заблокировал

Хостер блокирует чаще всего за рассылку спама с вашего IP. Откройте тикет: «сайт вылечен, прикладываю отчёт сканера, прошу разблокировать». Большинство хостеров после подтверждения чистки разблокируют в течение часа. Если хостер не идёт на контакт или требует много времени — перенесите сайт на другой хостинг временно или совсем.

Как вас взломали — типовые векторы атак

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

Уязвимый плагин — 90% случаев, как найти CVE

Самый частый сценарий. У вас стоит плагин версии 2.3, в нём найдена SQL-инъекция или RCE (CVE-2024-XXXXX), разработчик выпустил 2.4 с фиксом — но вы не обновили. Атакующий через Shodan или Wappalyzer находит уязвимые сайты и эксплуатирует.

Найти, через какой плагин зашли: посмотрите даты модификации файлов на сервере (find . -mtime -30 -type f — изменённые за 30 дней). Откройте wpvulndb.com или wordfence.com/threat-intel/ и проверьте версии установленных плагинов — какие из них имеют незакрытые CVE.

Брутфорс wp-login.php и xmlrpc.php

Если у вас слабый пароль администратора (Admin123, qwerty, имя жены) — атакующий может его подобрать через перебор. Атаки идут на /wp-login.php (стандартная форма входа) и на /xmlrpc.php (XML-RPC API, который большинству сайтов не нужен, но включён по умолчанию).

Признак в логах: тысячи запросов POST /wp-login.php или POST /xmlrpc.php с разных IP. Защита — отключить xmlrpc.php совсем (через плагин или nginx-правило), wp-login защитить через 2FA и ограничение попыток входа.

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

Скачали платный плагин «бесплатно» с торрента или варезного сайта? С 90% вероятностью в нём встроен бэкдор. Атакующий собирает базу сайтов, использующих этот nulled-плагин, и в любой момент активирует его. Иногда бэкдоры в nulled-сборках живут годами незамеченными.

Решение единственное: удалить все nulled-плагины и темы, заменить на лицензионные или бесплатные альтернативы. Экономия 5 000 ₽ на лицензии не стоит риска потерять весь сайт.

Слабые пароли FTP/SSH

Если FTP-пароль типа 123qweASD — это не пароль, это приглашение. Брутфорс FTP идёт круглосуточно с десятков тысяч ботов. Та же история со старыми SSH-паролями.

Защита: пароли длинной от 16 символов, генерированные менеджером (Bitwarden, 1Password, KeePass). На SSH — переход на ключи и отключение парольной аутентификации. На FTP — переход на SFTP, отключение plain FTP.

Старая версия WordPress или PHP

WordPress 5.x на сервере с PHP 7.0 — это коктейль уязвимостей. И ядро, и язык получают регулярные security-фиксы, которые применяются только при обновлении. Старая версия означает: десятки публично известных способов атаки.

Регулярно обновляйте ядро, плагины, темы и PHP. WP 6.x на PHP 8.2+ — современный безопасный стандарт.

Защита WordPress после лечения — 8 мер

После очистки нужно закрыть всё, через что могли войти. Без этих мер 30% сайтов взламывают повторно в течение 3 месяцев. Я применяю минимум 8 защитных слоёв.

Wordfence или Solid Security (бывший iThemes Security)

Базовый security-плагин для WordPress. Включает: файервол на уровне приложения (блокирует известные паттерны атак), сканер изменений файлов, ограничение попыток входа, мониторинг подозрительной активности. В большинстве случаев бесплатной версии достаточно.

Wordfence предпочитаю для технических админов — больше тонких настроек. Solid Security — проще для владельцев бизнеса, понятный UI.

Двухфакторная авторизация 2FA

Самая эффективная защита от компрометации админа. Даже если пароль украдут, без второго фактора (TOTP-код из Google Authenticator или Authy) войти не получится. Включается через плагины: WP 2FA, Two-Factor (от команды WordPress core), Wordfence Login Security.

Включите 2FA для всех ролей с правами публикации (редактор, автор, админ). Подписчиков можно не трогать — они не опасны.

Скрытие или перенос wp-login.php

Стандартный URL /wp-login.php и /wp-admin/ — первое, что пробует атакующий. Перенос на нестандартный URL (/secret-login/) через плагин WPS Hide Login убирает большинство автоматических атак. Это не безопасность через неизвестность как панацея, но снижает шум в логах в десятки раз.

Отключение xmlrpc.php

XML-RPC API нужен только для интеграций со старыми клиентами WordPress (мобильные приложения, Jetpack). Большинству сайтов он не нужен, но включён по умолчанию. Отключение через .htaccess:

<Files xmlrpc.php>
    Order Allow,Deny
    Deny from all
</Files>

Или через add_filter в functions.php темы. После отключения исчезают тысячи попыток брутфорса в логах.

WAF — Cloudflare / Sucuri / ModSecurity

Web Application Firewall — внешний слой защиты, который фильтрует трафик до того, как он дойдёт до сайта. Cloudflare даёт базовый WAF бесплатно, Sucuri — платный с расширенными правилами, ModSecurity — серверный (есть у нормальных хостеров). Закрывает SQL-инъекции, XSS, RCE на уровне правил OWASP.

Права на файлы: 644 для файлов, 755 для папок

Если на ваших файлах стоят 777 — любой пользователь сервера может в них писать. Это типичная ошибка после неаккуратной выгрузки FTP. Восстановите стандартные права:

find . -type d -exec chmod 755 {} ;
find . -type f -exec chmod 644 {} ;
chmod 600 wp-config.php

Конфиг с паролями — 600 (только владелец читает). Это убирает атаки через writable-файлы.

fail2ban от брутфорса

На VPS установите fail2ban с правилом для wp-login: при 5 неудачных попытках за минуту — бан IP на час. Брутфорс становится бесполезным. На shared-хостинге ту же логику дают плагины Limit Login Attempts Reloaded или встроенный Wordfence.

Автобэкапы в отдельное хранилище

Бэкапы должны лежать НЕ на том же сервере, что сайт. Если сервер скомпрометирован, бэкапы тоже. Используйте облачное хранилище: Yandex Object Storage, Selectel S3, Google Drive, Dropbox. Плагины UpdraftPlus и Solid Security умеют работать с этими сервисами.

Заодно при настройке защиты стоит проверить сайт на 152-ФЗ — раз уже разбираем код, можно одним проектом закрыть и безопасность, и закон. После лечения сайт может тормозить из-за сброшенных кэшей — оптимизация скорости восстановит производительность.

Когда самому не справиться — нужен специалист

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

Заражено ядро WordPress, wp-config или .htaccess

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

На хостинге несколько сайтов и заражены все

Cross-site contamination — когда атакующий через одну дыру заразил все сайты в аккаунте. Лечение каждого по отдельности не работает — после очистки одного остальные перезаражают его. Нужна синхронная чистка всех + изоляция аккаунтов на сервере.

Симптомы вернулись через сутки после чистки

Если после ваших действий вирус вернулся — значит остался бэкдор, который вы не заметили. Это самое сложное: что-то осталось живо и активирует заражение заново. Без серьёзной диагностики (анализ логов, мониторинг file changes, поиск cron-задач) — не справиться.

Сайт коммерческий — каждый час простоя = деньги

Интернет-магазин в сезон или сервис подписок не может позволить себе три дня экспериментов. Здесь время критично: 4–8 часов профессионального лечения дешевле, чем 3 дня самостоятельных проб с потерей выручки.

Сколько стоит лечение WordPress и сроки

Цены на рынке очень разные — от 500 ₽ «специалистов с авито» до 50 000 ₽ за корпоративные case’ы. Я разобрал реальный диапазон у адекватных фрилансеров и студий.

Цены: от 5 000 до 20 000 ₽ — от чего зависят

Стандартный случай: один сайт, заражение через плагин, до 50 заражённых файлов, нет специфики — от 5 000 ₽. Срок: 1–2 дня. Это базовый тариф у большинства специалистов.

Сложный случай: заражено ядро + БД + несколько сайтов на одном аккаунте, или большая кодовая база с кастомными плагинами — 10 000–20 000 ₽. Срок: 2–3 дня.

Срочный случай: заражение в момент пиковой нагрузки (распродажа, акция), нужна работа в нерабочее время — наценка 50–100% к базовому тарифу. У меня — от 10 000 ₽ за срочное лечение с приоритетом.

Сроки: 1-3 дня (не «за час»)

Если кто-то обещает «вылечить за час» — это либо поверхностная чистка симптомов с пропущенными бэкдорами, либо просто враньё. Реальное лечение даже простого случая — это 2–4 часа диагностики + 1–2 дня самой чистки и проверок. Сложные случаи — до 3 дней.

Гарантия: 30 дней повторного лечения бесплатно

Адекватный специалист даёт гарантию: если в течение 30 дней после лечения сайт заразили повторно при соблюдении вами рекомендаций — лечит бесплатно. Это нормальная индустриальная практика, без неё к специалисту лучше не идти.

Заключение и частые вопросы

Взлом WordPress — не катастрофа, а решаемая техническая задача. Главное: не паниковать в первые часы, не делать резких движений из заражённой сессии, последовательно идти по чек-листу. Большинство сайтов восстанавливаются полностью, без потери данных и SEO-позиций.

Сколько времени занимает лечение взломанного WordPress?

Диагностика — 2–4 часа. Полное лечение — 1–3 дня. Простые случаи (один бэкдор, одна точка входа) решаются за день. Сложные (заражено ядро + БД + несколько сайтов на одном аккаунте) — до 3 дней. Не верьте обещаниям «вылечить за час» — это либо поверхностная чистка с пропущенными бэкдорами, либо обман.

Можно ли вылечить сайт без потери данных?

В 95% случаев — да. Лечение — это не «удалить и поставить заново», а точечная чистка вредоносного кода. Контент, товары, заказы, пользователи, настройки сохраняются. Иногда теряются последние посты, если бэкдор прошёлся по wp_posts — но и это обычно восстанавливается через Wayback Machine.

Что делать, если бэкапа нет?

Лечим то, что есть: сканеры (AI-BOLIT, ImunifyAV) находят заражённые файлы, удаляем вручную, ядро WordPress и плагины переустанавливаем из официальных источников. Если контент частично потерян — частично восстанавливается через web.archive.org. После лечения — обязательно настроить автобэкапы в облачное хранилище.

Как Яндекс снимает предупреждение «сайт может угрожать»?

После очистки сайта подаётся запрос на пересмотр через Яндекс.Вебмастер: раздел «Безопасность и нарушения», кнопка «Я всё исправил». Робот заново проверяет страницы и снимает метку. Обычно — 3–7 дней после подачи запроса. Если не снимают дольше — значит остались следы, нужна доочистка.

Можно ли защитить WordPress от взлома на 100%?

На 100% — нет, абсолютной гарантии не даёт никто. Но можно снизить риск на 99%: регулярные обновления, 2FA для админов, WAF (Wordfence или Cloudflare), отключение xmlrpc.php, надёжные пароли, автобэкапы в облако. Большинство взломов происходит из-за устаревших плагинов и слабых паролей — это закрывается за один день правильной настройкой.