Listen to this Post

Introduction
Organizations grappling with securing remote workforces face the perennial dilemma of choosing between Virtual Private Networks (VPNs) and Remote Desktop Protocol (RDP). While VPNs create an encrypted tunnel to the entire internal network, RDP provides direct, session-based control over a specific remote machine, and each carries a distinct risk profile that demands a tailored hardening strategy. Attackers increasingly abuse misconfigured remote access as the primary pre-ransomware indicator, with exposed RDP services alone facing over 30,000 attack attempts daily.
Learning Objectives
- Distinguish core security models—network‑level VPN access vs. session‑based RDP—and their unique attack surfaces.
- Implement layered defenses including MFA, network segmentation, and application allow-listing to reduce remote access risk.
- Execute hardening commands for Windows RDP and Linux VPN servers using built‑in tools and verified configurations.
You Should Know
- VPN vs. RDP: Security Models and Attack Vectors
VPNs extend trust to remote devices, potentially increasing lateral movement if a client is compromised. RDP confines access to isolated sessions, but directly exposed RDP services remain a frequent target for automated brute‑force and pass‑the‑hash attacks. The table below compares their core security characteristics:
| Security Feature | VPN | RDP |
| : | : | : |
| Access Scope | Full network connectivity | Single‑machine session |
| Default Port | 1194 (OpenVPN) / 51820 (WireGuard) | 3389 (TCP/UDP) |
| Authentication | Certificates + pre‑shared keys | Passwords + NLA |
| MFA Support | Yes (SAML, RADIUS, OTP) | Yes (RD Gateway, third‑party) |
| Lateral Movement Risk | Higher | Lower (session confined) |
| Common Attacks | Split‑tunnel bypass, TLS vulnerabilities | Brute‑force, BlueKeep, phishing RDP files |
In practice, a defense‑in‑depth approach demands that RDP never be exposed directly to the internet. Instead, it should be published through a VPN, an RD Gateway, or a secure bastion host. Recent CVEs underline the urgency: CVE‑2026‑35058 is an OpenVPN TLS Crypt v2 assertion vulnerability, and CVE‑2026‑35424 exposes a resource‑management flaw in Windows IKE, affecting IPsec VPN services.
2. Hardening RDP: A Step‑by‑Step Lockdown Guide
Before applying any changes, check your current RDP configuration. Run the following Windows PowerShell (Admin) command to see listening ports:
Get-NetTCPConnection -LocalPort 3389 | Select-Object LocalAddress, State, OwningProcess
If the output shows `0.0.0.0:3389` (listening on all interfaces) and the firewall rule permits inbound from Any, your server is at high risk.
Step 1: Restrict RDP with Windows Firewall
1. Open Windows Defender Firewall with Advanced Security.
- Locate the inbound rule
Remote Desktop - (TCP-In).
3. Right‑click → Properties → Scope tab.
- Under Remote IP addresses, select “These IP addresses” and add your VPN subnet or specific management hosts. This reduces the exposure surface.
Step 2: Enforce Network Level Authentication (NLA)
NLA requires the client to authenticate before establishing an RDP session, mitigating DoS and credential‑dumping vectors.
- PowerShell (Admin):
`Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp” -Name “UserAuthentication” -Value 1`
Step 3: Deny Privileged Accounts via Group Policy
- Run `gpedit.msc` → navigate to Computer Configuration → Windows Settings → Security Settings → Local Policies → User Rights Assignment.
- Add
BUILTIN\Administrators,Domain Admins, and `Local Account` to “Deny log on through Remote Desktop Services”.
Step 4: Change the Default RDP Port (obscurity only, not security)
– Registry: `HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\PortNumber` → set a custom port, then update firewall rules.
Step 5: Install MFA (e.g., Duo, Microsoft Authenticator for RD Gateway). Without MFA, an attacker who guesses or steals a password gains immediate access.
- Deploying a Secure VPN Server on Linux: OpenVPN Hardening
A hardened OpenVPN server protects the tunnel used to access RDP. Below is a verified configuration for Ubuntu 22.04/24.04.
Step 1: Install and Configure Easy‑RSA (PKI)
sudo apt update && sudo apt install openvpn easy-rsa -y make-cadir ~/easy-rsa cd ~/easy-rsa ./easyrsa init-pki ./easyrsa build-ca nopass generates CA certificate ./easyrsa gen-req server nopass server private key & request ./easyrsa sign-req server server sign server certificate ./easyrsa gen-dh Diffie‑Hellman parameters sudo cp pki/ca.crt pki/issued/server.crt pki/private/server.key pki/dh.pem /etc/openvpn/server/
Step 2: Create the Server Configuration (`/etc/openvpn/server.conf`)
port 1194 proto udp dev tun ca /etc/openvpn/server/ca.crt cert /etc/openvpn/server/server.crt key /etc/openvpn/server/server.key dh /etc/openvpn/server/dh.pem server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt push "redirect-gateway def1 bypass-dhcp" push "dhcp-option DNS 8.8.8.8" keepalive 10 120 cipher AES-256-GCM auth SHA256 user nobody group nogroup persist-key persist-tun status openvpn-status.log verb 3 explicit-exit-notify 1
Step 3: Enable IP Forwarding and Firewall NAT
sudo sed -i 's/net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/' /etc/sysctl.conf sudo sysctl -p sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
Step 4: Generate Client Certificate & Start Service
cd ~/easy-rsa ./easyrsa gen-req client1 nopass ./easyrsa sign-req client client1 sudo systemctl start openvpn@server sudo systemctl enable openvpn@server
Security Verification (Quarterly): Check for weak ciphers or outdated TLS versions using openvpn --show-tls. Rotate client certificates every 180 days and enforce AES‑256‑GCM.
- VPN for Remote Desktop: Bridging Security and Access
Rather than choosing either/or, the most resilient architecture is RDP over VPN. This combines VPN’s encrypted network entry with RDP’s session isolation. Here’s how to tunnel RDP through WireGuard (lightweight and high‑performance):
Step 1: Install WireGuard on Server and Client (Linux or Windows)
sudo apt install wireguard -y Linux Windows: download from wireguard.com/install
Step 2: Generate Keys on the Server
cd /etc/wireguard/ umask 077 wg genkey | tee server_private.key | wg pubkey > server_public.key
Step 3: Create Server Configuration (`/etc/wireguard/wg0.conf`)
[bash] Address = 10.0.0.1/24 PrivateKey = <server_private_key> ListenPort = 51820 PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE [bash] PublicKey = <client_public_key> AllowedIPs = 10.0.0.2/32
Step 4: Client Configuration (connect to the VPN)
[bash] Address = 10.0.0.2/24 PrivateKey = <client_private_key> DNS = 8.8.8.8 [bash] PublicKey = <server_public_key> Endpoint = your.vpn.server.ip:51820 AllowedIPs = 0.0.0.0/0 PersistentKeepalive = 25
Once the VPN tunnel is up, launch mstsc.exe (Windows) or Remmina (Linux) and connect to the target machine using its VPN‑assigned IP address (e.g., 10.0.0.1). The entire RDP session is now encrypted within the WireGuard tunnel, even if RDP itself uses standard NLA.
5. Detecting and Mitigating Active RDP Attacks
Attackers frequently perform brute‑force or password‑spraying attacks against exposed RDP services. Proactive monitoring can stop them before they succeed.
Windows Event Log Detection (PowerShell):
Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4625} |
Where-Object {$<em>.Message -like "3389"} |
Group-Object -Property @{Expression={$</em>.Properties[bash].Value}} |
Sort-Object Count -Descending | Select-Object -First 10
This command lists the top 10 source IPs with failed RDP logins.
Mitigation Steps:
- Implement account lockout policies via Group Policy (e.g., 5 invalid attempts lock for 15 minutes).
- Use RDP Guard or Syspeace to automatically block IPs that exceed a failure threshold.
- Disable RDP for local admin accounts except for specific break‑glass users (use the “Deny log on through Remote Desktop Services” policy described earlier).
If an intrusion is suspected (e.g., unexpected new user accounts or unusual outbound connections):
– Collect forensic data: `copy C:\Windows\System32\winevt\Logs\Security.evtx` for offline analysis.
– Immediately revoke access: Block the source IP at the firewall and rotate all credentials that were used over RDP.
- Securing RDP with a Remote Desktop Gateway (RD Gateway)
RD Gateway acts as an HTTPS‑based reverse proxy for RDP, eliminating the need to expose port 3389 to the internet. It supports MFA, connection policies, and centralized logging.
Deployment Steps (Windows Server 2022):
- Install RD Gateway role via Server Manager → Add Roles and Features → Remote Desktop Services → RD Gateway.
- Request/install an SSL certificate (from a public CA or internal PKI) for the Gateway external name.
- Create RD CAP (Connection Authorization Policies) to define which users can connect.
- Create RD RAP (Resource Authorization Policies) to specify which internal servers those users can reach.
- Configure firewall to allow HTTPS (443) inbound to the Gateway server.
Client Configuration:
In mstsc.exe → Advanced tab → “Use these RD Gateway server settings” → enter the Gateway FQDN. The RDP client will now tunnel through the Gateway, and the Gateway server can log every connection attempt.
What Undercode Say
- VPNs provide broad network access but increase blast radius; RDP offers session confinement but requires strict isolation from the internet. In production, never deploy either without MFA, network segmentation, and continuous monitoring.
- Attackers overwhelmingly target exposed RDP—over 30,000 daily probes—making defense‑in‑depth mandatory. Layering a VPN or RD Gateway, changing default ports, enforcing NLA, and denying privileged account logins can reduce the risk of initial compromise by more than 80%.
Prediction
By 2028, traditional VPNs will largely be replaced by Zero Trust Network Access (ZTNA) and Secure Access Service Edge (SASE) architectures that apply per‑session, identity‑driven access controls. RDP will continue to evolve with Microsoft’s added security dialogs for `.rdp` files and improved NLA, but the attack surface will persist as long as legacy protocols are enabled. The most resilient organizations will adopt a “never trust, always verify” posture—treating every remote access request as potentially hostile and logging, inspecting, and restricting it accordingly.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Mohamed Abdelgadr – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅


