IaaSセキュリティはどこが危ない？ テスト結果を公開：企業が取るべきIaaSセキュリティ【前編】

クラウドサービスの中で、企業が負うセキュリティ維持の責任が最も重いモデルがIaaSだ。RackspaceのIaaSを使った標準的な仮想サーバでセキュリティテストを実施。企業が取るべきセキュリティ対策が明らかになった。

[Joseph Granneman，TechTarget]

　Infrastructure as a Service（IaaS）を使えば、企業はマウスを数回クリックするだけでサーバやストレージ、ネットワークのリソースを作成できる。だがIaaSはクラウドサービスの中では、ユーザー企業が負うセキュリティ維持の責任が最も重いモデルだ。米Amazon Web Services（AWS）や米Rackspace Hostingなど、主要なIaaSプロバイダーは既に低レベルのインフラについてはセキュリティを確保している。だが企業が自社で管理すべきサーバのセキュリティ対策が不適切な場合には、どうなるのだろう？　またこうした仮想インフラでは、サーバはどのようなタイプのリスクにさらされているのだろうか？　こうした疑問の答えを見つけるべく、私はRackspaceを使った標準的な仮想サーバでテストをしてみた。このテストからは、IaaSのセキュリティを確保するために企業が取るべきセキュリティ対策が明らかになった。

会員登録（無料）が必要です

続きを読む

IaaSセキュリティテストの設定

　テストでは、ApacheやSSH、FTPといった一般的なサービスをホストするためにFedora 13でLinuxサーバをプロビジョニングし、標準的な企業サーバで提供されるであろう各種のサービスをシミュレートした。Rackspaceはネットワークセキュリティの構成に関して多数のオプションを提供しているが、いずれのオプションもデフォルトでは有効化されていない。テストでは構成管理のエラーをシミュレートできるよう、Rackspaceのデフォルトのネットワークセキュリティ設定をそのまま利用し、オープンソースのIDS（侵入検知システム）「Snort」をインストールした。ルールセットには、登録して使用するRegisteredルールセットと最新の脅威に対応するルールセットの両方を用いて、結果をモニタリングできるようにした。SMTP（メール）やSamba（Windowsファイル共有）など、ハッカーから注目を集めやすいサービスは意図的に除外した。そうしたサービスまで含めれば、プローブ（脆弱性の探索）の件数があまりに多くなり、テストを対処可能な範囲に収められなくなることが懸念されたからだ。今回のテストの主要な目的は「Rackspaceのセキュリティ設定だけ忘れてしまった有能なITスタッフによるサーバ設定」をシミュレートしてモニタリングすることであるため、Fedoraのセキュリティについては入手可能なパッチを全てインストールした。

クラウドのコンプライアンス、セキュリティに関する記事

• 企業システムのクラウド化を成功させるセキュリティ戦略
• コストとコンプライアンスを踏まえたクラウド戦略の策定
• パブリッククラウドを選択できない企業、クラウドが越えなければならない壁
• パブリッククラウド利用前に押さえておきたい4つのセキュリティリスク
• 調査から見えたクラウドの不安要素とセキュリティ強化への意欲
• 調査結果から見る中堅・中小企業のクラウドセキュリティに対する懸念

SSHブルートフォース攻撃

　最初に検知されたプローブは、経験豊富なLinuxサーバ管理者であれば何度も遭遇したことがあるであろうものだ。自動化されたボットが直ちにSSHポートを見つけ出し、その後、サーバ上のユーザーアカウントに対してブルートフォース攻撃が仕掛けられた。テストでは、このタイプの攻撃が大勢を占め、全体の66％以上の攻撃がSSHプロトコルに向けられた。最も、こうしたブルートフォース攻撃は洗練されておらず、一般的なアカウント名やデフォルトのパスワードを探すだけのものであり、いずれも成功はしなかった。ただし、これらの攻撃のせいで管理が必要なシステムログが多数生成された。デフォルトのアカウント名や簡単に破られるパスワードを使っていれば、サーバは危険にさらされていたかもしれない。ここでの教訓は以下の通りだ。SSHは攻撃を受ける危険性が高く、クラウド環境においてもホスト環境と同様にセキュリティ対策を施すべきである。

VoIP攻撃

　次に多かったのは、はるかに具体的で意外なプローブだった。「SIPVicious」と呼ばれるオープンソースのセキュリティスイートを使った、VoIPシステムを標的としたプローブだ。SIPViciousツールは、本来は管理者が社内のVoIPシステムを検査したり、検知されたセキュリティ上の問題を修正したりするためのツールとして開発されたものだ。だがその他の多くのセキュリティツールと同様、SIPViciousツールもハッカーがインターネット経由でVoIPシステムのセキュリティ上の弱点を突く手段としても使われている。当然、Rackspaceのテストサーバには悪用されるようなVoIPサービスは何もインストールされていなかった。このプローブは単にインターネットをスキャンして脆弱な電話システムがないかを探す、自動化されたボットにすぎなかった。だがこの自動ボットを作成した人物にとっては、このテクニックが成功したこともあるはずだ。「企業のVoIP電話システムを匿名で使用できること」に対して犯罪者が強い動機を抱くのは当然のことだ。ここでの教訓は以下の通りだ。インターネットにさらされるVoIPシステムには強力なセキュリティ対策を講じること。

VoIP攻撃に関する記事

• 多発するVoIP攻撃――VoIP導入には慎重な検討が必要
• VoIPの脆弱性検証ツール──フラッディング、シグナリング操作ツール20選
• 電話も攻撃対象――セキュアなVoIP導入のためのノウハウ

データベース攻撃

　その次に多かったのは、Microsoft SQL ServerやOracle Database、MySQLなどのインストレーションから弱点を突けそうなデータベースシステムを探そうとするプローブだ。中には、こうしたデータベースシステムのネイティブなサービスポートである1433、1521、3306ポートへの接続を試みるシンプルなものもあれば、Rackspaceホストに対して実際にサービス拒否（DoS）攻撃を仕掛けようとするもの、他のホストを標的にバウンス攻撃を仕掛けようとするものなどもあった。驚くべきことに、Rackspaceホストに感染しようとするSQL Slammerワームのインスタンスすら見つかった。SQL Slammerは作成から8年以上もたつマルウェアだ。ここでの教訓は以下の通りだ。このタイプの攻撃を防ぐためにはインターネットへのデータベースの露出を極力制限すること。

データベース攻撃に関する記事

• 脆弱性診断ツールだけでは見つけられないDBセキュリティの脅威
• データベースセキュリティにありがちな5つの弱点
• 共通点・傾向は？　2011年上期の情報漏えい企業に起きたこと

　後編では、検知したプローブの発信国別ランキングを発表する。