Что делать, если сайт показывает чужую рекламу или редиректит на казино

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

Открываете свой сайт с телефона, а вместо главной грузится онлайн-казино или сомнительная аптека. С компьютера всё в порядке, у вас в админке тоже. Знакомо. Это классика последних лет, у меня в работе таких случаев десятки за год. Ниже разберу, где именно прячется редирект в WordPress, Битрикс и OpenCart, почему он срабатывает только с мобильных или только из поиска и как вычистить так, чтобы он не вернулся через два дня.

Сначала зафиксируйте симптом, потом ищите

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

Опишите для себя три вещи:

• С каких устройств срабатывает редирект (только Android, только iOS, всё мобильное, любой браузер).
• С какого источника (прямой заход, переход из Яндекса, из Google, из соцсетей, из закладок).
• На какой URL уходит и есть ли там промежуточный шлюз с цепочкой 302-редиректов.

Самый простой способ зафиксировать переход — открыть Chrome DevTools на десктопе, переключить на эмуляцию мобильного устройства, в сетевой панели включить Preserve log и зайти на сайт по ссылке из выдачи. Если редирект включается только на реальном телефоне, заходите с него и снимайте скрин-видео экрана. На цепочке редиректов будет видно, кто отправляет первый Location: заголовок: ваш сервер, JS на странице или внешний скрипт.

Если редирект уходит на домен вида *.click, *.top, *.xyz или короткий редиректор типа bit.ly с подстановкой UTM-меток, это коммерческая малварь, которая зарабатывает на партнёрках. Хорошая новость: чистится по понятному алгоритму. Плохая: точка входа обычно открыта, и вернётся через сутки, если не закрыть.

Где сидит редирект в WordPress

В WordPress 8 случаев из 10 это одно из четырёх мест.

1. Файл .htaccess в корне

Самое первое, что нужно открыть. Чистый WordPress-овский .htaccess короткий, помещается на экран. Если в нём есть конструкции вида:

RewriteCond %{HTTP_USER_AGENT} (android|iphone|ipod|blackberry) [NC]
RewriteRule ^(.*)$ http://malicious-site.example/?ref=123 [L,R=302]

или условие на HTTP_REFERER с google|yandex|bing, это оно. Удаляйте всё, что не относится к стандартному блоку WordPress между # BEGIN WordPress и # END WordPress. Важно: бывает, что вредоносный фрагмент стоит ВЫШЕ блока WordPress, тогда он срабатывает раньше и съедает запросы до того, как Apache дойдёт до родных правил.

2. Опция в таблице wp_options

Откройте phpMyAdmin или Adminer, выполните:

SELECT option_name, option_value
FROM wp_options
WHERE option_value LIKE '%<script%'
   OR option_value LIKE '%base64_decode%'
   OR option_value LIKE '%eval(%';

Часто видим инъекцию в опциях widget_text, theme_mods_*, иногда в кастомных опциях популярных SEO-плагинов. Внутри лежит base64-обёрнутый JS, который добавляет редирект через window.location.replace() для определённого user-agent.

3. Файл темы header.php или footer.php

Откройте активную тему, посмотрите на длинные однострочники в начале файла. Подозрение должны вызвать:

• Длинная строка eval(base64_decode("...")) или eval(gzinflate(base64_decode("..."))).
• Подключение внешнего JS с домена, который вы не ставили.
• Конструкции с preg_replace и модификатором /e (PHP 7+ их уже не поддерживает, но в старых темах встречаются).

4. Внедрение в index.php корня или в wp-load.php

Самый поганый вариант: правка системных файлов WordPress. Простой способ проверить — сравнить чексуммы с эталонной сборкой:

cd /tmp
wget https://wordpress.org/latest.tar.gz
tar xzf latest.tar.gz
diff -r wordpress/ /var/www/yoursite/ | grep -v '^Only in'

Любые отличия в файлах ядра WordPress — сразу красный флаг.

Где сидит редирект в Битрикс

Битрикс по архитектуре более закрытый, но способов внедриться тоже хватает.

1. Файлы init.php и dbconn.php

В bitrix/php_interface/init.php злоумышленники любят повесить событие OnEpilog или OnBeforeProlog, которое для определённого user-agent вызывает LocalRedirect() на нужный URL. Открыли файл — читайте сверху вниз каждую строчку, ищите подключения через require_once в неожиданных местах и обработчики через AddEventHandler.

2. Папка /upload/

Это самое уязвимое место Битрикс. PHP-исполнение в /upload/ по умолчанию запрещено, но если разработчик когда-то открыл его через .htaccess, любой загруженный файл с расширением .php или замаскированным .phtml, .php5 становится бэкдором. Найти всё подозрительное:

find /var/www/site/upload -type f ( -name "*.php*" -o -name "*.phtml" ) -ls

Все находки удалить, в /upload/.htaccess дописать php_admin_flag engine off.

3. Кастомные компоненты

Если у вас стоят сторонние компоненты (особенно скачанные с непроверенных источников), смотрите в папке /local/components/ и /bitrix/components/<vendor>/<name>/component.php. Малварь любит маскироваться под безобидный вспомогательный класс с именем вроде _helper.php.

Где сидит редирект в OpenCart

OpenCart самый частый клиент по части мобильных редиректов из-за обилия неподдерживаемых шаблонов и модулей.

Приоритетные места проверки:

• catalog/controller/common/header.php — inject в самое начало, до class ControllerCommonHeader.
• system/library/template.php или system/library/cache/file.php — там часто прячут base64-полезную нагрузку.
• Таблица oc_setting с парсингом значений по LIKE '%eval%'.
• Папка image/cache/ с замаскированными PHP-файлами под видом ресайзов.

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

Это сделано намеренно по двум причинам.

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

Вторая: поисковые роботы Яндекса и Google в основном ходят с десктопного user-agent. Если редирект сработает на них, сайт мгновенно вылетит из выдачи и ценность ноль. Поэтому условие выглядит обычно так: показать редирект, если User-Agent содержит мобильную сигнатуру И Referer содержит поисковую систему. Идеальная мишень: реальный человек с телефона из поиска.

В коде это выглядит примерно так:

$ua = $_SERVER['HTTP_USER_AGENT'] ?? '';
$ref = $_SERVER['HTTP_REFERER'] ?? '';
if (preg_match('/android|iphone|ipad/i', $ua)
    && preg_match('/google|yandex|bing/i', $ref)) {
    header('Location: https://malicious-site.example/');
    exit;
}

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

curl -A "Mozilla/5.0 (Linux; Android 13)" 
     -e "https://www.google.com/" 
     -I https://yoursite.ru/

Если в ответе есть Location: на чужой домен — вот оно.

Алгоритм чистки за один заход

Не лечите по одной находке. Это ловушка: убрали из header.php, через сутки вернулось из бэкдора в /uploads/. Делайте всё в правильном порядке.

Шаг 1. Снять грязный бэкап

Перед любой чисткой сохраните дамп БД и tar файлов. Это ваше доказательство для разбора и страховка, если случайно снесёте что-то нужное.

mysqldump -u user -p dbname > /tmp/dirty-backup.sql
tar czf /tmp/dirty-files.tar.gz /var/www/yoursite/

Шаг 2. Закрыть сайт от посетителей

Поставьте заглушку или 503 Service Unavailable, чтобы посетители не успели поймать редирект, пока вы работаете. В .htaccess это:

ErrorDocument 503 /maintenance.html
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !=YOUR.IP.HERE
RewriteCond %{REQUEST_URI} !/maintenance.html$
RewriteRule .* - [R=503,L]

Шаг 3. Прогнать поиск по сигнатурам

Из консоли по всему дереву сайта:

grep -rEn "(eval(base64_decode|eval(gzinflate|preg_replace.*/e|@include(.*$_)" 
  --include="*.php" /var/www/yoursite/

Каждое совпадение открывайте руками, не доверяйте автоматике на 100%. Иногда base64_decode стоит в легитимном плагине для работы с картинками. Глазом видно за минуту, что внутри: декодированный код или просто base64-encoded JSON конфига.

Шаг 4. Сравнить ядро CMS с эталоном

Для WordPress — выкачали свежую сборку, прогнали diff. Для Битрикс — есть скрипт верификации в bitrix/admin/security_check.php. Для OpenCart — сверка с git-репозиторием по вашей версии.

Шаг 5. Проверить базу данных

Не только wp_options, но и таблицы постов, виджетов, настроек темы. Запросы примерно те же:

SELECT * FROM wp_posts WHERE post_content LIKE '%<script%' AND post_status = 'publish';
SELECT * FROM wp_postmeta WHERE meta_value LIKE '%base64_decode%';

Шаг 6. Сменить все пароли и ключи

После чистки обязательно:

• Пароли всех админов CMS (минимум 16 символов, генерируйте, не придумывайте).
• Пароль FTP, SSH, MySQL.
• Соль и ключи в wp-config.php (генератор есть на api.wordpress.org/secret-key).
• Если был украден файл с токенами API (Telegram, SMS-агрегатор, платёжка), отозвать и перевыпустить.

Шаг 7. Открыть сайт обратно и протестировать

Снять заглушку, прогнать тот же curl с мобильным UA и поисковым Referer. Если Location чистый — переходите к закрытию точки входа.

Почему важно закрыть точку входа

Самая частая ошибка владельцев и неопытных подрядчиков: вычистили все редиректы, открыли сайт, а через два-три дня малварь вернулась. Объяснение простое: вы убрали последствия, а не причину.

Точка входа — это уязвимость, через которую злоумышленник попал на сайт первый раз. Вариантов немного:

Категория	Конкретика	Что закрыть
Старая CMS	WordPress 5.x, Битрикс 22.x, OpenCart 3.0.0	Обновить ядро до текущей версии
Старый плагин	Брошенный плагин с CVE 2-3 летней давности	Удалить или заменить на поддерживаемый
Слабый пароль	admin/admin, пароль из словаря	Сложный пароль + 2FA
Открытый /uploads	Исполнение PHP в папке загрузок	php_admin_flag engine off
Утечка через FTP	Старый FTP-аккаунт с паролем в FileZilla	Сменить пароль, перевести на SSH-ключи

Без закрытия точки входа вы будете чистить редиректы каждые две недели. Это не работа подрядчика, это сизифов труд.

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

ls -la --time=ctime /var/www/yoursite/wp-content/themes/ | sort -k 6,8
grep -E "POST .*.(php|aspx)" /var/log/apache2/access.log | head -100

Ищите подозрительные POST-запросы из одних и тех же IP, обращения к редко используемым endpoint, запросы с пустым User-Agent или странными именами ботов.

Чек-лист после чистки

После того как редирект ушёл и точка входа закрыта, пройдите этот список:

• [ ] Установлен файрвол уровня приложения (Wordfence для WP, ModSecurity на сервере, Cloudflare WAF).
• [ ] Включено двухфакторное подтверждение для всех админов.
• [ ] Настроены автоматические бэкапы вне сервера (хотя бы раз в сутки, хранение 30 дней).
• [ ] Выключено редактирование файлов через админку (define('DISALLOW_FILE_EDIT', true); в wp-config.php).
• [ ] Закрыт xmlrpc.php и доступ к wp-admin/ по списку IP, если возможно.
• [ ] Поставлен мониторинг изменений файлов (file integrity monitoring) с уведомлением в Telegram.
• [ ] Подал запрос на пересмотр в Я.Вебмастере и Google Search Console, если сайт уже отметили.

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

Когда имеет смысл звать подрядчика

Если у вас сайт на копеечном shared-хостинге, без SSH-доступа, без бэкапов и без понимания, где смотреть, разовая чистка вирусов у нормального специалиста стоит обычно от 8 до 25 тысяч рублей в зависимости от размера сайта и глубины заражения. Это разовая работа.

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

Если хочется глубже погрузиться в тему безопасности сайта, в рубрике Безопасность есть статьи про признаки взлома, ручную чистку WordPress и снятие пометки опасный сайт.

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

Что делать, если сайт редиректит на казино

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

Почему редирект видно только с телефона

Потому что он проверяет тип устройства и источник перехода. Так заражение живёт дольше: владелец заходит с компьютера напрямую и ничего не замечает месяцами.

Где чаще всего прячется код

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

Сколько стоит чистка

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