Вопрос сайты на WP стали редиректить на сторонние сайты ( при переходе с поисковика )

[Di Ost]

Доброго времени суток форумчане, столкнулся с такой проблемой, на сопровождении около 60+ сайтов, в один момент стали редиректиться на стороние спам сайты ( причем сайты всегда разные ), первым делом я взял самый простой сайт где 2-3 плагина и начал отключать - редиректы пропали. Стал отключать этот плагин на других сайтах на некоторых редирект не пропал. На данный момент нашел решение - обновление версии ВП + обновление плагинов. Хотел поинтересоваться у Вас такой беды не было за последний месяц - полтора ?

P.S. Важно! - редирект происходит если на сайт попадают с поисковой системы, если зайти напрямую редиректа нет.

 

[edgars2212]

Здравствуйте!

Ситуация, которую вы описали, характерна для случаев взлома WordPress-сайтов. Редиректы на сторонние спам-сайты, особенно при переходе с поисковых систем, чаще всего указывают на инфекцию в коде сайта или базе данных. Давайте разберем вашу ситуацию по шагам:

Возможные причины и источники проблемы:

1. Уязвимости в плагинах или теме: Старые версии плагинов и тем часто становятся целью хакеров. Если обновление помогло, это может быть причиной.
2. Вредоносный код в файлах сайта: Инъекции кода в файлы WordPress, такие как functions.php, index.php или даже в системные файлы ядра.
3. Инфекция базы данных: Хакеры могут добавлять вредоносный JavaScript или ссылки на сторонние сайты в базу данных (например, в таблицу wp_options или wp_posts).
4. Доступ через FTP или хостинг: Если ваши учетные данные скомпрометированы, злоумышленники могли получить доступ напрямую к серверу.

Шаги по устранению и предотвращению проблемы:

1. Проверка файлов сайта:
   • Скачайте сайт через FTP и выполните сканирование с помощью антивирусных инструментов, таких как Для просмотра ссылки Войди или Зарегистрируйся или Для просмотра ссылки Войди или Зарегистрируйся.
   • Ищите подозрительные строки в PHP-файлах, такие как base64_decode, eval, gzuncompress, или неизвестные скрипты.
2. Анализ базы данных:
   • Используйте инструмент для работы с базой данных, например, phpMyAdmin.
   • Проверьте таблицы wp_posts, wp_options и wp_usermeta на наличие инъекций вредоносного кода (обычно это длинные строки кода JavaScript).
3. Обновление WordPress, тем и плагинов:
   • Убедитесь, что все установлено в последней версии. Используйте проверенные плагины из официального каталога WordPress.
   • Удалите неиспользуемые плагины и темы.
4. Проверка доступа к сайту:
   • Смените все пароли: от FTP, панели управления хостингом, админки WordPress.
   • Убедитесь, что у вас настроен безопасный доступ через SFTP/SSH.
5. Настройка защиты:
   • Установите плагин безопасности, например, Wordfence или iThemes Security.
   • Добавьте файл .htaccess для ограничения доступа к административным страницам:

<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from [ВАШ_IP]
</Files>

1. Сканирование хостинга:
   • Свяжитесь с вашим хостинг-провайдером. У них могут быть дополнительные инструменты для проверки серверных файлов.
2. Проверка внешних ссылок:
   • Используйте инструменты типа Google Search Console для проверки отчетов о вредоносных URL. Если Google зафиксировал проблему, она отобразится в разделе "Проблемы безопасности".

Рекомендации на будущее:

• Регулярные резервные копии. Используйте инструменты типа UpdraftPlus или хостинговые сервисы.
• Мониторинг файлов. Плагины вроде Wordfence уведомляют об изменениях в файлах.
• Защита административной панели. Ограничьте доступ по IP или настройте двухфакторную аутентификацию.

Ваш случай (редирект только при переходе с поиска):
Это часто связано с кодом, добавленным для маскировки. Проверьте файлы шаблонов, такие как header.php или functions.php, на наличие условий вроде:

if (strpos($_SERVER['HTTP_REFERER'], 'google.com')) {
    header("Location: http://вредоносный-сайт.com");
    exit;
}

Удачи в решении проблемы! Если потребуется помощь с конкретным кодом или анализом логов, напишите!​

 

[Di Ost]

Здравствуйте!

Ситуация, которую вы описали, характерна для случаев взлома WordPress-сайтов. Редиректы на сторонние спам-сайты, особенно при переходе с поисковых систем, чаще всего указывают на инфекцию в коде сайта или базе данных. Давайте разберем вашу ситуацию по шагам:

Возможные причины и источники проблемы:

1. Уязвимости в плагинах или теме: Старые версии плагинов и тем часто становятся целью хакеров. Если обновление помогло, это может быть причиной.
2. Вредоносный код в файлах сайта: Инъекции кода в файлы WordPress, такие как functions.php, index.php или даже в системные файлы ядра.
3. Инфекция базы данных: Хакеры могут добавлять вредоносный JavaScript или ссылки на сторонние сайты в базу данных (например, в таблицу wp_options или wp_posts).
4. Доступ через FTP или хостинг: Если ваши учетные данные скомпрометированы, злоумышленники могли получить доступ напрямую к серверу.

Шаги по устранению и предотвращению проблемы:

1. Проверка файлов сайта:
   • Скачайте сайт через FTP и выполните сканирование с помощью антивирусных инструментов, таких как Для просмотра ссылки Войди или Зарегистрируйся или Для просмотра ссылки Войди или Зарегистрируйся.
   • Ищите подозрительные строки в PHP-файлах, такие как base64_decode, eval, gzuncompress, или неизвестные скрипты.
2. Анализ базы данных:
   • Используйте инструмент для работы с базой данных, например, phpMyAdmin.
   • Проверьте таблицы wp_posts, wp_options и wp_usermeta на наличие инъекций вредоносного кода (обычно это длинные строки кода JavaScript).
3. Обновление WordPress, тем и плагинов:
   • Убедитесь, что все установлено в последней версии. Используйте проверенные плагины из официального каталога WordPress.
   • Удалите неиспользуемые плагины и темы.
4. Проверка доступа к сайту:
   • Смените все пароли: от FTP, панели управления хостингом, админки WordPress.
   • Убедитесь, что у вас настроен безопасный доступ через SFTP/SSH.
5. Настройка защиты:
   • Установите плагин безопасности, например, Wordfence или iThemes Security.
   • Добавьте файл .htaccess для ограничения доступа к административным страницам:

<Files wp-login.php>
    Order Deny,Allow
    Deny from all
    Allow from [ВАШ_IP]
</Files>

1. Сканирование хостинга:
   • Свяжитесь с вашим хостинг-провайдером. У них могут быть дополнительные инструменты для проверки серверных файлов.
2. Проверка внешних ссылок:
   • Используйте инструменты типа Google Search Console для проверки отчетов о вредоносных URL. Если Google зафиксировал проблему, она отобразится в разделе "Проблемы безопасности".

Рекомендации на будущее:

• Регулярные резервные копии. Используйте инструменты типа UpdraftPlus или хостинговые сервисы.
• Мониторинг файлов. Плагины вроде Wordfence уведомляют об изменениях в файлах.
• Защита административной панели. Ограничьте доступ по IP или настройте двухфакторную аутентификацию.

Ваш случай (редирект только при переходе с поиска):
Это часто связано с кодом, добавленным для маскировки. Проверьте файлы шаблонов, такие как header.php или functions.php, на наличие условий вроде:

if (strpos($_SERVER['HTTP_REFERER'], 'google.com')) {
    header("Location: http://вредоносный-сайт.com");
    exit;
}

Удачи в решении проблемы! Если потребуется помощь с конкретным кодом или анализом логов, напишите!​

Благодарю за столь подробную информацию, но эти меры принимаются еще на базе сборки сайта, немного о моих проектах, сайты собираются на моей собственной кастомной теме ( ресетовая тема, по сути заранее прикрепленые файлы лес и базовые функции разбиты по файлам как мне удобно + экранирование рест апи и тп ), в этой теме все страници изначально занулены ( тобиш которые не используются содержат базовую функцию тайт+контент+редирект на основную страницу сайта ) и уже по мере надобности и тз накидываю произвольные типы записей + произвольные поля или ленды на вп бэкэри и тд )

Вот нюансы по лечению сайтов:
1. Один сайт был вылечен от редиректа обновлением ВП ( была ~18 года верссию не скажу ) до последней версии + замена плагина Types 3.4 на Post Type Builder 1.2.8
2. Другой сайт бы пролечен обновлением ВП ( ~22 года версию не скажу ) + обновлением плагина WPBakery Page Builder 6.7.0 на туже версию
3. Сайт был обновлен до последней версии ( была примерно 21-22 года ) ВП и проблема была в плагине Post Type Builder 1.2.8, заменил его на Post Type Builder 1.2.8 и проблема решилась.

Да я знаю о проблемах, когда долго ВП не обновляется потом прилетает, но меня смутило вот что, на хостинге я установил голый ВП + родная дефолтная тема и через какое то время случился редирект ( уже воюю с службой поддержки хостинга т.к. ощущение, что сидит в контейнере \ процесах )

Вот нюансы поведения вирусов:
1. Не всегда срабатывает редирект ( иногда сайт себя ведет обычно )
2. Большая активность в ночное время ( днем было так, что сайты спокойно открываются как ни в чем не бывало )
3. Редиректы происходят на разные сайты
4. Я бы согласился, что проблема в плагине\вп\бд\теме но они везде разные и самое что важное устанавливался голый вп ( дистрибутив с офф сайта ) + родная тема ( от туда же при установке ) и через некоторое время он тоже редиректил, там отключать нечего вообще голый ВП
5. На локальном ПК и у другого хостера сайт ведет себя обычно

Так же сайты имею разные плагины и версии, по ощущениям, что на срабатывание ПХП скрипта тригирит апачь хостинга \ блуждающий процесс и редиректит

И Самое важное что не сказал, с прямого запроса редиректов практически нет, срабатывает если прилетают юзерагентские даные что был совершен переход с поисковой системы.

Убедится вы можете на этом сайте ( его еще не трогал ) ( ОСТОРОЖНО САЙТ С ВИРУСОМ ) на анонимной вкладке в поисковой яндекса вбейте "обереги велимиров" и и пройдите на сайт velimirov.ru ( повторюсь редирект не всегда срабатывает и бывает так, что после прямого входа переходы с поисковиков не тригирят редирект ) ВАЖНО что сайт на который редиректит ( они все разные ) часто прописывает свои куки по этому ТОЛЬКО с анонимной вкладки, что бы небыло кражи данных.

 

[edgars2212]

Спасибо за уточнения! Ваши дополнительные подробности дают более четкое представление о проблеме. Давайте разберем ситуацию и предложим возможные причины и решения.

Анализ проблемы

1. Редиректы происходят на разные сайты — это указывает на случайные или динамические редиректы, которые могут быть связаны с вредоносным кодом, скрытым на сервере или в процессе работы веб-сервера (например, в Apache).
2. Редирект с поисковых систем — это важная деталь. Проблема может быть связана с определенными запросами или куки, которые устанавливаются на основе реферера (например, переход с поисковиков). Вредоносные скрипты могут отслеживать реферер и активировать редирект в зависимости от этого.
3. Действия только на хостинге — если локально и у другого хостера все работает нормально, это наводит на мысль, что проблема может быть связана с сервером или его конфигурацией.
4. Скачивание куков на редиректящих сайтах — это может свидетельствовать о том, что вредоносный код устанавливает куки для отслеживания или повторной активации редиректов при следующем посещении.

Возможные причины и решения
1. Уязвимость на сервере или в Apache
Возможно, сервер или конфигурация Apache может иметь уязвимости, которые позволяют выполнять вредоносные скрипты или PHP-инъекции. Также это может быть связано с серверным кешированием или настройками .htaccess, которые настраивают редиректы.

Решения:

• Проверьте серверные логи, чтобы выявить подозрительные активности или PHP ошибки. Это поможет увидеть, что вызывает редиректы.
• Убедитесь, что у вас настроены правила безопасности на уровне сервера. Например, ограничьте доступ к административной части сайта через .htaccess или через настройки IP.
• Настройте сервер для защиты от инъекций через Apache. Например, используйте защиту от скриптов, которые могут быть запущены через GET-запросы или другие нестандартные методы.

2. Вредоносный код в базе данных
Если проблема возникает даже с чистой установкой WordPress, возможно, вредоносный код был инъецирован в базу данных (например, через изменения в таблицах wp_options, wp_postmeta, или wp_posts), который реагирует на реферер или определенные условия.

Решения:

• Проверьте базу данных на наличие необычных записей или ссылок на внешние сайты в таблицах, связанных с контентом (например, wp_posts, wp_options).
• Проверьте таблицу wp_options на наличие аномальных записей, особенно тех, которые могут быть связаны с перенаправлениями.
• Используйте инструмент для поиска и удаления вредоносного кода в базе данных, такой как Для просмотра ссылки Войди или Зарегистрируйся или Для просмотра ссылки Войди или Зарегистрируйся.

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

Решения:

• Попробуйте отключить все плагины на чистом WordPress (не используя свою кастомную тему) и протестировать. Если редирект все равно появляется, то это скорее всего проблема в серверной части.
• Используйте мониторинг серверных процессов, чтобы выявить активные или необычные процессы. Это можно сделать через панель управления хостинга или с помощью инструментов вроде top или ps на сервере.

4. Рефереры и использование куков
Это может быть связано с использованием специальных куков или сессий, которые вредоносный код использует для отслеживания пользователей.

Решения:

• Проверьте, какие куки создаются сайтом, и попробуйте очистить их с помощью плагинов безопасности.
• Используйте функции для управления сессиями и защиты от манипуляций с реферерами (например, добавьте в .htaccess защиту от использования рефереров).

5. Подозрения на проблемы с контейнерами или виртуализацией
Если ваши подозрения на контейнеризацию (например, использование Docker) оправданы, возможно, проблема в процессе или контейнере, который не очищается должным образом после работы.

Решения:

• Проверьте процессы и контейнеры на сервере, если используется контейнеризация, и убедитесь, что все обновления для контейнеров выполнены корректно.
• Проверьте настройки серверной безопасности для защиты от использования скомпрометированных контейнеров.

Рекомендации для дальнейших шагов

1. Используйте инструменты безопасности для сканирования сайта и базы данных, такие как Wordfence или Sucuri.
2. Анализируйте серверные логи на предмет подозрительных активностей, особенно в ночное время.
3. Свяжитесь с хостингом и попросите их провести полную проверку на наличие вредоносного кода на уровне сервера.
4. Проверьте файлы .htaccess и конфигурацию Apache на наличие нестандартных правил, которые могут инициировать редиректы.

Если эта проблема повторится, возможно, потребуется провести более глубокую проверку на уровне сервера и баз данных.

 

[Di Ost]

Редиректы происходят на разные сайты — это указывает на случайные или динамические редиректы, которые могут быть связаны с вредоносным кодом, скрытым на сервере или в процессе работы веб-сервера (например, в Apache).

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

Редирект с поисковых систем — это важная деталь. Проблема может быть связана с определенными запросами или куки, которые устанавливаются на основе реферера (например, переход с поисковиков). Вредоносные скрипты могут отслеживать реферер и активировать редирект в зависимости от этого.

Вскрывал куки которые присваиваются и да, там действительно вещаются куки, что бы "аккуратно спамить"

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

Моя теория с разными хостингами провалилась т.к. редрект словил на локалке ( OS среда ), и тут стало понятно, что копать надо сам сайт

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

Иследовал эти куки но они не несут никакой информации ( для меня ) для посетителя сайта это скорее всего метка какой пользователь ( с поиска пришел или прямой заход )

Возможные причины и решения

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

В этом то и проблема, что по логам ничего подозрительного не обнаружил, специально тригирил редирект и чекал логи, там все спокойно

• Убедитесь, что у вас настроены правила безопасности на уровне сервера. Например, ограничьте доступ к административной части сайта через .htaccess или через настройки IP.

К сожалению доступ по ИП не могу себе позволить т.к. сайты имеют своих модераторов :|

• Настройте сервер для защиты от инъекций через Apache. Например, используйте защиту от скриптов, которые могут быть запущены через GET-запросы или другие нестандартные методы.

Изначально собираю код с экранированием как минимум на стороне файла оработчика, по возможности еще пилю js маски ( для форм ), а для гет\пост запросов экранирование скриптов\тегов, что подталкивает на мысль, что это исходило из плагина ( предположительно )

2. Вредоносный код в базе данных
Если проблема возникает даже с чистой установкой WordPress, возможно, вредоносный код был инъецирован в базу данных (например, через изменения в таблицах wp_options, wp_postmeta, или wp_posts), который реагирует на реферер или определенные условия.

Вот это самый больной вопрос т.к. в ручную перебирал, сравнивал со старыми бэкапами и разницы не нашел ( корме изменение версий вп \ плагинов )

Решения:

• Проверьте базу данных на наличие необычных записей или ссылок на внешние сайты в таблицах, связанных с контентом (например, wp_posts, wp_options).

Проверял, отсматривал, искал в бд все что связанно с http \ https и не связано с сайтом и контентом\внутрение ссылки и тп

• Проверьте таблицу wp_options на наличие аномальных записей, особенно тех, которые могут быть связаны с перенаправлениями.

Эту таблицу в первую же очередь проверял ))

• Используйте инструмент для поиска и удаления вредоносного кода в базе данных, такой как Для просмотра ссылки Войди или Зарегистрируйся или Для просмотра ссылки Войди или Зарегистрируйся.

Не пробовал, попробую

3. Проблемы с плагинами или серверными процессами

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

Вот прям большие подохрения на тригер плагина > занесение вируса в контейнер хостинга

• Попробуйте отключить все плагины на чистом WordPress (не используя свою кастомную тему) и протестировать. Если редирект все равно появляется, то это скорее всего проблема в серверной части.

Ставил, был редирект но я подохреваю т.к. это было в том же окне где уже были прописаны куки ( анонимную вкладку не переоткрывал )

• Используйте мониторинг серверных процессов, чтобы выявить активные или необычные процессы. Это можно сделать через панель управления хостинга или с помощью инструментов вроде top или ps на сервере.

С этим проблематично т.к. на хостинге те возможности просмотреть не дают полной информации, а сегодня еще зарамсил с поддержкой т.к. отсутствует вовлеченость и ответы копипаст, за ноздри подтянул когда они мне написали что проверяли указаный сайт и проблем не выявлено и на винде и на маке и на разных браузерах а я им скинул логскрин с яметрики где с одного компа открыли в 2х разных браузерах и все причем я им видео прислал как тригерит, на разных сайтах показал, ладно бы у меня одного такое у клиентов и посетителей сайтов клиентов тоже самое они ответ не дали. Доходчиво обяснил, что разводить лохов которые не шарят в этом могут, а когда общаются с ИТшником еще и спросить с них можно. ( Если что хостинг джино, и за последние 2 года ответы тех поддержки дошли до уровня Ctrl + C Ctrl + V )

4. Рефереры и использование куков
Это может быть связано с использованием специальных куков или сессий, которые вредоносный код использует для отслеживания пользователей.

Решения:

• Проверьте, какие куки создаются сайтом, и попробуйте очистить их с помощью плагинов безопасности.

Чистил - все равно новый редирект вешает

• Используйте функции для управления сессиями и защиты от манипуляций с реферерами (например, добавьте в .htaccess защиту от использования рефереров).

С этим проблема т.к. на некоторых сайтах стояли клоаки ( из за особеностей проектов ) и некоторые проекты у меня дружат по Rest API ( там все экранировано железабетонно ключем в который добавлена соль

5. Подозрения на проблемы с контейнерами или виртуализацией
Если ваши подозрения на контейнеризацию (например, использование Docker) оправданы, возможно, проблема в процессе или контейнере, который не очищается должным образом после работы.

Решения:

• Проверьте процессы и контейнеры на сервере, если используется контейнеризация, и убедитесь, что все обновления для контейнеров выполнены корректно.
• Проверьте настройки серверной безопасности для защиты от использования скомпрометированных контейнеров.

К сожалению в пределах хостинга мною это реализовать невозможно, запросы уже направлены в сапорт

Рекомендации для дальнейших шагов

1. Используйте инструменты безопасности для сканирования сайта и базы данных, такие как Wordfence или Sucuri.
2. Анализируйте серверные логи на предмет подозрительных активностей, особенно в ночное время.
3. Свяжитесь с хостингом и попросите их провести полную проверку на наличие вредоносного кода на уровне сервера.
4. Проверьте файлы .htaccess и конфигурацию Apache на наличие нестандартных правил, которые могут инициировать редиректы.

Если эта проблема повторится, возможно, потребуется провести более глубокую проверку на уровне сервера и баз данных.

Все это в процессе :| Пока что единственный результат это обновить версию ВП + все лпагины обновить \ заменить котроые не аплодят, но я опасаюсь, что если проблема глубже чем уязвимости плагинов, то это все вернется и проделаная работа будет в пустую :| хотя да такие провокации заставляют шевелится и обновлятся )

P.S. Попутно использую взгляды на проблему со стороны как этот форум, взгляды коллег и чат ГПТмучаю

 

[edgars2212]

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

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

1. Подробная диагностика на уровне сервера

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

• Проверьте логи ошибок Apache и PHP, особенно во время подозрительной активности.
• Если сервер работает через Nginx или Apache с mod_security, изучите правила безопасности, чтобы убедиться, что они не дают сбои.
• Используйте инструменты для мониторинга серверных процессов, такие как htop или ps, чтобы увидеть, если какой-то процесс подозрительно загружает сервер в ночное время.

2. Дополнительные инструменты для анализа базы данных

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

• Используйте WP-CLI для проверки целостности таблиц.
• Запустите специализированные скрипты для поиска строк, которые могут быть частью инъекций (например, код с base64, eval, и т. д.).
• Search and Replace DB — это инструмент, который позволяет искать и заменять потенциально вредоносные ссылки или коды в базе данных.

3. Мониторинг изменений на сервере

Чтобы избежать повторного заражения, полезно настроить мониторинг изменений файлов:

• Используйте AIDE (Advanced Intrusion Detection Environment) для отслеживания изменений в файлах на сервере.
• Плагины безопасности вроде Wordfence могут уведомлять вас, если на сайте появляется новый файл или происходит изменение в существующих.

4. Проверьте конфигурацию серверного кэширования

Если на сервере работает кэширование (например, Varnish, Redis, или внутренние механизмы кэширования в Apache/Nginx), проверьте, не сохраняются ли редиректы или другие вредоносные данные в кэше. Иногда они могут повторно активировать редиректы, если они были кэшированы на этапе заражения.

5. Долгосрочная защита и предотвращение

После того как проблема будет решена, подумайте о следующих мерах для предотвращения повторения:

• Настройка двухфакторной аутентификации для админов.
• Регулярное использование бекапов и автоматическая настройка восстановления с проверенных версий.
• Использование WAF (Web Application Firewall) на сервере для защиты от атак.

6. Тестирование на другом хостинге

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