そのパケットは、どこから来たのか？

トレースバック技術とは

　トレースバック技術、と言っても実はその意味は幅広い。3つのケースに分類して考えてみよう（図2）。

　1つ目は「発信源の探知」で、問題となるパケットを発信している端末を特定するケースである。これが最もイメージしやすく、かつ技術的に難しいケースだろう。経済格差も技術格差もあるインターネット全体でこんなことができるようになるのか、筆者自身もまだわからないが、単一組織が隅々まで完全にコントロールするネットワークなら、設備投資すれば可能だろう。ミッションクリティカルな巨大ネットワークでは、いずれ必須の機能になるであろう。

　2つ目は「送信経路の復元」である。これは、例えばチェコからドイツを経由して、ロンドンに入ってアメリカを渡って日本へ来ている、というような送信経路がわかれば、あるいはその一部だけでもわかればトラブルシューティングの役に立つ、というケースである。つまり、日米を結ぶリンクを経由しているのか、日韓を結ぶリンクを経由しているのかわかるだけで、対策が立てられる場合もあるということだ。また経由しているプロバイダーが1つわかるだけで、手が打てる場合もあるだろう。深夜なので上流プロバイダーには連絡がつかないが、さらに上流のプロバイダーは現地時間で昼間なので連絡がついた、というケースもある。

　3つ目は「流入口の探知」で、どの隣接プロバイダーから、あるいはどの加入者から流入しているかわかればよい、というケースである。大きなISPになればなるほど隣接プロバイダーは増えるので、オペレーターが思っていたのとまったく違うリンクから流入していた、なんて言うこともある。あて先への行きの経路はtracerouteで簡単に確認できるが、戻りの経路が実際どうなっているのかを、他人の手を借りずに、確実に確認する方法はこれまでなかった。

トレースバック技術で何ができるのか

　トレースバックは、これら三種類のトラブルシューティングに要する時間を飛躍的に短縮にする技術だ。これまでできなかった、というわけではない。今でもコマンドを一生懸命たたけば人手で流入口を探知することもできるし、発信源を探知することだってできる。逆探知なんてできない、と技術者に言われているマネージャ諸兄はだまされていると思った方がいい。単にオペレーターが「できない」と言い張っているだけである。単純な話、人手でやるとたいへん手間がかかるのである。

　要するに、20分かかっていた作業が2秒でできるようになれば「できない」が「できる」に変わり新しい対策が打てるのではないかということだ。これがトレースバック技術である。

　もう少し正確には、TCP/IPヘッダーを対象にネットワーク層でトレースバックをする場合、「IPトレースバック」と言う。なおアプリケーション層プロトコルごとに似たような仕組みを作ることもでき、「アプリケーション層トレースバック」にも研究としては取り組んでいる。

　例えばセキュリティーに少しでも詳しい読者なら「踏み台攻撃をどうするのか」と問うだろう。特定の技術でサイバー攻撃がすべて解決できるなら苦労はしないのだが、踏み台攻撃のトレースバックですら可能な場合があるとだけ言っておこう。

　以上の説明で、トレースバック技術は各レイヤにあわせて作られること、逆探知と言ってもトラブルシューティングの目的によって求められる情報が違うこと、がわかってもらえたと思う。では、どういったトレースバック技術が既にあって、使えるのだろうか。次ページで紹介しよう。