パケットは盗聴できるのか!?


巷ではよく、「パスワードを平文で通信路上に流すのは危険」などと言われる。

確かに、ネットワーク上に大事な情報を流すというのは、

覗き見されるリスクがあり、避けるべきである。

が、そんなことできるのだろうか?

本当にやられるのだろうか?

ということで、今回試してみる。

また、その結果に対する対策も含め、

以下の内容について記載していく。

  1. トライアルの概要
  2. まずはパケットをキャプチャしてみる
  3. 失敗の原因を探る
  4. ARP偽装でパケットを引き寄せる
  5. それでも失敗する原因を探る
  6. 再度パケットをキャプチャしてみる
  7. パケットの盗聴対策
  8. まとめ

なお、ここでは攻撃の原理やその結果、及び対策について記載するが、

具体的な手順については記載しない

ということにご注意頂きたい。

ちなみに、このトライアルを実施するにあたり

考えた事や調べたことが、

情報処理安全確保支援士試験合格に大きく役立った。

受験を検討している人は、

参考にしていただけるのではないか、と思う。

■トライアルの概要


通信路上を流れるデータは本当に取得できるのか?

それは簡単なのか?を確認するために、

これまでに構築してきたトライアル環境を元に、

以下のような実験を行う。

 

実験内容

今回の実験でやりたいことは以下の通り。

  • 二号機から一号機に対して FTP で file を送る。
  • 三号機において、その通信のパケットをキャプチャし、内容を取得する。

イメージとしてはこんな感じ。

ということで、いざ、実験開始。

■まずはパケットをキャプチャしてみる


三号機において、通信路上を流れるデータを取得するためには、それようのツールが必要となる。

通信データをキャプチャするにはいくつかのツールがあるが、

今回はネットワーク管理ツールとしてもよく使われる、

Wireshark

を利用する。

 

Wireshark のインストールと起動

 

まずは三号機に Wireshark をインストールする。
*なお、本来なら望ましくはないが、
*今回は独自環境ということもあり、
*三号機では全て root で作業する。

root@raspi-03# apt-get install wireshark -y

この際、途中で

「ルート権限でのキャプチャを許容するか?」

と聞かれる。

本来ならば制限した方がいいのだが、

上述の理由により今回は yes を選択する。

Wireshark がインストールできたら、早速起動する。

起動は、コマンドラインから、

root@raspi-03# wireshark &

とすればよい。そうすると、wireshark が立ち上がり、以下のような画面が現れる。

その後、データをキャプチャする

通信インターフェースとして

今回は wlan0 を選択し、capture を開始する。

うん、無事パケットはキャプチャできているようだ。

だとすると、これで二号機から一号機に

FTP 通信をやってあげれば、

そのパケットもとれるはずである。

 

二号機からの FTP 通信とそのパケットキャプチャ

 

ということで、早速二号機から FTP 通信をやってみた。

これで、三号機側でパケットがとれているはずである。

期待に胸を膨らませつつ、キャプチャされたパケットを見てみた。

???

FTP に関係しそうなパケットがとれていない。なんで!?

よくよく見てみると、どうも、以下のようなパケットしかとれていない。

  • 自分が発信したパケット
  • 自分宛に来たパケット(ブロードキャストパケットを含む)

*192.168.0.1 が一号機、192.168.0.20 が三号機の IP address である。

だとすると、別に平文通信したところで、

パケットを盗み見られないのだから安全なのでは???

いやいや、だったら一般的に

「パスワードを生で流すなんて!」

なんて言われるはずがない。

ということはどういうことなのだ?

少々混乱しつつも、原因を検討してみることとした。

■失敗の原因を探る


とりあえず、キャプチャの結果から、

自分に関連するパケットしかとれていない、

ということは判明した。

だとすると、考えられるのは以下の二つである。

  1. 自分宛以外のパケットを破棄している
  2. パケットそのものが三号機まで届いていない

つまり、パケットは三号機まで届いているが、

自分には関係ない、

と捨ててしまっているからキャプチャできていないのか、

そもそも届いていないのか、

のどちらかではないか、と思われた。

ということで、一つ一つ確認してみる。

 

1.自分宛以外のパケットを破棄している?

 

まずはパケットを破棄している可能性について検討。

通常、ネットワーク関連のインターフェースは、

ネットワーク上を流れるデータのうち、

自分宛のものしか取り込まない。

よって、この仕組みが働いているのではないか、と考えた。

これを解除するためには、

インターフェースをプロミスキャスモードに

切り替えてやればよい。

プロミスキャスモードでは、

パケットの宛先に関わらず

全てのパケットを取り込む。

よって、これでいけるのではないか、と考えた。

が、wireshark の設定を見てみると、

そもそも default で

プロミスキャスモード設定となっている。

ということは、

自分宛でなくてもパケットを取りこめる状態になっている、

ということになる。

よって

破棄している訳ではなさそうだ、

ということが分かった。

 

2.パケットそのものが三号機まで届いていない?

 

パケットを破棄していないのにキャプチャできていない、

ということは、そもそも

三号機までパケットが届いていない、

ということになる。

なんでそんなことになるんだっけ?

パケットって

同一ネットワークに接続されている全機器に流されて、

機器側で自分宛のものだけ取り込む

んじゃなかったっけ???

ということで、またまた自分の持っている

数少ない知識を総動員して考えてみた。

拙い記憶をたどってみると、

その昔私がネットワーク関連の勉強を

ちらっとやっていた時(一ヶ月も続かなかったが…)のこと、

ハブとかスイッチとか言う言葉があったことを思い出した。

ん?ハブとスイッチって何が違うんだっけ?

ハブって繋げるってことだよね?

スイッチは切り替え。ん?切り替え???

ということで、なんかこの辺に

ヒントがありそうな気がして、

ハブとスイッチの違いについて調べてみた。

具体的な内容に関しては、

こちらの記事が非常にわかりやすかったので、

リンクさせていただく。

Aiming for network engineers – ネットワークエンジニアを目指して –
「ハブとスイッチの機能の違い」
http://www.itbook.info/study/p50.html

簡単にいうと、ハブは、

ある接続機器から受信したデータを、

ハブに接続されている全ポートに対して送出する。

一方、スイッチは、

ある接続機器から受信したデータを、

その宛先となる機器が接続されている

ポートに対してのみ送出する、

ということの様だ。

だとすると、今回パケットがとれていない理由は、

一号機の WiFi アクセスポイントは、

スイッチとして動いているため、

三号機にはパケットが送られない、

という状態になっているのではないか、

と考えられた。

■ARP 偽装でパケットを引き寄せる


ということは、接続しているネットワークが

スイッチを利用しているならば、

自分に関係しないパケットは取得できないことになる。

また、最近のネットワーク構成を鑑みると、

通信データが増大していることもあり、

ハブが利用されるのは

本当に小さなローカルネットワーク

ぐらいである。

ということは、やっぱり、

パケットを取得する、

なんて現実には難しいのではないか?

そんな気もしてきたのだが、

やはり世の中的にも問題になっている現状を考えると、

腑に落ちない。

じゃぁこの状況でパケットを取得しようとすれば、

どうすればよいのか、ということをまず考えてみた。

一号機の WiFi アクセスポイントが、

スイッチとして動作している、

と仮定すると、

パケットの宛先を偽装しない限り、

三号機まで送られてこない。

ん?ちょっと待て。宛先を偽装?

ということで気がついた。

ARP spoof(poisoning) ってそういうことか。

ネットワークにつながる機器は、

IP address を割り当てられている。

これは当然論理的なアドレスである。

これに対し、各機器のネットワークインターフェースは、

機器固有の物理的なアドレスを持っている。

これが MAC address である。

で、実際にパケットを送受信する際には

IP address をベースにやりとりする。

が、IP address は起動毎に変わったりするので、

各機器はこの

IP address と MAC address の対応

を知っておかなければならない。

この対応表を作るのに使われるのが、

ARP(Address Resolving Protocol)

である。

実際には、ネットワーク上で、

「IP address が xxx.xxx.xxx.xxx の人は誰?」

という問い合わせパケットが一定のタイミングで流れ、

該当する IP address を割り当てられている機器が、

「それは私で MAC address はこれこれ」

と答える。

具体的には、先ほどの Wireshark の

スナップショットを見るとわかりやすい。

上の図では、6 行目において、

三号機(192.168.0.20)が

「192.168.0.1 は誰?192.168.0.20(三号機)に教えて!」

と要求している。

これに対し、7 行目において、一号機(192.168.0.1)が、

「192.168.0.1 は MAC アドレスが
b8:27:eb:1d:1d:7b(一号機の MAC address)の機器だよ」

と回答している。

これと同じ問い合わせは、当然、

二号機から一号機に対しても行われている。

ということは、二号機からの問い合わせに対し、

一号機よりも先に、

「192.168.0.1 は MAC address がb8:27:eb:0a:cc:e8(三号機)の機器だよ

と返してしまえば、二号機は騙されてしまうことになる。

さらに、ARP では問い合わせがなくとも

上述のようなパケットを流してしまうことで、

ネットワークにつながる機器は騙されてしまうことになる。

ということで、実際に ARP spoof を試してみた。結果は以下の通り。

6011 行目で、一号機(Raspberr_1d:1d:7b)が三号機(Raspberr_0a:cc:8e)に正しい ARP reply を返している。

が、その後、6013 行目や 6017 行目において、

三号機が 192.168.0.1(一号機の IP address)は三号機だ、

という嘘の ARP パケットを流している。
*今回は一定間隔でずっと流している。

これにより、まわりの機器は

192.168.0.1 は MAC address が

b8:27:eb:0a:cc:e8 の機器(すなわち三号機)だ、

と信じてしまう。

よし、これでうまく行った、と思ったが

実はまだ罠がまっていた。

■それでも失敗する原因を探る


こうして偽の ARP パケットを流し続けている間に、

二号機から一号機に FTP アクセスしてみる。

これまでの推測が正しければ、

パケットが三号機に到達するはずである。

ということでやってみたら、

今度は二号機から一号機への FTP アクセスが

session time up で close。

繋がらなくなってしまった訳だ。

これは明らかに、

パケットが一号機ではなく三号機に行った

ことが原因である。

で、またまたまたちょっと考えた。

が、考えるまでもなかった。

TCP のお約束をちゃんと理解してなかったのである。

つまりはこういうことだ。

TCP では、どんな通信であっても、

通信相手の生死確認を行うため、

3-way handshake

というのを行う。

まず最初に、アクセスを希望した側(通常はクライアント)が、

SYN パケットを送る。

アクセスされた側(通常はサーバー)は、

相手の生死を確認するための SYN と、

自分が生きているという応答の ACK を合わせた、

SYN/ACK パケットを返す。

最初にアクセスした側は、

帰ってきたパケットで相手が生きていることを確認するとともに、

自分が生きていることを示す ACK を返す。

こちらの絵がわかりやすいので参考にして頂きたい。

ネットワークエンジニアとして – TCP/IP – TCP three way handshake –
http://www.infraexpert.com/study/tcpip9.html

今回の場合、二号機からの SYN パケットが三号機に到達するも、

三号機では FTP サーバーを立ててないので、

SYN/ACK を返せず、時間切れとなる、ということだ。

であればどうするか?

三号機に FTP サーバーを立てた所で、

一号機と二号機のやりとりを見ることにはならない。

ということは、

あくまで三号機を中継地点にしてあげないといけない。

そのために、三号機において、

来たパケットを転送する、

という設定を行う。

これで、一号機と二号機間のやりとりを中継しつつ、

転送できるはずである。

ということで、再チャレンジしてみた。

■再度パケットをキャプチャしてみる


ちょっとおさらいになるが、今一度一連の流れを試してみる。

まずは wireshark を立ち上げておく。

root@raspi-03# wireshark &

次に、三号機にやってきたパケットを転送するように設定する。

その後、偽装 ARP パケットを頻繁に送りつける。

この状態で、二号機から一号機に対し、FTP 接続を行う。

user@raspi-02$ ftp 192.168.0.1

再び三号機に戻り、キャプチャしたパケットを確認する。

そうすると以下の通り、見事に FTP 通信時のパケットが取得できた。

6182 行目では user 名として raspi-01 が、 6200 行目では PASSWORD として password が、各々送られていることが分かると思う。

今回はそこまでやってないが、当然この後やりとりする file に関しても、同様にするとキャプチャできる。

ということで、分かってしまえば簡単にパケットの盗聴はできてしまう、ということが実感としてよく分かった。

■パケットの盗聴対策


パケットを引き寄せる手段は、ARP spoof 以外にもいろいろな手段が考えられる。

よって、パケットの盗聴に対しては、

End-to-End(通信の始点から終点まで)で通信路を暗号化する

ということが非常に有効となる。

具体的には、FTP ならば SFTP/FTPS を利用する、HTTP 通信は行わず、HTTPS 通信を行う、等である。

これらを実現するためのサーバー側の設定に関しては、追って記載していこうと思う。

■まとめ


いかがだっただろうか。

大事な情報を平文で流す、というのは如何に危険か、ということがご理解頂けたかと思う。

これを踏まえ、是非とも対策を実施していって頂きたい。

今回の Point!ネットワーク上を流れるデータは、簡単に取得することができる。

ARP spoofing により、パケットの宛先を変えることができる。

根本的な対策は、End-to-End で暗号化することである。


Copyright (c) 2017 Webmaster of this site All Rights Reserved.
カテゴリー: ラズパイでセキュリティ, 情報処理安全確保支援士 タグ: , , パーマリンク