Yandex WebmasterでMissing page contentになる場合の対処

なぜかYandexのボットが謎のURLにアクセスしてくるからクロール制御をしたいと思ってYandex Webmasterへ登録しました。
ところが、Yandexからページのデータがダウンロードできない状態に・・・
Yandex - Missing page content
メッセージは「Missing page content」と表示されておりレスポンスボディがないって事らしい。

サーバーログでは送信バイトもでているからコンテンツデータの転送をしている事になってるけれど、Yandexの受信は0バイト。
gzipの展開に失敗しているか?と思ってYandexだけgzipを切ってもダメ。
CSPなどのセキュリティヘッダーがダメなのか?と考えて、Yandexにだけ出力しないようにしてもダメ。
Google先生にきいても全然情報がなくてダメ、Yandexで検索してもダメ。

じゃあなんなの?
まさかドメインがダメなのか?と思って、Freedomから無料ドメインをゲットしてきて割り当てたらすんなりとダウンロードしてくれました。
これにはビックリしましたが気を取り直して、wolfs.jpドメインと無料ドメインの違いを挙げてみました。
 ・DNSサーバーが違う
 ・TLDがjpとml
 ・ドメイン名が普通のドメインとPunycode
 ・SSLありとなし
違いはこんな所。

とりあえず、簡単に検証できるSSLありとなしを試してみたところ、SSLなしのページではちゃんとダウンロードできました。
まさかの一発ヒット!

Yandexの検索ではSSLページはダメなのか?と思ったけど、GETリクエスト自体はできてきるのでSSL通信自体は問題ないよう。
ならHTTP2かな?ってことで試しにHTTP2からHTTP1.1にしてみたところ、SSLでもページをダウンロードしてくれた。
と言うことで、YandexはHTTP2に対応していないようです。

YandexだけHTTP2を使わないようにするにはApacheの設定へこれを追加すればOK。

BrowserMatch "^Mozilla\/5\.0 \(compatible; Yandex" no_http2
Header unset Upgrade env=no_http2

BrowserMatchはYandexだけで良いかもだけどYandexだけだと何か違う物も無効化してしまいそうだったので、Mozilla~Yandexまでを判定材料にしました。
Missing page contentで困ってるWebマスターさんはYandexのみHTTP2の無効化を試してみてくださいー

ccsetup527.exeへのリクエスト

ここ最近IPアドレス104.42.198.99が意味不明なURLにアクセスしてくる。
URLはこんな感じ。

/5dac7054e2b9487bb7fcbf6b9c9d141d/ccsetup527.exe?ttl=XXXXXXXXXX&token=00169082fc6f86fea31adabb626c9e03
/5dac7054e2b9487bb7fcbf6b9c9d141d/ccsetup527.exe?ttl=XXXXXXXXXX&token=fe4c2ca2978ce6eefecdd4fbafd8b052
/5dac7054e2b9487bb7fcbf6b9c9d141d/ccsetup527.exe?ttl=XXXXXXXXXX&token=1d0c643f96e94743fb11dfd06dede843
/5dac7054e2b9487bb7fcbf6b9c9d141d/ccsetup527.exe?ttl=XXXXXXXXXX&token=e44ebbcee8c690b9bb3b05ceec332664
/5dac7054e2b9487bb7fcbf6b9c9d141d/ccsetup527.exe?ttl=XXXXXXXXXX&token=fe1389843a196ce09f39efcb8df4056e
/5dac7054e2b9487bb7fcbf6b9c9d141d/ccsetup527.exe?ttl=XXXXXXXXXX&token=5bc4043a1a1ece94503b87199ce2b0f5

クエリーのtoken以外は全部同じで、エージェントはMozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727)でした。

とりあえずwhoisで照会してみるとMicrosoft Corporationに割り当てられたIPアドレスって事が判明。

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

#
# Query terms are ambiguous. The query is assumed to be:
# "n 104.42.198.99"
#
# Use "?" to get help.
#
#
# The following results may also be obtained via:
# https://whois.arin.net/rest/nets;q=104.42.198.99?showDetails=true&showARIN=false&showNonArinTopLevelNet=false&ext=netref2
#
NetRange: 104.40.0.0 - 104.47.255.255
CIDR: 104.40.0.0/13
NetName: MSFT
NetHandle: NET-104-40-0-0-1
Parent: NET104 (NET-104-0-0-0-0)
NetType: Direct Assignment
OriginAS:
Organization: Microsoft Corporation (MSFT)
RegDate: 2014-05-07
Updated: 2014-05-07
Ref: https://whois.arin.net/rest/net/NET-104-40-0-0-1

OrgName: Microsoft Corporation
OrgId: MSFT
Address: One Microsoft Way
City: Redmond
StateProv: WA
PostalCode: 98052
Country: US
RegDate: 1998-07-09
Updated: 2017-01-28
Comment: To report suspected security issues specific to traffic emanating from Microsoft online services, including the distribution of malicious content or other illicit or illegal material through a Microsoft online service, please submit reports to:
Comment: * https://cert.microsoft.com.
Comment:
Comment: For SPAM and other abuse issues, such as Microsoft Accounts, please contact:
Comment: * abuse@microsoft.com.
Comment:
Comment: To report security vulnerabilities in Microsoft products and services, please contact:
Comment: * secure@microsoft.com.
Comment:
Comment: For legal and law enforcement-related requests, please contact:
Comment: * msndcc@microsoft.com
Comment:
Comment: For routing, peering or DNS issues, please
Comment: contact:
Comment: * IOC@microsoft.com
Ref: https://whois.arin.net/rest/org/MSFT

OrgAbuseHandle: MAC74-ARIN
OrgAbuseName: Microsoft Abuse Contact
OrgAbusePhone: +1-425-882-8080
OrgAbuseEmail: abuse@microsoft.com
OrgAbuseRef: https://whois.arin.net/rest/poc/MAC74-ARIN
OrgTechHandle: MRPD-ARIN
OrgTechName: Microsoft Routing, Peering, and DNS
OrgTechPhone: +1-425-882-8080
OrgTechEmail: IOC@microsoft.com
OrgTechRef: https://whois.arin.net/rest/poc/MRPD-ARIN

#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at: https://www.arin.net/whois_tou.html
#
# If you see inaccuracies in the results, please report at
# https://www.arin.net/public/whoisinaccuracy/index.xhtml
#

URLから察するとCCleaner v5.27のインストーラーを落とそうとしているようですが、うちのサーバーにそんなものはない。
クローラーかと思ったけれどユーザーエージェントが違うし・・よくわからない。

とりあえずMicrosoftの公開連絡先へどうなっているのか確認するように連絡を入れて対応待ち。

WordPressでpingbackを検証できないサイトがある

最近うちのブログにpingbackを飛ばしてきたブログがあってそのブログのpingbackがエラーコード0、エラーメッセージnullで失敗とログに記録されていました。
なんだろうー?とXMLRPCサーバーの処理を追ってみたところ、HEADエレメント内のHTML文法エラーとJavaScriptの問題でした。

HTML文法エラーはそのまんまで <meta property="og:description" content=""説明""/> など普通の文法エラーによる解析失敗。
そしてJavaScriptはpackerで難読化した物がHEAD内にあると動作不良を起こしていました。

pingbackの主な処理はwp-includes/class-wp-xmlrpc-server.phpのfunction pingback_pingで行われます。

<?php
 
public function pingback_ping( $args ) {
    ...省略...
 
    $request = wp_safe_remote_get( $pagelinkedfrom, $http_api_args );
    $remote_source = $remote_source_original = wp_remote_retrieve_body( $request );
 
    if ( ! $remote_source ) {
        return $this->pingback_error( 16, __( 'The source URL does not exist.' ) );
    }
 
    /**
     * Filters the pingback remote source.
     *
     * @since 2.5.0
     *
     * @param string $remote_source Response source for the page linked from.
     * @param string $pagelinkedto  URL of the page linked to.
     */
    $remote_source = apply_filters( 'pre_remote_source', $remote_source, $pagelinkedto );
 
    // Work around bug in strip_tags():
    $remote_source = str_replace( '<!DOC', '<DOC', $remote_source );
    $remote_source = preg_replace( '/[\r\n\t ]+/', ' ', $remote_source ); // normalize spaces
    $remote_source = preg_replace( "/<\/*(h1|h2|h3|h4|h5|h6|p|th|td|li|dt|dd|pre|caption|input|textarea|button|body)[^>]*>/", "\n\n", $remote_source );
 
    preg_match( '|<title>([^<]*?)</title>|is', $remote_source, $matchtitle );
    $title = isset( $matchtitle[1] ) ? $matchtitle[1] : '';
    if ( empty( $title ) ) {
        return $this->pingback_error( 32, __( 'We cannot find a title on that page.' ) );
    }
 
    $remote_source = strip_tags( $remote_source, '<a>' ); // just keep the tag we need
 
    $preg_target = preg_quote($pagelinkedto, '|');
 
    foreach ( $p as $para ) {
        if ( strpos($para, $pagelinkedto) !== false ) { // it exists, but is it a link?
            preg_match("|<a[^>]+?".$preg_target."[^>]*>([^>]+?)</a>|", $para, $context);
 
            // If the URL isn't in a link context, keep looking
            if ( empty($context) )
                continue;
 
            // We're going to use this fake tag to mark the context in a bit
            // the marker is needed in case the link text appears more than once in the paragraph
            $excerpt = preg_replace('|\</?wpcontext\>|', '', $para);
 
            // prevent really long link text
            if ( strlen($context[1]) > 100 )
                $context[1] = substr($context[1], 0, 100) . '&#8230;';
 
            $marker = '<wpcontext>'.$context[1].'</wpcontext>';    // set up our marker
            $excerpt= str_replace($context[0], $marker, $excerpt); // swap out the link for our marker
            $excerpt = strip_tags($excerpt, '<wpcontext>');        // strip all tags but our context marker
            $excerpt = trim($excerpt);
            $preg_marker = preg_quote($marker, '|');
            $excerpt = preg_replace("|.*?\s(.{0,100}$preg_marker.{0,100})\s.*|s", '$1', $excerpt);
            $excerpt = strip_tags($excerpt); // YES, again, to remove the marker wrapper
            break;
        }
    }
 
    ...省略...
}
 
?>

ここのwp_safe_remote_getでpingback送信元へGETリクエストを送信しHTTPヘッダーとHTMLをダウンロードします。
そして次のwp_remote_retrieve_bodyでHTMLのみのデータを変数へセット。

その後はスペース、改行、エレメントを整理しpreg_match( '|<title>([^<]*?)</title>|is'....で記事タイトルをゲット。
strip_tagsでアンカーを消してexplode( "\n\n", $remote_source );で改行毎に配列に格納します。

後はforeach ($p as $para)で配列の中からpingback送信先URLが含まれる配列を探して、配列内にあるpingback送信先URLの前後の文章を抜粋して終了の流れ。

抜粋処理周りにはフィルターが一切ないので処理の変更ができません。
packerの難読化を使っているどうしようもないサイトからのpingbackへどうしても対応したい・・って事なら処理が開始される前に通るフィルターpre_remote_sourceがあるので、これでscriptタグを全て削除すると良いかもしれません。
 
私的には・・・
packerの難読化のような何にもならない物を使っているサイトは放置しても良いと考えます。
と言うのも、packerには悪いと思いますが、後ろめたいコードを書いているサイト多く使われている物ですし、元のコードへ戻すのが非常に簡単で使う意味がほぼ無な物なので。

送信側の方はpingbackの送信に失敗するな?と思ったら自分のブログのコードが正常か確認を。

Bingクローラーは学習しない

うちのブログは今年9月に完全SSL化しましたが、SNI未対応クライアントを配慮してSSLバーチャルホストのデフォルトをblog.wolfs.jpに設定していました。
その影響でSSLのwww.wolfs.jp、www.blog.wolfs.jpのアクセスも許可していました。

上記サブドメインを許可していた期間は僅か1ヶ月ほどでしたが一部の検索結果に上記サブドメインも載るようになったようで、www.wolfs.jp、www.blog.wolfs.jpへのアクセスがかなり増えましたw
これはダメだな・・と言うことでSNI未対応環境を捨ててblog.wolfs.jpドメインからのみアクセスを許可するよう設定し、検索結果から消すために301 Moved Permanentlyでリダイレクトするように設定して更に1ヶ月が経過。

Googleは9割blog.wolfs.jpへアクセスするようになったけれど、Bingだけは2ヶ月前と全く変わりません。
ログを見るとリダイレクト先へアクセスしていない状況。
但し、robots.txtのリダイレクトだけはちゃんとリダイレクト先にアクセスするよう。

Bingの挙動はかわってるなーと思っていたけど301を理解しないバカクローラーだとは思いませんでしたw
と言うことで、Bingは301を理解しないのでドメインを変更するときは注意が必要です。

ちなみに、リダイレクトをしているのはユーザーエージェントがGoogleとBingだけです。
リダイレクトのコードはこんな感じ。

<?php
 
if ($_SERVER['HTTP_HOST'] !== 'blog.wolfs.jp') {
    $agent = strtolower($_SERVER['HTTP_USER_AGENT']);
    if (strstr($agent, 'googlebot') !== false || strstr($agent, 'bingbot') !== false || strstr($agent, 'msnbot') !== false) {
        $redirect_host = 'blog.wolfs.jp';
        if (strstr($_SERVER['HTTP_HOST'], 'wolfs.jp') !== false) {
            $redirect_host = 'blog.wolfs.jp';
        } else if (strstr($_SERVER['HTTP_HOST'], 'xn--n6x.jp') !== false) {
            $redirect_host = 'xn--n6x.jp';
        } else {
            http_response_code(400);
            exit;
        }
 
        http_response_code(301);
        header('Location: https://'.$redirect_host.$_SERVER['REQUEST_URI'], true, 301);
        exit;
    }
 
    http_response_code(403);
    exit;
}
 
?>

これをwp-config.phpの一番上とかに書いておけば勝手にやってくれます。