xFirewall doesn't fix issue of Configuration Drift if rule that drifted is not defined in configuration

[DamianBis]

xFirewall still reports as compliant even if someone adds extra rules to the windows firewall outside of the DSC configuration.. Haven't found anywhere with a solution to this. Realistically all firewall rules on my server should be either 1. Default windows rules or 2. added through DSC

[PlagueHO]

I see. So basically the need would be to delete or report on any firewall rules that are not listed or set to "Ensure" in the DSC configuration applied to the node.

That is actually quite a difficult issue you raise, but I completely understand the need for this.

I can't think of a solution to this off the top of my head, but there are many smarter folk around these parts than I - @tysonjhayes, @TravisEz13, @iainbrighton?

[TravisEz13]

The current resource wasn't designed with this scenario in mind (as windows come with many default rules.) It is an xFirewallRule resource and therefore cannot enforce anything outside the rule described.

The only good way I see is to write a true xFirewall resource which takes an array firewall rules, and use the group semantic (Rules, RulesToInclude, RulesToExclude.)

[PlagueHO]

I've been considering this problem further and I can't figure out a way of determining which rules are "default" and which are user added. This is further compounded by the fact that adding or removing Windows Features will also add/remove default rules.

The solution @TravisEz13 proposes would work, but would result in quite large configurations, with the configuration of each Firewall rule property defined. Worth considering though.

[DamianBis]

In practice there's no reason we can't put every single rule (including windows defaults) in our DSC config. and then have any other rules on the server that aren't declared in DSC be considered non compliant...

Obviously my main concern is that we troubleshoot something. change a firewall rule or add a firewall rule/exception and then we rebuild a box 2 months later and have that issue occur again because the firewall rule wasn't committed to the configuration

[tysonjhayes]

While I personally like to declare as much as I can into DSC you may run into a few problems as the size grows.

1. It'll take longer to actually deploy all of the changes. Currently I have a few app boxes that take about five minutes to complete. Given I have it set to check DSC every 15 minutes means I'm applying DSC configurations a lot (something I need to fix come to think of it).
2. There is a size limit to how much WMI will swallow (I think 1024 KB? I've been meaning to write a blog post on this) so you may have to up this size on your servers as you start hitting that limit.

That being said I personally think if it's not in your source of truth (DSC) then it doesn't exist, so if you running into problems where default rules weren't committed to the configuration then you need to figure out how to solve that problem. :grin:

[PlagueHO]

I still can't think of an easy way to solve this problem. It is a real head scratcher.

@DamianBis - are you familiar with Chef? I wonder if they have tackled this sort of problem. It might be worth rummaging around the Chef community and see if anyone over there has done anything like this (I'd doubt it but worth a shot). Chef does use DSC resources under the hood to perform a lot of config on Windows boxes. If someone else has come up with a design pattern for this sort of thing then I'm sure the DSC community could probably implement something too.