Windows Serverを利用していると、大切なデータやサービスを守るためにファイアウォールの設定が欠かせません。特定のポートを閉じようとしても、なぜかNmapなどのポートスキャンでは依然開放状態に見えることがあります。この記事では、Windows Defender Firewallを使って意図した通りにポートをブロックする方法を詳しく解説します。
Windows Defender Firewallの概要
Windows環境における標準的なファイアウォール機能として、多くのサーバ管理者が利用しているのがWindows Defender Firewallです。以前は「Windows Firewall」と呼ばれていた時期もありますが、機能が進化するとともに「Windows Defender Firewall」という名称へ変わりました。
Windows Defender Firewallは、次のような特徴を持ちます。
- ドメイン、プライベート、パブリックの3つのプロファイルで細かくルールを設定できる
- アプリケーション単位やポート単位で通信を許可またはブロックすることが可能
- Windows標準のため、ほかのソフトウェアに比べてシステムとの親和性が高い
- netshコマンドを使ってGUI以外の方法でルールを追加・削除できる
ただし、GUI上の操作だけでは意図しないルールが残ってしまったり、Pleskなどのコントロールパネルが独自にファイアウォール設定を管理している場合があり、思った通りに設定が反映されないことがあります。
ポートをブロックしたつもりでも開いていると表示される原因
実際にNmapなどでスキャンすると「110」「143」「1433」「3306」といった、明らかに閉じたいポートが“open”もしくは“filtered”として表示されるケースがあります。原因はさまざまですが、以下のような事情が考えられます。
1. ルールの適用範囲や優先度の問題
Windows Defender Firewallには大きく分けて受信の規則（Inbound Rules）と送信の規則（Outbound Rules）があります。さらに、ドメインプロファイル、プライベートプロファイル、パブリックプロファイルの3種類があり、それぞれ適用されるネットワークの状況が異なります。
同じポートに対して「許可」や「拒否」のルールが複数存在すると、優先順位や適用プロファイルの差によってブロックされない場合があります。
2. 別のネットワークインターフェースまたはIPアドレスが存在
NICが複数あるサーバの場合、特定のアダプタに適用されているルールと別のアダプタに適用されているルールが噛み合わないことがあります。さらに、169.254..のようなAPIPAアドレスが自動的に割り当てられ、そちらの経路で想定外に通信が許可されているケースもあります。
3. 外部アプリケーションによるルールの上書き
Pleskなどの管理ツールが独自にファイアウォールをコントロールすることがあります。その場合、WindowsのGUIから設定したルールよりも、Pleskのファイアウォール設定が優先されることがあり、実際にはポートがブロックされていないケースが生じます。
4. netstat や Nmap の表示上の誤解
netstatコマンドやNmapのスキャン結果は、ポートが実際に通信できるかどうかではなく、アプリケーションがポートをリッスンしているかどうかを表す場合があります。ファイアウォールでブロックしていても、OSレベルでは“待ち受け”が確認されるため、Nmap上ではopenと表示されるケースがあります。ただし、実際にはブロックされているため通信が成立しないこともあります。
Windows Defender Firewallで確実にポートをブロックする手順
ここでは、特定のポート（例: 110, 143, 1433, 3306）をブロックしたい場合の具体的な手順を解説します。やるべきことは大きく3つに分かれます。
1. GUI上でのルール設定を再確認
Windows Server 2022の場合、サーバマネージャなどから「Windows Defender Firewallの詳細設定」に進みます。
- 受信の規則（Inbound Rules）を選択
- 既存の規則の中から「TCP ポート110」「TCP ポート143」などに該当するものを探す
- 「許可」や「ブロック」などの状態を確認し、不要な“許可”ルールがあれば削除
- 新規で「受信の規則の作成」を行い、ブロックしたいポート番号を指定する
- アクションを「ブロック」、プロファイルはドメイン、プライベート、パブリックすべて選択する
- 名前と説明をわかりやすく入力
以上の操作をGUIで行うことで、該当ポートの受信を遮断することができます。ただし、実際に設定しても、ほかのルールが邪魔をしていたり、Plesk等で別途設定が上書きされる場合があるため、以下のnetshコマンドも活用することをおすすめします。
2. netshコマンドで明示的にルールを追加
GUIでは見落としている設定があってもうまくいかないと感じたら、netshコマンドでブロックルールを追加するとより確実です。以下は受信（inbound）トラフィックをブロックする例です。
netsh advfirewall firewall add rule name="Block Port 110" protocol=TCP dir=in localport=110 action=block
netsh advfirewall firewall add rule name="Block Port 143" protocol=TCP dir=in localport=143 action=block
netsh advfirewall firewall add rule name="Block Port 1433" protocol=TCP dir=in localport=1433 action=block
netsh advfirewall firewall add rule name="Block Port 3306" protocol=TCP dir=in localport=3306 action=blockこのコマンドを実行する際は、管理者権限でコマンドプロンプトまたはPowerShellを起動する必要があります。なお、送信（outbound）トラフィックもブロックしたい場合は、dir=outと指定すればOKです。
3. Pleskなどの外部ファイアウォール設定をチェック
Pleskや他のコントロールパネル、ウイルス対策ソフトのファイアウォール機能がオンになっている場合、Windows Defender Firewallで作ったルールより優先して動作する場合があります。
たとえばPleskでは「Plesk Firewall」という拡張機能が有効化されていることがあります。その場合、Pleskの設定画面から該当ポートがどのように扱われているかを確認し、必要に応じてブロックまたは設定の削除を行いましょう。Plesk側でルールを変えたタイミングでWindows Defender Firewallの設定が書き換えられるケースがあるため、両方を整合させることが大切です。
APIPAや複数NICがある場合の確認ポイント
サーバに複数のNICが搭載されている、あるいは仮想NICを活用している場合、意図しない形で通信が許可される可能性があります。またDHCPサーバとの通信不具合などが発生し、169.254..のAPIPAアドレスが割り当てられると、別の経路で通信が成立しうるケースがあります。
複数NICの優先順位
Windowsでは、ネットワークアダプタのプロパティや「詳細設定」からNICの優先順位を確認・変更できます。ファイアウォールルールがどのインターフェースに適用されているのかを把握しないと、意図せず別のNICで通信を許可してしまうことがあります。
APIPAアドレスの削除方法
DHCPサーバが正常に動いているはずなのにAPIPAアドレスが付与される場合、以下の方法で修正を試みることができます。
- ipconfig /release と ipconfig /renew コマンドでIPアドレスを再取得する
- ネットワークアダプタの設定を開き、固定IP設定が必要であれば正しく入力する
- それでもAPIPAが解除されない場合は、NICドライバの再インストールやケーブル・スイッチの問題を疑う
ファイアウォールが正しく機能していても、NICレベルで意図せぬアドレスが使われているとスキャン結果に齟齬が生じる可能性があります。
ポートスキャンによる検証とトラブルシューティング
設定を施したら、Nmapなどのポートスキャナを使って本当にブロックできているかをチェックします。ここでは典型的なNmapコマンドの例を示します。
nmap -p 110,143,1433,3306 <ターゲットサーバのIPアドレス>実際にポートがブロックされていれば、filteredあるいはclosedとなるはずです。ただし、前述のようにアプリケーションが待ち受けをしているがファイアウォールでブロックしている場合、Nmapが「open」と判断することもあります。その際には、アプリケーションログやWindows Defender Firewallのログを併せて確認すると、通信が実際に遮断されているかどうかをより正確に把握できます。
Windows Defender Firewallのログ設定
Firewallの詳細設定画面で「監視」もしくは「プロパティ」を選択すると、ドメイン/プライベート/パブリックプロファイルごとにログの保存場所やサイズ、ドロップ情報の記録などの設定が行えます。ログにドロップ（ブロック）情報がきちんと記録されているならば、通信は正しく拒否されています。Nmapの結果に惑わされず、ログで実際のパケットドロップを確認することが重要です。
netstatコマンドでの確認
ファイアウォール設定に加え、サーバ内でどのプロセスがどのポートをリッスンしているかを把握するのに便利なのがnetstatコマンドです。例えばPowerShellやコマンドプロンプトで以下のコマンドを実行します。
netstat -ano | findstr :110ポート110をリッスンしているプロセスのPIDが表示されるため、タスクマネージャやProcess Explorerなどで該当アプリケーションを特定できます。もし不明なアプリケーションが動作していれば、それが原因でNmap上「open」と表示されているかもしれません。
設定が上書きされる場合の対処
Pleskやウイルス対策ソフトによるルールの上書きが頻繁に起こると、せっかく設定したブロックルールがいつの間にか消えていたり、状態が変更されたりします。対処法としては以下のアプローチが考えられます。
1. Pleskのファイアウォール機能を無効化または管理ポリシーを見直す
Plesk Firewallが明示的に必要でなければ、オフにするのも一つの手です。あるいは、Plesk側でブロック対象ポートの設定を同様に適用して、Windows Defender Firewallと矛盾が生じないように整合性を取ります。
2. ウイルス対策ソフト側の設定確認
ウイルス対策ソフトの中には、独自のネットワーク保護機能やファイアウォール機能を持つものがあり、Windows Defender Firewallの設定を上書きしてしまうことがあります。特に企業環境で多いのがTrend Micro、McAfee、Symantecなどのエンドポイントセキュリティ製品です。この場合、セキュリティ製品側でのポートブロック設定を確認し、Windows Defender Firewallと競合しないように調整する必要があります。
3. 手動による再適用スクリプトの作成
万が一設定がリセットされる場面が定期的にあるなら、netsh advfirewall firewall系のコマンドをバッチ化・スクリプト化しておき、定期的に再適用する方法もあります。たとえば、サーバ再起動後に自動実行されるタスクスケジューラを設定するなど、環境によっては「最終的に確実な方法」として機能します。
バックアップと復元の重要性
ファイアウォール設定が複雑化してしまったり、思わぬ不具合で一部のルールが削除できない・編集できないといったトラブルが起こる場合もあります。そういったときには、システム状態のバックアップやレジストリバックアップからの復元を検討することも選択肢の一つです。
レジストリバックアップの方法
Windows Defender Firewallの設定はレジストリに格納されています。復元ポイントを作成しておけば、特定の時点の状態に戻せる可能性があります。ただし、根本原因を解決しないままに戻してしまうと再発する恐れがあるため、復元後の設定確認を入念に行いましょう。
復元後に行う確認事項
- 復元前にブロックしたかったポート(110, 143, 1433, 3306)が、正しくブロックされているかNmapなどで再チェック
- netshコマンドを使ったルール一覧を取得し、期待しているルールが存在するか確認
- Pleskやウイルス対策ソフトなど外部要因の設定を再適用もしくは再度見直す
トラブルシューティングをより効率化するためのポイント
最後に、Windows Defender Firewallで意図した通りにポートをブロックする上で押さえておきたいポイントをまとめます。
1. ルールの重複と整理
同じポートに対して複数のルールが存在すると、どのルールが優先されているか混乱を招きがちです。基本的には「拒否（ブロック）」が「許可」よりも優先されますが、状況やプロファイルによっては思わぬ結果を生むことがあります。なるべく不要なルールを削除し、必要最小限に保つようにしましょう。
2. プロファイルの適切な選択
サーバが所属するネットワークがドメインプロファイルなのか、プライベートプロファイルなのか、あるいはパブリックプロファイルなのかを把握しましょう。とくに、プライベートかパブリックかを誤って設定すると、想定外の通信が通る、あるいは遮断される可能性があります。
3. ログを活用して通信の成否を追跡
Nmapの結果だけでなく、Firewallのドロップログやアプリケーションログを合わせてチェックすることで、通信がどこで止まっているかを可視化できます。
ログを取りやすいように、事前にファイアウォールのログサイズや保存先を十分に確保しておくことも重要です。
4. 上位の機器・サービスの存在
もしサーバの前段にロードバランサや別のファイアウォール機器がある場合、Windows Defender Firewallよりも先にトラフィックがフィルタリングされているかもしれません。設定変更後は、そちらの機器でもポートの状況を確認して、原因を切り分けることがポイントです。
5. 頻繁に変更するポートはドキュメント化
運用を続けると、新しいサービスを追加したり、利用しなくなったサービスのポートを閉じたりすることが度々あるでしょう。都度、ルールを追加・削除する際にはドキュメント化して、管理者全員がどのポートがどのような用途で開いているのかを把握できるようにしておきましょう。
まとめ
Windows Defender Firewallで特定のポートをブロックしようとしているにも関わらず、Nmapなどのポートスキャン結果で“open”と表示されてしまうと、不安になるものです。ですが、問題の多くは複数のルールの競合、Pleskやウイルス対策ソフトによる設定上書き、もしくは別のNICやAPIPAアドレスによる想定外の通信経路に原因が隠れています。
大切なのは、まずGUIとnetshコマンドの両面でルールを確認し、必要に応じて重複ルールを削除し、確実なブロックルールを作成することです。また、Plesk等のファイアウォール設定の存在を見落とさないようにし、ログを活用して通信の成否を客観的に把握することで、正しくポートをブロックできるようになります。
もしどうしても設定が反映されず不具合が起きる場合には、レジストリレベルやバックアップを利用した復元も検討してみてください。こうした一連の対策を講じることで、Windows Server 2022上のポート管理をより安心・安全に行うことができるはずです。トラブルシューティングを徹底し、必要なポートだけを開放してセキュリティを万全に保ちましょう。
コメント