Сайт почистили. Вредоносный код убрали. Главная страница снова открывается, редиректов нет, хостинг перестал ругаться. Казалось бы — все, отмучались.
А потом через неделю все по новой.
Знакомо? Это очень частая история с WordPress. И дело обычно не в том, что “плохо почистили” в лоб. Хотя и такое бывает, конечно. Чаще проблема глубже — убрали следствие, а дырка осталась. Или даже две. Или, что веселее, на сайте тихо сидит бэкдор и ждет.
Давайте на пальцах разберем, почему сайт заражается снова после вроде бы успешной очистки и что с этим делать, чтобы не бегать по кругу.
Очистка — это не лечение причины
Самая частая ошибка простая: нашли зараженный файл, удалили его, выдохнули. Но как он туда попал? Вот этот вопрос часто никто не задает.
Если на сайте был уязвимый плагин, старый пароль от админки, взломанный хостинг-аккаунт или открытый доступ через FTP, малварь вернется. Не магия. Просто дверь все еще открыта.
Смотрите, типичный сценарий у маленького бизнеса такой: интернет-магазин на WooCommerce, 18 плагинов, половина ставилась “на минутку”, пара лет без нормальных апдейтов, у бывшего подрядчика до сих пор есть доступ. Сайт чистят, но:
- не меняют все пароли;
- не обновляют WordPress, тему и плагины;
- не проверяют пользователей и их роли;
- не ищут, через что именно вошли;
- не смотрят cron-задачи, mu-plugins и подозрительные файлы.
И да — через пару дней тот же скрипт или бот снова заливает шелл. Все.
На сайте остался бэкдор
Вот это прям классика. Видимый мусор удалили, а маленький файл где-нибудь в /wp-includes/, /uploads/2023/11/ или внутри вроде бы безобидного плагина пропустили. Он может называться как угодно: wp-cached.php, class-content.php, admin-ajax-old.php. Иногда название вообще приличное. В этом и фишка.
Бэкдор — это запасной вход. Через него злоумышленник может вернуть малварь в любой момент. Даже если вы поменяли пароль от админки. Даже если обновили один плагин. Пока бэкдор жив, сайт по сути не очищен.
Честно говоря, ручная очистка “на глаз” тут часто не вывозит. Особенно если файлов много, сайт старый, а шаблон когда-то правили прямо на сервере. Нормальная проверка занимает не 10 минут. Маленький сайт — где-то час-два, магазин с кастомщиной — дольше.
Если сайт уже взламывали, разумнее сразу смотреть не только зараженные страницы, а весь след атаки. Иначе будете тушить пожар тряпкой. Для таких случаев как раз есть помощь после взлома сайта — когда чистят не “что видно”, а ищут, как именно залезли и что оставили после себя.
Пароли поменяли не везде. Или не всем
Иногда владелец говорит: “Мы же сменили пароль”. Один. От WordPress.
А есть еще пароль от хостинга, FTP/SFTP, базы данных, панели регистратора домена, почты администратора. Плюс старые юзеры в самой админке WordPress. И вот через такой забытый вход сайт и уводят обратно.
Причем совсем не обязательно суперсложным способом. Очень часто все банально. Слабый пароль, утечка из браузера, reuse одного и того же пароля в трех сервисах. Если эта тема вам знакома, советую отдельно почитать про слабые пароли и как из-за них уводят сайт. Там как раз без страшилок, по делу.
Что делать после очистки:
- Сменить все пароли, не только от админки.
- Удалить старых пользователей и подрядчиков, которым доступ уже не нужен.
- Включить 2FA хотя бы для админов.
- Проверить, нет ли странных админов с почтой вроде
wptechsupport24@....
На это уходит обычно 20-40 минут. А пользы больше, чем от половины “премиум-защит” за 300 евро в год.
Уязвимый плагин остался на месте
Тоже сплошь и рядом. Сайт почистили, но оставили тот же дырявый плагин, через который все и случилось. Через день бот снова его находит. И привет.
Особенно опасны:
— заброшенные плагины без апдейтов годами
— nulled-плагины и темы “бесплатно с форума”
— формы, слайдеры, импортеры, файловые менеджеры
— все, что умеет загружать файлы на сервер
И да, даже деактивированный плагин иногда лучше удалить совсем. Если в нем уязвимость в файлах, бот может достать до них напрямую. Многие об этом даже не думают.
Кстати, если у вас на сайте 47 плагинов и вы не уверены, какие из них вообще живые, стоит периодически прогонять проверку публичных уязвимостей. Например, через сканирование уязвимостей плагинов. Это не серебряная пуля, но хотя бы видно, где явная дыра. Обычно такая проверка занимает минуты, а не часы.
А еще очень советую прочитать про заброшенные плагины. Для старых сайтов это, наверноо, одна из самых недооцененных проблем.
Восстановили сайт из бэкапа — а бэкап уже был заражен
Вот это особенно обидно. Люди откатывают сайт на копию недельной давности, а заражение там уже сидело. Просто еще не проявилось явно.
В итоге кажется, что “после восстановления нас снова взломали”. А на деле вы сами вернули зараженные файлы назад.
Поэтому хороший бэкап — это не просто архив. Его еще надо уметь проверять. Как минимум:
- смотреть дату первого подозрительного поведения сайта;
- поднимать копию на тестовом домене или staging;
- проверять файлы темы, плагины, uploads и админов;
- не откатывать вслепую “самую свежую копию”.
Для маленького сайта такая проверка может занять час. Для магазина с заказами — больше, потому что надо еще не потерять новые данные. Но это все равно лучше, чем три раза подряд “восстанавливаться” из зараженной версии.
Проблема вообще не в WordPress
Иногда сам WordPress уже чистый. А заражение лезет с соседнего сайта в том же аккаунте хостинга, через старый phpMyAdmin, через дырявый скрипт на другом домене или через украденный FTP-доступ.
То есть вы лечите один сайт, а источник сидит рядом.
Я видел такое много раз: у компании есть основной сайт, лендинг пятилетней давности и тестовый поддомен “new.old.site”. Владелец про него забыл. Зато боты — нет. Через этот мусорный поддомен получают доступ ко всему аккаунту. Потом заражают основной сайт снова. Весело? Неа.
После очистки всегда стоит проверить весь аккаунт хостинга, а не только текущий домен. И если хостинг старый, без изоляции сайтов, без нормального логирования, без актуальной версии PHP — это тоже риск. Экономия на 3 евро в месяц тут обычно выходит боком.
Нет наблюдения после очистки
Еще одна ошибка — считать, что после уборки можно забыть про безопасность на полгода. На самом деле первые дни после очистки самые важные. Именно тогда часто видно, вернется ли атака.
Что полезно держать под рукой:
— мониторинг доступности сайта
— журнал действий пользователей
— контроль изменений файлов
— уведомления о подозрительных входах
— регулярные апдейты ядра, темы и плагинов
Короче, сайт после взлома лучше не “оставлять на авось”. Хотя бы месяц за ним надо смотреть внимательнее. А лучше держать нормальное регулярное обслуживание WordPress, где апдейты, проверки и базовая защита идут постоянно. Для малого бизнеса это обычно дешевле, чем один серьезный взлом с простоем магазина на день-два.
Что делать, чтобы заражение не вернулось
Если коротко — после очистки нужен не один шаг, а маленький план.
Вот рабочий минимум:
- Найти точку входа, а не только удалить вредоносный код.
- Сменить все доступы: WordPress, хостинг, FTP, база, почта.
- Обновить WordPress, плагины, тему, PHP.
- Удалить ненужные и заброшенные плагины и темы.
- Проверить пользователей, cron, uploads, mu-plugins, .htaccess.
- Проверить бэкапы перед восстановлением.
- Поставить мониторинг хотя бы на месяц после инцидента.
Звучит длинно. Но на деле для обычного корпоративного сайта это часто 2-4 часа нормальной работы. Не неделя. Просто делать надо не кусками и не “ну вроде открывается — значит ок”.
Итог
Если сайт заражается снова после “успешной” очистки, почти всегда причина одна: убрали последствия, но не убрали вход, источник или хвосты атаки.
Самая плохая стратегия тут — каждый раз просто удалять зараженные файлы и надеяться на лучшее. Так можно месяцами кататься по кругу и еще платить за это разным “специалистам”.
Нужен другой подход. Сначала понять, как залезли. Потом закрыть дыру. Потом уже чистить и наблюдать. Вот тогда есть шанс что сайт правда останется чистым, а не до следующего понедельника.
И да — если у вас сайт приносит заявки, продажи или записи клиентов, не тяните до очередного рецидива. После второго заражения это уже не “случайность”, а нормальный такой сигнал, что пора чинить все по взрослому.