Windows 11を特定用途のEdge PCとして運用していると、
このPC、本当にこんなに通信する必要があるのか？
と思うことがあります。
Windows 11には標準状態でも、
- Network Discovery
- Remote Assistance
- Wi-Fi Direct
- Wireless Display
- Media Streaming
- mDNS
- UPnP / SSDP
- Teams
- Xbox
- Hyper-V
- Connected Devices Platform
など、一般的なPCとして便利に使うための機能やFirewall Ruleが多数存在します。
しかし、
接続機器
↓
Edge PC
↓
Cloud
という用途に限定された端末では、そのすべてが必要とは限りません。
今回は、Windows 11 Proを搭載したEdge PCで、
業務上必要な通信は残し、使用しないWindows標準機能の通信を減らす
という方針でWindows Defender Firewallを整理した事例をまとめます。
結論：Firewall Ruleは「PCの役割」から逆算する
今回のEdge PCで必要だった主な通信は、次の2つです。
接続機器
↓
TCP 57545
↓
Edge PC
そして、
Edge PC
↓
TCP 443
↓
Cloud
整理すると次のようになります。
| 通信 | Direction | Port | 用途 |
|---|---|---|---|
| 接続機器 → Edge PC | Inbound | TCP 57545 | データ受信 |
| Edge PC → Cloud | Outbound | TCP 443 | Cloud通信 |
つまり、考え方としては、
必要な業務通信
↓
維持する
使用しないWindows機能
↓
Firewall Ruleを整理する
です。
重要なのは、
「不要そうなRuleを全部止める」ことではありません。
そのPCで何を動かすのかを先に決め、その役割からFirewallを逆算します。
Windows 11のFirewall Ruleを確認する
Windows Defender Firewallの詳細設定は、次の場所から確認できます。
Control Panel
↓
System and Security
↓
Windows Defender Firewall
↓
Advanced settings
ここには、
Inbound Rules
Outbound Rules
があります。
実際に確認すると、Windows 11にはかなり多くのRuleが存在します。
例えば、
Network Discovery
Remote Assistance
Wireless Display
Wi-Fi Direct
Windows Media Player
AllJoyn
Cast to Device
Connected Devices Platform
mDNS
Hyper-V
Xbox
Microsoft Teams
などです。
一般ユーザー向けPCでは便利でも、専用Edge PCでは使用しない機能があります。
そこで、
「このEdge PCで本当に使う機能か？」
を基準に一つずつ確認しました。
InboundとOutboundで設定方法を変えた
今回の構成では、InboundとOutboundで処理方法を分けました。
Inbound
不要な受信Ruleは、
Enabled
↓
Disabled
としました。
つまり、
使用しないInbound Ruleを無効化する
という方針です。
Firewall管理画面で対象Ruleを右クリックし、
Disable Rule
を選択します。
Outbound
Outbound側は、
RuleをEnabled
↓
Block the connection
としました。
つまり、
対象Ruleを有効にしたうえで、その通信を明示的にBlockする
という方法です。
整理すると、
| Direction | 今回の設定 |
|---|---|
| Inbound | 不要なRuleをDisabled |
| Outbound | RuleをEnabledにしてBlock |
という違いがあります。
Inboundで無効化した主なWindows機能
すべてのRule名を列挙すると非常に長くなるため、機能単位で整理します。
1. Network Discovery
例えば、
Network Discovery (LLMNR-UDP-In)
Network Discovery (NB-Datagram-In)
Network Discovery (NB-Name-In)
Network Discovery (SSDP-In)
Network Discovery (UPnP-In)
Network Discovery (WSD-In)
Network Discovery (WSD Events-In)
などです。
これらは主に、
PCやDeviceの探索
ネットワーク上のDevice発見
UPnP
SSDP
WSD
名前解決
などに関係します。
今回のEdge PCではLAN上の一般的なDevice Discoveryを必要としていないため、使用しないRuleを無効化しました。
2. Wi-Fi Direct / Wireless Display
例えば、
Wi-Fi Direct Network Discovery
Wi-Fi Direct Scan Service Use
Wi-Fi Direct Spooler Use
Wireless Display
Wireless Display Infrastructure Back Channel
WFD ASP Coordination Protocol
WFD Driver-only
などです。
今回のEdge PCでは、
無線ディスプレイ
Wi-Fi Direct
無線でのDevice探索
を使用しないため対象としました。
3. Cast to Device
WindowsにはCast to Device関連のRuleもあります。
例えば、
Cast to Device functionality (qWave-TCP-In)
Cast to Device functionality (qWave-UDP-In)
Cast to Device SSDP Discovery
Cast to Device streaming server
Cast to Device UPnP Events
などです。
これらは、
Media Device探索
Streaming
UPnP
などに関連します。
専用Edge PCでは使用しないため無効化しました。
4. Remote Assistance
例えば、
Remote Assistance (DCOM-In)
Remote Assistance (PNRP-In)
Remote Assistance (RA Server TCP-In)
Remote Assistance (SSDP TCP-In)
Remote Assistance (SSDP UDP-In)
Remote Assistance (TCP-In)
などがあります。
さらに、
Remote Desktop - Shadow (TCP-In)
なども確認しました。
Remote Assistanceを利用しない端末であれば、不要なRemote接続経路を残しておく必要はありません。
ただし、実際にRemote Desktopなどを運用している場合は止めてはいけません。
5. Hyper-V
Hyper-Vを使用しない端末では、
Hyper-V - WMI
Hyper-V MIG
Hyper-V REMOTE_DESKTOP
Hyper-V RPC
Hyper-V RPC-EPMAP
Hyper-V Management Clients
なども確認対象になります。
今回の端末ではHyper-Vを使用していなかったため整理しました。
6. mDNS / Connected Devices
例えば、
mDNS
Connected Devices Platform
Connected Devices Platform - Wi-Fi Direct Transport
Microsoft Edge mDNS
などです。
一般ユーザー向けPCでは便利ですが、
通信先が決まっている
用途が固定されている
Device Discoveryを使用しない
という端末では、必須とは限りません。
Application向けFirewall Ruleも確認する
Windows標準ApplicationにもInbound Ruleがあります。
例えば、
Microsoft Teams
App Installer
Desktop App Web Viewer
Feedback Hub
Game Bar
Microsoft Store
Microsoft To Do
Windows Camera
Windows Media Player
などです。
Edge PCが、
業務Applicationを起動する
↓
接続機器からDataを受信する
↓
Cloudへ送信する
ことだけを目的としているのであれば、Consumer向けApplicationを使用しない場合があります。
そのため、
Applicationを使っていないから終わり
ではなく、
そのApplication用のFirewall Ruleが残っていないか
も確認しました。
Outboundでは不要な通信をBlockする
Outbound側でも、同じように機能ごとに確認しました。
例えば、
LLMNR
NetBIOS
SSDP
UPnP
WSD
Wi-Fi Direct
Wireless Display
Remote Assistance
Windows Media Player
Media Streaming
などです。
さらにConsumer Applicationでは、
Teams
Microsoft Store
Microsoft To Do
Microsoft Photos
Microsoft Clipchamp
Feedback Hub
Game Bar
Get Help
Windows Camera
Widgets Platform Runtime
Windows Web Experience Pack
なども確認対象にしました。
使用しないと判断したOutbound Ruleについては、
Properties
↓
Enabled
↓
Block the connection
としています。
IPv6関連Ruleは特に注意する
今回の設定では、
DHCPv6
IPv6
ICMPv6
Neighbor Discovery
Router Advertisement
Router Solicitation
Multicast Listener
Teredo
IPHTTPS
などのIPv6関連Ruleも確認しました。
ただし、ここは特に注意が必要です。
IPv6関連Ruleは無効化した方がよい、という意味ではありません。
IPv6を利用している環境で安易に変更すると、
通信できない
名前解決に影響する
Network機能に影響する
といった問題が発生する可能性があります。
今回の環境では、
自分のシステムで使用しているか
↓
確認
↓
不要なものだけ変更
という判断をしています。
設定一覧だけをコピーして適用するのは避けた方がよいです。
Device Management関連をBlockするときも注意
Outboundには、
Windows Device Management Certificate Installer
Windows Device Management Device Enroller
Windows Device Management Enrollment Service
Windows Device Management Sync Client
などのRuleもあります。
これらは、
Intune
MDM
組織のDevice Management
を利用している場合に必要になる可能性があります。
したがって、
Rule名だけを見て不要と判断しない
ことが重要です。
Firewall Ruleを大量に変更するなら一覧管理する
Firewall Ruleを数個変更する程度ならGUIだけでも管理できます。
しかし数十個以上変更すると、
何を変更したのか
なぜ変更したのか
元の設定は何だったのか
が分からなくなります。
そのため今回は、
Rule Name
Direction
Current Status
変更後Status
Network Profile
用途
を一覧で管理しました。
例えば、
| Rule | Direction | 設定 |
|---|---|---|
| Network Discovery | Inbound | Disabled |
| Wireless Display | Inbound | Disabled |
| Remote Assistance | Inbound | Disabled |
| Network Discovery | Outbound | Block |
| Wireless Display | Outbound | Block |
| Media Streaming | Outbound | Block |
という形です。
特に量産・展開するEdge PCでは、
変更履歴と元に戻す方法を残しておく
ことが重要です。
Firewall変更後に確認すること
Firewall Ruleを変更できたからといって、作業完了ではありません。
最低限、
接続機器
↓
Edge PC
の通信を確認します。
今回であれば、
TCP 57545
です。
さらに、
Edge PC
↓
Cloud
側の、
TCP 443
も確認します。
ただしPortが開いていることだけでは不十分です。
最終的には、
接続機器
↓
Data送信
↓
Edge Application
↓
Data処理
↓
Cloud送信
↓
Cloud側でData到達を確認
まで実施します。
つまりFirewall変更後の判定基準は、
Ruleを変更できたかではなく、不要な通信を減らしても本来のシステム機能が維持されているか
です。
「全部止める」のではなく「端末の役割」を決める
今回一番重要だったのは、Firewall Ruleの名前を覚えることではありません。
最初に、
このEdge PCは何をするPCなのか？
を定義することでした。
今回必要なのは、
接続機器
↓
Edge PC
↓
Cloud
という通信です。
一方で、
Network Discovery
Media Streaming
Remote Assistance
Wi-Fi Direct
Wireless Display
Game関連
Consumer Application
などは、今回の端末の役割には含まれていません。
そのため、
Edge PCとして必要
↓
維持
Edge PCとして使用しない
↓
通信Ruleを整理
という方針にしました。
専用端末のFirewall設計では、
「何を止めるか」より先に「何を動かすPCなのか」を決める
のがポイントだと思います。
注意：この記事のRule一覧をそのまま適用しない
この記事で紹介した設定は、
Windows 11で一律に無効化・Blockすることを推奨するものではありません。
特に、
IPv6
Network Discovery
Remote Assistance
Device Management
Hyper-V
Wi-Fi Direct
mDNS
などは、環境によって必要になります。
実際に変更する場合は、
- PCの用途
- 必要なApplication
- 必要なNetwork通信
- IPv4 / IPv6構成
- Remote管理方法
- MDM / Device Managementの有無
- 元に戻す方法
を確認したうえで実施します。
また、変更後は検証環境で動作確認し、
本来必要な通信が維持されていること
を確認してから展開するのが安全です。
まとめ
今回のWindows 11 Edge PCでは、
接続機器 → Edge PC
TCP 57545
と、
Edge PC → Cloud
TCP 443
という必要通信を維持しながら、使用しないWindows標準機能のFirewall Ruleを整理しました。
考え方はシンプルです。
PCの役割を決める
↓
必要通信を洗い出す
↓
Windows標準Ruleを棚卸しする
↓
不要なInbound Ruleを無効化
↓
不要なOutbound通信をBlock
↓
実際の業務通信をEnd-to-Endで確認
Firewallを強くすること自体が目的ではなく、
必要な機能を維持したまま、不要な通信範囲を減らす
ことが目的です。
特に24時間365日動作するような専用Edge PCでは、一般ユーザー向けWindows PCとは違う視点でFirewall Ruleを確認する価値があります。
次回：病院ネットワークでAMQPが通らなかったので、AMQP over WebSocketへ変更した
Edge PC側のFirewallで必要な通信を許可していても、
Edge PC
↓
施設Network
↓
Cloud
という経路では、施設側のFirewallやNetwork Policyによって通信できない場合があります。
実際の運用では、Cloudへの通信に通常のAMQPを使用した際、
AMQP
↓
施設NetworkでBlock
となる環境がありました。
そこで、
AMQP
↓
AMQP over WebSocket
↓
TCP 443
へ通信方式を変更しました。
次回は、
「病院ネットワークでAMQPが通らない場合に、Azure IoT EdgeをAMQP over WebSocketへ変更した理由」
についてまとめます。
本記事は、実際のEdge PC運用・障害対応経験をもとに、機密情報に配慮して一部を一般化・匿名化しています。特定の組織・施設・製品・システムについて説明するものではありません。