I was preparing a DSC configuration for a new server this week and after configuring firewall rules with the xNetworking DSC resources available on the PowerShell Gallery, I realized that having only rules without configuring the firewall profiles is wrong.
Keep in mind DSC is for compliance not security.
In my opinion, we should first configure the firewall rules AND then the firewall profiles.
If you’ve got the rules and an admin turns the firewall off, DSC will either tell you and/or fix the problem depending on the way you configured the ConfigurationMode of the LCM (Local Configuration Manager)
In this case, I’d suggest that the xfirewall DSC should be renamed to xFirewallRule and a new DSC resource xFirewallProfile should be added.
As I was in a hurry, here is the quick and dirty way I used to configure the firewall profiles:
As you can see, I had to explicitly use scopes inside the TestScript block.
In the meantime, I’ve discovered what scopes can be used inside a Tescript block. Using the global or local scope worked but not the script scope.
Using the Set-Variable to define the problem variable in the parent scope didn’t work either.
You may also have noticed that I’ve hardcoded the firewall state, its DefaultInboundAction and DefaultOutboundAction properties.
We’ll see in Part 2 how to create a proper DSC resource and use these as parameters.