A fresh Windows VPS is reachable from the entire public internet within minutes of being provisioned. The built-in Windows Defender Firewall is the only thing standing between your RDP port and the botnets that sweep the IPv4 space every few seconds — and it is also the component administrators break most often, usually by disabling it “temporarily” to debug an application. Understanding how firewall profiles and rules actually work is one of the most important Windows Server administration skills you can build.
Before you harden anything, you need a server worth hardening. If you are still choosing hardware, compare Windows VPS plans on our comparison table and pick a provider that gives you firewall control at the hypervisor level as well as inside the operating system — both layers matter.
Know Your Firewall Profiles
Windows Firewall uses three profiles: Domain, Private, and Public. A standalone VPS almost always sits on the Public profile unless it is joined to an Active Directory domain. Rules can be scoped per profile, so a rule that allows RDP on Public does not automatically apply on Private — and vice versa. Check which profiles are active and what the default inbound action is with:
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundActionThe DefaultInboundAction of Block is what you want: inbound connections are denied unless an explicit allow rule matches. If a server shows Allow, change it back to Block immediately.
Audit What Is Currently Open
Before adding rules, inventory what is already listening. Open an elevated PowerShell prompt and run:
Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True | Select-Object DisplayName, Profile
Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcessCross-reference the listening ports with your allow rules. Anything listening that has no corresponding rule — or a rule that applies to all profiles — is a candidate for cleanup.
Allow RDP — But Not From Everywhere
The classic mistake is a rule that allows RDP (TCP 3389) from any source address. Brute-force scanners hit that port within minutes of a server going online, so restrict it to the IPs that actually need it:
New-NetFirewallRule -DisplayName "RDP from office" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 203.0.113.10 -Action AllowRemoteAddress accepts single IPs, CIDR ranges such as 203.0.113.0/24, and comma-separated lists. If your office IP changes often, keep the OS rule open to your VPN range instead, or manage access through the provider’s cloud firewall. Update an existing rule without recreating it using Set-NetFirewallRule.
Open Only the Ports Your Workload Needs
Web servers need 80 and 443; SQL Server needs 1433; WinRM needs 5985 and 5986. Open exactly what you use and nothing else:
New-NetFirewallRule -DisplayName "IIS HTTPS" -Direction Inbound -Protocol TCP -LocalPort 443 -Action AllowNever expose SQL Server’s 1433 to the whole internet. Scope it to your application server’s IP with the same RemoteAddress parameter, or keep the database on a private network entirely.
Common Ports Quick Reference
| Port | Service | Recommended exposure |
|---|---|---|
| 3389 | RDP | Restrict to known IPs |
| 80 / 443 | HTTP / HTTPS | Open; terminate TLS on IIS |
| 1433 | SQL Server | Restrict to app servers |
| 5985 / 5986 | WinRM | Restrict to management IPs |
Turn On Firewall Logging
Logging shows you what the firewall is blocking and reveals scanning behavior early:
Set-NetFirewallProfile -Profile Public -LogBlocked True -LogFileName C:\Windows\System32\LogFiles\Firewall\pfirewall.logThe log is written to %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log. A steady stream of entries hitting port 3389 from foreign IPs is the signature of a brute-force scan — your RDP restriction and lockout policy are what keep it harmless.
Mistakes That Get VPS Servers Hacked
- Disabling the firewall “just for testing” and forgetting to re-enable it
- Allowing RDP from any source address
- Applying allow rules to all three profiles instead of Public only
- Ignoring the provider-level firewall, which leaves ports open even when the OS firewall is correct
- Exposing 3389 while weak passwords are still in use
Outbound filtering is rarely needed on a VPS and tends to break Windows Update and licensing services. Leave outbound traffic allowed by default and focus your energy on the inbound rules, where the actual attack surface lives.
Verify Your Configuration
After any change, confirm the rule is enabled and scoped correctly:
Get-NetFirewallRule -DisplayName "RDP from office" | Select-Object Enabled, Action, ProfileThen test from a machine outside the server:
Test-NetConnection 203.0.113.10 -Port 3389If the test fails from your allowed IP, check the provider-level firewall before touching the OS rules again.
Conclusion
Windows Firewall is not a feature to disable — it is the foundation of Windows VPS security. Set profiles deliberately, allow inbound traffic only where required, restrict RDP to known addresses, and keep logging enabled. When you provision the next server, see the full Windows VPS specs on the comparison table and choose a plan with solid network-level filtering. If you want a low-cost environment to practice hardening on, InterServer’s Windows VPS — with promo code TRYINTERSERVER covering the first month for about a cent — is a cheap, safe place to break things and fix them again.
