このページは乱ことNobuoNakakoが運用する「Etherealを使おう」の一部です。お時間があれば表紙も訪れてやってください

リンク等についてはこちら。間違いを見つけた時や「ここはこうした方が良い」等の意見は遠慮なくこちらまで。


The Ethereal manual (WINDOWS&UNIX Var0.9.12)


Etherealの読み方
調査

Etherealをダウンロードして、パケットをキャプチャしても「〜のパケットが流れている」程度しか見る事ができません

ここではEtherealでICMP(Ping)をキャプチャした結果を元にパケットを解析していく例を説明します。

サンプルデータはここをクリックして下さい。Etherealで開いて見る事ができます。開き方についてはここを参照して下さい。


フレーム(PDU)について

フレームと聞いて「なにそれ?」という方はもしかしたらこれから下の事を呼んでもピンとこないかもしれません。TCP/IP関連のドキュメントを読んでフレーム(PDU)の意味ぐらいは知っておいて下さい。

 フレームはよく下記の様な帯の様な状態で表しています。(とりあえず中身は書きません)

これを16進数に直すと下記の様になります。

 

この16進数を見て何のパケットか分かりますか?「そんなの分かるわけないじゃん」と思っている方、それは間違いです。実はEtherealを使いこなすと上記の様な簡単なデータであれば「どこからどこへのパケット」「なんのパケット」ぐらいは分かる様になります。

上記のパケットはICMPのRequestyのフレームになります。簡単に言うとPingコマンドを入力してこちらからあて先へ対して出した信号になります。

この様な16進で表したフレームをEtherealでは「データフレーム」で確認する事が出来ます。

信号の正体を知る

さて、Etherealでフレームがどの様に表示されるか分かったところで次に知っておかなければならない事があります。

それは信号の正体です。つまり今自分が調査しようとしているパケットは何の信号かを知っている必要があります。単刀直入に言うと「プロトコル名」を知っているという事になります。

Etherealではプロトコル名はデフォルトでメインフレームのカラムに存在していますのでここで確認する事ができます。


※上記のIP211.14.15.5は公開されているYahooのIPです。これはwww.yahoo.co.jpに対してpingを入力したものです。

上記の場合、調査したいパケットの正体はICMPという事がわかります。

ここでとりあえずどれだけ調査を行いたいのかを考えます・・たとえばとりあえずICMPの信号が流れている事を確認したいのであればこれでOKです。どのIPからどのIPへ送信したのかを知る場合もこれでOKです。

ただ、ICMPの何の信号なのか(pingを発信したものかそれともnslookupなのか等)どの様に送信しているのか(チェックサムはあるのかシーケンスは何番か等)を調べる事はこのメインフレームではできません(カラムを変更するという手もありますがそれをここで言ってはダメ(-_-;))

RFCを知る

IETF(Internet Engineering Task Force)という団体が存在します。これはインターネットの基準を定めているIAB(Internet Architecture Board)の下部組織になり、主にインターネットでの技術基準を定めています。

この定められた技術基準をIETFが文書化し公開されているのがRFCになります。RFCは簡単に言うとインターネットのメーカマニュアルみたいなものになります。

メーカマニュアルですからプロトコルについても非常に詳細に記載されており、パケットのフレームを細かく調べるならば必須のドキュメントになります。

基本的には英語で書かれていますがこれを翻訳する団体も日本には複数存在し、日本語ドキュメントも簡単に手に入れる事ができます。

http://www.ietf.org/rfc.html(英語)

さて、今回調べたいのはICMPです。REF番号でいうと792が最適になります。(最適というのは他にもICMPに関するRFCドキュメントが存在するからです)上記サイトのRFC番号検索フォームで「792」と入力してみてください、ICMP(INTERNET CONTROL MESSAGE PROTOCOL)のドキュメントが表示されるはずです。

どのプロトコルのドキュメントがRFCのどの番号になるかはここで調べる事ができます。(ブラウザの「検索」機能等を使って下さい)

又、日本語のRFC辞典なるものも存在しますのでそちらを購入するのも良いかもしれません。

フレームの概要を知る

RFCを読むと分かりますがICMPのフレームは大きく書きの様に3つに分ける事ができます。

これをEthrealで表示される16進数で分けると下記の様になります。

それでは各フォーマットを読んでいきましょう

Ethernetフォーマット

ここで参考になるEthernetについてのRFCは894が相応しいと思います。

さて、Etherenetフレームの詳細は下記の通りになります。

これをEtherealでいう16進数では下記の様になっています。

つまりこのパケットの場合、宛先のEthernetアドレスは08:00:20:fe:67:eeで送信元のアドレスは00:40:ce:2d:44:0bという事になります。

タイプの0800ついては、RFC894によるとEthernetのフレームは16進数で0800という値を持たなければならないという規定がある為この数値を付けています。つまりこのフォーマットがEthernetに関しての情報を持っているという事がこのタイプの値により分かるという事です。

EthernetのフレームはIOSモデルでいう2層になるという事も気に止めておいてください。

IPフォーマット

参考のRFCは791が最適でしょう(ちなみにRFC791は基本中の基本のRFCになります)

IPフォーマットはRFC791で述べている通り、下記の様な形になります。

16進数で表すと下記の様になります。

さて、このフレームの意味についてはICMPだけではなくほとんどのIP信号に共通しています。じっくりと解析していきましょう。(Ethernetフレームもそうですが)
()の中は情報の長さを記しています[]はEtherealの詳細フレームで表示される表記です

  • バージョンについて(4ビット)[Varsion]

このバージョンはIPのバージョンを指しています。現在一般的に使用されているIPはバージョン4になります。この他にバージョン6が存在しますが復旧は復旧はまだまだ先の様です。

Var4なので[4]と表示されている事を確認して下さい。

  • IHLについて(4ビット)[Header length]

IHL(Internet Header Length)IPフレームのヘッダ長を32bitwordで表したものです。つまり32bitで1wordという事になります。実は上の部分(ICMP)では無いのですがパケットによってはIPフレームに「オプション」というヘッダが付く場合があります。これは可変長(情報の長さが定まっていない)の為、IPフレームの全体の長さを示すIHLが必要となります。

実際にはIHLはデータの長さ情報が入っているのではなくデータが開始する位置を記載しています。

正しいヘッダの最小値は5で、上記でも最小値の[5]が表示されている事を確認して下さい(160bit)。最低5ワードですのでこのパケットの実際の長さではなく160ビット以下という意味に注意して下さい(これを説明しない文献が多すぎる)ちなみに最大は150ワード(4800bit)ですがそこまでキャプチャするデバイスはほとんど存在しません。

  • サービスタイプ(8ビット)[Differentiated Services Field]

DSFはIPフレーム自体の「品質」を設定する物です。具体的に言うとデータの優先順位や信頼性等の設定です。

 上記の16進数のデータでは[00]となっています。これがどういう意味かを解説したいと思います。

まず、下記の様にDSFの中身をもう少し細かく表示してみましょう。

上記の様にDSFでは「優先度」「遅延」「スループット」「信頼性」の4つの設定が出来ます。

優先度はビット0〜2の間になります。000が「通常」001が「優先」010が「即時的」011が「瞬間的」100が「瞬間的で且つ最優先」101が「最重要又は緊急命令用」110は「インターネットワーク制御」111は「ネットワーク制御」になります。

遅延についてはビット3で0か1かの設定が可能です。0が「通常」1が「低遅延」になります。

スループットはビット4、0か1の設定で、0が「通常」1が「高スループット」になります。

信頼性はビット5で0か1の設定で、0が「通常」1が「高信頼性」になります。

6ビット〜7ビットまでは将来的に仕様する予定があるらしく予約となっており2003年2月現在の所、まだ意味はありません。

つまり[00]はすべてが「通常」という事になります。Etherealの詳細フレームでは下記の様に表示されています。

  • 全パケット長について(16ビット)[Total Length]

TLは名前の通りヘッダとデータを含む全パケットの長さを表した物です。単位はオクテット、1オクテットは8ビットなので1オクテット=1バイトと考えて下さい。
(1バイト=8ビットとは限りませんが1オクテットはかならず8ビットです)

例の16進数データでは[00 3c]となっています。これを10進数に直すと「60」になります。つまり全体の長さは60オクテット(約60バイト)となります。

  • 識別子について(16ビット)[Identification]

フラグメントの組み立ての再に参照される。いわゆるIPのIDの事。[8845]となっていますがもし組み立てるパケットがある場合(今回の場合ありません)相手の数値は[8846]となるのが一般的です。

  • フラグについて(3ビット)[Flags]

フラグメントの制御部分になります。フラグメントとはTCPストリーム等パケットが分割されている場合、それを結合する事を言います。詳細については下記の通りです。

DFに0が入ると「フラグメント許可」1が入ると「フラグメントの禁止」になります。通常は0です。

MFに0が入ると「このパケットが最終フラグメント」という事になり、1が入ると「次にフラグメントするパケットがある」という事になります。

例では[00]ですので基本的に分割されていないという事になります。

  • フラグメントオフセットについて(13ビット)[Fragment offset]

これはこのパケットが分割されている場合(フラグメント)データグラムのどの位置にあるかを記したものになります。基本は最初の0が入ります。

8オクテット(64ビット)で1フラグメントになりますので注意して下さい。例では[00]ですので最初のフラグという事になります。

  • 生存時間について(8ビット)[Time to live]

TTLの事、インターネット上での(ルータネットワーク上)パケットの寿命を設定しているところです。

ここの値が0になるとこのパケットは破棄されてしまいます。このTTL値はパケットを処理するモジュールを1つ介するごとに1つずつ減っていきます。

単位は秒ですが1秒以内であってもパケットを処理するモジュールを介すると1つ減る事に注意してください。つまりこの数値は実際の寿命ではなく「生存できる最大時間を表示しているという事です」これは当該するパケットが転送できない場合に約にたつものです。

例では[80]となっていますがこれを10進数に直すと[128]になります。前にも述べた様に128秒生存するという訳ではありません。

  • プロトコルについて(8ビット)[Protocol]

このIPのフレームですがIOS参照モデルでいう第3層(L3)になります。このプロトコルは次の層、つまり第4層(L4)の情報を記載しています。

例では[01]と表記されていますがこれはICMPを指しています。

  • ヘッダチェックサムについて(16ビット)[Header checksum]

ヘッダの部分のチェックサムがこれになります。チェックサムとはデータを送受信する際の誤り検出方法の一つになります。

ヘッダ内全ての16ビットワードの1の補数の和(符号なし整数の最大値から絶対値を引き算し 1 を加えたもの)を計算します。

チェックサムする場合はこのフィールドの値を0にし、再計算します。

  • 送信元アドレスについて(32ビット)[Source]

これは送信元のIPアドレスを指しています。

例では[c0 a8 01 33]となっていますがこれを10進数に変換すると[192 168 1 51]となります。つまりIP192.168.1.51が送信元という事になります。

  • 宛先アドレスについて(32ビット)[Destination]

これは宛先のIPアドレスを指しています。

例では[d3 0e 0f 05]となっていますがこれを10進数に変換すると[211 14 15 5]となります。つまりIP211.14.15.5(Yahooのwwwサーバ)が宛先という事になります。

ICMPフォーマット

ここで参照になるRFCは792になります。

さてICMPにはタイプがあります。

タイプNo 意味
0 エコー応答メッセージ
3 宛先到達不達
4 送信元抑制
5 リダイレクト
8 エコー
11 時間超過
12 パラメータ異常
13 タイムスタンプ
14 タイムスタンプ応答
15 情報要求
16 情報応答

例の場合はPingのエコーの信号ですのでタイプ8になります。

タイプ8のフォーマットは下記の様になります。

16進数で表すと下記の様になります。

では例によって解析していきましょう
()の中は情報の長さを記しています[]はEtherealの詳細フレームで表示される表記です

  • タイプについて(8ビット)[Type]

ここでは上の表にあるタイプが記載されます。例では[08]となっていますので8番の「エコー」のパケットという事が分かります。

  • コードについて(8ビット)[Code]

エコーの場合コードは例の通り[00]のみです。このコードはICMPのタイプによっては0以外の数値が入る事があります。

例えばタイプ3の「宛先到達不能メッセージ」ですがこれにはコードが0〜5まであり、コードの数値によって不達の理由がわかる仕組みになっています。

  • チェックサムについて(16ビット)[Checksum]

ICMP部分のチェックサムがこれになります。チェックサムとはデータを送受信する際の誤り検出方法の一つになります。

ヘッダ内全ての16ビットワードの1の補数の和(符号なし整数の最大値から絶対値を引き算し 1 を加えたもの)を計算します。

チェックサムする場合はこのフィールドの値を0にし、再計算します。

例の[42 5c]は計算の結果を表示しています。

  • 識別子(16ビット)[Identifier]

IDになります。基本的にはランダムに入力されます。Windowsのpingの場合、デフォルトでは4回エコーを繰り返しますがその関連を調べるには良いかもしれません。

  • シーケンス番号について(16ビット)[Sequence number]

これもエコーの場合、この番号はping等で役に立ちます。例えば、Pingの場合、Requestに対して正常であればReplyを返しますがこの2つの信号のシーケンス番号は統一されています。

つまりこのパケットに対する返答のパケットを探す場合に使用すれば便利です。(識別子も同じ使い方をできるという方がいますが実際にやってみてください。あまりアテになりません(-_-;)識別子の操作をすれば別ですが・・)

  • データについて(?ビット{pingであればデフォルトでは256ビット})[Data]

ここには実際に送信するデータが入ります。

例を見て下さい[61 62 63・・・・]と数字が並んでいると思いますこれ実は[abcdef・・・]とアルファベットを並べているんです。知ってましたか?WindowsのPingはただ単に256ビット(32バイト)分だけアルファベットを並べて送信してそれを「データ」としています。


以上でEtherealによるICMP(エコー)のパケット解析は終わりです。

どうでしたか?一つのパケットを解析するのにも結構大変です。ポイントとして重要なのは「これから調査するパケットは何のパケットなのか」という事と「RFCドキュメントを読む」という事です。この2つさえ守っていれば非常に高度な解析をEtherealで行う事ができます。


Copyright 2003 by Nobuo Nakako All right reserved.