Вредоносные редиректы — это явный и критический признак компрометации сайта. Хакеры используют их для перенаправления вашего трафика на фишинговые, фармакологические или мошеннические ресурсы. С точки зрения SEO, это немедленно приводит к ручному или алгоритмическому наказанию от поисковых систем, потере доверия пользователей и полному обрушению органического трафика.
Для эксперта, удаление редиректов — это не просто удаление одной строки кода, а комплексная операция, требующая обнаружения корневой уязвимости (Root Cause) и её немедленного устранения.
1. Фаза 1: Диагностика и Изоляция (Где искать)
Прежде чем приступать к чистке, необходимо точно определить, где и как происходит перенаправление, а также изолировать угрозу.
1.1. Инструменты обнаружения
Вредоносные редиректы часто используют клоакинг (cloaking), показывая чистый контент поисковым роботам (Googlebot) и вредоносный контент реальным пользователям.
- Google Search Console (GSC):
- Проверьте раздел «Безопасность и меры, принятые вручную» (Security & Manual Actions). Наличие здесь предупреждения — это официальный сигнал о взломе.
- Используйте инструмент «Проверить URL» (URL Inspection). Запустите проверку, и GSC покажет, видит ли робот чистую страницу (код 200) или редирект (код 302/307).
- DevTools (Инструменты разработчика):
- Откройте браузер, нажмите
F12, перейдите на вкладку Network (Сеть). - Снимите галочку с Disable cache (Отключить кеш).
- Загрузите скомпрометированную страницу. Вы увидите весь цепочку редиректов (Redirect Chain): какой URL инициировал редирект, какой код ответа (
301,302,307) был использован.
- Откройте браузер, нажмите
1.2. Основные точки инъекции
Хакерский код чаще всего внедряется в одном из четырех мест:
| Вектор | Типичный признак | Как обнаружить |
|---|---|---|
| Веб-сервер | Модификация .htaccess, httpd.conf | RewriteRule с Base64 или HTTP_REFERER. |
| CMS-база данных | Изменённые URL в таблицах options, settings. | SQL-запросы в таблицах опций CMS. |
| PHP-скрипты | Внедрение header('Location: ...') или eval(base64_decode(...)) | Поиск по ключевым словам в коде. |
| JavaScript | Скрипты с window.location.replace или fetch на вредоносные домены. | Поиск в .js файлах или в <head> HTML-шаблона. |
2. Фаза 2: Удаление кода (Методическая чистка)
После обнаружения источника необходимо перейти к удалению вредоносного кода. Всегда делайте полный бэкап системы перед началом чистки.
2.1. Очистка файла .htaccess (Критический шаг)
Файл .htaccess — самый частый источник редиректов, так как он выполняется на уровне веб-сервера. Хакеры часто добавляют код в начало или конец файла.
Что искать:
RewriteEngine On: Второе включение этого модуля или сложная серия правилRewriteRule.- Обфускация: Строки, содержащие
base64_decodeили длинные, нечитаемые конструкции, которые используют переменные HTTP-заголовков. - Условные правила: Правила, использующие
%{HTTP_REFERER},%{REQUEST_URI}или%{HTTP_USER_AGENT}для маскировки (клоакинга).
Пример вредоносного кода:
# Вредоносный код, часто в конце или в начале
<IfModule mod_rewrite.c>
RewriteEngine On
# Если пользователь не Googlebot, перенаправить его
RewriteCond %{HTTP_USER_AGENT} !(google|bot|slurp|yahoo) [NC]
RewriteRule ^(.*)$ [https://malicious-site.com/hacked-link](https://malicious-site.com/hacked-link) [L,R=302]
</IfModule>
# КОНЕЦ ВРЕДОНОСНОГО КОДА
Решение: Удалите весь лишний код и замените файл .htaccess чистой версией из официальной установки вашей CMS (например, чистый .htaccess для WordPress).
2.2. Поиск инъекций в PHP-файлах
Вредоносный код часто внедряется в файлы, которые выполняются при каждой загрузке страницы:
index.phpwp-config.php(для WordPress)header.php/footer.php(файлы шаблонов)functions.php(особенно в темах CMS)
Экспертный поиск через Bash (для Linux/UNIX): Используйте команду grep для поиска подозрительных функций в корневых директориях:
# Поиск обфусцированных функций и перенаправлений
grep -r -E "eval\(|base64_decode|gzinflate|header\('Location" /var/www/html/
# Поиск внешних URL, которые не должны быть в вашем коде
grep -r "http://" /var/www/html/ | grep -v "yourdomain.com"
Решение: Сравните зараженный файл с чистой версией из официального репозитория или бэкапа. Удаляйте только те строки, которые не соответствуют эталону.
2.3. Очистка базы данных (для CMS)
Если редирект происходит после загрузки страницы, хакер, вероятно, изменил настройки в базе данных.
Для WordPress:
- Проверьте
wp_options: Ищите изменения в поляхsiteurlиhome. - Проверьте пользователей: Ищите новых подозрительных администраторов.
- Проверьте контент: Ищите внедренные
<script>теги или<iframe>в поляхpost_contentилиpost_excerpt.
Пример SQL-запроса для поиска подозрительных ссылок:
SELECT * FROM wp_posts WHERE post_content LIKE '%malicious-site.com%';
3. Фаза 3: Устранение уязвимостей и Защита (Предотвращение повтора)
Чистка — это устранение симптомов. Если вы не найдете и не устраните корневую причину, редиректы вернутся в течение нескольких часов или дней.
3.1. Устранение корневой причины
- Обновление ВСЕГО: Немедленно обновите до последней версии CMS (WordPress, Joomla, Drupal), все плагины, темы и серверное ПО (PHP, MySQL). Устаревшее ПО — это уязвимость №1.
- Смена учетных данных: Смените все пароли: для администратора CMS, FTP, SSH, и базы данных. Используйте длинные, сложные пароли.
- Удаление лишнего: Удалите все неиспользуемые плагины и темы, которые могли служить точкой входа.
3.2. Укрепление разрешений (Permissions Hardening)
Неправильные права доступа (777 или 666) позволяют хакерам перезаписывать файлы после взлома.
- Файлы: Установите права
644для всех файлов. - Папки: Установите права
755для всех папок. - Конфиги: Для критических файлов (например,
wp-config.php) используйте максимально строгие права400или440.
# Пример установки правильных прав в корневой директории сайта
find /var/www/html/ -type d -exec chmod 755 {} \;
find /var/www/html/ -type f -exec chmod 644 {} \;
3.3. Внедрение FIM и Сканеров
После чистки необходимо настроить постоянный мониторинг, чтобы немедленно обнаружить повторное заражение.
- FIM (Мониторинг целостности файлов): Используйте систему, подобную той, что мы обсуждали в предыдущем гайде (Bash/Cron + SHA-256), для контроля изменений в ключевых файлах.
- Web Application Firewall (WAF): Установите WAF (например, Cloudflare, ModSecurity), чтобы блокировать известные векторы атаки, такие как SQL-инъекции и XSS.
- Сканеры: Регулярно запускайте серверные сканеры (например, Maldet или ClamAV) для поиска известных вредоносных сигнатур.
4. Заключение и Метаданные
Удаление вредоносных редиректов требует методичного подхода: диагностика (DevTools/GSC), хирургическое удаление вредоносного кода из .htaccess, PHP-файлов и базы данных, и, самое главное, устранение корневой уязвимости. Только после устранения уязвимости и укрепления прав доступа можно гарантировать долгосрочную безопасность. Не забудьте после чистки запросить повторную проверку в GSC, чтобы снять ручные санкции.
