Windows Defender Firewall の運用ベストプラクティス｜プロファイル・規則の棚卸し・ログ・GPO管理

Windows Defender Firewall（セキュリティが強化された Windows Defender ファイアウォール）を安全に運用する要点は、「3つのプロファイルをすべて有効にして受信は既定で拒否」「許可規則は範囲を絞り、定期的に棚卸しする」「ブロックのログを残す」「複数台は GPO や Intune で一元管理する」「変更前にエクスポートしておく」の5つです。この記事では、IIS で WordPress を動かす Windows Server や社内の Windows 端末を想定し、PowerShell を使った確認・設定・復旧の手順を説明します。

まず現状を把握する

運用を見直す前に、いまの状態を正確に知ることが出発点です。Windows のファイアウォールには「ドメイン」「プライベート」「パブリック」の3つのプロファイルがあり、接続しているネットワークの種類によって適用されるプロファイルが変わります。サーバーがドメインに参加しているのにネットワークが「パブリック」と判定されている、といったずれは珍しくなく、想定と違う規則が効いている原因になります。

# プロファイルごとの有効/無効と既定の動作
Get-NetFirewallProfile | Format-Table Name, Enabled, DefaultInboundAction, DefaultOutboundAction, LogBlocked

# 各ネットワーク接続がどのプロファイルに分類されているか
Get-NetConnectionProfile | Format-Table InterfaceAlias, NetworkCategory

DefaultInboundAction が NotConfigured と表示される場合は、既定値（受信はブロック）が使われている状態です。GPO で値を配布している環境では、ローカルで見える値と実際に適用される値が異なることがあるため、Get-NetFirewallProfile -PolicyStore ActiveStore で適用中の値を確認すると確実性が上がります。

プロファイルは無効化せず、受信は既定で拒否

トラブル対応で「とりあえずファイアウォールを切る」と、そのまま戻し忘れる事故がよく起きます。通信が通らないときは、ファイアウォール全体を無効化するのではなく、必要な許可規則を追加して切り分けるのが基本です。

# 3プロファイルを有効化し、受信は既定で拒否、送信は既定で許可
Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True `
  -DefaultInboundAction Block -DefaultOutboundAction Allow

送信も既定で拒否にすると防御は厚くなりますが、Windows Update、証明書の失効確認、ライセンス認証、監視エージェントなど必要な通信を洗い出す手間が大きく、運用負荷が上がります。まずは受信側を固め、送信の制限は対象を限定したサーバーから段階的に試す進め方が現実的です。

許可規則は「誰から・どのポートに・どのプロファイルで」を絞る

規則が増える最大の原因は、範囲を広く作った規則が残り続けることです。新しく許可規則を作るときは、次の3点を意識します。

• 送信元（RemoteAddress）を絞る：RDP（TCP 3389）や WinRM（TCP 5985/5986）は管理用の IP アドレスだけに許可し、インターネット全体に公開しない
• プロファイルを絞る：社内からの管理接続はドメインプロファイルだけに限定する
• 名前とグループを付ける：誰が何のために作った規則か後から分かるようにする

# 管理セグメントからだけRDPを許可する例（アドレスは環境に合わせて変更）
New-NetFirewallRule -DisplayName "Mgmt RDP from 192.0.2.0/24" `
  -Group "Ops-Managed" -Direction Inbound -Protocol TCP -LocalPort 3389 `
  -RemoteAddress 192.0.2.0/24 -Profile Domain -Action Allow

# IISでWordPressを公開する場合のHTTP/HTTPS
New-NetFirewallRule -DisplayName "Web HTTP/HTTPS" -Group "Ops-Managed" `
  -Direction Inbound -Protocol TCP -LocalPort 80,443 -Action Allow

既存の RDP 規則（「リモート デスクトップ」グループなど）が全アドレスに開いていないかも確認します。既存規則を書き換える前に、後述のエクスポートを済ませておくと安心です。

定期的な棚卸し

アプリケーションのインストール時に自動で作られた規則や、検証のために一時的に追加した規則は、放置すると攻撃面になります。四半期ごとなど周期を決め、有効な受信許可規則を一覧にして見直します。

# 有効な受信許可規則と、そのポート・送信元を一覧化
Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True |
  ForEach-Object {
    $port = $_ | Get-NetFirewallPortFilter
    $addr = $_ | Get-NetFirewallAddressFilter
    [pscustomobject]@{
      Name    = $_.DisplayName
      Profile = $_.Profile
      Proto   = $port.Protocol
      Port    = ($port.LocalPort -join ",")
      Remote  = ($addr.RemoteAddress -join ",")
    }
  } | Sort-Object Name | Format-Table -AutoSize

Remote が Any で、しかもパブリックプロファイルに適用されている規則は優先的に確認します。用途が分からない規則は、いきなり削除せず Disable-NetFirewallRule で無効化して一定期間様子を見ると、業務影響があった場合にすぐ戻せます。

ログを残して「何が止まったか」を見えるようにする

ファイアウォールのログは既定では無効です。ブロックしたパケットだけでも記録しておくと、「通信できない」という問い合わせに対して原因がファイアウォールかどうかを短時間で判断できます。

Set-NetFirewallProfile -Profile Domain,Private,Public -LogBlocked True `
  -LogAllowed False -LogMaxSizeKilobytes 16384 `
  -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log"

許可したパケットまで記録するとログが急速に膨らむため、通常はブロックのみで十分です。テキストログはサイズ上限に達すると古い内容が上書きされるので、長期保管や複数台の横断検索が必要なら、SIEM やログ収集エージェントで外部に送ります。

より詳しく追いたいときは、Windows フィルタリングプラットフォーム（WFP）の監査を有効にすると、セキュリティイベントログに接続の許可・ブロック（イベント ID 5156/5157 など）が記録されます。ただし大量に出力されるため、調査期間だけ有効にするのが無難です。規則の追加・変更・削除の履歴は、イベントビューアーの「Windows Firewall With Advanced Security」の Firewall ログに残るので、意図しない変更の検知に使えます（ログ名や表示は OS のバージョンで多少異なります）。

複数台は GPO や Intune で一元管理する

台数が増えると、端末ごとに手作業で規則を管理するのは限界があります。Active Directory 環境ではグループポリシー（コンピューターの構成 → ポリシー → Windows の設定 → セキュリティの設定 → セキュリティが強化された Windows Defender ファイアウォール）で、Entra ID／Intune 環境ではエンドポイントセキュリティのファイアウォールポリシーで配布できます（2026年10月現在）。管理画面の項目名は更新で変わることがあるため、各製品のドキュメントで確認してください。

一元管理では「ローカルで作った規則をマージするか」という設定が重要です。マージを許可しない設定にすると、利用者や他のソフトがローカルで追加した規則が効かなくなり、規則の散らばりを防げます。一方で、アプリの動作に必要なローカル規則も無効になるため、事前に必要な規則をポリシー側へ取り込んでから切り替えます。

変更前のバックアップと、締め出し対策

規則の一括変更や GPO の適用前には、現在の設定をエクスポートしておきます。

# 現在の設定をファイルに保存
netsh advfirewall export "C:\Backup\firewall-before-change.wfw"

# 問題があったときに戻す
netsh advfirewall import "C:\Backup\firewall-before-change.wfw"

リモートデスクトップ経由で作業しているときに受信規則を変えると、自分の接続を切ってしまうことがあります。次の順番を守ると締め出しを避けやすくなります。

1. 自分の管理元からの RDP 許可規則が残ることを先に確認する
2. クラウドのシリアルコンソールや仮想化基盤のコンソールなど、ネットワークに依存しない接続手段を用意する
3. 本番の前にステージング用のサーバーで同じ変更を試す
4. 変更後、別のセッションから新規に接続できることを確かめてから作業を終える

クラウドやネットワーク機器との役割分担

クラウド上の Windows Server では、ホストのファイアウォールとは別に、セキュリティグループやネットワークセキュリティグループなどのクラウド側フィルターがあります。どちらか一方だけで守るのではなく、外側（クラウド側）で公開範囲を大きく絞り、内側（Windows 側）でプロセスやプロファイル単位の制御を行う多層の考え方が有効です。通信が通らないときは、外側と内側のどちらで止まっているかを、上記のブロックログとクラウド側のフローログで切り分けます。

まとめ

• 3つのプロファイルを有効にし、受信は既定で拒否。トラブル時もファイアウォール全体は止めない
• 許可規則は送信元・ポート・プロファイルを絞り、名前とグループで管理する
• 定期的に受信許可規則を一覧化し、不要なものは無効化してから削除する
• ブロックのログを有効にし、必要に応じて外部のログ基盤へ送る
• 複数台は GPO／Intune で一元管理し、ローカル規則のマージ方針を決める
• 変更前に netsh advfirewall export で保存し、コンソール接続を確保してから作業する

• Windows Server と IIS で WordPress を動かす方法
• ファイアウォールでポートを開放する手順