ケーススタディ （基礎編）

Hokkaido.cap #3

2011.05.20

Masayuki YAMAKI

今日の目標

• 実際にネットワーク上で起こるトラブルが、Wireshark からどのように見えるか確認しましょう。

• 解析作業をとおして、パケット解析のコツ（見るべきところ）を抑えましょう。

2

前回までのおさらい

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

http://handsout.jp/slide/3623

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

3

今日の進め方

• 「実践パケット解析第7章ケーススタディ（基礎編）」の内容をベースに進めます。

• 本書をお持ちの方は演習に合わせて参照してください。（スライドには概要のみ記載しています）

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

4

5

演習資料

－ 基礎編 －

TCP の通信障害 (1/3)

• サンプルファイル : tcp-con-lost. pcap

• 5番目のパケット以降、通信の再送を繰り返している。 （Retransmission：再送）

- Windowsのデフォルトでは、約9.6秒(※)の間に5回再送を試み、5回とも失敗すると通信が終了する。

6

TCP の通信障害 (2/3)

• 徐々に再送の時間が増えているのがわかる。

- View → Time Display Format → Seconds SinceBeginning of Capture でキャプチャ時間の相対表示

» 0.2 → 0.6 → 1.2 → 2.4 → 4.8 [秒]

7

TCP の通信障害 (3/3)

• 応答確認番号（ACK=5481）とシーケンス番号（Seq=5841）に注目する。再送が始まった場所を見つけることが原因解明の手掛かりとなる。

8

応答確認番号

（次にほしいデータはシーケンス番号5481です）

シーケンス番号

届かないパケットと ICMP コード (1/2)

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

• 1番目のパケットで 10.2.10.2 → 10.4.88.88 にEchoリクエストを送信しているのに、2番目のパケットでは 10.2.99.99 が応答を返している。

- 正常な場合は本来の送信先である 10.4.88.88 がEchoリプライ（ICMPタイプ0）を返す。

9

届かないパケットと ICMP コード (2/2)

• 2番目のパケットの詳細でICMPの部分を展開すると、ICMPタイプ3のコード1（ホスト到達不能）が返っていることがわかる。

- すなわち、Echoリクエストが送信先ホストに到達できなかったことを示している。

10

IP フラグメンテーション (1/2)

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

• 「Fragmented IP Protocol」が表示されている。（補足： “TCP segment of a reassembled PDU “ は TCPレイヤでの分割）

- Ethernetで1回に送信できるパケットサイズ : 1,500byte- IPでは分割されたパケットを送信するとき、その順番を示す「オフセット値」を用意する。

- オフセット＋データサイズが次のパケットのオフセット値

11

IP フラグメンテーション (2/2)

• 1つ目のパケット

- Flags ： 1

- Flagment offset ： 0

12

• 3つ目のパケット

- Flags ： 0

- Flagment offset ： 2960

13

演習資料

－ 実際のトラブル －

接続不能 (1/4)

• BarryのPCは問題なくインターネットに接続できますが、BethのPCはインターネットに接続できません。原因を調べてみましょう。

14

ねぇ、なんでおれのPC ネット見れねーの？ ねぇなんで？

知るかボケ。自分で調べろや。

接続不能 (2/4)

• サンプルファイル : barryscomputer. pcapbethscomputer.pcap

• 正常に接続できるPCのキャプチャファイルと、接続できないPCのキャプチャファイルを比較し、原因を探る。

• ベースライニング

- 正常な状態を記録しておいて、それを基軸（ベースライン）として現状との相違点を調査する手法。

15

接続不能 (3/4)• barryscomputer. pcap

- ARP → ３ウェイハンドシェイクの後にHTTP通信開始

16

• bethscomputer.pcap- ARPの後にNetBIOS通信が開始されている

接続不能 (4/4)

• Windowsの場合、NetBIOSはTCP/IPが機能しなかったときに使われることが多い。

- TCP/IPを使ってインターネットへの接続を試みたが接続できず、かわりにNetBIOSを使用した。（NetBIOSも失敗）

• Barryのキャプチャファイルの異なる点は、

- ARP Responseが返っていない

- ARP Requestが要求しているIPアドレスが192.168.0.10 ではなく、192.168.0.11

17

→ 原因はデフォルトゲートウェイの設定ミス

Internet Explorer の悪魔 (1/3)

• Chadのブラウザのホームページは毎回気象サイトを

表示するようになってしまい、設定を変更しても元に戻ってしまいます。何が起こっているか調べてみましょう。

18

天気しか見れねぇ…おわっとる。

Internet Explorer の悪魔 (2/3)

• サンプルファイル : hauntedbrowser .pcap- 何もしていないのに、大量のTCPとHTTP通信が行われている。

19

Internet Explorer の悪魔 (3/3)

• 5番目のパケットを見るとインターネットからデータをダウンロードしているのがわかる。

20

• 11、12番目のパケットは気象サイトへの名前解決。

原因はPCの起動時にバックグラウンドで

動作するデスクトッププログラム

→

FTP サーバとの通信 (1/3)

• FTPクライアントからFTPサーバへアクセスすることがで

きません。クライアント、サーバ双方のパケットをキャプチャして調べてみましょう。

21

アップロード遅いよ！なにやってんの！？（ブライトさん風に）

FTP サーバとの通信 (2/3)• サンプルファイル : ftpclientdenied .pcap

22

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

• サーバ／クライアントのキャプチャファイルの内容はほとんど同じ。

• クライアントからSYNパケットを3回送信している。

- 送信元ポート番号が異なるのはキャプチャしたタイミングの違いであり、ここでは問題ではない。

FTP サーバとの通信 (3/3)

• ここでわかることは「クライアントからサーバにパケットが届いているが、サーバが応答していない」ということである。

• 考えられる主な原因は、

- サービスが稼働していない

- パケットが意図的にブロックされている（Windowsファイアウォールなど）

23

このパケットだけではトラブルそのものの原因はわからないが、問題がサーバ側にあることまで切り分けができ、問題の早期解決に繋がる。

→

私のせいじゃない (1/2)

• Erinがオンラインで製品の注文フォームを送信すると、毎回 HTTP 403 Forbidden になります。彼女はこれを社内ネットワーク側の問題であると疑っています。

• 原因を調査し、問題はWebサイト側にあることを証明しましょう。

24

私のせいじゃないですぅ。オムライスも食べれない

ですぅ。＞＜

私のせいじゃない (2/2)• サンプルファイル : http-fault-post .pcap

• 403のエラーを返している9番目のパケットを右クリックして Follow TCP Stream を実行。

25

クライアントからサーバにデータを送信していることがわかる。

→

悪魔のプログラム (1/5)

• MundieのPCがスパイウェアに感染しました。

• ここではすぐにスパイウェアを除去するのではなく、このPCがどのような挙動をしているか追跡してみましょう。

26

エロサイト見てたら感染した。おれ、

クビかな？

気にすんな。今日は飲み行くぞ。

悪魔のプログラム (2/5)

• サンプルファイル : evilprogram.pcap• 特徴的なパケット

- 3番目：外部から5554番ポートへのアクセス

- 5番目：外部から9898番ポートへのアクセス

» これらはPC起動中（DHCP初期化中）のため破棄されるが、通信可能になると受け取ってしまう。

» その後、MundieのPCにIPアドレス 24.6.125.19 が割り当てられ通信可能となる。

- 10番目～：引き続き外部からのアクセスがあるが、MundieのPCでは該当ポートのサービスが起動していないため、RSTパケットを返して通信が終了している。

27

悪魔のプログラム (3/5)• 正常な通信をフィルタする

- 68番目～：McAfeeのupdateが開始

» 今回のケースでは正常な通信は解析の邪魔になるため、ディスプレイフィルタで非表示にする。

• 特徴的なパケット（続き）

- 147番目：外部からのMessenger

» バイナリ部をみるとメッセージの内容がわかる。

» Messengerサービスが無効であるため、Mundieはこのメッセージを見てない。（148番目：ICMP port unreachable）

28

悪魔のプログラム (4/5)- 210番目：1025番ポートへのアクセスにRSTを返していない

» つまり、このポートを使ったサービスが稼働している。

» 以降、357番目までは同様の動き（成功、失敗の繰り返し）

- 357番目：DCERPC （リモートからのプログラム実行）

- 381番目：DNS名前解決（updates.virtumonde.com）

» このサイトとの通信のみ表示するフィルタを適用してみる。

29

Stastics → Conversations24.6.125.19 と 208.48.15.13の通信を右クリックしてApply as Filter

悪魔のプログラム (5/5)

- 386番目：bkinst.exe というプログラムをダウンロードしている

30

このケースではバックグランドで稼働しているRPCサービスを利用してスパイウェアをダウンロードし、実行していた。

→

ちなみに

31

• Mundieさんはクビになっていないのでご安心を。

32

まとめと参考資料

この演習のまとめ

• 実際にネットワーク上で起こるトラブルが、Wireshark からどのように見えるか確認しました。

• 実際のトラブルシューティングでは、膨大なパケットの中からポイントとなる部分を絞らなければなりません。慣れるまで何度も挑戦してみましょう。

33

参考資料

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

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

- ISBN978-4-87311-351-7

• Microsoft Windows Server 2003 TCP/IP 実装詳細- http://technet.microsoft.com/ja-jp/library/cc758746(WS.10).aspx

• Windows XP での TCP/IP と NBT の構成パラメータ

- http://support.microsoft.com/kb/314053/ja

34

写真提供 : ジャイアントパンダ写真集（フリー素材） http://giantpanda.jp