Protecting RDP from brute-force attacks

What this is#

Any Windows server on the public internet gets its RDP port scanned and password-guessed around the clock, it's the Windows equivalent of the SSH brute-force noise on Linux, but here there's no network-level ban system in front of you, so the defense is configured on the server. The measures below are ordered by how much each one actually buys.

First, see the problem for yourself: Event Viewer → Windows Logs → Security, filter for Event ID 4625 (failed logon). A fresh public VPS collects thousands of these, random usernames from random IPs. That's the internet's background radiation, the goal isn't zero attempts, it's making attempts worthless.

1. IP-restrict the RDP rule (the real fix)#

If RDP only answers your own addresses, the entire attack class ends, no guesses, no lockouts, no noise. The firewall guide walks the exact steps (scope the built-in Remote Desktop rule to your IPs), including the dynamic-IP caution and the Console-as-fallback safety net. If you can list where you connect from, do this one and the rest becomes defense in depth.

2. Verify Network Level Authentication is on#

NLA makes the connection authenticate before a desktop session is created, which starves both credential-guessing and pre-auth exploits. It's the default on every supported Server version, verify it stayed that way: System Properties → Remote → "Allow connections only from computers running Remote Desktop with Network Level Authentication" should be ticked. Leave it ticked; every client we document supports it.

3. Set an account lockout policy#

Make guessing self-defeating: after N wrong passwords, the account locks for a cooldown.

1. Run secpol.msc → Account Policies → Account Lockout Policy.
2. Sensible values: threshold 5 invalid attempts, lockout duration 15 minutes, reset counter after 15 minutes.

The honest caveat: a lockout policy can lock you out for its duration if you fat-finger the password repeatedly (or an attacker deliberately locks a known username). That's recoverable, wait out the cooldown, or use the Console in your client area, which doesn't go through RDP, and it's still a good trade: 5-guesses-per-15-minutes reduces brute force from millions of attempts to statistical irrelevance.

4. Optionally, move the port#

Changing RDP off 3389 eliminates the drive-by scanner traffic (targeted attackers will still find it, it's noise reduction, not security). The lockout-safe procedure, firewall rule first, then the registry value, then test, plus the ip:port client syntax, is its own guide: How can I change my RDP port?

5. Strong, unique password, always#

Everything above assumes the password isn't "P@ssw0rd2026". Long, unique, from a manager, pasted without whitespace, and per-person accounts rather than a shared Administrator (which also fixes the session fights).

What good looks like afterwards#

IP-restricted RDP + NLA + lockout policy means Event 4625 goes quiet, and any entry that does appear is worth reading. Check in occasionally; a change in the noise is your early warning. If you suspect someone actually got in, that's the compromise doctrine, not a settings tweak.

Still need help?#

You can open a support ticket. So we can help on the first reply, it's worth mentioning:

• the VPS hostname or IP,
• what you've applied so far (NLA, lockout policy, IP restriction),
• what the Event ID 4625 activity looks like.

Related questions#

• "How do I stop brute-force attacks on RDP?"
• "What is Event ID 4625 and why do I have thousands?"
• "How do I set an account lockout policy?"
• "Should I change the RDP port?"
• "What is Network Level Authentication?"