How to Configure Windows Firewall With Advanced Security (Beyond Default Settings)
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
Most Windows endpoints run Windows Firewall with its default settings: all inbound connections blocked unless explicitly allowed, all outbound connections allowed. The outbound-allow-all default means that once malware executes on an endpoint, it can freely communicate with external command-and-control infrastructure using any port over any protocol.
Windows Firewall with Advanced Security (WFAS) provides the controls to change this: but they require explicit configuration. The default settings are a starting point, not a finished security control.
Baseline: Verify Windows Firewall Is Enabled on All Three Profiles
Windows Firewall has three separate profiles: Domain (when connected to the corporate domain network), Private (home network or a trusted network), and Public (untrusted networks like airport WiFi). Each profile has independent rules and can be enabled or disabled independently.
Verify and enforce via PowerShell:
# Check current firewall state on all profiles
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
# Expected output:
# Name Enabled DefaultInboundAction DefaultOutboundAction
# ---- ------- -------------------- ---------------------
# Domain True Block Allow
# Private True Block Allow
# Public True Block Allow
# Enforce enabled state on all profiles
Set-NetFirewallProfile -All -Enabled True
# Block inbound by default on all profiles
Set-NetFirewallProfile -All -DefaultInboundAction Block
Group Policy enforcement (prevents users from disabling): Computer Configuration > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Windows Defender Firewall Properties:
- Domain Profile: Firewall state = On; Inbound connections = Block; Outbound connections = Allow
- Private Profile: Same settings
- Public Profile: Same settings
When configured via Group Policy, users cannot disable the firewall through the Control Panel: the option is greyed out.
Inbound Rules: Locking Down Attack Surface
By default, Windows allows inbound connections for many services that most workstations do not need. Disable rules that are not required:
View all enabled inbound rules:
Get-NetFirewallRule -Direction Inbound -Enabled True |
Select-Object DisplayName, Profile, Action, Description |
Sort-Object DisplayName | Format-Table -AutoSize
Rules to disable for most workstations:
# Disable Remote Desktop (unless RDP is required: harden it per the RDP guide if needed)
Disable-NetFirewallRule -DisplayName "Remote Desktop - User Mode (TCP-In)"
Disable-NetFirewallRule -DisplayName "Remote Desktop - User Mode (UDP-In)"
# Disable file and printer sharing if not needed
Disable-NetFirewallRule -DisplayGroup "File and Printer Sharing"
# Disable Remote Assistance
Disable-NetFirewallRule -DisplayGroup "Remote Assistance"
# Disable network discovery on Public profile
Set-NetFirewallRule -DisplayGroup "Network Discovery" -Profile Public -Enabled False
Create application-specific inbound rules instead of port-based rules:
When an application needs inbound access, create a rule that allows the specific executable rather than opening a port globally:
# Allow a specific application to receive inbound connections (not all traffic on a port)
New-NetFirewallRule `
-DisplayName "Allow Custom App Inbound" `
-Direction Inbound `
-Program "C:\Program Files\CustomApp\app.exe" `
-Action Allow `
-Profile Domain `
-Protocol TCP
Application-specific rules limit the attack surface: only that specific binary can receive the connection, not any process that binds to the same port.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Outbound Rules: Reducing C2 Attack Surface
Outbound filtering is the more powerful and less-commonly-used WFAS capability. Switching the default outbound action to Block and allowing only specific applications and ports significantly reduces malware C2 effectiveness: malware can only communicate through the channels you have explicitly allowed.
Switching to default-deny outbound (requires careful planning):
Do not flip this switch in production without extensive testing. Default-deny outbound will break applications that make outbound connections you have not explicitly allowed: and in a standard Windows environment, many processes make outbound connections.
Testing approach:
- Enable WFAS audit logging for outbound connections
- Review logs for 14 days to identify all outbound connections your applications make
- Create allow rules for each legitimate outbound connection
- Switch to default-deny outbound in a test environment
- Verify all legitimate applications still function
- Deploy to production with monitoring for blocked connections
# Enable outbound audit logging (write blocked connections to Windows event log)
Set-NetFirewallProfile -All -LogBlocked True -LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log"
# After reviewing logs, create outbound rules for legitimate traffic
# Example: Allow web browser outbound
New-NetFirewallRule `
-DisplayName "Allow Chrome Outbound HTTP/HTTPS" `
-Direction Outbound `
-Program "C:\Program Files\Google\Chrome\Application\chrome.exe" `
-Action Allow `
-Protocol TCP `
-RemotePort @(80, 443)
# Allow Windows Update
New-NetFirewallRule `
-DisplayName "Allow Windows Update" `
-Direction Outbound `
-Program "%SystemRoot%\system32\svchost.exe" `
-Service wuauserv `
-Action Allow `
-Protocol TCP `
-RemotePort 443
# Block outbound after creating all required allow rules
Set-NetFirewallProfile -All -DefaultOutboundAction Block
Higher-value outbound blocks that do not require full default-deny:
Even without switching to full default-deny, specific outbound blocks reduce C2 effectiveness:
# Block PowerShell from making outbound connections (reduces fileless malware C2)
# Note: Creates alert value: monitor for blocked events as an indicator of PowerShell abuse
New-NetFirewallRule `
-DisplayName "Block PowerShell Outbound - Suspicious" `
-Direction Outbound `
-Program "%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" `
-Action Block `
-Profile Public `
-Enabled True
# Block cmd.exe outbound connections
New-NetFirewallRule `
-DisplayName "Block CMD Outbound" `
-Direction Outbound `
-Program "%SystemRoot%\System32\cmd.exe" `
-Action Block `
-Profile Public
Group Policy Deployment and Monitoring
Deploy WFAS rules via Group Policy:
For enterprise deployment, configure WFAS rules through Group Policy rather than local policy: this ensures consistency across all domain-joined machines and prevents local policy from overriding security configurations.
Computer Configuration > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security
Right-click > Import Policy to import a .wfw policy file exported from a reference machine, or configure rules directly in the GPO editor.
Monitor blocked connections via Windows Event Log:
# Find blocked inbound connection attempts (Event ID 5157)
Get-WinEvent -LogName "Security" -FilterXPath "*[System[(EventID=5157)] and EventData[Data[@Name='Direction']='%%14593']]" |
Select-Object TimeCreated, -ExpandProperty Message |
Select-Object -First 20
# Monitor via SIEM: Splunk query for blocked outbound (C2 detection value)
index=wineventlog EventCode=5157 Direction=2 /* 2=Outbound */
| eval application=Application
| where NOT application IN ("C:\\Windows\\system32\\svchost.exe", "C:\\Program Files\\...")
| stats count by application, DestAddress, DestPort
| sort -count
Blocked outbound connections from unexpected processes (powershell.exe, cmd.exe, wscript.exe, mshta.exe, regsvr32.exe) are high-fidelity indicators of malware C2 activity: the malware cannot communicate, generates a blocked-connection event, and that event surfaces in your SIEM as an alert.
The DISA STIG and CIS Benchmark settings:
If you need a compliance baseline for WFAS rather than building rules from scratch:
- CIS Level 1 benchmark for Windows 10/11 includes WFAS settings that enforce enabled state, logging, and profile-appropriate defaults
- DISA STIG for Windows Firewall provides prescriptive settings for government/high-security environments
- Both are available as Group Policy Object imports from their respective publishers, reducing manual configuration to validation rather than build.
The bottom line
Windows Firewall with Advanced Security is underutilized at most organizations: the default settings allow all outbound traffic, which gives malware free C2 access. Key configurations: enforce enabled state on all three profiles via Group Policy (users cannot disable), disable inbound rules for services not in use (RDP, file sharing, remote assistance), and block specific high-risk processes from making outbound connections (PowerShell, cmd.exe on Public profile). Enable firewall logging and alert on blocked outbound from unexpected processes: this is one of the highest-signal malware C2 indicators available without additional tooling.
Frequently asked questions
What is Windows Firewall with Advanced Security?
Windows Firewall with Advanced Security (WFAS) is the host-based firewall built into Windows that provides application-specific rules, separate rule sets for Domain, Private, and Public network profiles, outbound traffic filtering, and connection security rules (IPsec). Unlike a network firewall that protects the perimeter, WFAS enforces rules on each individual endpoint regardless of what network it is connected to.
How do I block malware C2 communication with Windows Firewall?
Block outbound connections from processes that legitimate software does not use for internet communication: powershell.exe, cmd.exe, wscript.exe, mshta.exe, and regsvr32.exe. Use New-NetFirewallRule with -Direction Outbound and -Action Block targeting these executables. Enable WFAS logging for blocked connections, then alert in your SIEM on Event ID 5157 (blocked connection) for these processes: it is a high-signal malware indicator.
How do I configure Windows Firewall to only allow specific outbound connections?
Enable default-deny outbound by changing the outbound default rule from Allow to Block in WFAS (Windows Firewall with Advanced Security), then create explicit Allow rules for required connections. This is called an allowlist approach. Recommended rule structure: allow by application path and destination port rather than by IP (IPs change); create rules per application group (browsers on port 443, Windows Update on 443, DNS on port 53). Warning: default-deny outbound causes disruption on first deployment: pilot on 10-20 machines to identify missing rules before broad rollout. This approach is most practical for servers and kiosk systems, not general employee workstations.
How do I deploy Windows Firewall rules via Group Policy?
In Group Policy Management Console: Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security > Inbound Rules (or Outbound Rules). Add firewall rules here and they will be pushed to all machines in the GPO scope at the next Group Policy refresh (default 90 minutes). For immediate application, run 'gpupdate /force' on target machines. Use Security Filtering on the GPO to apply rules to specific computer groups rather than the entire OU. Test firewall GPOs in a separate test OU before linking to production systems.
What is the difference between Windows Defender Firewall and Windows Firewall with Advanced Security?
Windows Defender Firewall is the end-user interface (Control Panel or Settings) that provides basic on/off controls and simple application allow rules. Windows Firewall with Advanced Security (WFAS) is the full management interface (wf.msc) that exposes all rule capabilities: inbound and outbound rules with granular conditions (port, application path, IP range, service, protocol), connection security rules for IPsec, and monitoring views showing active rules and security associations. For security hardening, always use WFAS directly or Group Policy: the basic interface hides most of the controls needed for a properly configured firewall policy.
How do you use Windows Firewall connection security rules to enforce IPsec between hosts?
Connection security rules in WFAS use IPsec to authenticate and optionally encrypt traffic between Windows hosts: preventing lateral movement even within the same subnet by requiring cryptographic proof of identity before a connection is established. This is the core mechanism behind Microsoft's server isolation and domain isolation architectures. A request rule requires that incoming connections use IPsec authentication (Kerberos or certificate-based) but does not block unauthenticated traffic. A require rule blocks unauthenticated connections entirely, allowing only IPsec-authenticated hosts to communicate. To configure server isolation: create a connection security rule on your sensitive servers (database servers, domain controllers, HR file shares) that requires authentication from domain-joined machines. Non-domain machines, attacker tools running on compromised endpoints without domain credentials, and any host that fails Kerberos authentication cannot establish connections to the isolated server, even though they are on the same network. Configure in WFAS under Connection Security Rules: choose the Isolation rule type, set the requirement to require authentication for inbound and outbound connections, and use Computer and User (Kerberos V5) as the authentication method. Apply via GPO to the server tier you want to isolate. This stops lateral movement from a compromised workstation to a database server because the workstation's compromised process cannot present valid Kerberos credentials for the server's required authentication.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.