Windows Firewall Rules That Matter: Profiles, Scopes, and Logging

Most Windows VPS intrusions do not start with a zero-day exploit. They start with a firewall that was switched off “just for testing,” an RDP rule open to the entire internet, or a rule attached to the wrong network profile. Windows Defender Firewall is the default network boundary on every Windows Server, and getting profiles, scoping, and logging right is cheaper than any third-party security product. If you are still choosing a host, compare Windows VPS plans on our provider comparison table before you start locking anything down.

Profiles Decide Whether a Rule Even Applies

Windows assigns every network adapter a profile: Domain, Private, or Public. A VPS typically has one adapter and one public IP, so the adapter lands in the Public profile, which is the strictest. A rule you create for the Private profile alone will never apply to that adapter, which is the most common reason a port stays unexpectedly open or closed. Check the assignment first:

Get-NetConnectionProfile
Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Public

The default inbound policy for all profiles is Block and the default outbound policy is Allow. Resist the urge to flip the inbound default to Allow so “nothing gets stuck” — that one toggle undoes every rule you write. Add explicit allow rules and leave the default block in place.

Scope Every Rule. Especially RDP.

A rule that allows RDP (TCP 3389) from anywhere is the most scanned inbound rule on the internet. Scope it with the RemoteAddress property — the Windows Firewall with Advanced Security console exposes this as “Remote IP address,” and PowerShell does the same with -RemoteAddress:

New-NetFirewallRule -DisplayName "RDP - office only" -Direction Inbound `
  -Protocol TCP -LocalPort 3389 -RemoteAddress 203.0.113.0/24 `
  -Profile Public -Action Allow
  • -RemoteAddress accepts a single IP, a CIDR block, or a range. A bare IP without a mask behaves like a /32.
  • Rules are evaluated in order, and overlapping allows cause confusing behavior. Audit with Get-NetFirewallRule | Sort-Object DisplayName and delete duplicates.
  • The strongest setup is to hide RDP entirely: put Remote Desktop Gateway or a VPN in front, restrict the RDP rule to that gateway’s IP, and block direct 3389 from the internet. That configuration survives a leaked password far longer than an open port does.

Program Rules vs Port Rules

Port rules are simple but static: they open a port regardless of which process listens on it. Program rules tie the exception to an executable path, so a random service cannot bind to the same port and inherit the allowance. Use program rules for line-of-business apps that listen on nonstandard ports, and fall back to port rules only when the executable path is unstable — for example, a .NET app whose binaries change with every deployment. When in doubt, prefer the program rule: it is the difference between “port 8443 is open” and “this specific binary may accept inbound connections.”

Enable Logging Before You Need It

Firewall logging is off by default, which means the one night you need to know what was blocked, there is nothing to read. Enable dropped- and allowed-connection logging with a sane size cap:

Set-NetFirewallProfile -Profile Public -LogBlocked True -LogAllowed True `
  -LogMaxSizeKilobytes 32767 `
  -LogFileName C:\Windows\System32\LogFiles\Firewall\pfirewall.log

The log is a plain text file with one line per connection. The quick way to see what is being dropped right now:

Get-Content C:\Windows\System32\LogFiles\Firewall\pfirewall.log -Tail 50 |
  Where-Object { $_ -match "DROP" }

If you see constant drops on 3389 from random source IPs, your scoping is working — that is the botnet noise, not a misconfiguration. If you see drops on a port you expected to be open, the rule profile or scope is wrong; fix the rule instead of disabling the firewall.

The Three Mistakes That Undo Everything

  • Disabling the firewall to debug an application, then forgetting to re-enable it. Use a scoped allow rule instead — it takes the same two minutes and stays on.
  • Setting the inbound default to Allow. Every future rule becomes decoration.
  • Ignoring the profile field when creating rules in the console. New rules default to all profiles, which can quietly expose a service on adapters you thought were locked down.

Rules, profiles, and logs give you a firewall you can defend in a security review instead of one you hope nobody tests. Pair the network layer with the rest of the platform’s capabilities on our Windows VPS feature overview, and re-audit your rule set every time you add a role or an application. If you need a box sized for the load, check current Windows VPS pricing and plans before you commit.

Leave a Comment