Introduction
Some of the greatest enhancements to Terminal Services in its Windows Server 2008 implementation pertain to its overall security. Being one of the most prolifically used forms of remote server access by both administrators and users alike, this is not too much of a surprise and is greatly welcomed. In this article we will go through several things you can do to make your Terminal Server environment more secure.
Advertisement
Using Two-Factor Authentication
Do you remember watching the Little Rascal’s when you were growing up? If so, then you remember that every time someone wanted to walk into a He-Man Woman Hater’s club meeting, they first had to give a special knock on the door, followed by presenting the super secret official club handshake. Even a group of rambunctious seven year olds knew the importance of having two forms of authentication, so it makes that much more sense that we would want to do the same when thinking about network security.
There are several different forms of two factor authentication available, but the most common that is supported by Terminal Services is the use of Smart Cards. In using a smart card, a user not only has to provide valid logon credentials, but they must also be able to physically connect the smart card to the device they are using as a remote terminal.
In order to require smart card authentication, you must create a Group Policy Object that can be applied to your Terminal Server. In the GPO, browse to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options and enable the Interactive Logon: Require Smart Card setting. Also, you will need to enable Smart Cards to be redirected to the Terminal Server by placing a check in the Smart Cards checkbox on the Local Resources tab of the Remote Desktop Connection client on user workstations.
Figure 1
Enforce Network Level Authentication for All Clients
In previous implementations of Terminal Services authentication to the server was achieved by connecting to a session on the server and entering login credentials into the Windows Server logon screen. This may seem fairly trivial, but from a security perspective being able to achieve a session logon screen can disclose information about our network (domain name, computer name) or leave our server vulnerable to a denial of service attack to anybody who happens to have that servers’ public IP address.
Network Level Authentication (NLA) is a feature introduced in version 6.0 of the Remote Desktop Connection Client which allows a user to enter their logon credentials prior to being displayed a Windows Server logon screen. Windows Server 2008 allows us to utilize this ability and require all connecting clients to use it.
Figure 2
In order to use NLA, you must be using a Windows 2008 Server, and your connecting clients must support CredSSP (Windows XP SP3, Windows Vista, Windows 7) as well as be running Remote Desktop Connection 6.0 or higher. You can configure your Terminal Server to require its clients to use NLA in a few different locations:
- During the initial Terminal Services role installation process, when you are presented with the Specify Authentication Method for Terminal Server screen, select the Allow connections only from computers running Remote Desktop with Network Level Authentication option.
- Access the Terminal Services Configuration MMC Snap-In, right click the terminal server connection being used by your clients and select properties, and select the Allow connections only from computers running Remote Desktop with Network Level Authentication option.
- Create a Group Policy Object, browse to Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Security, enable the Require user authentication for remote connections by using Network Level Authentication setting, and apply it to an OU containing the terminal server.
Change the Default RDP Port
By default, a Terminal Server uses port 3389 for RDP traffic. By default, every single competent hacker in the world knows that a Terminal Server uses port 3389 for RDP traffic. That being the case, one of the quickest changes you can make to your terminal server environment to detour potential intruders is to change this default port assignment.
In order to change the default RDP port for a Terminal Server, open regedit and browse toHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp. Locate the PortNumber key and replace the hex value 00000D3D (which is equivalent to 3389) to the appropriate hex value for the port you wish to use.
Alternatively, you can change the port number used by your Terminal Server on a per connection basis. While still using regedit, browse to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\connection name. Again, locate the PortNumber key and replace the hex value in place with the value you wish to use.
Keep in mind that when changing this setting on your server, all connecting clients will need to be sure they are connecting to the Terminal Server with the new port extension tagged on to the servers IP address. For example, connecting to a Terminal Server with an internal IP address of 192.168.0.1 which is now using the non-standard port 8888 would require a user to enter 192.168.0.1:8888 into the Remote Desktop Connection client.
Figure 3
Use Easy Print and Limiting Redirected Printers
Printing from devices locally attached to client workstations has always been a downfall of Terminal Services prior to Windows Server 2008. In order to do this, you had to ensure the exact same version of the printers’ driver was installed on both the client and server, and even then this didn’t always work. From a security standpoint, we never want to install any more drivers to our system than we absolutely have to. Each driver installed to the server has the potential to broaden its attack surface.
Windows Server 2008 has introduced a feature called Easy Print which radically changes the way locally-attached printers are handled. In essence, TS Easy Print is a driver that serves as a proxy that all print data is redirected through. When a client prints to a device using the Easy Print driver, the data and print settings are converted to a universal format that is sent to the Terminal Server for processing. In doing this, after clicking print the print dialog box is launched from the client and not in the terminal session. This means that no drivers have to be installed to the Terminal Server in order to process print jobs from locally-attached print devices.
In order to configure Easy Print you will need to ensure that all locally-attached print devices have logical printers configured on the client workstations that are set to use the Easy Print driver. The Easy Print feature is supported by all Windows XP SP3, Windows Vista, and Windows 7 clients running Remote Desktop Connection 6.1 or later, and .NET Framework 3 SP1.
Figure 4
Once you have configured the locally-attached devices at the workstation level, it is a good idea to ensure that it is the only printer being redirected to the Terminal Server is the printer using TS Easy Print, which should be set as the default printer. You can do this by creating a Group Policy Object and browsing to Computer Configuration\ Administrative Templates\Windows Components\Terminal Services\Terminal Server\Printer Redirection, and enabling the Redirect only the default client printer option.
Limit Users Accounts
If you hire someone to plow your fields then typically all you need to do is give that person the keys to the tractor… not the keys to the combine, the barn, and the four-wheel drive. That is not just because they don’t need a combine to do the task at hand, but because you don’t really want to see your brand new John Deere turn up missing or find it in a ditch. Using that same train of thought, we have to keep in mind that when a user is connecting to and working directly from a server they may inherently have access to several things they don’t need, and in order to create a more secure environment we need to limit this. This not only protects against a users’ credentials being compromised, but also protects against a legitimate user with illegitimate intentions. A couple of things we can do include:
Use Specific Accounts for Terminal Users
It is not uncommon for a user to work locally with certain applications and then access a Terminal Server for access to other applications. Using the same user account for both local and terminal access is easier from a management standpoint, but it also makes things easier from the viewpoint of an attacker who simply has to compromise one set of credentials to access a multitude of applications. Creating a separate user account for Terminal Server access and limiting its permission set to only the necessary applications will greatly mitigate the impact of this type of compromise.
Use Software Restriction Policies
Software Restriction Policies are by no means a new development, but they are something I find drastically underutilized. Software Restriction Policies can be configured to allow or deny the use of certain applications and are commonly used in public computer or kiosk environments, although they are great in Terminal Server environments as well.
Creating Software Restriction Policies is a bit beyond the scope of this article, but you can read more about it atMicrosoft TechNet.
Monitor User Access to Terminal Servers with Group
By default, only members of a Terminal Servers Remote Desktop Users group (and Domain/Local Administrators) can log on to that Terminal Server. It is highly recommended that you document and regularly audit the members of this group. If a user doesn’t NEED to log in to a Terminal Server, then remove them from the Remote Desktop Users group.
Configure Additional Security with Group Policy
A great deal of security enhancements for Terminal Server environments are available through Group Policy. Here are a few of my favorites:
1. Restrict Terminal Services Users to a Single Remote Session
In most cases there is no need for a single user to initiate multiple sessions on a Terminal Server. Allowing this can result in an environment that is vulnerable to a denial of service attack should a users credentials be compromised. You can configure this setting by browsing to Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Connections within your GPO.
2. Do Not Allow Drive Redirection
Unless you have a specific need for it, allowing a user to access local drives from a Terminal Server session can create a very unsecure channel of communications. With this ability, not only can a user copy data to a Terminal Server, but that data may be of a malicious nature and could possibly even be executed on the server.
You can configure this setting by browsing to Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Device and Resource Redirection within your GPO.
3. Set Time Limit for Disconnected Sessions
In general, it’s not a good idea for a user to exit a session without fully logging off. Should someone gain control of this session they may walk right into a piece of sensitive data or find themselves already authenticated to another network application. A great way to combat this is to set a very low time limit for disconnected sessions. Once this time limit is reached the session will be terminated.
You can configure this setting by browsing to Computer Configuration\Administrative Templates\Windows Components\Terminal Services\Terminal Server\Session Time Limits within your GPO.
4. Disable Microsoft Windows Installer
Simply put, only administrators should be installing applications to a Terminal Server. In most cases users would not be able to install applications in the first place since they should not be logging on with administrative access. However, if certain users are required to have elevated priveleges, you can limit their ability to install some programs by disabling the Microsoft Windows Installer.
You can configure this setting by browsing to Computer Configuration\Administrative Templates\Windows Components\Windows Installer within your GPO. It is important that you configure this setting to Enabled rather than Always. Doing this ensures that you can still publish applications to the Terminal Server via Group Policy. Using the Always option prohibits this from occurring.
5. Folder Redirection
If I had a dollar for every time I’ve logged into a Terminal Server and found sensitive or mission critical data sitting on a users local desktop I would be sitting on a beach somewhere writing this article rather than in my office. Even though as network administrators we provide multiple public and private locations for data storage, some users cannot resist the impulse and convenience of storing data on their desktop. As an alternative to sending our network users to the stockades (tempting isn’t it?), we can simply trick them by redirecting their Desktop to an appropriate storage location on a file server.
You can configure this setting by browsing to User Configuration\Windows Settings\Folder Redirection within your GPO. The user desktop is by no means the only folder that we can redirect, and I recommend looking through all of the available to folders and redirecting whatever you think is appropriate for your environment.
6. Prohibit Access to the Control Panel
Just as with the Microsoft Installer, users should not have access to this in general. However, if you do have users who require administrative privileges then you can limit their access to the system control panel by configuring this setting.
You can configure this setting by browsing to User Configuration\Administrative Templates\Control Panel within your GPO.
Enable Auditing
When I was in college we had the “benefit” of a communal refrigerator. Most of the dorm’s tenants respected the golden rule of not eating food that was not yours, but I fondly remember an occasion during my freshman year where food started turning up missing. This went on for quite a while and there was not really a lot we could do in terms of preventing this from happening while still using the service. That being the case, a few of us decided to take a more passive approach to solving this security issue by putting a freshly baked batch of brownies in the communal fridge. Sure enough, we found the culprit by keeping an eye on who spent the majority of the next day in the bathroom. I guess that laxative brownie recipe did come in handy.
The point of that story is that in a lot of situations, we aren’t going to be able to prevent a security breach, but with an effective audit strategy in place we can find out when the breach occurred, how it occurred, and sometimes even who did it. It’s important that we select the appropriate items to audit on our Terminal Server so that we get the information we need without being overloaded with too much information. Microsoft recommends the following auditing settings:
- Audit Account Logon Events - No Auditing
- Audit Account Management - Audit Success and Failure
- Audit Directory Services Access - No Auditing
- Audit Logon Events - Audit Success and Failure
- Audit Object Access - Audit Failure
- Audit Policy Change - Audit Success and Failure
- Audit Privilege Use - Audit Failure
- Audit Process Tracking - Audit Failure
- Audit System Events - Audit Success and Failure
Along with this, you can also use Connection Auditing within Terminal Services. This allows you to audit several Terminal Server specific items. In order to view and configure these settings open the Terminal Services Configuration snap-in, right-click the connection you wish to enable auditing for and click Properties. Go to the Security tab, click Advanced, and type the user name of the account you wish to enable auditing for. At this point you can select one of the listed options.
Figure 5
Conclusion
This article is by no means all inclusive guide for everything you need to know about Terminal Server security, but it does encompass several of the big things you need to do and a lot of things I often see overlooked. Terminal Services has come a long way since its original inception and where as security was once thought of as a weak point, this is no longer the case when the proper configuration changes are made.
No comments:
Post a Comment