![TCP の通信障害 (2/3)
• 徐々に再送の時間が増えているのがわかる。
- View → Time Display Format → Seconds Since
Beginning of Capture でキャプチャ時間の相対表示
» 0.2 → 0.6 → 1.2 → 2.4 → 4.8 [秒]
7](https://image.slidesharecdn.com/hokkaido-cap3ensyu-110622101743-phpapp01/85/Hokkaido-cap-3-7-320.jpg)
Hokkaido.cap#3 ケーススタディ(基礎編)
- 1. ケーススタディ （基礎編） Hokkaido.cap #3 2011.05.20 Masayuki YAMAKI
- 2. 今日の目標 • 実際にネットワーク上で起こるトラブルが、 Wireshark からどのように見えるか確認しましょ う。 • 解析作業をとおして、パケット解析のコツ（見る べきところ）を抑えましょう。 2
- 3. 前回までのおさらい • 第1回目の資料「Winresharkの使い方（基礎 編）」を以下のURLで公開しています。 （USBメモリにも収録しています） Wiresharkを初めて使う方は参照しながら進め てみてください。 http://handsout.jp/slide/3623 • 操作方法がわからない場合は、遠慮せずにど んどん質問してください。 3
- 4. 今日の進め方 • 「実践パケット解析 第7章 ケーススタディ（基礎 編）」の内容をベースに進めます。 • 本書をお持ちの方は演習に合わせて参照してく ださい。 （スライドには概要のみ記載しています） • 気付いた点やわからない点があれば自由に ディスカッションしましょう。 4
- 5. 演習資料 － 基礎編 － 5
- 6. TCP の通信障害 (1/3) • サンプルファイル : tcp-con-lost. pcap • 5番目のパケット以降、通信の再送を繰り返して いる。 （Retransmission：再送） - Windowsのデフォルトでは、約9.6秒(※)の間に5回 再送を試み、5回とも失敗すると通信が終了する。 6
- 7. TCP の通信障害 (2/3) • 徐々に再送の時間が増えているのがわかる。 - View → Time Display Format → Seconds Since Beginning of Capture でキャプチャ時間の相対表示 » 0.2 → 0.6 → 1.2 → 2.4 → 4.8 [秒] 7
- 8. TCP の通信障害 (3/3) • 応答確認番号（ACK=5481）とシーケンス番号 （Seq=5841）に注目する。再送が始まった場所 を見つけることが原因解明の手掛かりとなる。 応答確認番号 （次にほしいデータはシー ケンス番号5481です） シーケンス番号 8
- 9. 届かないパケットと 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
- 10. 届かないパケットと ICMP コード (2/2) • 2番目のパケットの詳細でICMPの部分を展開す ると、ICMPタイプ3のコード1（ホスト到達不能） が返っていることがわかる。 - すなわち、Echoリクエストが送信先ホストに到達でき なかったことを示している。 10
- 11. IP フラグメンテーション (1/2) • サンプルファイル : ipfragments. pcap • 「Fragmented IP Protocol」が表示されている。 （補足： “TCP segment of a reassembled PDU “ は TCPレイヤでの分割） - Ethernetで1回に送信できるパケットサイズ : 1,500byte - IPでは分割されたパケットを送信するとき、その順番を 示す「オフセット値」を用意する。 - オフセット＋データサイズが次のパケットのオフセット値 11
- 12. IP フラグメンテーション (2/2) • 1つ目のパケット • 3つ目のパケット - Flags ： 1 - Flags ： 0 - Flagment offset ： 0 - Flagment offset ： 2960 12
- 13. 演習資料 － 実際のトラブル － 13
- 14. 接続不能 (1/4) • BarryのPCは問題なくインターネットに接続できますが、 BethのPCはインターネットに接続できません。原因を 調べてみましょう。 ねぇ、なんでおれの PC ネット見れねー の？ ねぇなんで？ 知るかボケ。 自分で調べろや。 14
- 15. 接続不能 (2/4) • サンプルファイル :barryscomputer. pcap bethscomputer.pcap • 正常に接続できるPCのキャプチャファイルと、接続 できないPCのキャプチャファイルを比較し、原因を 探る。 • ベースライニング - 正常な状態を記録しておいて、それを基軸（ベース ライン）として現状との相違点を調査する手法。 15
- 16. 接続不能 (3/4) • barryscomputer. pcap - ARP → ３ウェイハンドシェイクの後にHTTP通信開始 • bethscomputer.pcap - ARPの後にNetBIOS通信が開始されている 16
- 17. 接続不能 (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
- 18. Internet Explorer の悪魔 (1/3) • Chadのブラウザのホームページは毎回気象サイトを 表示するようになってしまい、設定を変更しても元に 戻ってしまいます。何が起こっているか調べてみましょ う。 天気しか見れねぇ… おわっとる。 18
- 19. Internet Explorer の悪魔 (2/3) • サンプルファイル : hauntedbrowser .pcap - 何もしていないのに、大量のTCPとHTTP通信が行わ れている。 19
- 20. Internet Explorer の悪魔 (3/3) • 5番目のパケットを見るとインターネットからデータをダ ウンロードしているのがわかる。 • 11、12番目のパケットは気象サイトへの名前解決。 → 原因はPCの起動時にバックグラウンドで 動作するデスクトッププログラム 20
- 21. FTP サーバとの通信 (1/3) • FTPクライアントからFTPサーバへアクセスすることがで きません。クライアント、サーバ双方のパケットをキャ プチャして調べてみましょう。 アップロード遅いよ！ なにやってんの！？ （ブライトさん風に） 21
- 22. FTP サーバとの通信 (2/3) • サンプルファイル : ftpclientdenied .pcap • サンプルファイル : ftpserverdenied .pcap • サーバ／クライアントのキャプチャファイルの内容はほ とんど同じ。 • クライアントからSYNパケットを3回送信している。 - 送信元ポート番号が異なるのはキャプチャしたタイミン グの違いであり、ここでは問題ではない。 22
- 23. FTP サーバとの通信 (3/3) • ここでわかることは「クライアントからサーバにパケット が届いているが、サーバが応答していない」ということ である。 • 考えられる主な原因は、 - サービスが稼働していない - パケットが意図的にブロックされている （Windowsファイアウォールなど） → このパケットだけではトラブルそのものの原因は わからないが、問題がサーバ側にあることまで 切り分けができ、問題の早期解決に繋がる。 23
- 24. 私のせいじゃない (1/2) • Erinがオンラインで製品の注文フォームを送信すると、 毎回 HTTP 403 Forbidden になります。彼女はこれを社 内ネットワーク側の問題であると疑っています。 • 原因を調査し、問題はWebサイト側にあることを証明し ましょう。 私のせいじゃないですぅ。 オムライスも食べれない ですぅ。＞＜ 24
- 25. 私のせいじゃない (2/2) • サンプルファイル : http-fault-post .pcap • 403のエラーを返している9番目のパケットを右クリック して Follow TCP Stream を実行。 → クライアントからサーバにデータを送信している ことがわかる。 25
- 26. 悪魔のプログラム (1/5) • MundieのPCがスパイウェアに感染しました。 • ここではすぐにスパイウェアを除去するのではなく、こ のPCがどのような挙動をしているか追跡してみましょう。 エロサイト見てた ら感染した。おれ、 クビかな？ 気にすんな。 今日は飲み 行くぞ。 26
- 27. 悪魔のプログラム (2/5) • サンプルファイル : evilprogram.pcap • 特徴的なパケット - 3番目：外部から5554番ポートへのアクセス - 5番目：外部から9898番ポートへのアクセス » これらはPC起動中（DHCP初期化中）のため破棄されるが、 通信可能になると受け取ってしまう。 » その後、MundieのPCにIPアドレス 24.6.125.19 が割り当て られ通信可能となる。 - 10番目～：引き続き外部からのアクセスがあるが、Mundie のPCでは該当ポートのサービスが起動していないため、RST パケットを返して通信が終了している。 27
- 28. 悪魔のプログラム (3/5) • 正常な通信をフィルタする - 68番目～：McAfeeのupdateが開始 » 今回のケースでは正常な通信は解析の邪魔になるため、 ディスプレイフィルタで非表示にする。 • 特徴的なパケット（続き） - 147番目：外部からのMessenger » バイナリ部をみるとメッセージの内容がわかる。 » Messengerサービスが無効であるため、Mundieはこのメッ セージを見てない。（148番目：ICMP port unreachable） 28
- 29. 悪魔のプログラム (4/5) - 210番目：1025番ポートへのアクセスにRSTを返していない » つまり、このポートを使ったサービスが稼働している。 » 以降、357番目までは同様の動き（成功、失敗の繰り返し） - 357番目：DCERPC （リモートからのプログラム実行） - 381番目：DNS名前解決 （updates.virtumonde.com） » このサイトとの通信のみ表示するフィルタを適用してみる。 Stastics → Conversations 24.6.125.19 と 208.48.15.13 の通信を右クリックして Apply as Filter 29
- 30. 悪魔のプログラム (5/5) - 386番目：bkinst.exe というプログラムをダウンロードしている → このケースではバックグランドで稼働している RPCサービスを利用してスパイウェアをダウン ロードし、実行していた。 30
- 32. まとめと参考資料 32
- 33. この演習のまとめ • 実際にネットワーク上で起こるトラブルが、 Wireshark からどのように見えるか確認しました。 • 実際のトラブルシューティングでは、膨大なパ ケットの中からポイントとなる部分を絞らなけれ ばなりません。慣れるまで何度も挑戦してみま しょう。 33
- 34. 参考資料 • 実践パケット解析 - 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 写真提供 : ジャイアントパンダ写真集（フリー素材） http://giantpanda.jp 34