Remote Desktop Monitoring – Advice for improving RDSH security

As a system administrator, you should be aware of who is doing what, when, on what server, and from where people are connecting in order to keep Remote Desktop Services (RDS) secure. So, to keep the environment secure, you need to perform remote desktop monitoring.

The problem with RDS is there is no such monitoring system. Because many users are connecting to your various servers, it is necessary to know who is on the servers and to audit all user activities and which apps are being run on the servers.

Take control. Ensure security. If you expose RDS to the internet, a number of problems can occur that can make it vulnerable:

Direct RDS exposure to the Internet

By default, only members of a local admin group can connect to the remote desktop server. If you have a weak admin password, or even an administrator without a password (yes people, it is still happening in 2018!) a remote attacker can easily gain access to the server.

A common scenario is that you install a third-party application that creates a user who is a local administrator, but the person who installed the app did not change the default user’s password, creating a weak spot. Just a few weeks ago, I heard about a hotel that installed a hospitality application, and an attacker gained access by using the default user password for the application. Of course, that user is a local admin, and the situation caused a big mess.

If you need to expose RDS to the internet, the first thing I recommend is to configure it so that after five failed attempts the user locks. I also recommend disabling the administrator default user and creating another user.

Attack on medium client-compatible level encryption

Some environments, especially those of older clients, do not support strong encryption because of their many remote desktop clients. In that situation, the admin often changes the encryption setting to medium, allowing attackers to exploit the weak encryption and gain access to the server.

Denial-of-service (DoS) attacks and Network Level Authentication (NLA)

Before NLA authentication, when connecting to a server you would enter the server name, the server would open a session, and you would then supply credentials. Opening a session would use the server’s hardware resources, making them subject to a DoS attack. An attacker would open a lot of sessions, causing a terminal server to hang and stop accepting new sessions. NLA sends the credentials to the server before the session opens. The server then validates the credentials and allows or doesn’t allow the user into the server. If you have NLA on your server (everything above Windows Server 2008 has it), we highly recommend enabling it because it will prevent DoS attacks.

Remote Desktop Services – Advice for improving security

Here are a few tips on how to make your Remote Desktop Services more secure:

Do not expose the RDS server directly to the Internet

The most important piece of advice is to not expose the RDS server to the internet. What advice, you might say! During my years as a consultant, I observed people exposing one terminal server to the internet and then after that all the other servers of the company. This is a bad practice, and I see it even today. If this is done to what we’ll call a “gateway” server, that server’s security is relaxed. If an attacker gains access to that server he can easily gain access to the other servers. Don’t do it!

Use the Remote Desktop Gateway role to provide access to the Terminal servers

I know it is pain in the ass to configure RD Gateway and to allow everybody out-of-the-box access to the RD Gateway because of the certificate you need to deploy for the client, but Microsoft created this role for the reason. It strongly secures access to the RD environment. Expose only the RD Gateway, disable RDP connections directly to the gateway, and allow people to only open pass-through connections.

This increases RD security – not only do users need to have a certificate to connect through the RD gateway, but they also need to identify a computer name behind the gateway to which they will connect. This is a great add-on to RDS.

Have I mentioned enabling NLA?

Enable it, make it mandatory. NLA is a great way to secure your environment. It’s a good thing that NLA is on WS 2012, and even better, it is enabled by default.

Limit users who can log in using Remote Desktop

Don’t add domain users to the group of remote desktop users, or something that is even more risky – to the local administrator’s security group. Create different security groups with access to remote desktop servers and perform remote desktop monitoring of who is connecting to them.

Set an account lockout policy

This is a great way to stop a brute force attack. Choose a reasonable number of tries after which a user is locked out, maybe five.

The account policy can be found in local security policy (secpol.msc) > account policies > account lockout policies. Set values for all three options – five invalid attempts, five-minute lockout with a reset after, let’s say, 15 minutes. This will greatly increase the chances that a brute force attacker will be rejected.

Change the listening RDP port

The default is always 3389, but personally I don’t like this policy as it creates confusion for the end users. I prefer default settings, but if you would like to change them, you can do so under HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp

If only administrators are accessing a server via the RDP, you can change the port settings. However, if there are end users and you have a Remote Desktop Session Host role instead of an administration, I do not recommend it.

You should monitor who has the access to the RD Session Host or through the RD gateway. If you need a simple application to monitor access to the remote desktop server with an installation time of under three minutes, check out Syskit Monitor.

Syskit Monitor can:

• Track all RDS user connections
• Track the number of users connecting daily
• Discover your most active users
• List all the hostnames of connected clients
• Track internal and public IP addresses

Download our Syskit Monitor 30 day-free trial and explore all the benefits it offers.