1

Initial question

Today, I'm stuck with a Windows Firewall problem and I hope you can help me. I'm trying to create rules dedicated to services but I can't make them match. I found some related topics still unanswered but they are quite old so I try ma luck here.

What I want to do:

  • Filter all outgoing traffic ("block all" by default)
  • Allow all programs to connect to some remote ports, like DNS and DHCP
  • Allow only some programs to connect to the network, like Web browsers
  • Allow only some services to connect to the network: "Windows Update service" and "Delivery Optimization Service"

Details about the situation:

  • I am running Windows 10 x64 22H2 + latest updates
  • "Windows Update" and "Delivery Optimization Service" are services in the form of .dll files (hosted by the well known svchost.exe)
  • All services I want to filter are already "unrestricted" (this means they have their own SID in the form S-1-5-80-xxx and are identifiable by firewall rules)
  • Every svchost-dependant service is the only one hosted per svchost.exe instance (no more than 1 service per instance of svchost.exe)

What I did:

  • I configured Windows firewall to "block all outgoing connection except if a rule explicitly allows it" for the 3 profiles (public + private + domain)
  • I created 2 firewall rules to allow outgoing traffic for services "Windows Update" and "Delivery Optimization Service" (either by selecting the service in the list or by entering the service short name)
  • All rules I created are configured for 3 profiles (public + private + domain)
  • I've defined my connections as private (command Set-NetConnectionProfile using PowerShell)

What I noticed, initial attempt:

At this time, my Web browsers perfectly worked (DNS was OK, HTTP and HTTPS were OK). But Windows Update was unable to connect to the Internet (even when stopping then restarting the service).

According to Windows Firewall logs and audit logs, the blocking rule is the default behavior of firewall. I saw connections to remote IP on port tcp/443 rejected. Log details showed process with command lines and process id for every block operation. I can confirm they were the expected process (parameter after -s in svchost.exe command line).

According to the security token of associated process, I could find a service SID in the form S-1-5-80-xxx corresponding to the expected service (ProcessExplorer and SystemInformer gave me the information).

All these findings suggest that the rules that are supposed to identify allowed services didn't match. <- HERE IS MY PROBLEM

What I noticed, new attempt:

Then I tried this solution but didn't work: https://superuser.com/a/1812889/1458121

What I noticed, another new attempt

Then I disabled all rules related to services and created another one allowing svchost.exe to connect to the Internet. Magically, Windows Update could fetch some updates and download them.

Since svchost.exe can host many services I don't want to reach the Internet, this option is not acceptable for me.

And now the questions:

What am I doing wrong and how can I achieve my goal?

Thanks for helping me.


More information related to asked questions (2023-12-08)

First of all, thanks for your help.

Have you already read through learn.microsoft.com/en-us/windows/security/… ?

Yes, sure. Especially section related to "outbound program or service rule". I noticed that details about service identification are only written in "inbound program or service rule". But since the same dialog box is used to select service for both inbound and outbound, I still think it doesn't matter.

Did you define both the program svchost.exe and the service shortname wuauserv in the same rule?

Yes but this didn't change anything.

Does the service look correct if you run Get-NetFirewallRule -DisplayName 'YourRuleName' | Get-NetFirewallServiceFilter?

Yes but only for rule based on service name. Please find my outputs:

PS C:\Windows\system32> Get-NetFirewallRule -DisplayName 'Windows Update Service (tcp) - by service SID' | Get-NetFirewallServiceFilter
Service : Any

PS C:\Windows\system32> Get-NetFirewallRule -DisplayName 'Windows Update Service (tcp) - by service name' | Get-NetFirewallServiceFilter
Service : wuauserv

PS C:\Windows\system32> Get-NetFirewallRule -DisplayName 'Delivery Optimization Service (tcp) - by service SID' | Get-NetFirewallServiceFilter
Service : Any

PS C:\Windows\system32> Get-NetFirewallRule -DisplayName 'Delivery Optimization Service (tcp) - by service name' | Get-NetFirewallServiceFilter
Service : DoSvc

Blocking all outgoing traffic is a very bad idea.

Yes and no, it depends on the final user. For "the man in the street", you're absolutely right because she/he doesn't master computers and just wants it works. But for people that (nearly) fully understand their Windows Operating System and basic security principles, this is just hardening.


More information related to asked questions (2023-12-10)

Can you add some example firewall log entries?

Sure! And a bit more than only logs. Here is my method of gathering information:

  1. I ran this command to enable auditing connections that are allowed or blocked by WFP: auditpol.exe /set /subcategory:"{0CCE9226-69AE-11D9-BED3-505054503030}" /success:enable /failure:enable.
  2. I cleared the "Security" event log (all logs).
  3. I started Windows Update from Settings panel and wait for the error (it appears very quickly).
  4. I got some logs like this one:
The Windows Filtering Platform has blocked a connection.

Application Information:
    Process ID:     7472
    Application Name:   \device\harddiskvolume3\windows\system32\svchost.exe

Network Information:
    Direction:      Outbound
    Source Address:     192.168.0.249
    Source Port:        63344
    Destination Address:    20.114.59.183
    Destination Port:       443
    Protocol:       6

Filter Information:
    Filter Run-Time ID: 85352
    Layer Name:     Connect
    Layer Run-Time ID:  48

Now, to easily deal with all logs, I wrote a PowerShell script that read these logs, and according to the Process ID, enriched logs with details of currently running processes (process command line, process location, short name of service if any, long name of service if any). I can give the script if anyone wants.

The most important part is here:

$ProcessWMI = Get-CimInstance -ClassName Win32_Process -Filter "ProcessId = $ProcessId" -ErrorAction Stop | Select-Object -Property CommandLine
$ProcessPWSH = Get-Process -Id $ProcessId -ErrorAction Stop | Select-Object -Property Path, Description
$ServiceWMI = Get-CimInstance -ClassName Win32_Service -Filter "ProcessId = $ProcessId" -ErrorAction Stop | Select-Object -Property Name, DisplayName, PathName

After that, I sent svchost.exe logs to a CSV file. Here it is:

#TYPE Selected.System.Diagnostics.EventLogEntry
"Index","TimeGenerated","EventID","Decision","Direction","Proto","SrcAddr","SrcPort","DstAddr","DstPort","Operation","ProcId","ProcPath","ProcCmdLine","SvcName","SvcDisplay"
"209565","2023-12-10 10:32:50 PM","5156","Allow","Out","UDP","192.168.0.249","57462","192.168.0.254","53","Connect","3480","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k NetworkService -p -s Dnscache","Dnscache","DNS Client"
"209577","2023-12-10 10:32:50 PM","5157","Block","Out","TCP","192.168.0.249","63319","40.126.32.76","443","Connect","12768","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wlidsvc","wlidsvc","Microsoft Account Sign-in Assistant"
"209575","2023-12-10 10:32:50 PM","5157","Block","Out","TCP","192.168.0.249","63318","40.126.32.136","443","Connect","12768","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wlidsvc","wlidsvc","Microsoft Account Sign-in Assistant"
"209573","2023-12-10 10:32:50 PM","5157","Block","Out","TCP","192.168.0.249","63317","20.190.160.22","443","Connect","12768","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wlidsvc","wlidsvc","Microsoft Account Sign-in Assistant"
"209571","2023-12-10 10:32:50 PM","5157","Block","Out","TCP","192.168.0.249","63316","40.126.32.134","443","Connect","12768","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wlidsvc","wlidsvc","Microsoft Account Sign-in Assistant"
"209569","2023-12-10 10:32:50 PM","5157","Block","Out","TCP","192.168.0.249","63315","40.126.32.138","443","Connect","12768","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wlidsvc","wlidsvc","Microsoft Account Sign-in Assistant"
"209567","2023-12-10 10:32:50 PM","5157","Block","Out","TCP","192.168.0.249","63314","40.126.32.68","443","Connect","12768","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wlidsvc","wlidsvc","Microsoft Account Sign-in Assistant"
"209643","2023-12-10 10:32:51 PM","5157","Block","Out","TCP","192.168.0.249","63342","20.114.59.183","443","Connect","7472","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wuauserv","wuauserv","Windows Update"
"209653","2023-12-10 10:32:51 PM","5157","Block","Out","TCP","192.168.0.249","63347","20.114.59.183","443","Connect","7472","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wuauserv","wuauserv","Windows Update"
"209651","2023-12-10 10:32:51 PM","5157","Block","Out","TCP","192.168.0.249","63346","20.114.59.183","443","Connect","7472","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wuauserv","wuauserv","Windows Update"
"209649","2023-12-10 10:32:51 PM","5157","Block","Out","TCP","192.168.0.249","63345","20.114.59.183","443","Connect","7472","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wuauserv","wuauserv","Windows Update"
"209647","2023-12-10 10:32:51 PM","5157","Block","Out","TCP","192.168.0.249","63344","20.114.59.183","443","Connect","7472","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wuauserv","wuauserv","Windows Update"
"209645","2023-12-10 10:32:51 PM","5157","Block","Out","TCP","192.168.0.249","63343","20.114.59.183","443","Connect","7472","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wuauserv","wuauserv","Windows Update"
"209668","2023-12-10 10:32:51 PM","5157","Block","Out","TCP","192.168.0.249","63354","20.114.59.183","443","Connect","7472","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wuauserv","wuauserv","Windows Update"
"209670","2023-12-10 10:32:51 PM","5157","Block","Out","TCP","192.168.0.249","63355","20.114.59.183","443","Connect","7472","C:\Windows\system32\svchost.exe","C:\Windows\system32\svchost.exe -k netsvcs -p -s wuauserv","wuauserv","Windows Update"

Useful to know:

  • 192.168.0.249 is the IPv4 of the computer I ran the tests on
  • 192.168.0.254 is the IPv4 of the nearest router (and it is also a DNS server)

What I noticed:

  1. svchost.exe (service "DnsCache") performs a DNS query. It is allowed because of a firewall rule that only uses the target port and the protocol.
  2. svchost.exe (service "Microsoft Account Sign-in Assistant") attempts TCP connections to some 40.x.x.x IPv4. They are rejected because no firewall allows them.
  3. svchost.exe (service "Windows Update") attempts some TCP connections to 20.114.59.183 IPv4 (Microsoft servers, see https://who.is/whois-ip/ip-address/20.114.59.183). They are rejected but I think they should be allowed according to the firewall rules targeting "wuauserv" service.

NOTE: If you want more details like screen captures or script sharing, I'll create and share a .zip file containing all the stuffs.

And now the .log file generated by Windows Firewall (please note this is another run because I forgot yesterday to show this file):

#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2023-12-11 21:29:56 DROP UDP 192.168.0.254 224.0.0.251 5353 5353 141 - - - - - - - RECEIVE
2023-12-11 21:29:56 DROP UDP 192.168.0.250 224.0.0.251 5353 5353 179 - - - - - - - RECEIVE
2023-12-11 21:30:04 ALLOW UDP 192.168.0.249 192.168.0.254 62986 53 0 - - - - - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 40.127.240.158 59536 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.23 59537 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.64 59538 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 ALLOW UDP 192.168.0.249 192.168.0.254 51123 53 0 - - - - - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.0 59539 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.73 59540 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 40.126.31.73 59541 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 40.126.31.67 59542 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 40.127.240.158 59543 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.68 59544 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.64 59545 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.75 59546 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.4 59547 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.0 59548 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.73 59549 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 40.127.240.158 59550 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 40.126.31.73 59551 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 40.126.31.67 59552 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.68 59553 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.64 59554 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.75 59555 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 20.190.159.4 59556 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:04 DROP TCP 192.168.0.249 40.127.240.158 59557 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.0 59558 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.73 59559 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.126.31.73 59560 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.126.31.67 59561 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.68 59562 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.64 59563 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.127.240.158 59564 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.75 59565 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.4 59566 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.0 59567 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.73 59568 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.126.31.73 59569 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.126.31.67 59570 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.127.240.158 59571 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.12.23.50 59572 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.12.23.50 59573 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.12.23.50 59574 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.68 59575 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.64 59576 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.75 59577 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.4 59578 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.0 59579 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.73 59580 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.12.23.50 59581 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.12.23.50 59582 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.12.23.50 59583 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.12.23.50 59585 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.127.240.158 59584 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.12.23.50 59586 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.126.31.73 59587 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 40.126.31.67 59588 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.68 59589 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.64 59590 443 0 - 0 0 0 - - - SEND
2023-12-11 21:30:05 DROP TCP 192.168.0.249 20.190.159.75 59591 443 0 - 0 0 0 - - - SEND

Thanks again for the help.

5
  • 1
    Have you already read through learn.microsoft.com/en-us/windows/security/… ? Did you define both the program svchost.exe and the service shortname wuauserv in the same rule? Does the service look correct if you run Get-NetFirewallRule -DisplayName 'YourRuleName' | Get-NetFirewallServiceFilter?
    – Cpt.Whale
    Commented Dec 6, 2023 at 0:17
  • 1
    Blocking all outgoing traffic is a very bad idea.
    – harrymc
    Commented Dec 6, 2023 at 21:22
  • @Cpt.Whale, I've added some details in the post.
    – shadowpool
    Commented Dec 7, 2023 at 21:53
  • Can you add some example firewall log entries?
    – Cpt.Whale
    Commented Dec 7, 2023 at 23:37
  • @Cpt.Whale, I've added some details in the post.
    – shadowpool
    Commented Dec 10, 2023 at 22:04

1 Answer 1

1

According to the thread here, this behavior happens because windows update uses threadpools for the connections, and those threads don't get tied back to the wuauserv service in a way that the windows firewall understands.

As an (untested!) workaround, you could try something like:

  1. Make a copy of svchost.exe, like svchost_wuauserv.exe
  2. Update the ImagePath for the service in HKLM\SYSTEM\CurrentControlSet\Services\
  3. Allow the new svchost_wuauserv.exe through the firewall

It should work in most cases, but be aware that anything hard-coded to svchost.exe like antivirus exclusions might get broken, and windows repair tools like SFC may reset those changes.


Another option is to point windows update to a specific endpoint like WSUS, and simply allow outbound traffic to that IP address.

1
  • OK, so this could be a matter of service tags. Please let me some time to perform deeper tests. I'll try to force those service tags in thread pool threads and confirm the Windows Firewall uses this data.
    – shadowpool
    Commented Dec 12, 2023 at 21:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .