マイクロソフトの Securing Windows 2000 Server ソリューション: 第 11 章 ‐ 結論

第 11 章 ‐ 結論

トピック

Contoso の環境で識別された脆弱性

まとめ

これでこのガイドは終わりますが、ここまでで、組織内の Microsoft Windows 2000 サーバーのセキュリティに影響を及ぼすリスクを評価する方法について、より明瞭な理解が得られたことと思います。可能な限りインフラストラクチャ レベルにセキュリティを組み込むため、計画を立てて設計する方法、そして安全な環境を引き続き維持する方法についての理解を得ることができました。このガイドは、どの組織にでも適用できる、規範となるガイダンスを含んでいます。Contoso, Ltd. でのセキュリティ上の必要性の調査は、企業において取り組むべきセキュリティ プロジェクトの例となっています。

このガイドには、様々な企業環境に Windows 2000 Server ソリューションを実装してきた、経験を積んだコンサルタントやシステム エンジニアから集めた資料が含まれており、この複雑なタスクを実行する上での、現時点での一連のベスト プラクティスを提供しています。このガイドの第 2 および第 3 章では、資産、危険、脆弱性の評価、悪用および対抗手段といった、セキュリティ リスク管理に関連する用語を導入しました。また、機密性、完全性、および認証を含む、他の多くの重要なセキュリティ用語についても学びました。第4 章では、Contoso を紹介し、会社環境内の Windows 2000 サーバーのセキュリティを改善するために何を行うべきかに関して、この組織がどんな決定を下したかについて説明しました。そして、Contoso の Windows 2000 コンピュータを評価し、識別された脆弱性に対処するための詳細な計画が立案されました。

第 5 ~ 7 章では、前の章で導入した概念の適用方法を例証しました。Contoso は、今日の企業間の実世界に広く存在する、セキュリティ上のトレードオフを反映したシナリオの例となりました。サーバーをそれらの主要な機能上の役割によってグループ化するために、Microsoft Active Directory ディレクトリ サービスに基づく組織単位 (OU) が使用されました。さらに、多数の設定を一度に適用してサーバーを攻撃や不正アクセスに対して強固にするために、グループ ポリシー オブジェクト (GPO) が作成され、OU にリンクされました。このことを達成するために IIS Lockdown Tool や URLScan のような多くの追加ツールが使用され、Contoso のシステムの安全性を高めました。また、サーバー強化の手順によっては手作業で行なわれました。

組織の環境がどのようなものであれ、セキュリティを真剣に受けとめるべきですが、多くの組織は依然としてセキュリティにあまり重点を置いていません。それらの企業は、セキュリティは企業の機敏さや柔軟性を制限するものであるという、誤った考えを持っています。実際のところ、優れた設計のセキュリティがビジネス上の中核的な要件となり、それについての計画がすべての IT プロジェクトの開始点を占めるようになれば、適切に実装されたセキュリティ戦略はお使いのコンピュータ システムの可用性とパフォーマンスを改善するのに役立ちます。一方、プロジェクトに後からセキュリティを継ぎ足すようなことでは、有用性、安定性、および管理上の柔軟性にマイナスの影響を及ぼしかねません。こうした重要な理由から、あらゆる組織においてセキュリティを最優先事項にする必要があるのです。

Contoso の環境で識別された脆弱性

第 4 章では、Contoso のサーバーの最も重大な脆弱性を識別しました。Contoso は、構成内の主要な問題点を識別するためにネットワーク上で脆弱性走査ツールを使用しました。ツールは多数の項目からなるリストを生成し、その中で脆弱性のリスクは、高、中、低と分類されています。次のセクションでは、このリストの概要とこれらの問題がどのように対処されたかついて簡単に説明します。

バッファ オーバーフロー

Contoso のサーバーの多くは、Microsoft IIS (Internet Information Services) と関連したバッファ オーバーフローの弱点を持っていると判定されました。バッファ オーバーフローは、攻撃者がシステムへのアクセスを獲得するために利用する弱点の一種です。特に、修正プログラムが適用されていなかったため、ツールは Code Red ワームが利用する ida/idq バッファ オーバーフローの存在を識別しました。ワームはスタンド アロンの自己増殖型プログラムで、通常、メモリの消費によってコンピュータのクラッシュを引き起こします。

特定のバッファ オーバーフローの脆弱性は、マイクロソフト からのサービス パックや、こうしたアプリケーションのこの種の脆弱性に機密性を提供するホットフィックスをインストールすることによって除去されました。さらに、攻撃者がその他のバッファ オーバーフローを利用する危険性も大きく低下しました。このことは、URLScan の構成、データ、アプリケーション、および Web コンテンツをオペレーティング システムから離れている記憶ボリュームに再配置すること、および 不必要なサービスやアプリケーションを無効にすることなどを含む、多数の対抗手段によって達成されています。

NetBIOS の列挙

Contoso のすべてのサーバーは、NetBIOS (network basic input/output system) の列挙の脆弱性があると判定されました。NetBIOS は、プロセス間通信 (IPC) のために既定の共有を利用します。既定では、誰もがこの共有に接続できます。ユーザー名もパスワードも要求されません。コンピュータ上の IPC$ 共有への null 接続 (ユーザー名やパスワードを使用しない接続) の作成が、ファイルや制御プロセスを表示する権利を誰かに与えることはありませんが、大量のシステム情報を表示することは可能になっています。悪意あるユーザーは、この情報開示の脆弱性を利用して、後の攻撃で使用するためのデータを集める場合があります。

攻撃者が NetBIOS による匿名アクセスを利用することに関わるリスクは、様々な対抗手段を実装することにより縮小されました。その中には、[匿名接続の追加を制限する] というグループ ポリシー セキュリティ オプションが含まれます。null セッション パイプと null セッション共有、および IPSec フィルタリングへのアクセスも制限されました。

SNMP の列挙

Contoso では、イベントのポートのために Windows 2000 サーバー上の SNMP (Simple Network Management Protocol) サービスを使用しています。これまではずっと既定の「public」という文字列を使用してきましたが、IT チームは、SMTP が、汎用的なハードウェア監視に加えて、会社のコンピュータの他の面についての情報を返すために用いられる場合もあることを知って、驚きました。攻撃者も、この情報開示の脆弱性を利用して、後の攻撃で使用するための情報を集める場合があります。

SNMP のネットワーク データ パケットがクリアテキストとして含まれているため、SNMP は本質的に安全ではないプロトコルですが、企業ネットワークを管理するための非常に有用なプロトコルであることに変わりはありません。SNMP は、現在のほとんどのネットワーク オペレーティング システムと企業管理システムがサポートしている業界標準です。SNMP を通して重要情報が開示されるという危険は、Contoso のすべてのサーバーで SNMP 文字列を変更することにより軽減されました。SNMP ネットワーク トラフィックを保護するためのより効果的な方法は、サーバー間に IPSec 暗号化を実装することです。しかしこの暗号は、使用中のサーバーの処理能力をかなり消費します。Contoso では、サーバーのネットワーク インターフェイス カード (NIC) を、最終的には、マシンの CPU に一切負荷をかけずに IPSec 暗号化を実行できるような NIC で置き換えることを計画しています。これらが展開した後で、Contoso はほとんどのサーバー間通信で IPSec 暗号化を実装します。

DNS の列挙

Contoso の Domain Name System (DNS) サーバーは、ゾーン転送を制限していませんでした。DNS のこの機能に安全対策を施さなかった場合、攻撃者は組織の DNS サーバーから容易にデータを取得できます。Contoso は、Microsoft Windows 2000 の DNS と統合された Active Directory を使用しています。DNS は、ドメインに関する大量の情報を保持しています。その中には、サーバー名や Internet Protocol (IP) アドレス、ネットワーク上で動作しているサービス、および、グローバル カタログや DC など、特定のサービスをホストしているサーバーについての情報が含まれます。

ゾーン転送を既知のコンピュータのリストに対してのみ許可するように DNS サーバーを構成することによって、攻撃者が DNS の列挙を利用することは、これまでよりずっと難しくなりました。正当なリストに記されていないサーバーからのゾーン転送のリクエストは無視されるようになりました。他の代替手段としては、ゾーン転送を許可しないことですが、Contoso のネットワークは大規模で、リモート サイトの副次的な DNS サーバーを含む DNS サーバーの階層構造が存在していたため、この対抗策は却下されました。

弱いパスワード

Contoso が選んだ評価ツールには、ユーザー アカウントに対する基本的な辞書攻撃を行なって、弱いパスワードを識別する追加機能があります。また、空白のパスワードや重複したパスワードの存在を判定するために、セキュリティ アカウント マネージャ (SAM) データベースのパスワード ハッシュの検査も行います。多数の重複パスワードが識別された場合、攻撃者はこれらが組織で新しいアカウントをセット アップする際に利用される可能性のある、既定のパスワードであると判断するかもしれません。

SAM の情報は暗号化されていますが、パスワードの割り出しを試みなくても空白のパスワードや重複したパスワードを識別することは、ハッシュに基づいて容易に行えます。Contoso ではアカウント ロックアウト ポリシーを定義していなかったので、パスワードを見つけるために何回でも試行が行えるようになっていました。スキャン ツールは、多数のパスワードがどんな辞書にも載っている一般的な単語のみから構成されており、ほんの数分で割り出せるようなものであることを発見しました。

Contoso ネットワークでのパスワード割り出しの危険は、厳密なパスワードとアカウント ロックアウト ポリシーを実装することにより低減されました。ユーザー認証のためにスマートカードを実装すれば、より効果的でしょう。しかし、Contoso はまだ公開キー インフラストラクチャ (PKI) を展開しておらず、企業 PKI を設計し、実装するためのリソースも持っていません。将来的には、Contoso は段階的なプロセスでスマートカードを展開するために、Active Directory と統合される強固な PKI を構築することを計画しています。

暗号化されていないサーバー メッセージ ブロックのトラフィック

既定では、Microsoft Windows NT のローカル エリア ネットワーク (LAN) マネージャ (NTLM) のチャレンジ/応答は、ネットワークを介して LanManager (LM) 認証や NTLM ハッシュを送らないようになっています。しかし、この交換トラフィックを監視して、力ずくの方法でオリジナルの LM ハッシュ値を導き出すことができるツールは存在します。ハッシュを得てしまえば、いくつかのユーティリィティを使用して、ハッシュからクリアテキストのパスワードを割り出すことが可能です。

残念ながら、[常にクライアント側の通信にデジタル署名を行う][可能な場合、クライアントの通信にデジタル署名を行う][常にサーバーの通信にデジタル署名を行う]、および [可能な場合、サーバーの通信にデジタル署名を行う] という、4 種類の SMB の暗号化と署名による対抗手段をすべて無効にしなければなりませんでした。

これは、従来型の SMB アプリケーションおよびオペレーティング システムとの互換性を保つためです。Contoso は、18 か月以内にシステム全体を Windows 2000、Microsoft Windows XP、および Microsoft Windows .NET Server 2003 にアップグレードすることにより、この脆弱性による危険を減らす計画です。アップグレードが完了すれば、会社のセキュリティ チームは、4 種類の設定をすべて有効にできます。しかし、チームは、最も負荷の高いサーバーの場合、パフォーマンスの点でかなりの影響が生じる可能性があることも理解しています。

パフォーマンス上の影響が大きすぎる場合、チームは会社のすべてのシステムについて、[常にクライアント側の通信にデジタル署名を行う] および [常にサーバーの通信にデジタル署名を行う] を無効にします。また、それでもパフォーマンス上の問題があるサーバーについては、4 種類の設定をすべて無効にします。代わりのソリューションは、エンドユーザーのシステムを含むすべてのコンピュータ間で、IPSec 暗号化を実装します。

有効でない監査

スキャンしたサーバーの多くは、潜在的な攻撃を識別するのに十分なほど監査の設定が有効にされていませんでした。たとえば、パスワードに対する力ずくの攻撃を識別するのに役立つ [アカウント ログオン イベントの監査] 設定が無効になっていました。

Contoso のサーバーに対し、セキュリティ上の重大なイベントはセキュリティ イベント ログに記録され、重要でないほとんどのものは省略されるよう、適切な監査設定が選択され、実装されました。最も負荷の高いサーバーでも、ログに数週間分のエントリを保持することができるように、イベント ログのサイズはかなり大きくなりました。

チェックされない DoS 攻撃

サービス拒否 (DoS) 攻撃には、ユーザーがリソースにアクセスするのを妨げるすべての攻撃が含まれます。DoS 攻撃には多くのバリエーションがありますが、最も一般的なのは IIS または個々のコンピュータの TCP/IP (Transmission Control Protocol/Internet Protocol) スタックに影響するものです。Contoso のコンピュータでは、TCP/IP ベースの DoS 攻撃の危険を小さくするために、いくらかの変更が加えられました。

TCP/IP ネットワーク スタックも、多くのレジストリ値エントリの調整により強化されました。これらはグループ ポリシーによって直接構成できないので、必要なエントリについては適切な GPO にインポートする前のセキュリティ テンプレートに追加されました。

IIS ディレクトリ スキャン

IIS サーバーの調査により、共通したディレクトリ スキャンの問題が明らかになりました。この脆弱性を利用すると、攻撃者が、ターゲット コンピュータ上のディレクトリ レイアウトやファイルの内容などの情報を表示できるだけでなく、多くの場合、サーバー上でのファイルの書き込みやコマンドの実行までが行えるようになってしまいます。

ディレクトリ スキャンの特定の脆弱性は、マイクロソフト の推奨サービス パックとホットフィックスのインストールにより除去されました。攻撃者が何らかの新しいディレクトリ スキャンの脆弱性を利用する危険は、URLScan を構成し、この種の攻撃で一般的に使用される文字列を含む HTTP (Hypertext Transfer Protocol) リクエストを遮断することにより、かなり減少しました。この危険を低減するために用いた他の対抗手段には、データ、アプリケーション、および Web コンテンツをオペレーティング システムから離れた記憶ボリュームに再配置すること、および 不必要なサービスやアプリケーションを無効にすることなどが含まれます。

ページのトップへ

まとめ

このガイドでは、Windows 2000 Server 環境でセキュリティ上のリスクを評価し、優先順位を定め、それらを軽減するための効果的な方法について説明しました。また、組織のネットワーク インフラストラクチャにセキュリティを組み込むための計画と設計の方法について述べ、Windows 2000 サーバー上で見つかることの多い、特定の脆弱性を修正する方法についての詳細なガイダンスを提供しました。

これらの選択を行った理由については、それぞれの対抗手段を Contoso サーバーに実装するかどうかの決定にしばしば関係する、トレードオフの観点から説明しました。お使いの環境でどの対抗手段を実装するかを、十分な情報に基づいて選択できるようにするため、特定の対抗手段がサーバーの機能、管理製、パフォーマンス、および信頼性にどう影響を及ぼすかについての詳細も提供されました。

最後に、ネットワークのサーバーを保護するためのタスクは 1 回限りのプロジェクトではなく、組織が予算とスケジュールに含めておく必要のある継続的なプロセスであることを理解しておくことは重要です。このガイドで論じたそれぞれの対抗手段を実装することにより、Windows 2000 サーバーを運用している組織の大多数において、セキュリティが改善されるでしょう。ただし、次に重大な脆弱性が発見されたときには、これらのサーバー環境はまた攻撃を受けやすい状態になることがあり得るため、様々なリソースに注目して、環境内にあるオペレーティング システム、アプリケーションおよびデバイスと関連するセキュリティ上の問題についての最新情報に通じておくことが非常に重要です。

このガイドの作成に関わったチームのすべてのメンバーは、このガイドが提供する資料が有用で、情報に富み、理解しやすいものとなっていることを願っています。

ページのトップへ

目次

ページのトップへ