OpenVPN&セキュリティ情報
2011-12-08
紛失したUSBメモリ、その中身は...?
download.comのOpenVPN GUIは使わないで!
CNETのdownload.comで公開されているアプリケーションで、インストーラにマルウェアがバンドルされていたという話、ITmediaなどでも取り上げられていますね。download.comはオープンソース、製品のデモ版などのたくさんのソフトウェアがダウンロードできるため、多くのユーザーが使用しています。
発端はNmapの作者であるGordon Lyon氏が自身のWebサイト(http://insecure.org/news/download-com-fiasco.html)で取り上げたことからですが、David Sommerseth氏がOpenVPN MLに送ったメールによれば、download.comからダウンロードできるOpenVPN GUIにもマルウェアがバンドルされていたようです。そのメールの内容はこちら。
2011-12-07
sqlite authentication plug-in for OpenVPN
This is an authentication plug-in for OpenVPN. It uses sqlite database for ID/Password authentication. It is python script, so you can modify this script as necessary.
2011-12-06
2011-11-24
OpenVPNのオランダ政府機関での採用が決定
2011-11-21
OpenSSLのパフォーマンスに関する実験結果
2011-11-05
OpenVPN設定 - 鍵と証明書の作成
2011-11-02
OpenVPN設定 - 認証局の設置
OpenVPNの設定は、まずこの認証局を設置することから始めます。
2011-10-13
OpenVPNのインストール手順
OpenVPNはとても便利なツールですが、Linuxでのインストールで引っかかってしまうという方もいらっしゃるようです。今回は新規インストール直後のCentOS 6にOpenVPNをインストールする手順を解説します。
2011-09-23
OpenVPNの"BEAST" exploitについての見解
2011-09-12
「ドッペルゲンガー・ドメイン」によるメール盗難
このタイポスクワッティングの危険性をメールの分野で調査した結果がnakedsecurityの「Missing dots from email addresses opens 20GB data leak」で取り上げられています。レポートそのものはwired.comの「Doppelganger Domains(ドッペルゲンガー・ドメイン)」で読むことができますが、かなりショッキングな結果になっています。
2011-08-26
8月23日のアメリカ東部の地震とインターネットトラフィック
8月23日の午後1時51分、アメリカ東部でマグニチュード5.8の地震が発生しました。大きな被害はなかったようですが、この地方は前回の地震から90年以上経過しているとあって、人生初の地震体験となった方も多かったようです。
インターネット・トラフィックを調査しているcomScoreのブログでは、この地震が発生した前後のトラフィックのグラフが掲載されています。PCのトラフィックとモバイルのトラフィックそれぞれのグラフが掲載されていますが、いずれも左の軸は通常のトラフィックとの比率(100%が通常時の平均)、下の軸が時刻です。震源地からの距離に応じて折れ線の色が分けられています。
2011-08-17
SSL VPNの安全性に関するホワイトペーパーを読んで
この記事はNCPというセキュリティ会社が公開したホワイトペーパー「Debunking the Myths of SSL VPN Security」に基づくものです(ホワイトペーパーは無料でダウンロードできますが、メールアドレスの登録が必要です)。タイトルも「SSL VPNのセキュリティの神話を暴く」というほどですから、力の入れようが伝わってきます。
2011-08-10
スマートデバイスに関するセキュリティレポート
ここでいう「スマートデバイス」とは「PC以外のデバイスで、ネットワーク(主にインターネット)に接続するデバイスすべて」を指しています。スマートフォンはもちろん、ネットワークプリンタやネットワーク機器(ルータやスイッチなど)、AV機器やゲーム機などが含まれます。考えてみると、ここ数年でオフィスや家の中にあるいろいろなデバイスがネットワークにつながるようになりましたね。
レポート内では興味深い数々のアンケート結果が取り上げられていますが、その中で、昨年と同じアンケート項目の結果で大きな変化が出ている一つのアンケート項目があります。
2011-08-05
Androidアプリケーションのセキュリティ
Androidアプリケーションとしてマルウェアを配布する方法として今最も手軽かつ広く用いられているのが、既存のアプリケーション(特に人気を集めそうなもの)にマルウェアを入れ込み、それを「リパッケージ」してアプリケーションとして公開する、という手法です。元記事にあった解説図がわかりやすかったので、日本語化してみました。
2011-07-28
Webアプリケーション・ファイアウォール(WAF)の限界
mod_securityはご存知のとおり、Apacheモジュールとして提供されているWebアプリケーション・ファイアウォール(WAF)です。少し前に、mod_securityが導入されたテストサーバーへのSQLインジェクション攻撃を仕掛ける「SQL Injection Challenge」というイベントが開催されました。「とにかく早く攻撃を成功させる」という「Level.1」と、「mod_securityの警告を表示させることなく攻撃を成功させる(より実践的といえるでしょう)」という「Level.2」の2つのカテゴリで行われ、見事に何人かのユーザーが攻撃を成功させました。この記事では、このうち「Level.2」で攻撃を成功させた9人の手順を詳しく解説しています。SQLのコメント機能を使ったもの、Cookieを使ったもの、タブ文字などの特殊文字を使ったものなど、まさに多彩といえる攻撃パターンです。
Webアプリケーション・ファイアウォールを使用する際には、以下の点を覚えておいたほうがよいでしょう。
2011-07-19
[OpenVPN TIPS] 証明書認証ではなく、ID/パスワード認証を使用する
OpenVPNでID/パスワード認証を使用する場合は、以下のようにします。
[1] ID/パスワード認証を行うプラグインを作成する
OpenVPNでID/パスワード認証を行うには、ユーザーから送信されてくるID/パスワードを認証する機能を独自に実装する必要があります。この実装方法には2つの方法があり、(1) スクリプトプラグイン(auth-user-pass-verifyディレクティブと組み合わせる)を使用する、(2) コンパイルされたShared ObjectやDLLとしてのプラグイン(pluginディレクティブと組み合わせる)を使用する、のいずれかになります。動作速度やセキュリティの面では (2) が優位ですが、(1) のほうが手軽に利用できます。基本的な動作は共通で、スクリプト内で認証処理を行い、認証に成功したら 0 を、失敗したら 1 を戻り値として返します。[2] サーバー側のOpenVPN設定ファイルを変更する
サーバー側のOpenVPN設定ファイルを変更し、作成したプラグインを使って認証を行うよう設定します。では、iniファイル形式で記述されたID/パスワードファイルを使って認証を行う、簡単なpythonスクリプトを作成してみましょう。
2011-07-14
インターネット上でまた一人の死者が生まれた
こちらでもオバマ大統領暗殺のデマについて取り上げましたが、SNSの普及により情報の発信と拡散が容易になった結果、この手のデマの広がる規模やその速度は今まで以上になっています。他にも、過去にはトム・クルーズやジョニー・デップ、エマ・ワトソンやカニエ・ウェストなどがインターネット上では一度死んだことになっています。
単なるいたずらとしてのデマだけでなく、衝撃的なニュースで興味を引かせ、URLにリンクさせてマルウェアを仕込むような攻撃も頻発しています。大きなニュースや、「まさか!?」と思うようなニュースのときには特に、複数の情報源、特に信頼できる情報源から裏を取るような習慣を根付かせておくことは大切ですね。
2011-07-13
今後1年の間に、1/20のAndroid/iOSデバイスがマルウェアに感染するという予測
5% of iPhones/Android handsets to be infected in next 12 months から。この記事では、単にマルウェアによる被害が拡大する、という点よりも、オンラインバンキングや支払い機能などをターゲットにしたマルウェアやトロイが大幅に増加するという懸念が取り上げられています。ユーザーの名前やメールアドレスといった基本情報を盗み出す段階から、お金に直結する情報、オンラインバンキングのIDとパスワードなどの重要な情報を抜き出す段階に移行してきているということでしょう。
現時点においては、AndoroidやiOSを搭載したスマートフォンから使用できるオンラインバンキング機能を提供している金融機関はまだそれほど多くはありません。しかし、金融機関の公式Webサイトからのアクセスという形での利用は可能な場合も多く、専用アプリなどによる対応も今後は広がっていくことになるでしょう。何らかのマルウェアに攻撃されたスマートフォンでオンラインバンキング機能を使用したときにIDやパスワードが抜き取られるという「Man in the Mobile」攻撃が発生することは容易に想像できますし、既にこの種のツールがAndroidへ移植されているという観測もあります。
iOSについても、仕組み上はAndroidよりも安全なようですが、ユーザーが思っているほどは安全ではないとのこと。少なくないユーザーがJailBreakしていることもあり、やはり同じリスクがあると述べられています。
スマートフォンのユーザー層の拡大は疑いようはありませんし、今後も世界中で拡大を続けていくでしょう。その中での5%とすると、その数も相当になります。スマートフォンは機能性や手軽さが強調されることが多いですが、こういったリスクや危険性があることも併せて知っておく必要がありますね。
2011-07-07
Dropbox 認証バイパス事件、集団訴訟へ
こちら(続編はこちらとこちら)で取り上げたDropboxの認証システムのバグですが、その後の対応について集団訴訟が起こされました。Dropbox Cloud Authentication Bug Sparks Class Action Suit で報じられています。
これらの記事によると、ロサンゼルス在住のDropboxユーザー Cristina Wong が集団訴訟を起こしたとのこと。訴えによると、Cristinaはユーザーだったのに、この問題や危険性について数日後のニュース報道まで知らず、Dropboxから何の連絡も来なかったことを問題視しています。Dropboxの唯一の公式アナウンスとなったブログでの投稿はユーザーへの通知としては不十分であり、すべてのユーザーが適切な通知を受け取るべきだったと主張し、さらにはDropboxが「他のストレージサービスよりも安全」であると宣伝し、ユーザーに機密データや重要なデータをアップロードさせた、としています。
ちょうどこのタイミングでDropboxが規約を変更したことも相まって、ユーザーに議論を巻き起こしているようです(なお、Dropboxの公式サイトに掲載されている改定後のサービス規約やプライバシーポリシーはまだ英語のみです。Dropboxは日本でもかなりのユーザーがいますが、ここに掲載されている英語の長文の文書を日本の多くのユーザーは理解できないことになります)。
まだ訴訟が起こされた直後という段階ですが、個人的にもDropboxの今回の対応に懸念を抱いていたこともあり、今後も注目していきたいと思います。まさにクラウド時代の構造とも言える、それほど大きくない会社が世界中に膨大なユーザーを抱えるという『クラウドサービス』で起きた問題に対するユーザー対応という意味でも、特に注視すべき事例と言えると思います。
2011-07-04
FoxNewsのTwitterアカウントがハックされて...バラク・オバマの暗殺をツイート
報道機関の公式Twitterアカウントの情報は、ユーザーから一定の信頼を持って受け止められますから、その公式アカウントでデマが流れることは大きな問題です。当然このデマは人々の関心を呼び、リツイートされていると報じられています。当然他のニュース報道などから見て事実ではないことはすぐにわかりますから、デマとわかって拡散しているのでしょう。
ちなみに、日本時間の7月4日の午後8時45分現在、このツイートは削除されていません。パスワードを変えられて(まあハッキングした後は当然そうするでしょうが)入れなくなり、ツイートの削除ができないということでしょうか。
ID(メールアドレス)とパスワードだけでログインでき、いとも簡単に情報を広く拡散できるのは、Twitterの大きなアドバンテージであると同時に、リスクでもあります。企業の公式Twitterアカウントもたくさん存在していますが、アカウントの乗っ取りなどが発生しないよう、今まで以上に情報管理の徹底が求められますね。
2011-07-01
2010年 情報セキュリティインシデントに関する調査報告書から
この報告書の内容で、注目すべき傾向はこのようなものです。
- 原因としては、「管理ミス」、「誤操作」、「紛失/置き忘れ」という3つの合計で80%に。いわゆる外部からの攻撃というよりは、内部の問題が多いことがわかります。
- 流出媒体として一番多いのは「紙媒体」で約70%。その後「USB等可搬記録媒体」の12.4%、「電子メール」の6.8%と続きます。
- 業種として一番多いのが「公務」で33.1%。その後「金融業、保険業」、「教育、学習支援業」と続きます。
意外なことに、家で業務をするなどの理由で不正にデータを持ち出してしまうケース(「不正な情報持ち出し」)というのはそれほど多くないようです(上記の「紛失/置き忘れ」は許可されている状況下でデータを持ち出し、紛失してしまったというケースです)。最近は個人情報の持ち出しについてはかなり意識されているということでしょうかね。
この報告書の結果から見える一つの点は、「セキュリティ」といってもシステム的な面だけでなく、ユーザーの意識や行動に起因するものもかなり多い、という状況です。
「管理ミス」や「誤操作」は基本的に人間のミスに起因するものです。人間はどうしてもミスをするものなので、そのミスをシステムでカバーする、またはそもそもミスを起こりにくくする、という観点から仕組みを作る必要があります。たとえば「BCCに入れるべきアドレスをCCに入れてしまった」というような典型的なケースを避けるために、通常のメールソフトを使わずに配信専用のツールを使う、などの方法も簡単な一例ですね。
外部からの攻撃に備えると同時に、ヒューマンエラーによる情報流出被害を最小化するためにいかにシステムやツールを活用できるか。こういった提案力が求められる時代、特にユーザーの観点に立った現実的なソリューションを提供できるよう考えていきたいと思います。
2011-06-28
ネットワークからの攻撃より危険!? 拾ったUSBメモリを使う人は少なくないらしい
政府や民間の建物の駐車場にCD-ROMやUSBメモリを置き去りにし、それを拾った人の行動を調査したものです。その結果、その記憶デバイスを拾った人のうちの60%のユーザーがデバイスを自分のPCに接続し、そのデバイスやCDケースに公式のロゴが入っている場合は90%のユーザーがインストールした、ということです。
制御機器を攻撃することで知られるStuxnetもUSBメモリを媒介にして広まりましたが、人間の好奇心という脆弱性はなかなか対策が難しいようです。
2011-06-26
Dropbox 認証バイパス事件 続報
そのメールによれば、被害を受けたユーザーは100人未満だったとのこと。そして、少なくともファイルの改変は行われていないようだ、とのことです。これはそれほど規模が拡大しなかったという意味ではいい内容です(と言ってもその100人の中の1人であれば大問題なわけですが...)。
一方の悪いニュースは、被害者全員のアカウントにアクセスしていた1人のユーザーがいる、ということです。つまり、タイプミスなどでうっかり他人のアカウントにアクセスしたわけではなく、このバグを利用して意図的に他人のアカウントにアクセスしていたユーザーが存在した、ということです。
被害者宛のメールでは、被害者が取る必要のある対策の概要が記載されています。また、DropboxのCEOであるDrew Houstonの電話番号が載せられており、質問などがあれば遠慮なく電話して欲しいとも書かれています。この問題に対してDropboxが危機感を持っている表れとも言えるかもしれません。
ただ....やはりこの情報もTechCrunchという外部の情報源からとなってしまいました。Dropbox Blogにも被害者の人数が100人未満だったことなどは追記として記載されていますが、あくまでもそれだけ。おそらくDropboxとしては、直接の被害者以外には細かい情報提供は行わないという方向性で進めているように見えますが、これが吉と出るか凶と出るか。
2011-06-24
流出したパスワードから傾向を読み取る
詳細な分析結果は元記事を見ていただくのが一番ですが、ちょっと要約するとこんな感じです。
- 長さは6文字と8文字が多い
- 英大文字、英小文字、数字、記号のうち3つ以上を使っているのは4%程度
- よく使われていたパスワード TOP10は以下の順序(元記事ではTOP 25が挙げられています)
- seinfeld
- password
- winner
- 123456
- purple
- sweeps
- contest
- princess
- maggie
- 9452
- インターネット上に公開されているパスワード辞書に合致したものは36%
- Sony内の複数サイトで共通したパスワードを使っていたケースが92%。
- ハッシュ解読で使用されるRainbow Tableで簡単に解析される「9文字以下の英小文字パスワード」を使っていたのは82%(つまり、流出したパスワードが仮にMD5などでハッシュ化されていたとしても、82%は解読可能だった可能性が高い、ということになります)
元記事のコメント欄でも活発な意見交換が行われていて、なかなか興味深いですよ。
2011-06-21
もう一つ、Dropboxの今回の対応について
「無料で使っているユーザーだったら文句は言えない」という考え方もあるかもしれませんが、せめて注意を促す対応は必要でしょう。
起こした問題だけでなく、その後の対応がユーザーの印象に大きな影響を与えることはたくさんの事例が証明しています。Dropboxが今後どのように対応していくのか、注目したいと思います。
これは大変だ! Dropbox 認証バイパス事件
数時間前にTwitterではつぶやきましたが、この問題はさすがに取り上げないわけにいきませんね...。Dropbox Blogで公式に発表されています。
Dropbox Blogでの記述をもとにすると、6月20日午後1時54分(太平洋標準時。日本時間では21日午前5時54分)にDropboxのシステムのコードに変更を加え、その際に認証メカニズムにバグが入り込みました。その後、午後5時41分(日本時間 午前9時41分)に問題が発覚、5分後の午後5時46分(日本時間 午前9時46分)に修正を完了した、としています。この4時間の間は、パスワードによる認証なしでユーザーのファイルにアクセスできる状態になっていた、ということです。
Dropbox Blogによればこのタイミングでログインしたのは「少数のユーザー(A very small number of users)」で「1%に遠く及ばない(much less than 1 percent)」としていますが、利用しているユーザー数を考えれば「少数」と片付けられる数ではないかもしれません。
ここしばらく続いているLulzsecなどによる情報流出問題とは異なり、これは完全にDropbox単独のミスによるものです。なんで認証に影響を与えるほど重要なコード修正で(しかも5分で修正できるような)バグを残したままProduction環境に投入したのか、コードレビューはなかったのかなど、気になるところは山積みですが、まずはユーザーとして対策を考えましょう。
Dropboxは、侵入された可能性のあるユーザーには個別にメールを送信するとしていますが、まずは重要なデータが入っているようであればすぐにでも退避させておきましょう。また、Dropbox上のファイルにパスワードなどの機密情報が含まれていた場合は、含まれていたパスワードを変更するなどの対策も必要です。
この手のシステムはどこか不安だったので、個人的にはTrueCryptで暗号化したファイルをDropboxにアップしていたのですが、その不安が的中してしまったのは残念です。暗号化をする手間がかかる分、面倒な部分もあるのですが、安全性には代えられません。クラウドを使ったファイル保存サービスはDropbox以外にもありますが、こういったオンラインサービスを利用する際には、重要なファイルだけでもクライアント側で暗号化してからファイルをアップするという慎重さが求められますね。できることなら、第三者の管理するサーバーではなく、自分の管理するサーバーで安全に管理できるのが望ましいですけど...。
nakedsecurityのDropbox lets anyone log in as anyone - so check your files now! には、こういったサービスの特徴である、どんどんアップデートしていく『ずーっとβ版(eternal beta)』スタイルに潜む危険性も触れられています。システム構築に関わる人間として、この点は常に意識しておかないといけないですね...。
2011-06-19
セキュリティエキスパートのように対応するための6つの方法
- ウィルスですか?と聞かれたときには
自信がなくても大丈夫。virustotalを使いましょう。 - 映画のようなハッキングは意外と簡単です
定番のnmapにはとてもいいGUIがあります。zenmapを使いましょう。iPhoneやAndroidには簡易版のようなOverlook Fingがありますよ。 - セキュリティに関する最新のニュースを常に追いかけるのは大変ですよね
1つお勧めするとしたらBruce Schneierのニュースレター「Cryptogram」です。毎月配信されるニュースレターです。 - リンク先の安全性をチェックするためにVM(仮想マシン)を使って1つずつ調べるのも大変です
リンク先に関するレポートを表示してくれるwepawetを使いましょう。 - パケットアナライザであるWiresharkを使いましょう
ネットワークで何が起きているのかを的確に把握できます。また、暗号化されていないパスワードが参照できることを見せるのはいいデモになるでしょう。 - WindowsだけでなくLinuxも使ってみましょう
まだ使ったことがなければ、インストールせずに使えるLive CDから使ってみましょう。セキュリティという観点から興味深いのはパスワードを復旧するために使用できるTrinity Rescue Kitです。またペネトレーションテストに特化したディストリビューションであるBackTrackもあります。
2011-06-16
iPhoneでよく使われるパスコードとは?
堂々のトップは、さすがの「1234」に! 第2位に3,000票以上の大差をつけての大勝利です。
第2位は「0000」。これも5,000票を超える優秀な成績です。
第3位に食い込んだのは「2580」。いかにもよくありそうな「1111」や「5555」を上回っての勝利は価値がありそうですが、この番号はどんな意味が...? あ、単純にキーパッドを上から下にってことですね。7位の「0852」はこれの逆で、下から上にということです。
興味深いのは第7位の「5683」です。「ごろーやーさん」とかって語呂合わせではなく、アルファベットの「love」を数値に置き換えたもののようです。他にもなかなか興味深いデータがたくさん出ていますので、関心ある方はこちらからどうぞ。
しかし、今回の統計で集まった20万以上のパスコード全体の中で、よく使われるパスコードの上位10位以内のいずれかを使っていたものが15%もあった、という結果はちょっと考えさせられますね...。
2011-06-13
[OPENVPN TIPS] VPNクライアントに固定IPアドレスを割り当てる
OpenVPNでは、接続してきたクライアントのVPNアドレスは動的に割り振られます(その際に割り振られる際のアドレス範囲はOpenVPNサーバー側設定ファイルに基づきます)。特定のVPNクライアントに特定のVPNアドレスを割り振りたい場合、OpenVPNでは以下の2つの方法で設定することができます。
- client-connectディレクティブで指定されたスクリプトによって生成される設定ファイルを使う
- client-config-dirディレクティブで指定されたディレクトリにクライアント構成ファイルを配置する
まず、サーバー設定ファイルのclient-config-dirディレクティブでクライアント構成ディレクトリを指定します。クライアント構成ディレクトリは、VPNクライアントごとの個別の設定ファイルを格納するディレクトリです。たとえば、クライアント構成ディレクトリを
/etc/openvpn/ccd
にする場合は、以下のようにディレクティブを設定します。client-config-dir /etc/openvpn/ccd
次に、クライアント構成ファイルを作成します。クライアント構成ファイルは、特定のVPNクライアントにのみ適用したい設定を記述しておくファイルで、ファイル名はその設定を適用したいクライアントの証明書の共通名と同じものにします。たとえば、クライアント構成ディレクトリは前述のように
/etc/openvpn/ccd
で、設定したいクライアントの共通名が「client1」であれば、クライアント構成ファイルは /etc/openvpn/ccd/client1
になります。このクライアント構成ファイルに、クライアントに割り当てるVPNアドレスを設定するためのipconfig-pushディレクティブを記述します。TAPを使用している場合で、そのクライアントに 192.168.5.123 を割り当てたい時には
ifconfig-push 192.168.5.123 255.255.255.0のようにIPアドレスとネットマスクを記述します。TUNを使用している場合は、クライアントに割り当てたいアドレスとサーバー側にあたるアドレスをセットで指定し、
ifconfig-push 10.8.2.5 10.8.2.6のように記述します。
クライアント構成ファイルを使う際の注意点を。クライアントごとに適用したい設定ファイルを証明書の共通名で判別するため、複数のVPNクライアントが同一の証明書(同じ共通名の証明書)を使って接続することはできません。したがって、duplicate-cnディレクティブとの併用はできません。
2011-06-08
[OpenVPN TIPS] OpenVPNのIPv6対応
OpenVPNでのIPv6サポートはどうなっていますか?
OpenVPN 2.2-RC2以前のバージョンでは限定されたIPv6対応が行われています。IPv6 TUNドライバがサポートされているOS(LinuxやBSDなど)では、PtoP IPv6トンネルがサポートされています。IPv6 over TAPはEtnernet上の他のプロトコルと同様、常にサポートされています。OpenVPN 2.0がサーバーモードで実行されている場合は、IPv6はTAPモードでのみサポートされます(TUNモードではサポートされません)。VPNのキャリア接続はIPv4エンドポイントを使用する必要があります。
OpenVPN 2.2-RC2では、Windows TAPドライバ用のTUNモードでのIPv6対応が実装されました。
完全なIPv6のサポートはGitの「allmerged」ブランチで利用可能になっており、OpenVPN 2.3で組み込まれる予定です。
2011-06-07
パスワードをどう保持するか ー それが問題だ
ログイン機能を持つWebシステムはたくさんあります。各ポータルサイトやオンラインショップなど、私たちが日常的に使っているものだけでもいくつかありますよね。特定のユーザーだけが使用する業務システムのようなものも含めれば、それほど膨大な認証システムが存在していることになります。
Sony Pictures Entertainmentのユーザー情報が流出した際にパスワードがプレーンテキストだった、という問題がありましたが、これは論外としても、システムを作る開発者としてユーザー認証のための情報をどう保持するか、という点は設計時によく検討しなければならない点の1つです。もちろんデータの流出自体を避けなければならないわけですが、万が一データの流出が発生したとしても、重要なデータはそのままではわからないようにしておく必要があります。
先週末にはFBIの関連組織であるInfragardのユーザー情報がクラックされたというニュースがありました。パスワードは暗号化されていたものの、復号されてしまったようです。saltが適切に設定されていなかった、または簡単に分かるsaltが使われていたのではないかと言われています。暗号化のアルゴリズムの弱点というよりは、システム自体の作りの甘さを示す一例といえます。
一般的には可逆性のある暗号化ではなく、非可逆のハッシュを使ってパスワードを保持しておくという方法がよく使われますが、これにもちょっとした落とし穴が。MD5やSHA1は既に破られる可能性があるので、もう使わないほうが安全です。たとえばMD5なら、ここやここ、ここなどのサイトで解読できるか試すことができます。現時点ではSHA1よりも安全性が高いといわれるSHA2を使うことが多いと思いますが、こういった仕組みはいつかは破られる宿命にあるものと考えて、常に新たな取り組みも含めて検討していく必要がありますね。
前述のMD5の解読サイトでいろいろ試していると、ひとつの重要な傾向に気づきます。それは、一般的な単語の組み合わせや、アルファベットだけの組み合わせだと本当に簡単に解読されることです。日本語の名前のアルファベット表記や、それをちょっといじったぐらいのものでも解読されるケースがあります。記号を含めたり長いパスワードにしたりといった複雑なパスワードにすると、解読される可能性が大幅に下がることが実感できます。
ユーザーとしてはそのシステムでどんな仕組みでパスワードが保護されているのかわからないわけで、とにかくパスワードを複雑にすることが唯一の自衛手段ですね。
2011-06-05
[ブックレビュー] 電話はなぜつながるのか
Asteriskを使ってIP内線網を構築したりといった経験はあるものの、改めて電話の基本を知っておこうと思って手に取った本です。
固定電話から携帯電話、IP電話の概念や仕組みが幅広く取り上げていますが、特に固定電話を中心に書かれています(といっても、IP電話などについても、使う上で押さえておくべき基本的な知識は十分書かれており、知識の整理に役立ちます)。
固定電話に関する情報は特に充実しており、NTTの電話回線網の仕組みがわかりやすく説明されています。この本はこの「わかりやすく」がポイントで、写真や図に加え、例えなども活用した説明が繰り広げられていて、私も含め、電気通信にそれほど詳しくない人でも抵抗感なく読み進められます。内容としてはかなりマニアックな領域まで踏み込んでいるのですが、知っておくと「なるほどね」と思える情報が随所に散りばめられています。
300ページを超える本なのでちょっと腰を据えて読むことになりますが、テレコミュニケーションは(形や仕組みは変わっていくでしょうが)今後も使い続けられていくものですし、そもそも「ネットワーク」=「網」として私たちにとって一番身近だったのは他でもない電話回線網。ネットワークの大先輩のこと、改めて知っておくのもいいかもしれません。
2011-06-03
さすがにこれは... Sony Pictures Entertainmentのデータ流出問題
今回の最大のシステム上の問題はこれでしょう。
今どき誰もが知っているべきレベルの簡単なSQLインジェクションでデータを取れた("SonyPictures.com was owned by a very simple SQL injection, one of the most primitive and common vulnerabilities, as we should all know by now.")という彼らの言い分が事実ならそのシステムの作り自体も大問題ですが、パスワードがデータベース上にプレーンテキストで保存されていたというのは弁解の余地がありませんね...。盗まれたデータも既にインターネット上に公開されており、メールアドレスとパスワードの組み合わせで第三者に流出してしまったことになります。他のサイトでも同じパスワードを使っているようなケースがあるとしたら...と考えると非常に危険なことがわかります。
PCWorld Security Alertでは、自分の情報が流出している可能性がある場合はすぐに次のように対応するよう勧めています。
- とにかくパスワードをすぐに変更する。同じパスワードを使っているサイトがあればそのサイトのパスワードも変える。
- フィッシングメールが急増する可能性があるので十分注意する。怪しいメールは絶対に開かない。
- メールだけでなく、通常の郵便も同様の危険がある。住所も流出している場合は特に注意する。
- クレジットカードや銀行の使用状況に注意する。これらの情報が流出した可能性がある場合は口座やカードを作り直したほうがいい。
- 流出した個人情報をもとにクレジットカードや口座が作成される恐れがあるため、詐欺に使用されないように注意する。
- (アメリカ国民の場合)毎年送られるクレジットカードの利用レポートをよく確認する。
2011-06-02
Gmailアカウントのフィッシング攻撃
Official Google Blogで取り上げられたこの問題、日本の各メディアでも取り上げられていますね。
ただ、その記事のタイトルが「Googleへの攻撃」といったニュアンスのものもあり、セキュリティに関する情報提供の難しさを感じさせられます。Official Google Blogでもあえて「Gmail自体のセキュリティの問題ではない」と書かれていますね。
今回の問題はGmailのシステムに攻撃が加えられたということではなく、一部のユーザーがフィッシングサイトに引っかかってしまい、フィッシングサイト上でGmailにアクセスするためのIDとパスワードを入力してしまったことが原因です。攻撃者はそのIDとパスワードを利用してGmailにアクセスし、メールの転送設定を追加することでメールの内容を盗んでいた、ということです。対象となったユーザーが米政府高官や中国の政治活動家などだったことから、特定の対象を狙ったものであることが推測できます。攻撃手法についてはこちらにまとめられています(今年の2月に報告されているものです)。
この問題に対して、Googleは2段階認証(ワンタイムパスワード)を使うことを推奨しています。この方法は今回のような問題の対策としてとても有効なものです。ただ、この設定は初心者にはちょっと敷居が書く(日本国内の場合はSMSを使った認証なども使用できないため、より条件が難しくなります)、広く普及させるのはなかなか難しいと思われます。
Gmailのようなフリーメールアカウントに限らず、各プロバイダから提供されるメールアドレスでもWebメールが提供されることが一般的になっています。どこからでもWebサイトにさえつながれば利用できるという利点もあり、特にライトユーザーがWebメールを多用する傾向が強いようです。セキュリティに関する知識をそれほど持ち合わせていないユーザーを対象にする場合は、セキュリティを向上させるために設定を変更させたり、手順を増やして対応させたりするのはあまり現実的ではありません。この問題、いろいろな企業システムでも同じように直面している問題です。
企業においては、システム側の対応を進めることはもちろんのこと、「怪しいメールは開かない」「怪しいリンクはクリックしない」「機密情報はメール以外の方法(または暗号化するなどの対策を取る)でやり取りする」といった基本的なユーザー教育を徹底するのが最初の一歩かな、と思います。攻撃するのも人間なら、身を守れるのも人間、ですもんね。
2011-06-01
OATHによるワンタイムパスワードの仕様 - 3
参考としてpythonのコードも併記してみます。
1. タイムステップを考慮したカウンタの算出
TOTPの場合、カウンタはunixtimeになります。しかし、これをそのまま使うとワンタイムパスワードが毎秒変わってしまうことになり、さすがにこれは実用的ではありません。それで、ワンタイムパスワードが切り替わる間隔としてタイムステップ (Time-Step) を設定し、unixtimeをタイムステップで割った値をカウンタとします。messagetime = unixtime / timestepこれにより、タイムステップが30なら、30秒間は同じワンタイムパスワードが生成されることになります。
※ OATHの仕様ではタイムステップとして30秒が推奨されています。
2. HMAC (SHA) の算出
まず、1.で生成した値を16バイトの16進数表記に変換します(バイト数が足りない分はゼロ埋めします)。その16バイトをASCII文字列に変換したものをデータとし、パスコードをキーとしてHMACダイジェストを算出します。message = '%016X' % messagetime h = hmac.new(key, message.decode("hex_codec"), sha) d = h.digest() hmac_result = [] for c in d: hmac_result.append(ord(c))これにより、20バイトのハッシュ文字列が生成されます。この文字列の文字コードを1文字ずつ配列に格納しておきます。
※ なお、ハッシュの算出にはSHA-1だけでなく、SHA-256やSHA-512なども使用できます。
3. オフセットの算出とビット演算
2. で生成されたハッシュの最後のバイト(20バイト目)を 0xf でマスクした値をオフセットとし、そのオフセットに基づいてビット演算を行います。offset = hmac_result[19] & 0xf sn = (hmac_result[offset] & 0x7f) << 24 | \ (hmac_result[offset+1] & 0xff) << 16 | \ (hmac_result[offset+2] & 0xff) << 8 | \ (hmac_result[offset+3] & 0xff)
4. ワンタイムパスワードの出力
3. で計算された値を 10のn乗(nはワンタイムパスワードの桁数となります)で割ります。その余りがワンタイムパスワードとなります。8桁の場合はこのようになります(桁数を合わせるためにゼロ埋めが必要です)。result = '%08d' % (sn % 10**8)
OATHの仕様には、Javaで記述されたリファレンスコードが掲載されています。また、生成されたワンタイムパスワードの値が正しいかどうかをテストするための値のリストも載せられていますので、独自に実装した際の確認のために使用することができます。
今回説明したように、ワンタイムパスワードの生成自体はそれほど難しいものではなく(計算は少々ややこしいですが…)、スクリプト言語でも比較的簡単に実装できます。PHPやpythonなどで開発されたWebアプリケーションに組み込むことも容易ですし、スマートフォンを使ったソフトウェア・トークンもいろいろと出てきていますので、Webアプリケーションのセキュリティを高めるためにも取り組んでみるいい機会かもしれませんね。
2011-05-30
OATHによるワンタイムパスワードの仕様 - 2
ワンタイムパスワード生成方法のキホン
OATHでは後述する2つの方法が規定されていますが、基本的な仕組みは同じです。ワンタイムパスワードを生成するために必要なデータは2つ、(1) ユーザーが決めたパスコード(一般的なパスワードと同じもので、「シークレット」とも呼ばれます)と、(2) 回数や時刻などのカウンタです。これらをサーバーとクライアントの両方で共有しておき、この2つのデータから決められた方法で計算した結果をワンタイムパスワードとして生成します。
OATHで規定している2つの生成方法は、(1) は共通で、(2) の部分だけが異なります。では、それぞれの方法について説明しましょう。
[1] HOTP : 利用ごとに生成する(生成回数ベース)
利用者がトークンのボタンを押すなどしてパスワードを生成するたびに、新しいワンタイムパスワードを生成します。この方法は最も基本的な方法で、OATHの規格では HOTP (HMAC-Based OTP Algorithm) として規定されており、RFC 4226としても規定されています。カウンタとして使用されるのは「今回のパスワード生成が何回目のパスワード生成か」を示す値です。この値は生成するたびに1つずつカウントアップされますが、サーバー側 (HOTP validator) とクライアント側 (HOTP generator) でこの値を共有していなければなりません。クライアント側はパスワードを生成した回数(何回目の生成か)、サーバー側は認証処理を行った回数(何回目の認証か)を持つことになります。
しかし、このカウンタはサーバー側とクライアント側で同一値になる保証がありません。例えば、パスワードは生成したがそのパスワードを使って認証処理を行わなかった、という場合には値がずれることになります(生成回数 > 認証回数となるため)。そのため、サーバー側にカウンタを再同期 (resync) させる機能を備えておく必要があります。
[2] TOTP : 現在の時刻に応じて生成する(時刻ベース)
一定時間ごとにワンタイムパスワードを生成します。OATHでは TOTP (Time-based One-time Password Algorithm) として規定されており、規格はドラフトとして公開(2011年4月現在)されています。仕組み上は、前述したHOTPの応用といった位置付けになります。カウンタとして使用されるのは「現在の時刻(UnixTime)」です。ワンタイムパスワードの基準が時刻であるため、サーバー側とクライアント側のそれぞれのデバイス(PC、スマートフォン、トークンなど)の時刻が正確でなければなりません。認証の仕組みを作る際にはある程度の時刻のずれは考慮しますが、当然ながら時刻が大幅にずれていると正しく認証できませんから、NTPやGPSなどを使って定期的に時刻が補正されているデバイスが望ましいでしょう。
では、次回は実際のワンタイムパスワードの算出方法を解説しましょう。
2011-05-27
OATHによるワンタイムパスワードの仕様 - 1
そもそもワンタイムパスワードとは?
「ワンタイムパスワード」はその名の通り、その時だけ有効な1回限りのパスワードを使って認証を行う仕組みです。使用するたびにパスワードが変わることになるので、万が一パスワードが漏えいしても、そのパスワードを他人に悪用される危険性を大幅に削減できます。では、利用者は毎回変わるパスワードをどうやって知るのでしょうか? 利用者は自分の使うパスワードを知るために、ワンタイムパスワードを生成する「道具」を別に持っている必要があります。
この「道具」としてよく用いられているのが「トークン」と呼ばれるものです。このトークンには、ボタンを押すたびに新しいパスワードが生成、表示されたり、決まった時間ごと(30秒ごと、1分ごとなど)に新しいパスワードが生成、表示されたりします。最近では、トークンの代わりにスマートフォンのアプリを使う(「ソフトウェア・トークン」とも呼ばれます)ケースも出てきています。
RSA SecurID トークン
WebアプリケーションやVPN機器など、ログイン先の認証システム(サーバー側)が生成するパスワードと、トークン(クライアント側)が生成するパスワードを共通の方法で算出し、両者のパスワードを常に一致させるようにすることによって、ワンタイムパスワードとして利用することができることになります。
次回は、OATHが規定しているワンタイムパスワードの2つの生成方法について取り上げましょう。
2011-05-26
[ブックレビュー] SEOを強化する技術
以前に比べると、本屋さんの棚に並んでいるSEO関連の本がちょっと減ってきたような気がしますが、まだまだたくさんありますね。私もWebサイトに関わることが少なくない(どちらかというとシステム寄りですが)のでいろいろと読んでみたのですが、SEO関連の書籍は個人的に「どうもしっくり来る本がないな」と思っていました(これは多分に私の感性の問題ですが...)。でも、この本はしっくり来ました!
主にGoogleとYahoo!の検索エンジン(まだYahoo!JapanがGoogleの検索エンジンを採用することを発表する前に執筆されています)を前提に、単なる「外部からのリンクを増やせ!」というスタンスではなく、サイト内のコンテンツ自体の質の向上や、ちょっとした工夫によってどのようにSEO対策を行えるのかが解説されています。さらに、コンテンツの移行時にURLを維持するための方法(mod_rewriteを使ったリダイレクトなど)やモバイルサイトにおけるSEO、eコマースやCMSなどでどのようにSEOを考慮した作りができるかといった点も具体的に取り上げており、どのサイトでもどこか適用できそうな、実践的な内容になっています。 コンテンツライターというよりはエンジニアにとって面白い本かもしれません。
とかく検索エンジンのアルゴリズムとのイタチごっこになりやすいSEOのお話ですが、本書ではいわゆる単純な「検索エンジン対策」というよりは、コンテンツそのものの質を高めることに注意が向けられている点が興味深く、かつ普遍的だと思います。著者の実際のSEO対策業務の中で実践されているちょっとしたヒントや手順のアドバイスなどもあり、Webサイトに関わる人なら誰でも参考にできる内容です。
SEOに関する書籍をお探しなら、ぜひ一度書店でご覧になることをお勧めします。
2011-05-24
Androidの脆弱性対応
こちらで取り上げたAndroidのClientLogin認証の脆弱性ですが、18日の時点で対応が進められていたようですね。
ユーザーによる端末のアップデートは不要で、仕組みとしてはサーバーサイドで同期の際のトークン使用時に必ずHTTPSを使うようにした模様です。なにはともあれ、迅速に対応が進められたのはユーザーにとっては朗報です。
ただ、Sophosのnakedsecurity内の該当する記事にも書かれていますが、Android端末が抱えている「OSアップデート(特にセキュリティフィックス)の対応が端末のメーカーに依存している」という点は、特に企業で使用する場合にはセキュリティ面でのリスクとして考慮する必要はありそうですね。
2011-05-20
[OpenVPN TIPS] TCPを使用する場合のスループット
そのため、OpenVPNをUDPで使用するほうが高いスループットを期待できます。しかし、ネットワーク構成上(ファイアウォールで許可されていない場合など)、UDPが使用できない場合もありますよね。
OpenVPNをTCPで使用する際には、tcp-nodelayディレクティブを使用すると速度が向上する可能性があります。OpenVPNのmanページにあるこのディレクティブの説明には以下のように書かれています。
このマクロを使用すると、サーバー側でTCP_NODELAYソケットフラグがセットされ、接続してきたクライアントにプッシュされます。TCP_NODELAYフラグはTCPソケット上でのNagleアルゴリズムを無効にし、細かいパケットを大きなパケットにまとめずに即時に送るようにします。TCP上でのVPNアプリケーションでTCP_NODELAYを使用すると、たいていの場合はレイテンシーの向上が見込めます。ディレクティブの書き方は簡単で、サーバー側の設定ファイルに
tcp-nodelayと一行書き加えるだけです。
公開されている実際の測定結果によると、UDPのスループットには達しないものの、UDPと通常のTCPのちょうど真ん中ぐらい(またはそれより少し速いぐらい)のスループットが出るようです。
OpenVPNをTCPで使用しておられる方は一度お試しを。
2011-05-18
AndroidのClientLogin認証における脆弱性
既にいろいろなところでニュースとして取り上げられていますが、ちょっと情報の整理も兼ねて。ドイツのウルム大学の研究者たちの報告が最初の情報源です。
GoogleではClientLoginという認証方式を設けており、この方式に関してはGoogleのサイト上でも開発者向けの情報「Authentication and Authorization in the Google Data Protocol」で説明されています。簡単に言うと、ユーザーが一度Googleアカウントの認証をパスすると、その後最大2週間使用できるトークンがGoogleから発行され、その期間内はGoogleのサービスにそのトークン付きでリクエストを投げれば認証を通過できる(Googleアカウントの再度の認証は不要)、という仕組みです。この仕組みはGoogleのサービスを利用するサードパーティのアプリケーションでも利用できます。
Googleアカウントの認証手続きそのものは暗号化された通信経路上(HTTPS)で行われるため、ここは問題ありません。問題はその後で、認証後に発行されたトークンを使ったGoogleサービスへのリクエストが、暗号化されていないHTTP上を通過してしまうケースがある、ということです。HTTP上を通るのか、HTTPS上を通るのかは、そのアプリケーションの作りに依存します。少なくとも、Android 2.3.3以前のバージョンに搭載されたカレンダーや連絡先などのアプリケーションでは、リクエストがHTTP上を通過する(つまり、トークンが暗号化されない)と報告されています。
前述の「Authentication and Authorization in the Google Data Protocol」で使われている図を使って説明すると、このようになります。
認証に代わるトークンのやり取りが暗号化されていないということは、HTTPのリクエストをキャプチャしてしまえばそのトークンがそのまま入手でき、悪用できてしまうことになります。そのトークンの有効期限内であれば、他人のトークンを使ってGoogleサービスにアクセスできることになってしまうわけです。
Android 2.3.4以降、またはタブレット向けAndroid 3.0では問題が解決されているとのことですが、日本国内に存在するAndroid端末はほぼすべてがそれ以前のバージョンです。Android OSのバージョンアップも基本的にベンダーによる対応に依存しており、ユーザーがこの問題に対処するために自力でバージョンアップすることは難しいでしょう。
ユーザーができる対応としては、
- 公開されている無線LANアクセスポイントなど、第三者による通信の傍受が可能な環境で使用しているときは、Googleアカウントを使用するサービスすべてを利用しない(自動同期なども無効にしておく)。
- Android OSのバージョンアップ情報をこまめに確認し、アップデートが公開されたら速やかに適用する。
といったぐらいでしょうか。私もAndroidのユーザーとして、各ベンダーにも迅速な対応をお願いしたいものです。
2011-05-16
OpenVPNのスループット
詳細は上記サイトを参照していただくとして、要は「いい性能のPCを使ってGigabit上でOpenVPNをつないでみて、どこまでスループットを上げられるか実験してみよう!」ということです。OSはサーバー、クライアントともLinuxです。以下、結果を簡単にまとめるとこんな感じ(すべて計測値はiperfによるもので、プロトコルはUDPを使用しています)。
- 標準設定(MTUやFragmentなどをいじらない&CipherはBlowfish)のOpenVPNスループットで156Mbps。Cipherをaes-256-cbcに変更すると 126Mbps。今回のPCのスペックでは標準のままで100Mbpsは超えます。この速度で十分というケースもありそうですね。
- OpenVPNでMTUの設定値を大きくし、フラグメントを無効にするとスループットが上昇する。たとえばMTUを9000にすると 370Mbps、24000では 466Mbps、48000では 510Mbps。この値が最大で、これ以上MTUを増やすと速度は低下していく。 Cipherをaes-256にすると、MTUとスループットの相関性は低くなる(MTUを上げてもちょっとしかスループットが上がらない)。こんな大きいMTU設定したことない…。
- AES-NIを使用すると速度がかなり向上する(当然、CipherをAESにしないと効果はありません)。たとえば、AES256でAES-NIを使用すると、MTUが9000なら 249Mbps→410Mbps に、24000なら 259Mbps→540Mbps に、48000では 247Mbps→585Mbps に上がります。これは相当なパワーアップですね。
- OpenVPNの暗号化と署名を無効にした場合、 930Mbps というスループットに。Gigabitの範囲であればユーザー空間とカーネル空間の分離はパフォーマンスにそれほど影響せず(この結果によれば7%程度)、やはりOpenSSLによる暗号化と署名の処理がスループットに大きく影響することがわかる。
Profile
- 山崎 太郎 (Taro Yamazaki)
- プラムシステムズ株式会社所属。 主にVPN(OpenVPN)やセキュリティ関連技術、Webアプリケーションを手がけています。
Page Views
Popular Posts
-
「VPNっていろいろあるけど、OpenVPNのメリットって何?」 という疑問は多くの方が持たれますよね。この点は公式サイトなどにもいろいろ書かれているのですが、実際に使ってきたユーザー側としてメリットと思う部分をまとめてみました。
-
現在ダウンロードできるOpenVPNでは、今まで認証局の構築で使用していたeasy-rsaが含まれなくなっています。 OpenVPN.netのダウンロードページ にも Note that easy-rsa is no longer bundled with OpenVPN...
-
Jan Just Keijser氏の記事「 Optimizing performance on gigabit networks 」については こちら でも概要を取り上げましたが、記事全体にいろいろなヒントが含まれていますので、全文の日本語訳を掲載しています。意訳している部分も...
-
OpenVPNでは、接続してきたクライアントのVPNアドレスは動的に割り振られます(その際に割り振られる際のアドレス範囲はOpenVPNサーバー側設定ファイルに基づきます)。特定のVPNクライアントに特定のVPNアドレスを割り振りたい場合、OpenVPNでは以下の2つの方法で設定...
-
では、いよいよiPhone構成ユーティリティでVoDの設定をしてみましょう。あ、 前の記事 での準備はきちんとやっておいてくださいね!
-
前回 は2つのワンタイムパスワードの生成方法について取り上げました。今回はいよいよ実際の生成アルゴリズムを取り上げましょう。TOTPをベースに説明します(ただ、前回も解説したように、基本的なロジックはTOTPとHOTPで同じです)。 参考としてpythonのコードも併記してみま...
-
OpenVPNはLinuxをはじめとした幅広いプラットフォームで動作実績があるのが特徴の一つです。 今回は、最近の電子工作ブームでも話題のシングルボードPC 3機種をOpenVPNサーバーとしてセットアップし、OpenVPNのVPNパフォーマンスを測定してみましょう。
-
現時点においてはマニュアルやHowToにも記載されていない(ChangeLogにちょっとだけ出てきます)あまり知られていない機能なのですが、「設定ファイルで鍵ファイルや証明書ファイルのパスを記載する」という通常の方法とは別に、「鍵ファイルや証明書ファイル内のデータをそのまま設定フ...
-
前回 はワンタイムパスワードの基本的な仕組みについて説明しました。サーバー側とクライアント側で、それぞれ共通のルールに基づいてパスワードを生成させる必要があることを取り上げましたが、今回は OATH が規定しているその生成ルールについて具体的に説明します。 ワンタ...
-
OpenVPN Connect for iOSがリリース されましたので、それを記念(?)して、OpenVPNサーバーにiPhoneから接続する手順をまとめてみましょう。
© yamata::memo 2013 . Powered by Bootstrap , WebLyb