Сканер безопасности пометил наш сайт как зараженный — реальный взлом или ложная тревога?

Проверять сайт только со своего компа через обычный браузер бесполезно. Злоумышленники почти всегда настраивают клоакинг: редиректы срабатывают только при переходе из поисковиков или строго на мобилках. Делайте чистые curl-запросы к серверу через терминал, подменяя User-Agent и Referer, и сравнивайте отдачу. Скрытый base64 в теле ответа так спалить намного проще.

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

В прошлом году у нас была похожая паника. Онлайн-сканер выдал, что сайт попал в черный список, и посыпались предложения от сервисов почистить всё за 800 долларов. Начали разбираться глубже — оказалось, предупреждение вылезло из-за просроченного сертификата у плагина онлайн-чата. Заплатили разработчику 40 долларов за обновление скрипта и решили проблему без лишних трат.

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

Какое именно имя файла или URL сканер пометил как вредоносный в отчете? И еще: ставили ли на сайт за последние пару недель новые плагины, платежные формы или сторонние маркетинговые пиксели? Без этих деталей сложно понять, ложная это тревога или реальный взлом.

Когда клиенты начинают жаловаться, это неприятно но главное — без паники. Если в Google Search Console красной плашки еще нет трафик мгновенно не рухнет. Тем не менее сразу же смените все пароли и вместе с разработчиком построчно проверьте файлы. Без суеты этот вопрос можно закрыть за полдня.

у нас тоже такое было сканер тупо код аналитики за вирус принял. ну не ведитесь сразу на панику и не скупайте дроогущие тарифы безопасности потом гляньте логи если левых запросов с мутных ip нет то скорее всего ложняк.

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

Слежу за темой.

Извините, но это верно не во всех случаях. Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.

Если напишете результат здесь, это поможет и другим.

Мои сомнения развеялись, спасибо.

Отличная работа. Чем сложнее отменить решение, тем медленнее его принимайте.

Интересно, есть ли те, кто делает иначе.

Я маленький бизнес, расскажу со своей стороны. Главное не цифра, а то, на основе чего она получена.

Не полагайтесь на одну меру защиты; действуйте слоями.

Вы правы.

У нас было так. Непроверенная резервная копия — не резервная копия.

Если напишете результат здесь, это поможет и другим.

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

Не полагайтесь на одну меру защиты; действуйте слоями. Если напишете результат здесь это поможет и другим.

я столкнулся с тем же два года назад. если разрешение и объем тестирования не зафиксированы письменно, тест не начинать.

конечно, если ваша ситуация отличается, всё меняется.

Посмотрю с другой стороны, я на стороне поставщика. Главное не цифра, а то, на основе чего она получена.

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