Hardening RDP if you have to use it

Understanding why RDP is necessary and who needs access are important when hardening the RDP server. For example, if staff are using the server to access an application, you should not allow highly privileged accounts to log on to the server. If it is a server that is used for administrative tasks, it should only be accessible from administrative workstations, by administrators. Domain Administrator privileges should be used as sparingly as possible, only on domain controllers.

Tip

Over-use of administrative privileges, especially Domain Administrator, is a common theme in ransomware attacks. Restricting the number of accounts with these privileges, and only using them on higher trust devices can reduce the severity of a network compromise

If you really do have to allow RDP, even internally, then hardening the RDP server and service is a good idea, as well as some client side hardening. Aside from the controls mentioned above (patching, MFA etc), you should look at the following settings, in order to prevent or mitigate certain RDP-specific attacks.

Naming: When we say RDP Server, we mean the device that is receiving the RDP connection. RDP Client means the device initiating the connection. This is not a reflection of whether the device is running a Windows Server or a workstation version of Windows.

Tip

Many of these controls can be applied automatically across your domain through Group Policy Objects. Check the documentation for your specific operating systems for the exact configuration settings to apply.

Server side

These settings apply to the RDP server, whether or not that is a server or a workstation.

  • Run endpoint protection software
    Ensure you have visibility and control over what gets run on the RDP server.
  • Enable MFA

As with any password reliant access system, MFA should be utilized to reduce the risk of brute forcing. App based MFA is preferred.

  • Configure password lockout settings

Another measure to prevent brute forcing is setting the number of attempts for a user to enter a password, and the length of time they will be locked out for after a certain number of unsuccessful attempts.

  • Only allow access from specific sources
    Whether this is using the Windows firewall, or a network firewall, limit what devices can talk to the RDP service, only allowing sources that are expected to connect to the RDP service.
  • Network Level Authentication (NLA)
    The RDP server should be configured to only accept RDP connections using NLA. This is a mitigation against vulnerabilities such as Bluekeep.
  • Disabling device redirection
    Devices such as printers and other USB devices can present security issues if they are allowed to be redirected over an RDP session. Disable the following:
    • COM Port redirection
    • LPT Port redirection
    • Client Printer redirection
    • Plug and Play Device redirection
    • Drive redirection
  • Set session timeouts
    Idle sessions should lock the screen after 15 minutes of inactivity. Idle sessions should be disconnected after 60 minutes.
  • Disable Clipboard redirection
    Clipboard redirection is often abused by attackers to copy text and even files across the network. This should be disabled.
  • Allow and Deny users and groups
    RDP can be configured to only allow certain users or groups, as well as to explicitly deny users or groups. Use these settings to ensure that access to the RDP server is limited only to the accounts with a specific need to access it.

Hardening the RDP client

Some important security settings are configured on the client, rather than the server. Set these on your devices, and ensure that they are set on other devices such as your IT service providers computers.

  • Do not allow passwords to be saved
    Attackers look for credentials that have been stored on devices, and use them to move laterally across the network. Passwords should only ever be stored in secure places such as password managers