|
|
Administrators are known to say, “My terminal servers are safe and stable until users log on.” Well, terminal servers do derive their right to exist from the fact that users log on and execute applications on them. How can desktop and application access be secured so that no unauthorized activities can be performed without impeding all other, permitted activities?
One big problem affecting terminal server stability is the fact that users with access to the Internet and e-mail also have the opportunity to download undesirable software. Undesirable software includes, for example, hacking tools, all sorts of games, animated screen savers, executable viruses, and many Microsoft Visual Basic scripts.
We should not, of course, forget that users might have the potential to install undesirable software locally. It is very difficult for a terminal server running with default settings to control downloads off redirected CD-ROMs, floppy disks, USB sticks, or digital cameras. A user who needs access to a CD-ROM drive for a supplier database can also use this method to install and use any application.
If the user installs illegal tools this way, he or she might obtain access to sensitive data. Unauthorized access often occurs through software that exploits the known weak spots of a terminal server. For instance, it is possible for password recovery and network monitoring tools to allow access to other users’ IDs. Users who work with such tools can then pass themselves off as other users or can try to obtain extended permissions. The Internet makes it very easy for even non-administrator users to obtain these tools or permissions.
Basically, there are two ways of securing the desktop:
Through extensive limitation of all desktop functions that users could misuse for illegal activities.
By replacing or expanding Explorer.exe as a desktop process, where an additional communication to the Terminal Services clients could be initiated.
The first method is easy to implement using Group Policies. The administrative templates for the user configuration allow adequate control of all objects on the desktop, in the Start menu, task bar, and system control, and on the system. The latter even contains preset buttons on the security screen that can be opened only via the secure path.
| Note |
It is recommended that limiting the desktop functions through policies be performed through an organizational unit in the Active Directory, and through the local security policies only by exception. |
The problem with this method is that removing icons from the desktop or eliminating individual menu items from the Start menu does not prevent the users from opening the corresponding programs or elements in another way.
The second method described in the preceding paragraphs changes a value in the HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon\Shell registry key to start an alternative desktop process—for example, Internet Explorer with a specific start page containing all required applications. Or a self-developed program with the only task of providing users with secure access to their applications. This way, all unnecessary functions are no longer available. Another option is to extend the client platform functions to obtain the desired results.
However, the problem with this method is that users no longer access the applications via the interface they are used to. Furthermore, the seamless integration of user interface and terminal server operating system is lost. A combination of both methods is, of course, possible. This would require special policies and programs to modify desktop behavior.
| Note |
On the commercial market, special products address this problem in different ways. Solutions include, for example, desktop2001 by triCerat (http://www.tricerat.com), SoftGrid for Terminal Servers by Softricity (http://www.softricity.com), PowerFuse by Real Enterprise Solutions (http://www.respowerfuse.com), and EOL Desktop Manager by Emergent Online (http://www.go-eol.com). |
A significantly more powerful method of securing a terminal server is controlling application execution. This function is provided by the Windows Server 2003 software restriction policies. These include not only executable programs, but also macros and scripts.
An administrator sets a software restriction policy in the local computer policies or in an organizational unit in the Active Directory. The software restriction policy is then enabled by activating the policy. If the policy applies to the computer, it is executed during the next system start. If the policy applies to the users, it becomes active during the next logon procedure. If a user then starts a program or script, the operating system or Script Host checks the relevant policy and ensures that the policy is executed.
If no software restriction policies are defined, the relevant Group Policies object appears as shown in Figure 8-10.
If a new policy is defined via the Action\New Software Restriction Policy menu item, it allows controlled execution of unknown or suspect software. Basically, the administrator can choose between two software restriction security levels:
If the administrator knows all applications to be started on the terminal server, he or she can list them on a positive list. Then it will not be possible to execute any other applications on the terminal server.
If the administrator wants to prevent certain applications from being executed, he or she writes up a negative list.
When drawing up a positive list, the basic question an administrator should ask first is: what applications do the users really need? Furthermore, should all users have access to all applications installed? Should there be exceptions for certain users or applications? Even these simple questions demonstrate that configuring software restriction policies is an enormously complex and time-consuming task.
Software restriction policies are relatively easy to configure. Using the Enforce object type, select the software and users to which the policies will apply. In addition to executable files, libraries (that is, DLLs) can be included in or excluded from the policies. However, including DLLs could result in significantly higher configuration effort and increased system load because the DLLs need to be verified during system start.
An administrator might want to prevent certain programs from being run. However, the administrator himself might need to retain permission to execute all programs. For this reason, software restriction policies can be applied to all users except the local administrator, if required. If the software restriction policies are created in an Active Directory Group Policy object, this should not apply to an object containing the administrator group.
It is now possible to determine the rules for limiting program execution. This is done using the Additional Rules option. This option already contains four default rules. Four methods exist to describe the application files in detail:
Hash This rule creates a cryptographical fingerprint of the file to clearly identify it. The hash algorithms used are MD5 or SHA-1 and the file name is not included in the hash value. Only if the file remains unchanged can it be executed by a user from any location in the file system—even under a different name.
Certificate Scripts or ActiveX controls with a valid certificate can be permitted through an individual rule. It is possible to prevent all other scripts and ActiveX controls from running.
Path A rule based on the path to an executable file can contain either the folder only, or the program name as well. If the rule contains only the folder path, all programs in that folder and all its subfolders are affected. Environment variables and wildcards can also be part of the path name. Paths saved in the registry can be used for such a rule. The registry path format looks like this: %[Registry Hive]\[Registry Key]\[Value Name]%. All registry values involved must be either REG_SZ or REG_EXPAND_SZ. Furthermore, the abbreviations HKLM or HKCU are not allowed, only their real names: HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER.
Zone A rule can identify software by its Internet Explorer zone. These zones include Internet, local intranet, restricted sites, trusted sites, and local computer. However, this rule is currently used for only MSI installation packages.
Although each rule is quite easy to create in itself, one should not underestimate the complexity involved in securing a terminal server with this approach. For terminal server environments, it is particularly recommended that the software restriction policies be configured for a domain environment or organizational unit in the Active Directory and not for the local computer.
Several other problems exist with software restriction policies in larger environments:
It is not easy to find out which users might launch which applications. There is no tool that can help an administrator in this case. Many companies have software that is supposed to be used by only a few select persons. Reasons could include high license costs. However, it is quite difficult to define exceptions using the software restriction policies. The administrator has to create a new software restriction policy within the Active Directory and assign it to the relevant persons. This would have to be done for each user or application exception, which would significantly increase configuration and maintenance relating to these policies.
Other rules—for instance, applying a software restriction policy via a hash value—are equally problematic. If the administrator installs a service pack or hotfix for an application or the operating system, the hash values for these files will most probably change. The administrator has to redefine the hash for all updated applications to which the software restriction policies apply so that the users can work with the updated applications.
It is impossible to customize the message window. This means that the contents of this message window is fixed and cannot be changed.
A software restriction policy cannot recognize that a user is simply trying to open a self-extracting ZIP file. If a program is started in this way, the software restriction policy might prevent execution of the program. Complete control by administrators is therefore impossible because ZIP files can have different names and content. The software restriction policy is not able to register this and therefore prevents the files from being extracted.
Software restriction policies allow an administrator to search for relevant hints using only entries in the local Event Viewer of the terminal server being protected. There is no way to evaluate these events centrally.
Despite these limitations, which need to be viewed according to the target platform concerned, software restriction policies comprise a powerful tool for controlling applications, in particular on terminal servers. As soon as the software restriction policies have been established, the user receives a dialog box containing a default message after an attempt to start an application has been blocked.
Software restriction policies do not work for .NET Framework applications. On the contrary, the .NET Common Language Runtime introduces a new security model that is based on the evidence of the application code loaded on the system. In this way, the model called Code Access Security complements the operating system security mechanisms.
The .NET Framework application code features are linked to the relevant assembly. The security settings are aligned with the information on who published the assembly and where the assembly comes from. Examples of assembly features include the application directory, the strong name, an X.509 certificate, or the URL.
If the security settings of a .NET Framework application are to extend beyond the usual file options with their user and group assignments, they need to be established via the features described in the preceding paragraph. This is performed either directly in the code, through the functions invoked, or through the Common Language Runtime. The relevant runtime security policies apply to the organization, the computer, the users, or the application domain (that is, the code).
The basic security policy settings for accessing the code of .NET Framework applications in Windows Server 2003 are established using the Microsoft .NET Framework 1.1 Configuration, which is located under the Start\Administration menu item. However, describing all possibilities in this respect would go beyond the scope of this book.
AppSense Technologies Ltd. specializes in developing system tools for controlling security and resource capacity on Windows-based PCs. For instance, the AppSense Application Manager prevents undesirable applications from being launched. This tool is therefore an alternative to the software restriction policies. AppSense Application Manager uses kernel-level filters that control each program request. Unlike the software restriction policies, the Application Manager does not only verify the start path, name, hash, or signature of an application.
The Application Manager builds on a technology called trusted ownership checking. If this mechanism is established on Windows Server 2003, a user can execute applications only if he or she is a trusted owner of this application. In principle, local administrators and the system account are always recognized as trusted owners. The list of trusted owners is freely configurable in the Application Manager. Even in its default settings, the Application Manager prevents execution of all applications that do not belong to an administrator. This function alone controls execution of undesirable applications very efficiently.
With the Application Manager, terminal server administrators are not required to make any changes to the security configuration when they install service packs or new software versions. This is because these later installations are still performed within the administrator accounts. For this reason, users can start working with the updated applications immediately.
But what does access restriction look like for critical tools that are included in the Windows Server 2003 standard scope? The operating system is always installed by an administrator; this means that the system tools are marked as being installed by a trusted owner. Without any further configuration, all users can therefore start the system tools. With the Application Manager, however, you can block even those applications with a trusted owner. The administrator can determine these and other settings using the Application Manager management console. In this way, filter rules are established that allow only predetermined users or groups to start applications and tools.
If a user attempts to start a restricted application, the Application Manager stops the attempt and displays a message that the administrator has defined through variables.
So how can these complex application access rules be distributed to any number of servers? The solution is similar to the Group Policies concept: Central server processes manage the configuration information that can be edited via a special administration console. Client elements that communicate with the server processes apply the filter rules in line with the central configuration.
To simplify central distribution and administration of all AppSense products in corporate environments, an administrator works with the AppSense Deployment Subsystem. In addition to the tasks mentioned, this subsystem also handles license administration. The Deployment Subsystem includes these components:
The Deployment Server provides the required client software and manages configurations.
With the Deployment Manager, an administrator logically combines terminal servers into a node. All terminal servers in one node get assigned the appropriate AppSense software defined at the node level, including the configuration. This way, it is relatively easy for the administrator to distribute updated configurations to the terminal servers. The administrator configures the update cycle as well.
Deployment Agents are installed with the help of Deployment Server components on all terminal servers (= AppSense clients) to be controlled. A Deployment Agent’s tasks include downloading, installing, and updating client software and the corresponding configurations.
A wizard controls the installation of the AppSense Application Manager on a server. The Application Manager is then available within the Deployment Manager as an additional component. The application access filter rules are configured by using a different management console. The main window of the Application Manager console consists of two parts. On the left, there is a list of the individual administration objects to be selected. On the right, are the relevant option windows for the configuration.
When installed, the Application Manager allows a number of configuration adjustments to administration objects, any of which might change their standard behavior:
Trusted owners Defines the application owners that the Application Manager trusts. Two trusted owners are already listed by default: the system account and the local administrators group. The group of trusted owners is extendible.
User/group overrides Application Manager restrictions do not apply to the users listed here. Users listed in this administration object may execute any application. By default, this administration object contains only the group of local administrators. The administrator can add new users or groups to the list.
Prohibited items (applications and directories) This configuration object is needed to lock applications for all users. The administrator can explicitly add to the list the applications to be locked, or even entire directories. This function can be activated for both system tools and conventional end-user applications.
With the Application Manager objects described in the preceding list, an administrator is able to lock many applications for all users. The Exceptions administration object enables the administrator to grant certain users or groups access to individual applications. Exceptions includes several options:
Users Only listed users can work with the application configured here.
User groups Only users who belong to the listed groups can work with the application configured here.
Clients Users can execute this application only if they log on to the terminal server from the client listed here.
In addition to the filter rules described so far, there are more useful options for terminal servers, including, for instance, limiting the number of application launches by a user. Or establishing a time during which applications may be used. Even more important is the validation of application files invoked indirectly—in particular, ActiveX controls, screen savers, Microsoft Windows Installer MSI packages, Windows Script Host script files, .reg files for registry changes, the Cmd.exe command interpreter, and self-extracting ZIP files. The owner of the indirectly invoked application files plays a key role here. All this results in improved control of terminal server environment security.
|
|
