著者： Robert Graham
日本語訳： yomoyomo
以下の文章は、Robert Graham による Pin-pointing China's attack against GitHub の日本語訳であり、著者の許可を得て公開するものである。
この一週間（訳注：原文は2015年4月1日に公開された）、「GitHub」というウェブサイトが中国による攻撃にさらされた。この投稿では、http-traceroute を行うことでその攻撃がどこから来てるかを特定する。
GitHub はインターネットの重要基盤をなすウェブサイトで、オープンソースプロジェクトの最大のホスト先だが、最も有名なのは Linux である（私のコードもそこでホストしている）。GitHub はまた、人気のブログプラットフォームでもある。
数え切れないほどホストしているプロジェクトの中に、https://github.com/greatfire や https://github.com/cn-nytimes がある。これらはそれぞれ http://greatfire.org と http://cn.nytimes.com というウェブサイトのミラー（複製）である。GreatFire は、中国のインターネット検閲を回避するツールを提供しており、ニューヨーク・タイムズには中国が検閲したいニュース記事がある。
中国は自身にとって不愉快なウェブサイトをブロックするが、GitHub 上のミラーとなると容易にはブロックはできない。選択肢は GitHub 上のすべてをブロックするか許可するかのいずれかになる。GitHub はオープンソースの重要基盤なので、GitHub をブロックするのは、あまり実行可能な選択肢ではない。
その結果、中国は別の選択肢を選んだのだが、それは GitHub にそれらのページを削除するよう圧力をかけるべく、特定の GitHub の URL にトラフィックを集中させるというものだった。アメリカ人は検閲の問題にとても敏感で、そうした圧力に従うのをよしとしないので、これは言うまでもなく愚かな方針決定である。対応する方法はいくらでもあるので、GitHub 自体でこの問題を解決できるだろう。もしできなくても、（CloudFlare など）他の会社がその防御をかってでるだろう。
攻撃がどこから来ているかは大きな問題である。この攻撃は中国政府公認なのだろうか？ それとも自分勝手なハッカーの仕業だろうか？
スウェーデンの Netresec という会社が、ハックの詳細の大部分を解説することで、この疑問にある程度答えた。ある中間者（man-in-the-middle）装置が、外から中国に入ってくるウェブリクエストを傍受し、それからコンテンツを GitHub を攻撃する JavaScript のコードに置き換えるのがその攻撃方法である。具体的には、Baidu のウェブ解析リクエストを傍受した。検索エンジンの Baidu は中国における Google であり、広告を追跡するために Google のような解析ソフトウェアを運用している。中国内部のページを訪問する中国外にいる誰もが、GitHub を攻撃するこの JavaScript を走らせることになる。攻撃は「いたるところから」来ているように見えるので、GitHub には攻撃をブロックするのが難しいわけだ。
Netresec は、パケット内の TTL フィールドを見ることで、中間者攻撃が発生していたのをはっきり特定できた。TTL、つまり time-to-live は、パケットの寿命を監視する、すべてのインターネットのパケットにある領域である。ルータがパケットを転送するたびに、TTL のフィールドから1引かれる。フィールドの値が0になると、パケットは破棄される。これが、ルーティングのループがあっても、その中をパケットが際限なく転送されるのを防いでいる。
多くのシステムは、最初 TTL の値を64にしてパケットを送信する。従って、あなたのところでパケットの TTL の値が46になっていれば、送信者とあなたの間に18ホップあることが分かる（64 - 18 = 46）。
Netresec が見つけたのは、以下の画像で示される状況である。この画像は、サーバが送信元のパケットとサーバが宛先のパケットのシーケンスを示している。こちらから Baidu サーバ宛てに送られたパケットの TTL は、送信時の初期値の64である。サーバからの最初の応答の TTL 値は46になる――パケットは TTL が64で送信され、私のコンピュータに到達するまでに18引かれたからである。私がウェブリクエストを送信すると、98とか99というおかしな TTL が入った応答が返っている。これらのパケットは明らかに元々のサーバからではなく、何かしら間に介在する中間者装置から来たものだ。
この中間者が私と Baidu の間のどこかにいることは分かるが、どこだろう？ それに答えるために、traceroute のコンセプトを利用する。
traceroute はすごくいかした技である。TTL に64を入れてパケットを送るのではなく、そのツールは TTL にまず1を入れて送信し、その後2、その後3と TTL の値を増やしていく。TTL の値がとても小さいので、パケットは宛先まで届かない。TTL が最終的に0になると、宛先までの途中にあるルータはパケットは破棄する。ルータはこれを行う際に――ルータの IP アドレスから――Time-Exceeded メッセージという通知パケットを送り返す。従って、これらの送り返されたパケットをすべて集めれば、私と宛先の間にあるルータがマッピングできるわけだ。
これを行うツールを以下に示すが、私のマシンから Baidu のサーバに traceroute した結果である。
二番目の列が所要時間である。ご覧の通り、パケットがロサンゼルスに到達するのにだいたい80ミリセカンドかかっており、その後遅延時間は中国に到達すると230ミリセカンドに跳ね上がる。16ホップ進んだ後に traceroute をブロックするファイアウォールがあるため、サーバまで到達できないことにもご留意いただきたい。
さて、この経路のどこで中間者による通信傍受が起きているのだろうか？ この疑問に答えるために、いくらかコードを書かなければならなかった。独自のちょっとした traceroute ツールを書いたのだ。一つパケットを送るのでなく、ターゲットとなるサーバまでパケットが到達するように、まず普通の TTL で接続を確立した。それから、ウェブリクエストのパケットを送信する際に、より小さい TTL を使用したら、サーバに到達する前にパケットは破棄される――が、うまくいけばそれは中間者がパケットを見た後になる。さまざまな TTL でパケットを送ることで、邪悪な装置が待ち伏せしているところを発見できるはずである。
私は、その装置が11ホップと12ホップの間で待ち伏せしているのに気付いた。TTL に11を入れて送られたウェブリクエストのパケットは返ってこない一方で、TTL が12のパケットは、以下のように応答が返ってくる。
上の画像の黒の行が、TTL に12を入れて私が送ったパケットである。オレンジの行（とその上の二つのパケット）が、中間者装置から受信したパケットである。TTL に11を入れてパケットを送信すると、その邪悪な装置から応答が返ってこない。
traceroute の IP アドレスを見ると、中間者装置が、中国の主要サービスプロバイダである中国聯合通信（China Unicom）の基幹回線上にあるとはっきり証明できる。
次のステップは、中国から http://www.nytimes.com の170.149.168.130といったブロックされているアドレスの方向に traceroute することだ。http://www.linkwan.net/tr.htm というウェブサイトを使うと、以下のような結果が得られる。
これは、グレートファイアウォールが中国聯合通信の基幹施設内で動いていることを示している。
結論
自分であつらえた http-traceroute を使い、私は GitHub を攻撃する中間者マシンが、中国のグレートファイアウォール上かその付近にあることを証明した。ハッカーがこれらのマシンに侵入しているとかいろいろ言い訳は可能だが、GitHub の攻撃元として間違いなくもっとも疑われるのは、中国政府である。
これは我々の政府にとって重要な証言である。我々の政府がこれらの攻撃――アメリカ合衆国のインターネットの重要基盤に対する国民国家による攻撃である――にどのように応対するか見るのが楽しみだ。