名乗りを、どう確かめるか
UA・SNI・IP・署名

3本を貫いていた、ひとつの問い

このシリーズでは、別々のテーマを扱ってきたつもりでした。 並べてみると、同じ問いを違う角度から見ていたことが分かります。

すべて「相手が名乗っていることを、どう確かめるか」でした。 最後に User-Agent を置くと、全体像が見えます。

名乗りには、種類がある

リクエストには、いくつもの「名乗り」が含まれています。 それぞれ、確かめられる度合いが違います。

UA と Referer だけ、対応する検証手段がありません。 仕様として「自由に書いてよい文字列」だからです。 嘘をついても、規格には違反しません。

なぜ IP だけは、詐称しにくいのか

表の中で IP アドレスだけ「困難」としました。理由は通信の仕組みにあります。

クライアント → サーバー   SYN
サーバー → クライアント   SYN+ACK   ← 名乗ったIPに返される
クライアント → サーバー   ACK       ← これを返せなければ成立しない

偽の IP を名乗ると、サーバーの応答はその偽のIPへ送られます。 攻撃者の手元には届かない。だから3手目を返せず、接続が成立しません。

この性質が重要です。UA は確かめられないが、IP は確かめられる。 なら、IP を手がかりに UA を検証できないか——それが次の話です。

UA を、IP で裏づける

主要なクローラは、自社の管理下にある IP から接続してきます。 Googlebot なら Google の、Applebot なら Apple の。

そこで、IP から辿ってドメインを確かめる方法が使われます。 逆引きと正引きを組み合わせる——FCrDNS と呼ばれます。

① 逆引き（PTR）：IP からホスト名を引く
66.249.73.72 → crawl-66-249-73-72.googlebot.com

② ドメインの照合：名乗りと一致するか
googlebot.com は Googlebot の管理ドメイン → 一致

③ 正引き（A）：ホスト名から IP に戻す
crawl-66-249-73-72.googlebot.com → 66.249.73.72
                                    元のIPと一致 → 正当

なぜ、①だけでは足りないのか

ここが肝心です。逆引き（PTR）は、IP の管理者が自由に設定できます。

そこで③が要ります。 正引きを設定できるのは、そのドメインの管理者だけです。 googlebot.com の DNS を書き換えられるのは Google だけ。

前回の署名と、考え方は似ています。 当人にしかできない操作を、外から確認する。 署名は秘密鍵、こちらは DNS の管理権限です。

デモ：名乗りを検証する

リクエストを選ぶと、3段階の検証が順に実行されます。 とくに「PTR だけ詐称」のケースを見てください。

実測 — 7日間で6件

運用しているサーバーで、Googlebot を名乗る接続を全件検証しました。 その結果です。

詐称は7日間で6件。すべてデータセンター事業者のドメインでした。 サーバーを借りて、そこから Googlebot を名乗っていたことになります。

詳しい経緯は botは、3種類いるに書きました。 この記事ではなぜその手順が有効なのかを扱っています。

検証できない相手は、どうするか

FCrDNS が使えるのは、逆引きを整備している事業者だけです。 それ以外の相手には別の方法が要ります。

署名という方向

前回扱った電子署名を、 リクエストに付ける仕組みが検討されています。 bot が自分の秘密鍵で署名し、サーバーが公開鍵で検証する—— UA の詐称を根本的に防げます。

ただし、bot 側とサーバー側の双方が対応する必要があります。 普及には時間がかかるでしょう。

名乗りが確かめられないなら、行動を見る

最後に残るのは、実際の挙動と照らす方法です。

まとめ

4本を通じて見てきたのは、「名乗りは、それだけでは意味を持たない」ということでした。

HTTPS は経路上の書き換えを防ぎ、SNI と Host の照合は食い違いを検出し、 署名は作成者を特定する。 どれも「確かめる仕組み」があって初めて、名乗りに意味が生まれます。