Welcome
Welcome to vistafirewallcontrol

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today!

Secret Rules of Windows Firewall

Secret Rules of Windows Firewall

Postby NoelC » Fri Dec 16, 2016 5:12 pm

Quite a long while ago I reached the conclusion that the Windows Firewall service should be disabled when the Sphinx WxFC package is on the job. For me that works well.

Now I'm learning (thanks, PietO) that's a good idea for even more reasons. In this case, because of secret rules loaded into the Base Filtering Engine when the Windows Firewall service runs.

The only glitch with keeping the Windows Firewall off so far is that I have observed under some conditions that I am unable to complete a Windows 10 update without starting the Windows Firewall service - however briefly. Fortunately, I don't see this behavior with the systems I actually rely upon for my business - Windows 7 and 8.1. Windows Firewall is NEVER enabled on those systems any more.

Thing is, I don't want any secret firewall rules in force. That's why I'm using Sphinx WxFC.

The firewall is not a plaything for Microsoft to use to further its goals. It's a serious tool, on MY system, protecting MY data.

Who knows, maybe the system is just waiting to send a bunch of telemetry or maybe it's ready to let Microsoft load unauthorized updates in to do who knows what.

I'd like to further the discussion of secret rules here.

I did a little bit of legwork on my Windows 10 test system. Per PietO's suggestion, I explored the command:

netsh wfp show state

This provides an XML file containing information about what's currently active in the filtering subsystem. In fact, I ran it twice, once with the Windows Firewall Disabled and once with it Enabled. Lo and behold, on a system where I have deleted ALL overt rules listed in the Windows Advanced Firewall control snapin, just in comparing <name> directives I found the following added after the service was Enabled:

Allow all inbound TCP and RPC to SPPEXTCOMOBJ
Allow all outbound TCP and RPC from SPPEXTCOMOBJ
Allow Grouping to receive from port 3587
Allow Grouping to send to port 3587
Allow inbound RPC traffic to the Block Level Backup service (wbengine) over TCP
Allow inbound TCP port 389 traffic for vmicheartbeat
Allow inbound TCP port 636 traffic for vmicheartbeat
Allow inbound TCP traffic to AJRouter
Allow inbound traffic to SearchProtocolHost
Allow inbound UDP traffic to AJRouter
Allow inbound UDP traffic to SNMPTRAP service
Allow incoming RPC traffic to VDS
Allow incoming TCP to PeerDistSvc
Allow incoming WSD to PeerDistSvc
Allow NTP traffic from Wcmsvc
Allow Out http traffic from WinDefend
Allow outbound LDAP traffic from SearchIndexer
Allow outbound TCP traffic for vmicheartbeat
Allow outbound TCP traffic from AJRouter
Allow outbound traffic from SearchProtocolHost
Allow outbound UDP traffic from AJRouter
Allow outgoing TCP from PeerDistSvc
Allow outgoing WSD from PeerDistSvc
Allow PNRP to receive from port 3540
Allow PNRP to send from port 3540
Allow PNRP to send to port 3540
Allow RPC/TCP traffic to EventLog
Allow SSL Out traffic from WinDefend
Allow TCP traffic from Wcmsvc
AppContainerLoopback
AxInstSV TCP outbound allow
Block all inbound traffic to SearchFilterHost
Block all outbound traffic from SearchFilterHost
Block Inbound Default Rule
Block Outbound Default Rule
Cast to Device streaming server hardening - Block incoming TCP traffic
Cast to Device streaming server hardening rules for RTSP
Device Metadata Retrieval
DhcpFirewallPolicy
Interface Binding Callout
InternetClient Default Rule
InternetClientServer Inbound Default Rule
InternetClientServer Outbound Default Rule
IPsec Policy Agent service hardening - LDAP/TCP
IPsec Policy Agent service hardening - LDAP/UDP
IPsec Policy Agent service hardening - Remote Management
Modern Network Isolation Diagnostics Bfe Session
NetBIOSHelperFirewallPolicy
State Management Provider Context
TermServiceLOM
Wi-Fi Direct ASP Coordination Protocol (UDP-In)
Wi-Fi Direct ASP Coordination Protocol (UDP-Out)
Windows Firewall Dynamic Session
Windows Firewall: callout
Windows Media Player Network Sharing Service service hardening - Block any other incoming TCP traffic
Windows Media Player Network Sharing Service service hardening - RTSP
WSH Default Inbound Block
WSH Default Outbound Block


Seems like an awful lot of stuff to be adding to someone's firewall without their knowledge, eh?

It would appear I need to discover what it is that needs to be done so that the Windows Firewall service never needs to be enabled/started again on any system.

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Secret Rules of Windows Firewall

Postby VistaFirewallControl » Fri Dec 16, 2016 6:47 pm

>Who knows, maybe the system is just waiting to send a bunch of telemetry or maybe it's ready to let Microsoft load unauthorized updates in to do who knows what.

W10FC priority is higher.
So disabling by W10FC is final in spite of WF rules (if any)

>netsh wfp show state
This provides an XML file containing information about what's currently active in the filtering subsystem.

Not sure the list you have provided is complete though.
It’s just WF rules, not all the rule in BFE.
We can send you our internal rules dumper to compare the result if you would like.
(the dumper can be sent on private basis only, so please contact by e-mail, if you do need the dumper.)

>Seems like an awful lot of stuff to be adding to someone's firewall without their knowledge, eh?

There may be some persistent rules in BFE as well.
Most probably they are meaningless as the WxFC priority is higher and WxFC blocking is final
(following the official BFE arbitration manual at least)


>It would appear I need to discover what it is that needs to be done so that the Windows Firewall service never needs to be enabled/started again on any system.

The common sense suggests that all persistent rules should be mentioned in the registry somewhere. So deleting (with backup-ing just in case) those keys could limit the number of “predefined” rules significantly.

Also there are no evidences that WindowsUpdate requires only rules of WF and WF itself can be switched off easily. The relationship may be more complex. It’s rather a subject of experiments.
And, sorry, once more, W10FC priority is higher anyway.
VistaFirewallControl
Site Admin
 
Posts: 1479
Joined: Fri Mar 27, 2009 11:25 am

Re: Secret Rules of Windows Firewall

Postby PietO » Sat Dec 17, 2016 11:16 am

NoelC wrote: Lo and behold, on a system where I have deleted ALL overt rules listed in the Windows Advanced Firewall control snapin, just in comparing <name> directives I found the following added after the service was Enabled:

Seems like an awful lot of stuff to be adding to someone's firewall without their knowledge, eh?

If you would have tried the WindowsFirewallNotifier (see previous thread) you would have seen exactly these hidden WF rules! Thus exactly these rules could possibly impact the Windows-update behaviour when enabling/disabling WFservice but . . . . according to the moderator: blocked by WxFC = blocked.

Will check what happens deleting all predefined BFE-rules. As far as i remember, i did modify / delete these BFE-rules early 2014 on Win7 (also checking with the dump-utility of Sphinx), but they were recreated in the registry by . . . ??

Edit: checking Win10 gives the result that also persistant BFE-rules are recreated but not all: after restart 4 filters are initially recreated from the 22 "predefined".
The investigation in 2014 was about "Interface Un-quarantine filter" filterrules belong to layer FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4 / FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V6. This filtering layer allows for authorizing accept requests for incoming TCP connections, as well as authorizing incoming non-TCP traffic based on the first packet received. It relates to traffic encapsulated in tunnels: Win7 filter key {b02a4013-b6b5-4859-9168-1e3299e43b24}. Exactly this BFE filterrule is -at least initially- not recreated in Win10 when deleted. Impact on system / WxFC behavior missing these 18 rules is unknown to me; any check on practical impact will be very limited in my environment.
PietO
 
Posts: 192
Joined: Wed Mar 02, 2011 12:09 pm

Re: Secret Rules of Windows Firewall

Postby NoelC » Sat Dec 17, 2016 6:49 pm

VistaFirewallControl wrote:W10FC priority is higher.
So disabling by W10FC is final in spite of WF rules (if any)

I suspected as much, and it's comforting to hear it confirmed. So the mystery remains why my Win 10 system seems to be allowed to contact all update servers, but somehow never completes the update check unless the Windows Firewall is started. If I hadn't heard of others being able to complete a check, I'd have been pretty convinced it's an issue where the update code just doesn't have proper error recovery from finding the Windows Firewall service not in a running or startable state.

I am dealing with some difficult technical issues with my own products (unrelated to the firewall) at the moment and have limited additional mental capacity to spend on this (not to mention the distracting nature of the holiday season), but I hope to get back to where I can further this conversation soon. I do appreciate all the conversation.

PietO, I wasn't able to find time or energy to bring in WindowsFirewallNotifier for the above reasons. I don't mean to ignore your suggestions. Your input is helpful and very much appreciated.

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Secret Rules of Windows Firewall

Postby PietO » Sat Dec 17, 2016 9:32 pm

Just for comparision and fun: after WFservice was disabled and all BFEpersistant filters were deleted, i checked normal TCP and UDP traffic and that was fine (svchost / system / browser)

Than checked the actual, active filterrules present with "Netsh WFP Show Filters verbose=on" in Windows 10; strange that i could not find many rules back that were populated in W10FC but the 4 remaining persistant BFE rules were in the report:
{9248d57e-f843-4159-807d-3813173e2096} NIS ALE Flow Established V4 Filter (BFE persistent rule from registry)
{4658cd86-525d-44ed-98a5-791a7b8655f1} NIS ALE Flow Established V6 Filter (BFE persistant rule from registry)
{56b4fdc4-bb4e-4c42-a9d8-f627ee15ac21} NIS Stream V4 Filter (BFE persistant rule from registry)
{1ba41ed8-151d-4577-9272-317856bc637c} NIS Stream V6 Filter (BFE persistant rule from registry)

Than 2 rules that are "hidden" but do not belong to the Basic Windows system (not in registry)
{1b7cf0ee-4936-466c-be51-1be0aee7fdbe} Windows10FirewallControl UDP Filter port
{9385d5a3-5455-468c-9e59-bbd75af5392b} Windows10FirewallControl TCP Filter port

and filterrules that do not directly relate to connectivity:
{8e44982c-f477-11df-85ce-78e7d1810190} NDU Flow Established V4 SubLayer Filter
{8e44982e-f477-11df-85ce-78e7d1810190} NDU Flow Established V6 SubLayer Filter
{8e449830-f477-11df-85ce-78e7d1810190} NDU Inbound Transport SubLayer Filter
{8e449834-f477-11df-85ce-78e7d1810190} NDU Outbound Transport SubLayer Filter
{8e449838-f477-11df-85ce-78e7d1810190} NDU Inbound Mac Frame Native SubLayer Filter
{8e44983a-f477-11df-85ce-78e7d1810190} NDU Outbound Mac Frame Native SubLayer Filter

Above seems to be a really minimal set of "hidden" rules without any overhead, but functionality is garanteed. I will leave the testsystem with above and wait for problems.

NoelC: no problem; i'm just in the lucky situation that time is a special problem: a mechanical watch that to keeps the time for me , is waiting to be repaired . . . ..
PietO
 
Posts: 192
Joined: Wed Mar 02, 2011 12:09 pm

Re: Secret Rules of Windows Firewall

Postby NoelC » Mon Dec 19, 2016 10:56 pm

PietO wrote:Just for comparision and fun:

I'm still feeling overwhelmed by all the details, but it seems like we should be able to begin to derive Microsoft's intent from the progression of "secret default" rules from OS release to OS release... Here's what I've learned so far. Similar to your list, these are just lists of rule names from the Windows Filtering Platform to me at this point; I need to interpret what they mean/do in more detail to begin to get some understanding...

Windows 8.1, after the Sphinx firewall is stopped and WITHOUT the Windows Firewall service running:

    WFP Built-in Edge Traversal Sublayer
    • ET Allow All
    • ET Bind callout
    • ET Default Block All
    • ET ICMPV6 Destination Unreachable - Permit
    • ET ICMPV6 NA - Permit
    • ET ICMPV6 NS - Permit
    • ET ICMPV6 Packet Too Big - Permit
    • ET ICMPV6 Parameter Problem - Permit
    • ET ICMPV6 Time Exceeded - Permit
    • ET Listen Callout
    WFP Built-in Inspection Sublayer
    • NDU Flow Established V4 SubLayer Filter
    • NDU Flow Established V6 SubLayer Filter
    • NDU Inbound Mac Frame Native SubLayer Filter
    • NDU Inbound Transport SubLayer Filter
    • NDU Outbound Mac Frame Native SubLayer Filter
    • NDU Outbound Transport SubLayer Filter
    Edge traversal Teredo Authorization Sublayer
    • Teredo socket option opt out block filter

Windows 10 build 14393.576, after the Sphinx firewall is stopped and WITHOUT the Windows Firewall service running:

    WFP Built-in Edge Traversal Sublayer
    • ET Allow All
    • ET Bind callout
    • ET Default Block All
    • ET ICMPV6 Destination Unreachable - Permit
    • ET ICMPV6 NA - Permit
    • ET ICMPV6 NS - Permit
    • ET ICMPV6 Packet Too Big - Permit
    • ET ICMPV6 Parameter Problem - Permit
    • ET ICMPV6 Time Exceeded - Permit
    • ET Listen Callout
    WFP Built-in Inspection Sublayer
    • NDU Flow Established V4 SubLayer Filter
    • NDU Flow Established V6 SubLayer Filter
    • NDU Inbound Mac Frame Native SubLayer Filter
    • NDU Inbound Transport SubLayer Filter
    • NDU Outbound Mac Frame Native SubLayer Filter
    • NDU Outbound Transport SubLayer Filter
    NIS High Priority Sublayer
    • NIS ALE Flow Established V4 Filter
    • NIS ALE Flow Established V6 Filter
    • NIS Stream V4 Filter
    • NIS Stream V6 Filter
    Edge traversal Teredo Authorization Sublayer
    • Teredo socket option opt out block filter

-Noel
NoelC
 
Posts: 62
Joined: Fri Aug 21, 2015 12:59 am

Re: Secret Rules of Windows Firewall

Postby PietO » Tue Dec 20, 2016 1:37 pm

NoelC wrote: Similar to your list,

NoelC: correct; if you read some entries back, you will see that i mentioned that i deleted all 22 persistant BFE-rules (exactly the 22 rules in your Win10 list i presume) and 4 were recreated (new in Win10 list, not in Win8) and the system runs fine at a first glance. Thus indeed, what is the exact purpose of them.

Why this all: trying to find an explanation why your WIndowsUpdate did not work when WF is disabled. Until today, i can't find a possibly related rule except when Win10 is downloading from your LAN even when it's configuration-wise disabled.
Did you note that traffic is consistantly reported on port 53048 (dynamic/private port) on your LAN just while trying downloading! Could be just by chance but . . . .
see e.g. http://noel.prodigitalsoftware.com/Foru ... oading.png
see e.g. http://noel.prodigitalsoftware.com/Foru ... rewall.png

Further, there are rules we still don't see at BFE-level (e.g. most WxFC-rules and maybe others) and i put a question to Spinx-Soft on this.
PietO
 
Posts: 192
Joined: Wed Mar 02, 2011 12:09 pm


Return to Specific behavior

Who is online

Users browsing this forum: No registered users and 0 guests

suspicion-preferred