Add support to distinguish Name and DisplayName in win_firewall rules

[jborean93]

Add support to distinguish Name and DisplayName in win_firewall rules

[jborean93]

From @charlesgreen on Nov 02, 2017 02:23

Btw, I am more than happy to submit a PR for this request if considered.

[jborean93]

From @charlesgreen on Nov 05, 2017 15:52

Would a PR be considered for this change?

[jborean93]

From @jborean93 on Nov 05, 2017 22:07

I'm not sure if we are looking at the same module, win_firewall_rule has had 2 versions in the past;

• 1st iteration (pre 2.4) used netsh advfirewall to configure firewall rules
• 2nd iteration (2.4 and current) uses COM objects like HNetCfg.FwPolicy2 and HNetCfg.FWRule instead

HNetCfg.FWRule has a few properties but we are using the Name property to filter the rules and it seems like it is equal to -DisplayName for the Get-NetFirewallRule cmdlet. Here is the an example output of a rule and its properties.

Name                        : Remote Desktop - User Mode (TCP-In)
Description                 : Inbound rule for the Remote Desktop service to allow RDP traffic. [TCP 3389]
ApplicationName             : C:\Windows\system32\svchost.exe
serviceName                 : termservice
Protocol                    : 6
LocalPorts                  : 3389
RemotePorts                 : *
LocalAddresses              : *
RemoteAddresses             : *
IcmpTypesAndCodes           :
Direction                   : 1
Interfaces                  :
InterfaceTypes              : All
Enabled                     : True
Grouping                    : @FirewallAPI.dll,-28752
Profiles                    : 2147483647
EdgeTraversal               : False
Action                      : 1
EdgeTraversalOptions        : 0
LocalAppPackageId           :
LocalUserOwner              :
LocalUserAuthorizedList     :
RemoteUserAuthorizedList    :
RemoteMachineAuthorizedList :
SecureFlags                 : 0

From my understanding each Name should be unique per profile, your example regarding the RDP protocols seem to be incorrect. Here is what I have on a Windows Host

Name: RemoteDesktop-UserMode-In-TCP
DisplayName: Remote Desktop - User Mode (TCP-In)

Name: RemoteDesktop-UserMode-In-UDP
DisplayName: Remote Desktop - User Mode (UDP-In)

Is there another example that you can give us that have duplicate display names in the same profile? If we were using Get-NetFirewallRule then I would agree there should be 2 parameters like we do with win_service but in this case the COM object doesn't allow us to configure the -Name property and I'm not sure where PS is sourcing that info from.

[jborean93]

From @charlesgreen on Nov 06, 2017 04:42

Thank you @jborean93 for the prompt and detailed reply.
Apologies. I must have made a mistake with the repo.

I took a second look at the win_firewall_rule module and as you mentioned, it is using the Name property to determine if there are multiple rules returned with the same name.

As the Name is unique per profile could the Name check be extended to include the $profile?

For example:
The current implementation returns the following 2 results for Remote Desktop - User Mode (TCP-In) and then fails when I try to update the rule because there are multiple rules with the same name.

Current Implementation:
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/windows/win_firewall_rule.ps1#L200

$existingRule = $fw.Rules | Where { $_.Name -eq $name }

Results:

Name                        : Remote Desktop - User Mode (TCP-In)
Description                 : Inbound rule for the Remote Desktop service to allow RDP traffic. [TCP 3389]
ApplicationName             : C:\Windows\system32\svchost.exe
serviceName                 : termservice
Protocol                    : 6
LocalPorts                  : 3389
RemotePorts                 : *
LocalAddresses              : *
RemoteAddresses             : *
IcmpTypesAndCodes           :
Direction                   : 1
Interfaces                  :
InterfaceTypes              : All
Enabled                     : True
Grouping                    : @FirewallAPI.dll,-28752
Profiles                    : 3
EdgeTraversal               : False
Action                      : 1
EdgeTraversalOptions        : 0
LocalAppPackageId           :
LocalUserOwner              :
LocalUserAuthorizedList     :
RemoteUserAuthorizedList    :
RemoteMachineAuthorizedList :
SecureFlags                 : 0

Name                        : Remote Desktop - User Mode (TCP-In)
Description                 : Inbound rule for the Remote Desktop service to allow RDP traffic. [TCP 3389]
ApplicationName             : C:\Windows\system32\svchost.exe
serviceName                 : termservice
Protocol                    : 6
LocalPorts                  : 3389
RemotePorts                 : *
LocalAddresses              : *
RemoteAddresses             : *
IcmpTypesAndCodes           :
Direction                   : 1
Interfaces                  :
InterfaceTypes              : All
Enabled                     : False
Grouping                    : @FirewallAPI.dll,-28752
Profiles                    : 4
EdgeTraversal               : False
Action                      : 1
EdgeTraversalOptions        : 0
LocalAppPackageId           :
LocalUserOwner              :
LocalUserAuthorizedList     :
RemoteUserAuthorizedList    :
RemoteMachineAuthorizedList :
SecureFlags                 : 0

Ansible firewall rule:

- name: Firewall rule to allow RDP on private TCP port 3389
  win_firewall_rule:
    name: Remote Desktop - User Mode (TCP-In)
    localport: 3389
    remoteip: 192.168.56.1
    action: allow
    direction: in
    protocol: tcp
    profiles: private
    state: present
    enabled: yes

Error:

TASK [win_firewall : Firewall rule to allow RDP on private TCP port 3389] **********************************************
fatal: [192.168.56.3]: FAILED! => {"changed": false, "failed": true, "msg": "Multiple firewall rules with name 'Remote Desktop - User Mode (TCP-In)' found."}

Proposed change:

$existingRule = $fw.Rules | Where { $_.Name -eq $name -and $_.profiles -eq $profiles }

[jborean93]

From @jborean93 on Nov 06, 2017 05:23

Yep, this sounds like an actual issue that should be fixed. I don't know too much about the implementation but it may require some more changes than that, or may not I'm not 100% sure. The trouble is that each rule can be for 1 profile or multiple ones, e.g. a rule can cover all the profiles, just domain and private, or just domain and so on. @ar7z1 is probably the best person to comment on this as he wrote the current implementation of the module.

[jborean93]

From @charlesgreen on Nov 06, 2017 08:05

I'm guessing it will be more complicated.

I did a check of the default Windows 2012 R2 firewall profile ID's and found:
Additional profile ID's that are not listed in the win_firewall_rules module.

In the module, I found ID's 1, 2, 4 and 0x7fffffff.
https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/windows/win_firewall_rule.ps1#L53

In my default Windows Firewall configuration, I found additional profile ID's.
1, 2, 3, 4, 6, and 2147483647 (0x7fffffff)

I tried to find a list of valid ID's however I haven't been able to find one.

[jborean93]

From @dagwieers on Nov 06, 2017 08:48

@charlesgreen I think it's using bits to indicate which profile. So

• 3 means the first and second profile (2^0 + 2^1)
• 4 means the 3rd profile 3 (2^2)
• 6 means the 2nd and 3rd profile (2^1 + 2^2)
• 7 means the 1st, 2nd and 3rd profile (2^0 + 2^1 + 2^2)
• 0x7ffffff means all possible profiles (I assume the highest bit is unused, or used for something else)

If this is the case we can extend our module to include profile numbers and/or all profiles as options. Leaving it to 0 would be the same as disabling it (I guess).

[jborean93]

From @charlesgreen on Nov 06, 2017 09:02

Thanks for your reply. It's helpful to understand. If you'd like me to submit a PR please let me know otherwise I'm happy to test.

[jborean93]

From @dagwieers on Nov 06, 2017 09:15

Like @jborean93 I think we need to wait for current maintainer @ar7z1 to indicate his preference and then look for an acceptable implementation. I can sense some disagreement how it ought to work.

• Do we make Name unique only
• Do we make it unique per profile (Windows presumably does this)
• Do we make it unique and merge profiles into a single statement (if so, how do we handle existing inconsistencies, do we merge these as well ?)

There's a likely impact to other firewall-related applications.

[jborean93]

From @ar7z1 on Nov 06, 2017 19:42

Do we make it unique per profile (Windows presumably does this)

Unfortunately, Windows allows you to create completely identical rules. :-(

I've created two identical rules (with same profile value). For them $fw.Rules | Where { $_.Name -eq 'tst8888' } returns:

Name                        : tst8888
Description                 :
ApplicationName             :
serviceName                 :
Protocol                    : 6
LocalPorts                  : 8888
RemotePorts                 : *
LocalAddresses              : *
RemoteAddresses             : *
IcmpTypesAndCodes           :
Direction                   : 1
Interfaces                  :
InterfaceTypes              : All
Enabled                     : True
Grouping                    :
Profiles                    : 2
EdgeTraversal               : False
Action                      : 1
EdgeTraversalOptions        : 0
LocalAppPackageId           :
LocalUserOwner              :
LocalUserAuthorizedList     :
RemoteUserAuthorizedList    :
RemoteMachineAuthorizedList :
SecureFlags                 : 0

Name                        : tst8888
Description                 :
ApplicationName             :
serviceName                 :
Protocol                    : 6
LocalPorts                  : 8888
RemotePorts                 : *
LocalAddresses              : *
RemoteAddresses             : *
IcmpTypesAndCodes           :
Direction                   : 1
Interfaces                  :
InterfaceTypes              : All
Enabled                     : True
Grouping                    :
Profiles                    : 2
EdgeTraversal               : False
Action                      : 1
EdgeTraversalOptions        : 0
LocalAppPackageId           :
LocalUserOwner              :
LocalUserAuthorizedList     :
RemoteUserAuthorizedList    :
RemoteMachineAuthorizedList :
SecureFlags                 : 0

I'm not sure that it'll be a good decision to automatically merge them.

I think we should:

1. Improve search algorithm: if there are several rules with the same name, we can try to distinguish them by task parameters. So we'll resolve @charlesgreen issue (profile parameter will help to select single rule).
2. If we can't select single rule we can change all of them. Old netsh advfirewall firewall does so. For my identical rules netsh advfirewall firewall changes two rules:

   C:\WINDOWS\system32> netsh advfirewall firewall set rule name="tst8888" new localport=8889
   
   Updated 2 rule(s).
   Ok.
   

@jborean93 @dagwieers @charlesgreen What do you think about it?

[jborean93]

From @jborean93 on Nov 06, 2017 20:16

If there is truly no unique identifier we can use then I would say option 2 is the way to go, if that is the way netsh advfirewall firewall works then. We'll see what other people say.

[jborean93]

From @charlesgreen on Nov 07, 2017 01:58

@ar7z1 I followed your example and use Get-NetFirewallRule to obtain a unique identifier.

I first created a new firewall rule with Ansible and then created a second rule manually using the GUI. The Name field in the GUI and the Ansible module mapped to the DisplayName (when returned by Get-NetFirewallRule) while the Name property is a unique GUID.

Name                  : {30732030-39C5-4729-835A-1B5E969370E9}
DisplayName           : Test1
Description           : 
DisplayGroup          : 
Group                 : 
Enabled               : True
Profile               : Private
Platform              : {}
Direction             : Inbound
Action                : Allow
EdgeTraversalPolicy   : Block
LooseSourceMapping    : False
LocalOnlyMapping      : False
Owner                 : 
PrimaryStatus         : OK
Status                : The rule was parsed successfully from the store. (65536)
EnforcementStatus     : NotApplicable
PolicyStoreSource     : PersistentStore
PolicyStoreSourceType : Local

Name                  : {B848FE82-6349-4896-9FEC-D2C6E8F4EA9C}
DisplayName           : Test1
Description           : 
DisplayGroup          : 
Group                 : 
Enabled               : True
Profile               : Private
Platform              : {}
Direction             : Inbound
Action                : Allow
EdgeTraversalPolicy   : Block
LooseSourceMapping    : False
LocalOnlyMapping      : False
Owner                 : 
PrimaryStatus         : OK
Status                : The rule was parsed successfully from the store. (65536)
EnforcementStatus     : NotApplicable
PolicyStoreSource     : PersistentStore
PolicyStoreSourceType : Local

[jborean93]

From @ar7z1 on Nov 07, 2017 07:59

@charlesgreen You're right, Windows generates unique ids for rules created via GUI or HNetCfg.FWRule. It uses these ids as keys in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules:

Unfortunately, Windows doesn't allow to access this rule id (or -Name property in terms of Get-NetFirewallRule cmdlet) when you use HNetCfg.FWRule COM object (or when you create rule manually via GUI). I think there are only two ways to access it:

1. Use -Name property of New-NetFirewallRule/Get-NetFirewallRule/Set-NetFirewallRule/Remove-NetFirewallRule cmdlets. These cmdlets are supported from Windows Server 2012 and Windows 8. So we have to drop support for previous Windows version (Windows 7, Windows Server 2008 and Windows Server 2008 R2).
2. Use evil registry access to control ids of created firewall rules. I think this is the wrong way.

First of all, we should decide why we'll use that rule id property in win_firewall_rule module.
There are several scenarios:

1. Rule is completely managed via ansible. Then there are no duplicates in the rule names.
2. We need to manage rule created via GUI. Then this rule will have a random id (-Name), so we can't specify it in ansible task. But improved rule search algorithm can help to select the right rule.
3. We need to manage Windows built-in rules with duplicated -DisplayName (Remote Desktop - User Mode (TCP-In) for example). -Name property certainly can help in this situation. Improved rule search algorithm will select right rule too.

I think the best decision will be to slightly modify current search algorithm: if there are several rules with the same name, try to distinguish them by profile property. And if we can't distinguish return old "Multiple firewall rules with name '$name' found." error. I think it will completely fix @charlesgreen issue.
I can create a PR for that (or @charlesgreen can if he want ;-)).

[jborean93]

From @charlesgreen on Nov 07, 2017 10:23

@ar7z1 great info. I agree with the recommended modification of the search algorithm given the challenges. I think it would cover many of the default firewall use cases.

I can submit a PR for the change within the next 24 hours. Always happy to try and help.

[jborean93]

From @ar7z1 on Nov 07, 2017 12:22

I can submit a PR for the change within the next 24 hours.

@charlesgreen Great news! Thank you a lot!

[jborean93]

From @dagwieers on Nov 07, 2017 12:22

If Windows does not have a unique identifier for rules, it means other applications also have no means of selecting a single instance. Which makes me favor merging identical rules (same name, different profiles) into a single entry (it's as simple as a boolean OR on the profile value). Only when we add/modify, obviously.

I think it greatly simplifies firewall management and takes away any confusion. If existing rules conflict, and we're not imposing anything, the module should avoid merging and provide a warning related to this. (Because it's unknown what exactly the user wants to happen in this case).

And it also avoids issues related to profile: 1, profile: 3 and profile: 7, overlapping/managing the first profile and second profile.

@ar7z1 I wonder if the order of the rules is of any importance ? I would assume it is, but from your output, I cannot make this up.

[jborean93]

From @charlesgreen on Nov 07, 2017 14:28

@dagwieers in the case of the Remote Desktop - User Mode (TCP-In) there are 2 built-in rules that are created by default.

Through the GUI changes cannot be made however I'm not sure if they can be merged programmatically. I'll check tomorrow.

Would the approach be to create a new rule while deleting the existing rules or would it be to modify an already created rule?

I'm in favor of the simplest solution which can meet the needs of the default firewall rules. I believe that can be accomplished by Name and Profile. That along with perhaps a Rule naming recommendation would give the user the ability to start with a default build and customize as they see fit.

I'll start with a PR to select firewall rules based on Name and Profile and share it for feedback. From there if the group decides to add merging of rules I'll make changes but I'll need to better understand the desired logic and use cases.

[jborean93]

From @dagwieers on Nov 07, 2017 14:40

@charlesgreen The problem with just comparing profile, is that if you create a rule for profile 1, and then one for profile 3, they are considered 2 different rules, which is incorrect. The second rule incorporates the first rule. Same for profile 0x7fffffff, which incorporates both profiles (and any other profile combinations).

So it wouldn't actually be idempotent in the sense that if you want to adapt an existing rule to include, "private" (e.g. profile 2), you would first have to remove the existing "public" one (e.g. profile 4), and then add one with "public,private" (e.g. profile 6). While it's just extending the scope of the existing rule. (so merging the profiles 2 | 4 = 6)

What I found interesting is that in your RDP rule, Windows added 2 rules, one with profile 3 and one with profile 4. Both are not overlapping. I assume from this that:

• Domain = 1
• Private = 2
• Public = 4

Which means the first rules was one for Domain+Private zones, the second was for Public zones.

[jborean93]

From @ar7z1 on Nov 07, 2017 21:45

I wonder if the order of the rules is of any importance ?

@dagwieers Do you mean rules creation order? I think no.
From Order of Windows Firewall with Advanced Security Rules Evaluation:

Block rules. This type of rule explicitly blocks a particular type of incoming or outgoing traffic. Because these rules are evaluated before allow rules, they take precedence. Network traffic that matches both an active block and an active allow rule is blocked.

First of all, Windows searches for the first matched block rule. If none matched, it searches for the first allow rule. If none matched, Windows applies default policy (block for input direction by default).

If Windows does not have a unique identifier for rules, it means other applications also have no means of selecting a single instance.

Windows has a unique identifier for rules but we can't get access to it via GUI or HNetCfg.FWRule COM object. :-( We can access to it only through a registry or Get-NetFirewallRule cmdlet.
For example, Daniel Strommen from Microsoft wrote that PowerShell cmdlets allows to access rule id:

Windows Firewall PowerShell in Windows 8 offers additional functionality over netsh advfirewall, in that now you can get and set the localized names and string ID's separately: Name (firewall rule ID), ElementName/DisplayName, Group/DisplayGroup. This should make scripting across languages of Windows easier.

I think it greatly simplifies firewall management and takes away any confusion.

Microsoft recommends to use firewall id (-Name) in scripts in some cases. From docs for -DisplayName property:

When writing scripts in multi-lingual environments, the Name parameter should be used instead, where the default value is a randomly assigned value.

So if we'll automatically merge firewall rules we can cause a lot of problems.
For example, there are three build-in almost identical rules from my Windows 10:

There are three values in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules for them:

• {859DF931-F28C-4B68-AC3B-E4CD9E60E6D0}: v2.27|Action=Allow|Active=TRUE|Dir=In|Protocol=6|Profile=Public|LPort=RPC|RA4=LocalSubnet|RA6=LocalSubnet|App=%SystemRoot%\system32\spoolsv.exe|Svc=Spooler|[email protected],-28535|[email protected],-28538|[email protected],-28502|
• FPS-SpoolSvc-In-TCP: v2.27|Action=Allow|Active=TRUE|Dir=In|Protocol=6|Profile=Private|LPort=RPC|RA4=LocalSubnet|RA6=LocalSubnet|App=%SystemRoot%\system32\spoolsv.exe|Svc=Spooler|[email protected],-28535|[email protected],-28538|[email protected],-28502|
• FPS-SpoolSvc-In-TCP-NoScope: v2.27|Action=Allow|Active=FALSE|Dir=In|Protocol=6|Profile=Domain|LPort=RPC|App=%SystemRoot%\system32\spoolsv.exe|Svc=Spooler|[email protected],-28535|[email protected],-28538|[email protected],-28502|

I think we'll break some applications if we merge FPS-SpoolSvc-In-TCP to {859DF931-F28C-4B68-AC3B-E4CD9E60E6D0} (or merge them both into new rule).

And I think that slightly improved rule search algorithm is the safest way to move. Old netsh advfirewall firewall show command does the same: it filters rules by name and profile.

[jborean93]

From @dagwieers on Nov 08, 2017 00:45

@ar7z1 The first two could be merged. The third is not active, so could not be merged. But here the different profiles have been split. What happens if you add a rule for both Public/Private that is identical ? Or one with profile=0x7fffffff ?

It seems wrong (and potentially dangerous) to create a third rule.

[jborean93]

From @ar7z1 on Nov 08, 2017 07:20

The first two could be merged.

@dagwieers If we merge FPS-SpoolSvc-In-TCP into {859DF931-F28C-4B68-AC3B-E4CD9E60E6D0} then rule with id FPS-SpoolSvc-In-TCP will be removed. After that, some Windows application may check firewall rules, determine that rule FPS-SpoolSvc-In-TCP doesn't exist and recreate that rule. After that ansible task again will merge two rules. And so on... :-) I mean that we should not remove existing rule because it id may be used somewhere else.

[jborean93]

From @dagwieers on Nov 08, 2017 10:59

@ar7z1 The fact that we impact existing rules, and they may reappear is not something we can ever prevent in Ansible. And it should not be a concern in itself, at the very least Ansible will tell you there's a change you weren't expecting.

If you want to avoid this, you'll be crippling the module. Ultimately the module would have to stay clear from rules it did not create itself, severely limiting the scope of the module. I do want to manage all firewall rules.

And this is BTW not a unique problem, everything Ansible manages (on Windows or Unix) can be managed outside of Ansible's control and could interfere with a proper functioning system.

I think we need to bring this up in a Windows WG meeting.

[jborean93]

From @ar7z1 on Nov 08, 2017 15:19

I do want to manage all firewall rules.

Me too. :-)

And it should not be a concern in itself, at the very least Ansible will tell you there's a change you weren't expecting.

Hmm, I think you're right!

I think we need to bring this up in a Windows WG meeting.

Great idea! Can I join you?

[jborean93]

From @charlesgreen on Nov 09, 2017 01:02

Looking forward to the feedback and direction from the meeting. If you'd like any assistance with the PR after an approach is agreed upon please let me know. Many thanks.

[jborean93]

From @adilio on Dec 05, 2018 05:40

Our team has just run into this issue as well. We are attempting to manage the multiple built-in Windows Firewall rules, that are assigned to different profiles. In our case the rules are Windows Remote Management (HTTP-In) , and we also get:

 "Multiple firewall rules with name 'Windows Remote Management (HTTP-In)' found."

Has there been any resolution or workaround to this (or a PR awaiting merge we're missing)? We'd like to avoid deleting built-in Windows rules, if we can avoid it.

[jborean93]

From @ruzickap on Dec 28, 2018 13:31

I used this nasty workaround for ICMP:

- name: Allow ICMP
  win_shell: Set-NetFirewallRule -DisplayName "File and Printer Sharing (Echo Request - ICMPv4-In)" -enabled True
  changed_when: false

Using the "ansible way" which is much better, but non-working right now:

- name: Allow ICMP
  win_firewall_rule:
    name: File and Printer Sharing (Echo Request - ICMPv4-In)
    action: allow
    direction: in
    enabled: yes

[jborean93]

From @charlesgreen on Feb 07, 2019 02:29

Apologies, I am no longer able to provide any details.
It has been more than a year, we moved to a different solution and I no longer have access to the environment.

[Outek]

Can we revive this issue? We have an issue with a rule

 Get-NetFirewallRule -DisplayName *windows_*                                                                                                                                

Name                          : {4188B18F-821D-485F-B24F-5EDB7783B217}
DisplayName                   : windows_exporter (HTTP )

I would like to remove this rule, but i have to use "{4188B18F-821D-485F-B24F-5EDB7783B217}" in order to remove it.

I think of a fallback. If the name is not found, we should make a fallback to "Get-NetFirewallRule -DisplayName " or something like this.

[BZanten]

Hi all, is there any progress in this issue?

We're facing the same issue, an even better example would be the following Rule:
mDNS (UDP-In)

Because for this, there are 3 identically named rules, 1 each for each profile.
Within PowerShell the rule 'DisplayNames' are identical, the Names are unique.
From within the COM object the Names are identical, but unique per profile.

if this issue is not resolved we're forced to create our own version of this module that is not nice.

Another issue, is the code in your script where a 'profiles' of value 7 is replaced with 0x7fffffff this causes the code to CHANGE the FW rules and note them as changed, even though it should not have happened, but that is probably for another thread.