パケットキャプチャは取得された環境はパケットの情報に含まれない、と以前の記事「パケットキャプチャをする前に知っておきたいこと」で書きました。ですので、パケットを解析する前にキャプチャ環境を担当者にヒアリングすることは非常に重要です。

ですが、パケットの情報を手がかりにどんな環境でキャプチャされたか、ということを推測できる場合もあります。今回は、パケットのどの情報でどんなことがわかるかを解説します。

SYN-SYN/ACKとSYN/ACK-ACKのデルタ時間からキャプチャポイントを推測する

TCPの３ウェイハンドシェイクの「SYN-SYN/ACK」と「SYN/ACK-ACK」のデルタタイムをみるとどこでキャプチャが設置されているかが推測できます。３ウェイハンドシェイクのパケットで比較する理由は、アプリケーションの処理時間を考慮する必要がないからです。

SYN-SYN/ACKのデルタタイム > SYN/ACK-ACKのデルタタイム

クライアント側に近いところでキャプチャされている可能性が高い

SYN-SYN/ACKのデルタタイム < SYN/ACK-ACKのデルタタイム

サーバ側に近いところでキャプチャされている可能性が高い

図式化すると一目瞭然です。クライアントに近い場所でキャプチャされた場合、黄色の線のほうが緑の線より伝送路が長いため、デルタタイムも長くなります。

パケットキャプチャで遅延をはかる場合は、「どこでキャプチャしたか」が非常に重要になってきます。クライアント側にキャプチャ装置を設置した場合、サーバからのパケットの到着は、サーバ側に設置したときと比べて長くなります。ですので、どちらかのレスポンスが遅い場合、そもそもキャプチャ装置が設置されている位置を確認します。ネットワークにトラブルが起きてなさそうなケースにおいては、３ウェイハンドシェイクでもある程度は推測が可能です。

TTLからホストのOSとホップ数を推測する

IPv4ヘッダには、TTL（Time to Live）が設定されています。TTLは、1オクテットすなわち0-255までの値を持つことが可能で、ルータを1つ超えるごとに1ずつ減っていきます。このTTLの初期値はOSにより異なります。

以前のMac OSやSun OSは、60だったこともありましたが、現在では大半のOSが、64、128、255のどれかです。OSによりTTLが異なっている理由はわかりませんが、調査した限りではRFCでTTLのデフォルト値は、規定されていませんでした。

Client（Windows PC）から、ロケーションが日本にあるクラウド上のServer（SYNESIS）に通信をしたパケットをClientのWiresharkでキャプチャして確認します。Clientが送信元になっているTTLは128となっています。これは、Windows PCから送信しているパケットなので、Windowsの初期値が128であることが確認できます。また、Serverが送信元になっているTTLが58となっていますので、この初期値は64であると推測できます。

ServerのTTLが128や255ではなくなぜ64と推測できるのか、と疑問に思う方もいらっしゃると思います。理由は、通常は大陸を超えても間にルータが50個以上存在している、ということは想定しづらいからです。
ためしに自宅（東京）とアメリカの子会社（サンフランシスコ）で通信をしてみたところ、ホップ数は13でした。日本とアメリカですらこの値ですので、このケースにおいてホップ数が50を超えている、すなわちServer側のTTLの初期値が128や255の可能性は非常に低い、と結論づけられます。

このようにOSの初期値から端末を推測することを「Passive OS fingerprinting」と言いますが、これを逆手に取った攻撃が存在します。そのため、TTLの初期値から推測する手法は、補助的な情報として扱うべきであり、キャプチャされた環境が完全に不明な場合は、他のパラメータと総合的に判断することが重要です。

チェックサムエラーから取得方法を推測する

パケットの取得方法は、以下の図のように２通りあります。
「モニタポート接続」（右図）は、SPAN、TAP、NPBなどモニタ専用のポートを設置し、そのポートにNICを接続する方法です。この場合、キャプチャデバイスはネットワークに参加していないため、キャプチャデバイスが故障したとしてもネットワークに影響を与えることはありません。一般的には、ネットワークの監視等でパケットを所得する場合はこちらの方法が用いられます。
もうひとつの方法として、「通信ポート接続」（左図）があります。こちらは、キャプチャするネットワークに直接NICを接続してキャプチャする方法です。WireshaekがインストールされているPC上で自分自身の通信を可視化する場合に用いられます。

通信ポートでキャプチャした場合、正常に通信しているにもかかわらずIP、TCP、UDPの各チェックサム項目でエラーが表示されることがあります。これは、PCのチェックサムオフロード機能により、チェックサムエラーとなっているだけで実際にチェックサムエラーが発生しているわけではありません。最近のPCは、CPUの負荷を軽減させるためにNICでチェックサムを計算して送信を行う、チェックサムオフロード機能がデフォルトで有効になっていることが多いですので、注意が必要です。

ためしに私の業務用のパソコンでキャプチャをしてみると以下のようにチェックサムエラーがでてきます。

かなり前のバージョンから、Wiresharkでは、デフォルトでIP、TCP、UDPのチェックサム計算機能を無効にしていますので、気がつかないかもしれませんが、IP、TCP、UDPのチェックサムを有効にしてみて、同じ送信元IPからのみチェックサムエラーが発生している場合は、オフロード機能による影響ですので気にする必要はありません。ただし、これは通信ポート接続に限った話です。モニタポート接続でチェックサムエラーとなった場合は、原因は別の可能性があります。

なお、このオフロード機能ですが、キャプチャするアダプタにより機能を無効にできる場合があります。私のPCですと、無線はそれらしき設定は見当たらなかったのですが、有線ではチェックサムオフロードをレイヤーごとに無効にできる設定がありました。
ですので、チェックサムエラーがないからといって、必ずしも通信ポートで取得されたものではない、とは言いきれません。ですが、同じ送信元のIPからのみチェックサムエラーが出ている場合は、そのIPで通信しているPCからキャプチャされたデータである可能性が高いと推測できます。

また、SYNESISをはじめとするパケットキャプチャ専用装置では、ほとんどの場合モニタポートに接続してキャプチャをしますので、このようなチェックサムエラーは発生しません。

あとがき

これらのテクニックは、どちらかというとキャプチャ環境を「特定する」のではなく「この可能性は排除できる」という方向で使うことが多いです。ただし、あくまで「キャプチャ環境が推測できます」、というだけで、推測が当たっているかどうかの保証はできません。パケット解析の際は、パケットを取得した前提条件（事実）を確認、整理することが重要となります。
今回書ききれなかったネタがいくつかありますので、機会があればまた本ブログで紹介したいと考えています。