Before I Begin
Before I get started, I want to mention that this article in by no means a comprehensive guide to Terminal Service security. I could probably write a good sized book on the subject, so there is no way that I can adequately cover the topic in a few pages. Instead, I’m going to give you some basic pointers for securing your Terminal Service environment.
Planning Your Deployment
Let’s start by talking about planning for Terminal Server deployment. I know that many organizations are strapped for cash, but rule number one is that a Terminal Server should never be assigned double duty. To put it simple, you should never run the Terminal Services along side some other server application such as Exchange Server. Doing so can place a major strain on server resources such as the CPU and memory, and creates a huge security risk.
Probably the best example of a “double duty” configuration that presents a security risk is running the Terminal Services on a domain controller. Naturally there is the issue that if one of your users manages to exploit a weakness and gain access to the underlying operating system, they have gotten access to a domain controller, but the security risks are actually much worse than that. At least some versions of the Windows Terminal Services require users to have Log on Locally permissions in order to log in through a Terminal Service session. If the Terminal Services are running on a domain controller and this permission is applied, then users are granted Log on Locally permissions to all of the domain controllers in the domain. This means that if a user can gain physical access to a domain controller, they could just log in.
Another common mistake that administrators make during a Terminal Service deployment is using an inappropriate security model. As I’m sure you’re aware, each new version of Windows Server that comes out offers new security features, but maintains backward compatibility with previous versions of Windows Server. Often though, the only way to maintain this backward compatibility is to sacrifice some security features that the older operating system doesn’t support.
This is exactly what happens when you deploy the Terminal Services. When you install the Windows Server 2003 version of the Terminal Services, you are given the option of using “relaxed security” as a way of maintaining backward compatibility with older versions of Windows Server. The Windows 2000 version does something similar by offering you the choice of using either permissions compatible with Windows 2000 Server or permissions compatible with Terminal Server 4.0 Users.
To demonstrate how these permissions are a factor in network security, let’s pretend that you are running the Terminal Services on a Windows Server 2003 box, but you have some Windows 2000 Servers in your environment and you are running some older applications. You aren’t completely sure that Windows Server 2003’s security is completely compatible with your older servers and applications, so you go with the relaxed security model. A year later though, you have upgraded your remaining servers to Windows Server 2003 and brought all of your applications up to date. The problem is that your Terminal Server is still running in relaxed security mode.
This is where planning comes into the picture. Any time that you are running a mixed mode environment, I recommend maintaining a list of things that should be done once all of the servers are brought up to date with the latest operating system. Resetting Terminal Service security should be an item on such a list. Fortunately, when you choose to run the Terminal Services using a relaxed security model, you are not making a permanent commitment. Your server’s security mode can easily be changed by opening the Terminal Services Configuration console and selecting the Server Settings container, as shown in Figure A. You can then right click on the Permission Compatibility option and select the Properties command from the shortcut menu. When you do, the Permission Compatibility dialog box will appear. Just select the Full Security option and click OK.
Figure A: The Server Settings container allows you to control some general aspects of Terminal Service security
The screen shown in Figure A can be used to control a number of security related settings. In Windows Server 2003, most of these options are set to a secure setting by default. However, Windows 2000 uses the exact same options, but they are insecure by default.
The first option on this screen is to delete temporary folders on exit. The Terminal Services store user environment data in temporary folders during a user’s session. Microsoft recommends that you delete this data at the end of the session to prevent malicious users from gaining access to another user’s environment information.
The second option on the screen is to use temporary folders for each session. This goes back to the user environment information that I just talked about. You should use temporary folders for each session
One last setting on this part of the console that is related to security is the Active Desktop setting. As you may recall, Active Desktop was a technology that Microsoft released with an old version of Windows (I think that it was Windows 98). The idea was that you could run HTML code directly on the Windows desktop so that you could have various applets that would display information that’s important to you directly on the Windows desktop. Active Desktop was a good idea in its time, but today we know that not all Web applets are trustworthy. To prevent users from accidentally executing a malicious script, Active Desktop should be disabled.
Staying up to Date
Although there are lots of ways that you can fine tune the Terminal Services to provide you with better security, I tend to think that the biggest threats to the Terminal Services are the applications that run on it and the underlying server operating system. If a vulnerability exists in one of the applications that is being run on the terminal server or if a vulnerability exists within Windows itself, the vulnerability could be exploited in an effort to compromise the underlying Windows operating system.
This is why patch management is so important. Once a security vulnerability is made public, it doesn’t take very long for hackers to figure out how to exploit that vulnerability. Most software companies routinely release patches to correct known vulnerabilities. If a well known vulnerability exists though, and you leave your system unpatched, then you become an easy target for hackers.
Patch management used to be a very expensive and time consuming task, but it is easier than it used to be to keep systems up to date. Microsoft makes a utility called Windows Server Update Service (WSUS) that will automatically keep most Microsoft products up to date. Keep in mind though that although WSUS doesn’t patch non Microsoft applications, it is critically important for you to keep up with patches for any application that might be running on your terminal server.
Isolate Network Traffic
One other thing that you can do to help increase Terminal Service security is to isolate terminal service related network traffic from other types of network traffic. Terminal Server clients need to be able to communicate with Terminal Servers, but they do not need to communicate directly with back end servers, such as database servers. You could isolate client traffic from other types of traffic by placing two NICs into your Terminal Server. One NIC could connect to a network segment containing the client machines, while the other NIC connects to a network segment that services only backend servers (a backbone segment). In doing so, you not only improve security, but you also improve efficiency because clients are not competing with backend servers for network bandwidth.
Conclusion
As you can see, it’s impossible for me to create a comprehensive guide to Terminal Service security in a few short pages. Instead, I have given you a few basic security techniques that you can use to increase the security of your own Terminal Service deployment.
