Hokkaido.cap#2 一般的なプロトコルのパケットを覗いてみよう

一般的なプロトコルのパケットを覗いてみよう

Hokkaido.cap #2

2011.04.22

Masayuki YAMAKI

今日の目標

• 一般的なプロトコルのパケットがどのようなものか理解しましょう。

• 各プロトコルのパケットがWiresharkからどのように見えるか確認しましょう。

• 前回に引き続き、Wiresharkの使い方を覚えましょう。

2

前回のおさらい

• 第1回目の資料「Winresharkの使い方（基礎編）」を以下のURLで公開しています。Wiresharkを初めて使う方は参照しながら進めてみてください。

http://handsout.jp/slide/3623

• 操作方法がわからない場合は、遠慮せずにどんどん質問してください。

3

今日の進め方

• 「実践パケット解析第6章一般的なプロトコル」

の内容をベースに進めます。本書をお持ちの方は演習に合わせて参照してください。

• スライドには各プロトコルの概要のみ記載しています。実際のパケットがこのとおりの動きをしているか確認していきましょう。

• 気付いた点やわからない点があれば自由にディスカッションしましょう。

4

5

演習資料

ARP (Address Resolution Protocol)

• サンプルファイル : arp.pcap• RFC 826

• レイヤ3のアドレス（IPアドレス）をレイヤ2のアドレス（MACアドレス）に変換するプロトコル。

• 送信元のノードはARPリクエストをレイヤ2ブロー

ドキャストアドレス（ｆｆ：ｆｆ：ｆｆ：ｆｆ：ｆｆ：ｆｆ）へ送信し、それを受け取ったノードは自分のIPアドレスと合致した場合、自分のMACアドレスをレスポンスとして返す。

6

ARP (Address Resolution Protocol)

• ARPは要求と応答の2つのパケットしか使わない。

7

DHCP (Dynamic Host Configuration Protocol)

• サンプルファイル : dhcp.pcap• RFC2131

• ネットワーク情報（IPアドレス、コンピュータ名等）を提供するプロトコル。

• クライアントはDHCP Discoverパケット（DHCPサーバを

探すためのパケット）をブロードキャストアドレス（255.255.255.255）へ送信し、DHCPサーバがこのアドレスを受け取るとクライアントにDHCP Offerパケット（クライアントに提供するネットワーク情報）を送信する。

8

DHCP (Dynamic Host Configuration Protocol)

• 次に、クライアントはDHCPサーバの提示したアドレスに問題がなければDHCP Requestパケットを送信し、正式にIPアドレスを要求する。

• 最後に、クライアントがDHCP Ackメッセージを受信すると、その内容に従いIPアドレス設定を行う。

9

TCP/IP と HTTP

• サンプルファイル : http.pcap• TCP (Transmission Control Protocol) : RFC793

- レイヤ4のプロトコル。透過的で信頼性が高く、欠損パケット再送などのエラー訂正機能を持つ。

• IP (Internet Protocol) : RFC791- レイヤ3のプロトコル。通信を可能とするためのアドレッシングを行うコネクションレス型のプロトコル。

• HTTP (Hypertext Transfer Protocol) : RFC2616- Webページを転送するためのプロトコル。

10

パケットヘッダと Ethernet フレーム

11

SourceMAC Address

(6byte)FCS

(4byte)Type

(2byte)

DestinationMAC Address

(6byte)Data

(46~1500byte)

Ethernet Header (IP Header) (TCP Header) Data

IP Header (TCP Header) Data

TCP Header Data

IP ではデータ

Ethernet ではデータ

パケットヘッダの階層構造

Ethernetフレームフォーマット

IPv4 ヘッダフォーマット

12

Version(ﾊﾞｰｼﾞｮﾝ)

IHL(ヘッダ長)

Type of Service(サービスタイプ)

Identification(識別子)

Total Length(パケット長)

Flags(フラグ)

Flagment Offset(フラグメントオフセット)

Source IP Address(送信元IPアドレス)

Option + Padding(オプション + パディング)

Data(TCP,UDP,ICMPなどのプロトコルのヘッダとデータ)

Destination IP Address(宛先IPアドレス)

Time To Live(生存時間)

Protocol(プロトコル番号)

Header Checksum(ヘッダチェックサム)

0 3 4 7 8 15 31(bit)16

TCP ヘッダフォーマット

13

Source Port(送信元ポート番号)

Sequence Number(シーケンス番号)

Destination Port(宛先ポート番号)

Option + Padding(オプション + パディング)

Data (データ部)

0 3 4 9 10 15 31(bit)16

Acknowledgement Number(確認応答番号)

DataOffset

Reserved(予約領域)

Window Size(ウィンドウサイズ)

Checksum(チェックサム)

Urgent Pointer(緊急ポインタ)

SYN

URG

ACK

PSH

RST

FIN

Code bit

TCP コネクション管理

14

SYN (コネクション確立要求)

ACK (SYNに対する確認応答)SYN (コネクション確立要求)

ACK (SYNに対する確認応答)

FIN/ACK (コネクション切断要求)

ACK (FINに対する確認応答)

FIN/ACK (コネクション切断要求)

ACK (FINに対する確認応答)

コネクション確立後データデータ転送開始

コネクション確立(3 -Way Handshake)

コネクション切断

TCP ヘッダ Codebit

15

Codebit 説明

URG(Urgent)

このビットが1の場合、緊急処理すべきデータが含まれることを意味する。

ACK(Acknowledgement)

このビットが1の場合、確認応答番号のフィールドが有効であることを意味する。コネクション確立時の最初のSYNセグメント以外は必ず1である必要がある。

PSH(Push)

このビットが1の場合、受信したデータをすぐに上位のアプリケーションに渡す。0の場合はバッファリングを許す。

RST(Reset)

このビットが1の場合、コネクションが強制的に切断される。何らかの異常を検出した場合に送信される。

SYN(Synchronize)

このビットが1の場合、コネクション確立の意思表示を表す。また、シーケ

ンス番号のフィールドに格納されている番号でシーケンス番号の初期化が行われる。

FIN(Fin)

このビットが1の場合、今後送信するデータがないことを意味する。それぞれのFINに対して確認応答されるとコネクションが切断される。

サンプル HTTP ファイル

• 4番目のパケットがGETリクエスト

- Follow TCP Stream を使うと一連の通信の流れを特定しやすい。

16

サンプル HTTP ファイル

• 38番目のパケットがOKパケット

17

DNS (Domain Name System)

• サンプルファイル : dns.pcap• RFC1034

• ドメイン名（www.google.comなど）をIPアドレスに変換する。

• たいていの場合、DNSサーバへの名前解決要求→応答という2つのパケットで事足りる。

18

DNS (Domain Name System)

• 実際にキャプチャしてみると１つのWebページで複数のDNSパケットが流れていたり、レスポンスにCNAME（別名に対する正規名）が含まれていることがわかる。

19

FTP (File Transfer Protocol)

• サンプルファイル : ftp.pcap• RFC959• クライアント/サーバ間のデータ転送のためのプロトコル。

• 21番ポートを制御コネクションとして使用し、選択したモードに従いデータ転送コネクションを確立する。

- ACTIVEモード : 20番ポートを使用し、サーバ側からデータ転送コネクションを確立する。

- PASSIVEモード : 任意のポートを使用し、クライアント側からデータ転送コネクションを確立する。

20

FTP (File Transfer Protocol)

• FTPの場合、パケット一覧を確認するだけでも十分な情報が得られる。

- パスワードも見えてしまう。

21

TELNET

• サンプルファイル : telnet.pcap• RFC854

• コンピュータ、ネットワーク機器などをリモートから操作するためのプロトコル。

• 転送レートやデータ転送モードを指定するオプションを指定し、通信を始める前にそれらを同期する必要がある。

22

TELNET

• 平文で通信するため、セキュリティ上問題となる場合がある。

- 重要なデータは、より安全なSSHを使用したほうがよい。

23

MSNMS (MSNメッセンジャーサービス)

• サンプルファイル : msnms.pcap

• Microsoft社が提供しているインスタントメッセンジャーサービスのプロトコル。

• インスタントメッセンジャーにはいくつか種類があり、それぞれ似てはいるが独自のプロトコルを使用している。

24

ICMP (Internet Control Message Protocol)

• サンプルファイル : icmp.pcap• RFC792

• IPのエラーメッセージや制御メッセージを転送するプロトコル。

• ICMPパケットには必ず数字で表わされるタイプ

が含まれており、その数字によって送信先コンピュータでの処理方法が変わる。

25

ICMP タイプの例

26

タイプ 説明

0 エコー応答 (Echo Reply)

3 宛先到達不能 (Destination Unreachable)

4 発信元抑制 (Source Quench)

5 リダイレクト (Redirect)

8 エコー要求 (Echo Request)

9 ルータアドバタイズ (Router Advertisement)

10 ルータ選択 (Router Selection)

11 時間超過 (Time Exceeded)

12 パラメータ問題 (Parameter Problem)

タイプ 3 （宛先到達不能）のコード

27

コード 説明 コード 説明

0 Netwrok Unreachable 8 Source Host Isolated

1 Host Unreachable 9 Network Administartively Prohibited

2 Protocol Unreachable 10 Destinantion Host Administartively Prohibited

3 Port Unreachable 11 Network Unreachable For TOS

4 Fragmentation Needed and DF (Don't Fragment) set

12 Host Unreachable For TOS

5 Source Route Failed 13 Communication Administratively Prohibited

6 Destination Network Unknown 14 Host Precedence Violation

7 Destination Host Unknown 15 Precedence Cutoff in Effect

28

まとめと参考資料

この演習のまとめ

• 一般的なプロトコルのパケットがWiresharkでどのように見えるか確認しました。

• 実際のトラブルシューティングでは「プロトコルの本来の動き」とはどういうものか知っていると問題の早期解決に繋がります。

• テキストに載っていないプロトコルについても、興味があればキャプチャして覗いてみましょう。

29

参考資料

• 実践パケット解析 - Wiresharkを使ったトラブルシューティング

- http://www.oreilly.co.jp/books/9784873113517

- ISBN978-4-87311-351-7

• RFC Editor （RFCの公開および管理機関）

- http://www.rfc-editor.org

• RFC 日本語版リスト （原文へのリンクもあり）

- http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html

30