How to Set Up Windows Firewall: PowerShell Hardening Guide

Introduction: Your Firewall Is Only as Strong as Its Configuration

Windows Firewall ships with every edition of the operating system — Pro, Enterprise, Education — enabled by default, at no additional cost [1]. It blocks unsolicited inbound traffic from the moment you boot up. And yet, breaches keep happening.

The problem is rarely a missing firewall. It is a misconfigured one. That default posture — block incoming, allow all outgoing — is a starting point, not a finish line [1]. Out of the box, logging sits disabled, outbound traffic flows unchecked, and rules accumulate.

Both CISA Cyber Essentials [9] and NIST SP 800-41 [8] position firewall configuration as a foundational cybersecurity control. Not installation — configuration. The distinction matters more than most administrators realize.

What follows is a practical, PowerShell-driven hardening walkthrough. We will cover network profiles, rule creation, logging, IPsec layering, auditing, enterprise-scale automation via Group Policy, and an emergency lockdown technique called Shields-Up mode. By the end, you will have a checklist that closes the back doors administrators accidentally leave open.

Understanding the Three Network Profiles (And Why They Matter)

Windows Firewall applies rules through three network profiles — Domain, Private, and Public — each mapped to a different trust level. The system assigns them automatically through Network Location Awareness (NLA) [1].

Domain activates when the device detects an Active Directory domain controller, which happens automatically for AD-joined machines. Private covers home or internal networks and must be set manually by an administrator. Public is the restrictive default applied to any unidentified network — think coffee shop Wi-Fi [1].

NLA switches between profiles based on connection context, no prompt required. Convenient, until it bites you. Here is the subtle danger: a disconnected network adapter is automatically assigned to the Public profile [2]. On a workstation, that is harmless. On a server with a temporarily downed NIC, it can silently reshape your entire security posture as rules scoped exclusively to the Domain profile stop applying.

Microsoft's guidance for servers is straightforward: apply firewall rules to all three profiles [2]. Servers do not roam between coffee shops and boardrooms. There is no reason to leave gaps that a profile switch can exploit.

Never Disable the Firewall — Here Is What to Do Instead

The single most dangerous misconfiguration is not a bad rule. It is disabling the Windows Firewall service entirely. Administrators do this while troubleshooting connectivity issues, then forget to re-enable it. Or worse, they do it deliberately because a third-party security product "requires" it.

Microsoft does not support stopping the MpsSvc service, and the consequences cascade quickly: the Start menu can stop working, modern apps fail to install or update, and phone activation of Windows breaks [1]. These side effects exist because Windows Firewall is woven into the OS at a fundamental level — it is not a bolt-on feature you can remove cleanly.

The damage goes deeper than broken UI. Disabling the service also eliminates IPsec connection security rules, network fingerprinting protection, Windows Service Hardening, and boot-time filters [1]. That last one deserves emphasis: boot-time filters protect the machine during the vulnerable window between power-on and full OS load — precisely when you can least afford to be exposed.

When you genuinely need to open things up, disable specific profiles while keeping the service intact:

Set-NetFirewallProfile -Profile Public -Enabled False

This suspends the Public profile's rules without touching the underlying service [3]. Third-party firewall software that needs compatibility can programmatically disable only specific Windows Firewall rule types — never the service itself [3].

Hardening Your Profiles with PowerShell

With profiles understood and the service running, it is time to lock things down. The Set-NetFirewallProfile cmdlet is your primary instrument [4].

Step 1: Set default actions. Blocking inbound should already be in place. The stronger move is blocking outbound as well:

Set-NetFirewallProfile -Profile Domain,Private,Public `
    -DefaultInboundAction Block `
    -DefaultOutboundAction Block

Blocking outbound by default is aggressive, but it prevents compromised software from phoning home. The trade-off: you will need explicit allow rules for every legitimate outbound connection.

Step 2: Enable logging. This is where most configurations fall short. By default, logging for allowed, blocked, and ignored connections is set to False [4]. Your firewall is silently dropping traffic with no record of it — a blind spot you cannot afford.

Set-NetFirewallProfile -Profile Domain,Private,Public `
    -LogAllowed True `
    -LogBlocked True `
    -LogFileName "%windir%\system32\logfiles\firewall\pfirewall.log" `
    -LogMaxSizeKilobytes 32767

The default log cap is 4,096 KB [4]. On a busy server, that fills fast. The maximum configurable value is 32,767 KB [4] — use it for any server handling meaningful traffic.

Step 3: Enable stealth mode for IPsec. This suppresses outgoing ICMP unreachable and TCP reset messages for ports where no application is listening [4]. Without it, an attacker can map your open and closed ports simply by reading the different response types:

Set-NetFirewallProfile -Profile Domain,Private,Public `
    -EnableStealthModeForIPsec True

Writing Tight Firewall Rules That Do Not Leave Gaps

Default actions set the baseline. Individual rules define the exceptions. Every rule you create is a potential back door, so precision is everything.

When working in the Windows Firewall with Advanced Security console, always select the Custom rule type. This exposes all wizard pages and gives you maximum flexibility, whereas selecting Program or Port limits the options available [2].

The most important principle: restrict program rules to specific ports. If you allow an application through the firewall without specifying which ports it needs, you have handed it a blank check. The program gets blocked only when it tries to listen on a port not specified in the rule — but that protection vanishes if you never specified a port in the first place [2].

In PowerShell, a well-scoped rule looks like this:

New-NetFirewallRule -DisplayName "Allow SQL Server" `
    -Direction Inbound -Action Allow `
    -Protocol TCP -LocalPort 1433 `
    -Program "C:\Program Files\Microsoft SQL Server\MSSQL16\MSSQL\Binn\sqlservr.exe" `
    -Profile Domain

Program, port, protocol, profile — no ambiguity.

For scenarios where trusted scanning servers or management tools need to bypass block rules, use authenticated bypass rules. These allow traffic from a specified trusted device or user to override blocks without opening port-level exceptions for everyone else [3].

Adding IPsec for Authenticated and Encrypted Communications

Firewalls filter traffic. IPsec authenticates and encrypts it. Layering both creates defence in depth that is significantly harder to circumvent.

Windows Firewall supports IPsec connection security rules that require authentication from any device attempting to communicate with the host [1]. The concept is powerful: devices that cannot prove they are trusted get blocked entirely, regardless of what ports are open [1].

Two deployment patterns stand out:

Domain isolation restricts communication to domain-joined devices only. A laptop that connects to your network but is not joined to the domain simply cannot reach your servers — even with a valid IP address and the right firewall ports open.

Server isolation goes further, restricting access to authorized users or devices for specific servers. A domain-joined workstation in accounting cannot reach the engineering build servers, even though both sit on the same domain.

IPsec also supports encryption of network traffic for sensitive communications [1]. Pair that with firewall rules requiring IPsec authentication, and you get a configuration where traffic must be both authenticated and encrypted before it passes through — a significant upgrade from port-based filtering alone.

Auditing Existing Rules to Find the Back Doors

A fresh installation with carefully crafted rules is clean. Give it six months of application installs, vendor requirements, and late-night troubleshooting sessions, and the rule set becomes a liability.

Start your audit by enumerating all active inbound allow rules:

Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True |
    Format-Table DisplayName, Profile, Direction, Action

Then pipe to Get-NetFirewallPortFilter to surface the worst offenders — rules configured with Any port or Any protocol [6]:

Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True |
    Get-NetFirewallPortFilter |
    Where-Object { $_.LocalPort -eq "Any" -or $_.Protocol -eq "Any" } |
    Format-Table InstanceID, Protocol, LocalPort

These broad rules represent your greatest exposure. Each one effectively says: "allow anything through this door."

Watch for two specific problems. Stale rules belong to applications uninstalled months ago — the software is gone, but its firewall exceptions linger. Shadow rules are overridden by other rules yet still present in the configuration, creating confusion and potential future exposure when the overriding rule changes.

Make these audits a recurring practice. Firewall rules accumulate over time, and every one is a potential back door someone forgot to close.

Managing Firewalls at Enterprise Scale

Manually configuring firewalls machine by machine does not scale. Group Policy is the standard mechanism for deploying consistent rules across all domain-joined devices [2].

For large rule sets, PowerShell supports GPO caching through Open-NetGPO and Save-NetGPO. These cmdlets load a domain GPO onto the local machine for batch editing before writing back, reducing load on Domain Controllers [3]:

$gpo = Open-NetGPO -PolicyStore "contoso.com\ServerFirewallPolicy"
# Make multiple rule changes against $gpo
Save-NetGPO -GPOSession $gpo

For ad-hoc changes and troubleshooting, remote management via WinRM works out of the box. Cmdlets supporting the CimSession parameter can manage firewall rules on remote hosts [3] without requiring RDP or physical access:

$session = New-CimSession -ComputerName "Server01"
Get-NetFirewallRule -CimSession $session -Direction Inbound

The recommended pattern: a GPO baseline covering standard rules across all machines, with local rules handling server-specific exceptions.

Shields-Up Mode: Emergency Lockdown During Active Incidents

When you are under active attack and need to sever all inbound traffic immediately, Shields-Up mode is the nuclear option.

Setting AllowInboundRules to False while DefaultInboundAction is set to Block activates Shields-Up mode on a profile [4]. Every inbound firewall rule you have created gets ignored. All inbound connections are blocked, no exceptions:

Set-NetFirewallProfile -Profile Domain,Private,Public `
    -DefaultInboundAction Block `
    -AllowInboundRules False

This is deliberately extreme. It will break legitimate services, remote management, and user access. That is precisely the point — during an active breach, stopping lateral movement takes priority over availability.

You can deploy this per-profile or across all profiles simultaneously. The critical requirement: have a tested Shields-Up playbook ready before an incident occurs. The middle of a breach is not the time to learn the commands, gauge the impact, or discover you have locked yourself out of the only management interface.

Document the activation command, the expected impact, and the rollback procedure. Test it quarterly.

Conclusion: A Firewall Checklist You Can Use Today

Firewall security is not a set-and-forget proposition. It is an ongoing cycle of configuration, auditing, and adaptation. Here is your hardening checklist:

• Verify profiles: Confirm all three profiles are active and that rules apply across all profiles on servers
• Never disable the service: Use Set-NetFirewallProfile -Enabled False if needed — never stop MpsSvc
• Enable logging: Turn on logging for allowed and blocked connections; increase maximum log size
• Tighten rules: Use Custom rule types, restrict to specific ports and programs, eliminate broad allow-all entries
• Layer IPsec: Require authentication for sensitive servers; encrypt traffic where needed
• Audit regularly: Enumerate rules quarterly, remove stale entries, investigate any rule scoped to Any port
• Automate via GPO: Deploy baseline rules through Group Policy; use GPO caching for batch changes
• Prepare Shields-Up: Document and test your emergency lockdown procedure before you need it

NIST SP 800-41 [8] and CISA Cyber Essentials [9] both provide frameworks for ongoing firewall policy governance. Use them as your reference points.

Firewalls are one layer in defence-in-depth. Combine them with network segmentation, regular patching, and access controls [9]. No single control stops every threat.

The back door stays closed only if you keep checking the lock.