Windows Firewall RDP Protection: What It Can't Do

Windows Firewall RDP protection works at the network layer — it decides which packets reach port 3389. Once a TCP connection is allowed through, the firewall steps out of the picture. The authentication handshake that follows — the part where an attacker tries Administrator with Password123, then Password1234, then ten thousand more — happens above the firewall's line of sight. Many administrators assume that having the firewall enabled and RDP on TCP port 3389 is enough. It isn't.

That gap is where RDP brute force attacks live. What the built-in firewall does, what it can't see, and what needs to be added to actually stop repeated login attempts — that's what this page covers.

What does Windows Firewall actually do for RDP?

Windows Defender Firewall is a stateful packet filter. According to Microsoft's firewall overview, it inspects packets by source IP, destination IP, port, and protocol, and decides whether to allow or block them based on rules. For RDP, the relevant rule is almost always "allow inbound TCP 3389."

That's useful. It means you can:

• Restrict RDP to a specific source IP range, such as your office's static public IP.
• Block 3389 entirely on internet-facing network interfaces while allowing it on a management VLAN.
• Combine rules with the Public, Private, and Domain network profiles, so a laptop that joins a coffee-shop Wi-Fi automatically tightens up.

If your team works from a single static IP, that IP-based restriction is genuinely strong protection. The attacker can't even reach the login screen. The problem is that most real environments don't look like that — admins work from home, from mobile networks, from clients' offices. Source IP filtering becomes impractical when the source keeps changing.

So in practice, port 3389 ends up open to a broad range, or to the world. And the moment that happens, the firewall's job is done. Everything that follows — usernames, passwords, lockouts, audit logs — happens at a layer the firewall does not read.

Does Windows Firewall protect against brute force attacks?

No. This is the misconception worth correcting clearly.

A brute force attack against RDP doesn't try to exploit a network-layer flaw. It opens a legitimate TCP connection to 3389, completes the handshake, then begins guessing credentials at the application layer. From the firewall's perspective, this looks identical to a normal user logging in. Same port. Same protocol. Same packet shape.

Each failed login generates Event ID 4625 in the Windows Security Event Log. That's the signal you'd want to act on — one IP producing dozens or hundreds of 4625s over a few minutes is a brute force attempt in progress. But the Windows Firewall does not read the Event Log. It has no concept of "this IP has failed to log in 200 times." It cannot promote authentication failures into firewall rules.

CISA has consistently flagged RDP as one of the most-attacked protocols on the internet — notably in AA22-137A, which lists exposed RDP as a routinely exploited initial access vector. Vendor incident response data reinforces this: the Sophos Active Adversary Report has named external remote services — primarily RDP — as the leading initial access vector across multiple years of real-world cases. These are brute force and credential-stuffing attacks against exposed RDP — exactly the threat the firewall alone cannot stop.

Why can't Windows Firewall stop RDP brute force on its own?

Three structural reasons, all worth understanding:

It doesn't count failed logins. A firewall rule is static. It either allows traffic from an IP or blocks it. It doesn't track how many sessions that IP has initiated, how many of them ended in LogonFailure, or how quickly they're cycling.

It can't block IPs dynamically. You can manually add a block rule for a single IP, but that's a reactive, after-the-fact action — and modern brute force tools rotate through hundreds or thousands of source IPs. Manual blocking does not scale.

Account lockout is not a substitute. Windows includes an Account Lockout Threshold setting in Local Security Policy. By default it's 0, meaning accounts never lock out. If you enable it — say, lock after 5 failed attempts — you've stopped the brute force on that account, but you've also handed the attacker a denial-of-service tool. They can lock your real Administrator account out, on demand, from anywhere on the internet. The IP keeps trying. Only the username gets punished.

Network Level Authentication (NLA), available since Windows Vista and Windows Server 2008, helps somewhat. It requires the client to authenticate before a full RDP session is created, which reduces the resource cost of each failed attempt and blocks some unauthenticated exploit paths. But NLA still accepts password guesses — it just requires them to be wrapped in CredSSP. A brute force tool that speaks CredSSP is no harder to write than one that doesn't. NLA is necessary, but not sufficient.

For the underlying attack mechanics, see our explainer on what an RDP brute force attack is.

What does dedicated RDP brute force protection add?

The missing piece is a process that watches the Security Event Log in real time, counts failed logins per source IP, and writes a Windows Firewall rule to block that IP once it crosses a threshold.

That's the entire job. It sounds simple, and architecturally it is — but doing it reliably (parsing 4625 events, extracting the source IP from the right field, handling IPv6, persisting blocks across reboots, ignoring legitimate users who typo their password twice) is where dedicated tooling earns its place.

BruteFence does exactly this. It listens to Event ID 4625 entries tied to RDP, counts failures per source IP, and when an IP crosses a configurable threshold — commonly between 3 and 10 failures — it adds a block rule to Windows Firewall for that IP. The firewall is still doing the blocking. BruteFence is just feeding it intelligence the firewall can't gather on its own.

The crucial difference from Account Lockout Policy: BruteFence blocks the IP, not the account. Your real Administrator account stays usable. The attacker, wherever they're coming from, stops getting packets through.

It installs in about 5 minutes, runs entirely on the server with no cloud dependency, and uses roughly 1% CPU under normal conditions. There's a 7-day free trial if you want to see the block rules appear in your firewall in real time. Step-by-step setup is in our guide on how to install BruteFence.

This isn't a replacement for the Windows Firewall — it's a controller for it.

Is Windows Firewall still worth keeping?

Yes, without question. The right framing is layered defense, not either/or. Here's what each layer actually does:

| Layer | What it does | What it doesn't do | |---|---|---| | Windows Firewall | Blocks packets by IP, port, protocol | Cannot see authentication failures | | Account Lockout Policy | Locks an account after N failures | Locks the legitimate user too; doesn't block IP | | Network Level Authentication | Requires pre-auth before RDP session | Still accepts unlimited password guesses | | Dedicated protection (BruteFence) | Blocks attacker IP automatically on failure threshold | Doesn't replace network segmentation or MFA |

A reasonable Windows Server deployment uses all four. The firewall is the foundation. NLA is mandatory. Account lockout is set thoughtfully — long enough thresholds and short enough durations that real users aren't punished. And a dedicated brute force tool fills the gap none of the others can.

For a full layered checklist, see our Windows Server Security Checklist for 2026.

How should you configure Windows Firewall for RDP?

Even with a dedicated tool in the mix, the firewall configuration matters. Five practical steps:

1. Restrict source IPs where you can. Open the RDP inbound rule in wf.msc, go to the Scope tab, and add your known good IP ranges under "Remote IP address." Even narrowing from Any to your country's IP block reduces the attack surface dramatically.

2. Bind RDP to specific network interfaces. On a multi-NIC server (one management interface, one public), use the firewall rule's "Interface types" or "Profiles" tab to allow RDP only on the management profile. Servers in Azure or AWS often have a dedicated management subnet — use it.

3. Consider changing the RDP port — but don't overestimate it. Moving RDP from 3389 to a high port reduces noise from untargeted scanners. It does not stop a determined attacker, who will find the new port within hours. Treat it as a small reduction in log volume, not a security measure.

4. Enable firewall logging. In Advanced Settings → Properties → Logging, turn on pfirewall.log for dropped packets. It's useful evidence when correlating with the 5 signs of an active brute force attack.

5. If IP restriction isn't workable, add a dedicated tool. If your admins genuinely need to connect from anywhere, source IP filtering breaks down. That's the case for adding dedicated RDP brute force protection — it does the dynamic blocking the firewall can't.

What should you do right now?

Open Event Viewer on your Windows Server. Navigate to Windows Logs → Security. Filter the current log by Event ID 4625. Look at the last 24 hours.

If the count is in the dozens or hundreds, the Windows Firewall is currently letting those attempts through — because that's all it can do. Every one of those events is a connection the firewall accepted, an authentication the firewall couldn't see, and a failure the firewall didn't act on.

That's the layer you're missing. Adding it doesn't mean replacing the firewall. It means giving the firewall the eyes it doesn't have.

If you want to see what's happening on your server, try BruteFence free for 7 days.