特集
|
|
Windows Server 2003 Service Pack 1(以下Windows Server 2003 SP1、または文脈から明らかな場合は単に「SP1」と表記)には、以前のWindows Server 2003と比べると、より高機能なファイアウォール機能が用意されている。これを利用することにより、システム起動時にも安全を維持しながら(以前のものでは、ブート時にはわずかな時間ではあるが、ファイアウォールが無効になる期間があった)、より高機能で、セキュアなネットワーク接続環境を実現することができる。
Windowsファイアウォール | ||||||||||||
Windows XP SP2で導入されたものと同じファイアウォール機能がWindows Server 2003 SP1にも導入された。 | ||||||||||||
|
Windows Server 2003の初期版(SP1未適用版)には2種類のファイアウォール機能が用意されていた。ネットワーク・インターフェイスごとに設定する「インターネット接続ファイアウォール(ICF)」と、ルーティングとリモート・アクセス(RRAS:Routing and Remote Access Service)に含まれる「NAT/ベーシック ファイアウォール」である。Windows Server 2003 SP1で新しく用意された「Windowsファイアウォール」は、このうちインターネット接続ファイアウォールの後継となる機能であり、Windows XP SP2に実装されたWindowsファイアウォールと同じものである。
Windows Server 2003 SP1のWindowsファイアウォールの機能は、Windows XP SP2のものとほぼ同様であり、その機能や設定、管理方法もほぼ同じ方法が踏襲されている。Windowsファイアウォールの基本的な使用法としては、デフォルトですべてのポートを閉じておき、必要に応じて通信に使われるポートをオープンする、というふうにする。ポートをオープンする条件としては、あらかじめ管理者自身が静的にオープンしておく方法と、プログラムやサービスの実行/終了に応じてオープン/クローズするという、動的な制御方法の2とおりがある。
|
前述したとおり、Windowsファイアウォールそのものの機能は、XP SP2のものと同じであり、サーバだからといって特に強化・変更されている機能はないので、基本的な機能については関連記事を参考にしていただきたい。本記事では、Windows Server 2003 SP1のWindowsファイアウォールの固有の機能について解説する。
なお、Windows Server 2003 SP1では、インストール直後のデフォルト状態ではWindowsファイアウォールは有効になっていない。クライアントOSであるWindows XP SP2では、インストール直後からファイアウォールが有効になっていたが、サーバOSでは稼働しているサービスも多く、無条件に有効にするとサーバ・サービスが利用できなくなるというトラブルが発生する可能性が非常に高いからだ。SP1のインストール後、サーバの管理者がサーバ状態に応じて、適切に設定を行う必要がある。
サーバOSで利用するWindowsファイアウォール
Windows Server 2003 SP1のWindowsファイアウォールも、クライアント向けとして提供されているWindows XP SP2のものと機能的には差はない。だが、クライアントOS向けに提供されているものとは、その設定運用方法が異なる。クライアントの場合は、コンピュータの内部から外部へ向けての通信(アウトバウンドの通信)がメインであるのに対し、サーバでは、外部からの着信を受けてサービスを提供する通信(インバウンドの通信)がメインとなる。そのためファイアウォールでフィルタリング・ルールを設定する場合、サーバOSでは、クライアントOSよりも多くのポートを空けて待ち受けしなければならないし、その分だけ設定や運用などにも手間がかかる。
例えば、以下はActive Directory(の複製サービス)関連で使用される通信ポートの例である。
サービス | ポート/プロトコル | 用途 |
RPCポート・マッパ | 135/TCP、135/UDP | RPCのポート・マッパ(MS-RPC) |
NetBIOS名前サービス | 137/TCP、137/UDP | NetBIOSの名前解決サービス |
NetBIOSデータグラム・サービス | 138/UDP | NetBIOSのデータグラム通信用 |
NetBIOSセッション・サービス | 139/TCP | NetBIOSのセッション指向通信用 |
RPC動的ポート | 1024〜65535/TCP | RPC通信用ポート。動的に変化するが、レジストリ設定などで限定することも可 |
SMBサービス | 445/TCP, 445/UDP | ダイレクト・ホストSMBサービス(Microsoft-DS) |
LDAP | 389/TCP | 軽量ディレクトリ・アクセス・プロトコル |
LDAP over SSL | 636/TCP | SSL上のLDAPプロトコル |
グローバル・カタログLDAP | 3268/TCP | グローバル・カタログ用LDAP |
グローバル・カタログLDAP over SSL | 3269/TCP | SSL上のグローバル・カタログ用LDAP |
ケルベロス | 88/TCP, 88/UDP | ケルベロス認証用 |
DNS | 53/TCP、53/UDP | Domain Name System用 |
WINS | 1512/TCP、1512/UDP | WINS解決用 |
WINS複製 | 42/TCP、42/UDP | WINS複製用 |
Active Directory(の複製サービス)関連で使用されるポートの例 | ||
Active Directory関連のほか、DNSやWINS、ファイル共有などのプロトコルも含まれているので、これらを間違いなく許可しなければならない。詳細は「Active Directory Replication over Firewalls[英文](マイクロソフト)」などを参照。 |
Active Directory関連だけでもこれだけのポートの設定を行わなければならない。サーバ上で動作するサービスや製品には多くの種類があり、そのそれぞれについて、関連するサービスやポートを間違いなく設定・確認するのは非常に困難な作業である。特にWindowsファイアウォールでは、単に静的にポートを空けておくだけでは安全性に問題があるため、可能ならばサービス(プログラム)が起動している間だけポートがオープンするように、動的なポート制御を行うべきである。特に、動的なポートをオープンして使用するサービスでは、この制御方法が必須である。
このためには、サービスとそれを実現しているプログラム・ファイルの関係を知る必要があるが(指定したプログラム・ファイルが実行されている間だけポートをオープンにするため)、サーバOSともなると、どのサービスとプログラム、ポートが結びついているのかが非常に分かりにくい。このような情報は(公式には)公開されていないからだ(OS内部の構成にも依存するので、明確にドキュメント化できないからだろう)。例えば上記のActive Directoryの例では、静的なルールと動的なルールの両方を組み合わせなければ実現することができない。
この例は、単一のサーバでの設定例であったが、実際には複数台のサーバに対して設定作業を行う必要もあるだろう。また障害発生時のサーバ切り替え作業なども考慮すると、なるべく少ない手間で、確実に、複数のサーバに対して適切に設定を行う必要がある。
以上のような事情があるため、クライアント向けとは違い、サーバでは、設定や運用の容易さも考慮したファイアウォールの管理手法が必要となるだろう。そこでWindows Server 2003 SP1のWindowsファイアウォールでは、従来のXP SP2におけるWindowsファイアウォールの管理方法に加えて、新しく「セキュリティ構成ウィザード」を使った方法も用意されている。これを使えば簡単にファイアウォールの設定を済ませることができるだけでなく、設定情報をほかのサーバへも容易に適用できるようになっている。管理者は、動作しているサービスやサーバの用途を指定するだけで、ポートの番号やプログラム・ファイルの情報などを知らなくても、その構成に合った適切な設定を行うことができる。
Windowsファイアウォールの運用ガイド
|
Windows Server 2003 SP1のWindowsファイアウォールを利用する場合は、以下のような点に注意して利用する。完全に独立した(アプライアンス製品などの)ファイアウォール製品と違い、その機能には限界があるため(インバウンド方向にしかフィルタがかけられないとか、フィルタの条件にはポート番号やアドレス程度しか指定できないなど)、必要ならば外部に専用のファイアウォール製品を利用するとか、Windowsファイアウォールではなく専用ファイアウォール・ソフトウェア(Microsoft ISA Server 2004など)の導入を検討するべきである。
■手動によるポート設定は避ける
すでに述べたように、サーバOSではリッスンしなければならないポートも多いし、サービスと関連付けられているプログラム・ファイルを知るのも容易ではない。そのため、可能な限り手動によるファイアウォール・ルールの設定は避け、前述した「セキュリティ構成ウィザード」など、ほかの方法を採用するべきである。
■サーバごと、ポートごとの個別設定はなるべく避ける
サーバは稼働しているサービスが多く、ウイルスやワームなどに狙われる可能性も高い。そのため、サーバごとに異なるファイアウォール設定を施すと、どのコンピュータにどのような設定を行ったかを把握するのが困難になるし、設定漏れの発見や設定変更などの作業も難しくなる。可能な限り、グループ・ポリシーやセキュリティ構成ウィザードなどを使った手法が望ましい。
■グループ・ポリシーで一括制御する
グループ・ポリシーを利用すると、中央からまとめてサーバの設定を変更することができるし、設定の変更も簡単になる。またグループ・ポリシーで設定を行うと、ローカルに設定を上書きすることができなくなるので、安全性が増す。Active Directoryを利用している場合は、このグループ・ポリシーによる設定を利用するのが望ましい。
■セキュリティ構成ウィザードで設定する
Windows Server 2003 SP1では、セキュリティ構成ウィザードでWindowsファイアウォールの設定を行うことができるようになっている。サーバの利用目的や稼働しているサービスを指定すれば、自動的に必要なファイアウォール・ルールが設定されるので、非常に便利である。また設定情報はXMLファイルとしてインポート/エクスポートできるので、サーバの再インストール後の再設定や、ほかのサーバへの適用なども容易に行える。可能な限り、このウィザードを利用するとよい。
セキュリティ構成ウィザード | |||
システムの状態を調査し、最適なセキュリティ設定を自動的に行わせるためのツール。Windowsファイアウォールの例外ルールの生成も行う。 | |||
|
■RRASやほかのファイアウォール製品とは共存できない
Windowsファイアウォールは、従来のインターネット接続ファイアウォールの機能拡張版のようなものである。そのため、ルーティングとリモート・アクセス(RRAS)やファイアウォール製品(ISA Server 2004など)とは併用できない。RRASのルータ機能やNAT/ベーシック・ファイアウォール、RAS/VPNサーバなどを利用する場合は、Windowsファイアウォールは利用できない。
これ以外の注意事項については、以下のドキュメントなどを参考にしていただきたい。
INDEX | ||
[特集]Windows Server 2003 SP1レビュー | ||
第4回 ネットワーク・セキュリティを実現する「Windowsファイアウォール」 | ||
1.Windowsファイアウォール機能の概要 | ||
2.Windowsファイアウォールの設定 | ||
「特集」 |
- Azure Web Appsの中を「コンソール」や「シェル」でのぞいてみる (2017/7/27)
AzureのWeb Appsはどのような仕組みで動いているのか、オンプレミスのWindows OSと何が違うのか、などをちょっと探訪してみよう - Azure Storage ExplorerでStorageを手軽に操作する (2017/7/24)
エクスプローラのような感覚でAzure Storageにアクセスできる無償ツール「Azure Storage Explorer」。いざというときに使えるよう、事前にセットアップしておこう - Win 10でキーボード配列が誤認識された場合の対処 (2017/7/21)
キーボード配列が異なる言語に誤認識された場合の対処方法を紹介。英語キーボードが日本語配列として認識された場合などは、正しいキー配列に設定し直そう - Azure Web AppsでWordPressをインストールしてみる (2017/7/20)
これまでのIaaSに続き、Azureの大きな特徴といえるPaaSサービス、Azure App Serviceを試してみた! まずはWordPressをインストールしてみる
|
|