Нужно ли ставить перенаправление со страницы index.php на сайт? — веб-студия Муравейник

Автор статьи
Андрей Буйлов

Подробнее об авторе

В этой статье разберем вопрос, нужно ли ставить перенаправление со страниц index.php сайта.

Подписчик спрашивает: «На сайте index.php отдает 404 ошибку. Что лучше: 301 редирект сделать или пусть остается ошибка 404?»

Для тех, кто не в курсе, расскажу: index.php — это во многих CMS-системах основной исполняемый файл, к которому идет обращение, когда вы только зашли на сайт. Его не всегда видно, технически это может быть сделано так, что этот index.php есть, но обращение к нему идет в скрытом режиме, и вы его в адресной строке не видите. Но он часто имеется.

И почему вообще возник такой вопрос в нашем, посвященном SEO, блоге? Потому что многие CMS-системы, многие движки выдают по адресу index.

php ту же самую версию главной страницы, что и без него.

Например, вы заходите на «site.ru» и на «site.ru/index.php» — и получаете одну и ту же страницу. Это плохо, как, в принципе, и все дубли страниц на сайте. А если еще есть и какие-то ссылки на «index.php», заходы, то она может попасть в индекс, и здесь поисковик будет решать, какой вариант ему оставить в индексе: «site.ru» или «site.ru/index.php». К тому же еще и часть внешних ссылок на такую страницу может идти, и если вы ее закроете 404 ошибкой, то эти ссылки просто пропадут — ни вес, ни анкорная составляющая по ним передаваться не будет.

Таким образом, если у вас такая ситуация возникла, то оставлять подобную страницу открытой нельзя, нужно что-то с ней сделать. Но если закроете ее 404, то как уже сказал, те ссылки, которые на нее ведут, пропадут. Либо, в случае, когда она где-то проиндексировалась, стала ранжироваться, по каким-то запросам выходить, и люди начали на нее переходить, тогда, если поставите 404, то все накопленные положительные моменты пропадут: ссылки, которые на нее ведут, поведенческие факторы, которые у нее были, а её возраст не то, чтобы занулиться, но, скажем так, никак не будет помогать вашему сайту.

И даже если она нигде не выходила, но ссылки на нее были, то тоже не очень хорошо, если это всё пропадет. Поэтому 404 я бы не рекомендовал ставить, а лучше 301 редирект, либо чтобы rel canonical на ней стоял. Этот атрибут в блоке <head> страницы ставится, и он указывает на основную версию, вам достаточно просто указать там ваш «site.ru».

И в этих случаях — что в случае 301 редиректа, что в случае rel canonical — все основные параметры, которые шли на ту страницу, факторы, которые могут влиять на продвижение вашей главной страницы: ссылки, которые на нее шли, поведенчески, которые на ней были (если были), возраст, если какой-то накопился — они перетекают на вашу основную. Ну возраст вряд ли будет больше, чем у главной, поэтому в этом смысле можно не сильно беспокоиться, а вот ссылки и поведенческие запросто могут перетечь.

К тому же, если, опять же, есть внешние ссылки, размещенные в таких местах, откуда могут переходить люди, то пользователи могут расстроиться, если там будет выходить 404 ошибка, а так их через редирект перекинет на основную. Поэтому я бы поставил 301 редирект. Тут главное смотреть, чтобы когда вы будете его ставить, у вас ничего не поломалось. Потому что index.php — это важная техническая страница, и если топорно подойти к вопросу, то можно что-то поломать. Потому здесь будьте аккуратнее. В остальном особо секретов никаких нет, и 301 редирект или canonical лучше, чем 404.


Кампания

Massive ois[.]is Black Hat по перенаправлению вредоносных программ

С сентября 2022 года наша исследовательская группа отслеживала всплеск вредоносного ПО WordPress, перенаправляющего посетителей веб-сайтов на поддельные сайты вопросов и ответов через ois[.]is . Эти вредоносные перенаправления, по-видимому, предназначены для повышения авторитета сайтов злоумышленников для поисковых систем.

Результаты PublicWWW показывают, что почти 15 000 веб-сайтов были затронуты этой вредоносной программой. Наш собственный сканер SiteCheck обнаружил эти перенаправления на более чем 2500 сайтов в сентябре и октябре. По данным наших внутренних зачисток, файловая структура каждого зараженного веб-сайта содержит большое количество зараженных файлов — всего около 90 003 20 000 90 004 обнаружений.

Что делает эту кампанию особенно необычной, так это то, что злоумышленники продвигают несколько поддельных низкокачественных сайтов вопросов и ответов.

В этом посте мы проанализируем, что делает эта инфекция, как работают вредоносные перенаправления и как снизить риск и очистить вредоносное ПО.

Содержание:

  • Обзор
  • Часто заражаемые файлы
  • Методы уклонения
    • 90 023 Сценарии перенаправления
  • Развитие вредоносных перенаправлений
  • Перенаправление на спам-сайты вопросов и ответов
  • Пункты назначения перенаправления
  • Инструкции по очистке
  • Методы смягчения последствий

Обзор

Вредоносные SEO-перенаправления можно описать как вредоносное ПО, предназначенное для захвата веб-сайта с целью злоупотребления его ресурсами (особенно трафиком и рейтингом веб-сайта). Злоумышленники часто рекламируют спам для фармацевтики, услуг по написанию эссе, подделок дизайнерских товаров или, в данном случае, поддельных сайтов вопросов и ответов.

Перенаправления на спам-сайты не являются чем-то новым. Фактически, более 50% вредоносных программ, очищенных Sucuri в прошлом году, были SEO-спамом. Кроме того, на спам приходится более трети всех обнаружений вредоносного ПО с помощью нашего инструмента SiteCheck. Тем не менее, спам 9В частности, перенаправления 0065 не так распространены: чуть более 13% всех заражений SEO-спамом классифицируются как вредоносное перенаправление.

Анализ вредоносных перенаправлений ois[.]is

Некоторые вредоносные программы, заражающие веб-сайты, ограничивают себя небольшим количеством файлов, часто для того, чтобы уменьшить их след и избежать обнаружения. Это вредоносное ПО наоборот — в среднем более 100 зараженных файлов на каждый веб-сайт.

Давайте рассмотрим некоторые из наиболее распространенных мест заражения.

Часто заражаемые файлы

Наиболее часто поражаемые файлы — это основные файлы WordPress, однако это вредоносное ПО также заражает вредоносные файлы .php , созданные другими несвязанными кампаниями вредоносного ПО.

Вот 10 наиболее часто заражаемых файлов.

  • ./wp-signup.php
  • ./wp-cron.php
  • ./wp-links-opml.php
  • ./wp-settings.php
  • ./wp-comments-post.php
  • ./wp-mail.php
  • ./xmlrpc.php
  • ./wp-activate.php
  • ./wp-trackback.php
  • ./wp-blog-header.php

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

  • RVbCGlEjx6H.php
  • lfojmd.php
  • wp-newslet.php
  • wp-ver.php
  • wp-logln.php
    • 900 59

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

    Методы уклонения

    Далее давайте взглянем на само вредоносное ПО.

    Вот пример обнаруженного вредоносного кода, внедренного в основной файл index.php зараженной среды WordPress:

    Обнаружен вредоносный код, внедренный в основной файл index.php WordPress.

    Фрагмент в верхней части инъекции отвечает за проверку того, вошел ли посетитель веб-сайта в настоящее время в WordPress.

     $ckUjYggTf = 0;
foreach($_COOKIE как $vUjUnHvOOoO => $vvvUjUnHvOOoO){
  если (strstr(strval($vUjUnHvOOoO), 'wordpress_logged_in')){
    $ckUjYggTf = 1;
    перерыв;
  }
}
if($ckUjYggTf == 0 && !strstr(strval($_SERVER['REQUEST_URI']), 'wp-login.php')){

    Перенаправление не произойдет, если присутствует файл cookie

    wordpress_logged_in или текущая страница wp-login.php . Это используется как маневр уклонения, чтобы скрыть себя от администраторов.

    Сценарии перенаправления

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

    Базовое перенаправление:

    В одном варианте мы видели, что злоумышленники использовали простую комбинацию window.location.href и meta refresh перенаправляет, как показано ниже.
    Сложная переадресация:

    Другой более сложный вариант сохраняет информацию о переадресации в браузере посетителя localStorage , чтобы убедиться, что они не перенаправляются чаще, чем раз в 2 или 6 часов, в зависимости от используемого варианта. Это значение жестко закодировано в AllowHours переменная.

    Variant использует переменную allowHours для определения частоты перенаправления.
    Перенаправляет на файлы logo.png

    Во всех случаях вредоносная программа перенаправляет на файлы . png . Простая версия имеет только один пункт назначения перенаправления:

    • hxxps://ois[.]is/images/logo.png

    В то время как более сложный вариант выбирает один из следующих 8 файлов:

    • logo -1.png
    • логотип-2.png
    • logo-3.png
    • logo-4.png
    • logo-5.png
    • logo-6.png 90 004
    • logo-7.png
    • логотип -8.png
    Более сложный вариант перенаправления использует несколько целей.

    Эволюция вредоносных редиректов

    В начале этой кампании атака использовала немного укороченный сервис ссылок hxxps://bit[.]ly/3AAXYh6 , который в итоге перенаправлял на hxxps://ois[.]is/rr/page-1.php и затем hxxps://ois[.]is/images/logo.png .

    Согласно Bitly, эта ссылка была создана 1 сентября 2022 .

    Перенаправление на спам-сайты вопросов и ответов

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

    Вредоносное ПО использует функцию window.location.href для перенаправления на URL-адрес результатов поиска Google спам-домена по своему выбору.

    В данном случае злоумышленники использовали поддельный сайт вопросов и ответов:

    Пункты перенаправления

    Мы наблюдали, как злоумышленники меняли веб-сайты, на которые они перенаправлялись. На данный момент мы определили следующие направления перенаправления:

    • en.w4ksa[.]com
    • Peace.yomeat[.]com
    • qa.bb7r[.]com
    • en.ajeel[.]store
    • qa.istisharaat[.]com
    • en.photolovegirl[.]com
    • en.poxnel[.]com
    • qa.tadalafilhot[.]com
    • вопросов.rawafedpor[.]com
    • qa.elbwaba[.]com
    • вопросов.firstgooal[.]com
    • qa.cr-halal[.]com 9002 6
    • ка .aly2um[.]com

    Некоторые из этих сайтов имеют более одного субдомена (например, en. и qa. ). Вы можете найти многие из них, используя этот запрос URLscan. io.

    Стоит отметить, что большинство сайтов (включая ois[.]is ) скрывают свои серверы за прокси CloudFlare. Кроме того, кажется, что сайты используют один и тот же шаблон вопросов и ответов и созданы с использованием платформы вопросов и ответов с открытым исходным кодом Question2Answer (Q2A). Согласно их веб-сайту, эта платформа в настоящее время поддерживает более 24 500 сайтов на 40 языках.

    Целевой контент и темы спама

    Спам-сайты злоумышленников заполнены различными случайными вопросами и ответами, найденными на других сайтах вопросов и ответов. Многие из них имеют криптовалютную и финансовую тематику.

    На данный момент мы не заметили вредоносного поведения на этих целевых страницах. Однако в любой момент операторы сайтов могут произвольно добавлять вредоносное ПО или начинать перенаправлять трафик на другие сторонние веб-сайты.

    Гипотеза

    Эта кампания, похоже, пытается повысить авторитет своих сайтов вопросов и ответов для поисковых систем, поэтому злоумышленники, вероятно, используют ссылки результатов поиска Google в своих перенаправлениях.

    Возможно, эти злоумышленники просто пытаются убедить Google, что реальные люди с разных IP-адресов, использующие разные браузеры, нажимают на их результаты поиска. Этот метод искусственно посылает Google сигналы о том, что эти страницы хорошо работают в поиске.

    Если это так, то это довольно хитрый черный SEO-трюк, который мы редко видели в масштабных хакерских кампаниях. Однако его эффект сомнительный, учитывая, что Google будет получать много «кликов» по ​​результатам поиска без выполнения каких-либо реальных поисков.

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

    Тематика доменных сайтов второго уровня также говорит сама за себя. Например, cr-halal[. ]com говорит о криптовалютах, а tadalafilhot[.]com содержит слово tadalafil в доменном имени, которое является родовым названием Сиалиса — одного из лучших препаратов для лечения эректильной дисфункции, продвигаемых фармацевтическими спам-кампаниями вредоносного ПО.

    Некоторые из доменов второго уровня не имеют реальных сайтов, но показывают индекс каталога, который раскрывает дополнительную информацию о кампании. Например, istisharaat[.]com и aly2um[.]com показывают следующие поддомены вопросов и ответов, созданные 20 апреля 2021 года.

    Эти домены также содержат файлы ads.txt, показанные ниже.

    Эти файлы просто показывают, что сайты размещают рекламу AdSense только от Google и идентификаторов издателя. Вы можете найти эти файлы ads.txt на сайтах, которые также не раскрывают свои списки каталогов.

    Больше прибыли от Google AdSense, скорее всего, было первоначальным планом для этих сайтов вопросов и ответов, но оказалось, что создание сайтов, заполненных извлеченным контентом с других сайтов, не генерирует достаточного трафика.

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

    • Привлечь больше трафика на свои поддельные сайты (и, надеюсь, нажать на Google Ads)
    • Повысить авторитет сайтов с помощью поддельного поиска

    Инструкции по очистке

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

    Выполнение проверки целостности основного файла должно быть вашим первым шагом. Если вы можете идентифицировать какие-либо файлы с этим вредоносным ПО, обязательно запросите в своей файловой системе любые другие файлы, содержащие ту же самую инъекцию; почти наверняка будет немало других.

    Это вредоносное ПО часто сочетается с другими инъекциями, особенно с теми, которые обнаруживаются в поддельных файлах .htaccess или спамных файлах . html . Найдите в своей файловой системе любые недавно измененные или добавленные файлы.

    Например, если вы знаете, что заражение произошло в течение последних двух недель, вы можете запустить эту команду SSH, чтобы найти все файлы, измененные за последние 15 дней:

     $ find . -тип f -mtime -15

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

    Для получения более подробной информации ознакомьтесь с нашим руководством «Как исправить взломанный веб-сайт WordPress».

    Методы смягчения последствий

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

    Также вероятно, что веб-сайты скомпрометированы из скомпрометированных панелей администратора wp-admin. По этой причине настоятельно рекомендуется защитить вашу панель администратора wp с помощью 2FA или других ограничений доступа.

    И (как и в случае со всеми другими инфекциями веб-сайтов) обязательно измените все пароли администратора и точки доступа (такие как учетные записи FTP, cPanel, хостинг и т. д.). Вы также должны убедиться, что все программное обеспечение на вашем веб-сайте обновлено и исправлено до самой последней версии.

    Вы можете разместить свой веб-сайт за брандмауэром, чтобы защитить его от атак. И, как всегда, если ваш сайт взломан и вам нужна помощь, чтобы все исправить, зарегистрируйтесь в наших службах безопасности, и мы во всем разберемся!

    Регулярные выражения перенаправления — перенаправление

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

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

    В контексте перенаправления совпадение простого URL-адреса будет соответствовать только одному URL-адресу. URL-адрес регулярного выражения может соответствовать многим URL-адресам.

    Помимо сопоставления многих URL-адресов, регулярное выражение может извлекать информацию из исходного URL-адреса и копировать ее в целевой URL-адрес.

    Несколько примеров могут оказаться полезными. Перенаправление с исходным URL /my-url будет соответствовать запросам только на /мой-url .

    Перенаправление с исходным URL-адресом /my-url/.*  будет соответствовать запросам:

    • /my-url/this
    • /my-url/that

    И так далее .

    Важная часть /my-url/.*  это .* ​. Это часть URL-адреса, состоящая из регулярных выражений, и она эквивалентна фразе «сопоставить /мой-url/ с любой последовательностью символов».

    Обратите внимание: чтобы включить соответствие регулярному выражению в перенаправлении, убедитесь, что вы включили параметр «регулярное выражение».

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

    Синтаксис регулярных выражений

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

    В данном случае .  означает «любой символ», а *  означает любой номер предыдущего выражения. То есть любое количество любых символов.

    Но подождите, все гораздо сложнее!

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

    Извлечение информации об источнике

    Регулярное выражение может не только соответствовать множеству URL-адресов, но и извлекать информацию из исходного URL-адреса и копировать ее в целевой URL-адрес.

    Зачем тебе это? Давайте посмотрим на другой пример. Скажем, у вас есть сайт, некоторые страницы которого находятся ниже 9.0375 /oldpage/ , и вы переместили их в /newpage/ .

    • /oldpage/bananas/
    • /oldpage/best-post-in-the-world/ ​

    И вы хотите переместить их по адресу:

    • /newpage/бананы/
    • /newpage/best-post-in-the-world/

    То есть вы хотите изменить /oldpage/ на /newpage/ , но оставить бананов и best-post -в -мир .

    Для этого вы можете создать регулярное выражение, такое как /oldpage/(.*) .

    Обратите внимание, что .*  заключено в квадратные скобки. Это говорит Redirection «захватить» данные. Тогда целевой URL будет /newpage/$1 .

    Здесь $1 заменяется содержимым захваченного (. *) . Итак:

    /oldpage/bananas  => /oldpage/(bananas)  => /newpage/$1  => /newpage/bananas

    Бесконечные циклы

    Часто возникающая проблема с регулярными выражениями — бесконечное перенаправление . То есть вы создаете регулярное выражение, которое перенаправляет на URL-адрес, который сам перехватывается тем же регулярным выражением. Затем он перенаправляется снова, и снова, и снова, пока браузер не остановится с сообщением ERR_TOO_MANY_REDIRECTS (или эквивалентным).

    Например, у нас есть такое перенаправление:

    /index.php/(.*) 9  указывает регулярному выражению, что оно применяется только при совпадении в начале URL. Это предотвращает его совпадение в другом месте URL-адреса и останавливает бесконечную переадресацию.

    Тестирование регулярных выражений

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

    • https://regexr.com/
    • https://regex101.com/

    Обратите внимание, что перенаправление использует регулярные выражения PHP. Они широко известны как PCRE и могут отличаться от других библиотек регулярных выражений.

    Хороший ресурс для понимания регулярных выражений можно найти здесь.

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

    Соответствие всему URL-адресу

    Перенаправление выполняет замену регулярного выражения – preg_replace . Источником перенаправления является шаблон соответствия, целью является шаблон замены, а запрошенный URL-адрес — это тема.

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

    Обратите внимание, что в этом контексте термин «полный URL» относится ко всему, кроме протокола и домена.

    Общие регулярные выражения

    В WordPress обычно используются следующие регулярные выражения. Как упоминалось выше, вам нужно будет включить опцию regex .

    Обратите внимание, что регулярные выражения не могут генерировать новую информацию. Например, вы не можете создать категорию из URL-адреса, если она там еще не существует.

    Дата перенаправления и имя постоянная ссылка 9/(?!blog)(.*)

    Цель

    /blog/$1

    Перенаправить каждую страницу старого сайта на новый сайт
    http://oldsite.com/your-thing/ 9037 6 ⇒ https://newsite.

    No related posts.