Проверка веб сайтов на вирусы в Йошкар-Оле: последовательность лечения
В этой статье
- Симптомы, с которыми к нам приходят
- Шаг 1. Снять копию, ничего не удаляя
- Шаг 2. Найти, как именно попали внутрь
- Шаг 3. Сверить движок с оригинальной сборкой
- Шаг 4. Вычистить базу данных
- Шаг 5. Убрать шеллы и бэкдоры
- Шаг 6. Поменять доступы, закрыть уязвимость и проверить результат
- Что ещё уточняют клиенты
В Йошкар-Оле мы лечим сайты пищевых производств, мебельных фабрик, строительных компаний и учебных центров. Общее у них одно: ресурс сдавали несколько лет назад, обновлений с тех пор не было, и в какой-то момент автоматический бот нашёл в движке известную уязвимость. Дальше – подробный порядок работ, из которого нельзя выбросить ни один пункт.
Симптомы, с которыми к нам приходят
Хостинг предупреждает о нагрузке или блокирует аккаунт. Письма с домена перестают доходить. В поиске по названию компании появляются посторонние страницы. Посетители с телефонов сообщают о переадресации. Иногда единственный признак – сайт стал загружаться в два раза дольше, потому что чужой код выполняется при каждом обращении.
Шаг 1. Снять копию, ничего не удаляя
Архив файлов и дамп базы делаются до вмешательства. Это одновременно страховка и материал для расследования: даты изменения задают период взлома, найденные фрагменты кода служат образцом для поиска остальных копий по всему каталогу.
Шаг 2. Найти, как именно попали внутрь
По журналам веб-сервера и FTP выстраивается картина проникновения. Ищем обращения к файлам, которых нет в дистрибутиве, серии POST-запросов с одного адреса, загрузки через формы, входы в панель ночью. Пока причина не названа, всё дальнейшее – косметика.
Шаг 3. Сверить движок с оригинальной сборкой
Файлы ядра сравниваются по контрольным суммам с чистым дистрибутивом той же версии. Расхождения разбираются вручную: часть будет правками прошлого разработчика, часть – внедрённым кодом. Проверяются также папки загрузок и кеша, где исполняемый скрипт маскируется под картинку или временный файл.
Шаг 4. Вычистить базу данных
Инъекции в таблицах – причина большинства «повторных» заражений. Стандартный список находок:
- скрипты в текстах страниц, новостей и карточек продукции;
- скрытые ссылки в служебных блоках шаблона;
- лишние учётные записи администраторов;
- подменённые системные настройки движка.
Всё это удаляется адресными запросами, затем база проверяется ещё раз.
Шаг 5. Убрать шеллы и бэкдоры
Взломщик оставляет несколько путей возврата и задание в планировщике, которое восстанавливает удалённые файлы. Поэтому лечение – это не поиск одного вируса, а зачистка всей инфраструктуры доступа. Проверяем cron, права на каталоги, служебные конфигурации, соседние сайты на аккаунте хостинга.
Шаг 6. Поменять доступы, закрыть уязвимость и проверить результат
Новые пароли получают панель хостинга, FTP, SSH, пользователь базы, административная часть, почта восстановления и все ключи интеграций. Учётные записи, которыми давно никто не пользуется, удаляются. Без ротации взломщик просто входит заново, и предыдущие часы работы пропадают.
Обновляются движок и расширения, убирается неиспользуемый функционал, ограничиваются права на запись, при необходимости настраивается фильтрация запросов. Чистка без этого шага гарантирует повторное заражение. Через несколько дней сайт сканируется повторно, проверяется индекс и отдача страниц роботу, при санкциях отправляется заявка на пересмотр в Яндекс.Вебмастер и Search Console. Чтобы история не повторилась, движок должен обновляться планово – это входит в техническую поддержку, а просевшие позиции возвращают SEO-работы.
Что ещё уточняют клиенты
- Нужно ли уведомлять кого-то об утечке? Если пострадали данные клиентов, действуют требования 152-ФЗ, порядок подскажем.
- Вернёте старый дизайн после чистки? Внешний вид не меняется, удаляется только чужой код.
- Есть ли смысл лечить сайт, которому десять лет? Считаем два варианта: лечение с обновлением движка или разработку заново, решение остаётся за вами.
Позвоните по номеру +7 (917) 818-43-57 – начнём с бесплатной диагностики и покажем, что нашли.
