- Open RDP on port 3389 gets scanned on every public server within minutes and probed with standard logins.
- Network Level Authentication, strict account lockout, and restricted access via a firewall rule belong on every Windows server running RDP.
- The cleanest approach is to never expose RDP openly to the internet in the first place, but to reach it via VPN instead.
A freshly set up Windows server with an open RDP port doesn't get its first login attempt after days – often it takes only a few minutes. Automated bots continuously scan the entire IPv4 address space for port 3389 and then doggedly work through lists of standard usernames like administrator against thousands of passwords. If you leave RDP unprotected at the edge of your server, you're playing a numbers game – except the house always wins in the end.
This post covers how to secure a Windows server running RDP so that it never joins this game in the first place: from the firewall rule through Network Level Authentication to a VPN tunnel as the cleanest solution.
Why Open RDP Is a Preferred Attack Target
RDP is attractive to attackers because a successful login immediately means full control of the server – no detour through a web shell, no privilege escalation needed. That's exactly why compromised RDP credentials regularly turn up on underground forums, often as an entry point for ransomware. The attack patterns are almost always the same:
- Port scan: Mass scanning for open TCP 3389 across the entire address space.
- Credential stuffing: Automated testing of leaked username/password combinations from old data breaches.
- Brute force: Doggedly working through password lists against known or guessed usernames like
administratororadmin.
A look at Event Viewer under Windows Logs, Security quickly shows how serious the problem is: on a freshly set up, unprotected server, numerous failed login attempts (event ID 4625) with completely different usernames pile up within a short time – a clear sign of automated scans, not colleagues mistyping their passwords.
The following table shows which safeguard actually helps against which attack pattern:
| Measure | Effective Against | Effort |
|---|---|---|
| Firewall rule limited to a fixed IP | Port scan, brute force | Low |
| Network Level Authentication | Automated exploits before login | Low |
| Account lockout after failed attempts | Brute force, credential stuffing | Low |
| VPN instead of an open port | Port scan, brute force, credential stuffing | Medium |
Step by Step: Securing RDP on the Windows Server
The following steps assume a Windows Server such as the one running as a Windows VPS with us. All commands run in an administrative PowerShell.
- Restrict access to fixed IP addresses. If you know which IP you connect from (office, fixed home line), allow only that IP through the Windows Firewall on port 3389:
The second line disables the built-in, open RDP rule so that two conflicting rules don't exist side by side. If you work from changing locations or your connection doesn't have a fixed IP address, this restriction won't work reliably – the rule would need to be adjusted after every IP change, or you'd suddenly lock yourself out. For exactly this case, step 5 is the better solution.New-NetFirewallRule -DisplayName "RDP nur von Büro-IP" -Direction Inbound -Protocol TCP -LocalPort 3389 -RemoteAddress 203.0.113.10 -Action Allow Set-NetFirewallRule -DisplayName "Remote Desktop*" -Enabled False - Enforce Network Level Authentication (NLA). NLA requires authentication before a full RDP session is even established, blocking a large share of automated attacks before the actual login screen ever appears:
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1 - Enable account lockout after failed attempts. Without a lockout, a bot can keep trying indefinitely. With this setting, an account is locked for 30 minutes after 5 failed attempts:
net accounts /lockoutthreshold:5 /lockoutduration:30 /lockoutwindow:30 - Rename the Administrator account. The built-in
Administratoraccount is known on every Windows server and is therefore the first target of any dictionary attack:Rename-LocalUser -Name "Administrator" -NewName "svc-mgmt-lokal" - Make RDP reachable only via VPN. This removes the open port 3389 entirely – no RDP service is visible from outside at all, only the VPN endpoint. Connections then run through the tunnel before RDP even comes into reach, and they work regardless of whether your own IP address changes. A ready-made solution for this is our VPN Server product, which can be placed directly in front of your existing root server.
- Set up monitoring for failed logins. You shouldn't discover repeated login attempts only after the fact in the Event Log – you should be alerted to them. You can find out what this looks like with our monitoring in the post Monitoring at Prepaid-Host.
Changing the Port or Using a VPN – Which Is the Right Approach?
Both approaches show up in forums as "the" solution. In practice, it's worth taking an honest look at their limits:
- Done in five minutes, no additional infrastructure required
- Noticeably reduces the background noise from pure port-3389 scanners
- Somewhat more setup effort, VPN client required on every access device
- Port 3389 is completely invisible from outside, not just harder to find
- The extra login step still protects you even if a password is leaked
A port that nobody can reach from outside doesn't need to be secured against brute force either.
For a single server that only you administer, changing the port is an acceptable first step. As soon as multiple people or multiple servers are involved, a VPN server is the far more robust solution – and it can also be used for other services that would otherwise be exposed on the open internet.
Checking Whether the Safeguards Actually Work
After setting this up, you should check three things before relying on the new configuration:
- Check the port from outside. From another server or your own machine, outside the allowed IP:
IfTest-NetConnection -ComputerName DEINE-SERVER-IP -Port 3389TcpTestSucceeded : Falsecomes back even though you're testing from your allowed IP, check the firewall rule from step 1 first – the old, supposedly disabled rule is probably still blocking it. - Check the NLA status. If you connect with an RDP client that doesn't support NLA, the connection must be rejected with an error message – if a classic login screen appears instead, NLA is not active.
- Test the lockout. Three to four deliberate failed logins with a test account must trigger a lockout; visible in the Security event log under event ID 4740.
If you also run several public services on the same server, it's worth taking a look at DDoS protection anyway – RDP scans aren't a DDoS attack in the classic sense, but the same underlying principle of keeping the attack surface as small and controlled as possible applies to both areas.
In the end, securing RDP isn't a one-time project but a combination of a few consistently applied measures: as little exposed surface as possible, an extra login step, and a lockout that makes brute force run into a dead end. Anyone who implements these three points removes the basis for practically every standard attack on RDP.
_6a4f6e96d67aa.png)