UVM WSH configuration seems wrong, leading to services unaccessible in Hyper-V isolation mode

Open
#613 11 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
docker
Domain
infrastructure, networking, operating-systems

Research direction

Start by reproducing the Hyper-V-isolated Windows Server container case with pktmon and netsh wfp show filters, then compare the WSH rule's %SystemRoot% expansion with the svchost.exe path in wfpdiag.xml. Use the RestrictedServices registry paths and the reported SYSTEM-hive workaround as references; done means EventLog is reachable from the host without that patch.

Written by the indexing model from the issue text.

Description

Hi everyone !

I have been troubleshooting why some services of a windows container (windows server image) aren't reachable from the host when the container is running in Hyper-V isolation mode, most notably the EventLog which is not reachable from the network. (This can be verified pretty quickly by running pktmon in the UVM, which shows the 'Syn' packets getting dropped).

My analysis

When running in Hyper-V isolation mode, I believe that the firewall of the UVM has an invalid configuration of the Windows Services Hardening keys (https://learn.microsoft.com/en-us/windows/win32/api/netfw/nn-netfw-inetfwservicerestriction).

Here's the rule that's supposed to allow the running EventLog service to be reached (in the UVM):

reg query "HKLM\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System" /v "Eventlog Allow RPC over TCP"

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Static\System
    Eventlog Allow RPC over TCP    REG_SZ    V2.0|Action=Allow|Dir=In|LPort=RPC|Protocol=6|App=%SystemRoot%\system32\svchost.exe|Svc=EventLog|Name=Allow RPC/TCP traffic to EventLog|

Running netsh wfp show filters in the UVM shows that this was expanded to the following :

Extract from filters.xml 
<item>
	<filterKey>{d1bfb869-9a7b-41c4-9cfa-e0613617a8ed}</filterKey>
	<displayData>
		<name>Allow RPC/TCP traffic to EventLog</name>
		<description/>
	</displayData>
	<flags numItems="1">
		<item>FWPM_FILTER_FLAG_INDEXED</item>
	</flags>
	<providerKey>FWPM_PROVIDER_MPSSVC_WSH</providerKey>
	<providerData>
		<data>3700000000000000</data>
		<asString>7.......</asString>
	</providerData>
	<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
	<subLayerKey>FWPM_SUBLAYER_MPSSVC_WSH</subLayerKey>
	<weight>
		<type>FWP_EMPTY</type>
	</weight>
	<filterCondition numItems="4">
		<item>
			<fieldKey>FWPM_CONDITION_ALE_APP_ID</fieldKey>
			<matchType>FWP_MATCH_EQUAL</matchType>
			<conditionValue>
				<type>FWP_BYTE_BLOB_TYPE</type>
				<byteBlob>
					<data>5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650032005c00770069006e0064006f00770073005c00730079007300740065006d00330032005c0073007600630068006f00730074002e006500780065000000</data>
					<asString>\device\harddiskvolume2\windows\system32\svchost.exe</asString>
				</byteBlob>
			</conditionValue>
		</item>
		<item>
			<fieldKey>FWPM_CONDITION_ALE_USER_ID</fieldKey>
			<matchType>FWP_MATCH_EQUAL</matchType>
			<conditionValue>
				<type>FWP_SECURITY_DESCRIPTOR_TYPE</type>
				<sd>O:SYG:SYD:(A;;CCRC;;;S-1-5-80-880578595-1860270145-482643319-2788375705-1540778122)</sd>
			</conditionValue>
		</item>
		<item>
			<fieldKey>FWPM_CONDITION_IP_PROTOCOL</fieldKey>
			<matchType>FWP_MATCH_EQUAL</matchType>
			<conditionValue>
				<type>FWP_UINT8</type>
				<uint8>6</uint8>
			</conditionValue>
		</item>
		<item>
			<fieldKey>FWPM_CONDITION_ALE_SIO_FIREWALL_SYSTEM_PORT</fieldKey>
			<matchType>FWP_MATCH_EQUAL</matchType>
			<conditionValue>
				<type>FWP_UINT32</type>
				<uint32>1</uint32>
			</conditionValue>
		</item>
	</filterCondition>
	<action>
		<type>FWP_ACTION_PERMIT</type>
		<filterType/>
	</action>
	<rawContext>0</rawContext>
	<reserved/>
	<filterId>66495</filterId>
	<effectiveWeight>
		<type>FWP_UINT64</type>
		<uint64>1689691673853952</uint64>
	</effectiveWeight>
</item>

Note that the path is \device\harddiskvolume2\windows\system32\svchost.exe. However, a WFP capture trying to reach the EventLog port shows the following:

Extract from wfpdiag.xml 
<netEvent>
	<header>
		<timeStamp>2025-09-15T16:09:39.033Z</timeStamp>
		<flags numItems="9">
			<item>FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET</item>
			<item>FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET</item>
			<item>FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET</item>
			<item>FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET</item>
			<item>FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET</item>
			<item>FWPM_NET_EVENT_FLAG_APP_ID_SET</item>
			<item>FWPM_NET_EVENT_FLAG_USER_ID_SET</item>
			<item>FWPM_NET_EVENT_FLAG_IP_VERSION_SET</item>
			<item>FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET</item>
		</flags>
		<ipVersion>FWP_IP_VERSION_V4</ipVersion>
		<ipProtocol>6</ipProtocol>
		<localAddrV4>100.64.0.1</localAddrV4>
		<remoteAddrV4>100.64.0.254</remoteAddrV4>
		<localPort>49154</localPort>
		<remotePort>59438</remotePort>
		<scopeId>0</scopeId>
		<appId>
			<data>5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650034005c00770069006e0064006f00770073005c00730079007300740065006d00330032005c0073007600630068006f00730074002e006500780065000000</data>
			<asString>\.d.e.v.i.c.e.\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.4.\.w.i.n.d.o.w.s.\.s.y.s.t.e.m.3.2.\.s.v.c.h.o.s.t...e.x.e...</asString>
		</appId>
		<userId>S-1-5-19</userId>
		<addressFamily>FWP_AF_INET</addressFamily>
		<packageSid>S-1-0-0</packageSid>
		<enterpriseId/>
		<policyFlags>0</policyFlags>
		<effectiveName/>
	</header>
	<type>FWPM_NET_EVENT_TYPE_PUBLIC_CLASSIFY_DROP</type>
	<classifyDrop>
		<filterId>66518</filterId>
		<layerId>44</layerId>
		<reauthReason>0</reauthReason>
		<originalProfile>0</originalProfile>
		<currentProfile>0</currentProfile>
		<msFwpDirection>MS_FWP_DIRECTION_IN</msFwpDirection>
		<isLoopback>false</isLoopback>
		<vSwitchId/>
		<vSwitchSourcePort>0</vSwitchSourcePort>
		<vSwitchDestinationPort>0</vSwitchDestinationPort>
	</classifyDrop>
	<internalFields>
		<internalFlags numItems="2">
			<item>FWPM_NET_EVENT_INTERNAL_FLAG_FILTER_ORIGIN_SET</item>
			<item>00000008</item>
		</internalFlags>
		<capabilities/>
		<fqbnVersion>0</fqbnVersion>
		<fqbnName/>
		<terminatingFiltersInfo numItems="3">
			<item>
				<filterId>66549</filterId>
				<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_QUARANTINE</subLayer>
				<actionType>FWP_ACTION_PERMIT</actionType>
			</item>
			<item>
				<filterId>66518</filterId>
				<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_WSH</subLayer>
				<actionType>FWP_ACTION_BLOCK</actionType>
			</item>
			<item>
				<filterId>66532</filterId>
				<subLayer>FWPP_SUBLAYER_INTERNAL_FIREWALL_WF</subLayer>
				<actionType>FWP_ACTION_PERMIT</actionType>
			</item>
		</terminatingFiltersInfo>
		<filterOrigin>WSH Default</filterOrigin>
		<interfaceLuid>1689399632855040</interfaceLuid>
		<policyAppId/>
		<compartmentId>2</compartmentId>
		<processId>1532</processId>
		<serviceSids>S-1-5-80-2078495744-2416903469-4072184685-3943858305-976987417,S-1-5-80-2940520708-3855866260-481812779-327648279-1710889582,S-1-5-80-880578595-1860270145-482643319-2788375705-1540778122,S-1-5-80-172094073-716411664-54255058-185476446-2329512179,S-1-5-80-2381253463-2694003897-3435975801-3559003598-683041300,S-1-5-80-410965207-2550896871-1717734767-2321332215-3755966139,S-1-5-80-3557709225-3446934100-2592608561-3401846376-4273827271,S-1-5-80-3098585136-2538892366-1097114017-2832417424-2016953023</serviceSids>
	</internalFields>
</netEvent>

The packet is dropped by the "WSH Default" WSH rule (documented here), which means the rule I mentionned earlier doesn't seem to have matched (which looks like a bug to me). I suspect that it's because the binary that received the packet was seen as \device\harddiskvolume4\windows\system32\svchost.exe (!= \device\harddiskvolume2\windows\system32\svchost.exe).

This looks like a bug caused by the expansion of %SystemRoot% in a wrong place :/ I would really appreciate if anyone could confirm that this analysis sounds sane.

Current workaround

I currently patch the SYSTEM hive of the UVM with the following:

HKLM\SYSTEM\ControlSet001\Services\SharedAccess\Parameters\FirewallPolicy\RestrictedServices\Configurable\System
Image

This is super hacky but at least it works (EventLog is properly reachable from outside the container).

All in all, this feels like something that might want to be fixed. Thanks a lot for the incredible work and any help. Cheers

Additional informations

  • Edition: Windows 11
  • Base Image being used: Windows Server
  • Container engine: docker
Dominant language
PowerShell
Stars
551
Forks
76
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/Windows-Containers

All issues in microsoft/Windows-Containers

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.