Recent Update – Hardening RDP Security with Logon Auditing

When I wrote the blog post below, I had not actually experienced any issues.  I already locked out access to servers I manage by using IP restrictions, and I wasn’t generally too worried about workstations because I do push my clients to adhere to good password policies.  Given that I manage 30 networks and over 600 systems, this seemed to be pretty safe.

Recently I had an issue where user accounts were getting locked out, but not by the user.  Not just one user, and not just one network, but different users on unrelated networks.  When I started digging into it, I discovered that IP’s originating from countries all over the world were actively trying to brute force passwords using RDP.

What concerned me the most was how specific the attacks were.  They were targeting workstations with custom RDP ports (Port Redirections as described below) and even monitoring for changes in the custom ports.  For one user I grew concerned that the redirect port 3344 was too low and too easy to find, so moved it up to 25698.  Without skipping a beat the attacks resumed on the new port.  In addition to the port, they were targeting a specific username – the actual user of that PC.  The only thing they were missing (most of the time) was the domain itself, and obviously the password.

After ramping up some security measures, enhanced router logging and reporting, and turning on some auditing policies, it became clear that this is a widespread issue that was quietly targeting almost every network I manage.  Before I knew it, one of my clients who had an old 2003 server that was unfortunately exposed to the Public interface, got hacked and encrypted with Ransomware.

The fundamental issue I found with RDP security, while it does utilize SSL encryption, is that Microsoft has not hidden or even randomized the salt used for the encryption.  The “Man in the Middle” attack can therefore insert itself into the connection and collect all kinds of data about the connection state, including last used username.

So ignore the post below where I say RDP is secure.  It’s wrong.  RDP is not secure in and of itself.  If you cannot restrict access by IP then use something else.  VPN appears to be the favored approach (client VPN to the router/gateway) or move to a third party connection broker such as TeamViewer.

I am leaving the old post as a reminder that I do not know everything, and in this case I was wrong.  The MSP was right to recommend against RDP and possibly should have even refused to do the work. 

However, since they did do the work, they should have at least inserted some measures to ensure getting in one machine did not mean being able to get into all machines.  The processes I describe in this article should be followed regardless as best practices for security. I say this because the same issue happened to one of my networks (described above) but they were not able to get any further than that one server.  The MSP in question still did crappy work, but I will give them credit for making the recommendations to not use RDP in the first place.

I had a friend contact me recently about concerns using Remote Desktop Services.  Staff at his office wanted to be able to work from home.  RDP is built in to all Professional/Business Class operating systems, and it’s free. 

Apparently the IT company they use recommended against it, declaring that Remote Desktop Protocol is highly insecure.  The company did end up getting their RDP connections but no attention to improving security was observed.

Months later, the network was hacked.  Ground Zero was a conference room PC that had an open RDP connection to the public and was somehow compromised.  The IT company used this opportunity to say, “See? We told you this would happen.”

This is my blog so I feel I am entitled to have an opinion on this.

  1. RDP itself is not insecure.  It is an encrypted connection (128-bit) that requires an authenticated connection.  It has policies in place that prevent things like user accounts with no passwords from connecting.  User accounts must either be local administrators or be added to the Remote Desktop Users security group.  
  2. In my opinion the IT company in question here was right to inform the client of the security risks, but instead of just setting up the RDP connections should have also taken steps to harden the network security around the workstations that were opened up for remote connectivity.  Stepping up now with “we told you so” is a dick move.  If I was a decision maker at this company, I would be deciding to find another IT company.

Common security pitfalls setting up RDP:

  • All Windows PC’s have a local built-in Administrator account as well as an initial administrator-level user account that was created when the PC was set up.  Typically Administrator is disabled, but equally typically on a Windows domain network, the initial user account that was created when the PC was set up has a weak or non-existent password.  This local user account is in the local Administrators group which is by default a member of the Remote Desktop Users group. (It should be noted that the username for this account could be anything – avoid using “user” or the PC name as the username for setting up the PC so it can’t be easily guessed.)
  • Default RDP port is 3389.  It is possible to override this port in the registry but typically there’s no need.  However, if you have 1 public IP address and 3 remote desktop users each wanting to connect to his or her own workstation, you have to set different ports for each workstation.  This is done on the router and it’s called Port Redirection:
    • Workstation1 – Local IP: 10.0.0.11 RDP 3389 – Public IP 206.56.98.125 Port 56896
    • Workstation2 – Local IP: 10.0.0.12 RDP 3389 – Public IP 206.56.98.125 Port 56897
    • Workstation3 – Local IP: 10.0.0.13 RDP 3389 – Public IP 206.56.98.125 Port 56898 
  • Some ISP’s change the Public IP’s for their customers frequently.  This can make using RDP access difficult if the Public IP changes – the users won’t know that the IP changed and the connection will be broken.  There are two solutions for this:
    • Obtain a Static IP from your ISP and/or
    • Utilize DDNS (Dynamic Domain Naming System)DDNS allows you to register a hostname.domain that links to your Public IP, no matter what your Public IP may be today.  This is accomplished by installing an agent on the network that sends a constant heartbeat to a public service that tracks the IP changes.  Utilizing DDNS is a good idea and many commercial and even some consumer level routers support it from common DDNS providers.  It’s anywhere from reasonably cheap to completely free. 

There are a number of easy-to-do tasks that can help prevent unauthorized access.  On a Windows Domain this can done by using Group Policies but if you don’t have a Windows Domain you can still do a lot at the workstation level by getting familiar with the Local Policies.

  1. Ensure all local accounts are secured with strong passwords:
    1. Start -> Programs -> Administrative Tools -> Local Security Policy -> Account Policies -> Password Policy

      I actually recommend a “Minimum password length” of ’10’ but the important bit is the “Password must meet complexity requirements”.  This ensures that users cannot just put in “1234567” or “password” as a password.
      Remember to reset the passwords of the local accounts, and disable the Administrator account if it’s not already.
  2. Set an account lockout policy:
    1. Start -> Programs -> Administrative Tools -> Local Security Policy -> Account Policies -> Account Lockout Policy

      This is a solid way to prevent brute force attacks.  With complicated passwords and getting locked out 30 minutes at a time it’s next to impossible to guess a password.
  3. Limit which accounts can log in using Remote Desktop:
    1. Start -> Programs -> Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment
      1. Open Allow log on through Remote Desktop Services
      2. Remove Administrators
    2. Add users to the Remote Desktop Services Security Group manually

If you find a user account is constantly locked due to attempts to brute-force the password, start logging the IP’s of the attackers and set up additional firewall rules to block future attempts from these sources.  Unless it’s from bots on many systems specifically attacking your systems this should put an end to the attacks pretty quick.

This is the easy stuff and if you are using a Windows Domain then using Group Policies makes it easier to apply these settings to all workstations, or if that’s too intrusive then you can separate out only the PC’s and Users who require RDS (Remote Desktop Services) and apply to only those systems.

More complex considerations are:

  • Two Factor Authentication
  • Signed Certificates – Password Protected
  • IP restrictions (limit which public IP’s can remotely connect)*

Two Factor Authentication just means that two authentication methods must be passed successfully to connect.  In this case, the user connects to the PC, logs in successfully using the Windows credentials, but is blocked from getting a desktop until another password prompt is successfully passed.

Two Factor Authentication is not built into connecting directly to Windows workstations and is a third party application that must be purchased or subscribed to.  If security is important to you then the costs associated shouldn’t really stop you.  I did some digging and found the costs to be generally quite reasonable. (I looked at Duo)

Signed Certificates (as opposed to Self-Signed Certificates) can be used but this is far more complicated to set up (and more costly).  The idea is to limit RDP access to the host PCs by requiring a signed and authenticated certificate using pre-shared keys to be installed to the remote PCs.  Basically, both ends of the connection must have the same certificate installed or the connection is dropped, even if Windows Authentication is successful.

On a workstation level this is probably not very practical.  I’ve never tried it either so I’m not even sure it would work, but in theory it should.  It’s a good idea but really only if you are also implementing RDP Gateway technologies to add additional security layers – in which case you have other options as well.  Plus to do it properly you shouldn’t use the same certificate for each system but rather purchase individual certificates for individual systems – which is a substantial yearly cost even at $100 per workstation.

IP Restrictions is probably one of the easiest ways to secure RDP connections but it can also be a bit inconvenient.  Basically, your router firewall rules specify which IP’s are permitted to connect to which PC’s.  Anyone probing your network looking for a way in will never even see an open port because the router will drop all traffic that doesn’t come from the specified IP’s.  The downside is the remote user must always be using the same IP to connect from.  The remote user can’t take his or her notebook to the local Starbucks to use the free WiFi to remotely connect.

I had a thought about this though.  In the same way that you can use DDNS to make the host network easy to find for the end user, you may be able to use the same concept in reverse to allow users to connect from anywhere by using a DDNS client on each workstation.  The connection is still restricted by IP but the IP can now be dynamic because it’s using the remote users DDNS client to get constant updates.  As long as the router can resolve names to an IP (internal DNS) and allows you to specify a host name vs strictly IP’s, I can’t see why this wouldn’t work.  I do this with VPN connections all the time in SonicWALL routers.

Getting back to the original reason for the post – the IT company mentioned above did none of these things.  The ground-zero PC was hacked into, then used to plant malicious software that spread throughout the network.  The hackers were able to get different types of remote connectivity to the other workstations and presumably the server to further compromise the security of the network.  Even if the original door was closed (the conference computer), access was still assured by way of the other systems.  Egg cracked wide open.

In addition to hardening the security of the RDP connection, it’s critical that systems are well protected by up-to-date antivirus software.  One in particular AV suite I like is from Kaspersky.  It’s protection is first class and it has features that renders it virtually bulletproof from tampering.  Even if there is unauthorized access to the PC, the remote user can do nothing to defeat the antivirus.  Somehow the hacker got in the door but got blocked at the elevator.

The final consideration is always the big picture.  Let’s say the hacker does somehow get past all of this security and manages to get a desktop session.  At this point, how secure is your network from malicious activity?  The AV software on the PC may prevent the hacker from installing malicious software, but will that stop data theft?  This is where, on business networks with Windows domain management, I tend to push to get user data away from the workstation. Using Group Policies I redirect user data to the file servers and I lock down all the shares to prevent ‘public’ access.  Even if a hacker finds himself on a desktop without a domain account, there’s virtually no corporate data he or she can access. 

Anyway, the scope of this post is to harden RDP connectivity.  I’ll talk about how to secure internal networks in separate posts.