Как проверить сайт на вирусы и закрыть дыры в защите

О том, что сайт взломали, владелец обычно узнаёт последним. Сначала Google помечает ресурс как опасный, потом хостинг блокирует аккаунт за рассылку спама, а уже потом кто-то из клиентов пишет: «у вас там реклама казино выскакивает».

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

Как обычно ломают сайты

Забудьте о хакере, который целенаправленно атакует именно вас. В 95% случаев всё прозаичнее: боты непрерывно обходят интернет и проверяют сайты на известные уязвимости. Нашли устаревший плагин — залили вредоносный код. Дальше сайт используют не против вас, а как ресурс: для рассылки спама, редиректа посетителей на партнёрские страницы или скрытого майнинга.

Три самые частые двери, через которые заходят:

• Устаревший плагин или тема. Самый распространённый вариант в WordPress. Уязвимость публикуют, и через несколько часов боты уже проверяют все сайты мира.
• Украденный пароль. Часто не с вашего сайта, а с другого сервиса, где вы использовали тот же. Или с заражённого компьютера через FTP-клиент, который хранит пароли в открытом виде.
• Открытый служебный файл. Об этом ниже отдельно — это недооценённая и очень дешёвая для злоумышленника лазейка.

Шаг 1. Просканировать код на вредоносные сигнатуры

Откройте проверку сайта на вирусы и вставьте адрес. Инструмент анализирует код главной страницы на характерные признаки заражения:

• eval(atob(...)) — выполнение закодированного кода. В нормальном сайте такого не бывает почти никогда;
• скрытые iframe нулевого размера — классический способ подгрузить чужую страницу незаметно;
• майнеры криптовалюты, которые грузят процессор посетителя;
• обфусцированный JavaScript с переменными вроде _0x4f2a — код намеренно сделан нечитаемым;
• редиректы на сторонние домены через window.location.

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

Шаг 2. Проверить, не лежат ли в открытом доступе служебные файлы

Это то, что мы находим чаще вирусов, и что даёт злоумышленнику больше, чем любой взлом.

Тот же инструмент проверяет доступность типичных адресов. Самые опасные два:

Файл .env — в нём обычно лежат пароли к базе данных, ключи платёжных систем и токены API в открытом виде. Если он открывается по прямой ссылке, ломать ничего не надо: человек просто открывает адрес и читает ваши ключи.

Папка .git/config — через неё можно восстановить весь исходный код сайта вместе с историей изменений. А в истории часто лежат пароли, которые когда-то закоммитили, а потом удалили — из рабочей копии они исчезли, из истории нет.

Кроме них проверяются wp-config.php.bak, backup.zip, dump.sql, phpinfo.php и листинг папок. Каждый из этих файлов — отдельная история о том, как «временно положил и забыл».

Если что-то нашлось, закрывайте немедленно на уровне веб-сервера, а не просто переименовывайте: боты перебирают и варианты имён.

Шаг 3. Посмотреть на заголовки безопасности

Проверка безопасных заголовков показывает, какие защитные механизмы включены. Самые важные четыре:

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

Шаг 4. Проверить SSL-сертификат

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

Проверка SSL показывает эмитента и количество дней до окончания. Поставьте напоминание за две недели до даты — даже автоматическое обновление Let’s Encrypt иногда ломается после изменения конфигурации сервера, и об этом узнают уже от клиентов.

Шаг 5. Навести порядок с паролями и доступами

Самое слабое звено почти всегда здесь. Минимум, который стоит сделать:

• Убрать учётную запись admin — именно её перебирают боты в первую очередь. Создайте нового администратора с другим именем, а старого удалите.
• Заменить пароли, которые совпадают с паролями от других сервисов. Сгенерировать надёжные можно генератором паролей.
• Включить двухфакторную аутентификацию в админке, если CMS это умеет.
• Проверить список пользователей. Лишний администратор, которого вы не создавали — главный признак, что сайт уже взломали.
• Закрыть тестовые версии сайта паролем на уровне сервера. Это делается генератором .htpasswd и заодно спасает от индексации черновиков поисковиками.

Что делать, если заражение уже произошло

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

1. Сменить все пароли. Хостинг, FTP, SSH, админка, база данных. Сначала это, потому что заражение обычно начинается именно с украденного доступа.
2. Развернуть чистую резервную копию — сделанную до даты заражения. Как настроить бэкапы, чтобы такая копия всегда была, мы разбирали в статье о резервном копировании.
3. Обновить CMS и все расширения. Если этого не сделать, вас взломают тем же способом на следующей неделе.
4. Проверить список пользователей админки и удалить чужие учётные записи.
5. Проверить запланированные задачи (cron) — злоумышленники оставляют там скрипт, который восстанавливает заражение.
6. Отправить сайт на проверку в Google Search Console, если он попал под пометку опасного. Без этого предупреждение в браузере останется даже после чистки.

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

Чек-лист: десять минут раз в месяц

1. Сканирование на вредоносный код — сигнатуры и служебные файлы.
2. Заголовки безопасности — как минимум HSTS и X-Frame-Options.
3. SSL — больше двух недель до окончания.
4. Список пользователей админки — ни одного лишнего.
5. Обновления CMS и плагинов — всё актуальное.

Это не отнимает времени, зато находит проблему до того, как её найдёт Google. Остальные проверки — скорость, индексация, почта — собраны в нашем каталоге из 43 инструментов.

Если сайт уже ведёт себя странно, а разобраться самостоятельно сложно — напишите нам, посмотрим.