Windows 11 ノート PC をハードニングするとき、最初に迷うのが「Windows Defender Firewall は既定のままで良いのか、どこまでカスタムすべきか」です。本記事は実運用に基づく判断軸・具体的な設定例・監査と段階的強化の進め方までを一気通貫で解説し、迷いなく安全かつ機能的な構成にたどり着けるよう設計しています。
目次
前提：Windows Defender Firewall は「セキュア・バイ・デフォルト」
Windows Defender Firewall（以降、WDF）は、OS や主要サービス（Windows Update、DHCP、DNS クライアント、時刻同期、Active Directory 参加環境でのドメイン関連通信など）が正常動作するための組み込みルールを同梱しています。これらは OS のライフサイクルに合わせて緻密にチューニングされており、むやみに削除・無効化するとネットワーク機能や更新プロセス、ライセンス認証、ストアアプリの配信に支障をきたす可能性が高くなります。
また、WDF の既定ポリシーは「受信は原則ブロック」「送信は原則許可」という最小権限モデルに立脚しており、一般的なクライアント端末のハードニングにおいては、この方針をベースに必要最小限の例外だけを追加するのがベストプラクティスです。
結論（先出し）：どう設定すべきか
- 既定ルールは削除・無効化しない。OS 機能に直結するため温存が原則。
- 受信は既定でブロック、必要なサービスのみ個別許可。RDP・SMB・WinRM など、提供が必要なものだけを限定公開。
- 送信は既定で許可を維持。機密端末や分離ネットワークなど高セキュリティ要件に限り、監査 → ホワイトリスト化 → 段階的ブロックへ移行。
- ベースラインは Microsoft の推奨（Security Baseline）を踏襲。グループポリシーまたは Security Compliance Toolkit を用いて適用し、監査ログと併用して安全に運用。
なぜ既定ポリシーが推奨されるのか
- 最小権限の設計に適合：受信は明示許可がない限り遮断。端末が「サービス提供者」にならない限り、侵入口を作らない。
- 送信の全面ブロックは運用コストが高い：アプリやサービス単位で許可リストを維持する必要があり、更新や新規導入のたびに保守が発生。一般クライアントではコスト対効果が悪化しがち。
- OS サービスの相互依存が複雑：Windows Update・ライセンス認証・ストア配信・Defender の脅威定義更新などは多様なエンドポイントと動的ポートを利用。誤ったブロックでセキュリティ自体を損なう恐れ。
Microsoft ベースラインの要点（Windows 11 クライアント）
Microsoft が提供するセキュリティ ベースライン（Security Compliance Toolkit 収録）は、企業・組織での大多数のユースケースに対応する「安全かつ機能的」な初期値を提供します。WDF 周りのエッセンスをまとめると以下のとおりです。
| 項目 | 推奨設定（要旨） | 運用ポイント |
|---|---|---|
| ファイアウォール有効化 | 全プロファイル（ドメイン/プライベート/パブリック）有効 | サービス停止・無効化は不可。例外はトラブル時の一時的対応に限定。 |
| 既定の受信動作 | ブロック | 明示許可のない着信は遮断。必要サービスのみポート/アプリ単位で許可。 |
| 既定の送信動作 | 許可 | 高機密環境を除き維持。強化時は監査→ホワイトリスト→段階的ブロック。 |
| 既定ルール群 | 削除・無効化しない | OS 機能に直結。変更は最小限かつ再現手順をドキュメント化。 |
| ログ/監査 | ドロップ/許可の監査を有効化 | イベント 5156/5157/5152 等で可視化。運用の要。 |
| 管理 | GPO または Security Compliance Toolkit | 構成の一元管理とバージョン管理を徹底。 |
カスタム ルールを追加すべき場面と設計指針
受信（Inbound）：公開の必要があるサービスのみ個別許可
- リモート デスクトップ（RDP）:管理端末からの接続を必要とする場合のみ。プロファイルは Private/Domain に限定し、特定の送信元のみ（管理用サブネットや VPN プール）を許可。
- ファイル共有（SMB）:社内共有が必要なときのみ。Public プロファイルでは許可しない。LocalSubnet または特定サブネットに制限。
- リモート管理（WinRM、WMI）:運用チームの管理要件を満たす範囲に限定し、アクセス元を明確に。
- 開発/検証用途:WSL2/コンテナ/ローカル HTTP サーバの公開が必要な場合、ループバック/ローカルのみに留めるか、時間制限付きルールで運用。
送信（Outbound）：高セキュリティ要件に限り段階的に強化
送信ブロックは効果も高い反面、最も壊れやすい設定です。以下の段階で進めると安全です。
- 監査のみで可視化：現状の通信をイベントログで収集し、アプリごとの依存関係を洗い出す。
- リスクの高い宛先をスポットで遮断：既知の不要プロトコル/宛先をピンポイントにブロック。
- 重要アプリのホワイトリスト化：svchost のサービス単位（例：wuauserv）や特定の実行ファイルにひもづけて許可。
- プロファイル単位で段階的に既定送信＝ブロックへ移行：まず Public→Private→Domain の順に。
実践：ベースライン導入から運用定着まで
1) ベースラインの適用
- 最新の Windows 11 セキュリティ ベースラインを取得し、GPO 形式で適用。
- 個別端末のみで運用する場合は、ローカル グループ ポリシー（gpedit.msc）またはローカル セキュリティ ポリシーで同等設定を反映。
2) 現状把握（監査モードの整備）
イベントログで許可/拒否を可視化します。以下は最小構成の例です。
REM 監査ポリシー（Filtering Platform）を有効化
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
REM ログ出力の確認（イベント ビューア）
REM セキュリティログ: ID 5156（許可）、5157（拒否）、5152（パケット ドロップ）テキストログ（pfirewall.log）も併用する場合は、各プロファイルのログ設定を有効化しておくと分析が容易です。
PowerShell
# 全プロファイルでファイアウォールを有効化し、既定動作を確認
Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True `
-DefaultInboundAction Block -DefaultOutboundAction Allow `
-NotifyOnListen True
# pfirewall.log を有効化
Set-NetFirewallProfile -Profile Domain,Private,Public ` -LogAllowed True -LogBlocked True -LogFileName %systemroot%\system32\LogFiles\Firewall\pfirewall.log`
-LogMaxSizeKilobytes 327673) 受信ルールの最小化（例：RDP, SMB, WinRM）
| 用途 | プロトコル/ポート | 対象 | 推奨スコープ/プロファイル | 備考 |
|---|---|---|---|---|
| RDP | TCP 3389 | TermService | RemoteAddress：管理セグメント/VPN、Profile：Domain/Private | Public では許可しない。二要素認証/ネットワークレベル認証の併用を推奨。 |
| SMB | TCP 445 | System | RemoteAddress：LocalSubnet、Profile：Domain/Private | Public での許可は避ける。プリンター共有も同様。 |
| WinRM | HTTP 5985 / HTTPS 5986 | WinRM | RemoteAddress：運用端末の IP 範囲 | 可能なら HTTPS のみ。証明書/認証の整備が前提。 |
PowerShell 例：
PowerShell
# RDP を管理セグメントからのみ許可（Private/Domain）
New-NetFirewallRule -DisplayName "RDP from AdminLAN" -Direction Inbound -Protocol TCP -LocalPort 3389 `
-Action Allow -Profile Domain,Private -RemoteAddress 192.168.10.0/24 -Program System -Service TermService
# SMB をローカルサブネットからのみ許可（Private/Domain）
New-NetFirewallRule -DisplayName "SMB from LocalSubnet" -Direction Inbound -Protocol TCP -LocalPort 445 `
-Action Allow -Profile Domain,Private -RemoteAddress LocalSubnet -Program System4) 送信強化の段階的アプローチ
まずは危険度の高い宛先/プロトコルのスポットブロックから始めます（例：LAN 内で不要な古いクリアテキストプロトコル）。
PowerShell
# 例：Telnet（TCP 23）送信をブロック（全プロファイル）
New-NetFirewallRule -DisplayName "Block Telnet Outbound" -Direction Outbound -Protocol TCP -RemotePort 23 `
-Action Block -Profile Domain,Private,Public
# 例：SMB のインターネット向け送信をブロック（Public）
New-NetFirewallRule -DisplayName "Block SMB to Internet" -Direction Outbound -Protocol TCP -RemotePort 445 `
-Action Block -Profile Public -RemoteAddress Any本格的に既定送信＝ブロックへ移行する際は、重要サービスのホワイトリストを先に作ります。
PowerShell
# Windows Update を許可（svchost + wuauserv サービス）
New-NetFirewallRule -DisplayName "Allow Windows Update" -Direction Outbound `
-Program "%SystemRoot%\System32\svchost.exe" -Service wuauserv -Protocol TCP -RemotePort 80,443 -Action Allow
# その後に既定送信をブロックへ切替（Public → Private → Domain の順に段階的に）
Set-NetFirewallProfile -Profile Public -DefaultOutboundAction Block
# 動作確認後に Private、最後に Domain と広げる運用ディテール：プロファイル、スコープ、優先度を理解する
プロファイル（Domain / Private / Public）
- Domain：ドメイン参加中でドメイン コントローラーに到達できるネットワークで自動適用。社内想定の許可が多め。
- Private：信頼する自宅/社内ネットワーク。最小限の共有が許可され得る。
- Public：空港/カフェ/テザリングなど公共ネットワーク。最も厳格に。
ネットワーク プロファイルはユーザー/管理者の選択や検出ロジックに依存します。誤判定に備え、Public でも破綻しない許可設計にしておくと実地で壊れにくくなります。
ルールの優先度（概念）
| 比較軸 | 優先されやすいもの | メモ |
|---|---|---|
| Allow vs Block | Block | 同一トラフィックに競合する場合、ブロックが勝つ。 |
| スコープの具体性 | より具体的（特定プログラム/サービス/ポート/アドレス） | プロセス/サービスに縛ると誤許可を防ぎやすい。 |
| プロファイル | 適用対象のプロファイル | Public で無用な許可を出さない。 |
| Edge Traversal | Block | NAT 超えの到達性を許してよいかを明確に制御。 |
スコープ設計のコツ
- RemoteAddress は Any を避ける：最低でも LocalSubnet、可能なら管理セグメント等に限定。
- InterfaceType を活用：ワイヤレス/有線/VPN の別で制御すると事故を減らせる。
- サービス単位のひも付け：svchost.exe は多彩なサービスをホスト。-Service で目的のサービスに限定。
よくある落とし穴と対処法
- Windows Update が失敗する：送信ブロックの導入順序が逆。wuauserv 等の許可を先に作る。インターネット プロキシ/SSL 検査の影響も確認。
- ネットワーク プリンタへ印刷不可：SMB/WS-Discovery/IPP 等の受信/送信が必要。プロファイルとサブネットを限定して許可。
- VPN 接続時のみ動作が変：InterfaceType=RAS を考慮した別ルールを用意。Split/Full トンネルの違いにも注意。
- WSL2/コンテナ環境でのポート公開：ローカル開発用途は 127.0.0.1 バインドを基本に。外部公開は時間限定ルールで。
- Public で RDP が開いてしまった：プロファイル選択の誤り。Public を除外したルールに修正し、Public での Edge Traversal は Block に。
- サードパーティ製 FW/EDR との競合：ドライバ階層やフィルタ順序で予期せぬ結果に。ベンダー推奨の共存設定を確認。
シナリオ別の推奨構成
個人/一般クライアント（持ち出し PC）
- 既定：受信ブロック／送信許可
- Public を最優先で安全化（共有系許可なし）
- RDP/SMB の受信許可は原則なし。必要時のみ時間限定・場所限定。
小規模オフィス
- 既定：受信ブロック／送信許可
- SMB の受信は LocalSubnet 限定で Private/Domain のみ許可
- 管理のための WinRM を導入する場合、運用端末の固定 IP のみに限定
機密端末/分離セグメント
- 段階的に既定送信＝ブロックへ移行（Public → Private → Domain）
- Windows Update/認証/時刻同期/監視/資産管理の許可を先行してホワイトリスト化
- USB テザリング/パーソナルホットスポットなど Public では厳格に
開発者 PC/検証端末
- ローカル開発サーバはループバック限定
- 対外公開が必要な場合は「期間限定ルール＋ログ監視」をセットで運用
バックアップとロールバック
変更前に必ずエクスポートしておくと安心です。
REM 既存ポリシーのバックアップ
netsh advfirewall export "C:\Backup\wdf_backup.wfw"
REM 復元
netsh advfirewall import "C:\Backup\wdf_backup.wfw"運用のゴール：監査→最小許可→ドキュメント化→自動化
- 監査：イベント（5156/5157/5152）、pfirewall.log を収集。できれば中央集約（WEF/ログ基盤）。
- 最小許可：受信は「公開が必要なサービスのみ」。送信は「高リスクのみブロック → 重要アプリを許可 → 既定ブロックへ段階移行」。
- ドキュメント化：背景・影響範囲・ロールバック手順を記載。変更管理の記録を残す。
- 自動化：GPO/Intune/構成管理で配布。PowerShell スクリプトはバージョン管理。
「必要最小限」の判断フロー（テンプレート）
| 質問 | Yes の場合 | No の場合 |
|---|---|---|
| 外部から当該端末へアクセスされる必要があるか？ | 受信を個別許可（プロファイル/送信元を限定） | 受信は既定ブロックのまま |
| Public 環境での利用が想定されるか？ | Public での許可は原則禁止、必要性を再評価 | Private/Domain のみに許可を適用 |
| アプリは自動更新/オンライン認証を必要とするか？ | 送信許可リストに事前登録（サービス単位を活用） | 送信制限の候補として監査で確認 |
チェックリスト（公開前の自己レビュー）
- 全プロファイルで WDF は有効化されているか？
- 既定の受信＝ブロック、送信＝許可（または段階的強化の計画）になっているか？
- 受信許可は本当に必要なサービスだけか？送信元・プロファイル・インターフェイス・期間を絞っているか？
- Public で危険な許可を出していないか？Edge Traversal は Block か？
- ログ/監査は有効化され、確認手順が整備されているか？
- バックアップ（.wfw）とロールバック手順は用意したか？
- 変更理由・影響・連絡体制がドキュメント化されているか？
FAQ
Q. 既定ルールをまとめてオフにすると軽くなりますか？
A. いいえ。既定ルールは OS 機能のために最適化されています。無効化はトラブルの温床になり、パフォーマンス改善にもつながりません。
Q. 送信を全面ブロックすれば最強では？
A. セキュリティ効果は高いものの、更新・認証・各種クラウド連携が破綻しやすく、結果的に運用不能になるケースが多いです。必ず監査→ホワイトリスト化→段階導入を。
Q. RDP をどうしても公開したい場合の最低限は？
A. 公開するなら VPN 前提で、端末直公開は避ける。やむを得ない場合は送信元 IP の固定、Public 不許可、アカウント保護（NLA/多要素/アカウント ロックアウト）を併用。
Q. 家庭内の NAS/プリント共有が使えないときは？
A. プロファイルが Public になっていないか確認。必要に応じて Private に切替え、SMB 関連の受信ルールを LocalSubnet 限定で有効化します。
まとめ
標準ルールは温存し、受信ブロック／送信許可の既定ポリシーを基本に、必要最小限のカスタムを追加する——これが Windows 11 クライアントのハードニングで最も壊れにくく、コスト効率の高い構成です。高セキュリティ要件でも、監査で可視化しながら段階的に強化すれば、業務影響を極小化しつつ堅牢性を着実に引き上げられます。
実装スニペット（まとめ）
PowerShell
# 1) ベースライン相当の土台
Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True `
-DefaultInboundAction Block -DefaultOutboundAction Allow -NotifyOnListen True
# 2) ログ/監査
Set-NetFirewallProfile -Profile Domain,Private,Public -LogAllowed True -LogBlocked True `
-LogFileName %systemroot%\system32\LogFiles\Firewall\pfirewall.log -LogMaxSizeKilobytes 32767
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
# 3) 最小受信（例：RDP/SMB）
New-NetFirewallRule -DisplayName "RDP from AdminLAN" -Direction Inbound -Protocol TCP -LocalPort 3389 ` -Action Allow -Profile Domain,Private -RemoteAddress 192.168.10.0/24 -Program System -Service TermService
New-NetFirewallRule -DisplayName "SMB from LocalSubnet" -Direction Inbound -Protocol TCP -LocalPort 445`
-Action Allow -Profile Domain,Private -RemoteAddress LocalSubnet -Program System
# 4) 送信の段階的強化（例）
New-NetFirewallRule -DisplayName "Block Telnet Outbound" -Direction Outbound -Protocol TCP -RemotePort 23 ` -Action Block -Profile Domain,Private,Public
New-NetFirewallRule -DisplayName "Allow Windows Update" -Direction Outbound`
-Program "%SystemRoot%\System32\svchost.exe" -Service wuauserv -Protocol TCP -RemotePort 80,443 -Action Allow
# 検証後に Public → Private → Domain の順で既定送信を Block へ
# Set-NetFirewallProfile -Profile Public -DefaultOutboundAction Block最終ポイント：「止める」ことより「壊さない」ことのほうが難しいのがクライアント ファイアウォールの現実です。監査で現状を見える化し、既定の安全設計を尊重しつつ、必要な例外だけを丁寧に積み上げていく——この順番を守れば、Windows Defender Firewall は強力な味方になります。
コメント