« 2010年12月 | トップページ | 2011年2月 »

2011年1月の7件の記事

2011年1月26日

Firefox/NoScript 対 Google Chrome/NotScripts

Firefoxは起動が遅いのが玉に瑕である。Google Chromeの速さを知ってしまうと尚更だ。Chromeの拡張機能も徐々に揃ってきた。HTTPS Everwhereの代替になりそうなSecure sitesという拡張機能もある。そろそろ移行できるかと思ったが、そうはいかなかった。

検索エンジンで調べ物をするとき、雑多なサイトにアクセスすることになる。怪しいサイトでないかどうか、ドメイン名やURLをいちおう気にしているが、更に防御を固めるためにNoScriptをFirefoxにインストールしている。最近の攻撃はJavaScriptを利用したものが多い。JavaScriptの実行をデフォルトで無効にしておけば防御できる。

NotScriptsというChrome拡張機能は、FirefoxのNoScriptを目指して開発されたもの。これは使える!と思ったが、 Readabilityブックマークレットとの食い合わせが悪く、訪問サイトのJavaScriptを許可しなければ使えない。そのほかにもChrome + NotScriptの組み合わせで動かなくなるブックマークレットがいくつもある。なかでもInstapaperブックマークレットが使えないのは痛い。

Chrome + NotScritpsでブックマークレットが動かないのはChromeの仕様だ。サイト由来とブックマークレット由来のスクリプトを区別できないからだと、開発者EricとユーザJasonとのやり取りにある。

NotScripts
http://optimalcycling.com/other-projects/notscripts/

@Jason, it looks like that bookmarklet requires that you whitelist the current page you are on with NotScripts (and google.com if you don’t have that whitelisted already). Unfortunately, there is no way to distinguish between javascript from a webpage and javascript from a bookmarklet in Google Chrome. If you run lots of bookmarklets, I recommend you consider using NotScripts in WHITELIST_ALLOW_TOP_LEVEL mode which allows same origin scripts: http://optimalcycling.com/2010/09/06/blacklist-mode-implemented-for-notscripts-v0-9-6/

whitelist + top level sitesモードを使えば回避できるとEricが提案しているが、訪問ページのスクリプトが自動的に許可されるので好ましくない。当面Firefoxから離れられないようだ。

(本ブログの関連記事)
HTTPSを強制するFirefoxアドオン(HTTPS EverywhereとForce-TLS)
http://raven.air-nifty.com/night/2010/11/httpsfirefoxhtt.html

Distraction-free Web Reading ー Webの記事を読むのに集中できるツール
http://raven.air-nifty.com/night/2010/09/distraction-fre.html

| | コメント (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月24日

Googleデスクトップを使っているとOutlookのプロセスが終了しないことがある

以前書いたように、Outlookのメールは四半期ごとのPSTファイルに保存していて、必要なメールはGoogleデスクトップで検索する(注1)。ところで、Outlookアプリを終了してもプロセスOUTLOOK.EXEが残留する現象に悩まされていた。2002年くらいから起きていた記憶がある。仕方なくタスクマネージャで強制終了すると、次回起動時にメールボックスのチェックが走り、使えるようになるまで時間がかかる。

ネットで調べても事例が見つからず、半分あきらめていたのだが、根本原因らしきものがようやく分かった。Outlookに接続しているPSTファイルのメールが非常に多く、かつGoogleデスクトップで検索対象にしていると起きるようだ。四半期ごとのPSTファイルを切断し、ExchangeメールボックスのキャッシュであるOSTファイルだけにしておくと、この問題を防げるようだ。今日まで約10日間は順調である。いままでもぬか喜びで終わったことがあるので注意深く監視中である。

私のGoogleデスクトップインデックスには141,725件のメールが入っている。2005年の入社以来のメールを全て保存しているPSTファイルは、合計で5GB近くある(注2)。普通の人はそんなに大量のメールを Outlookに接続してないので、問題が起きないのだろう。

Outlook を終了するとHDDへのアクセスがしばらく続く。Googleデスクトップが抽出したメールがいったんメモリ上に展開され、Outlook終了時にインデックスデータベースに書き込むようになっているようだ。PSTファイルをたくさん接続していてOutlookがアクセスできるメール数が膨大だと、 Googleデスクトップはそこも見に行って、メモリに展開されるデータが多くなり、HDDへ書き出す処理も長くなる。それが規定の時間内に終わらないなどでタイムアウトし、Outlookプロセスが宙ぶらりんな状態になる。そんな現象が起きているのだろう。推測だらけだが、ThinkPad T42からX201にリプレースして、HDDアクセスを含めて性能が上がったらプロセス残留が発生しにくくなったことからも、この推測は当たらずといえども遠からじだろう。

Googleデスクトップがインデックスできるのは、 Outlookが起動しているとき、そしてOutlookに接続しているPST/OSTファイル内のメールである。それを拡大解釈しすぎて、見つかったメールをすぐに開くには、PSTファイルを常にOutlookに接続していなければならないと考えてしまった。実際には、Googleデスクトップのインデックスに入っていれば、PSTファイルの接続状態にかかわらず検索結果に出てくるし、「Outlookで開く」リンクをクリックすればOutlookのメールウインドウで表示される。

四半期ごとにPSTファイルを分けていることがここで効いてくる。四半期が終われば、新しいメールがそのPSTファイルに入ってくることはなく、インデックスを更新する必要がないから、Outlookから切り離せる。顧客別やプロジェクト別にしてしまうと、新しいメールが次々に入ってくるので、PSTファイルを常にOutlookに接続しておかなければならない。

(注1)
フォルダ分けしないメール整理
http://raven.air-nifty.com/night/2006/12/post_1236.html

(注2)
これだけ大量のメールを溜め込むことに異論はあるだろうが、少なくとも私にとっては、極めて貴重な事例データベースであり、仕事の記録である。これに助けられたことは何度もある。

| | コメント (0)

2011年1月21日

Windows 7でWiresharkを使う設定

ラボのVMware ServerにWindows 7ゲストが入ったので、さっそくWiresharkをインストール。起動したら、いきなりエラーが出た。

The NPF driver isn't running. You may have trouble capturing or listing interfaces.

パケットフィルタドライバが動いてないと言っている。ネット検索するとすぐに対処方法が分かった。

WinPcapのインストール時に、システム起動時にNPFドライバを開始するようにチェックボックスをオンにする。デフォルトでオンになっているはず。私は起動時の負荷を減らそうと、XPの時からオフにすることにしていたので、このエラーに出くわしてしまった。

システム起動時にドライバを開始しない設定の場合は、次のコマンドを実行する。コマンドプロンプトを管理者権限で実行しておく必要がある。

  • sc start npf (手動でドライバを開始)
  • sc config npf start=auto (次回からは自動開始する設定)

つまり、Wireshark本体が非管理者ユーザで動くので、パケットフィルタドライバを開始できないのだろう。ずっとXPを使ってきてVistaをすっ飛ばしたので、権限周りで戸惑いそうだ。

コマンドプロンプトを管理者権限で実行するには、スタートメニューの「プログラムとファイルの検索」に「cmd」を入力し、検索結果の「cmd.exe」 を右クリック。そして「管理者として実行」を選ぶ。Ctrl-Shift-Enterでもよい。あるいはプログラム一覧をたどってコマンドプロンプトを探 して右クリックする。こっちはCtrl-Shift-Enterが効かない。

これでWiresharkは動くようになったのだが、ときどきWindows 7がフリーズしてしまう。pingには応答するしマウスも動くが、何も操作できない。Windows 2003ゲストでは問題ない。類似事例が見つからないということは、私の環境に何かあるのだろうと思って調べたら、トリガーが分かった。

キャプチャしたパケットをリアルタイムで画面に表示し、かつ自動スクロールしていると起きる。画面更新の処理が追いつかないなど、ディスプレイドライバあたりの問題のようだ。似たようなフリーズをWindows 3.1やWindows 95でよく経験した。Capture Optionsの「Update list of packets in realtime」をオフにすれば回避できる。パケットをキャプチャできているかどうか不安なときは、「Hide capture info dialog」をオフにすればよい。Preference→Captureでこの設定をデフォルトにできる。

以前のWiresharkは、リアルタイムのパケット表示をせず、Capture infoダイアログを表示するのがデフォルトだったと思う。PCの性能が上がって、リアルタイム更新で問題ないと判断して仕様を変更したのだろうか。

(参考文献)

NPF driver Problem in Windowns 7
http://ask.wireshark.org/questions/1281/npf-driver-problem-in-windowns-7

Platform-Specific information about capture privileges
http://wiki.wireshark.org/CaptureSetup/CapturePrivileges#windows

Run a Command as Administrator from the Windows 7 / Vista Run box
http://www.howtogeek.com/howto/windows-vista/run-a-command-as-administrator-from-the-windows-vista-run-box/

| | コメント (1)

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)

2011年1月 6日

Windows 2003にリモートデスクトップ接続するための設定

Windows 2003にリモートデスクトップ接続しようとすると、次のエラーで失敗した。対処をメモっておく。

このリモートコンピュータにログオンするには、ターミナルサービスでのログオンを許可する権利が必要です。既定では、Remote Desktop Usersグループのメンバにはこの権利があります。Remote Desktop Usersグループのメンバまたはこの権利がある別のグループのメンバではない場合、またはRemote Desktop Userグループにこの権利がない場合、権利を手動で得る必要があります。

Remote Desktop Usersグループの最後の「s」が、3箇所目で抜けているのが面白い。

まず、アカウントをRemote Desktop Usersグループに入れる。すぐに有効にならないことがあるようだ。しばらく待つか、一時的にAdministratorsグループに入れて、そのほかの設定が正しいかどうかを確認してみる。

ログオン先がドメインコントローラなら、ドメインコントローラセキュリティポリシーの「ユーザー権利の割り当て」→「ターミナルサービスを使ったログオンを許可する」にRemote Desktop Usersを追加する。既定ではAdminstratorsグループのみが許可される。ドメインコントローラ以外のマシン(サーバ、ワークステーション)はRemote Desktop Usersグループも既定で入っている。サーバの役割によって挙動が異なるので、ここでハマってしまった。要注意。

| | コメント (1)

« 2010年12月 | トップページ | 2011年2月 »