Windowsファイアウォールを肥大化させている犯人は誰だ！：山市良のうぃんどうず日記（147）

山市良のうぃんどうず日記

膨大な数の「DNS Server Forward Rule -TCP」と「DNS Server Forward Rule - UDP」のペア

　Windows 10 バージョン1809のWindowsファイアウォール、正確には「セキュリティが強化されたWindows Defenderファイアウォール」（バージョン1803から“Defender”が付きました）の「受信の規則」で発見した大量の規則とは、次のような名称のものです。

　「XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX」の部分は何かのID（GUID）のようで、1つのペアでは共通ですが、他のペアとは異なります。規則の内容はどれもDNSクエリのためにTCPおよびUDPポート53の受信方向の通過を許可するもので、それ以外の特別な設定は見当たりません（画面1）。

画面1　大量に存在する謎の規則「DNS Server Forward Rule - TCP」と「DNS Server Forward Rule - UDP」のペア

　最初に見つけたPCにあった規則の数は、数える前に削除してしまったので分かりませんが、あまり起動することのない別のWindows 10 バージョン1809のPCでも50（25のペア）以上ありました。最初に見つけたPCにはもっとあったはずです（その理由は後ほど明らかに）。一方、この名前の規則が1つも存在しないWindows 10 バージョン1809のPCもありました。

　大量に存在する問題の規則を全て削除してみました。PCを再起動すると、再び2つの規則（1つのペア）が自動登録されました。シャットダウンして起動でも同じです。再起動または起動ごとに1ペアずつ増えていくのです（画面2）。

画面2　削除してもPCを再起動すると復活。そして再起動するごとに増えていく

謎の規則はHyper-V仮想スイッチ「Default Switch」に由来

　「受信の規則」に「DNS Server Forward Rule -TCP」と「DNS Server Forward Rule - UDP」のペアが存在するPCと、1つも存在しないPCの違いを確認してみると「クライアントHyper-V」の有効／無効の違いを見つけました。クライアントHyper-Vを有効化していないPCには、1つも存在しません。

　Windows 10のクライアントHyper-Vの仮想マシン環境を利用していなくても、クライアントHyper-Vに依存する機能やアプリケーション（例えば、Windows 10のWindows Defender Application GuardやDocker Desktop for Windowsなど）を利用している場合は、問題の規則が大量に存在すると思います。

　「PCの起動ごとに新たに規則が自動作成される」「Windows 10 バージョン1809のクライアントHyper-Vに関係」「DNS Server Forward Rule……という規則の名称」、これらの情報から問題の規則が大量に作成される犯人が思い当たりました。Windows 10 バージョン1809のクライアントHyper-Vに既定で作成されるHyper-V仮想スイッチ「Default Switch」です。

　Windows Server 2019でHyper-Vを有効化した場合は「Default Switch」は作成されませんが、Docker Enterprise（Docker EE for Windows Server）を導入している場合、コンテナ用の仮想スイッチ「nat」が作成されるため、同様の現象が発生します。

　Hyper-V仮想スイッチの情報は、レジストリの「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\SwitchList」に存在します。最後に登録された規則（全て削除して再起動したときの規則）に含まれる謎のID「XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX」は、現在の「Default Switch」に対応するレジストリの下に見つかりました。このGUIDは、Windows 10の仮想ネットワークアダプター「vEthernet（Default Switch）」が接続される「Default Switch」のポートのGUIDでした（画面3）。

画面3　謎のGUIDは、Hyper-Vホストの「vEthernet（Default Switch）」の接続先となっているHyper-V仮想スイッチ「Default Switch」のポートのGUID

　そのことは「ipconfig /all」コマンドで確認できる「vEthernet（Default Switch）」のMACアドレスと、「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmsmp\parameters\NicList」下の情報を突き合わせることで分かります。

Default Switchとは何者？

　Windows 10 Fall Creators Update（バージョン1709）からは、Hyper-Vを有効にすると、Hyper-Vの仮想スイッチとして既定で「既定のスイッチ」（バージョン1809での名称は「Default Switch」）が自動作成されるようになりました。

　この仮想スイッチは、ユーザーによる削除や設定変更ができません。また、この仮想スイッチは内部ネットワークタイプですが、仮想マシンに対してインターネットプライベートIPアドレス空間のサブネットからのIPアドレス自動割り当てと、Windows 10のホストのネットワークを共有したNAT（ネットワークアドレス変換）機能を提供します。

　実は、Windows 10 バージョン1809の「Default Switch」は、PCを起動するたびにNATネットワークのプライベートIPのサブネットアドレスが「172.x.x.x/28」と「192.168.x.x/28」のいずれかにランダムに変わってしまうという現象を筆者は確認しています。

　筆者の以下の個人ブログに書いたように、イベントログで確認すると、PCを起動するたびに「Default Switch」の仮想スイッチとポートの削除と作成が行われていることを確認できます。

• 謎：Windows 10 ver 1809のDefault SwitchのNATサブネットが起動ごとに変わる件（筆者の個人ブログ：山市良のえぬなんとかわーるど）

　これはWindows 10 バージョン1803以前の「既定のスイッチ」とは異なる挙動です。Windows 10 バージョン1803以前でも何らかの理由で「既定のスイッチ」が再作成されることはあるようですが、通常は一度作成されたら変わりません。そして「DNS Server Forward Rule - TCP - 仮想スイッチのポートのGUID - 0」と「DNS Server Forward Rule - UDP - 仮想スイッチのポートのGUID - 0」の「受信の規則」のペアが1つだけ存在します（再作成されたことがない場合）。

　Windows 10 バージョン1809になって「Default Switch」のサブネットがコロコロ変わるからといって、NAT機能が利用できなくなるわけではないのであまり問題視していませんでした。もしかしたら、意図的に変更された新たな仕様なのかもしれないとも思いました。

　しかし、「受信の規則」の肥大化は無視できません。Windows 10 バージョン1809の「Default Switch」の仮想スイッチとポートはPCの起動ごとに作成されてポートのGUIDが変わるため、「DNS Server Forward Rule -TCP」と「DNS Server Forward Rule - UDP」の規則のペアがそのたびに増えていくというわけです。

　試しに、「DNS Server Forward Rule -TCP」と「DNS Server Forward Rule - UDP」の規則を全て削除し、「Default Switch」に接続された仮想マシンにどう影響するのかを確認してみました。

　規則が存在する場合、仮想マシンからの名前解決は正常に行えますが、規則を削除すると仮想マシンからの名前解決要求はタイムアウトしてしまいます（画面4、画面5）。そしてHyper-Vを実行するPCを再起動すれば新しい規則が作成されるので、再び仮想マシンで名前解決ができるようになります。

画面4　「DNS Server Forward Rule -TCP」と「DNS Server Forward Rule - UDP」の規則は「Default Switch」に接続された仮想マシンからの名前解決を可能にしている

画面5　「DNS Server Forward Rule -TCP」と「DNS Server Forward Rule - UDP」の規則を削除すると、仮想マシンからの名前解決の要求はタイムアウト

　なお、仮想マシンからの名前解決のために、「受信の規則」の名称に含まれるポートのGUIDが一致する規則である必要はないようです。過去に作成された規則のペアでも、マニュアルで作成したTCPおよびUDPポート53への許可規則でも名前解決は可能でした。また、Windows 10の「Docker Desktop for Windows」やWindows Server 2019の「Docker Enterprise」のコンテナ用スイッチ「nat」を使用するコンテナの名前解決には、これらの規則の有無は影響しません。

　Windows 10 バージョン1809には長期サービスチャネル（Windows 10 Enterprise LTSC 2019）がありますし、同じく、長期サービスチャネルのWindows Server 2019のDocker Enterpriseでも発生するので、このまま長期運用していくと規則の数がオーバーフローしてしまうのではないかと心配です。

　当面の回避策としては、次のようなコマンドラインを記述したWindows PowerShellスクリプト「CleanupDNSServerForwardRules.ps1」を作成し、コンピュータ起動時に「タスクスケジューラ」で自動実行するようにしておけば、常にカスタムで作成した1ペアだけを残すことができるでしょう（画面6）。

Remove-NetFirewallRule -Name "DNS Server Forward Rule - *"
New-NetFirewallRule -Name "DNS Server Forward Rule - TCP - Custom" -DisplayName "DNS Server Forward Rule - TCP - Custom" -Direction Inbound -Protocol TCP -LocalPort 53 -Action allow
New-NetFirewallRule -Name "DNS Server Forward Rule - UDP - Custom" -DisplayName "DNS Server Forward Rule - UDP - Custom" -Direction Inbound -Protocol UDP -LocalPort 53 -Action allow

画面6　増加し続ける受信の規則の問題に対処するために、自動的にクリーンアップするようにスクリプトを仕込んでおく

　ちなみに、Windows 10の次のバージョン（バージョン1903、19H1）のInsider Previewビルド（18323.1000）で確認してみたところ、「HNS Container Networking - ICS DNS（TCP-In）- XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - 0」と「HNS Container Networking - DNS（UDP-In）- XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX - 0」という名前のペアで、同様の現象が発生していました。

　名前が変更されてしまうと、この回避策は無意味になってしまいます。たまに「セキュリティが強化されたWindows Defenderファイアウォール」を開いて確認し、受信の規則から1つのペアだけを残して削除してしまう方が簡単かもしれません。

UWPアプリ由来の受信／送信の規則も気になる

　「セキュリティが強化されたWindows Defenderファイアウォール」の規則を眺めていると、他にも規則を肥大化しているものに気が付きました。ストアアプリ（UWPアプリ）に由来する規則です。規則の名前は、アプリそのものの（または連想させる）名称だったり、「@{Microsoft.……}」だったりします（画面7）。

画面7　ストアアプリ（UWPアプリ）由来の規則が、「受信の規則」と「送信の規則」に大量に存在。不要と分かるものは削除してよいだろう（自己責任で）

　このような規則は、アプリのインストール時や要求時に自動作成されるようです。「Candy Crush Soda Saga」や「Xbox」アプリなど、一度も触ったことがないアプリについても規則が存在し、有効になっていたりします。本当に必要な規則なのかどうか分かりませんが、Windows 10の以前のバージョンから残っている無駄なものもあるようです。

　規則の肥大化は、パフォーマンスに影響するかもしれないので、たまに見直して、不要なものはクリーンアップするとよいかもしれません。筆者の場合、アプリを頻繁に使わないPCだったので、ごっそり削除してしまいました。皆さんは、慎重に吟味した上で、不要であると確実に分かるものだけ削除すればよいでしょう。