Infrastructure as a Service（IaaS）を使えば、企業はマウスを数回クリックするだけでサーバやストレージ、ネットワークのリソースを作成できる。だがIaaSはクラウドサービスの中では、ユーザー企業が負うセキュリティ維持の責任が最も重いモデルだ。米Amazon Web Services（AWS）や米Rackspace Hostingなど、主要なIaaSプロバイダーは既に低レベルのインフラについてはセキュリティを確保している。だが企業が自社で管理すべきサーバのセキュリティ対策が不適切な場合には、どうなるのだろう？ またこうした仮想インフラでは、サーバはどのようなタイプのリスクにさらされているのだろうか？ こうした疑問の答えを見つけるべく、私はRackspaceを使った標準的な仮想サーバでテストをしてみた。このテストからは、IaaSのセキュリティを確保するために企業が取るべきセキュリティ対策が明らかになった。
テストでは、ApacheやSSH、FTPといった一般的なサービスをホストするためにFedora 13でLinuxサーバをプロビジョニングし、標準的な企業サーバで提供されるであろう各種のサービスをシミュレートした。Rackspaceはネットワークセキュリティの構成に関して多数のオプションを提供しているが、いずれのオプションもデフォルトでは有効化されていない。テストでは構成管理のエラーをシミュレートできるよう、Rackspaceのデフォルトのネットワークセキュリティ設定をそのまま利用し、オープンソースのIDS（侵入検知システム）「Snort」をインストールした。ルールセットには、登録して使用するRegisteredルールセットと最新の脅威に対応するルールセットの両方を用いて、結果をモニタリングできるようにした。SMTP（メール）やSamba（Windowsファイル共有）など、ハッカーから注目を集めやすいサービスは意図的に除外した。そうしたサービスまで含めれば、プローブ（脆弱性の探索）の件数があまりに多くなり、テストを対処可能な範囲に収められなくなることが懸念されたからだ。今回のテストの主要な目的は「Rackspaceのセキュリティ設定だけ忘れてしまった有能なITスタッフによるサーバ設定」をシミュレートしてモニタリングすることであるため、Fedoraのセキュリティについては入手可能なパッチを全てインストールした。
最初に検知されたプローブは、経験豊富なLinuxサーバ管理者であれば何度も遭遇したことがあるであろうものだ。自動化されたボットが直ちにSSHポートを見つけ出し、その後、サーバ上のユーザーアカウントに対してブルートフォース攻撃が仕掛けられた。テストでは、このタイプの攻撃が大勢を占め、全体の66％以上の攻撃がSSHプロトコルに向けられた。最も、こうしたブルートフォース攻撃は洗練されておらず、一般的なアカウント名やデフォルトのパスワードを探すだけのものであり、いずれも成功はしなかった。ただし、これらの攻撃のせいで管理が必要なシステムログが多数生成された。デフォルトのアカウント名や簡単に破られるパスワードを使っていれば、サーバは危険にさらされていたかもしれない。ここでの教訓は以下の通りだ。SSHは攻撃を受ける危険性が高く、クラウド環境においてもホスト環境と同様にセキュリティ対策を施すべきである。
次に多かったのは、はるかに具体的で意外なプローブだった。「SIPVicious」と呼ばれるオープンソースのセキュリティスイートを使った、VoIPシステムを標的としたプローブだ。SIPViciousツールは、本来は管理者が社内のVoIPシステムを検査したり、検知されたセキュリティ上の問題を修正したりするためのツールとして開発されたものだ。だがその他の多くのセキュリティツールと同様、SIPViciousツールもハッカーがインターネット経由でVoIPシステムのセキュリティ上の弱点を突く手段としても使われている。当然、Rackspaceのテストサーバには悪用されるようなVoIPサービスは何もインストールされていなかった。このプローブは単にインターネットをスキャンして脆弱な電話システムがないかを探す、自動化されたボットにすぎなかった。だがこの自動ボットを作成した人物にとっては、このテクニックが成功したこともあるはずだ。「企業のVoIP電話システムを匿名で使用できること」に対して犯罪者が強い動機を抱くのは当然のことだ。ここでの教訓は以下の通りだ。インターネットにさらされるVoIPシステムには強力なセキュリティ対策を講じること。
その次に多かったのは、Microsoft SQL ServerやOracle Database、MySQLなどのインストレーションから弱点を突けそうなデータベースシステムを探そうとするプローブだ。中には、こうしたデータベースシステムのネイティブなサービスポートである1433、1521、3306ポートへの接続を試みるシンプルなものもあれば、Rackspaceホストに対して実際にサービス拒否（DoS）攻撃を仕掛けようとするもの、他のホストを標的にバウンス攻撃を仕掛けようとするものなどもあった。驚くべきことに、Rackspaceホストに感染しようとするSQL Slammerワームのインスタンスすら見つかった。SQL Slammerは作成から8年以上もたつマルウェアだ。ここでの教訓は以下の通りだ。このタイプの攻撃を防ぐためにはインターネットへのデータベースの露出を極力制限すること。
後編では、検知したプローブの発信国別ランキングを発表する。
AI活用で日本が米国に追い付く――PwC調査
PwC Japanグループが日本で実施した調査の結果から、日本企業によるAI活用が大きく進み、...
SaaS企業の成功メソッド「PLG」を実践するための組織作りとは？
成長を続けるSaaS企業には組織としての共通点がある。それは具体的にどのようなものだろ...
メディア総接触時間、「携帯電話／スマートフォン」が「テレビ」を上回り首位に
博報堂DYメディアパートナーズによる、生活者のメディア接触の現状を捉える年次調査の結...
ITmediaはアイティメディア株式会社の登録商標です。
