Mr. Mackey says it best — Open RDP ports on the internet are bad… mmmmkay. When you are architecting an environment, you should avoid them like the plague. Even on an internal network, you should avoid them. Otherwise, you are just asking for problems at some point whether it is someone pounding away looking for a username/password combination or a remote vulnerability in the service. Compromised servers (via RDP) are mainstays for criminal jump points and some are even monetizing the exploits in recent ransomware campaigns such as Crysis (Infragard flash alert).

eWeek (and others) also discussed how 35,000 servers have been compromised via RDP and hackers were selling the hacked systems and/or using them for nefarious purposes.

http://www.eweek.com/security/cyber-criminals-using-compromised-rdp-servers-to-anonymize-attacks

So wait… Why the hell would I talk about how to secure them?!?! Avoid them like the plague, yes, but sometimes that isn’t reality. As a consultant who performs security assessments, I’m often not the architect or even the person who does the fixing. I simply make recommendations and sometimes a VPN, the latest/greatest 2FA, or whatever else is not possible for a myriad of reasons.

Instead, quick, easy, and more secure reigns supreme! In this post, I’ll outline 3 primary ways of protecting open RDP ports – network-based firewalls, host-based Windows firewalls, and finally with freeware — IPBan (it’s like Linux’s fail2ban, but for Windows and RDP). Keep in mind the last 2 ways also work for internal RDP ports and I would highly recommend using them there as well!

Originating IP address – network-based firewall

If possible, this remains one of my favorites. It is often built-in and it’s stupid simple. Find the IP addresses (or hostnames) that need to access RDP and then add a ‘source’ rule. On a network-based firewall, this will come in the form of a NAT rule. On a pfSense, simply go to Firewall -> NAT and click the Add above green icon. Fill in the information like the screenshot, however, ensure that you input your source IP address and you re-direct to your internal host of choice. Click ‘Save’ and then ‘Apply Changes’ on the next screen. Note: If you want to follow best practices, I would suggest using aliases if your firewall supports them.

Also note that pfSense creates the NAT rule and associated firewall rules on the WAN interface. An overwhelming majority of firewalls do this now, but I’m sure there are still some that don’t. Also, if you previously had a NAT or port forwarding rule to the host, make sure you remove it!

Here is the obligatory mention of “security through obscurity.” It’s important to note that for some small measure of improvement, you could also change the port as seen in the image below.

If you change the port, keep in mind that you will also need to add ‘:<port>’ (minus the quotes) to the end of your remote desktop connection as shown below.

Originating IP address – Windows host-based firewall

What if you don’t have a network-based firewall in place and/or you’re in the wondrous and mysterious cloud? No problem! Just create an originating IP address rule on the host instead. In Windows, go to Control Panel -> Windows Firewall -> Advanced Settings. Keep in mind this is assuming you are using the built-in Windows firewall and not using a firewall provided by endpoint protection.

While ‘Inbound Rules’ is selected, click on ‘New Rule…’ to start the wizard.

Select ‘Custom’ and ‘Next >’ on the rule type.

Click ‘Next >’ on the program selection.

Change the protocol to ‘TCP,’ type in ‘3389’ under the local port, and then click ‘Next >’.

Add in the specific IP address under the remote IP addresses and click ‘Next >’ as shown below.

Leave ‘Allow the connection’ as the selection and click ‘Next >’ again.

Let the rule apply to all profiles (Domain, Private, and Public) and hit ‘Next >’.

Last, but not least, give the rule a name such as ‘remote desktop allowed from only certain client’.

The new rule should show up at the top of the inbound rules.

Great! But we’re not done just yet! Now you either add more rules or simple disable the existing “allow” rules. I’m a huge fan of less is more approach so scroll down to the ‘Remote Desktop (TCP-In)’ rules, right-click, and select ‘disable rule.’ While you’re there, go ahead and disable the ‘Remote Desktop – RemoteFX (TCP-In)’ rules for good measure.

Windows remote desktop (RDP) -> IPBan

So you don’t have a network-based firewall and/or you can’t limit by originating IP addresses? IPBan is a little freeware gem I discovered many years ago and it is still actively developed by @jjxtra. The project is opensource so please throw a donation his way if you use it in production! The software download (185KB) and his Bitcoin/PayPal info for donations may be found at the link below.

http://www.digitalruby.com/securing-your-windows-dedicated-server/

Before we get to the setup of IPBan and if you don’t already have it installed, download a copy of .NET Framework 4.X and install it!

https://www.microsoft.com/net/download/windows

The IPBan program downloads as a simple zip file. I prefer to extract the file to c:\ipban as shown below.

From an administrator command prompt, run the following command. This creates an IPBan service that auto-starts on bootup. It uses the path I previously mentioned so if you extracted it somewhere else, you will need to change the path.

c:\>sc create IPBan type= own start= auto binPath= c:\ipban\ipban.exe DisplayName= IPBan

You will also need to make a few group policy changes either via gpedit.msc (pictured below) or via command prompt (2 auditpol commands below). Both values should be set to “Success,Failure” once completed.

c:\>auditpol /set /category:"Logon/Logoff" /success:enable /failure:enable
c:\>auditpol /set /category:"Account Logon" /success:enable /failure:enable

Now, simply start the IPBan service. You can either reboot the machine or start it from an administrator command prompt.

c:\>net start ipban

Testing

Assuming the service started, now you need to test it! You can either fire up the remote desktop connection within Windows (mstsc) and enter the wrong username/password multiple times (5) or launch hydra using Kali Linux. The following command will try multiple times before it ultimately fails… Failure is a good thing in this instance. 😉 If you don’t have the rockyou.txt password file, substitute “rockyou.txt” with “dnsmap.txt” in the command.

# hydra -V -l administrator -P /usr/share/wordlists/rockyou.txt -e ns -t 4 <my ip address> rdp

Hydra v8.6 (c) 2017 by van Hauser/THC - Please do not use in military or secret service organizations, or for illegal purposes.
Hydra (http://www.thc.org/thc-hydra) starting
[WARNING] the rdp module is currently reported to be unreliable, most likely against new Windows version. Please test, report - and if possible, fix.
[DATA] max 4 tasks per 1 server, overall 4 tasks, 14344401 login tries (l:1/p:14344401), ~3586101 tries per task
[DATA] attacking rdp://<my ip address>:3389/
[ATTEMPT] target <my ip address> - login "administrator" - pass "administrator" - 1 of 14344401 [child 0] (0/0)
[ATTEMPT] target <my ip address> - login "administrator" - pass "" - 2 of 14344401 [child 1] (0/0)
[ATTEMPT] target <my ip address> - login "administrator" - pass "123456" - 3 of 14344401 [child 2] (0/0)
[ATTEMPT] target <my ip address> - login "administrator" - pass "12345" - 4 of 14344401 [child 3] (0/0)

Taking a peek at the Windows system, we can see IPBan has a new log entry, which means the IP address is getting blocked and IPBan is working! By default, the IP address is banned for 1 hour, but this setting and many more are easily modified in the IPBan.exe.config file.