カテゴリー「IT技術」の30件の記事

2012年2月 4日

SSDを使えば必ず低価格で高性能のシステムが作れるわけではない

SSDs and the TPC-C top 10(StorageMojo)
http://storagemojo.com/2012/01/19/ssds-and-the-tpc-c-top-10/

SSDはHDDに比べてずっと速いが、システム価格は高額だ。HDDで性能を出そうと思ったら、実際に必要な容量以上のHDDを使い、I/Oを複数のデバイスに分散させなければいけない。結果的に全体の容量が大きくなる。というのが世の中で信じられている"常識"だが、TPC-Cベンチマークは正反対の結果が出た。

トランザクションあたりのコストを示す指標tpmCで見ると、最も高価なSSD/HDD混在システムは、最も安価なHDDベースシステムより15%くらい安い。最も容量の大きいシステムはSSD/HDD混在のOracleで1760TB。最も容量が少ないシステムもSSD/HDD混在システムで83TB。

単にHDDの一部分をSDDで置き換えれば、より低価格で高性能なシステムが構築できると言うほど物事は単純ではないようだ。

| | コメント (0)

2012年1月23日

Windowsの新ファイルシステムReFSが防ごうとしている「torn write」

Building Windows 8ブログにReFSの記事が掲載された。NTFSの後継となる新しいファイルシステムで、名称はResilient File System(回復性のあるファイルシステム)に由来する。その名前が示すとおり、電源断などの異常が起きてもファイルが破損しないように、そしてもしファイルシステムに異常が見つかっても、全体をオフラインにすることなく、異常部分を切り離して業務を継続できるように設計されている。

記事の中に「torn write」という聞き慣れない言葉が出てきた。以下の部分である。

The main disadvantages of a journaling system are that writes can get randomized and, more importantly, the act of updating the disk can corrupt previously written metadata if power is lost at the time of the write, a problem commonly known as torn write.

「commonly known」と書いているが、Googleで検索すると5000件弱しかヒットしない。検索結果の多くがExchange Serverのエラーメッセージに関するページである。「How to use Eseutil to test transaction log files for damage in Exchange 2000 Server and in Exchange Server 2003」の中で、torn writeを定義している。マイクロソフトによる日本語訳は「データの欠落したページ」「書き込み時のデータ欠落」である。

A torn write is an incomplete physical write that is left in the E00.log file after the database service suddenly stops. A torn write may be caused by a power failure, by an operating system crash, by invoking End Process on the database process, or by using a termination utility such as Kill.exe. A torn write causes checksums on the affected transactions in the log file to be calculated incorrectly, and the log is then detected as damaged by Eseutil.

FAST08でNetAppの技術者たちが発表したものと思われるプレゼンテーションも参考になる。「Torn Write」は、ブロックの一部だけが書き込まれ、セクタの一部が失われるが、Writeは成功するとされている。

Parity Lost and Parity Regained
http://www.cs.berkeley.edu/~krioukov/ParityLostAndParityRegained-FAST08.ppt

元のブロックを更新中に電源が落ちると、そこにあったデータの一部が書き換わり、新しいデータは一部しか反映されていないという中途半端な状態になり、データが破損する。チェックサムが不正となるので、問題があることが検出できるが、破損したデータはリカバリできない。これを防ぐためReFSは新しいブロックを割り当てて、更新データをそこに書き込む(allocation on write)。書き込み途中で電源が落ちても、元データは手つかずのまま残っている。とブログは書いている。

ZFSも似たようなアプローチを取っている。ブロックを更新するときに常に新しいブロックを割り当てる。ファイルシステムを構成するツリーの最上位まで正しく更新完了するまで、以前のデータを保持する。もし更新途中で問題が起きた場合は、更新前の状態に戻す。アトミックなトランザクションとして行われるため、ファイルの状態は更新前か更新後かどちらかに定まり、中途半端な状態にはならない。

| | コメント (0)

2011年10月24日

CentOS 5へのSSHログインが遅い

puttyからCentOS 5.3にSSH接続してlogin asプロンプトにユーザ名を入力すると、数十秒待ってようやく「Access denied」というメッセージとともにpasswordプロンプトが出てくる。関係する設定は2箇所ある。ひとつは/etcv/ssh/sshd_configのuseDNSパラメータである。CentOS 5.3デフォルトの設定ファイルで「#UseDNS yes」とコメントアウトされているが、キーワード未設定時のデフォルト値はyesである。これは接続先の名前とIPアドレスをダブルチェックするためのものだ。ラボ環境などでDNSが整備されてない場合はnoにする。

UseDNS
Specifies whether sshd should look up the remote host name and check that the resolved host name for the remote IP address maps back to the very same IP address.  The default is “yes”.
(sshd_config (5)のmanページ)

この設定でログインの待ち時間がなくなるが、「Access denied」が相変わらず出てくる。これはputtyがデフォルトでGSSAPI認証を要求するためである(SSH-2の場合)。さらにCentOS 5.3は「GSSAPIAuthentication yes」とsshd_configに書いてあり、これを許可する。どちらかの設定を変えて、GSSAPI認証を試行しないようにすれば良い。puttyの場合は、設定ツリーをConnection → SSH → Auth → GSSAPIと展開し、「Attempt GSSAPI authentication (SSH-2 only)」のチェックボックスを外せばよい。

GSSAPIAuthentication
Specifies whether user authentication based on GSSAPI is allowed.  The default is “no”.  Note that this option applies to protocol version 2 only.
(sshd_config (5)のmanページ)

| | コメント (0)

2011年8月 5日

SSDはHDDより信頼性が高いか?

Investigation: Is Your SSD More Reliable Than A Hard Drive? (Tom's Hardware)
http://www.tomshardware.com/reviews/ssd-reliability-failure-rate,2923.html

Webで9ページにもわたる力作。SSDを多数導入しているデータセンターに取材し、実運用場面での故障について調査している。彼の結論は、結局のところSSDがHDDより高信頼性だとは言えないということ。バックアップは必須である。そしてバックアップさえ取っていれば、SSD導入をためらう必要はない。私も気にしていたNANDフラッシュセルの書き込み上限回数は、故障の原因としては無視できる。SSD故障の大きな要因の一つはファームウェアである。

興味深かった点を抜き出してメモしておく。

エンタープライズ向けHDDとコンシューマ向けHDDに部品の違いはない。差を生み出すのは外部インタフェース、そしてファームウェアの設計。これがストレージ業界の秘密。同じことがSSDにも言えるのではないか。

HDDには故障の予兆が見られるが、SSDは突然死する。故障したSSDからのデータリカバリは、HDDからのリカバリに比べて難しい。全く不可能なこともある。

SMARTはあまり当てにならない。機械的故障の事前検出に最適化されたものであり、電気的故障には役に立たない。SSDの故障でSMARTが役に立った例はないとの証言あり。

高いI/O性能を出すのに必要なドライブ数がHDDに比べて減る。サーバ構成を単純にでき、電力消費も下げられる。冷却コストも下がる。パーツ点数が減れば、故障による交換回数も減る。

ブランドごとの信頼性の差は大きい。インテルはやはり信頼されているし、安価なOCZはDOAが多かったという証言もある。

SSDを2年以上使用したときのデータが不足している。HDDは5年間の統計データがある。

ディスクアレイ内でHDDが1台故障すると、もう1台故障する可能性が高くなる。RAID再構築もその要因。

HDDの温度は故障率と余り関係ない。

| | コメント (0)

2011年1月25日

Windows 7/VistaクライアントでSMB2を無効にするのは無意味

Windows Vista、Windows 2008、Windows 7はSMB2をサポートしている。XP/2003以前はSMB1だ。SMB2がどういうものかは他の文献を見ていただくとして、SMB2を無効にする設定について調べたことをまとめる。

件の設定はMS09-050にある。

マイクロソフト セキュリティ情報 MS09-050 - 緊急
SMBv2 の脆弱性により、リモートでコードが実行される (975517)
https://www.microsoft.com/japan/technet/security/bulletin/MS09-050.mspx

「脆弱性の詳細」にあるCVEのどれかを展開すると、レジストリ設定による回避策が書いてある。要約すると、HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanmanServer\Parametersの下に「smb2」というキーを追加して0(ゼロ)を入力する。その後Serverサービスを再起動する。

Windows 7やVistaがファイルサーバに繋がらないという問題が起きたとき、SMB2を無効にするということがよく行われているようで、Google検索でいくつも引っかかる。しかし私が調べたところ、クライアント側でやっても無駄だ。この設定はサーバ側の挙動を変えるものである。

クライアントがファイルサーバに接続するとき、まず自分がサポートするプロトコル(dialect)を列挙したNegotiate Protocol要求を送信する。Windows Vistaは「SMB 2.002」をサポートしている。Windows 7はこれに加えて「SMB 2.???」をサポートしている(注1)。私がテストしたかぎり、smb2レジストリキーの値にかかわらず、同じプロトコルを列挙してNegotiate Protocol要求を送信する。つまりクライアントとしての挙動に変化はない。

サーバとして振る舞う場合、つまりNegotiate Protocol要求を受信するVistaやWindows 7は、smb2の値で挙動が変わる。SMB2を無効(キー値0)にしておくと、SMB2のdialectを受信してもSMB1のNegotiate Protocol応答を返し、その後のやり取りがSMB1で行われる。SMB2が有効(キー値1)の時にSMB2のdialectを受信すると、SMB2のNegotiate Protocol応答を返し、SMB2のやり取りが始まる。レジストリキーがLanmanServerというのも示唆的である。

この設定はSMB2の脆弱性を回避する手段として公開されたものである。脆弱性からシステムを守るには、外部からSMB2で接続要求が行われても拒否すればよい。サーバとしての動作で回避しようというのが、この設定の意図なのだろう。悪意のあるサーバにSMB2で接続したクライアントが攻撃されるということもありうるのだが、まずは悪意のあるクライアントから攻撃を受けないようにするのが先決である。

(注1)
「???」(0x3f3f3f)が何を意味するのか不明。Windows 7はSMB 2.1をサポートしているので、それと関係あるのかもしれない。

(注2)
Windows 7は、SMB2のdialectを列挙しないでNegotiate Protocol要求を送ることがある。発生条件がよく分からない。いちど接続したサーバがSMB2をサポートしてないと分かっていると、次に接続するときはSMB2のdialectを列挙しないのだろうかと思って試したが、思うように再現できない。

| | コメント (0)

2011年1月14日

iPhoneとAndroidのどちらがセキュアか

Trend Microの会長Steve Changが、AndroidはiOSよりセキュリティが弱いと発言したそうだ。私もそう思うが、理由は違う。

AndroidはiOSより脆弱--トレンドマイクロ会長が発言
http://japan.cnet.com/news/business/20424955

Android more at risk than iOS, says Trend Micro
http://news.cnet.com/8301-13506_3-20028262-17.html

この記事に、「2010年7月には複数のセキュリティ専門家が、AndroidとiOSはいずれも『同程度の』セキュリティを確保しているが、これを実現する方法が異なっているとの見解を明らかにした」と書いてある。翻訳版では原典が分からないが、記事原文にはリンクが張ってある。

Experts: Android, iPhone security different but matched
http://news.cnet.com/8301-27080_3-20009362-245.html

Chang氏やセキュリティ専門家たちが焦点を当てているのは、あとからインストールするアプリケーションが携帯電話内のデータに不正にアクセスできるかどうかという点である。Androidは、アプリケーションがどのデータにアクセスできるか、どんなことができるかについて、インストール時にユーザの承認を求める。iPhoneの場合、アプリケーションはすべて同じ範囲のデータにアクセスできる(位置情報だけはユーザの承認が必要)。AndroidのアプリケーションはGoogleによる事前承認がないので、悪意のあるソフトウェアが流通してしまう可能性が高い。Appleの事前審査はそういったソフトウェアを排除するのに役立つが、いったん承認されたソフトウェアが、悪意のあるコードをダウンロードする可能性もある。どちらのプラットフォームにも長所と弱点があり、ほぼ互角という結論である。

しかしこれらの記事は、OSのセキュリティ脆弱性が見つかったあと、どのようにしてそれを修正するかという点について触れていない。ソフトウェアには必ず脆弱性がある。そしてそれを迅速に修正するという点に関して、現時点ではiPhoneに軍配が上がる。

iOSは、Appleが修正版を出せば、すぐにエンドユーザが入手してiPhoneをアップデートできる。バージョン番号の3桁目の小規模リリースで脆弱性を修正した実績もある(注1)。いっぽうAndroidは、Googleが修正版をリリースしたあと、携帯電話メーカやキャリアのテストを経てエンドユーザに届けられる。他のAndroid携帯との差別化のためにUIやアプリケーションを作り込んでいると、アップデート版のリリースに時間がかかることが考えられる。ドコモのXperiaはAndroid 1.6で発売され、アップデートできるようになるまでには、約半年かかった。しかも、アップデート先は最新の2.2ではなく2.1である。任意のコードが実行できるというWebKitの脆弱性は修正されていない(注1)。auのIS01はアップデートすらしない(注2)。Androidのアップデートが比較的大規模のものなのも、メーカやキャリアの対応が遅れる原因ではないだろうか(これは今後変わるかもしれない)。

iOSもAndroidもサンドボックス化によって、悪意のあるコードから他のプロセスやデータを守っている。しかしiOSのPDF脆弱性が示したように、ソフトウェアのバグによってこの防御機構が破られ、root権限を奪われることがある。root権限を奪われたら為す術がない。そしてAndroidに似たようなバグがあっても不思議ではない。完璧なソフトウェアは存在しないからである。CoverityがAndroidのソースコードを解析したところ、88個のハイリスクなものを含めて、セキュリティ脆弱性に繋がりかねない潜在的な問題が359個見つかったそうだ(注4)。ソースコードが公開されていないiOSで同じ分析を第三者がおこなうことはできないが、Appleとて人の子。状況はさほど変わらないだろう。

アプリケーションがアクセスできるデータについてユーザの確認を求めるAndroidの画面も、実際には防御にならない。セキュリティに関心が高いユーザ以外は、何のためらいもなく承認してしまうだろう。PCのブラウザを使っているときに、送信する情報が暗号化されていないという警告や、サイトのSSL証明書が不正だという警告が出たとしても、平均的なユーザは特に気にも留めずOKボタンをクリックしているはずだ。そのサイトを使いたい、そのアプリケーションを使いたいという欲求の前には、ソフトウェア開発者が表示する警告画面は無力である。せいぜい何か問題が起きたときに、「我々は警告したはずだ」と言い訳できるくらいだ。

以上のように考えると、少なくとも現状ではiPhoneの方がより安心して使える。もちろん常に最新版のiOSにアップデートすることが前提である。そしてAndroid陣営のGoogleや携帯電話メーカ/キャリアが脆弱性の修正についてどのように対応していくか、目を離せない。

そして携帯電話のセキュリティで最も大事なのは、置き忘れたときにデータを盗まれないようパスワードでロックしておくことと、紛失したり壊したりしてもデータを失わないようにバックアップを取っておくことだ。

(注1)
アップル、iOSのPDFセキュリティ脆弱性に対するパッチをリリース
http://japan.cnet.com/apple/20418312/

iPhone jailbreak could double as security hole
http://news.cnet.com/8301-31021_3-20012511-260.html

(注2)
「Android」端末ブラウザに「WebKit」の脆弱性--「Android 2.2」は対応済み
http://japan.zdnet.com/news/sec/story/0,2000056194,20422578,00.htm

(注3)
au IS01はOSアップデートなし、Android 1.6で終了
http://japanese.engadget.com/2010/11/16/au-is01-android-1-6/

(注4)
Study: 359 Android code flaws pose security risks
http://news.cnet.com/8301-30685_3-20021437-264.html

| | コメント (0)

2011年1月13日

Erasure coding

Twitterやメールマガジンで続けて目にした「erasure coding」について勉強。「冗長符号」と訳しているところもあるが(注1)、「Erasure」と「冗長」は全く結びつかない。「消失訂正符号」がよいのではないか。冗長符号という訳語を充てている分野があるのだろうか。

erasure codingは、消失したビット列を復元するための技術で、リード・ソロモン符号(Reed-Solomon Coding)はCDやADSLに使われているし、QRコードにも使われている(注2)。とくに目新しい技術ではなく、ごく日常的に使われている。

RAIDレベルのなかでもっとも普及しているRAID-5の誤り検出/訂正は、CPU計算力をあまり必要としないXOR(排他的論理和)に基づいたパリティを使っている。私の会社のRAIDアーキテクトは、これも広義にはerasure codingだと言っている。さらにミラーリングRAID-1でさえ、消失したディスクのデータをもう1台から復元するので、erasure codingの非常に特殊なケースとのこと。

ディスクの容量が増大するに従って、ディスク障害時のRAID再構築にかかる時間が問題になってきている。再構築中はI/O性能も落ちる。訂正不可能な読み取りエラーがもう1台のディスクで再構築中に発生すると、データを失うことになる。ディスクの読み取りエラー率は以前から変わっていないため、1TB~2TBのディスクドライブでRAID-5を組んで再構築を行うなど、読み取るデータ量が大きくなればなるほど、エラーが起きる可能性も高くなってくる。ストレージコンサルタントのStephen Foskettは、12TBあたり1ビットの読み取りエラー率であり、ディスクドライブ容量がMBとかGBのオーダーの時は問題にならなかったが、大容量のドライブでは読み取りエラーの可能性が十分あると書いている(注3)。RAIDの自動再構築を無効にしておく方がよいという意見もある(注4)。

そこでRAID-6が登場する。XORのパリティに加えて、erasure codingに基づくもうひとつのパリティを持つことにより、ディスク2台の故障でもデータを失わなくてすむ。RAID-6のほかにもさまざまな技術が考え出されている。どれも、複数ディスク故障時にデータ損失が起きないようにしたり、再構築の時間をなるべく短くしたりということが目的である。

以上のようなことを知ってしまうと、個人向けのRAID-5対応外付けHDDは怖くて使えなくない。使われているディスクドライブは、エンタープライズ向けのものに比べて信頼性が劣るはず。設置環境もよくない。企業システムのディスクアレイ装置は温度や湿度が管理されたサーバ室に設置されているのに対して、家庭のHDDは机の上や部屋の隅に転がっている。ディスク故障で再構築が走ったとき、もう1台のディスクが読み取りエラーを起こしても全然不思議ではない。Droboや法人向けのRAID-6対応NASのような製品でなければ心配だ。

(注1)RAIDに取って替わるもの(後編)(JDSF)
http://www.jdsf.gr.jp/backup/stm/201007.html

(注2)Reed-Solomon error correction(Wikipedia)
https://secure.wikimedia.org/wikipedia/en/wiki/Reed%E2%80%93Solomon_error_correction

(注3)Erasure codes: The foundation of RAID 6 arrays(SearchStorage)
http://searchstorage.techtarget.com/tip/0,289483,sid5_gci1519386,00.html

(注4)【ATA RAID5の落し穴】(Ontrack Now)
http://knowledge.ontrack-japan.com/ontrack_now/20060515_mamechisiki.html

| | コメント (0)

2010年11月22日

Firesheepと無線LANカードの相性

誰でも簡単に他人のTwitterやFacebookのセッションを乗っ取れるFiresheepだが、無線LANカードとの相性がある。自分宛以外の無線LAN通信パケットを捕捉するには、プロミスキュアスモード(promiscuous mode)をサポートしていなければならないし、プロミスキュアスモードをサポートしている無線LANカードでもうまく傍受できないことがある。FiresheepのGoogleグループには、どの無線LANカードが使えてどれが使えないというスレッドがある。

List of Wifi chipsets
https://groups.google.com/group/firesheep/browse_thread/thread/eb1438219981f7d6

たとえばThinkPad T42が内蔵しているインテル2200BGは、プロミスキュアスモードをサポートしていないので、Firesheepを起動するとエラーになってしまう。ThinkPad X201のインテル6250ABNは、プロミスキュアスモードをサポートしているように見えて、Firesheepは起動するが、実際にはパケットをキャプチャできない。Wiresharkでも同様で、キャプチャできるのは自分宛のパケットと、ブロードキャストとおよびマルチキャストのパケットだけだ。インテルのプロミスキュアスモードは、特定ISVだけに開放しているのではないだろうか。以下のホワイトペーパには、3945ABGとAirMagnetの組み合わせでパケットキャプチャができると書いてある。

Managing Wireless Clients with the Administrator Tool
http://www.intel.com/network/connectivity/products/whitepapers/admin_tool_wp.pdf

MacBookも機種による。私の13インチMacBook(MacBook 2,1)ではだめだ。この機種はAtheosの無線LANチップを内蔵している。MacBookは2008年後半にAtheosからBroadcomに無線LANチップを変更したらしい。BroadcomのチップはFiresheepが正常動作するようだ。

AirPort(Wikipedia)
https://secure.wikimedia.org/wikipedia/en/wiki/AirPort

The particular brand and model of card has changed over the years; in early models, it was Atheros brand, while since late 2008 they have been Broadcom cards.

したがって、公衆無線LANスポットに自分のPCを持っていってFiresheepを起動し、他の人のセッションがひとつも見つからないからといって、その無線LANスポットが安全だなどと考えてはいけない。WPAやダイナミックWEP以外の公衆無線LANは、基本的に第三者傍受ができるものである。正しい装備を持った人であれば、他人の通信を完璧に盗聴することができる。盗聴を防ぐには、サーバとの間の通信をSSLで暗号化する必要がある。

| | コメント (0)

HTTPSを強制するFirefoxアドオン(HTTPS EverywhereとForce-TLS)

Firesheepなどの第三者傍受から身を守るには、サーバとの通信を暗号化するのが根本的な解決である。TechCrunchの「FiresheepからWiFiでログイン情報を守る方法」は、FirefoxアドオンのForce-TLSとHTTPS Everywhereを紹介している。

もともとForce-TLSは、WebサイトがStrict-Transport-Security HTTPヘッダを送ってきたときにSSLを強制するものだが、バージョン2.0から自分でサイトを追加できるようになった。たとえば、*.instapaper.comを追加してhttp://www.instapaper.comに接続すると、通信はHTTPで行われて、アドレスバーもhttps://www.instapaper.comに変わる。しかしhttp://instapaper.comは変換してくれない。満了日が1年先に設定されるのも少々不安だ。1年後にもう一度定義し直さなければいけないのだろうか。それはちょっと面倒だ。きっと忘れてしまう。

HTTPS Everywhereは、正規表現を使って自分でルールを書けば、任意のサイトでHTTPSを強制できる。以下のルールを定義すると、http://instapaper.comもhttp://www.instapaper.comもHTTPS接続に変換できる。こちらのほうが自由度が高いのでお勧めだ。

<ruleset name="Instapaper">
  <rule from="^http://instapaper\.com/" to="https://www.instapaper.com/"/>
  <rule from="^http://(www\.)?instapaper\.com/" to="https://www.instapaper.com/"/>
</ruleset>

(参考記事)

FiresheepからWiFiでログイン情報を守る方法(TechCrunch)
http://jp.techcrunch.com/archives/20101025firesheep/

(2010/11/24追記)
HTTPS Everywhereのバージョン0.3.0以降は<target>を指定しなければならない。これに対応したルールは以下のようになる。Twitterのルールを参考にして、<securecookie>も書いておいた。

ルールをHTTPSEverywhereUserRulesディレクトリに保存したあと、アドオンの設定画面でInstapaperにチェックが入っていることを確認しておく。もし設定画面にInstapaperが表示されないときは、ルールにエラーがある。Firefoxのエラーコンソールに何か表示されているはずだ。

<ruleset name="Instapaper">
  <target host="*.instapaler.com" />
  <target host="instapaper.com" />

  <securecookie host="^(.*\.)instapaper\.com$" name=".*" />

  <rule from="^http://instapaper\.com/" to="https://www.instapaper.com/"/>
  <rule from="^http://(www\.)?instapaper\.com/" to="https://www.instapaper.com/"/>
</ruleset>

(2011/01/27追記)
FacebookがフルHTTPSに移行する。アカウント設定でチェックを付ければ、パスワードなどの認証部分だけでなく、全ての通信がHTTPSになる。
A Continued Commitment to Security
http://blog.facebook.com/blog.php?post=486790652130

| | コメント (0)

公衆無線LANのセキュリティはかなりお寒い

Firesheepが公開されて、公衆無線LAN内の他人のTwitterやFacebookのセッションを誰でも簡単に乗っ取る(sidejack)ことができるようになってしまった(参考記事1)。

ソフトバンクモバイルが無料で配布しているせいか、最近あちこちで電波を見かけるFONは通信を暗号化していない。Firesheepの格好の餌食である。

WEPを使っている公衆無線LANも危険だ。アクセスポイントのWEPキー(パスワード)は公開されていて、そのキーをもとに全クライアントに共通の鍵を生成して暗号化する。これは暗号化していないのと同じだ。「通信内容を暗号化することでセキュリティーを強化」とホームページなどで喧伝している公衆無線LANサービスもあるが、それがWEPなら虚偽広告といって構わない。

NTT系の公衆無線LAN(ホットスポット、Mzone、フレッツ・スポット)は、IEEE802.1X認証によってクライアントごとの個別鍵を動的に生成するダイナミックWEPが使える。個別鍵に加えて、鍵を定期的に更新しているらしい。ダイナミックWEPであれば多少なりとも安全かもしれないが、更新の間隔が公開されていない。WEPは1分以内に破られてしまうから、どの程度防御されているか判断できない。また802.1X認証はオプション扱いだったり、専用のクライアントソフトをインストールしなければならなかったりする。何もせずに接続すれば共通鍵のWEPである。

いちばんも安心なのはWPA/WPA2である。しかし公衆無線LANサービスでこの方式を使っているものは少ない。私が調べたかぎりでは、ワイヤ・アンド・ワイヤレスのWi2 300がサポートしている。しかし「ローミングエリア、バス車内、および一部店舗においては、WPA/WPA2(802.11i)に対応しておりません。 ご了承ください」とのこと。つまりWi2 300独自のアクセスポイントだけでWPA/WPA2が使えるようなのだが、エリアが狭くて話にならない。大多数はBBモバイルポイントやlivedoor Wirelessのローミングである。

このように公衆無線LANのセキュリティはかなりお寒い状況なので、自分の身は自分で守るしかない。HTTPS(SSL)でサーバとの通信を暗号化するのが必須である。

(参考記事)
Twitter、Facebook、Dropbox、Evernote、全部危ない―WiFiでログイン情報を盗み取れるFirfoxアドオンFiresheep(TechCrunch)
http://jp.techcrunch.com/archives/20101024firesheep-in-wolves-clothing-app-lets-you-hack-into-twitter-facebook-accounts-easily/

| | コメント (0)