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 \u2014 and it is also the component administrators break most often, usually by disabling it \u201ctemporarily\u201d 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.<\/p>\n\n
Before you harden anything, you need a server worth hardening. If you are still choosing hardware, compare Windows VPS plans on our comparison table<\/a> and pick a provider that gives you firewall control at the hypervisor level as well as inside the operating system \u2014 both layers matter.<\/p>\n\n Windows Firewall uses three profiles: Domain<\/strong>, Private<\/strong>, and Public<\/strong>. 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 \u2014 and vice versa. Check which profiles are active and what the default inbound action is with:<\/p>\n\n The Before adding rules, inventory what is already listening. Open an elevated PowerShell prompt and run:<\/p>\n\n Cross-reference the listening ports with your allow rules. Anything listening that has no corresponding rule \u2014 or a rule that applies to all<\/em> profiles \u2014 is a candidate for cleanup.<\/p>\n\n 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:<\/p>\n\n Web servers need 80 and 443; SQL Server needs 1433; WinRM needs 5985 and 5986. Open exactly what you use and nothing else:<\/p>\n\n Never expose SQL Server’s 1433 to the whole internet. Scope it to your application server’s IP with the same Know Your Firewall Profiles<\/h2>\n\n
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction<\/code><\/pre>\n\nDefaultInboundAction<\/code> of Block<\/code> is what you want: inbound connections are denied unless an explicit allow rule matches. If a server shows Allow<\/code>, change it back to Block<\/code> immediately.<\/p>\n\nAudit What Is Currently Open<\/h2>\n\n
Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True | Select-Object DisplayName, Profile\nGet-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess<\/code><\/pre>\n\nAllow RDP \u2014 But Not From Everywhere<\/h2>\n\n
New-NetFirewallRule -DisplayName \"RDP from office\" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 203.0.113.10 -Action Allow<\/code><\/pre>\n\nRemoteAddress<\/code> accepts single IPs, CIDR ranges such as 203.0.113.0\/24<\/code>, 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<\/code>.<\/p>\n\nOpen Only the Ports Your Workload Needs<\/h2>\n\n
New-NetFirewallRule -DisplayName \"IIS HTTPS\" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow<\/code><\/pre>\n\nRemoteAddress<\/code> parameter, or keep the database on a private network entirely.<\/p>\n\nCommon Ports Quick Reference<\/h2>\n\n