Enterprise Services (COM) Security Considerations | Improving Web Application Security: Threats and Countermeasures

Enterprise Services (COM+) Security Considerations

COM+ provides the underlying infrastructure for Enterprise Services; therefore, secure COM+ if you use it on the middle- tier application server. Two main steps are involved in securing an application server that uses Enterprise Services:

Secure the Component Services Infrastructure .

You must secure the underlying operating system and Enterprise Services infrastructure. This includes base security measures, such as applying patches and updates, and disabling unused services, blocking unused ports, and so on.
Configure Enterprise Services application security .

You must secure the Enterprise Services application that is deployed on the server, taking into account application-specific security needs.

The developer can specify many of the application and component-level security configuration settings using metadata embedded in the deployed assemblies. These govern the initial catalog security settings that are applied to the application when it is registered with Enterprise Services. Then, the administrator can view and amend these if necessary by using the Component Services tool.

Secure the Component Services Infrastructure

Enterprise Services is not an optional component, and it is installed as an integral part of Windows 2000. From a security perspective, knowing what operating system components are installed to support Enterprise Services helps you take appropriate security measures.

What Does the Operating System Install?

The following table shows the core Component Services elements that are installed with a standard operating system installation.

Table 17.1: Enterprise Services Components
Item	Details
Administration	Component Services Explorer This provides configurable administration of COM+ applications, and is located at \WINNT\system32\Com\comexp.msc. COM+ Catalog The COM+ Catalog maintains configuration information for each COM+ application.
System Application (a COM+ server application)	System Application This application manages the configuration and tracking of COM+ components. It can be viewed from the Component Services Microsoft Management Console (MMC). It has two associated roles: Administrator and Reader . By default, the administrators are part of the Administrator role, which can modify the COM+ Catalog, while Everyone is part of the Reader role, which can read only COM+ Catalog values.
Services	COM+ Event System This service is required to support the COM+ loosely coupled event (LCE) system. The LCE system is used by operating system services such as the System Event Notification Services (SENS) service and optionally by your applications. Distributed Transaction Coordinator (DTC) This service is required if your Enterprise Services solution uses COM+ automatic transactions.
Accounts	Enterprise Services do not create any accounts. Library applications run as the identity of the process they run in. Server applications can be configured to run as the interactive user or a specific user. (You can configure the user account on the Identity tab of the COM+ application's Properties dialog box in Component Services).
Log Files	DTC log file: %windir%\system32\DTCLog CRM log file: %windir%\registration
Registry Keys	HKEY_CLASSES_ROOT\CLSID HKEY_CLASSES_ROOT\AppID

What Does the .NET Framework Install?

When you install the .NET Framework, the following components that relate to Enterprise Services are installed.

Table 17.2: NET Framework Enterprise Services Tools and Configuration Settings
Item	Description
Regsvcs.exe	Command line tool used to register Enterprise Services components with COM+
Libraries	System.EnterpriseServices.dll System.EnterpriseServices.Thunk.dll System.EnterpriseServices.tlb
Machine.config Configuration Elements	If you call Enterprise Services from ASP.NET, the following entries in Machine.config are relevant: <assemblies> Loads the System.EnterpriseServices assembly for ASP.NET. <processModel> The comAuthentication attribute configures ASP.NET authentication levels. DCOM authentication levels are negotiated between the client (for example, the Web application) and the server (the Enterprise Services application). The higher of the two security settings is used. The comImpersonationLevel attribute configures ASP.NET impersonation levels (for all outgoing DCOM calls). The client determines the impersonation capabilities that are granted to the server.

To secure the component services infrastructure, consider the following items:

Patches and updates
Services
Ports
COM+ catalog

Patches and Updates

Update the application server with the latest service packs and patches to mitigate the risks posed by viruses, worms, and Trojan horses. The software that needs to be regularly updated includes the operating system, which includes IIS and the .NET Framework.

Updates to the COM+ runtime are sometimes released as QFE releases. Use the following resources to help manage patches and updates:

Windows updates and patches

Use the Microsoft Baseline Security Analyzer (MBSA) to detect missing security updates on application servers. For more information about how to use the MBSA on a single computer and to keep a group of servers up-to-date, see "How to: Use MBSA" in the "How To" section of this guide.

For information about environments that require many servers to be updated from a centralized administration point, see "How To: Patch Management" in the "How To" section of this guide.
.NET Framework updates and patches

At the time of this writing (May 2003), MBSA does not have the ability to detect the .NET Framework. Therefore, you must update the .NET Framework manually.

Task To manually update the .NET Framework

Determine which .NET Framework service pack is installed on your Web server.

To do this, see Microsoft Knowledge Base article 318785, " INFO : Determining Whether Service Packs Are Installed on .NET Framework."
Compare the installed version of the .NET Framework to the current service pack.

To do this, use the .NET Framework versions listed in Microsoft Knowledge Base article 318836, "INFO: How to Obtain the Latest .NET Framework Service Pack."

COM+ updates and patches

The latest Windows service packs include the current fixes to COM+. However, updates to the COM+ runtime are sometimes released in the form of QFE releases. An automatic notification service for COM+ updates does not currently exist, so monitor the Microsoft Knowledge Base at http://support.microsoft.com . Use "kbQFE" as a search keyword to refine your search results.

Services

To reduce the attack surface profile, disable any services that are not required. Required services include the Microsoft DTC and the COM+ Event System service, which is required to support the LCE COM+ feature.

To secure the services on your application server, disable the MS DTC if it is not required.

Disable the Microsoft DTC If It Is Not Required

The DTC service is tightly integrated with COM+. It coordinates transactions that are distributed across two or more databases, message queues, file systems, or other resource managers. If your applications do not use the COM+ automated transaction services, then the DTC should be disabled by using the Services MMC snap-in.

Ports

Serviced components communicate using DCOM, which in turn communicates using the RPC transport.

By default, DCOM dynamically allocates ports, which is undesirable from a security and firewall configuration perspective. DCOM ports should be restricted to reduce the attack surface profile and to ensure that you do not need to open unnecessary ports on the internal firewall. Two options exist for restricting the ports used by DCOM:

Use port ranges .
Use static endpoint mapping .

Port Ranges

For incoming communication, you can configure RPC dynamic port allocation to select ports within a restricted range above 1024. Then configure your firewall to confine incoming external communication to only those ports and port 135, which is the RPC endpoint mapper port.

Task To control RPC dynamic port allocation

Start the Component Services tool.
Click to expand the Component Services and Computers nodes, right-click My Computer , and then click Properties .
Click the Default Protocols tab, and then select Connection-oriented TCP/IP in the DCOM Protocols list box.
Click Properties .
In the Properties for COM Internet Services dialog box, click Add .
In the Port range text box, add a port range, for example 5000 “5020, and then click OK .
Leave the Port range assignment and the Default dynamic port allocation options set to Internet range .
Click OK twice to close the dialog boxes.
Restart your computer so the changes can take effect.

Static Endpoint Mapping

Windows 2000 (SP3 or QFE 18.1) or Windows Server 2003 allows you to configure Enterprise Services applications to use a static endpoint. If a firewall separates the client from the server, you only need to open two ports in the firewall. Specifically, you must open port 135 for RPC and a port for your Enterprise Services application.

Task To configure a static endpoint for DCOM

Obtain the application ID for your Enterprise Services application from the COM+ catalog. To do this:
1. Start the Component Services tool.
2. Display the Properties dialog box of the application, and retrieve the application ID from the General page.
Start the registry editor (Regedt32.exe).
Select the following registry key:
```
 HKEY_CLASSES_ROOT\AppID 
```
From the Edit menu, click Add Value , and then add the following registry value, where {your AppID} is the Application ID of the COM+ application that you obtained in step 1:
```
 Key name: {Your AppID} Value name: Endpoints Data type: REG_MULTI_SZ Value data: ncacn_ip_tcp,0,<port number> 
```
The port number that you specify in the Value data text box must be greater than 1024 and must not conflict with well-known ports that other applications on the computer use. You cannot modify the ncacn_ip_tcp,0 portion of this key.
Close the registry editor.

COM+ Catalog

Enterprise Services application configuration settings are maintained in the COM+ catalog. The majority of configuration items are contained in the registration database (RegDB), which consists of files located in the following directory:

 %windir%\registration

By default, the Everyone group has permission to read the database. Modify the access control list (ACL) for this directory to restrict read/write access to administrators and the local system account. Also grant read access to the accounts used to run Enterprise Services applications. Here is the required ACL:

 Administrators: Read, Write System: Read, Write Enterprise Services Run-As Account(s): Read

Secure Enterprise Services Applications

Individual application configuration settings are maintained in the COM+ catalog and can be configured using the Component Services tool or by using script. Many of the settings discussed below can also be specified by application developers by using the correct assembly level metadata in the serviced component assembly. When you register the service component, for example by using Regsvcs.exe, the COM+ catalog is automatically configured using this metadata, although the application run-as identity must be configured administratively.

To secure an Enterprise Services application, you must configure the following items:

Identity (run as)
Authentication level
COM+ role based security
Impersonation
CRM log files
Application assemblies

Identity (Run As)

Configure Enterprise Services server applications to run with least privileged accounts. This reduces the potential damage that might occur if the server process is compromised by an attacker who manages to execute code using its security context.

If the serviced components within the Enterprise Services application are not impersonating the caller's security context, then the process-level identity specified through the run-as account is used for downstream local and remote resource access. To support network authentication to a remote database server, you can create a "mirrored" local account, which is a local account on the remote server that has a matching username and password.

Note	When you set the run-as identity with Enterprise Services, the required "Logon as a batch job" privilege is automatically granted to the account.

Authentication Level

Enterprise Services applications authenticate callers using RPC, which in turn uses the underlying authentication services of the operating system provided through the Security Service Provider Interface (SSPI) layer. This means that applications authenticate callers using Windows authentication; either Kerberos or NTLM.

RPC defines authentication levels that determine when authentication occurs and whether the authenticated communication should be checked for integrity or encrypted. At minimum, you should use call-level authentication to ensure that every method call to a serviced component method is authenticated.

Note	Call-level authentication does not result in the encryption of message data. As a result, if network eavesdropping is a real concern, use the packet privacy authentication level, or use call-level authentication over a channel secured with IPSec.

Table 17.3 shows the various authentication levels:

Table 17.3: Enterprise Services Application Authentication Levels
Authentication Level	Description
Default	Choose authentication level using normal negotiation rules
None	No authentication
Connect	Only authenticates credentials when the client initially connects to the server
Call	Authenticates at the start of each remote procedure call
Packet	Authenticates all data received from the client
Packet integrity	Authenticates all data and verifies that none of the transferred data has been modified
Packet privacy	Authenticates all data and encrypts all packets transmitted using RPC encryption

Task To set call-level authentication

Start Component Services and display the Properties dialog box of the application.
Click the Security tab.
Select Call from the Authentication level for calls drop-down list.

COM+ Role-Based Security

Authorization in Enterprise Services applications is provided by Enterprise Services (COM+) roles. COM+ roles contain Windows user and group accounts and are used to restrict access to the application, component, interfaces, and method. Ideally, your Enterprise Services applications should be configured for component level authorization, which allows you to authorize callers to individual serviced component methods .

To configure role-based security:

Enable role-based security .
Enable component-level access checks .
Enforce component-level access checks .

Enable Role-Based Security

Role-based security is disabled by default on Windows 2000. The reverse is true for Windows Server 2003.

Task To enable role-based security

Start the Component Services tool and display the Properties dialog box of the application.
Click the Security tab.
Select Enforce access checks for this application .

Figure 17.7: Enabling role-based security

Enable Component-Level Access Checks

Without component-level access checks, any account that is used to connect to any application component is granted access if it is a member of any role within the application. Component-level access checks allow individual components to apply their own authorization. This is the recommended level of granularity.

Task To enable component level access checks

Start the Component Services tool and display the Properties dialog box of the application.
Click the Security tab.
Click Perform access checks at the process and component level .

Figure 17.8: Enabling component-level access checks

Enforce Component-Level Access Checks

To allow individual components inside the Enterprise Services application to perform access checks and authorize callers, you must enable component-level access checks at the component level.

Task To enforce component-level access checks

Start the Component Services tool and expand your application in the tree control.
Select the Components folder, right-click it, and then click Properties .
Click the Security tab.
Click Enforce component level access checks .

Note
This setting is effective only if you have enabled application-level access checking and have configured process and component level access checks, as described earlier.

Impersonation

DCOM clients set the impersonation level to determine the impersonation capabilities of the server with which they are communicating. When an Enterprise Services application on a middle-tier application server is configured, the configured impersonation level affects any remote calls made to downstream components, including the database server. The impersonation level is set on the Security page of the Properties dialog box of the application in Component Services, as Figure 17.9 shows.

Figure 17.9: DCOM impersonation levels

The appropriate level depends on the desired application-level functionality, although you should use the following guidelines to determine an appropriate level:

Avoid Anonymous impersonation. The downstream component will not be able to identify your application for authentication or authorization purposes.
Use Identify to allow the downstream component to authenticate and authorize your application. It will not, however, be able to access local or remote resources using the impersonated security context of your application.
Use Impersonate if you want to allow the downstream component to impersonate the identity of your application so that it can access local resources on the downstream server.
Use Delegate if you want to allow the downstream component to impersonate the identity of your application so that it can access local or remote resources. This requires accounts configured for delegation in Active Directory

All downstream resource access that is performed by serviced components on your middle-tier application server normally uses the server application's identity. If, however, the serviced components perform programmatic impersonation, and the client application (usually an ASP.NET Web application or Web service on the Web server) has been configured to support Kerberos delegation, then the client's identity is used.

For more information, see "How To: Enable Kerberos Delegation in Windows 2000" in the "How To" section of "Microsoft patterns & practices Volume I, Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication " at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/secnetlpMSDN.asp .

CRM Log Files

If your Enterprise Services application uses the CRM, you should ensure that the CRM log files are secured to prevent potential information disclosure. Depending on the nature of the application, the files can contain sensitive application data. The CRM log files are created in the following directory:

 %windir%\system32\dtclog

CRM log file names are derived from the Enterprise Services application ID and have the file name extension .crmlog. CRM log files are secured when they are created by Enterprise Services and the file is configured with an ACL that grants Full Control to the run-as account of the application. No other account has access.

If you change the identity of the application after the log file is created, you must manually change the ACL on the file. Make sure that the new run-as identity of the application has Full Control permissions.

Application Assemblies

To protect the deployed application assemblies that contain the serviced components of the application, you should harden the ACL associated with the assembly .dll files to ensure they cannot be replaced or deleted by unauthorized users.

Apply the following ACL to the DLL folder of your application:

 Users: Execute Application Run as account: Execute Administrators: Read, Write and Execute

The location of the assembly DLLs of an application is specified at deployment time and may therefore vary from installation to installation. The Properties dialog box in the Component Services tool does not show the assembly DLL location. Instead, it points to %windir%\System32\mscoree.dll, which provides the interception services for the component.

Task To check the location of application DLLs

Start the Component Services tool and expand your application in the tree control.
Expand the Components folder, select a component, right-click it, and then click Properties .
In the Properties dialog box, retrieve the Class ID (CLSID) of the component.
Start Regedt32.exe and locate the retrieved CLSID beneath HKEY_CLASSES_ROOT\CLSID .
Click the InprocServer32 key.

The DLL location is indicated by the CodeBase named value.