Securing Remote Desktop Protocol RDP With Public IP Whitelists

Securing Remote Desktop Protocol (RDP) against relentless automated attacks requires restricting inbound connections exclusively to trusted networks using IP filtering. By default, exposing port 3389 to the entire internet invites brute-force attempts, credential stuffing, and zero-day exploitation that can compromise your entire infrastructure. Implementing an IP allowlist ensures that only authorized locations, such as your corporate office or trusted home networks, can even initiate a handshake with your Windows servers.

Before you begin crafting firewall rules or cloud security groups, you need to know the exact external public IP address of the location from which you are connecting. If you are unsure of your current network's exit IP, you can use the What Is My IP utility to instantly view your public IPv4 and IPv6 addresses so you configure your access lists accurately.

Understanding RDP Vulnerabilities and IP Filtering

RDP operates over TCP and UDP port 3389. When this port is open to 0.0.0.0/0 (the entire public internet), automated scanning bots immediately detect the open port and begin bombarding the authentication service with password dictionaries. While enforcing Network Level Authentication (NLA) and strong passwords mitigates some risk, vulnerability disclosures regularly prove that relying solely on RDP software-layer defenses is insufficient.

IP whitelisting shifts the security boundary from the operating system to the network edge. If an attacking IP address is not explicitly allowed by your firewall, router, or security group, the connection packet is dropped silently. The server does not even respond, rendering it invisible to external reconnaissance.

Gathering and Verifying Your Whitelist Sources

Before implementing restrictions, you must document every legitimate source IP or subnet that requires administrative access. Static office connections are straightforward, but dynamic residential IP addresses pose a challenge.

Identifying Static vs. Dynamic IPs

• Static Business IP: Ideal for whitelisting. These rarely change and are tied to your ISP contract.
• Dynamic Residential IP: Often changes periodically or after router reboots. If your home IP is dynamic, you should route your RDP traffic through a secure VPN gateway with a static IP rather than constantly updating your server firewall.

To verify your current public IP via command line, you can use curl from a terminal:

curl https://api.ipify.org

Configuring Public IP Whitelists on Cloud Providers

Most modern infrastructure lives in cloud environments. Restricting RDP access here involves modifying virtual firewall constructs.

Amazon Web Services (AWS) Security Groups

1. Navigate to the EC2 Dashboard in your AWS Management Console (note that specific menu labels may differ slightly across console updates).
2. Select Security Groups from the left navigation pane and click on the security group attached to your Windows instance.
3. Edit the Inbound rules.
4. Change the Type from RDP to Custom TCP.
5. Set Port Range to 3389.
6. In the Source field, select My IP or manually enter your static IP in CIDR notation (e.g., 192.0.2.25/32).
7. Save the rules.

Microsoft Azure Network Security Groups (NSGs)

1. Open the Azure Portal and go to your Virtual Machine.
2. Click on Networking under the Settings menu.
3. Select your inbound port rule for RDP (default is usually port 3389).
4. Change the Source from Any or Internet to IP Addresses.
5. Enter your trusted public IP address in the Source IP addresses/CIDR ranges box (e.g., 192.0.2.50/32).
6. Ensure the Action is set to Allow and click Save.

Configuring Windows Firewall for Local or Bare-Metal Servers

If your server sits on-premise or in a traditional data center, you can enforce IP restrictions directly inside the Windows Firewall with Advanced Security.

1. Press Windows Key + R, type wf.msc, and press Enter.
2. Click on Inbound Rules in the left sidebar.
3. Locate the pre-built rule named Remote Desktop - User Mode (TCP-In) or create a new custom rule for port 3389.
4. Right-click the rule and select Properties.
5. Navigate to the Scope tab.
6. Under Remote IP Address, select These IP addresses.
7. Click Add, and input your trusted IP address or subnet (e.g., 192.0.2.0/24).
8. Click Apply and OK.

You can also verify and apply these rules quickly via PowerShell with administrative privileges:

# Create a firewall rule allowing RDP only from a specific trusted IP
New-NetFirewallRule -DisplayName "Secure-RDP-Whitelist" `
    -Direction Inbound `
    -Protocol TCP `
    -LocalPort 3389 `
    -RemoteAddress "192.0.2.25" `
    -Action Allow

Comparing RDP Access Control Methods

Method	Security Level	Management Overhead	Best Use Case
Open RDP (Port 3389 to World)	Critical Risk	None	Never recommended
Public IP Whitelist	High	Low to Medium	Small teams with static office IPs
VPN + Internal RDP	Very High	Medium	Growing organizations with remote workers
Bastion Host / Azure Bastion	Maximum	High	Enterprise environments requiring zero public exposure

Common Mistakes and How to Fix Them

• Locking Yourself Out: A frequent error is adding a strict IP whitelist without including your current IP address, instantly terminating your active management session. Fix: Always perform rule modifications over a secondary management channel, serial console, or ensure your cloud provider has a recovery console (like AWS Systems Manager or Azure Serial Console) enabled.
• Forgetting IPv6: If your ISP assigns you an IPv6 address and your firewall rule only restricts IPv4 (0.0.0.0/0), attackers can still reach your server over IPv6. Fix: Ensure you apply explicit IPv6 allowlists (2001:db8::/32) or disable IPv6 on the server network adapter if it is not required.
• Ignoring ISP IP Changes: If your home internet has a dynamic IP address, your connection will drop the moment your ISP rotates your lease. Fix: Use a business-class static IP or route your connection through a dedicated cloud VPN instance.

Quick Implementation Checklist

• Identify and document all legitimate user and office public IP addresses.
• Check your current exit IP using network lookup utilities.
• Remove any existing inbound firewall rules allowing RDP from Any or 0.0.0.0/0.
• Apply the new inbound rule specifying exact IP addresses or restricted CIDR blocks.
• Test the connection from an allowed IP address to ensure successful login.
• Test the connection from an unauthorized network to verify the traffic is successfully blocked.