【特集】 不正侵入対策最前線 （前編）
〜不正侵入の現状とトータルセキュリティのススメ〜

丸山 龍一郎
ストーンソフト・ジャパン
ネットワークセキュリティーマネージャー
2001/8/21

セキュリティソリューションの錯覚

　現在導入されているセキュリティソリューションは、ネットワークベースあるいはゲートウェイタイプのものが多数を占める。ファイアウォールやアンチウイルス用ゲートウェイ、ネットワーク型IDSなどである。これらのシステムを導入する場合に、ある錯覚に陥ってしまうケースが多い。

■ファイアウォールがあれば安全か？

　例えば、ファイアウォールによってアクセス制御されているDMZ上のWebサーバを考えてみる。ファイアウォールによって、インターネットからHTTP／HTTPSのみのインバウンドアクセスが許可されている。この環境では、インターネットからDMZ上のWebサーバに対してはHTTP／HTTPS以外のプロトコルはファイアウォールによって遮断されている。ユーザーが望むとおりのセキュアな環境が完成したように思える。果たしてセキュアなのか？ もし、ファイアウォールが通過を許可しているHTTP／HTTPSを使用したアプリケーションにセキュリティホールがあった場合はどうだろうか？ これらのセキュリティホールを突いた攻撃はファイアウォールでは一切検出されることはなく、直接Webサーバ上のアプリケーションに対して実行可能なのである。そのセキュリティホールを突いた攻撃によりWebページを改ざんされたり、管理者権限を取得されたり、さらにはそのシステムを踏み台としてイントラネットにまで侵入されてしまうケースもある。

　このように、ファイアウォールがどのような不正アクセスに対して有効なのかを理解する必要がある。明示的にファイアウォールが許可している通信を利用した攻撃は「防御できない」ということを。

■侵入検知システム（IDS）とファイアウォールの連携

　それに対する1つの解決策が侵入検知システムとの連携である。ファイアウォールが許可したパケットに対して専門的にモニタすることにより、トータルでセキュリティを実現できるのである。しかし、侵入検知システムに関しても、導入すればネットワーク上のすべての不正パケットを検知できるという考えは捨て去るべきである。現在の企業ネットワークは、組織内の多数のネットワークが接続されて1つの企業ネットワークを形成している。そのネットワーク上には、本来業務には必要のないトラフィックが流れている。このような環境にネットワーク型IDSを導入してもほとんどが無駄なパケットを検査することになり、最終的に期待する効果が得られない。また、ログ情報が大量に記録され、実際に不審なパケットが到達しても見逃してしまうケースが多い。

　ネットワーク型IDSには処理上の限界が存在するかもしれないが、導入以前にネットワークを正規化（業務上必要なプロトコルのみ許可するようにする。あるいは、トラフィックパターンのプロファイリング）がされていればより効果的に動作するはずである。侵入検知システムには、ネットワーク型とホスト型があり、それぞれ使用する目的が異なっている。詳細は、次回に説明する。

■ポイントは「ネットワークレベル」と「ホストレベル」

　先にトータルセキュリティという言葉を使用したが、セキュリティシステムを構築していくうえで考慮すべきポイントは、ネットワークレベル・セキュリティとホストレベル・セキュリティの両面からアプローチしていかなければならないということである。このどちらが欠如してもネットワークセキュリティは達成できないのである。

　先に紹介したゲートウェイタイプのソリューションを使用すると、比較的容易にネットワークレベルのセキュリティを実現することが可能である。なぜなら、すべてのパケットがそのゲートウェイを通過するように制御されるからである。設定されたルールは、ゲートウェイを通過するすべてのネットワークに対して有効とすることができる。次に、各Webサーバが動作するシステムに対しては、オペレーティングシステムや使用するWebプログラムのセキュリティホール、不要なネットワークサービスの除去を実施する必要がある。当然、パッチなどがリリースされたら即座に対応することは重要である。この作業が、いわゆるホストレベルのセキュリティの構築である。

　これらの作業は大変パワーを要するものではあるが、最終的に攻撃されないネットワークを構築する、さらに仮に攻撃されても被害を最小限に抑えるためには必要不可欠な作業である。どちらかというと、ホストレベルでセキュリティがある程度実現されている環境であれば不正アクセスは防ぐことができるが、実際は個々のシステムでの実作業のためのパワーが必要であるため、ネットワークレベルのセキュリティに頼ってしまっているというのが正直なところである。

　セキュリティソリューションを導入するうえで重要なのは、各ソリューションの特性を把握することである。各セキュリティソリューションで、どのような事象に対して、どの程度までの制御が可能なのかを理解することは、裏を返せば現在導入しているソリューションでカバーできないリスクを抽出することを可能とする。リスクが明確になれば、そのポイントを狙うような攻撃手法も制限されるため、実際に攻撃された場合の検出、対応も迅速に行えるはずである。

セキュアなWebシステムの構築例

　ここまでに述べてきたトータルセキュリティを考慮した構築例を以下に記述する。

図1　セキュリティはトータルで考える

■ネットワークレベルのセキュリティの実現

• 企業ネットワークへの入り口にあたるISPルータにおいてIP-Spoofingパケットなどの不正パケットをフィルタリング
  
• インターネットと企業ネットワーク間のアクセスコントロールを実現するファイアウォールの設置
  
• 必要であれば侵入検知システムを併用

■ホストレベルのセキュリティの実現

• Webサービスに利用するプラットフォームを選択（統計によると最近改ざんされたWebシステムのプラットフォームは、IISを使用しているケースがほとんどである）
  
• オペレーティングシステムをインストールする際に、Webサービスの実現に必要でないモジュール（コンパイラも含む）、ネットワークアプリケーションを削除
  
• Webソフトウェアの導入（必要なパッチを適用）
  
• Webソフトウェアの設定（特にCGIが起動されるユーザーアカウントには注意）
  
• コンテンツの設定、作成（CGIなどを作成する場合、プログラマー自身もWebシステムの仕組みを理解し、セキュリティを意識したコードを作成するように教育する）

■セキュリティ検査

　完成したWebシステム環境の脆弱点を検査ツール（ISS社のInternet Scannerなど）を利用して検査する。その場合、少なくとも3つのロケーションから試験することをお勧めする。

図2　セキュリティ検査の実施

• インターネットからの検査
  
  　この検査によって、サービスを提供するWebシステムがインターネットからどのように見えるのかを確認することになる。このときに注意しなければいけないのは、導入されているファイアウォールのタイプである。
  
  　 パケットフィルタリングタイプのファイアウォールであれば、許可しているサービス（この場合は、HTTP／HTTPS）に対してはその要求は直接Webシステムに到達するため、検査パケットは構築したWebシステムをインターネットからアクセスした場合の脆弱点を検査できることになる。それ以外のパケットは当然ファイアウォールでフィルタリングされる。
  
  　 もし、導入されているファイアウォールがアプリケーションゲートウェイタイプのものである場合、要求はすべてファイアウォール上のプロキシによって中継されてWebシステムに到達する。この場合、インターネットからの検査は、直接はファイアウォール上のプロキシ（この場合は、HTTPプロキシ）を検査しているにすぎない。この相違を十分に理解しておく必要がある。

• Webサーバと同一ネットワーク上からの検査
  
  　この検査の目的は、Weｂシステム自体が潜在的に持っている脆弱点を見つけることである。つまり、この結果が現在のWebシステムのホストセキュリティのレベルを示すことになる。従って、ここで結果として示された脆弱点に対しては、優先順位を付けて対応する必要がある。その対応が完了すれば、その時点（あくまでも検査した時点である）での脆弱点を取り除いたセキュアな環境を構築できたということである。
  
  
• イントラネットからの検査
  
  　この検査の目的は、Webシステムがイントラネットからどのように見えるかを確認することである。ファイアウォールのポリシーを構築するうえでイントラネットからDMZ上のサーバに対するアクセスは、比較的自由に行えるように設定する場合が多い。Webページの更新作業やそのほかのメンテナンス作業が主な用途だからである。しかし、最近の不正アクセスの多くは内部犯行であるといわれているため、イントラネットからのアクセスコントロールも外部からのアクセスと同じレベルで考慮する必要がある。

　これらの検査を実施することで、構築したWebシステムへのアクセス形態がある程度固定化されるわけである。その後は、限られたアクセス形態におけるリスクを検討し、いざ発生した場合のアクションを明確にしておけば、より絞り込まれた範囲での運用が可能となるのである。ここで実施した脆弱点検査の結果は、あくまでも実施時点での結果である。利用しているオペレーティングシステムやアプリケーションに関するバグ・フィックス情報を日々チェックし、検査も定期的に実施することをお勧めする。

■情報収集とログ監視

　ネットワーク管理者の本来の仕事はここから始まるといっても過言ではないと思う。環境構築が完了した後は、導入しているソリューションに関する情報収集を行い、常にソフトウェアが最新の状態になるように努める。また、生成されるログ情報を毎日監視することは当然重要である。

　ここまで説明してきた内容は典型的な構築時の作業である。それでは、Webシステムのセキュリティに関して別の視点から考えてみよう。

　Webシステムを稼働させるシステムのディスクパーティションについてである。なぜコンテンツを格納しているパーティションをRead／Write可能なモードでマウントする必要があるのか？ Webのようなアプリケーションはオペレーティングシステム上で動作している。オペレーティングシステムのレベルでRead ONLYと設定されている領域は、基本的にアプリケーションからの書き込みは不可能である。従って、仮にWebサーバのプログラムにバグがあり、それを利用されてWebページが改ざんされるような場合でも、オペレーティングシステム自身がファイルの更新を許可しない。このような考え方はファイアウォール構築時にも適応できる。

　ファイアウォールの一般的な利用形態では、ディスクに書き込む必要がある情報はアクセスログのみである。ログを記録する領域のみ別のディスクパーティションを用意することにより、ほかのシステム領域はRead ONLYでマウントすることが可能となる。このように、セキュリティを考えていくうえで1つのソリューションやアプローチを利用するのではなく、異なった階層の技術を組み合わせていくことによってより堅牢な環境を実現できるのである。極端な例を挙げると、コンテンツの更新頻度がそれほど高くないのであれば、Webコンテンツ自体をCD-ROMに焼いて公開するといったユニークな方法も考えられるのである（メンテナンスは多少面倒にはなるが）。

　今回は、最近多数報告されているWeb改ざんを例としてセキュアなネットワーク構築を実現する場合の留意点について、筆者の経験を基に説明してきた。次回は今後のネットワークセキュリティに欠くことができないソリューションである侵入検知システムについて技術的な部分を交えて説明したいと思う。

「監視カメラとしてのIDS」へ

Index 特集：不正侵入対策最前線（前編）

Page 1 敵もさるもの、やはりクラッカーの方が賢いのか 管理者苦難の時代 キーワードは「トータル」 Page 2 セキュリティソリューションの錯覚 セキュアなWebシステムの構築例 特集：不正侵入対策最前線（後編） 　 Page 3 監視カメラとしてのIDS IDSの基本的な動作の仕組み ネットワーク型IDSの特徴 　 Page 4 ホスト型IDSの特徴 クラッカーの攻撃手法を取得するおとりサーバ（ハニーポット） トータルセキュリティの理想的な構成 セキュリティシステム導入時の留意点 注目されるIDSの今後

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）