Windows - Security - Windows Firewall Management

What the Windows Firewall enforcement Worklet does

This Automox Worklet™ enforces a declarative Windows Defender Firewall configuration on every endpoint under management. You define which TCP ports should be blocked, which should be explicitly allowed, which firewall profiles the policy applies to (Domain, Private, Public, or all three), and whether the firewall itself must be enabled. The Worklet evaluates the live configuration against that desired state, flags any drift, and applies the missing or conflicting rules on the next remediation pass.

The script ships with a named service map that covers the ports most often touched by a baseline policy: HTTP/80, HTTPS/443, FTP/21, SFTP/22, SMB/445, RDP/3389, SMTP/25, SMTPS/587, SMTPSSL/465, IMAP/143, IMAPS/995, and Kerberos/88. You move a service name into the $portsToBlock or $portsToAllow array and the Worklet handles the rest. Every rule it creates is named AUTOMOX WORKLET: [ TCP ][ <port> ], so a single Get-NetFirewallRule query returns the full set of policy-managed rules for inventory or rollback.

Rule conflict handling is built in. Moving a port from $portsToBlock to $portsToAllow on the next policy run triggers Remove-NetFirewallRule against the matching block rule before the allow rule is created, so Windows does not silently let the block continue to take precedence. The reverse move applies the same logic. Drift introduced by a local administrator, a competing GPO, or a manual rule edit is reconciled on the next evaluation without operator intervention.

Why enforce a firewall baseline at fleet scale

Inconsistent inbound firewall rules across a Windows fleet create the exact gaps lateral-movement playbooks target. Common examples include a workstation with SMB/445 open to the Public profile because a developer disabled the rule for a test, an RDP/3389 rule left enabled on a server image from a migration, or a Domain-profile-only block that never reaches a laptop joining a coffee-shop network. Any of those is the foothold an attacker needs. The Worklet aligns with the Windows Defender Firewall sections of the CIS Microsoft Windows Benchmark and NIST 800-53 SC-7 (Boundary Protection), giving you an auditable record of which ports are blocked or allowed per profile on every endpoint.

Firewall state drifts for predictable reasons. A local admin opens a port to troubleshoot a printing issue and forgets to revert the rule, a profile state is corrupted during a domain join transition, a Group Policy refresh never reaches a remote laptop sitting on a coffee shop Wi-Fi for the week. The Worklet calls Get-NetFirewallProfile for Domain, Private, and Public on every cycle, enumerates the existing AUTOMOX WORKLET-tagged rules, and reasserts the baseline ports defined in $portsToBlock and $portsToAllow against every profile, so policy holds against remote, hybrid, and unmanaged-network endpoints where Group Policy rarely lands cleanly.

How Windows Firewall enforcement works

1. Evaluation phase: The Worklet reads the configured $targetProfile (Any, Domain, Private, or Public), $targetState (0, 1, or $null), $portsToBlock, and $portsToAllow. For each profile in scope it calls Get-NetFirewallProfile -Name <Profile> and compares the .Enabled property against $targetState. For every named service in the block and allow arrays it runs Get-NetFirewallPortFilter piped into Get-NetFirewallRule to test whether an enabled rule with the matching action exists, and whether a conflicting rule from the other action is overriding it. Any mismatch writes a remediation-required message to Automox activity logs and exits 1.

2. Remediation phase: Set-NetFirewallProfile -Name <Profile> -Enabled $targetState reconciles each in-scope profile to the desired enablement state. For each port in $portsToBlock the script removes any conflicting allow rule with Remove-NetFirewallRule, then calls New-NetFirewallRule with Action Block, Protocol TCP, LocalPort <port>, Profile <targetProfile>, and DisplayName AUTOMOX WORKLET: [ TCP ][ <port> ]. The same flow runs in reverse for $portsToAllow. Errors during rule creation set $exitCode to 1 and emit the exception message; a clean run exits 0 with the line confirming the live firewall configuration is in line with the desired state

Firewall enforcement requirements

• Windows 8 or later, or Windows Server 2012 or later. The NetSecurity module ships with these builds and exposes Get-NetFirewallRule, New-NetFirewallRule, and Set-NetFirewallProfile.

• PowerShell 3.0 or later. The Automox agent runs as SYSTEM, which already meets the elevation required by the NetSecurity cmdlets.

• Set $targetProfile to Any (Domain, Private, and Public), Domain, Private, or Public depending on which profile the baseline should govern.

• Set $targetState to 1 to enforce the firewall enabled, 0 to enforce it disabled, or $null to leave the existing enablement state alone and only manage rules.

• Populate $portsToBlock and $portsToAllow with service names from the script's built-in map: HTTP, HTTPS, FTP, SFTP, SMB, RDP, SMTP, SMTPS, SMTPSSL, IMAP, IMAPS, Kerberos. To add a port outside the map, append a hashtable entry of the form $MYSERVICE = @{ Protocol = 'TCP'; Port = <int> } in the Script Vars section and reference its name.

• If a competing Group Policy Object enforces firewall rules on the same endpoints, exclude those scopes from the GPO or accept that GPO-applied rules outrank locally created rules. The Worklet manages local rules only.

Expected firewall state after enforcement

After a clean remediation, the endpoint reflects the declared baseline. Get-NetFirewallProfile shows .Enabled matching $targetState for each profile in $targetProfile. Get-NetFirewallRule returns one rule per service in $portsToBlock with Action Block, Enabled True, Protocol TCP, the configured LocalPort, and a DisplayName of AUTOMOX WORKLET: [ TCP ][ <port> ]. The same query returns one Allow rule per service in $portsToAllow, and no rule in the opposite action remains for those ports. Subsequent evaluation runs report that the live firewall configuration is in line with the desired configuration and exit 0.

Validate the policy from PowerShell on a remediated endpoint with Get-NetFirewallRule | Where-Object DisplayName -like 'AUTOMOX WORKLET*' | Select DisplayName, Action, Enabled, Profile. Inspect the per-port filter with Get-NetFirewallPortFilter -All | Where-Object LocalPort -in 80,443 | Get-NetFirewallRule. Confirm profile state with Get-NetFirewallProfile | Select Name, Enabled, DefaultInboundAction. Probe a blocked listener with Test-NetConnection -ComputerName localhost -Port 443 – TcpTestSucceeded should return False once the block rule is in place.

Drift is self-healing on the next policy interval. If an administrator deletes a managed rule with Remove-NetFirewallRule, or changes the profile enablement with netsh advfirewall set, the next evaluation enumerates Get-NetFirewallRule, sees the missing AUTOMOX WORKLET display name, and the remediation pass rebuilds the rule against the same profile. Rollback is just as direct: empty $portsToBlock and $portsToAllow and set $targetState to $null, and the next remediation leaves the firewall untouched while the existing managed rules persist until manually removed. Treat the Worklet as the runtime that holds your firewall baseline in place against every Windows endpoint in scope, and treat the source script as the source of truth for which ports the baseline actually contains.