Сайт заражён вирусом: что делать

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

Мы регулярно лечим взломанные сайты — в основном на WordPress, но принципы одинаковы для любой CMS. В этой статье разберём, по каким признакам распознать заражение, что владельцу сделать в первые часы, как выглядит нормальное лечение, как вернуть доверие Google и, главное, как закрыть дыру, чтобы история не повторилась.

Откуда берётся «вирус» на сайте

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

В наших проектах самые частые точки входа такие:

• Устаревшие плагины и темы. Разработчик уже выпустил исправление, но сайт не обновляли месяцами. Для ботов это открытая дверь.
• «Взломанные» (nulled) платные темы и плагины. Их скачивают с сомнительных сайтов, чтобы не платить за лицензию. Очень часто бэкдор уже вшит в такой архив.
• Слабые или повторяющиеся пароли к админке, хостингу, FTP. Пароль, который уже утёк с другого сервиса, проверяют первым.
• Заражённый компьютер кого-то из команды. Вредоносная программа крадёт сохранённые пароли FTP или панели хостинга, и злоумышленник заходит «легально».
• Забытые копии сайта. Папки вроде /old/, /test/, тестовые поддомены со старой версией CMS, которую никто не обновляет.
• Соседи по хостингу. На дешёвом виртуальном хостинге с плохо настроенными правами заражение может перейти с одного сайта на другой в пределах одного аккаунта.

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

• Редиректы — посетителей перебрасывают на казино, «розыгрыши», сомнительные магазины. Заработок на чужом трафике.
• SEO-спам — на сайте генерируются тысячи страниц или скрытых ссылок, чтобы продвигать чужие ресурсы за счёт вашего домена.
• Фишинг — в глубине сайта размещают поддельные страницы входа в банк или почту.
• Рассылки — сервер используют для массовой отправки спама, и страдает репутация вашей почты.
• Скиммеры — скрипт на странице оплаты перехватывает данные карт покупателей.

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

Признаки того, что сайт заражён

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

Что вы замечаете	Что это может означать	Где проверить
Перебрасывает на сторонние сайты, но не всегда	Условный редирект: только для мобильных, только из поиска или только при первом визите	Смартфон через мобильный интернет, переход из Google, окно инкогнито
Красный экран предупреждения в браузере	Сайт попал в списки Google Safe Browsing	Search Console, раздел «Проблемы безопасности»
Пометка «Этот сайт может быть взломан» в поиске	Google нашёл спамные страницы или подменённое содержимое	Поиск site:вашдомен, Search Console
В индексе тысячи страниц о лекарствах, казино, репликах	Спам-инъекция: страницы генерируются скриптом	Отчёт «Страницы» в Search Console, поиск site:
Хостинг заблокировал аккаунт или пишет о рассылке	Сайт рассылает спам или атакует другие серверы	Письма хостинга, почтовые логи, нагрузка на сервер
Новые администраторы, которых никто не создавал	Злоумышленник закрепился в админке	Список пользователей CMS

Другие тревожные сигналы: незнакомые PHP-файлы в папке загрузок, резкий рост нагрузки на сервер без роста посещаемости, письма с корпоративной почты, которые вдруг начали попадать в спам, странные скрипты на странице оформления заказа, внезапное падение органического трафика. Отдельно проверьте сайт именно на смартфоне: мобильная версия — это то, по чему вас оценивает Google, и именно там чаще всего «живут» скрытые редиректы. О важности мобильной версии мы подробно писали в статье «Как достичь успеха в mobile-first index».

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

Первые часы: что делать владельцу

Цель первых часов — не вылечить сайт, а остановить ущерб и ничего не испортить. Вот порядок, который мы рекомендуем:

1. Зафиксируйте, что видите. Скриншоты, адреса, время, откуда заходили, с какого устройства. Это поможет найти вредоносный код и понять, когда началось заражение.
2. Не удаляйте всё подряд и не восстанавливайте бэкап наугад. Поспешное удаление уничтожает следы, по которым можно найти точку входа. А бэкап может быть заражён так же, как живой сайт.
3. Сделайте полную копию текущего состояния — файлы и базу данных. Да, заражённую. Она нужна для анализа, и её нельзя использовать для восстановления.
4. Смените пароли с чистого устройства: панель хостинга, FTP/SFTP, база данных, администраторы CMS, почта, к которой привязан домен. Если есть сомнения в рабочем компьютере — используйте другой.
5. Ограничьте ущерб. Если сайт перебрасывает людей на мошеннические ресурсы или крадёт платёжные данные, лучше временно закрыть его страницей обслуживания, чем держать открытым.
6. Сообщите хостингу. Хороший хостинг ведёт логи доступа, может подсказать, что происходило, и проверить соседние сайты в аккаунте.
7. Для магазина — сообщите платёжному провайдеру, если есть подозрение, что затронута страница оплаты. Это не формальность: так вы защищаете покупателей и себя.

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

Чего точно не стоит делать: ставить пять «плагинов-антивирусов» одновременно, переносить заражённый сайт на другой хостинг, «чтобы начать с чистого листа», или ждать, пока «само пройдёт». Не пройдёт: вредоносный код, как правило, обновляется и закрепляется глубже.

Как лечат сайт: пошагово

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

Шаг 1. Диагностика

Сначала мы сравниваем файлы сайта с оригинальными: ядро CMS, плагины и темы можно сверить с официальными версиями тех же номеров. Всё, что отличается или не должно там находиться, — под подозрением. Дальше ищем недавно изменённые файлы, PHP-скрипты в папках, где их быть не должно (например, в загрузках), и типичные признаки замаскированного кода — длинные закодированные строки, вызовы вроде eval(base64_decode(...)), подключение файлов со странными названиями.

Отдельно проверяем базу данных. В WordPress вредоносный код часто сидит в таблице настроек, в тексте записей и виджетов, в запланированных задачах, а также прячется за скрытыми пользователями с правами администратора. Просматриваем .htaccess, конфигурационные файлы, задания cron на сервере. И обязательно — логи доступа, чтобы найти, через какой файл или какую форму зашёл злоумышленник.

Шаг 2. Очистка

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

Шаг 3. Закрытие уязвимости

Нашли, как злоумышленник попал внутрь, — закрываем именно этот путь. Обновляем всё устаревшее, включая версию PHP. Исправляем права на файлы и папки, запрещаем выполнение PHP в каталоге загрузок. Удаляем забытые копии сайта и тестовые поддомены.

Шаг 4. Замена всех ключей

Пароли вы уже сменили, но этого мало. Мы обновляем секретные ключи CMS (в WordPress это salts в wp-config.php), чтобы разлогинить все старые сессии, и перевыпускаем ключи API: платёжных систем, почтовых сервисов, CRM. Если злоумышленник видел конфигурацию, он видел и их.

Шаг 5. Повторная проверка

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

Иногда встаёт вопрос: лечить или восстанавливать из бэкапа? Сравнение вариантов:

Вариант	Когда подходит	Риски
Восстановление из бэкапа	Точно известно, когда началось заражение, и есть чистая копия старше этой даты	Потеря новых заказов и контента; без закрытия уязвимости сайт взломают снова
Ручное лечение	Сайт живой, изменения свежие, бэкапа нет или он сомнительный	Требует опыта: пропущенный бэкдор означает повторное заражение
Перенос на чистую установку	Заражение глубокое, сайт старый, плагинов много и половина не поддерживается	Дольше по времени, нужна проверка всего переносимого контента

После лечения: Google, почта и позиции

Чистый сайт ещё не означает, что посетители и поисковая система уже об этом знают. Этот этап часто пропускают, а потом удивляются, почему трафик не возвращается.

• Search Console. Если в разделе «Проблемы безопасности» есть сообщение, после очистки отправляем запрос на проверку с кратким описанием сделанного. Красный экран в браузере снимается после того, как Google подтвердит, что сайт чист.
• Спамные страницы. Сгенерированные адреса должны отдавать код 404 или 410. Перенаправлять их на главную не стоит: для Google это выглядит как подмена. Для ускорения их можно временно скрыть через инструмент удаления URL.
• Техническая гигиена. Проверяем карту сайта, robots.txt, canonical и hreflang — злоумышленники иногда меняют и их. Что из этого должно быть в порядке на здоровом сайте, мы описывали в материале «Внутренняя SEO-оптимизация сайта».
• Почта. Если сайт рассылал спам, проверяем, не попали ли IP сервера и домен в чёрные списки, и настраиваем SPF, DKIM и DMARC.
• Аналитика. Сравниваем трафик и конверсии до и после, чтобы увидеть реальный масштаб потерь.

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

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

Как не допустить повторения

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

• Регулярные обновления ядра, плагинов и тем — с тестированием на копии сайта, а не «нажать всё сразу в пятницу вечером».
• Минимум плагинов. Каждый лишний плагин — это и уязвимость, и нагрузка. Чистка лишнего заодно ускоряет сайт; этим мы занимаемся в рамках услуги оптимизации сайта.
• Только лицензионные темы и плагины из официальных источников.
• Двухфакторная аутентификация для всех администраторов и для панели хостинга.
• Уникальные пароли в менеджере паролей, отдельный аккаунт для каждого человека и минимальные права: копирайтеру не нужна роль администратора.
• SFTP вместо FTP и запрет редактирования файлов из админки (в WordPress — DISALLOW_FILE_EDIT).
• WAF — файрвол веб-приложений на уровне хостинга, CDN или плагина, который отсекает типовые атаки до того, как они дойдут до сайта.
• Бэкапы вне сервера с историей за несколько недель и регулярной проверкой, что из них действительно можно восстановиться.
• Мониторинг: контроль изменений файлов, проверка доступности, уведомления Search Console на почту, которую кто-то читает.

Технические меры работают, только когда за ними кто-то следит. Поэтому договоритесь, кто отвечает за безопасность сайта, и закрепите простой ритм: раз в неделю просматривать уведомления мониторинга и Search Console, раз в месяц планово обновлять всё на тестовой копии и переносить на рабочий сайт, раз в квартал проверять, что из бэкапа действительно можно восстановиться, и пересматривать список пользователей с доступом. Когда человек уходит из команды или заканчивается работа с подрядчиком, его доступы закрываются в тот же день.

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

Типичная ситуация из практики

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

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

Главный вывод этой истории не в том, что взлом был сложным. Он был типичным. Проблема в том, что в первый раз лечили симптом, а не причину: убрали видимый редирект, но оставили и старый плагин, и бэкдор, и чужого администратора.

Ошибки, которые затягивают лечение

1. Восстановить бэкап и считать проблему решённой. Без закрытия уязвимости это лишь отсрочка.
2. Удалить видимый вредоносный файл и остановиться. Бэкдоры обычно разложены в нескольких местах.
3. Сменить пароль только к админке. Хостинг, FTP, база, почта и ключи API остаются у злоумышленника.
4. Проверять сайт только с рабочего компьютера. Условные редиректы владельцу не показываются.
5. Не отправить запрос на проверку в Google. Сайт чист, а предупреждение висит неделями.
6. Вернуться к старым привычкам: nulled-тема, общий пароль на всю команду, обновления «когда-нибудь потом».

Короткий чек-лист

• Зафиксировать симптомы и сделать копию заражённого состояния.
• Сменить все пароли с чистого устройства, сообщить хостингу.
• Найти точку входа, заменить ядро и плагины чистыми копиями, почистить базу.
• Удалить бэкдоры, чужих пользователей, забытые копии сайта.
• Обновить всё, перевыпустить ключи CMS и API.
• Отправить запрос на проверку в Search Console, убрать спамные страницы из индекса.
• Настроить обновления, 2FA, WAF, внешние бэкапы и мониторинг.

Частые вопросы

Можно ли просто восстановить сайт из бэкапа?

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

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

Небольшой сайт с одним типом заражения обычно удаётся вылечить за день-два. Глубоко заражённому магазину со старыми плагинами может понадобиться несколько дней работы и последующее наблюдение. Снятие предупреждения Google занимает ещё какое-то время после запроса на проверку.

Поможет ли плагин-антивирус?

Как часть защиты — да: сканирование и WAF полезны. Но плагин работает внутри уже заражённой системы и не всегда видит бэкдоры, изменённые файлы сервера или вредоносный код в базе. Лечение — это ручная работа, а плагин — инструмент мониторинга после неё.

Повлияет ли заражение на позиции в Google?

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

Итог

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

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