IPsecポリシーをスクリプトで作成
 IPsecポリシーを作成する際には,コマンド・ライン・ツールを使うこともできる。これはスクリプトを記述する場合に便利である。Windows 2000では,米MicrosoftのWebサイトからダウンロードできるipsecpol.exeを使用する。Windows XPではWindows XP Service Pack 2 Support Toolsなどに含まれているipseccmd.exeを,Windows Server 2003ではOSに標準で付属するNetsh Ipsecコマンドを使う。

 例えば,Windows XPで先のSlammerフィルタと同様のIPsecポリシーを作成して割り当てるには,以下のコマンドを使用する。

ipseccmd -w REG 
-p "Block UDP 1434 Filter"
-r "Block Inbound UDP 1434 Rule"
-f *=0:1434:UDP -n BLOCK -x

△ 図をクリックすると拡大されます
表2●ipseccmdコマンドの主要なオプション
 大文字と小文字は記事の通りに入力してほしい。IpsecpolとIpseccmdは大文字と小文字を区別するからだ。また,誌面の都合でコマンドが複数行にわたっているが,実際には改行なしで入力する必要がある。コマンドのオプションについては表2を参照していただきたい。

 このコマンドは,「Block UDP 1434 Filter」という静的なポリシーを作成して割り当てる。このポリシーには,先にGUIで作成したときと同様のフィルタ一覧を持つ「Block Inbound UDP 1434 Rule」という1つのルールが含まれている。静的ポリシーはレジストリに格納されるため,再起動後も有効である。ただし,コマンドで静的ポリシーを作成した場合,ポリシーはOSを再起動するか,またはIPsecポリシー・エージェントを再スタートするまで適用されない。直ちにポリシーを割り当てたい場合は,スクリプトにポリシー・エージェント・サービスをいったん停止して再スタートするよう記述する必要がある。ちなみにこのポリシーをGUIで構築した場合は即座に適用される。

△ 図をクリックすると拡大されます
表3●既にSlammerに感染してしまったコンピュータが外部に被害を及ぼさないようにするためのポリシー・ルールの内容
 コンピュータが実際にSlammerに感染してしまったら,別のIPsecルールを使ってUDPポート1434あてのアウトバウンド通信をブロックすることで,ほかのコンピュータへの感染を防止できる。これには表3のようなルールを作成する。

 表3では,先に紹介したインバウンド・ルールとフィルタ一覧の設定が異なる点に注意してほしい。先のフィルタは,「すべてのアドレス:すべてのポートから,設定するマシンのアドレス:ポート1434/udp」へのトラフィックを監視していた。対して,ここで設定するアウトバウンド・ルールでは,「設定するマシンのアドレス:すべてのポートから,すべてのアドレス:ポート1434/udp」を監視する。このアウトバウンド・ルールが,送信先のコンピュータにかかわらず,UDPポート1434へのトラフィックをブロックする。このルールを先のルールと同じ「Block UDP 1434 Filter」ポリシーに追加するスクリプトを記述するには,以下のコマンドを実行すればよい。

ipseccmd -w REG 
-p "Block UDP 1434 Filter"
-r "Block Outbound UDP 1434 Rule"
-f 0=*:1434:UDP -n BLOCK

 先に紹介したコマンドでは,新しいポリシーを作成して割り当てるために「-x」オプションを指定していた。ここで紹介したコマンドは既存のポリシーに別のルールを追加するものなので,「-x」スイッチは除く必要がある。また,このコマンドのフィルタ一覧部分に指定した「*」と「0」は,最初のコマンドと逆になっている。これはフィルタの方向が逆転しているからである。

 コマンド・ライン・ユーティリティを利用すれば,「動的ポリシー」を割り当てることもできる。動的ポリシーは,システムが実行されている間だけ有効なポリシーで,コンピュータを再起動したり,ポリシー・エージェント・サービスを再スタートしたりすると消えてしまう。動的ポリシーは,長期間必要でないポリシーを一時的に割り当て,再起動したときにクリアしたい場合に便利である。以下の2つのコマンドで,先ほどの静的ポリシーと同じように振る舞う動的ポリシーを作成できる。

ipseccmd -f[*=0:1434:UDP]
ipseccmd -f[0=*:1434:UDP]

 動的ポリシーの場合は,フィルタの指定を[ ]で囲むと,そのトラフィックをブロックするという意味になる。トラフィックを許可する場合はフィルタの指定を( )で囲めばよい。

 ここまでで,IPsecを使って既知のぜい弱性などを持つ特定のポートへの双方向のトラフィックをブロックする方法を紹介した。IPsecポリシーでは,すべてのトラフィックを両方向について原則ブロックし,特定のポートへのトラフィックの往来だけを許可するルールを作成することで,さらに制限を強化することもできる。どのようなトラフィックを許可するかをよく検討し,念入りに計画を立て,実稼働システムで運用する前に徹底的にテストを実施するようにしよう。

サーバー保護にIPsecを使う
 サーバーを保護するためには“block-all-except-for”ポリシーを使うとよい。例えば,Webサーバーのインターネット側の接続では,Web関連以外のインバウンド・トラフィックを受け付ける必要はない。IPsecポリシーを使えば,サーバーの目的に合致しないトラフィックをすべて破棄するという,基本的なパケット・フィルタを作成できる。Webサーバーで言えば,TCPポート80あてのトラフィック以外はすべて破棄することになる。HTTPS(HTTPセキュア)を使用するページがある場合は,TCPポート443も通過させる必要がある。

△ 図をクリックすると拡大されます
表4●不要なトラフィックをすべて破棄するためのポリシー・ルール(その1)
△ 図をクリックすると拡大されます
表5●不要なトラフィックをすべて破棄するためのポリシー・ルール(その2)
 サーバー保護ポリシーは,パッチをテストしたり配置したりするときの時間稼ぎにも利用できる。例えば誰かがOSにぜい弱性を発見したら,そのぜい弱なサービスに対するアクセスを拒否するポリシーを一時的に割り当て,システムのメンテナンス・スケジュールに合わせてそのパッチのテストと配置が行えるように時間を稼ぐのである。そうすれば,サービス・レベルの契約が締結されている場合でも契約を破らなくて済む。

 Webサーバー用のIPsecポリシーは,「原則としてすべてのトラフィックをブロックするルール」(表4)と,「例外としてポート80,ポート443へのトラフィックを許可するルール」(表5)——の2つで構成する。表5のルールでは,ポート80,ポート443へのトラフィックを指定するために,フィルタ一覧に2つのフィルタ(表ではフィルタ1,フィルタ2と表記)を定義している点に注意してほしい。

 これらポリシーを設定するには以下のコマンドを使う。

ipseccmd -w REG
-p "Web traffic packet filter"
-r "Block everything"
-f *+0 -n BLOCK -x
ipseccmd -w REG
-p "Web traffic packet filter"
-r "Permit web traffic"
-f *+0:80:TCP -f *+0:443:TCP
-n PASS

 この例では,フィルタの指定で発信元とあて先を区切る「=」の代わりに「+」を使っている。「+」は,ポリシー・エージェントにミラー・ルールの作成を指示するものである。ミラー・ルールは,TCPポート80やTCPポート443で受信したリクエストに対する応答をWebサーバーから発信するために必要になる。ミラーがない場合は,これらアウトバウンドのトラフィックを許可するルールを別に作成しなければならない。ちなみにGUIでルールを作成した場合は,自動的にミラーも設定される。

△ 図をクリックすると拡大されます
図5●作成した「Permit web traffic」フィルタ一覧を[IPフィルタ一覧]ダイアログで確認したところ
△ 図をクリックすると拡大されます
図6●作成したポリシー「Web traffic packet filter」の規則をプロパティ・ダイアログで確認したところ
 ここで作成したポリシーをGUI画面で確認してみたのが図5図6である。図5は,「Permit web traffic」ルールに結び付けられたフィルタ一覧を表示しており,ポート80用,ポート443用の2つのフィルタが定義されていることが分かる。図6は「Web traffic packet filter」ポリシーが2つのルールを含むことを表している。1つはすべてのトラフィックをブロックするルール,もう1つはWebトラフィックを許可するルールである。

 同じことをホスト・ベースのファイアウオールでもできるだろうか。もちろんできるし,Windows Server 2003であればその方がよい。しかし,Windows 2000 Serverの場合,IPsecによるパケット・フィルタは攻撃の可能性を減らすに当たって大変効果的である。社内の様々なサーバーについて役割を洗い出し,それぞれに適したIPsecポリシーの策定を始めてはいかがだろうか。グループ・ポリシーを利用すれば,サーバーの役割に応じてOU(組織単位)を定め,それに基づいてIPsecポリシーを割り当てられる。サーバーへのトラフィックを制限する手法を実践するだけでも,セキュリティをある程度強化できるはずだ。

IPsecを使ってドメインを分離
 ネットワーク・リソースを使いたいユーザーは,DC(ドメイン・コントローラ)に対して認証する必要があるので,ユーザーが誰であるかはすぐに分かる。ではユーザーのコンピュータについてはどうだろうか。もちろんコンピュータの一部はドメインに所属している。ただし,Windowsはコンピュータがドメインの一員であることを条件としていない。ユーザーが有効な身元証明情報を有している限りは,ネットワーク上のどのコンピュータからでもネットワーク・リソースにアクセスできる。Windows XPの認証情報管理機能によって,ドメインに所属していないクライアントによるネットワーク・リソースへのアクセスはますます簡単になっている。

 ドメイン分離は,“無法状態”のマシンによるドメイン・リソースへのアクセスを禁止する。つまり,ドメインに所属し,認証を受けたコンピュータだけがほかの認証されているコンピュータと通信できるようにするのである。ドメインに所属しているコンピュータにはグループ・ポリシー,セキュリティ・テンプレート,ソフトウエアの実行制限,IPsecポリシー,SMS(Systems Management Server)など,集中的に制御・管理できるセキュリティ関連のテクノロジが適用されているため,ある程度は信用できる。

 このように制御されたコンピュータは,許可されたことだけを実行する。従って,その存在も構成も不明の管理されていない無法状態のマシンと比べて,はるかに危険度が低い。できるだけ早くドメインを分離することについて検討するようお勧めする。

△ 図をクリックすると拡大されます
表6●ドメインに参加していないコンピュータとの通信を拒否するためのポリシーの内容
 ドメイン全体にわたってドメインの分離を実施するのは意外と簡単である。まずは表6に示すIPsecポリシーを既定のドメインGPO(グループ・ポリシー・オブジェクト)に追加する。

 ここで暗号化なしのESP(カプセル化セキュリティ・ペイロード)を使うのは,パケット単位の認証が目的であって,暗号化ではないからだ。プライバシは要件になっておらず,SHA-1が提供する認証と整合性だけが必要なのである。暗号化なしのESPの代わりにIPsec Authentication Header(AH)を使ってもよいが,NAT(ネットワーク・アドレス変換)を介して通信する機器の場合にはポリシーが機能しなくなってしまう。

 また,これとは別に,DCを免除するポリシーも作成する必要がある。クライアントがDCと通信して認証し,ほかのあらゆる通信に使えるKerberosチケットを入手する必要があるためである。これには,DCのアドレス,もしくはアドレスの範囲を指定したフィルタ一覧を作成し,フィルタ操作として[許可]を設定する。規則は表1と同じでかまわない。このほか,ネットワーク・プリンタなどIPsecに参加できないマシンのためにも同様のポリシーを設定する必要がある。

 これらのポリシーをテストして配置すると,以後ドメインに所属しているマシンとの通信にはIPsecが必要となり,ドメインに所属していないマシンはドメインに所属するマシンと通信できなくなる。クライアントはドメインに参加しない限りIPsecポリシーを取得できない。またドメイン外のクライアントが独自にポリシーを適用して通信することも不可能だ。IPsecポリシーはKerberos認証を必要とし,これはドメインに参加していないと利用できないからである。ドメインのメンバーはすべてポリシーを受け取り,ほかのドメイン・メンバーすべてと通信できる。

 現在,ネットワークの境界は内側に向かって動いている。実際,かつてのようにネットワークの内側と外側を厳密に区別するのは難しい。現在のネットワークは卵のようにネバネバした中身を殻が守っているのではなく,むしろタマネギのように複数の層で構成されている。単に境界のセキュリティを強化すれば済むのではなく,各層,各コンピュータのセキュリティを保護しなければいけない時代になっているのだ。IPsecは,ネットワーク上のすべてのコンピュータを強化するのにうってつけのテクノロジである。