イベントページのリクエストを追跡する

はじめに

Grove のイベントチームは、訪問者が Night Garden Walk の詳細を開く様子を示す信頼できるサンプルを必要としています。実際に記録された HTTP 通信から目的の訪問を見つけ、リクエストとレスポンスを対応付けて、別の分析担当者が開き直せるキャプチャを用意します。

ファイルを開く操作、簡単な端末コマンドの入力、基本的な Wireshark 表示フィルターの適用ができることを前提とします。プログラミングは不要です。このラボでは一貫して Desktop を使います。端末、Wireshark、テキストエディターは同じ練習用コンテナー内にあります。データは制御された環境での記録であり、実際の訪問者のライブ通信ではありません。このラボは独立して開始でき、推定時間には読解と通常の操作ミスも含まれます。

1 回の訪問の完全な通信を切り分ける

このステップでは Cedar の正常な訪問を見つけ、完全な通信をエクスポートします。Desktop から始めます。画面左下のメニューで Applications → Terminal Emulator を開いてください。用意されたキャプチャは入力ファイルなので、変更せずに保持します。次のコマンドで Wireshark を起動し、ファイルを開きます。Wireshark の実行中は端末が使用中になるため、その後は Wireshark のウィンドウで操作します。

wireshark /home/labex/project/event-page/input/casebook.pcapng

タイトルバーの最大化ボタンでウィンドウを広げます。上段はパケット一覧、中段は選択したパケットの説明、下段はそのバイト列です。このファイルにはローカルのイベントサービスへの 3 回の訪問が記録されています。サービスのアドレスは 127.0.0.1 です。クライアントアドレスは異なるローカルのテスト用識別情報であり、物理的な別マシンではありません。

パケット一覧の上の表示フィルターバーをクリックし、次の式を入力して Enter を押します。ip.addr はどちらの端点にも一致するので、両方向が残ります。== は等しいことを意味します。表示フィルターは表示だけを変え、入力ファイルのパケットは削除しません。

ip.addr == 127.0.0.2

Statistics → Conversations を開き、TCP タブを選び、必要なら Limit to display filter を有効にします。TCP の会話は双方のアドレスとポートを含みます。Duration には待機時間も含まれるため、1 つの HTTP レスポンスの測定値ではありません。選択した会話が Cedar とイベントサービスを結んでいることを確認し、ダイアログを閉じます。

Info が GET で始まるリクエストを選びます。HTTP はアプリケーションのリクエストとレスポンスのプロトコルです。URI は要求するリソースを示し、ここでは view の値が list、details、programme を選びます。リクエストを右クリックし、Follow → TCP Stream を選びます。必要に応じてスクロールし、両方向の通信を読んでください。Cedar は同じ接続で詳細を 2 回要求します。このため、同じ URI とストリームだけでは 1 つのリクエストを一意に識別できません。

Close で Follow ウィンドウを閉じます。Wireshark にはストリームフィルターが残ります。そのままにしてください。この表示は HTTP と表示されたパケットだけでなく、接続の TCP セグメントも含みます。別の訪問を選んだ場合は、フィルターを Cedar のアドレス式に戻し、Cedar のリクエストで Follow をやり直します。

File → Export Specified Packets を選びます。/home/labex/project/event-page/output/evidence.pcapng に、形式 pcapng、範囲 Displayed、その表示集合内の All packets を指定して保存します。入力ファイルとは別に保存してください。出力名を間違えた場合は、指定名でもう一度エクスポートします。Export Packet Dissections は再利用できるキャプチャではなく要約を生成するため、使用しません。

保存前に Displayed 列と All packets を確認します。例では Cedar の 30 パケットが表示されています。

File → Open で新しい evidence.pcapng を開きます。表示フィルターに http を適用します。GET が 4 件、HTTP レスポンスが 4 件あるはずです。件数だけでなく内容も確認してください。1 つのレスポンスは複数の TCP セグメントにまたがることがあります。元の画面で完全に見えていても、HTTP と表示された行だけをエクスポートすると前のセグメントが欠落する可能性があります。エクスポートを開き直すことで、この問題に気付けます。

レスポンスが欠けたり再構成できなかったりする場合は、元の入力を開き、Cedar のアドレスフィルターに戻して、完全な接続を再度エクスポートします。欠けたレスポンス内容を別ファイルへの手入力で補わないでください。

リクエストと実際のレスポンスを対応付ける

このステップでは 2 回の詳細リクエストを区別し、正しい 4 組を記録します。Wireshark を開いた Desktop から始めます。File → Open で /home/labex/project/event-page/input/casebook.pcapng に戻ります。以下の表のフレーム番号はすべて元の入力の番号であり、再採番されたエクスポートの番号ではありません。

&& で 2 条件を組み合わせると、両方が一致する必要があります。http はデコードされた HTTP メッセージを選びます。

ip.addr == 127.0.0.2 && http

最初の GET を選びます。中段の Hypertext Transfer Protocol を三角形で展開するか、その行を選んで Right Arrow を押します。URI と X-Request ヘッダーを読んでください。この合成アプリケーションは、cedar-01 のようにリクエストごとに固有の識別子を付けています。

Response in frame を探して右クリックし、Go to Linked Packet を選びます。レスポンスの HTTP 部分の Request in frame は元のリクエストを指します。両方向のリンクが重要です。ストリームの最後のレスポンスが最初のリクエストへの応答とは限りません。

レスポンスの JavaScript Object Notation → Object → Member: title を展開し、必要なら中段をスクロールします。または Follow → TCP Stream で完全なアプリケーション通信を読みます。イベントタイトルは Night Garden Walk です。JSON はラベル付きのアプリケーション値を表します。title がラベルで、その後の引用符内の語句が値です。200 の応答コードだけでなく、実際の値を読んでください。JSON 部分が見えない場合は中段をスクロールします。

2 回の詳細リクエストを含め、Cedar の各リクエストで繰り返します。この固定された記録では次の組み合わせになります。

レスポンスへのリンクを比べやすくするため、リクエストの Response in frame を右クリックして Apply as Column を選びます。レスポンス行のセルが空欄なのは正常です。それらには代わりに Request in frame があります。この列は補助であり、必須のプロファイル設定ではありません。繰り返された詳細リクエストが別々のレスポンスを指すことを確認します。

左側の元のフレーム番号と隣の Response in frame を読みます。2 回の詳細リクエストはフレーム 16 と 27 に対応します。

短い引き渡し表を GUI のテキストエディターで作ります。再び Applications → Terminal Emulator を開き、Desktop に別の端末を作ります。mousepad は用意されたエディターを開き、絶対パスは出力ファイルを指定します。

mousepad /home/labex/project/event-page/output/pairs.csv

次の CSV 全体を入力します。CSV はフィールドをコンマで区切り、1 行に 1 レコードを置きます。ヘッダーは列名です。これらのタイトルにはコンマがないので、追加の引用符は不要です。

request_frame,response_frame,title
4,10,Night Garden Walk
12,16,Night Garden Walk
17,21,Night Garden Walk
23,27,Night Garden Walk

Ctrl+S で保存します。保存ダイアログが出たら、正確な出力ディレクトリと pairs.csv を確認します。ウィンドウまたは下部パネルのボタンで Wireshark に戻ります。CSV の各行を入力の実際のリクエスト・レスポンスリンクと比べます。この表は調査を記録しますが、完全な evidence.pcapng の代わりにはなりません。

まとめ

Wireshark の会話統計と Follow TCP Stream で 1 回の訪問を切り分け、完全なエクスポートを開き直し、繰り返される HTTP リクエストをそれぞれのレスポンスに対応付けました。元の入力は変更されていません。エクスポートしたパケットと短い対応表は独立して検証できます。