はじめに

Wiresharkを使用してパケット分析する機会があったので、使い方と基本的な通信の動きについてまとめます。
本記事では、以下書籍参考に作成しています。

概要

こちらのサンプルキャプチャを使用して、分析を進めていきます。

ARP→DNS→TCP→HTTPというきれいな流れができていますので、順番に深堀します。
またそれぞれのIPアドレスとMACアドレスは以下のようになっています。

IPアドレス

クライアントPC：192.168.1.219
デフォルトゲートウェイ:192.168.1.1
DNSサーバ:8.8.8.8
Webサーバ:180.235.36.115

MACアドレス

クライアントPC：8c4c:f4:78:63(aeがなぜか隠れる）
デフォルトゲートウェイ:10:4b:46:b8:48:70
DNSサーバ:外部NW
Webサーバ:外部NW

では以降からそれぞれのパケットについて分析をしていきます。

NO1~2

クライアントPC⇔デフォルトゲートウェイのARPリクエストですね。

ちなみに48ビット（6バイト）のMACアドレスのうち最初の24ビット（3バイト）はOUI（Organizationally Unique Identifier）と呼ばれてベンダーごとに固定されています。

そのため、PCのMACアドレスはPlugable Technologiesのf4:78:63ということになります。
Ethernetの中身ですが、クライアント→デフォルトゲートウェイへの通信を拡大すると以下になります。

Destination がBroadcastになっておりSourceにはクライアントPCのMACアドレスが記載されています。
またその下のTYPEには、続くカプセル化の形式を指定しています。0x0806なのでARPということがわかります。

以下ARPの中身です。

ARP Requestでは、TPYEで次のレイヤーのプロトコルが指定され。またTargetのMACアドレスが空の状態で実施されます。

では返りに通信についてみていきましょう。

これはMACアドレスと次のプロトコルが記載されているだけですね。
次はARPリプライを見ていきます。

しっかりSenderのMACアドレスが埋まっていますね。

NO3~4

デフォルトゲートウェイ⇔DNSサーバの通信で、インターネット層～アプリケーション層（IP→UDP→DNS）の通信です。
まずはインターネット層から見てみましょう

Ethernet ⅡやARPに比べて大きなヘッダです。
項目が多すぎるますが、ざっくり理解すると
・バージョン（version)
・優先順位の設定（DSCP）
・パケットの分割について（Flag）
・パケット破棄までに経由するルータの数（TTL)
・次のプロトコル(Protocol)
・ヘッダの内容に問題がないかの確認(Header Checksum)
・送信元と送信先のIP

が含まれてます。
次はUDPです。

かなりシンプルですね。
ここでポート番号が割り振られていることに注目です。
送信元ポート番号が63861となっていますが、この番号はクライアントのWindowsが利用していないUDPポート番号を動的に割り当てたものです。宛先ポートは53となっており、DNSのアプリケーションを阿波らしていることがわかります。

以下ポート番号についての参考記事です。
53はwell knownポートなので、後に続くプロトコルはDNSであるとわかるんですね。

返りの通信では宛先ポートと送信元ポートが逆になります。

ではいよいよDNSについてみていきましょう。
以下はDNSqueryですね。

その前にDNSについて整理します。
「www.ikeriri.ne.jp」というWebサイトの名前解決は以下の図のように実施されます。
それぞれのネームサーバーのNSレコードを参照して、該当するドメインを下位のネームサーバに聞きに行きます。
注意点として、「www.ikeriri.ne.jp」というFQDNのホスト名の「www」は本当にこのような名前がついているわけではなく、実際にはasashinaというホスト名が紐づけられています。ikeririドメインのウエブサーバであることがわかるようにこのような名前が付けられてています。

では早速ダンプ分析していきます。

といっても割とシンプルで
識別子(transaction ID)
DNSの制御(Flag)
問い合わせ内容(Queries)

といった感じです。
応答には、AレコードとCNAMEレコードの詳細が記載されています。

NO5~7

次はいよいよクライアントPCとWebサーバの通信ですね。
ポイントが多すぎるので、今回は3ウェイハンドシェイクに絞って、分析します。

①クライアントPC→Webサーバ（SYN:0 ACK:0)

今回は、クライアント側のポートが2367で動的に割り当てられています。送信先はWebサーバなので、Wellknownポートの80番となります。
TCP通信の開始時は、SYNフラグを付けてセグメントを送信しています。

➁Webサーバ→クライアントPC（SYN:0 ACK:1)

返りの通信では、送信開始側が送信したシークエンス番号に1を足した値を確認応答番号してセットしています。

③クライアントPC→Webサーバ(SYN:1 ACK:1)

最後に、接続開始側がセグメントを返します。
シークエンス番号は、確認応答番号をそのまま流用します。一方受け取ったシークエンス番号を確認する意味で、応答側から送られたシークエンス番号に1を足した値を確認応答番号にセットします。

NO5~6

ではいよいよ最後のHTTP通信についてみていきます。

重要なところとしては、所定のURLにgetメソッドで情報を取得しに行っているところかと思います。

次に応答メッセージをみていきます。

まずstatus codeに注目です。
200と記載されているので、正常応答であることがわかります。
異常応答の場合は、404をはじめとして、さまざまなエラー応答コードが表示されます。
後に続くのが、キャッシュの有無、コンテンツの種類、エンコード化の種類などです。

こちらが後半です。
こちらには実際のテキストが記載されていますね。この内容がWebブラウザに渡されます。

おわりに

以上です。今後ともパケット分析をする機会はあると思います。
数をこなすにつれて、少しずつ細部まで理解できるように、学習を続けたいです。