Hardware

Lock IT Down: Safeguard Windows 2000 Terminal Services from attack

Dealing with security issues youll face in a Terminal Services environment


Windows 2000 Terminal Services is an incredibly useful feature of Windows 2000 because it supports Remote Administration and allows older PCs to be able to use applications that they normally would be incapable of running. However, Terminal Services presents a very unique set of security challenges. In this article, I’ll describe some of the security issues that you’ll face in a Terminal Services environment. I’ll then go on to provide some recommendations for dealing with these potential vulnerabilities.

Security challenges
Many people feel that, by its very nature, a terminal session is more secure than a standard workstation connection. In some ways, this statement is true. After all, if a profile that you’ve configured is controlling the user’s entire session, and all of the user’s applications are running directly from the server, then the session does tend to be secure.

However, even in an environment such as this, there are still some serious issues that must be addressed. These issues fall into three primary areas:
  • Securing the users’ workstations
  • Securing the connection to the terminal server
  • Securing Terminal Services itself

Securing the users' workstations
The most common security mistake that I see administrators make in a Terminal Services environment is neglecting the workstations. It’s not surprising that network administrators miss this step because Terminal Services is designed to be workstation independent. From a functionality standpoint, the only thing that matters is that the workstation runs a thin client and is able to physically attach to the terminal server. From a security standpoint, however, there is much more to be concerned about when it comes to workstations.

If your users use workstations in the office to access the terminal server, then it makes sense to take some steps to secure those workstations. Unfortunately, if you have users who access the terminal server from their home PC, then there’s little that you can do in the way of workstation security.

For any workstation that accesses the terminal server, I recommend locking down the workstation to the point that the terminal client is the only thing that will run on the workstation. By doing so, you can prevent someone from running a hacker utility in the background during a terminal session, or infecting the machine with a virus that could potentially spread throughout your network.

The techniques for locking down a workstation differ considerably among operating systems. For Windows XP and Windows 2000 workstations, you can lock down the operating system by applying a few simple policy settings. Locking down a Windows 9x workstation is considerably more difficult. For more information about securing a Windows 9x workstation, see the Daily Drill Down “Seven steps to Windows 98 desktop security.”

As you lock down the operating system, your goal should be to prevent the user from running anything other than the terminal client, and maybe some antivirus software. Ideally, you should make the terminal client load immediately after the user logs into the workstation. Some operating systems will also allow you to log the user out automatically when they close the terminal client. Both of these procedures vary from operating system to operating system and are beyond the scope of this article.

I also recommend taking some time to lock down the system’s CMOS setup. You can configure the CMOS to only boot after the user has supplied the proper password. By doing so, you can prevent the user from booting the system from a bootable CD or floppy disk.

Securing the connection to the terminal server
The second main area that you must examine when analyzing Terminal Services security is the connection between the client and the terminal server. In its simplest form, the connection is nothing more than a TCP/IP route between the client and the server.

If no one accesses the terminal server from outside of your office, then there isn’t much you’ll have to do beyond the typical security measures to protect data flow. If you do have users accessing Terminal Services from outside the organization, you’ll probably want to take steps to secure the RAS, VPN, and/or Internet connection that your external user uses to access the terminal server. For more information about securing RAS, see the Daily Drill Down “Increasing Windows 2000 RRAS security.”

If you are dealing with users accessing the terminal server from outside of your organization, remember that Terminal Services relies on the Remote Desktop Protocol (RDP). The RDP protocol is a TCP/IP-based protocol that’s designed to be a part of the T-120 protocol family. The RDP protocol uses port 3389. Therefore, you’ll have to make sure that your firewall doesn’t block this port.

Regardless of whether you must contend with internal terminal server users, external users, or both, I recommend implementing some form of encryption. Implementing the IPSec protocol is a start, but Terminal Services actually offers its own encryption algorithms.

To control Terminal Services' encryption level, open the Terminal Service Configuration console, found on the Administrative Tools menu. When the console opens, select the Connections container and you’ll see the RDP-TCP connection appear in the column to the right. Right click on the RDP-TCP connection and select the Properties command from the resulting context menu. You’ll now see the RDP-TCP properties sheet.

If you look at the RDP-TCP properties sheet’s General tab, you’ll see that by default, the encryption level is set to Medium. You can select high encryption, but doing so may affect the server’s performance, as higher encryption levels require more CPU time and greater bandwidth.

Securing Terminal Services itself
The final area that you must focus on is the terminal sessions themselves. There are several things that you can do to make the terminal sessions more secure. First, implement auditing and check the security logs on a daily basis. Auditing works in the exact same way for a terminal session as it does for a normal session. The only difference is that if you audit successful or failed login attempts, you’ll see a little bit more information in the log than usual. At a bare minimum, you should audit failed logins so that you can see if someone is trying to exploit your terminal server.

Next, review which users are allowed to use Terminal Services. You can do this by opening the Active Directory Users and Computers console and looking at the Allow Logon To Terminal Server check box on the Terminal Services Profile tab, as shown in Figure A.

Figure A
Be careful to whom you grant terminal service privileges.


Generally, if Terminal Services is running in Remote Administration mode, then terminal service permissions are granted only to administrators by default. If, however, the terminal server is running in Application Server mode, then permissions are granted to every member of the Users' group. The Users' group contains all of the domain users, so everyone in the entire domain has access to Terminal Services by default. Keep in mind that the Users' group includes both authenticated users and interactive users. Interactive users are anonymous users who may be accessing the domain from a trusted domain or from the Internet.

Unfortunately, Windows 2000 requires you to grant privileges to Terminal Services on a per-user basis. You can’t simply set up a group and grant the group Terminal Services privileges. Therefore, you’ll have to go through and manually remove access from any users you don’t want accessing Terminal Services.

When you are doing this, make sure that anonymous users can’t use Terminal Services from across the Internet (unless you require such functionality). To prevent anonymous users from using Terminal Services, I recommend that as you go through the user list, you remove the terminal service permissions from all service accounts and from any account that doesn’t represent an actual user. For example, Internet Information Server uses an account named IUSR_servername to allow anonymous users to access Web resources. You should make absolutely sure that this account doesn’t have Terminal Services privileges.

Another potential security vulnerability is that regardless of whether Terminal Services is running in Remote Administration mode or in Application Server mode, the Administrator account is given access to Terminal Services by default. If you’re really concerned about a security breach, but you still need Remote Administration capabilities, try setting up another user account that blends in with all of the other user accounts, but has administrative privileges. You could then grant this account Terminal Services permissions, and revoke the permissions from the Administrator account. By doing so, you’ll still be able to conduct a remote administrative session, but a hacker will have to work a lot harder to figure out which account is used for Remote Administration.

You should take this step even if you’ve renamed the Administrator account to something else, because there are many different hacker utilities that can detect which account is the Administrator account. Simply using a completely different account and revoking Terminal Services privileges from the main administrative account is a good way to start securing the system.

Using profiles
Another good way to secure Terminal Services is to implement mandatory profiles for terminal service users. As you saw in Figure A, the Terminal Services Profile tab on a user’s properties sheet contains a place where you can specify the profile to be used during a terminal service session. Specifying a mandatory profile is a great way of ensuring that terminal service users are given a desktop containing only the desired icons. If a user only needs access to a single application, you could even create a mandatory profile that’s designed to automatically load that application.

Group policies
If you implement mandatory profiles as suggested above, then you can control which applications are available to the users through the desktop. However, for the most part, a profile is cosmetic. Even if you’ve implemented a very restrictive profile, it may still be possible for a user to run unauthorized applications or access system files through Windows Explorer, My Computer, the Run prompt, and so on. To truly secure the system, you must implement a group policy that restricts access to any feature that a user potentially could use to gain access to any unauthorized files or applications.

If you do decide to implement a group policy for your terminal server users, you must be careful as to how you do so. Remember that when a user logs on, the domain level group policies are applied first, followed by the computer policy. Therefore, if you apply the group policy at the domain level, then the policy will be applied to the user, regardless where they log on from. This means that the policy will be active whether the user is using Terminal Services or simply accessing the network through a standard client/server session. The best way to get around this problem is to place your terminal servers in an Organizational Unit (OU) that’s separate from the OU containing other member servers. You may then apply an OU level group policy to the OU containing the terminal servers. To find out more about user profiles and group policies, see the Daily Drill Down “Understanding Windows 2000 Group Policies.”

Compatibility mode
If you are running Terminal Services in Application Server mode, then you can increase security by installing Terminal Services in a way that makes it compatible with Windows 2000 users only. This will ensure that users that are running Windows 9x or Windows NT Workstation won’t be able to access Terminal Services.

During the installation process, you’ll see the screen shown in Figure B. As you can see in the figure, the Terminal Server 4.0 mode offers backward compatibility to older applications. However, in doing so, this mode exposes critical operating system components, such as the registry and various system files. If your users will be using Windows 2000 or Windows XP to access Terminal Services, and you aren’t planning on running any legacy applications, then you can enhance the security by using Windows 2000 mode.

Figure B
Windows 2000 mode is more secure than the Terminal Server 4.0 compatibility mode, but it still has limitations.


Overriding user settings
So far, you’ve seen how each individual user who has access to the terminal server can establish a session based on his or her own profile and policy settings. However, you can make the terminal server more secure by overriding individual user settings with blanket settings that apply to any user who’s using Terminal Services. To do so, open the Terminal Service Configuration console, found on the Administrative Tools menu. When the console opens, select the Connections container and you’ll see the RDP-TCP connection appear in the column to the right. Right click on the RDP-TCP connection and select the Properties command from the resulting context menu. You’ll now see the RDP-TCP properties sheet.

Now, look at the properties sheet’s Logon Settings tab. This tab gives you a choice between using client-provided logon information or a specific user name and password. If you decide to use a specific user name and password, then a user will have to log on to the network by using his or her individual user name and password. The user must then have permission to use Terminal Services. Upon attaching to the terminal server, the user must provide the credentials from the designated account in order to gain access. By using a designated account, you’ve required the user to provide two different sets of logon credentials. Additionally, because everyone is using the same account to access Terminal Services, it’s easy to monitor what permissions this account has access to.

The RDP-TCP Properties sheet also allows you to override individual settings on the Sessions tab and on the Environment tab. The Sessions tab contains options that allow you to override settings for ending a disconnected session, an idle session limit, and an active session limit. You can also use this tab to control how Terminal Services should react when a session limit is reached or when a connection is broken. In addition, you can control whether someone is allowed to reconnect from the previous client only or from any client.

The Environment tab allows you to override settings from the individual user’s profile. You can configure Terminal Services so that a specific program loads any time that someone attaches to the terminal server. Additionally, the Environment tab allows you to boost performance by globally disabling the wallpaper.

Conclusion
Terminal Services can be a very useful feature, centralizing control while still allowing users to run necessary programs. On the flip side, Terminal Services also acts as a potential point of access for hackers. However, by using the suggestions in this article, you can greatly reduce, if not avoid completely, the security problems that Terminal Services presents.

Editor's Picks

Free Newsletters, In your Inbox