現在地 HOME > 掲示板
> ＩＴ２ > 205.html
★阿修羅♪
|
現在地 HOME > 掲示板
> ＩＴ２ > 205.html
★阿修羅♪
|
|
これは非常に興味深い記事です。セキュリティに関心を持ち、セキュリ
ティをキーワードにネットワークを勉強すると、スキルが格段にアップで
きるのを実感します。
GreedyDogというパケットスニファを紹介した下記部分も参考になります。
> というわけで、自らの安全性確保のために、パケットのスニファリング
>ツールでLAN回線（Ethernet）の状態を調査してみたところ……。
>
> いや参った、参った。他人のパケット（Ethernetフレーム）が、キャプ
>チャできることできること。
>
> 日本の某有名電機メーカーや、サンプルを買い付けたらしき電子商社、
>はたまたイタリアやロシアの会社員のやりとりしているリアルタイムなデ
>ータパケットが、パスワードやメールの内容まで含めて丸見えじゃないで
>すか（すみません、あくまでもセキュリティチェックが目的で、悪気はな
>かったんです）。
>
>
>今回キャプチャに使用したツールは、GreedyDogというパケットスニファ。
>Shadow Penguin Securityが開発した、マルチプラットフォーム（Windows、
>Mac、Unixなど）対応のスグレモノツール
>
>
>「Dump Mode」にチェックを付けて、Goボタン（キャプチャスタート）を
>押すと、画面上には、リアルタイムキャプチャした結果（16進ダンプ）が
>次々に表示されていく（“45 00”から始まる部分がIPヘッダのキャプチ
>ャ結果）。パケットをキャプチャしたいネットワークのインタフェース
>（I/F：）やポート番号の範囲（Port：）、送信元IPアドレス（SRC：）、
>宛先IPアドレス（DST：）も指定することで、分析したいデータのみを抽
>出してキャプチャすることもできる）
>
>
>「Stopボタン」を押し、キャプチャを終了した後は、その結果がログファ
>イルに保存される。ログファイルは、キャプチャした16進ダンプを、ユー
>ザーに分かりやすいようにセッションサービス単位に取りまとめ、翻訳し
>てくれる上画面は、あるユーザーが、POPサーバに接続した際の翻訳結果
>受信したメールデータにおける表示例（モザイクのかかった部分には、接
>続先のサーバ名や、ユーザー名、パスワード情報、メール本文の内容など
>がそのまま表示される）
>
> 海外のビジネスマンに人気のホテルさん、いくらなんでも、これは「や
>ばい」でしょう。だって、僕が例えばメールを送受信したら、やっぱり同
>じことをやってる他の誰かに、やりとりしている内容や、パスワード情報
>が丸見えしちゃうはず。これじゃ、セキュリティ対策もへったくれもあっ
>たもんじゃないぞ！
>
>
>HUBの種類を「おさらい」しよう。
です。
※なお、GreedyDog は下記ＵＲＬから手に入れることができます。
http://www.shadowpenguin.org/sc_toolbox/unix/gdd/index-j.htm
Overview
GreedyDog はLinux、FreeBSD、NetBSD、OpenBSD、Solaris2、SunOS4、AIX、
HP-UX、IRIX、MacOSX、およびWin32用イーサーネットパケットスニファで
す。GreedyDogはそれぞれのTCPセッションのストリームを維持し、ログフ
ァイルに書き込みます。このため、セッションストリームを作成するため
に細切れになったパケットを再構築する必要がなく、ログを簡単に分析す
ることができます。このため、telnetなど比較的大きいセッションをロギ
ングする場合有効となるでしょう。システム管理者はリモートユーザーの
telnetセッションをコネクション終了までのストリーム単位で見ることが
でき、管理下のネットワークから他のネットワークにクラッカーがtelnet
した場合もGreedyDogは他のネットワークを含む全ての行動を一ストリー
ムとしてロギングすることができます。また、「grep＆アクション機能」
により"cat /etc/shadow"などの怪しい行動をストリーム単位で監視し、
指定されたアクションを実行させることができるIDS機能を有します。
下記部分も参考になりました。
> まさしく「目からウロコ」的な衝撃だった。彼らの基本スタイルは「イ
>ンフラは提供するけれども、自分自身の安全を確保するのは、おまえら自
>身なんだぜ！」なのだ。
>
> そういえば、台湾（台北）では、人が青信号で横断歩道が歩いていても、
>原付やクルマがまったく気にせずつっこんでくる。最初、これにはかなり
>面喰らったが、横断歩道で、クルマの隙間をぬってよけるのは、常に人間
>の方なのだ（滞在中の4日間で5件の接触事故を目撃してしまった……）。
>
>
> とにかく、改めてここが「日本でない」ことを実感した。日本の場合、
>まず、サービスを提供する施設の安全性が求められ、サービス提供者側に
>も「責任」が求められるが、こちらでは決してそうではない。
>
> ちょっと例えはよろしくないが、人間、最期（死ぬとき）は一人、つま
>り、各人で対策してなんぼの世界なのだ。
>
>
>中途半端なセキュリティ対策は役に立たない
>
> Webアクセスやメールの送受信、場合によってはTelnetを使った接続や
>専用アプリケーションの利用など、ビジネスマンは、とかく出張先からイ
>ンターネット環境を利用する機会が多い。
>
> その中でも電子メールは、コミュニケーションツールとして、決して欠
>かすことができない重要なサービスの一つ。しかし、世間一般的に使われ
>ているSMTPサービスやPOPサービスは、標準でパケットの暗号化を行わな
>い。
>
> また、APOPなどの暗号化パスワードによるメールの受信も、メールの内
>容（本文）は、プレーンテキスト（生データ）のまま、受信するというの
>が現状だ。
>
> つまり、今回のレポートにあるように、ホテルそのものの設計思想（バ
>ックボーン）が、リピータHUBやデュアルスピードで構築されていた場合、
>中途半端な暗号化は全く意味をなさない。「パスワードは守れても、メー
>ルの本文は丸見え」または「メールの本文は守れてもパスワードは丸見え」
>という事態が起こってしまうからなのだ。
>
> これらの問題を防ぐには、VPNを利用した完全な暗号化や、あるいはSSH
>を使ったポートフォワーディング、簡単な例では、HotmailなどのSSLを利
>用したメールサービスなどを利用するのが得策だろう。
>
> また、少しイレギュラーな方法ではあるが、メールの受信パスワードは
>APOPを導入することで漏洩を防ぎ、メールの本文はパスワード付きの圧縮
>ファイル（Zipなど）にして相手に送信する、という方法でもある程度の
>セキュリティが確保できる。
>
> ただし、SSLメールの利用や、APOP＋パスワード付きメールデータ（圧
>縮ファイル）などの方法は、あくまでも「メールの送受信」のみに特化し
>た安全性の確保であり、Webアクセスなどにはまるで役に立たない。
>
> つまり、すべてのアプリケーションにおけるセキュリティを確保するに
>は、VPNなどの完全な暗号化の仕組みを確保する以外に方法がないという
>ことを、肝に銘じておこう。
>
> いずれにせよ、日本のホテルでは、ここまでアバウトなネットワークは
>存在しないと思うが、それでも不特定多数の第三者が利用するホテルのネ
>ットワークやホットスポットなどには、いかに危険性があるか、十分に証
>明できたと言えるだろう。
下記に全文をご紹介しておきますが、是非もとのページを参照されることをお勧めします。写真、イラスト付で分りやすいです。
COMPUTEX TAIPEI 2003番外編
ネットは今日も筒抜け！？――インターネット完備ホテルの落とし穴（1/3）
http://www.zdnet.co.jp/news/0309/29/nj00_taipeinet.html
台湾（台北）で行われたCOMPUTEX TAIPEI 2003での体験談。ただ、会場の
ネタについては別記事でもたくさん提供されるはずなので、ここでは息抜
きネタとして、台北のとあるホテルにおけるインターネット環境事情につ
いてレポートしよう。
海外ビジネスマンに人気の“こ洒落れた”ホテルに宿泊
今回、チケットの手配が遅れた関係で直行便が予約できず、我々が韓国
（インチョン）経由で台北空港に到着したのは、9月24日の午後7時を少し
まわったころ（日本と台湾との時差は1時間）。荷物を受け取り、少しお
どおどしながら空港の外に出ると、「Mr.WATANABE」と記した紙を掲げた
品の良い、スーツ姿の紳士が我々を歓迎してくれた。
そう、彼は我々の到着を見計らって、空港まで迎えに来てくれたホテル
専属のドライバー。軽い挨拶の後、黒塗りのリムジン・ベンツに誘われ、
VIP気分を満喫した我々が到着した先は、台北市内の商業区域にある優雅
な雰囲気の漂うホテルであった。
隠れ家的な雰囲気を持ち、内装や従業員のサービスには以前から定評が
あるこのホテル、施設も十分に充実しており、フロアに向かう途中にはド
リンクや軽食が用意されたラウンジで商談をしたり、フィットネスルーム
（ヘルスクラブ）で、汗を流す外国人（我々も外国人だが）の姿も垣間見
ることができた。
しかし、我々がこのホテルを選択したワケは、もちろんそんなことから
ではない。お察しの通り、各部屋にインターネットのブロードバンド環境
が整備されており、かつ、宿泊者のために、PCルームが24時間開放されて
いるという「決め手」があったからなのだ。
ここでホテルのLANを調査に行っただけではない証拠を1つ。COMPUTEX
TAIPEI会場近くを闊歩していたNVIDIAのお姉さんたち
というわけで、足早に高層階の部屋にチェックインし、窓からの夜景を
楽しむより先に、早速室内に設置されたLANポート（RJ45端子）に、日本
から持ち込んだノートPCを接続してみることにした。
部屋のデスクに装備されているRJ-45端子。他にも1Fのラウンジ、談話ス
ペース、ビジネスセンターなど、いたるところにLANポートが設置されて
いた
データが丸見え！
LANポートに接続したノートPCは、ホテル内のDHCPサーバから
「192.168.X.X」というお決まりのIPアドレスと、DNSサーバ、デフォルト
ゲートウェイのIPアドレスを取得し、何のトラブルもなくインターネット
へ接続することができた。数日に渡って使用してみた体感通信速度は、お
およそ1Mbps程度といったところだろうか。日本のインフラ事情から見れ
ば、それほど速いわけではないが、かといって実用に耐えられないほど遅
いわけでもない。旅先で、メールやちょっとしたWeb閲覧する程度におい
ては、十分快適と言えるだろう。
さてこの某ホテル、セキュリティ対策はもちろん万全なんだろうか？
今回は、おそらく我々と同じようにCOMPUTEX TAIPEIが目当てで宿泊して
いる客も相当数にのぼるはず……。大切な商談のメールや、Telnetなどの
操作履歴などが、他人に見えたらひとたまりもないはずだ。
というわけで、自らの安全性確保のために、パケットのスニファリング
ツールでLAN回線（Ethernet）の状態を調査してみたところ……。
いや参った、参った。他人のパケット（Ethernetフレーム）が、キャプ
チャできることできること。
日本の某有名電機メーカーや、サンプルを買い付けたらしき電子商社、
はたまたイタリアやロシアの会社員のやりとりしているリアルタイムなデ
ータパケットが、パスワードやメールの内容まで含めて丸見えじゃないで
すか（すみません、あくまでもセキュリティチェックが目的で、悪気はな
かったんです）。
今回キャプチャに使用したツールは、GreedyDogというパケットスニファ。
Shadow Penguin Securityが開発した、マルチプラットフォーム（Windows、
Mac、Unixなど）対応のスグレモノツール
「Dump Mode」にチェックを付けて、Goボタン（キャプチャスタート）を
押すと、画面上には、リアルタイムキャプチャした結果（16進ダンプ）が
次々に表示されていく（“45 00”から始まる部分がIPヘッダのキャプチ
ャ結果）。パケットをキャプチャしたいネットワークのインタフェース
（I/F：）やポート番号の範囲（Port：）、送信元IPアドレス（SRC：）、
宛先IPアドレス（DST：）も指定することで、分析したいデータのみを抽
出してキャプチャすることもできる）
「Stopボタン」を押し、キャプチャを終了した後は、その結果がログファ
イルに保存される。ログファイルは、キャプチャした16進ダンプを、ユー
ザーに分かりやすいようにセッションサービス単位に取りまとめ、翻訳し
てくれる上画面は、あるユーザーが、POPサーバに接続した際の翻訳結果
受信したメールデータにおける表示例（モザイクのかかった部分には、接
続先のサーバ名や、ユーザー名、パスワード情報、メール本文の内容など
がそのまま表示される）
海外のビジネスマンに人気のホテルさん、いくらなんでも、これは「や
ばい」でしょう。だって、僕が例えばメールを送受信したら、やっぱり同
じことをやってる他の誰かに、やりとりしている内容や、パスワード情報
が丸見えしちゃうはず。これじゃ、セキュリティ対策もへったくれもあっ
たもんじゃないぞ！
HUBの種類を「おさらい」しよう。
でもちょっと待て、このホテルのバックボーンハブ（以下、HUB）には、
一体何が採用されているんだ？
みなさんも冷静に考えてみよう。
[ワタナベイクヲ, ZDNet/JAPAN]
前のページ | 1/3 | 次のページ
ZDNN 2003年9月29日 10:00 PM 更新
COMPUTEX TAIPEI 2003番外編
ネットは今日も筒抜け！？――インターネット完備ホテルの落とし穴（2/3）
http://www.zdnet.co.jp/news/0309/29/nj00_taipeinet_2.html
前のページ
現在、ちょっとしたLANを構築するには、100MbpsのEthernet
（100BASE-TX）を使う方法が最もポピュラーだ。そして、ほとんどの
100Mbps Ethernetは、スイッチングHUB（スイッチ）を介して各端末（PC）
をケーブル接続している。
スイッチングHUBは、それに接続された機器のMACアドレス（別名：物理
アドレスやアダプタアドレスとも呼ばれる、LANボードに書き込まれたア
ドレス）を読み取ることで、各端末（PC）を識別し、目的とする通信相手
にのみ、パケットを伝送する性質を持つHUBだ。
そう、インターネットの世界で「アドレス」といえば、「IPアドレス」
を指すことが多いが、IPアドレスは、TCP/IPプロトコルを利用する際に使
用される“ソフトウェアレベル”のアドレスであり、各端末を物理的に識
別する“ハードウェアレベル”では、必ずMACアドレス情報を元にして、
端末の識別/パケット（Ethernetフレーム）の転送が行われているわけだ。
Windows系OSの場合、コマンドプロンプト（DOSプロンプト）から、
「ipconfig /all」と実行することで、自分のPCに割り当てられたIPアド
レス、MACアドレスを知ることができる。MACアドレスは、LANボードなど
のROMチップにハードウェア的に焼き込まれており、原則としてユーザー
側では変更できない。画面はWindows XPでipconfig /allを実行したとこ
ろ（ワクで囲んだPhysical Address（物理アドレス）の部分がMACアドレ
ス）
別の言い方をすれば、スイッチングHUBは、各ポート単位に、MACアドレ
ス情報を記憶するためのメモリ空間を搭載していることになる。だからこ
そ、各ポートに接続されたPCのMACアドレスを識別し、目的とする端末に
対してのみ、必要とするパケットを転送することができるのだ。
スイッチングHUBは、各ポートごとに、MACアドレスを自動学習し、目的と
する宛先MACアドレスを持つ端末に対してのみ、パケットを転送する性質
を持つ（ただし、ブロードキャストパケットと呼ばれる、同一ネットワー
ク（LAN）内に存在する全端末に同報通知するパケットについてはスイッ
チングHUBの全ポートにパケット送信する性質を持つ）。したがって、宛
先（宛先MACアドレス）が異なれば、パケットが衝突することなく、複数
組同時に通信することが可能だ
さしずめ、IPアドレスは、インターネット上で目的のネットワーク（コ
ンピュータ）を識別するための電話番号（外線番号）、そしてMACアドレ
スは、同一ネットワーク（LAN)内で、各端末を識別するための電話番号
（内線番号）のような存在ととらえて良いだろう。
以上の理由から、バックボーンHUBにスイッチングHUBが採用されていれ
ば、他の利用者のパケットが、無関係な第三者に流出することは構造上あ
りえない。
しかし、今回は、見事に他人のパケットまでもがキャプチャできてしま
った。では、このホテルでは、一体どのような方法で各端末（各部屋）を
接続しているのか？
考えられる形態は、いわゆる帯域共有型の「シェアードHUB」と「デュ
アルスピードHUB」のどちらかだ。
シェアードHUBは、いわゆるリピータ（リピータHUB）と呼ばれる帯域共
有型のHUBのこと。現在は、高集積化により、低価格なスイッチングHUB用
チップ（LSI）が量産されたため、見かける機会も減りつつあるが、ほん
の6〜7年前までは、日本国内でも主流の接続形態として広く利用されてい
たHUBである（もちろん今でも、シェアードHUBを使用しているネットワー
クは存在する）。
しかし、シェアードHUB（リピータHUB）は、あまり品のよろしくない言
葉だが、業界関係者には「バカHUB」と呼ばれるほどお粗末な機能しか持
ち合わせていない。というのも、スイッチングHUBのように、MACアドレス
を記憶（学習）するといった機能はなく、単純に、各端末を接続するだけ
の機能を提供するHUBだからだ。
HUB自身にMACアドレスを学習する機能がないため、接続される全ポートに
対して、パケットが垂れ流される。結果的に、パケットを受信した各PCが、
そのパケットが自分のものかを判断して受け取る
だからこそ、リピータHUB（シェアードHUB）で構成されたLANでは、ネ
ットワーク上の全ての端末に対してパケットを「垂れ流し」にしてしまう。
言い方を変えれば、PCに割り振られたMACアドレスを見て、どの端末
（PC）に、パケットを送信すべきかを判断できないため、結果的に、すべ
てのPCに対して、パケットを送りつけてしまうのだ（だからこそ、PC側で
そのパケットが自分のものかを判断し、自分のものであれば「受信」、そ
うでなければ「破棄」する方式をとっている）。
また、もちろん、同じタイミングで、パケットを送信したい複数の端末
が存在した場合は、パケットの衝突（コリジョン）という問題も発生して
しまう（コリジョンの発生したパケットは、一定時間待った後に、再送し
なければならない）。
つまり、シェアードHUB（リピータHUB）で構成されたネットワークは、
それだけで、“安全上の欠陥”を抱えたネットワークと言えるのだ。職場
のように閉じられた環境で利用するのであればまだしも、今回のホテルの
ように、「不特定多数の第三者」が利用する環境では、そのリスクも計り
知れないものと言えるだろう。
それでは、デュアルスピードHUBの場合はどうだろうか？
[ワタナベイクヲ, ZDNet/JAPAN]
前のページ | 2/3 | 次のページ
ZDNN 2003年9月29日 10:00 PM 更新
COMPUTEX TAIPEI 2003番外編
ネットは今日も筒抜け！？――インターネット完備ホテルの落とし穴（3/3）
http://www.zdnet.co.jp/news/0309/29/nj00_taipeinet_3.html
前のページ
デュアルスピードHUBは、1つの装置内に10MbpsのリピータHUBと100Mbps
のリピータHUBを内蔵し、この伝送媒体の異なるセグメント間を、ブリッ
ジ回路（スイッチング回路）によって接続したHUBだ。
このHUBは、すべてのポートで10Mbps/100Mbpsの自動認識を行い、100Mbps
（100BASE-TX）と10Mbps（10BASE-T）の2つのネットワークセグメント
（コリジョンドメイン）を形成する（ブリッジ回路には、各端末が10Mbps、
100Mbpsのどちらのセグメントに所属しているかのMACアドレス情報が記録
され、10Mbpsと100Mbpsのセグメントをまたぐ場合にのみ、MACアドレスを
使って、パケットを転送するかを判断する）
HUBの各ポートでは、10Mbps/100Mbpsの自動認識が行われ、あたかもLAN
全体が一つのセグメントに接続されているかのように見えるが、実際には
上図のように10Mbpsネットワークと、100Mbpsのネットワークで、別々の
セグメント（＝パケット）の衝突が発生するコリジョンドメイン）が形成
されてしまう。
つまり、10MbpsのLANと100MbpsのLANが独立して存在し、それぞれのセ
グメント内においては、リピータHUBとまったく同じ動作（垂れ流し）を
するわけだ。
デュアルスピードHUBは、10Mbps環境（10BASE-T）から100Mbps環境
（100BASE-TX）への段階的な移行を想定して、1998年頃から市場に投入さ
れたが、世間はあっという間に100Mbps環境（100BASE-TX）に移行してし
まったため、今となっては、一過性の製品としての感もぬぐいきれない。
しかし、いずれにせよ、ホテルの各室を結ぶバックボーンHUBが、この
シェアードHUB（リピータHUB）か、デュアルスピードHUBのどちらかであ
れば、今回の垂れ流しが起こる理由も明らかになるわけだ。
我々の推測は正しいか！？ 思い切ってホテルに直撃取材！
今回宿泊したホテルは、宿泊者に「カードキー」を手渡し、室内への出
入りのほか、エレベータもカードキーを差し込まなければ動作させないと
いう、徹底した入室チェックを実施している。つまり、ホテル宿泊者以外
の第三者が、ホテル内を自由に出入りすることを禁止しているのだ。
しかし、それだけのセキュリティを確保し、ブロードバンド環境や、ビ
ジネスルーム、PCルーム完備で「IT環境対応」を大きくうたっているホテ
ルが、「情報セキュリティ」に関して、何も対策を施していないというの
は、なんたる怠慢か！？
というわけで、憤りを感じながら、いつまでも無差別に流れてくる他人
のパケットをキャプチャしていても仕方がない。良い育ちではない我々は、
ホテルのフロントに、この情報セキュリティの不備に関し、思い切って直
撃取材を申し入れた。
だが、いくらホテルのフロントで、情報セキュリティの不備について力
説しても、彼らは何のことだかさっぱり理解してくれない。
それはそうだ。彼はあくまでもホテルマンであり、情報担当者ではない
のだ。また、我々がメイン使える言語プロトコルは、日本語と下手くそな
英語であるのに対し、ホテルマンが使える言語プロトコルは、流暢な中国
語と英語、あとは挨拶程度の日本語だ。技術的な話を理解してもらうには、
お互いが持つプロトコルに違いがありすぎる。
通信プロトコルと同じで、お互いに同じ下位プロトコル（TCP/IPなど）
を実装していても、実装しているアプリケーションサービス（POP、SMTP、
HTTP、FTPなど）に違いがあれば、コミュニケーションがとれないのと同
じだ（今回はまさしくその状態で、向こうが接客コミュニケーションのプ
ロ、そしてこちらがIT技術のプロという状況だった）。
とりあえず、30分ほど経過しただろうか、数人のホテルマンとコミュニ
ケーションし、少しずつ偉い人を呼び出してもらって、我々は、ようやく
このホテルのITシステムを管理するサポートセンターの担当者と電話で話
をすることに成功した。
自分の安全は自分で確保せよ。それが「台湾流」だ！
サポートセンターの担当者は、独学で勉強したというそこそこ上手な日
本語で話してくれた。そして、その結果、我々の疑問点は見事に暴かれて
いく。
担当者：はい、お察しの通りです。そちらのホテルのバックボーンはデュ
アルスピードHUBを使っています。
――しかし、それでは各人のセキュリティが保てないのではないですか？
担当者：はい。しかし、自分の安全は自分で確保するものですから。セキ
ュリティを確保したい場合はVPNを使ってください。
――ということは、ホテル側として何か対策を施すことはないのですね？
担当者：将来的にはあるかもしれませんが、今はありません。
まさしく「目からウロコ」的な衝撃だった。彼らの基本スタイルは「イ
ンフラは提供するけれども、自分自身の安全を確保するのは、おまえら自
身なんだぜ！」なのだ。
そういえば、台湾（台北）では、人が青信号で横断歩道が歩いていても、
原付やクルマがまったく気にせずつっこんでくる。最初、これにはかなり
面喰らったが、横断歩道で、クルマの隙間をぬってよけるのは、常に人間
の方なのだ（滞在中の4日間で5件の接触事故を目撃してしまった……）。
とにかく、改めてここが「日本でない」ことを実感した。日本の場合、
まず、サービスを提供する施設の安全性が求められ、サービス提供者側に
も「責任」が求められるが、こちらでは決してそうではない。
ちょっと例えはよろしくないが、人間、最期（死ぬとき）は一人、つま
り、各人で対策してなんぼの世界なのだ。
中途半端なセキュリティ対策は役に立たない
Webアクセスやメールの送受信、場合によってはTelnetを使った接続や
専用アプリケーションの利用など、ビジネスマンは、とかく出張先からイ
ンターネット環境を利用する機会が多い。
その中でも電子メールは、コミュニケーションツールとして、決して欠
かすことができない重要なサービスの一つ。しかし、世間一般的に使われ
ているSMTPサービスやPOPサービスは、標準でパケットの暗号化を行わな
い。
また、APOPなどの暗号化パスワードによるメールの受信も、メールの内
容（本文）は、プレーンテキスト（生データ）のまま、受信するというの
が現状だ。
つまり、今回のレポートにあるように、ホテルそのものの設計思想（バ
ックボーン）が、リピータHUBやデュアルスピードで構築されていた場合、
中途半端な暗号化は全く意味をなさない。「パスワードは守れても、メー
ルの本文は丸見え」または「メールの本文は守れてもパスワードは丸見え」
という事態が起こってしまうからなのだ。
これらの問題を防ぐには、VPNを利用した完全な暗号化や、あるいはSSH
を使ったポートフォワーディング、簡単な例では、HotmailなどのSSLを利
用したメールサービスなどを利用するのが得策だろう。
また、少しイレギュラーな方法ではあるが、メールの受信パスワードは
APOPを導入することで漏洩を防ぎ、メールの本文はパスワード付きの圧縮
ファイル（Zipなど）にして相手に送信する、という方法でもある程度の
セキュリティが確保できる。
ただし、SSLメールの利用や、APOP＋パスワード付きメールデータ（圧
縮ファイル）などの方法は、あくまでも「メールの送受信」のみに特化し
た安全性の確保であり、Webアクセスなどにはまるで役に立たない。
つまり、すべてのアプリケーションにおけるセキュリティを確保するに
は、VPNなどの完全な暗号化の仕組みを確保する以外に方法がないという
ことを、肝に銘じておこう。
いずれにせよ、日本のホテルでは、ここまでアバウトなネットワークは
存在しないと思うが、それでも不特定多数の第三者が利用するホテルのネ
ットワークやホットスポットなどには、いかに危険性があるか、十分に証
明できたと言えるだろう。
同時多発テロやイラク戦争、北朝鮮問題など、外交環境的に緊迫しつつ
も、平和ボケしていると言われ続ける日本人。これを機に、みなさんも、
自身のインターネット環境をしっかり見直してみてはいかがだろうか？
[ワタナベイクヲ, ZDNet/JAPAN]
前のページ | 3/3 | 最初のページ
題名には必ず「阿修羅さんへ」と記述してください。