Chapter 17 – Securing Your Application Server

 

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Improving Web Application Security: Threats and Countermeasures

J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan
Microsoft Corporation

Published: June 2003

Last Revised: January 2006

Applies to:

• .NET Framework version 1.1
• Microsoft Windows® 2000 operating system

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Improving Web Application Security: Threats and Countermeasures.

Summary: This chapter describes how to secure middle tier application servers that host business logic and data access services. The chapter focuses on the application server configuration and the associated communication channels that connect the Web server to the application server and the application server to the database server. Technologies covered include Enterprise Services, Web services and .NET remoting.

Contents

In This Chapter
Overview
How to Use This Chapter
Threats and Countermeasures
Methodology
Communication Channel Considerations
Firewall Considerations
.NET Remoting Security Considerations
Enterprise Services (COM+) Security Considerations
Summary
Additional Resources

In This Chapter

• Identifying threats and countermeasures for middle-tier application servers
• Securing the communication channels between tiers
• Securing middle-tier Remoting and Web services applications
• Locking down an Enterprise Services application
• Configuring an internal firewall

Overview

Middle-tier application servers are most often used to host business logic and data access services. This functionality is usually packaged inside Enterprise Services applications or is exposed to front-end Web servers by using middle-tier Web services or Microsoft® .NET Remoting technology. This chapter addresses each technology separately and shows you how to secure your application server in each case.

Figure 17.1 shows the focus of this chapter, which includes configuring internal firewalls that are featured in many multitiered deployment models.

Figure 17.1

Remote application server deployment model

Before delving into technology-specific configuration, the chapter identifies the main threats to an application server. These threats are somewhat different from those that apply to an Internet-facing Web server because middle-tier application servers are (or should be) isolated from direct Internet access.

To secure the application server, you must apply an incremental security configuration after the underlying operating system and Internet Information Services (IIS) Web server (if installed) have been locked down.

How to Use This Chapter

This chapter focuses on the application server and the associated communication channels that connect the Web server to the application server and the application server to the database server.

To get the most out of this chapter:

• Read Chapter 2, "Threats and Countermeasures." This will give you a better understanding of potential threats to Web applications.
• Use the companion securing chapters. The current chapter is part of a securing solution that includes chapters that cover host (operating system) and network layer security. Use the following chapters in tandem with this one:
  • Chapter 15, "Securing Your Network"
  • Chapter 16, "Securing Your Web Server"
  • Chapter 18, "Securing Your Database Server"

Threats and Countermeasures

Many threats to an application server come from within an organization because application servers should be isolated from Internet access. The main threats to an application server are:

• Network eavesdropping
• Unauthorized access
• Viruses, Trojan horses, and worms

Figure 17.2 shows the main threats to an application server.

Figure 17.2

Top application server related threats and vulnerabilities

Network Eavesdropping

Attackers with network monitoring software can intercept data flowing from the Web server to the application server and from the application server to downstream systems and database servers. The attacker can view and potentially modify this data.

Vulnerabilities

Vulnerabilities that can make your application server vulnerable to network eavesdropping include:

• Sensitive data transmitted in clear text by the application
• Use of Microsoft SQL Server authentication to the database, resulting in clear text credentials
• Lack of transport or application layer encryption
• Insecure network-hardware administrative interfaces
• Use of the .NET Remoting TCP Channel to remote components

Note   The .NET Framework 2.0 mitigates .NET remoting TCP channel vulnerability through its support for authentication, authorization, and encryption when using the TCP channel.

Attacks

The attacker places packet-sniffing tools on the network to capture traffic.

Countermeasures

Countermeasures to prevent packet sniffing include the following:

• Use secure authentication, such as Windows authentication, that does not send passwords over the network.
• Encrypt SQL Server authentication credentials. If you use SQL Server authentication, you can encrypt credentials automatically by installing a server certificate on the database server.
• Secure communication channels. Options include using Secure Sockets Layer (SSL) or Internet Protocol Security (IPSec).
• Use remote procedure call (RPC) encryption with Enterprise Services applications.
• Use a segmented network, which can isolate eavesdropping to compromised segments.
• Use the HttpChannel and SSL with .NET Remoting.

Unauthorized Access

If you fail to block the ports used by applications that run on the application server at the perimeter firewall, an external attacker can communicate directly with the application server. If you allow computers other than the front-end Web servers to connect to the application server, the attack profile for the application server increases.

Vulnerabilities

Vulnerabilities that can result in unauthorized access include:

• Weak perimeter network and firewall configurations
• Superfluous ports open on the internal firewall
• Lack of IPSec policies to restrict host connectivity
• Unnecessary active services
• Unnecessary protocols
• Weak account and password policies

Attacks

Common attacks to gain unauthorized access include:

• Port scanning that detects listening services
• Banner grabbing that gives away available services and possibly software versions
• Malicious application input
• Password attacks against default accounts with weak passwords

Countermeasures

Countermeasures to prevent unauthorized access include:

• Firewall policies that block all traffic except expected communication ports
• TCP/IP filtering or IPSec policies to prevent unauthorized hosts from establishing connections
• Disabling unused services
• Static DCOM endpoint mapping that allows access only to authorized hosts

Viruses, Worms, and Trojan Horses

These attacks are often not noticed until they begin to consume system resources, which slows down or halts the execution of other applications. Application servers that host IIS are susceptible to IIS attacks.

Vulnerabilities

• Unpatched servers
• Running unnecessary services
• Unnecessary ISAPI filters and ISAPI extensions

Countermeasures

Countermeasures that help mitigate the risk posed by viruses, Trojan horses, and worms include:

• Promptly applying the latest software patches
• Disabling unused functionality, such as unused ISAPI filters and extensions
• Running processes with least privileged accounts to reduce the scope of damage in the event of a compromise

Methodology

By securing the communication channels to the application server and preventing any hosts except authorized Web servers from accessing the application server, attackers are limited to application-layer attacks that exploit vulnerabilities in Web application design and development.

To mitigate this risk, developers must apply the secure design and development approaches described in Parts II and III of this guide.

The configuration solutions in this chapter are specific to the application server and they should not be applied in isolation. Apply them alongside the solutions presented in Chapter 15, "Securing Your Network," Chapter 16, "Securing Your Web Server," and Chapter 18, "Securing Your Database Server."

Communication Channel Considerations

Sensitive application data and authentication credentials that are sent to and from the application server should be encrypted to provide privacy and integrity. This mitigates the risk associated with eavesdropping and tampering.

Encrypting network traffic addresses the network eavesdropping and tampering threats. If you consider this threat to be negligible in your environment — for example, because your application is located in a closed and physically secured network — then you do not need to encrypt the traffic. If network eavesdropping is a concern, then you can use SSL, which provides a secure communication channel at the application layer, or IPSec, which provides a transport-level solution. IPSec encrypts all IP traffic that flows between two servers, while SSL allows each application to choose whether or not to provide an encrypted communication channel.

Enterprise Services

Enterprise Services (or COM+) applications communicate over the network using DCOM over RPC. RPC uses port 135, which provides endpoint mapping services to allow clients to negotiate parameters, including the communication port, which by default is dynamically assigned.

The Enterprise Service channel can be secured in one of two ways:

• RPC Encryption

  You can configure an Enterprise Services application for RPC Packet Privacy authentication. In addition to authentication, this provides encryption for every data packet sent to and from the Enterprise Services application.

• IPSec

  You can use an IPSec policy between the Web server and the application server to encrypt the communication channel.

.NET Remoting

Two possible implementation models exist for applications that use .NET Remoting:

• HTTP channel over port 80

  This model uses ASP.NET as the hosting service.

• TCP channel over any port

  In this model, the application is hosted inside a custom executable, usually a Windows service.

Depending on the performance and security requirements of the application, you can use one of two methods to secure the Remoting channel.

• Use SSL with the HTTPChannel.

  If you host in ASP.NET, you can take advantage of the built-in HTTPS functionality provided by IIS. HTTPS provides authentication and secure data communication.

• Use IPSec with the TCPChannel.

  With the TCP channel, you can use an IPSec policy to provide transport-layer encryption for all IP data. Note that if you use the TCP channel, you must provide your own authentication mechanism. For more information, see Chapter 13, "Building Secure Remoted Components."

  Note   The .NET Framework 2.0 supports authentication and encryption when using the TCP channel.

Web Services

Web services are hosted by ASP.NET and IIS, and the services use the HTTP protocol for communication over the network.

SSL or IPSec can be used to secure the communication channel. Alternatively, encryption can be handled at the application layer by encrypting the message payload or the sensitive parts of the payload. To do this using open standards, use the Web Services Enhancements (WSE) download available for Web services. For more information, see Chapter 12, "Building Secure Web Services."

SQL Server

The application server communicates with SQL Server using TCP port 1433 by default. Unless otherwise configured, UDP port 1434 is also used for negotiation.

To secure the channel from the application server to SQL Server, use IPSec or SSL. SSL requires a server certificate to be installed on the database server.

For more information on using SSL with SQL Server, see Microsoft Knowledge Base article 276553, "How To: Enable SSL Encryption for SQL Server 2000 with Certificate Server."

Firewall Considerations

Your security infrastructure can include internal firewalls on either side of the application server. This section discusses the ports that you open on these firewalls to support the functionality of your application.

Enterprise Services

If you use middle-tier Enterprise Services, configure an internal firewall that separates the Web server and application server to allow DCOM and RPC traffic. Additionally, if you use Enterprise Services, your applications often use distributed transactions and the services of the Distributed Transaction Coordinator (DTC). In this event, open DTC ports on any firewall that separates the application server from remote resource managers, such as the database server. Figure 17.3 shows a typical Enterprise Services port configuration.

Figure 17.3

Typical Enterprise Services firewall port configuration

Note   Figure 17.3 does not show the additional ports that are required for authentication mechanisms between a client and an Enterprise Services application and possibly between the Enterprise Services application and the database server. Commonly, for networks that do not use Active Directory, TCP port 139 is required for Windows authentication. For more information on port requirements, see the articles "TCP and UDP Port Assignments," at https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx, and "Security Considerations for Administrative Authority," at https://technet.microsoft.com/en-us/library/cc723501.aspx.

By default, DCOM uses RPC dynamic port allocation, which randomly selects port numbers above 1024. In addition, port 135 is used by the RPC endpoint mapping service.

Restrict the ports required to support DCOM on the internal firewall in two ways:

• Define port ranges.

  This allows you to control the ports dynamically allocated by RPC. For more information about dynamic port restrictions, see Microsoft Knowledge Base article 300083, "How To: Restrict TCP/IP Ports on Windows 2000 and Windows XP."

• Use static endpoint mapping.

  Microsoft Windows 2000 SP3 (or QFE 18.1 and later) or Windows Server 2003 allows you to configure Enterprise Services applications to use a static endpoint. Static endpoint mapping means that you only need to open two ports in the firewall: port 135 for RPC and a nominated port for your Enterprise Services application.

  For more information about static endpoint mapping, see Microsoft Knowledge Base article 312960, "Cannot Set Fixed Endpoint for a COM+ Application."

Web Services

If you cannot open ports on the internal firewall, then you can introduce a Web-services façade layer in front of the serviced components on the application server. This means that you only need to open port 80 for HTTP traffic (specifically, SOAP messages) to flow in both directions.

This approach does not allow you to flow transaction context from client to server, although in many cases where your deployment architecture includes a middle-tier application server, it is appropriate to initiate transactions in the remote serviced component on the application server.

For information about physical deployment requirements for service agents and service interfaces, such as the Web-services façade layer, see "Physical Deployment and Operational Requirements" in the Reference section of MSDN article, "Application Architecture for .NET: Designing Applications and Services," at https://msdn.microsoft.com/en-us/library/ms954595.aspx.

DTC Requirements

If your application uses COM+ distributed transactions and these are used across remote servers separated by an internal firewall, then the firewall must open the necessary ports to support DTC traffic. The DTC uses RPC dynamic port allocation. In addition to port 135 for RPC, DTC communication requires at least one additional port.

If your deployment architecture includes a remote application tier, transactions are normally initiated there within the Enterprise Services application and are propagated to the database server. In the absence of an application server, the Enterprise Services application on the Web server initiates the transaction and propagates it to the SQL Server resource manager.

For information about configuring firewalls to support DTC traffic, see:

• "DTC Security Considerations" in the COM+ platform SDK at https://msdn.microsoft.com/en-us/library/ms680682(VS.85).aspx
• Microsoft Knowledge Base article 250367, "INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall."
• Microsoft Knowledge Base article 306843, "How To: Troubleshoot MS DTC Firewall Issues."

.NET Remoting

If you use the HTTP channel and host your remote components in ASP.NET, only open port 80 on the internal firewall to allow HTTP traffic. If your application also uses SSL, open port 443.

If you use the TCP channel and host in a Windows service, open the specific TCP port or ports that your Remoting application has been configured to use. The application might need an additional port to support callbacks.

Figure 17.4 shows a typical .NET Remoting firewall port configuration. Note that the port numbers shown for the TCP channel scenario (5555 and 5557) are illustrations. The actual port numbers are specified in web.config configuration files on the client and server machines. For more information, see Chapter 13, "Building Secure Remoted Components."

Figure 17.4

Typical Remoting firewall port configuration for HTTP and TCP channel scenarios

Web Services

Web services communicate using SOAP over HTTP; therefore, only open port 80 on the internal firewall.

SQL Server

If a firewall separates the application server from the database server, then connecting to SQL Server through a firewall requires that you configure the client using the SQL Server Client Network Utility and configure the database server using the Server Network Utility. By default, SQL Server listens on TCP port 1433, although this can be changed. The chosen port must be open at the firewall.

Depending on the chosen SQL Server authentication mode and use of distributed transactions by your application, you might also need to open several additional ports at the firewall:

• If your application uses Windows authentication to connect to SQL Server, open the necessary ports that support the Kerberos protocol or NTLM authentication.
• If your application uses distributed transactions, for example automated COM+ transactions, configure your firewall to allow DTC traffic to flow between separate DTC instances, and between the DTC and resource managers, such as SQL Server.

For more information on SQL Server port requirements, see Chapter 18, "Securing Your Database Server."

.NET Remoting Security Considerations

The .NET Remoting infrastructure enables applications to communicate with one another on the same machine or across machines in a network. The Remoting infrastructure can use the HTTP or TCP transports for communication and can send messages in many formats, the most common of which are SOAP or binary format.

Hosting in a Windows Service (TCP Channel)

Because the Remoting infrastructure provides no default authentication and authorization mechanisms, it is not recommended for use by Internet-facing applications. It is designed for applications that run in a trusted environment and is well suited for Web server communication to remote application servers, which is shown in Figure 17.5.

Figure 17.5

Remoting with the TCP channel and a Windows service host

In this scenario, a Windows service hosts the Remoting objects and communication occurs through a TCP channel. This approach offers good performance, but does not necessarily address security. For added security, use IPSec between the Web server and the application server and only allow the Web server to establish connections with the application server.

Hosting in IIS (HTTP Channel)

To benefit from the security features provided by ASP.NET and IIS, host your remote components in ASP.NET and use the HTTP channel for communication, as Figure 17.6 shows.

Figure 17.6

Remoting with the HTTP channel and an ASP.NET host

In this scenario, you can use Windows integrated authentication to authenticate the ASP.NET Web application process identity. You can also use SSL for secure communication and the gatekeepers provided by IIS and ASP.NET for authorization.

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 and Windows Server 2003. 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 the Microsoft Baseline Security Analyzer" 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: Implement Patch Management" in the "How To" section of this guide.

• .NET Framework updates and patches

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

To manually update the .NET Framework

1. 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."

2. 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 https://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.

To control RPC dynamic port allocation

1. Start the Component Services tool.
2. Click to expand the Component Services and Computers nodes, right-click My Computer, and then click Properties.
3. Click the Default Protocols tab, and then select Connection-oriented TCP/IP in the DCOM Protocols list box.
4. Click Properties.
5. In the Properties for COM Internet Services dialog box, click Add.
6. In the Port range text box, add a port range, for example 5000–5020, and then click OK.
7. Leave the Port range assignment and the Default dynamic port allocation options set to Internet range.
8. Click OK twice to close the dialog boxes.
9. 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.

To configure a static endpoint for DCOM

1. 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.

2. Start the registry editor (Regedt32.exe).

3. Select the following registry key:

   HKEY_CLASSES_ROOT\AppID
   

4. 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 Valuedata 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.

5. 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

To set call-level authentication

1. Start Component Services and display the Properties dialog box of the application.
2. Click the Security tab.
3. 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.

To enable role-based security

1. Start the Component Services tool and display the Properties dialog box of the application.

2. Click the Security tab.

3. 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.

To enable component level access checks

1. Start the Component Services tool and display the Properties dialog box of the application.

2. Click the Security tab.

3. 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.

To enforce component-level access checks

1. Start the Component Services tool and expand your application in the tree control.
2. Select the Components folder, right-click it, and then click Properties.
3. Click the Security tab.
4. 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 https://msdn.microsoft.com/en-us/library/aa302383.aspx.

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.

To check the location of application DLLs

1. Start the Component Services tool and expand your application in the tree control.

2. Expand the Components folder, select a component, right-click it, and then click Properties.

3. In the Properties dialog box, retrieve the Class ID (CLSID) of the component.

4. Start Regedt32.exe and locate the retrieved CLSID beneath HKEY_CLASSES_ROOT\CLSID.

5. Click the InprocServer32 key.

   The DLL location is indicated by the CodeBase named value.

Summary

When sufficient perimeter network defenses are in place, many of the threats that affect middle-tier application servers come from inside of an organization. A secure infrastructure that consists of IPSec policies that restrict access to the application server from selected Web servers only, and also provide secure communication channels, is an effective risk mitigation strategy.

This chapter has shown you additional security measures. These measures differ depending on the technology used on the application server.

Internal firewalls on either side of the application server present other issues. The ports that must be open depend on application implementation choices, such as transport protocols and the use of distributed transactions.

For a checklist that summarizes the steps in this chapter, see "Checklist: Securing Your Application Server" in the "Checklists" section of this guide.

Additional Resources

For more information about the issues addressed in this chapter, see the following articles in the Microsoft Knowledge Base at https://support.microsoft.com:

• Article 233256, "How to: Enable IPSec Traffic Through a Firewall"
• Article 312960, "Cannot Set Fixed Endpoint for a COM+ Application"
• Article 259011, "SAMPLE: A Simple DCOM Client Server Test Application"
• Article 248809, "PRB: DCOM Does Not Work over NAT-Based Firewall"
• Article 250367, "INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall"
• Article 154596, "How To: Configure RPC Dynamic Port Allocation to Work with a Firewall"

Retired Content
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.