【レポート】ネットワーク上に流れるパケット観察

【レポート】ネットワーク上に流れるパケット観察

目的と概要

 ネットワーク上に流れるパケットを観察することにより、電子メールとネットワークの仕組みを理解し、他人のパスワードやメール内容を簡単に見ることができることを発見した。また、セキュリティ対策することにより、パスワードやメール本文が見られなくなることを知った。

実験システムの構成および実験方法

 実験は、Thunderbirdというメーラーを用いた。メールにおいて送信をSMTP、受信をPOPというプロトコルを用いた。自分のノートPCにはパケットキャプチャツールのVigilをインストールしてメール内容を読めるようにした。実験システムの構成図をFig.1に示す。

Fig.1実験システムの構成図

 メーラはメールの送受信を行い、POP、SMTPサーバやアカウント、接続プロトコルを設定した。Vigilはハブを通過するパケットをキャプチャした。SMTP、POPサーバはアカウント、パスワード、メールアドレス、プロトコルなどを登録した。実験方法は、メールサーバーとクライアントの設定を行い、メールの送受信を可能したあと他のグループとメールを送受信した。Vigilを用いて送受信したメールパケットを確認した。次にセキュリティプロトコルを変更し、再びメールを送受信し、メールパケット確認した。同様に画像添付のメールも行った。またメールのヘッダを取得しヘッダも確認した。メール以外にはHPを参照しているとき、DNS時のパケットキャプチャをしてみた。

普通状態でのパケットキャプチャ

送受信したメールの内容

 他のペアとメールを送受信して、メールを確認した。Thunderbirdで送信したメールをFig.2に、Thunderbirdで受信したメールをFig.3に示す。

Fig.2 セキュリティをかけていない時のThunderbirdの送信メール
Fig.3 セキュリティをかけていない時のThunderbirdの受信メール

キャプチャしたパケットの内容

 送信したメールの内容を送受信しなかったパソコンからVigilを用いてFig.2の送信メールとFig.3の受信メールを確認した。送信側のIPアドレスは「192.168.1.41」であり、受信側のIPアドレスは「192.168.1.31」であった。送信メールはSMTPプロトコルにあり、受信メールはPOPにあった。送信メールをVigilで見たときのSourceの画面をFig.4に示す。また同様に受信したメールを確認し、Vigilで見たときのSourceの画面をFig.5に示す。 

Fig.4 192.168.1.41のSMTPのSource
Fig.5 192.168.1.41のPOPのSource

 次にVigilからTCPプロトコル上に表示されているパケットに注目した。SMTPはTCPの25番ポートなので確認した。TCP25のDefaultをFig.6に示す。同じくPOPはTCPの110番ポートなので確認し、Fig.7に示す。

Fig.6 192.168.1.41のTCP25番のDefault
Fig.7 192.168.1.41のTCP110番のDefault

 また他の班のメールの確認するためにSMTPとPOPを見てみた。IPアドレスは「192.168.1.61」だった。Fig.8にSMTPのDefaultを、Fig.9にPOPのDefaultを示す。

Fig.8 192.1.68.1.61のSMTPのDefault
Fig.9 192.1.68.1.61のPOPのDefault

分析と考察 

 Fig.4のVigilからSMTPの送信メールを確認してみる。Jikken04からjikken03に送ったので送信者のfromにはjikken04で受信者のToにはjikken03があるのが分かった。日付はUTCから9時間進んでいることが考えられる。Toより下の部分はSubject、Contentがある。これよりSubjectが題名、Contentがメールの本文に関することであると考えられる。Content-Typeと書かれているから本文の形式であると考えた。そこでISO-2022-JPを調べてみると日本語はISO-2022-JPにエンコードして送り出していることが発見できた。ISO-2022-JPの仕組みにそって定義された日本語の文字コードの一つとしてJISコードがあるのも発見できた。JISコードはデータに変換するときに7bitであり、海外はASCIIを扱っていて7bit単位の文字コードで考えていたため電子メールソフトウェアなどと相性が悪く電子メールで日本語を扱う際の標準として広まったものである。以上のことを踏まえて、Contentは文章の形式を表していると考えられる。よって「$b%$%1%a%s(Bdesu $B$M!<!* (B」が本文であると考えられる。同じようなことが受信メールからも確認できた。またSMTPとPOPのTCPを比較すると青文字と赤文字の多さに違いがあった。SMTPは赤文字、POPは青文字である。このことから赤文字はクライアントからのメッセージであり、青文字はメールサーバーからのメッセージであると考えられる。また送信メールに関するFig.4とFig.6と受信メールであるFig.5とFig.7を比べてみる。送信メールはFig.4に書いてあったものがFig.6の下にある赤文字が続いているところと同じものだった。Fig.6のほかの赤文字を見ると送信元と送信先のアドレスを2回メールサーバに送っている。これはメールの誤送信を防ぐため確認しているからだと考えられる。Fig.5とFig.7を比べるとig.5の内容がFig.7の下のほうにある青文字と同じものであったサーバ側から「+OK Logged in」でログインを認めた後に「LIST」とサーバ側に求めると「+OK 1 message」ときた。このことからメールが来ているか確認したと考えられる。またこの実験で他の班のSMTP、POPが見れたかを考える。1つ目はハブがリピータハブであるからだと考えられる。リピータハブは接続しているパソコンすべてにパケットを送信している。そのためあるパケットが必要なパソコンはそのまま受け取ればよいが、不必要なパソコンは破棄しなければならない特徴がある。その為、他の班のメールが見ることができたと考えられる。2つ目はこの実験の時にはまだセキュリティをかけていないためメールが見られたと考えられる。

セキュアプロトコルを使用した場合のパケットキャプチャ

送受信したメールの内容

 セキュアプロトコルのSSLを使用して再びメールを送受信した。受信したメールを開こうとしたところFig.10の画面が出てきた。この画面を見ると、証明書の有効性を検証できなかったと書いてあった。

Fig.10 警告文

その後、Thunderbirdでメールを確認した。送信したメールをFig.11、受信したメールをFig.12に示す。

Fig.11 SSL使用時のThunderbirdの送信メール
Fig.12 SSL使用時のThunderbirdの受信メール

キャプチャしたパケットの内容

 Vigilを用いてメールの内容を確認した。送信側のIPアドレスは192.168.1.41で受信側のIPアドレスは192.168.1.31であった。Fig.13にTCPの465番ポートの送信メールを示し、Fig.14にTCPの995番ポートの受信メールを示す。

Fig.13 192.168.1.41のTCP465番のDefault
Fig.14 192.168.1.41のTCP995番のDefault

分析と考察

 受信したメール開こうとしたが、警告文が出てきた。認証局は公開鍵証明書を発行するが今回のセキュリティは独自に作ってしまったので認証局が把握していないものになってしまった。認証局は認可していても使用者が本当に安全か分からない。SSLを使用しているから警告文が出たのではなく、本当に安全か分からない為、警告文が出たと考えられる。セキュリティがかかっているため他人から見えなくなる。その為、VigilのPOPとSMTPからは確認することは出来なかった。また、TCPからDefaultを見るとセキュリティをかける前とかけた後の違いを確認してみる。かける前は何が書いてあるかわかったが、かけた後では文字化けのようになっていて何と書いてあるか分からなかった。また、セキュリティをかけた後だと送受信ともに上部に「Hosei Univ…] と始まる部分があった。この部分が文字化けしていないのは認可された法政大学がSSLをかけているからだと考えられる。ほかの部分は内容に関することのため文字化けが起こっていると考えらえる。またポート番号が25から465に変更された。これもセキュリティのためだと考えられる。

メールヘッダの分析

分析したメールのソース

 Thunderbirdで送られてきたメールの中から1つを選び、そのメールのヘッダを確認した。ヘッダをFig.15に示す。

Fig.15 メールのヘッダ

分析と考察

「Received」からIPアドレス[192.168.1.31]のコンピュータから受け取っていることがわかる。受け取ったのは「mail.ai-jikken.k.hosei.ac.jp」のコンピュータで宛先は「jikken04@ai-jikken.k.hosei.ac.jp」であると考えられる。「User-Agent」よりThunderbirdというメーラを使っていると考えられる。「Message-ID」はこのメールの識別番号を表していて世界1つしかなく重複することがないものだと考えられる。一方で、「X-UIDL」はPOPサーバが届いたメールごとに自動でつける文字列だと考えられる。

TLS

送受信したメールの内容

 セキュリティをSSLからTLSに変更し、Thunderbirdでメールを送受信した。その時の送信メールをFig.16に、受信メールをFig.17に示す。

Fig.16 TLS使用時のThunderbirdの送信メール
Fig.17 TLS使用時のThunderbirdの受信メール

キャプチャしたパケットの内容

 TLSをした場合のメールをVigilで見た。自分のIPアドレスの192.168.1.41から192.168.1.31に送りTCP110番のDefaultの内容をFig.18に示す。

Fig.18 TLS使用時のTCP110番のDefault

分析と考察

 TLSとSSLはどちらもセキュリティであるが使用時に違いがあった。1つ目はSSL使用時にポート番号が変わったがTLS使用時はセキュリティをかけていない時と同じポート番号であった。2つ目はTLSの時に出た警告文が出なかった。Fig.14とFig.18を比べるとFig.18には暗号化されていない場所があった。また、メールサーバーと通信し、メーラ側から「STLS」と発信された後、サーバ側から「+OK Begin TLS negotiation now.」が確認できた。しかし「+OK」は3つあった。最初の「+OK」のあとに「Devocot ready」とあるが、Devocotは受信サーバの構築に使用される。これにより最初の「+OK」はメールサーバが準備完了という意味だと考えられる。次の「+OK」は「CAPA」の後にあった。「CAPA」はサーバの実装機能の一覧を取るのでこれはTLSに関係ないことだった。これより「STLS」、「+OK Begin TLS negotiation now.」の部分がTLSに関することだと考えられる。以上のことからTLSは送信相手がTLSに対応しているか確認し、対応していれば暗号化すると考えられる。もし対応していなければ、暗号化しないが今回は対応していたことになる。その為、ポート番号が変更しなかったと考えられる。

画像を添付した場合のパケットキャプチャ

送受信したメールの内容

 Thunderbirdでメールを送るときに画像を添付して送ってみた。その時の送信画面をFig.19に、受信画面をFig.20に示す。

Fig.19 Thunderbirdで画像添付時の送信メール
Fig.20 Thunderbirdで画像添付時の受信メール

キャプチャしたパケットの内容

 画像を添付したメールのパケットをVigilで見てみた。自分のIPアドレスの192.168.1.41から192.168.1.31に送信した。受信は反対である。TCP25番のDefaultをFig.21に、TCP110番のDefaultをFig.22に示す。

Fig.21 192.168.1.41のTCP25番のDefault
Fig.22 192.168.1.41のTCP110番のDefault

分析と考察

 どちらにも「Content-Type: image/jpeg」というのがあった。これはメールの中の画像がjpegで圧縮していることを表していると考えられる。受信メールはbase64でエンコードされたと考えられる。送信メールにはbase64とISO-2022-JPの2つが書かれていた。Base64はエンコード方式の1つで、ISO-2022-JPはJISコードなので使用文字コードを表している。またどちらも「filename」のところから「desert」と「ddh181」という名前の画像だと考えられる。

HTTPの観察

キャプチャしたパケットの内容

 違うパソコンがInternet Explorerを使ってあるサイトを見ている。そのサイトを自分のパソコンのVigilを用いてパケットをキャプチャし、表示してみることにした。自分のパソコンのIPアドレスは192.168.1.41である。キャプチャするためにTCP80番を確認した。自分のパソコンにサイトを見るにはHTTPプロトコルを確認した。TCP80番のDefaultをFig.23に、HTTPプロトコルのDefaultをFig.24に示す。

Fig.23 192.168.1.41のTCP80番のDefault
Fig.24 192.168.141のHTTPプロトコルの「http://www.yahoo.co.jp/」のDefault

分析と考察

「Accept」の部分から画像が3つあると考えられる。Fig.24を見ると2つ発見できた。しかし、ページ全体が見ることが出来ないのでこれが正しいか確認できない。「Referer」からはYahoo JapanのURLが書かれているので見ているURLを表していると考えられる。「Content-Length」より本文は2259byteであると考えられる。

DNS

DNSの動作の確認

 DNSの動作を確認するためにGoogleのホームページにいき、Vigilを用いてIPアドレスを調べる実験をおこなった。しかしうまくいかなかったので自分でIPアドレスを調べて、打ち込んでみた。GoogleのIPアドレスをFig.25に、IPアドレスを打ち込み出た画面をFig.26に示す。

Fig.25 GoogleのIPアドレス
Fig.26 IPアドレスからGoogleのページにアクセスした画面

分析と考察

 URLとIPアドレスの違いについて考える。パソコンは2進数しかわからないで、パソコンのページも2進数で表現になる。その為、人間には非常にわから面鋳物になる。そのため2進数で表現されたIPアドレスを10進数に直し、見やすくしたのがFig.25で調べたIPアドレスである。しかし、それでもわかりづらいので文字に変換したのがホスト名である。ホスト名は人間にはわかりやすいがパソコンには理解できない。そのためDNSを使ってホスト名とIPアドレスの相互変換をしていると考えられる。

パスワードの復元

パスワードの復元のキャプチャ

 パケットからメールの内容を読み取るようにIDとパスワードも復元出来ることに注目してIDとパスワード復元した。解析サイト用いてパケットの一部を引用してみるとFig.27のようになった。

Fig.27 暗号化されたID、パスワードの解析

分析と考察

 Fig.7の上部に「AGppa2tlbjA0Agpaa2tlbg==」があり、その下には「+OK Logged in」があった。これよりログインに関することだと考えられるのでbase64でエンコードするとFig.27のようになり、IDとパスワードが表示された。IDとパスワードを確認することによりセキュリティの保守性が保たれていると確認できた。

まとめ

 セキュリティにも種類があり用途や安全性、使いやすさなどを考えてメールを送らなければいけない。また、画像を見たり、Internet Exploreの閲覧をしているが世の中の物質はすべて原子からできている様に、ネットワーク上にはパケットという存在で構成されていることをこの実験から再度確認することが出来る。

【参考資料】

・エンコード・コレクション

http://homepage1.nifty.com/glass/tom_neko/web/web_03.html

・SEO 高屋 1クリックで自動解析SEOチェックツール

http://seo-takaya.com/?url=https%3A%2F%2Fwww.google.co.jp%2F

・メールヘッダの一覧

http://www.atmarkit.co.jp/fnetwork/rensai/netpro03/mail-header.html

・メールサーバー構築(Postfix+Devecot)

http://centossrv.com/postfix.shtml

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です