As we all know the increasing use of RDP is ever increasing. But with more use comes more people wanting to get in thru this protocol. This is why having strong security-based control in place are ever more important. Luckily, Windows Group Policy can be enabled to protect Terminal Services.
Below are some settings that would help you lock down the farm:
- Enable a Audit Policy for successful and failed logins on all server including Terminal Servers, best if you deploy at the root of the forest with Loopback set to merge.
- Change RDP port from 3389 to a different high ranged port. Article here on how to change this: Cyber Security/Windows: Everyday security for RD[Protocol], but how? – I.T.HINK …So you don’t have too…https://www.g15it.com/cyber-security-windows-everyday-security-for-rdprotocol-but-how/
- Create a Security Group with the Terminal Servers in this group and then assign this group to the policy in step 4 with authenticated users binded to the policy
- Move TS into their own OU that below the Audit Policy and enable a security lockdown policy with the following settings:
- Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout > Account Lockout Threshold is set to 2 or 1 and set it to Enabled
- Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout > Lockout Duration of 99998 and set it to Enabled
- User Configuration > Policies > Administrative Templates > System > Prevent access to registry editing tools and disable regedit from running silently and set it to Enabled
- User Configuration > Policies > Administrative Templates > System > Do not display Getting started welcome screen at login and set it to Enabled
- User Configuration > Policies > Administrative Templates > System > Ctrl+Alt+Del > Remove Change Password and set to Enabled
- User Configuration > Policies > Administrative Templates > System > Ctrl+Alt+Del > Remove Task Manager and set to Enabled
- Ensure that IPS and IDS is enabled on the WAN to LAN rule destined for the Terminal Server if you are pushing the access to the internet thru your customer TLDN registrar and if you have a Sophos or Sonicwall make sure IPS is set to it’s highest limit and DDoS filtering is enabled
6. If your customer has a PKI, make use of a Computer Certificate with Server Authentication so that end-users will need to have a valid Kerberos login and valid PKI-based certificate to log into your Terminal Server environment.
- a. While annoying might be good idea to set validation period to 6 months on this certificate or even less if you want to ensure the certificates are safe and not compromised.
7. (Optional) we have found a need for Auto Log Off and I remembered from my past life about a Source Forge Project called Lithnet Auto Log Off and it does the following:
The source code for this ADMX is here: https://blog.lithnet.io/2012/01/lithnetidlelogoff-log-off-users-after.html
In closing: Sure 1 or 2 incorrect user login lockout may be a bit anal but what worse a compromised network or a complaining president or sales person? – I’d rather be the a-hole IT person they dislike than the IT company they fire cause they got breached! 😛
Remain frosty peeps!