Welcome to SapporoWorks! We create stimulating network programs. By a demand from user, SapporoWorks evolves.
トップページ | ソフトウエア | シェアウエア登録 | セキュリティ情報 | 開発情報 | ドキュメント |
ドキュメント > ネットワークスニッファVIGILで学ぶ TCP/IP+Ethernet ネットワーク管理講座 > 最終回

--- 出典（ネットワークマガジン）８月号より --- ネットワークスニファVIGILで学ぶ TCP/IP + Ethernet ネットワーク管理講座 前回は、ネットワーク資源の利用状況確認及びネットワーク上のルータの検出などについて学習した。今回は、「クライアントソフトのバージョン確認」「パスワードの確認」「DHCPサーバの動作確認」について、作者の古谷誠進氏がVIGILでの実装方法を交えながら解説する。 文○古谷誠進 (furuya@sapporoworks.ne.jp) 短期集中連載 最終回 今回の講義内容 1.クライアントソフトのバージョン確認 2.パスワードの確認 3.DHCPサーバの動作確認 ●●●●クライアントソフトのバージョン確認 　ネットワーク管理者はファイアウォールを設置して外部からの不正なパケットによる攻撃からネットワークを守ると同時に、セキュリティホールを抱えたプログラムを使うことの危険性を認識しなくてはいけません。管理するネットワーク内でどのようなプログラムが使われているのか、そして、そのバージョンについても気を配っておくとよいでしょう。 　そんな時に役に立つのがネットワークスニッファです。私が作ったVIGILは、トラフィックの内容からＷｅｂブラウザと電子メールソフトの製品名やバージョン情報を検出できます。 　どうしてトラフィックを分析するとＷｅｂブラウザなどのバージョンが分かるのでしょうか？ 　HTTPでは、リソースを取得するときに「ＧＥＴ」というコマンドを使います。このとき、電子メールのヘッダに非常によく似た方法で、付加情報を併せてサーバ側に送るのが一般的です。ヘッダを使うことで、たとえば「ＪＰＥＧ計しいの画像は表示できないので、もし取得したいリソースがＪＰＥＧだったらいらない」のような情報をＷｅｂサーバに伝えるわけです。 　ＧＥＴのようにクライアントに要求するときに付けるヘッダのことを「リクエスト（要求）ヘッダ」と呼びます。一般的に、Ｗｅｂブラウザはリクエストヘッダの中の「User-Agent」というヘッダフィールドにクライアントの識別情報を記入しています。たとえばInternetExplorerは、 　User-Agent: Mozikka/4.0 (compatible; MSIE 6.0; Windows NT 5.0;T312461;Q312461) 　のようになります。VIGILはHTTPの通信を検出するとヘッダ部分からUser-Agentの行を取り出し、そのHTTP通信で使われているＷｅｂブラウザとして表示します。 　電子メールの場合はどうでしょうか。電子メールでもメッセージの中で、X-Mailerというヘッダフィールドを使って、送信者の電子メールソフトの製品名やバージョンを記すのが一般的です。たとえば、Outlook Express 5.5 では、 　X-Mailer: Microsoft Outlook Express 5.50.4522.1200 　のようなヘッダフィールドが付くはずです。VIGILは、SMTPの通信を検出すると、送信されたメッセージのヘッダ部分からX-Mailerの行を取り出し、送信者が使った電子メールソフトとして表示します。 やってみよう！−クライアントソフトのバージョン確認 192.168.0.10の端末がブラウザとして「MSIE 5.5;Windows NT 5.0; T312461」、 メールクライアントとして「Microsoft Outlook Express 5.50.4807.1700」を使用しているのが分かる。 　 　一覧ウインドウ（左上）で端末を選択したとき、表示ウインドウ（右上）の「Default」に表示されている項目のうち、「BROWSER」に表示されているのが、Ｗｅｂブラウザ、「MAILER」に表示されているのが電子メールソフト。 ●●●●パスワードの確認 　勤務先のネットワークで個人加入のプロパイダのPOP3のサーバを利用したり、Ｗｅｂメールで私的なメッセージをやり取りしているユーザを多く見かけます。社内のネットワーク用のパスワードはまだしも、インターネットでパスワードを使うことの危険を知らせるためには、実際にパスワードが暗号化されずにやり取りされていることを見せるのが効果的です。 　VIGILでは、HTTPとPOP3の基本認証でやり取りパスワードの表示に対応しています。もちろん、VIGILはクラッキングツールではありません。パスワードを表示するといっても、暗号化されたものを解読するのではなく、最初からネットワークを流れているものを表示するだけです。 ●●●●ＨＴＴＰの認証 　HTTPにおける認証を順を追ってみましょう。まず、Ｗｅｂサーバは、アクセスが制限されたディレクトリへの要求があると401(Authorization Required)のステータスコードで応答します。応答時のヘッダフィールドには、 WWW-Authenticate: <認証方式> "realm=" <領域名> のような形式で、アクセスするための条件がＷｅｂブラウザに伝えられます。 　Ｗｅｂブラウザは、401の応答に対して、ユーザ名とパスワードの入力を促すダイアログを表示します。ダイアログにある「領域」の部分には、Ｗｅｂサーバからの応答にある領域名です。 　ユーザがユーザ名とパスワードを入力すると、Ｗｅｂブラウザはもう一度要求を送信します。今度は要求ヘッダの中に Authrization: <認証方式><認証文字列> の形式で認証情報を含めます。HTTPの認証方式では、いまでも「基本認証」というやり方が広く使われています。基本認証では、ユーザ名とパスワードはAuthorizationヘッダフィールドの認証文字列として、「ユーザ名=パスワード」の形式でＷｅｂサーバに伝えられます。ネットワークスニッファで認証文字列を取得すると、一見、パスワードそのものとは異なる文字列になっています。ただし、これは「ユーザ名=パスワード」の文字列を単純にBASE64という方法でエンコードしただけなので、簡単に元の文字列に変換できてしまいます。 　Ｗｅｂサーバの認証文字列を受け取るとBASE64でデコードします。有効なユーザ名とパスワードが含まれていれば、URLで要求されたリソースが送られてきます。そうでなければ、Ｗｅｂサーバは同じく401のステータスを応答し続けるのです。 　では、ユーザが異なるディレクトリに移動したらどうなるでしょうか？Internet Explorerを初めとして、現在使われるＷｅｂブラウザは、最初に認証を受けたディレクトリの下位に移動しても、あらためてダイアログが表示されることはありません。ユーザからは最初の認証ダイアログにパスワードを入れたことで、そのＷｅｂサイトすべてのＷｅｂページについて、ユーザに対しては接続を許可してくれたように見えます。 　しかし、HTTPはステートレスな（=状態管理のない）プロトコルです。クッキー（cookie）のような仕組みを使わない限り、ＷｅｂサーバとＷｅｂブラウザの関係は１回の要求と応答で終わってしまいます。実際には、アクセス制限のあるディレクトリは２回目以降も認証が必要なのです。とはいえ、いちいちユーザにダイアログを表示していたのは面倒です。そこでＷｅｂブラウザは最初に認証を受けたディレクトリとその下位のディレクトリへの２回目以降の要求について、初めに入力したパスワードを自動的にAuthorizationのヘッダフィールドとして追加しているのです。 ●●●●POP3の認証 　POP3は、SMTPと同様のテキストベースのプロトコルです。CRLFで区切られた１行ごとの要求と、その応答によってメールサーバからメッセージを取得します。POP3の認証は、接続後にサーバからの挨拶文に対して、 USER john *OK のようにすることで始まります。USERコマンドが成功すると「+OK」の応答がありますので、続けて PASS s1e2c3r4e5t6 のようにパスワードを送信します。POP3の認証はユーザ名もパスワードもまったく暗号化されず、テキストそのものを送信するので、内容を簡単に取得できるのです。 　そこでPOP3の認証を改良したAPOPが誕生しました。APOPの認証では「チャレンジ＆レスポンス方式」が使われています。サーバに接続する挨拶文として +OK POP3 Server Ready.<11.22@pop3.example.com> のように「チャレンジ文字列」が送られてきます。電子メールソフトは APOP john <MD5ダイジェスト文字列> のようにパスワードそのものではなく、MD5ダイジェスト文字列を応答する仕組みです。MD5ダイジェスト文字列は、挨拶文に含まれる「<11.22@pop3.example.com>s1e2c3r4e5t6」のような文字列を作り、この文字列からMD5でダイジェスト文字列を算出します。チャレンジ文字列は毎回変わるので、本当のパスワードを知っているメールサーバとメールクライアントだけが正しいMD5ダイジェスト文字列を計算できるはずです。したがって、VIGILでパスワードを読みとれるといっても、旧来からのUSER/PASSコマンドによる認証だけです。 やってみよう！−ユーザ名とパスワードの確認 192.168.1．１０の端末が次のようなユーザ名とパスワードを使用していることが分かる (1) 192.168.1.1のメール（POP3)サーバに、ユーザ名user1、パスワード123のアカウント。 (2) 192.168.1.1のＷｅｂサーバに、ユーザ名user1、パスワードuser1の基本認証でアクセスしている。 　一覧ウインドウ（左上）で端末を選択したとき、表示ウインドウ（右上）の「Default」に表示されている項目のうち、「PASSWD」の項目が認証に使用されたユーザ名とパスワードです。使用されたサーバのＩＰアドレスとプロトコルの種類も表示されています。「PASSWD」の項目は、認証データを取得できたときのみ表示されます。 　ちなみに、VIGILは、入力された　ユーザ名とパスワードが、誤入力などで正しくなくても表示します。 ●●●●ＤＨＣＰサーバの動作確認 　ＤＨＣＰは、古くから存在するＢＯＯＴＰの上位互換プロトコルです。やり取りされるメッセージの内容は、元になったＢＯＯＴＰをそのまま使っています。ＢＯＯＴＰで使われていた仕組みを拡張し、ＩＰアドレスだけでなく、クライアントがネットワークに参加するためのパラメータ（サブネットマスク、ゲートウエイアドレス、ドメイン名など）までサーバが集中管理し、動的に割り当てるようにしたのがＤＨＣＰです。 　ＢＯＯＴＰメッセージの最後のフィールドであるオプション領域はデフォルトで64バイト（オクテット）に制限されています。しかし、その先頭4バイトが後続のデータを解釈するためのモード決定（マジック・クッキー）に使われています。この４バイトを１６進数で「63825363」と指定すると、後続のデータが自由形式になります。ＤＨＣＰでは、この最大312バイトの領域を使うことで、ＢＯＯＴＰでは定義されていない、サブネットマスク、デフォルトゲートウエイ、ＤＮＳサーバ、ドメイン名などの情報を扱います。 　ＤＨＣＰでは、ＢＯＯＴＰ同じくＵＤＰパケットが使われます。ＤＨＣＰサーバはＵＤＰポートの67で待ち受け、クライアントはＵＤＰポート68でサーバからの応答を待ち受けます。VIGILでは、このポート番号の組み合わせにもとづいてＤＨＣＰパケットを検出し解析し、表示します。 　ＤＨＣＰメッセージのやり取りは、クライアントがサーバを見つけるために、最初に検出メッセージ（ＤＨＣＰ　ＤＩＳＣＯＶＥＲ）をブロードキャストで送信することから始まります。検出メッセージを受信したサーバは、その応答として、送信元のクライアント宛てにユニキャストで提供メッセージ（ＤＨＣＰ　ＯＦＦＥＲ）を送信します。提供メッセージを受けたクライアントは、あらためて、そのサーバに対し、要求メッセージ（ＤＨＣＰ　ＲＥＱＵＥＳＴ）を送信します。そして、ＤＨＣＰサーバはその応答として、肯定応答メッセージ（ＤＨＣＰ　ＡＣＫ）または、拒否応答メッセージ（ＤＨＣＰ　ＮＡＫ）を送信します。また、クライアントはアドレスが必要なくなったとき、解放メッセージ（ＤＨＣＰ　ＲＥＬＥＡＳＥ）を送信します。 　ＤＨＣＰの障害としては、ネットワークに参加したＰＣのＩＰアドレスがまったく無効なアドレスになったり、そもそも取得できずに「０．０．０．０」になったりするケースがあります。ネットワークをモニタしてみて、クライアントから正常に検出メッセージが送信されているのに、サーバからの提供メッセージの応答がない場合は、ＤＨＣＰサーバが停止または正常に機能していない可能性が高いです。 　ＤＨＣＰ障害時の別の事象として、予想外のＩＰアドレスを取得するというものがあります。サーバ系のＯＳを新しくインストールした時に、ＤＨＣＰリレーエージェント（ＢＯＯＴＰ転送）の機能が有効になってしまい、別の部署にあるＤＨＣＰサーバからＩＰアドレスを取得するなどが原因です。 　ＤＨＣＰの最初の検出メッセージは、ブロードキャストされます。そのため、ネットワーク内に２つ以上のＤＨＣＰサーバがあると、それぞれが提供メッセージを送信します。クライアントは２つ以上の提供メッセージを受信すると最初に到着したメッセージのサーバと以後の更新を続けることになります。ただし、ネットワークに２つ以上のＤＨＣＰサーバがあったとしてもからなず障害が起こるわけではなく、ＰＣのネットワーク的な位置によっては正常に機能してしまいます。問題が起こるまで気がつかないわけです。 　Windowsは、 >ipconfig /release を使って、取得中のアドレスを解放し、あらためて、 >ipconfig /renew とすることでアドレスの解放と取得をユーザが制御できます。このときネットワークスニファを使って、適切なＤＨＣＰサーバからの提供メッセージ応答があるかどうか、予想外の他のＤＨＣＰサーバが提供メッセージを送信していないかを確認できます。クライアントから送信された検出メッセージのブロードキャストを受け取ったネットワーク内のすべてのＤＨＣＰサーバはかならず、提供メッセージを送信してくるはずです。 やってみよう！−ＤＨＣＰサーバの動作確認 　VIGILには、目的とするパケットだけを抽出するために、フィルタの機能があります。そこで、ＤＨＣＰメッセージだけを表示するために、次のようなフィルタを設定します。 １　「Frame」タブで、何もチェックしないで、Deny（破棄）を選択 ２　「Type」タブで、ＩＰにチェックして、Accept（保存）を選択 ３　「Protocol」タブで、ＵＤＰにチェックして、Accept（保存）を選択 ４　「IP Address」タブで、何もチェックしないで、Deny（破棄）を選択 ５　「Port」タブで、67-68の項目を追加してチェックし、Accept（保存）を選択 ６　「Data」タブで、何もチェックしないで、Deny（破棄）を選択 　以上の設定でキャプチャすると、DHCP以外のパケットは保存されないため、各端末の階層下には、それぞれが送信したＤＨＣＰメッセージだけが表示されます。各メッセージを選択し、表示ウインドウ（右上）に表示される内容表示画面で、「ＤＨＣＰ」の中の「オプション」を展開すると最初の項目に、ＤＨＣＰパケットの種類（メッセージタイプ）を確認できます。また、「オプション」の部分で、ルータ、ＤＮＳサーバ、ドメイン名などを追加情報として取得している場合は、その内容を確認できるでしょう。 　なお、IPアドレスを持たない端末が最初に送信するブロードキャストの検出メッセージパケットは、当然送信元ＩＰアドレスの情報がありません。（通常、0.0.0.0になっています）。VIGILの一覧表示ウインドウ（左上）は、端末をIPアドレスで識別して表示しているため、IPアドレスを持たないパケットは分類できないため、階層下に表示できません。この場合、ログウインドウ（下）に時系列に表示されているパケットを選択して内容を確認して下さい。 SMTP Simple Mail Transfer Protocol 電子メールを送受信し、サーバ間を中継させて、宛先のメールボックスに配信するためのプロトコル POP3 Post Office Orotocol version 3 電子メールの受信用プロトコル HTTP HyperText Transfer Protocol ＷＷＷでデータを送受信するためのプロトコル BASE64 MIMEで定義されているエンコード方式。8ビットのデータを6ビットごとに64種類の文字に変換することで、バイナリデータをテキストとして扱える URL Uniform Resource Locator インターネット上のリソースの場所とその取得方法を統一的に表記する方法 クッキー Ｗｅｂサーバが利用するためにＷｅｂブラウザが保管するテキストファイルのこと APOP Authenticated Post Office Protocol POP3のログイン機能の安全性を強化するために、従来のUSER/PASS に代えて使うコマンド、またはその機能 MD5 Message Digest version 5 ある情報を端的に表すy=f(x)があったとき、yをハッシュ値という。MD5はハッシュ値を算出するための方法 ダイジェスト文字列 APOPで使うためにMD5で算出された値を文字列にしたもの DHCP Cynamic Host Configulation Protocol ネットワーク上の端末に対して、IPアドレスなどを自動的に割り当てるためのプロトコル BOOTP BOOTstrap Protocol クライアントがネットワーク関する設定をサーバから自動的に取得するためのプロトコル ブロードキャスト 同一ネットワーク内のすべてのホストにデータを送信すること ユニキャスト １つのホストにデータを送信すること 　 BOOTP転送 リレーエージェント。BOOT/DHCPのパケットが異なるブロードキャストドメイン間で行き来できるようにする機能。一般的にはルータが実装する機能

ドキュメント > ネットワークスニッファVIGILで学ぶ TCP/IP+Ethernet ネットワーク管理講座 > 最終回

copyright(c) 1995- SapporoWorks 当サイトはリンクフリーです。リンク時に連絡などは必要有りません。また、どのページにリンクして頂いても構いません。