- Before You Begin
- Physical Access
- Administrative Delegation
- User Authentication
- Connection Authorization
- System Privileges and Restrictions
- Application Privileges and Restrictions
- System Auditing
- System Auditing
- Security Patch Management
This chapter is from the book
This chapter is from the book
This chapter is from the book
Application Privileges and Restrictions
Application security can be broken down into two categories. The first deals with managing user access to only those applications they are required to use, and the second deals with controlling what options and functionality within an application are available to different users. The extent to which you need to manage both categories depends on the requirements of your implementation. If you run a large number of applications on your servers, it is likely you will need to limit access to one or more of these applications (or functionality within these applications) based on security, licensing, or performance requirements.
NOTE
Two separate Terminal Server audits I performed easily demonstrate how different organizations can view application security. In both cases, one finding was that all applications remained accessible to all users on the server.
For one administrator this came as no surprise and had been left as such simply be-cause all Terminal Server users accessed the same group of applications, and highly sensitive data was not accessed through their Terminal Server implementation.
For the other administrator it was a completely different story. Application segregation was supposed to have been implemented prior to this team's inheriting the Terminal Server environment, and the lack of any proper controls was a major concern because sensitive sales and customer information was easily accessible to any user interested and determined enough to search for it.
Application Access Restrictions
In a Terminal Server environment, application access is usually managed in one of two ways:
-
Restricting application access—The most common method of access management is to assume that all Terminal Server users have access to all applications on the server, and only those applications that require limited access are restricted through special application security groups.
-
Granting application access—The alternate application access method assumes that users have no access to any of the applications on the server unless such access has been explicitly granted. Not only is this management method the more restrictive of the two, but it also takes much more work up front to configure properly and can quickly become cumbersome, particularly when a large number of applications are involved. One benefit to being so restrictive is that users are not automatically able to run new applications introduced onto the server; this as a result helps guard against rogue applications being introduced via e-mail or download.
This implementation is commonly used simply because this is the default behavior of Windows. When an application is installed on a Windows Terminal Server, by default it is accessible to all users unless access restrictions are defined at the file system level, the application level, or both. For example, an inventory management system may be installed on a Terminal Server and all users can launch the application and reach the logon prompt, but only those users authorized to actually access the application have a valid user ID and password.
While the second option is certainly more appealing from a security perspective, trying to manage multiple application access lists for different groups of users can quickly become overwhelming. The best approach to restricting application access is to implement a combination of the two access methods. By combining the two, you still enjoy the additional security benefits of explicitly defining what executables a user can run while minimizing the time required to manage such an implementation.
When combining the two, the first task is to establish a list of all applications users are authorized to run. Specific items on the list are then restricted further, accessible only to the subset of users authorized to run those specific applications. For example, a typical application access list for a Terminal Server user might look like the one shown in Table 16.8. A single application access list is created, but then only users belonging to the appropriate groups can access the Inventory Management or Customer Billing programs.
Table 16.8 A Windows Terminal Server Application Access List Example
|
Application |
Notes |
|
Microsoft Word Excel |
These applications are available to all users and not Microsoft restricted based on group membership. Microsoft Outlook Custom Time-Tracking App |
|
Inventory Management |
This application is available only to members of the APP_Inventory_Mgr group. |
|
Customer Billing |
This application is available only to members of the APP_Cust_Billing group. |
How you approach the restriction of application access will depend on the version of Windows that you are running and how tightly you wish to enforce these restrictions. The three different methods of locking down application access that I will discuss are:
-
The "Run only allowed Windows Applications" group policy object. This GPO allows you to manage a list of allowed Windows applications that can be executed by users affected by the policy. Usually the policy is applied to all non-administrative users logged on to a Terminal Server. The one limitation of this policy is that it does not track applications based on their full path, only their application name. This creates the situation where a user could execute any desired application, simply by changing the application's name to be the same as an application that is authorized to run.
-
The APPSEC security utility. This tool, available as part of the Windows 2000 Server Resource Kit allows you to define a list of allowed applications, much like the "Run only allowed Windows Applications" group policy. The three main differences between this utility and the GPO are:
-
All non-administrator users are affected by this application's restrictions. There is no way to limit the access based on a particular security group.
-
Only application executables that reside on a server's physical drive can be executed. Any attempt to launch a network-based executable will fail.
-
The listed applications must reside with the specific path specified for that application. Attempting to run a listed application from any other location will fail.
-
Windows Server 2003 does not support the APPSEC security utility. Instead it has introduced the "Software restriction policies," a much more robust version of the "Run only allowed Windows Applications" GPO. This GPO allows for the following:
-
Determine whether the default behavior of the GPO is to allow applications to execute based on the access rights of the user, or to restrict access to all executables regardless of access rights.
-
Applications to be allowed or restricted can be identified by a binary hash that is calculated, a certificate or a file system path or Internet security zone. These choices allowing for the clear identification of the authorized executable while still allow flexibility in how it is located and run.
-
Entire folders can also be managed, allowing all applications within those folders to be assigned restricted or unrestricted application execution access.
These differences greatly increase the effectiveness of the APPSEC utility to more tightly secure an environment when compared to the "Run only allowed Windows Applications" GPO.
I will now take a brief look at each of these three choices.
Run Only Allowed Windows Applications Group Policy Object
Through use of a group policy object, Windows provides the ability to limit a user's access to only those applications explicitly defined for that user. The specific GPO is located under
User Configuration\Administrative Templates\System
and is called "Run only allowed Windows applications." Typically this particular policy can be defined as part of the Terminal Server Regular Users GPO, so it is applied to all non-administrative users logged on to a Terminal Server. Figure 16.19 shows the dialog box for this policy in a Windows 2003 domain. The applications are added by clicking the Show button and entering the corresponding executable name.
)
Figure
16.19 The Run Only Allowed Windows Applications Properties dialog
box.
For a user to be able to properly work within a Terminal Server session, you must be certain that you include all the necessary executables the user will need to run. When a user attempts to run an application not included in the list, they receive an error message similar to the one in Figure 16.20.
){kind=small}
Figure
16.20 Attempting to access an application not authorized results in this
message.
Contrary to what you might think, you are not required to list any of the core Windows components required for a user to be able to log on, such as winlogon.exe, wfshell.exe, or explorer.exe. This is because the application list applies only to launching programs through Windows Explorer. Applications launched directly from the system or through a command prompt are not controlled by this policy. If you restricted the user's ability to access the command prompt, they cannot circumvent Explorer to launch applications directly. If you enable this policy but include no applications in the list, the user still can log on to the server but once logged on cannot launch any applications.
Table 16.9 shows an actual executable list taken from a Terminal Server implementation where users were restricted to running only the listed applications. Note that this list also includes a batch script. If you provide users with an application shortcut that launches a batch script that in turn launches an executable, you must include the batch script name in the authorized application list or it will fail to launch. The name of the executable itself is not required because it is launched from within the batch script.
Table 16.9 Sample Listing of Allowed Application Executable Names Taken from an Actual Terminal Server Implementation
|
Executable Name |
Application Name |
Notes |
|
Excel.exe |
Microsoft Excel |
|
|
Iexplore.exe |
Internet Explorer |
|
|
Notes.cmd |
Custom batch script to launch Lotus Notes |
This batch script performs some configuration prior to starting Lotus Notes. Note that the script name is included in the executable list but not the actual Notes executable. This is because the executable is launched from within the CMD session initiated by the batch script and is not controlled by this application access list. |
|
Osa.exe |
Microsoft Office Startup Assistant |
This is provided with Office XP and a number of shared Office components for use. It is normally found in the Startup folder. |
|
Outlook.exe |
Microsoft Outlook |
|
|
PN.exe |
Citrix Program Neighborhood |
If you're going to allow users to access published applications available on different servers through a Terminal Server session, then PN.exe must be made available. This is required only when using the ICA passthrough client. If users are launching published applications directly from their local PC desktop, this executable does not need to be included in the list. |
|
Powerpnt.exe |
Microsoft PowerPoint |
|
|
Winword.exe |
Microsoft Word |
|
Once the list of all allowable applications has been defined and implemented, access to these applications can be further restricted using security groups if necessary. For example, if access to Microsoft PowerPoint was to be limited to only a few individuals, then a group could be created (for example, APP_TS_PowerPoint_Users) and used to define security on the PowerPoint executable. Any users not belonging to this group who attempted to run PowerPoint would receive an access-denied message.
TIP
Whenever a Terminal Server implementation calls for restriction of access to one or more applications, it can be less confusing to the user if the Start menu has been organized in such a way that applications they cannot access are segregated and, ideally, not even visible. Common applications accessible by all users are usually located under the main portion of the Start menu, while restricted applications available to only a limited number of users are located in subfolders with labels such as "Customer Service Managers" and "Order Desk Sales Reps." The permissions on these subfolders are set to grant read access to only those users authorized to run the applications they contain, so when other users click the subfolder it appears empty, as shown in Figure 16.21.
)
Figure
16.21 A sample Start menu configuration based on application access
restrictions.
The APPSEC Security Utility
Before running the APPSEC utility you must download the appropriate installation files from the Microsoft Web site and install APPSEC on your Terminal Server. The version of APPSEC that ships with the Windows 2000 Server Resource Kit will not function properly as it is missing some necessary system files. The APPSEC.ZIP file can be downloaded from the Microsoft FTP site at: ftp://ftp.microsoft.com/reskit/win2000/
Once downloaded, extract the contents into a temporary folder and then run InstAppSec to install the tool.
The APPSEC security utility is launched by running APPSEC from a command prompt or using the Run command on the start menu. Once started, the main APPSEC application window will appear as shown in Figure 16.22. The application automatically includes a set of applications required for a user to be able to log onto the server. By default the APPSEC utility will be disabled until explicitly enabled by an administrator.
)
Figure
16.22 The APPSEC Windows 2000 application security utility.
Once APPSEC has been enabled, the settings will immediately be applied to any new user session logons. Users currently logged onto the server will not pickup these changes until they have logged out and back into the server. APPSEC settings apply only to regular users and will never restrict anyone with administrative privileges. When a user attempts to run an application not in the list they will receive an error message stating that "Access to the specified device, path or file is denied."
Adding and removing applications from the list are very straightforward and performed by selecting the desired option. When adding new applications to the list, there is an option available to "track" the results of running a particular application (Figure 16.23). Tracking allows an administrator to run an application while APPSEC monitors and adds any associated executables to the list. This helps to ensure that a particular program has all of the necessary components in order to work properly.
)
Figure
16.23 The APPSEC utility provides a means of tracking any associated
executables for an application to ensure they are all added to the allowed
application list.
While APPSEC provides a very rudimentary interface, it can be a very powerful tool for securing a Windows 2000 Terminal Server environment.
Windows Server 2003 Software Restriction Policies
Windows Server 2003 provides the specific GPO for Software Restriction Policies, which can be found under
Windows Settings\Security Settings\Software Restriction Policies
By default this policy is not enabled and must be created by right-clicking Software Restriction Policies and selecting New Software Restriction Policies (SRP). Once selected the appropriate settings for the policy are created and available to be set as shown in Figure 16.24.
)
Figure
16.24 Software Security Policies in Windows Server 2003 replace the APPSEC
tool.
The basic layout of the Software Restriction Policies is as follows:
-
Only one SRP is created for each GPO. After selecting New Software Restriction Policies, that option will no longer be available unless the existing SRP is deleted.
-
Under the Software Restriction Policies folder, there are three attributes, which are
-
Enforcement—This setting dictates the general enforcement criteria for the policy. By default, it will restrict only executables (not executable libraries such as DLLs) and will apply to all users affected by the policy, including administrators.
-
Designated File Types—In addition to the standard executables files with the suffix EXE all of the file types listed here are assumed to represent executables and will be included in the software restrictions. File types can be added and removed on this screen.
-
Trusted Publishers—Defines whether or not the user has any control over what publishers will be trusted when presented with certificates that verify the authenticity of an application.
-
The Security Levels folder has two items, Disallowed and Unrestricted. Only one of these items can be set as the default at any given time. When Disallowed is chosen, the policy enforces that no users will be able to run software, unless the software has been designed as an additional rule, which is discussed next. If the Unrestricted option is chosen, then all applications are accessible unless explicitly denied in the Additional Rules section.
-
The Additional Rules folder is where the majority of the items will be managed. The purpose of this folder is to store either specific entries that are unrestricted or disallowed. Entries are added here simply by right-clicking and choosing the rule to define the entry. The four choices are Certificate Rule, Hash Rule, Internet Zone Rule and Path Rule. The most common select is Path Rule, allowing an administrator to provide an explicit path to a folder, executable file, or registry location. The security level for the rule dictates if the entry is unrestricted or disallowed.
In a Terminal Server deployment, the Software Restriction Policies are usually created within the Terminal Server Regular Users policy so that the changes are picked up by the non-administrative users in the environment.
Application Functionality Restrictions
In addition to allotting the desired application access to your various user groups, quite often you will want to control what options and functionality in an application are available to different users. The exact method by which these changes are performed (if they're even supported) will vary from application to application. Many provide their own integrated security based on a logon ID and password managed from within the program, while others such as Microsoft Office leverage functionality of group policy objects to allow customization based on group membership. When an application supports configuration changes using a GPO, the functionality is added into the active directory through what are know as administrative template files. Figure 16.25 shows the Add/Remove Templates submenu along with some of the Office XP templates already loaded into the Administrative Templates folder. Custom template files are usually stored in the WINNT\INF folder and have the extension ADM. More details on general installation and use of template files are provided in Chapter 15.
)
Figure
16.25 Custom and third-party administrative template files can be added to a
group policy in the active directory.
As part of a complete security implementation, I recommend that whenever you have the opportunity to customize and/or lock down any of the applications you are implementing, you should do so. By pre-configuring options such as target data directories, turning off Web-based integration, or disabling automatic update features, you are simplifying the user's environment and reducing the exposed areas where potential security issues could develop. The fewer the number of customization options available to the end user, the less likely you are to have application-related issues in the environment. In Chapter 20, I look more closely at some of the configuration options available for Microsoft Office through administrative templates.