Threats and the common types of attack Part3

 In This Article

• Security benefits of managed code
• Role-based security versus code access security
• Principals and identities
• PrincipalPermission objects
• .NET Framework role-based security fundamentals
• .NET Framework security namespaces

Overview

The Microsoft .NET Framework gives numerous techniques and a vast range of types in the security namespaces to help you build secure code and create secure Web applications. This Article defines the .NET Framework security landscape by briefly introducing the security benefits of managed code development. This Article also introduces and contrasts the two complimentary forms of security that are available to .NET Framework applications: user security and code security. Finally, the Article briefly examines the security namespaces that you use to program .NET Framework security.

This Article emphasizes how .NET Framework security applies to ASP.NET Web applications and Web services.

How to Use This Article

This Article describes the security benefits inherent in using the .NET Framework and explains the complementary features of .NET Framework user (or role-based) security and .NET Framework code-based (or code access) security. We recommend that you use this Article as follows:

• Understand the two-layered defense provided by the .NET Framework. Role-based security allows you to control user access to application resources and operations, while code access security can control which code can access resources and perform privileged operations.
• Create applications that use the security concepts in this Article. This Article tells you when you should use user-based security and when you should use code-based security. After reading this Article, you will be able to identify how any new applications you create can be more secure by using role-based or code-based security.

Managed Code Benefits

Developing .NET Framework applications provides you with some immediate security benefits, although there are still many issues for you to think about. These issues are discussed in the Building Articles in Part III of this guide.

.NET Framework assemblies are built with managed code. Compilers for languages, such as the Microsoft Visual C#® development tool and Microsoft Visual Basic® .NET development system, output Microsoft intermediate language (MSIL) instructions, which are contained in standard Microsoft Windows portable executable (PE) .dll or .exe files. When the assembly is loaded and a method is called, the method's MSIL code is compiled by a just-in-time (JIT) compiler into native machine instructions, which are subsequently executed. Methods that are never called are not JIT-compiled.

The use of an intermediate language coupled with the run-time environment provided by the common language runtime offers assembly developers immediate security advantages.

• File format and metadata validation. The common language runtime verifies that the PE file format is valid and that addresses do not point outside of the PE file. This helps provide assembly isolation. The common language runtime also validates the integrity of the metadata that is contained in the assembly.
• Code verification. The MSIL code is verified for type safety at JIT compile time. This is a major plus from a security perspective because the verification process can prevent bad pointer manipulation, validate type conversions, check array bounds, and so on. This virtually eliminates buffer overflow vulnerabilities in managed code, although you still need to carefully inspect any code that calls unmanaged application programming interfaces (APIs) for the possibility of buffer overflow.
• Integrity checking. The integrity of strong named assemblies is verified using a digital signature to ensure that the assembly has not been altered in any way since it was built and signed. This means that attackers cannot alter your code in any way by directly manipulating the MSIL instructions.
• Code access security. The virtual execution environment provided by the common language runtime allows additional security checks to be performed at runtime. Specifically, code access security can make various run-time security decisions based on the identity of the calling code.

User vs. Code Security

User security and code security are two complementary forms of security that are available to .NET Framework applications. User security answers the questions, "Who is the user and what can the user do?" while code security answers the questions "Where is the code from, who wrote the code, and what can the code do?" Code security involves authorizing the application's (not the user's) access to system-level resources, including the file system, registry, network, directory services, and databases. In this case, it does not matter who the end user is, or which user account runs the code, but it does matter what the code is and is not allowed to do.

The .NET Framework user security implementation is called role-based security. The code security implementation is called code access security.

Role-Based Security

.NET Framework role-based security allows a Web application to make security decisions based on the identity or role membership of the user that interacts with the application. If your application uses Windows authentication, then a role is a Windows group. If your application uses other forms of authentication, then a role is application-defined and user and role details are usually maintained in SQL Server or user stores based on Active Directory.

The identity of the authenticated user and its associated role membership is made available to Web applications through Principal objects, which are attached to the current Web request.

Note   When using the Role Manager feature in ASP.NET 2.0, if the roles are application-defined, the role information is not made available through Principal objects. Instead, the Role Manager obtains role information directly from the role store. For more information see How To: Use Role Manager in ASP.NET 2.0 [ http://msdn.microsoft.com/en-us/library/ms998314.aspx ] .

Figure 6.1 shows a logical view of how user security is typically used in a Web application to restrict user access to Web pages, business logic, operations, and data access.

Figure 6.1

A logical view of (user) role-based security

Code Access Security

Code access security authorizes code when it attempts to access secured resources, such as the file system, registry, network, and so on, or when it attempts to perform other privileged operations, such as calling unmanaged code or using reflection.

Code access security is an important additional defense mechanism that you can use to provide constraints on a piece of code. An administrator can configure code access security policy to restrict the resource types that code can access and the other privileged operations it can perform. From a Web application standpoint, this means that in the event of a compromised process where an attacker takes control of a Web application process or injects code to run inside the process, the additional constraints that code access security provides can limit the damage that can be done.

Figure 6.2 shows a logical view of how code access security is used in a Web application to constrain the application's access to system resources, resources owned by other applications, and privileged operations, such as calling unmanaged code.

Figure 6.2

Logical view of code-based security

The authentication (identification) of code is based on evidence about the code, for example, its strong name, publisher, or installation directory. Authorization is based on the code access permissions granted to code by security policy. For more information about .NET Framework code access security, see Article 8, "Code Access Security in Practice [ http://msdn.microsoft.com/en-us/library/aa302424.aspx ] ."

.NET Framework Role-Based Security

.NET Framework role-based security is a key technology that is used to authorize a user's actions in an application. Roles are often used to enforce business rules. For example, a financial application might allow only managers to perform monetary transfers that exceed a particular threshold.

Role-based security consists of the following elements:

• Principals and identities
• PrincipalPermission objects
• Role-based security checks
• URL authorization

Principals and Identities

Role-based security is implemented with Principal and Identity objects. The identity and role membership of the authenticated caller is exposed through a Principal object, which is attached to the current Web request. You can retrieve the object by using the HttpContext.Current.User property. If the caller is not required to authenticate with the application, for example, because the user is browsing a publicly accessible part of the site, the Principal object represents the anonymous Internet user.

Note   When using the Role Manager feature in ASP.NET 2.0, if the roles are application-defined, the role information is not made available through Principal objects. Instead, the Role Manager obtains role information directly from the role store. For more information see How To: Use Role Manager in ASP.NET 2.0 [ http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000013.asp ] .

There are many types of Principal objects and the precise type depends on the authentication mechanism used by the application. However, all Principal objects implement the System.Security.Principal.IPrincipal interface and they all maintain a list of roles of which the user is a member.

Principal objects also contain Identity objects, which include the user's name, together with flags that indicate the authentication type and whether or not the user has been authenticated. This allows you to distinguish between authenticated and anonymous users. There are different types of Identity objects, depending on the authentication type, although all implement the System.Security.Principal.IIdentity interface.

The following table shows the range of possible authentication types and the different types of Principal and Identity objects that ASP.NET Web applications use.

Table 6.1   Principal and Identity Objects Per Authentication Type

PrincipalPermission Objects

The PrincipalPermission object represents the identity and role that the current principal must have to execute code. PrincipalPermission objects can be used declaratively or imperatively in code.

Declarative Security

You can control precisely which users should be allowed to access a class or a method by adding a PrincipalPermissionAttribute to the class or method definition. A class-level attribute automatically applies to all class members unless it is overridden by a member-level attribute. The PrincipalPermissionAttribute type is defined within the System.Security.Permissions namespace.

Note   You can also use the PrincipalPermissionAttribute to restrict access to structures and to other member types, such as properties and delegates.

The following example shows how to restrict access to a particular class to members of a Managers group. Note that this example assumes Windows authentication, where the format of the role name is in the format MachineName\RoleName or DomainName\RoleName. For other authentication types, the format of the role name is application specific and depends on the role-name strings held in the user store.

Note   The trailing Attribute can be omitted from the attribute type names. This makes the attribute type name appear to be the same as the associated permission type name, which in this case is PrincipalPermission. They are distinct (but logically related) types.

The next example shows how to restrict access to a particular method on a class. In this example, access is restricted to members of the local administrators group, which is identified by the special "BUILTIN\Administrators" identifier.

Other built-in Windows group names can be used by prefixing the group name with "BUILTIN\" (for example, "BUILTIN\Users" and "BUILTIN\Power Users").

Imperative Security

If method-level security is not granular enough for your security requirements, you can perform imperative security checks in code by using System.Security.Permissions.PrincipalPermission objects.

The following example shows imperative security syntax using a PrincipalPermission object.

To avoid a local variable, the code above can also be written as:

The code creates a PrincipalPermission object with a blank user name and a specified role name, and then calls the Demand method. This causes the common language runtime to interrogate the current Principal object that is attached to the current thread and check whether the associated identity is a member of the specified role. Because Windows authentication is used in this example, the role check uses a Windows group. If the current identity is not a member of the specified role, a SecurityException is thrown.

The following example shows how to restrict access to an individual user.

Declarative vs. Imperative Security

You can use role-based security (and code access security) either declaratively using attributes or imperatively in code. Generally, declarative security offers the most benefits, although sometimes you must use imperative security (for example, when you need to use variables that are only available at runtime) to help make a security decision.

Advantages of Declarative Security

The main advantages of declarative security are the following:

• It allows the administrator or assembly consumer to see precisely which security permissions that particular classes and methods must run. Tools such as permview.exe provide this information. Knowing this information at deployment time can help resolve security issues and it helps the administrator configure code access security policy.
• It offers increased performance. Declarative demands are evaluated only once at load time. Imperative demands inside methods are evaluated each time the method that contains the demand is called.
• Security attributes ensure that the permission demand is executed before any other code in the method has a chance to run. This eliminates potential bugs where security checks are performed too late.
• Declarative checks at the class level apply to all class members. Imperative checks apply at the call site.

Advantages of Imperative Security

The main advantages of imperative security and the main reasons that you sometimes must use it are:

• It allows you to dynamically shape the demand by using values only available at runtime.
• It allows you to perform more granular authorization by implementing conditional logic in code.

Role-Based Security Checks

For fine-grained authorization decisions, you can also perform explicit role checks by using the IPrincipal.IsInRole method. The following example assumes Windows authentication, although the code would be very similar for Forms authentication, except that you would cast the User object to an object of the GenericPrincipal type.

Note When using the Role Manager feature in ASP.NET 2.0, you can also use the Roles API such as Roles.IsUserInRole for role checks. For more information, see "How To: Use Role Manager in ASP.NET 2.0 [ http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000013.asp ] ."

URL Authorization

Administrators can configure role-based security by using the <authorization> element in Machine.config or Web.config. This element configures the ASP.NET UrlAuthorizationModule, which uses the principal object attached to the current Web request in order to make authorization decisions.

The authorization element contains child <allow> and <deny> elements, which are used to determine which users or groups are allowed or denied access to specific directories or pages. Unless the <authorization> element is contained within a <location> element, the <authorization> element in Web.config controls access to the directory in which the Web.config file resides. This is normally the Web application's virtual root directory.

The following example from Web.config uses Windows authentication and allows Bob and Mary access but denies everyone else:

The following syntax and semantics apply to the configuration of the <authorization> element:

• "*" refers to all identities.
• "?" refers to unauthenticated identities (that is, the anonymous identity).
• You do not need to impersonate for URL authorization to work.
• Users and roles for URL authorization are determined by your authentication settings:

  Note   When using the Role Manager feature in ASP.NET 2.0, you only need to enable Role Manager and configure the role provider to point to the role store. Because the IPrincipal object internally uses the Role Manager, you do not need to explicitly set the role information in the Principal object. For more information see How To: Use Role Manager in ASP.NET 2.0 [ http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000013.asp ] .

  • When you have <authentication mode="Windows" />, you are authorizing access to Windows user and group accounts.

    User names take the form "DomainName\WindowsUserName".

    Role names take the form "DomainName\WindowsGroupName".

    Note   The local administrators group is referred to as "BUILTIN\Administrators". The local users group is referred to as "BUILTIN\Users".

  • When you have <authentication mode="Forms" />, you are authorizing against the user and roles for the IPrincipal object that was stored in the current HTTP context. For example, if you used Forms to authenticate users against a database, you will be authorizing against the roles retrieved from the database.
  • When you have <authentication mode="Passport" />, you authorize against the Passport User ID (PUID) or roles retrieved from a store. For example, you can map a PUID to a particular account and set of roles stored in a Microsoft SQL Server database or Active Directory.
  • When you have <authentication mode="None" />, you may not be performing authorization. "None" specifies that you do not want to perform any authentication or that you do not want to use any of the ASP.NET authentication modules, but you do want to use your own custom mechanism.

    However, if you use custom authentication, you should create an IPrincipal object with roles and store it in the HttpContext.Current.User property When you subsequently perform URL authorization, it is performed against the user and roles (no matter how they were retrieved) maintained in the IPrincipal object.

Configuring Access to a Specific File

To configure access to a specific file, place the <authorization> element inside a <location> element as shown below.

You can also point the path attribute at a specific folder to apply access control to all the files in that particular folder. For more information about the <location> element, see Article 19, "Securing Your ASP.NET Application and Web Services [ http://msdn.microsoft.com/en-us/library/aa302435.aspx ] ."

.NET Framework Security Namespaces

To program .NET Framework security, you use the types in the .NET Framework security namespaces. This section introduces these namespaces and the types that you are likely to use when you develop secure Web applications. For a full list of types, see the .NET Framework documentation. The security namespaces are listed below and are shown in Figure 6.3.

• System.Security
• System.Web.Security
• System.Security.Cryptography
• System.Security.Principal
• System.Security.Policy
• System.Security.Permissions

Note   The .NET Framework 2.0 has introduced new security-related namespaces such as System.Security.AccessControl, System.Security.Cryptography.Pkcs, System.Security.Cryptography.X509Certificates, System.Security.Cryptography.Xml, and System.Net.Security. For more information, see .NET Framework Class Library [ http://msdn2.microsoft.com/en-us/library/ms306608.aspx ] .

Figure 6.3

.NET Framework security namespaces in .NET 1.1

System.Security

This namespace contains the CodeAccessPermission base class from which all other code access permission types derive. You are unlikely to use the base class directly. You are more likely to use specific permission types that represent the rights of code to access specific resource types or perform other privileged operations. For example, FileIOPermission represents the rights to perform file I/O, EventLogPermission represents the rights for code to access the event log, and so on. For a full list of code access permission types, see Table 6.2 later in this Article.

The System.Security namespace also contains classes that encapsulate permission sets. These include the PermissionSet and NamedPermissionSet classes. The types you are most likely to use when building secure Web applications are:

• SecurityException. The exception type used to represent security errors.

  Note   In .NET 2.0, the SecurityException class has been improved to facilitate debugging security issues and provide detailed information about security exceptions.

• AllowPartiallyTrustedCallersAttribute. An assembly-level attribute used with strong named assemblies that must support partial trust callers. Without this attribute, a strong named assembly can only be called by full trust callers (callers with unrestricted permissions.)
• SupressUnmanagedSecurityAttribute. Used to optimize performance and eliminate the demand for the unmanaged code permission issued by the Platform Invocation Services (P/Invoke) and Component Object Model (COM) interoperability layers. This attribute must be used with caution because it exposes a potential security risk. If an attacker gains control of unmanaged code, he is no longer restricted by code access security. For more information about using this attribute safely, see "Unmanaged Code" in Article 8, "Code Access Security in Practice [ http://msdn.microsoft.com/en-us/library/aa302424.aspx ] ."

  Note   In .NET 2.0, the System.Security namespace has new classes such as SecurityContext and SecureString. For more information, see .NET Framework Class Library - System.Security Namespace [ http://msdn2.microsoft.com/en-us/library/system.security.aspx ] .

System.Web.Security

This namespace contains the classes used to manage Web application authentication and authorization. This includes Windows, Forms, and Passport authentication and URL and File authorization, which are controlled by the UrlAuthorizationModule and FileAuthorizationModule classes, respectively. The types you are most likely to use when you build secure Web applications are:

• FormsAuthentication. Provides static methods to help with Forms authentication and authentication ticket manipulation.
• FormsIdentity. Used to encapsulate the user identity that is authenticated by Forms authentication.
• PassportIdentity. Used to encapsulate the user identity that is authenticated by Passport authentication.

System.Security.Cryptography

This namespace contains types that are used to perform encryption and decryption, hashing, and random number generation. This is a large namespace that contains many types. Many encryption algorithms are implemented in managed code, while others are exposed by types in this namespace that wrap the underlying cryptographic functionality provided by the Microsoft Win32®-based CryptoAPI.

System.Security.Principal

This namespace contains types that are used to support role-based security. They are used to restrict which users can access classes and class members. The namespace includes the IPrincipal and IIdentity interfaces. The types you are most likely to use when building secure Web applications are:

• GenericPrincipal and GenericIdentity. Allow you to define your own roles and user identities. These are typically used with custom authentication mechanisms.
• WindowsPrincipal and WindowsIdentity. Represents a user who is authenticated with Windows authentication together with the user's associated Windows group (role) list.

  Note   In .NET 2.0, the WindowsIdentity class now supports a new constructor that accepts a user name represented by the user principal name (UPN). This constructor uses the Kerberos S4U (Service-for-User) extension to obtain a Windows token for the user.

System.Security.Policy

This namespace contains types that are used to implement the code access security policy system. It includes types to represent code groups, membership conditions, policy levels, and evidence.

System.Security.Permissions

This namespace contains the majority of permission types that are used to encapsulate the rights of code to access resources and perform privileged operations. The following table shows the permission types that are defined in this namespace (in alphabetical order).

Table 6.2   Permission Types Within the System.Security.Permissions Namespace

The SecurityPermission class warrants special attention because it represents the rights of code to perform privileged operations, including asserting code access permissions, calling unmanaged code, using reflection, and controlling policy and evidence, among others. The precise right determined by the SecurityPermission class is determined by its Flags property, which must be set to one of the enumerated values defined by the SecurityPermissionFlags enumerated type (for example, SecurityPermissionFlags.UnmanagedCode).

Note   The .NET Framework 2.0 has introduced new permissions such as DataProtectionPermission, GacIdentityPermission, KeyContainerPermission, and StorePermission. For more information, see .NET Framework Class Library - System.Security.Permissions Namespace [ http://msdn2.microsoft.com/en-us/library/system.security.permissions.aspx ] .

Summary

This Article has introduced you to the .NET Framework security landscape by contrasting user security and code security and by examining the security namespaces. The .NET Framework refers to these two types of security as role-based security and code access security, respectively. Both forms of security are layered on top of Windows security.

Role-based security is concerned with authorizing user access to application-managed resources (such as Web pages) and operations (such as business and data access logic). Code access security is concerned with constraining privileged code and controlling precisely which code can access resources and perform other privileged operations. This is a powerful additional security mechanism for Web applications because it restricts what an attacker is able to do, even if the attacker manages to compromise the Web application process. It is also an extremely powerful feature for providing application isolation. This is particularly true for hosting companies or any organization that hosts multiple Web applications on the same Web server.

In This Article

• Securing your network
• Identifying network threats and describing countermeasures
• Showing secure router, firewall, and switch configurations
• Providing a snapshot of a secure network

Overview

The network is the entry point to your application. It provides the first gatekeepers that control access to the various servers in your environment. Servers are protected with their own operating system gatekeepers, but it is important not to allow them to be deluged with attacks from the network layer. It is equally important to ensure that network gatekeepers cannot be replaced or reconfigured by imposters. In a nutshell, network security involves protecting network devices and the data that they forward.

The basic components of a network, which act as the front-line gatekeepers, are the router, the firewall, and the switch. Figure 15.1 shows these core components.

Figure 15.1

Network components: router, firewall, and switch

How to Use This Article

This Article provides a methodology and steps for securing a network. The methodology can be adapted for your own scenario. The steps put the methodology into practice.

To get most out of this Article:

• Read Article 2, "Threats and Countermeasures." This will give you a better understanding of potential threats to Web applications.
• Use the snapshot. Table 15.3, which is at the end of this Article, provides a snapshot of a secure network. Use this table as a reference when configuring your network.
• Use the Checklist. Use "Checklist: Securing Your Network" in the "Checklist" section of this guide, to quickly evaluate and scope the required steps. The checklist will also help you complete the individual steps.
• Use vendor details to implement the guidance. The guidance in this Article is not specific to specific network hardware or software vendors. Consult your vendor's documentation for specific instructions on how to implement the countermeasures given in this Article.

Threats and Countermeasures

An attacker looks for poorly configured network devices to exploit. Common vulnerabilities include weak default installation settings, wide-open access controls, and unpatched devices. The following are high-level network threats:

• Information gathering
• Sniffing
• Spoofing
• Session hijacking
• Denial of service

With knowledge of the threats that can affect the network, you can apply effective countermeasures.

Information Gathering

Information gathering can reveal detailed information about network topology, system configuration, and network devices. An attacker uses this information to mount pointed attacks at the discovered vulnerabilities.

Vulnerabilities

Common vulnerabilities that make your network susceptible to an attack include:

• The inherently insecure nature of the TCP/IP protocol suite
• Configuration information provided by banners
• Exposed services that should be blocked

Attacks

Common information-gathering attacks include:

• Using Tracert to detect network topology
• Using Telnet to open ports for banner grabbing
• Using port scans to detect open ports
• Using broadcast requests to enumerate hosts on a subnet

Countermeasures

You can employ the following countermeasures:

• Use generic service banners that do not give away configuration information such as software versions or names.
• Use firewalls to mask services that should not be publicly exposed.

Sniffing

Sniffing, also called eavesdropping, is the act of monitoring network traffic for data, such as clear-text passwords or configuration information. With a simple packet sniffer, all plaintext traffic can be read easily. Also, lightweight hashing algorithms can be cracked and the payload that was thought to be safe can be deciphered.

Vulnerabilities

Common vulnerabilities that make your network susceptible to data sniffing include:

• Weak physical security
• Lack of encryption when sending sensitive data
• Services that communicate in plain text or weak encryption or hashing

Attacks

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

Countermeasures

Countermeasures include the following:

• Strong physical security that prevents rogue devices from being placed on the network
• Encrypted credentials and application traffic over the network

Spoofing

Spoofing, also called identity obfuscation, is a means to hide one's true identity on the network. A fake source address is used that does not represent the actual packet originator's address. Spoofing can be used to hide the original source of an attack or to work around network access control lists (ACLs) that are in place to limit host access based on source address rules.

Vulnerabilities

Common vulnerabilities that make your network susceptible to spoofing include:

• The inherently insecure nature of the TCP/IP protocol suite
• Lack of ingress and egress filtering. Ingress filtering is the filtering of any IP packets with untrusted source addresses before they have a chance to enter and affect your system or network. Egress filtering is the process of filtering outbound traffic from your network.

Attacks

An attacker can use several tools to modify outgoing packets so that they appear to originate from an alternate network or host.

Countermeasures

You can use ingress and egress filtering on perimeter routers.

Session Hijacking

With session hijacking, also known as man in the middle attacks, the attacker uses an application that masquerades as either the client or the server. This results in either the server or the client being tricked into thinking that the upstream host is the legitimate host. However, the upstream host is actually an attacker's host that is manipulating the network so that it appears to be the desired destination. Session hijacking can be used to obtain logon information that can then be used to gain access to a system or to confidential information.

Vulnerabilities

Common vulnerabilities that make your network susceptible to session hijacking include:

• Weak physical security
• The inherent insecurity of the TCP/IP protocol suite
• Unencrypted communication

Attacks

An attacker can use several tools to combine spoofing, routing changes, and packet manipulation.

Countermeasures

Countermeasures include the following:

• Session encryption
• Stateful inspection at the firewall

Denial of Service

A denial of service attack is the act of denying legitimate users access to a server or services. Network-layer denial of service attacks usually try to deny service by flooding the network with traffic, which consumes the available bandwidth and resources.

Vulnerabilities

Vulnerabilities that increase the opportunities for denial of service include:

• The inherent insecurity of the TCP/IP protocol suite
• Weak router and switch configuration
• Unencrypted communication
• Service software bugs

Attacks

• Common denial of service attacks include:
• Brute force packet floods, such as cascading broadcast attacks
• SYN flood attacks
• Service exploits, such as buffer overflows

Countermeasures

Countermeasures include:

• Filtering broadcast requests
• Filtering Internet Control Message Protocol (ICMP) requests
• Patching and updating of service software

Methodology

Security begins with an understanding of how the system or network that needs to be secured works. This Article breaks down network security by devices, which allows you to focus on single points of configuration.

In keeping with this guide's philosophy, this Article uses the approach of analyzing potential threats; without these analyses, it's impossible to properly apply security.

The network infrastructure can be broken into the following three layers: access, distribution, and core. These layers contain all of the hardware necessary to control access to and from internal and external resources. The Article focuses on the software that drives the network hardware that is responsible for delivering ASP.NET applications. The recommendations apply to an Internet or intranet-facing Web zone and therefore might not apply to your internal or corporate network.

The following are the core network components:

• Router
• Firewall
• Switch

Router

The router is the outermost security gate. It is responsible for forwarding IP packets to the networks to which it is connected. These packets can be inbound requests from Internet clients to your Web server, request responses, or outgoing requests from internal clients. The router should be used to block unauthorized or undesired traffic between networks. The router itself must also be secured against reconfiguration by using secure administration interfaces and ensuring that it has the latest software patches and updates applied.

Firewall

The role of the firewall is to block all unnecessary ports and to allow traffic only from known ports. The firewall must be capable of monitoring incoming requests to prevent known attacks from reaching the Web server. Coupled with intrusion detection, the firewall is a useful tool for preventing attacks and detecting intrusion attempts, or in worst-case scenarios, the source of an attack.

Like the router, the firewall runs on an operating system that must be patched regularly. Its administration interfaces must be secured and unused services must be disabled or removed.

Switch

The switch has a minimal role in a secure network environment. Switches are designed to improve network performance to ease administration. For this reason, you can easily configure a switch by sending specially formatted packets to it. For more information, see "Switch Considerations" later in this Article.

Router Considerations

The router is the very first line of defense. It provides packet routing, and it can also be configured to block or filter the forwarding of packet types that are known to be vulnerable or used maliciously, such as ICMP or Simple Network Management Protocol (SNMP).

If you don't have control of the router, there is little you can do to protect your network beyond asking your ISP what defense mechanisms they have in place on their routers.

The configuration categories for the router are:

• Patches and updates
• Protocols
• Administrative access
• Services
• Auditing and logging
• Intrusion detection

Patches and Updates

Subscribe to alert services provided by the manufacturer of your networking hardware so that you can stay current with both security issues and service patches. As vulnerabilities are found — and they inevitably will be found — good vendors make patches available quickly and announce these updates through e-mail or on their Web sites. Always test the updates before implementing them in a production environment.

Protocols

Denial of service attacks often take advantage of protocol-level vulnerabilities, for example, by flooding the network. To counter this type of attack, you should:

• Use ingress and egress filtering.
• Screen ICMP traffic from the internal network.

Use Ingress and Egress Filtering

Spoofed packets are representative of probes, attacks, and a knowledgeable attacker. Incoming packets with an internal address can indicate an intrusion attempt or probe and should be denied entry to the perimeter network. Likewise, set up your router to route outgoing packets only if they have a valid internal IP address. Verifying outgoing packets does not protect you from a denial of service attack, but it does keep such attacks from originating from your network.

This type of filtering also enables the originator to be easily traced to its true source since the attacker would have to use a valid — and legitimately reachable — source address. For more information, see "Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing" at http://www.rfc-editor.org/rfc/rfc2267.txt [ http://www.rfc-editor.org/rfc/rfc2267.txt ] .

Screen ICMP Traffic from the Internal Network

ICMP is a stateless protocol that sits on top of IP and allows host availability information to be verified from one host to another. Commonly used ICMP messages are shown in Table 15.1.

Table 15.1   Commonly Used ICMP Messages

Blocking ICMP traffic at the outer perimeter router protects you from attacks such as cascading ping floods. Other ICMP vulnerabilities exist that justify blocking this protocol. While ICMP can be used for troubleshooting, it can also be used for network discovery and mapping. Therefore, control the use of ICMP. If you must enable it, use it in echo-reply mode only.

Prevent TTL Expired Messages with Values of 1 or 0

Trace routing uses TTL values of 1 and 0 to count routing hops between a client and a server. Trace routing is a means to collect network topology information. By blocking packets of this type, you prevent an attacker from learning details about your network from trace routes.

Do Not Receive or Forward Directed Broadcast Traffic

Directed broadcast traffic can be used to enumerate hosts on a network and as a vehicle for a denial of service attack. For example, by blocking specific source addresses, you prevent malicious echo requests from causing cascading ping floods. Source addresses that should be filtered are shown in Table 15.2.

Table 15.2   Source Addresses That Should be Filtered

For more information on broadcast suppression using Cisco routers, see "Configuring Broadcast Suppression" on the Cisco Web site at http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_Article09186a00800eb778.html [ http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_Article09186a00800eb778.html ] .

Administrative Access

From where will the router be accessed for administration purposes? Decide over which interfaces and ports an administration connection is allowed and from which network or host the administration is to be performed. Restrict access to those specific locations. Do not leave an Internet-facing administration interface available without encryption and countermeasures to prevent hijacking. In addition:

• Disable unused interfaces.
• Apply strong password policies.
• Use static routing.
• Audit Web facing administration interfaces.

Disable Unused Interfaces

Only required interfaces should be enabled on the router. An unused interface is not monitored or controlled, and it is probably not updated. This might expose you to unknown attacks on those interfaces.

Apply Strong Password Policies

Brute force password software can launch more than just dictionary attacks. It can discover common passwords where a letter is replaced by a number. For example, if "p4ssw0rd" is used as a password, it can be cracked. Always use uppercase and lowercase, number, and symbol combinations when creating passwords.

Use Static Routing

Static routing prevents specially formed packets from changing routing tables on your router. An attacker might try to change routes to cause denial of service or to forward requests to a rogue server. By using static routes, an administrative interface must first be compromised to make routing changes.

Audit Web Facing Administration Interfaces

Also determine whether internal access can be configured. When possible, shut down the external administration interface and use internal access methods with ACLs.

Services

On a deployed router, every open port is associated with a listening service. To reduce the attack surface area, default services that are not required should be shut down. Examples include bootps and Finger, which are rarely required. You should also scan your router to detect which ports are open.

Auditing and Logging

By default, a router logs all deny actions; this default behavior should not be changed. Also secure log files in a central location. Modern routers have an array of logging features that include the ability to set severities based on the data logged. An auditing schedule should be established to routinely inspect logs for signs of intrusion and probing.

Intrusion Detection

With restrictions in place at the router to prevent TCP/IP attacks, the router should be able to identify when an attack is taking place and notify asystem administrator of the attack.

Attackers learn what your security priorities are and attempt to work around them. Intrusion Detection Systems (IDSs) can show where the perpetrator is attempting attacks.

Firewall Considerations

A firewall should exist anywhere you interact with an untrusted network, especially the Internet. It is also recommended that you separate your Web servers from downstream application and database servers with an internal firewall.

After the router, with its broad filters and gatekeepers, the firewall is the next point of attack. In many (if not most) cases, you do not have administrative access to the upstream router. Many of the filters and ACLs that apply to the router can also be implemented at the firewall. The configuration categories for the firewall include:

• Patches and updates
• Filters
• Auditing and logging
• Perimeter networks
• Intrusion detection

Patches and Updates

Subscribe to alert services provided by the manufacturer of your firewall and operating system to stay current with both security issues and service patches.

Filters

Filtering published ports on a firewall can be an effective and efficient method of blocking malicious packets and payloads. Filters range from simple packet filters that restrict traffic at the network layer based on source and destination IP addresses and port numbers, to complex application filters that inspect application-specific payloads. A defense in depth approach that uses layered filters is a very effective way to block attacks. There are six common types of firewall filters:

• Packet filters

  These can filter packets based on protocol, source or destination port number and source or destination address, or computer name. IP packet filters are static, and communication through a specific port is either allowed or blocked. Blocked packets are usually logged, and a secure packet filter denies by default.

  At the network layer, the payload is unknown and might be dangerous. More intelligent types of filtering must be configured to inspect the payload and make decisions based on access control rules.

• Circuit-level filters

  These inspect sessions rather than payload data. An inbound or outbound client makes a request directly against the firewall/gateway, and in turn the gateway initiates a connection to the server and acts as a broker between the two connections. With knowledge of application connection rules, circuit level filters ensure valid interactions. They do not inspect the actual payload, but they do count frames to ensure packet integrity and prevent session hijacking and replaying.

• Application filters

  Smart application filters can analyze a data stream for an application and provide application-specific processing, including inspecting, screening or blocking, redirecting, and even modifying the data as it passes through the firewall. Application filters protect against attacks such as the following:

  • Unsafe SMTP commands
  • Attacks against internal DNS servers.
  • HTTP-based attacks (for example, Code Red and Nimda, which use application-specific knowledge)

  For example, an application filter can block an HTTP DELETE, but allow an HTTP GET. The capabilities of content screening, including virus detection, lexical analysis, and site categorization, make application filters very effective in Web scenarios both as security measures and in enforcement of business rules.

• Stateful inspection

  Application filters are limited to knowledge of the payload of a packet and therefore make filtering decisions based only on the payload. Stateful inspection uses both the payload and its context to determine filtering rules. Using the payload and the packet contents allow stateful inspection rules to ensure session and communication integrity. The inspection of packets, their payload, and sequence limits the scalability of stateful inspection.

• Custom application filters

  These filters ensure the integrity of application server/client communication.

When you use filters at multiple levels of the network stack, it helps make your environment more secure. For example, a packet filter can be used to block IP traffic destined for any port other than port 80, and an application filter might further restrict traffic based on the nature of the HTTP verb. For example, it might block HTTP DELETE verbs.

Logging and Auditing

Logging all incoming and outgoing requests — regardless of firewall rules — allows you to detect intrusion attempts or, even worse, successful attacks that were previously undetected. Historically, network administrators sometimes had to analyze audit logs to determine how an attack succeeded. In those cases, administrators were able to apply solutions to the vulnerabilities, learn how they were compromised, and discover other vulnerabilities that existed.

Apply the following policies for logging and log auditing.

• Log all traffic that passes through the firewall.
• Maintain healthy log cycling that allows quick data analysis. The more data you have, the larger the log file size.
• Make sure the firewall clock is synchronized with the other network hardware.

Perimeter Networks

A firewall should exist anywhere your servers interact with an untrusted network. If your Web servers connect to a back-end network, such as a bank of database servers or corporate network, a screen should exist to isolate the two networks. While the Web zone has the greatest degree of exposure, a compromise in the Web zone should not result in the compromise of downstream networks.

By default, the perimeter network should block all outbound connections except those that are expected.

Advantages of a Perimeter Network

The perimeter network provides the following advantages:

• Hosts are not directly exposed to untrusted networks.
• Exposed or published services are the only point of external attack.
• Security rules can be enforced for access between networks.

Disadvantages of a Perimeter Network

The disadvantages of a perimeter network include:

• Network complexity
• IP address allocation and management
• Requirement that the application architecture accommodate the perimeter network design

Switch Considerations

A switch is responsible for forwarding packets directly to a host or network segment, rather than sharing the data with the entire network. Therefore, traffic is not shared between switched segments. This is a preventive measure against packet sniffing between networks. An attacker can circumvent this security by reconfiguring switching rules using easily accessed administrative interfaces, including known account names and passwords and SNMP packets.

The following configuration categories are used to ensure secure switch configuration:

• Patches and updates
• Virtual Local Area Networks (VLANs)
• Insecure defaults
• Services
• Encryption

Patches and Updates

Patches and updates must be tested and installed as soon as they are available.

VLANs

Virtual LANs allow you to separate network segments and apply access control based on security rules. However, a VLAN enhances network performance, but doesn't necessarily provide security. Limit the use of VLANs to the perimeter network (behind the firewall) since many insecure interfaces exist for ease of administration. For more information about VLANs, see the article "Configuring VLANS" on the Cisco Web site.

Insecure Defaults

To make sure that insecure defaults are secured, change all factory default passwords and SNMP community strings to prevent network enumeration or total control of the switch. Also investigate and identify potentially undocumented accounts and change the default names and passwords. These types of accounts are often found on well-known switch types and are well publicized and known by attackers.

Services

Make sure that all unused services are disabled. Also make sure that Trivial File Transfer Protocol (TFTP) is disabled, Internet-facing administration points are removed, and ACLs are configured to limit administrative access.

Encryption

Although it is not traditionally implemented at the switch, data encryption over the wire ensures that sniffed packets are useless in cases where a monitor is placed on the same switched segment or where the switch is compromised, allowing sniffing across segments.

Additional Considerations

The following considerations can further improve network security:

• Ensure that clocks are synchronized on all network devices. Set the network time and have all sources synchronized to a known, reliable time source.
• Use Terminal Access Controller Access Control System (TACACS) or Remote Authentication Dial-In User Service (RADIUS) authentication for highly secure environments as a means of limiting administrative access to the network.
• Define an IP network that can be easily secured using ACLs at subnets or network boundaries whenever possible.

Snapshot of a Secure Network

Table 15.3 provides a snapshot of the characteristics of a secure network. The security settings are abstracted from industry security experts and real-world applications in secure deployments. You can use the snapshot as a reference point when evaluating your own solution.

Table 15.3   Snapshot of a Secure Network

Summary

Network security involves protecting network devices and the data that they forward to provide additional security for host servers. The primary network components that require secure configuration are the router, firewall, and switch.

This Article has highlighted the top threats to your network infrastructure and has presented security recommendations and secure configurations that enable you to address these threats.

Hosting Multiple Web Applications

Overview

If you host multiple ASP.NET Web applications on a shared Web server, you need to consider application isolation. For example, how can you ensure that individual applications will not affect one another at runtime? How can you prevent a single rogue or badly written application from consuming critical system level resources on the server that keeps other applications from running properly?

The issue is particularly significant for Internet Service Providers (ISPs) who host large numbers of applications from different companies. In a hosting scenario, it is essential to ensure that the installation of a new application cannot adversely impact the operation of existing applications.

There are a number of ways in which application isolation can be achieved. The available options vary depending on the version of the .NET Framework and the version of the operating system that you run on the Web server. If you are running .NET Framework version 1.1 or 2.0, you can use the resource constraint model provided by code access security to provide one level of application isolation. This application isolation is achieved by restricting an application from to access different types of resources such as the file system, registry, event log, Active Directory, databases, network resources, and so on.

In addition, Windows Server 2003 provides process isolation through Internet Information Services 6.0 (IIS 6) application pools that enable multiple applications to run in separate IIS worker process instances. Process isolation is not possible on Windows 2000 because all Web applications run in a single instance of the ASP.NET worker process, with application domains providing isolation.

The Table 20.1 summarizes the various options for application isolation that are available on Windows 2000 and Windows Server 2003.

Table 20.1   Application Isolation Features for Windows 2000 and Windows Server 2003

Windows Server 2003 running .NET Framework 1.1 or 2.0 is the recommended platform for hosting multiple ASP.NET applications because it supports process isolation and provides the richest range of options for application isolation.

ASP.NET Architecture on Windows 2000

On Windows 2000, multiple Web applications run in a single instance of the ASP.NET worker process (Aspnet_wp.exe). Each application resides in its own application domain that provides a degree of isolation for managed code. The Windows 2000/IIS 5 architecture is shown in Figure 20.1.

Figure 20.1

ASP.NET architecture on Windows 2000 with IIS 5

The components of the architecture depicted by Figure 20.1 are summarized in Table 20.2.

Table 20.2   Components of the Windows 2000 ASP.NET Architecture

ASP.NET Architecture on Windows Server 2003

On Windows Server 2003, the architecture changes because IIS 6 allows multiple processes to be used to host separate Web applications. This is shown in Figure 20.2.

Note   IIS 6 supports a backwards compatibility mode that, in turn, supports the IIS 5 ASP.NET worker process model.

Figure 20.2

ASP.NET architecture on Windows Server 2003 with IIS 6

Compared to the ASP.NET architecture under Windows 2000, the primary difference in Windows Server 2003 is that separate IIS worker process instances (W3wp.exe) can be used to host Web applications. By default, these run using the NT Authority\NetworkService account, which is a least privileged local account that acts as the computer account over the network. A Web application that runs in the context of the Network Service account presents the computer's credentials to remote servers for authentication.

Configuring ACLs for Network Service

Configuring an access control list (ACL) for the Network Service account varies for local and remote machines. If you want to grant access to the Network Service account on the local machine, add the Network Service account to an ACL. If you want to grant access to the Network Service account on a remote machine, add the DomainName\MachineName$ account to an ACL.

Note   Do not confuse the Network Service account with the Network built-in group, which includes users who were authenticated across the network.

The main components of the architecture depicted by Figure 20.2 are summarized in Table 20.3.

Table 20.3   Components of the Windows Server 2003 ASP.NET Architecture

Isolating Applications by Identity

You can isolate ASP.NET Web applications from an operating system identity standpoint by controlling the account identity used to run each application. If each application uses a separate fixed account identity, you can authorize and audit each application separately.

Note   If you host an ASP.NET Web application built using the .NET Framework version 1.0, the process account needs appropriate permissions to the root of the current file system drive. For more information, see Microsoft Knowledge Base article 317955, "FIX: 'Failed to Start Monitoring Directory Changes' Error Message When You Browse to an ASP.NET Page."

There are two ways to use separate fixed identities for each application on a shared Web server:

• Anonymous account impersonation
• Fixed identity impersonation

Anonymous Account Impersonation

With anonymous account impersonation, your application impersonates the anonymous account specified by IIS and configured for your application's virtual directory. You can use this approach if your application authenticates users independently of IIS, for example, by using Forms or Microsoft Passport authentication. In these scenarios, you can isolate the application by using a fixed anonymous account. Once the caller is authenticated and roles are checked, the trusted server model can be used for downstream resource access, where the configured anonymous account provides the trusted identity.

To support this approach, the application's virtual directories in IIS must support anonymous access and a separate anonymous account must be configured for each application. The application must then be configured for impersonation. This approach is shown in Figure 20.3. Local and remote resource access assumes the security context of the impersonated anonymous account.

Figure 20.3

Multiple anonymous accounts used for each application

To use multiple anonymous accounts for resource access

This procedure describes how to use multiple anonymous accounts, one per Web application, for resource access to support individual application authorization and auditing.

1. Create new anonymous user accounts, one per application.

   For more information about creating an anonymous user account, see the "Step 5. Accounts" section in Article 16, "Securing Your Web Server."

   If you need to access remote resources using the anonymous account, either use a least privileged domain account, or use a local account and create a duplicated local account on the remote server with a matching user name and password.

2. Use <location> tags in Machine.config to configure each Web application for impersonation.
    

   Copy Code

   <location path="Web Site Name/VDirName" allowOverride="false" >
     <system.web>
       <identity impersonate="true" />
     <system.web>
   <location>
   

   The allowOverride="false" setting prevents an individual application from overriding this setting in a Web.config file. For more information about the <location> element, see "Machine.Config and Web.Config Explained" in Article 19, "Securing Your ASP.NET Application and Web Services."

3. Use Internet Services Manager to configure each application's virtual directory to use a separate anonymous user account.
   1. Start Internet Services Manager from the Administrative Tools program group.
   2. Select the application's application directory, right-click and then click Properties.
   3. Click the Security tab and then click the Edit button.
   4. Ensure Anonymous access is selected and click Edit.
   5. Enter the user name for the anonymous account that you have created, or click Browse to select the user name from a list.
   6. If you want to use the account to access a remote resource, clear the Allow IIS to Control Password checkbox for the anonymous account.

      If you select Allow IIS to Control Password, the logon session created using the specified anonymous account has NULL network credentials and cannot be used to access network resources where authentication is required. If you clear this checkbox, the logon session is an interactive logon session with network credentials. However, if the account is local to the machine, no other machine on the network can authenticate the account. In this scenario, create a duplicate account on the target remote server.

      Note   The type of logon session created is controlled by the LogonMethod IIS Metabase setting. The default is an interactive logon session, which requires the account to have the "Allow Log on Locally" user privilege.

      The Allow IIS to Control Password option is not available on IIS 6. IIS 6 sets the default LogonMethod to Network Cleartext, which requires the account to have the "Access this computer from the network" user privilege. This allows the account to be authenticated by a network server.

4. Configure NTFS permissions for each account to ensure that each account has access only to the appropriate file system files and folders, and cannot access critical resources such as operating system tools.

   For more information about configuring NTFS permissions for the anonymous account, see Article 16, "Securing Your Web Server [ http://msdn.microsoft.com/en-us/library/aa302432.aspx ] ."

   Note   If you run the IISLockdown wizard, it creates a Web Anonymous Users group. Members of this group are denied access to system directories and tools.

Fixed Identity Impersonation

When you need IIS to authenticate users for your application, for example by using Integrated Windows authentication or certificate authentication, you can use a fixed impersonation identity to execute your ASP.NET application. This scenario is shown in Figure 20.4.

Figure 20.4

Applications impersonate a fixed account and use that to access resources

You can configure individual ASP.NET applications to impersonate a fixed account. The advantage of this configuration is that it can be used with any IIS authentication method, and does not require IIS anonymous authentication.

To use multiple fixed impersonation accounts for resource access

This procedure describes how to use multiple fixed impersonation accounts, one per Web application, for resource access to support individual application authorization and auditing.

1. Create new anonymous user accounts, one per application.

   For more information about creating an anonymous user account, see the "Step 5. Accounts" section in Article 16, "Securing Your Web Server."

   If you need access to remote resources using the anonymous account, either use a least privileged domain account, or use a local account and create a duplicated local account on the remote server with a matching user name and password.

2. Store the encrypted account credentials in the registry.

   Run Aspnet_setreg.exe to store the new account's encrypted credentials in the registry. For more information, see Microsoft Knowledge Base article 329290, "How To: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings."

   Note   If you are running .NET 2.0, you can encrypt the <identity> configuration section by using the Protected Configuration feature. For more information, see "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using DPAPI [ http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000005.asp ] " and "How To: Encrypt Configuration Sections in ASP.NET 2.0 Using RSA [ http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000006.asp ] ."

3. Configure Web applications for impersonation.

   You can do this in Machine.config or Web.config. To configure multiple applications with different identities, use <location> tags in Machine.config.

   If you are running .NET 1.1, the output of Aspnet_setreg.exe run in the previous step shows you the required format of the userName and password attribute values for the <identity> element. Some examples are shown below.

    

   Copy Code

   <location path="Web Site Name/appvDir1" allowOverride="false" >
     <system.web>
        <identity impersonate="true"
                  userName=
             "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,userName"
                  password=
             "registry:HKLM\SOFTWARE\YourApp1\identity\ASPNET_SETREG,password"/>
     </system.web>
   </location>
   
   <location path="Web Site Name/appvDir2" allowOverride="false" >
     <system.web>
         <identity impersonate="true"
                   userName=
           "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,userName"
                   password=
           "registry:HKLM\SOFTWARE\YourApp2\identity\ASPNET_SETREG,password"/>
     </system.web>
   </location>
   

   To configure impersonation at the application level, use an <identity> element in the application's Web.config file as shown below.

    

   Copy Code

   <identity impersonate="true"
      userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
      password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>
   

4. Configure NTFS permissions for each account to ensure that each account has access only to the appropriate file system files and folders, and no access to critical resources such as operating system tools.

   For more information about configuring NTFS permissions for the anonymous account, see Article 16, "Securing Your Web Server [ http://msdn.microsoft.com/en-us/library/aa302432.aspx ] ."

Note   On Windows 2000 and the .NET Framework version 1.0, if you impersonate a fixed identity by using the above configuration, you must grant the "Act as part of the operating system" privilege to the ASP.NET process account used to run your Web applications. This is contrary to the principle of least privilege. You are recommended to upgrade to the .NET Framework version 1.1 where this is no longer a requirement.

Note For more information about isolating the applications using application pools, see "How To: Improve Security When Hosting Multiple Applications in ASP.NET 2.0 [ http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000029.asp ] ."

Isolating Applications with Application Pools

If your applications run on Windows Server 2003, you can use application pools and configure each application to run in its own worker process that provides process-level isolation. By default, all applications run in a default application pool. With application pools, you can configure each process to run using a separate identity and, as a result, you do not need to use impersonation.

To provide process level isolation

1. Create a set of new Windows accounts, one per application to run each worker process instance.
2. Configure NTFS permissions for each account to ensure that each account only has access to the appropriate file system files and folders, and cannot access critical resources such as operating system tools.

   For more information about configuring NTFS permissions for the anonymous account, see Article 16, "Securing Your Web Server [ http://msdn.microsoft.com/en-us/library/aa302432.aspx ] ."

3. Disable Web application impersonation.

   You can do this in Machine.config or Web.config. To disable impersonation for multiple applications in Machine.config, place <identity> elements inside <location> elements as shown below.

   Use the following configuration. This configuration does not impersonate.

    

   Copy Code

   <location path="Web Site Name/appvDir1" allowOverride="false" >
     <system.web>
        <identity impersonate="false"
     </system.web>
   </location>
   

   Note   ASP.NET applications do not impersonate by default.

4. Create new application pools and configure them to run under the new accounts.

   Use IIS 6 to create new application pools with default settings, and use the accounts created in step 1 to configure the identity of each pool, so that each pool runs using a separate identity.

5. Configure each application to run in its own application pool.

   On the Directory tab of each IIS application, choose the application pool for the application to run in.

Note For more information about isolating the applications using application pools, see "How To: Improve Security When Hosting Multiple Applications in ASP.NET 2.0 [ http://msdn.microsoft.com/library/en-us/dnpag2/html/PAGHT000029.asp ] ."

Isolating Applications with Code Access Security

In .NET Framework 1.1 and 2.0, you can configure applications to run at partial trust levels, using the <trust> element. The following configuration shows how to configure an application's trust level from the Machine.config file. In this example, the Medium trust level is used.

Note   In ASP.NET, the trust-level setting is in the machine-level Web.config file.

If you configure an application to run with a trust level other than "Full," the application has restricted code access security permissions to access specific types of resources. In this way, you can constrain applications to prevent them from interacting with one another and from gaining access to system level resources such as restricted areas of the file system, the registry, the event log, and so on.

For more information about the ASP.NET trust levels and how they can be used to provide application isolation and about application specific design and development considerations, see Article 9, "Using Code Access Security with ASP.NET [ http://msdn.microsoft.com/en-us/library/aa302425.aspx ] ."

Note   If you use code access security to provide application isolation, you should still consider the operating system identity of the application. The recommended isolation model is to use code access security together with process level isolation on Windows Server 2003.

Forms Authentication Issues

If you use Forms authentication with version 1.0 of the .NET Framework, you should use separate cookie paths and names. If you do not do so, it is possible for a user authenticated in one application to make a request to another application without being redirected to that application's logon page. The URL authorization rules within the second application may deny access to the user, without providing the opportunity to supply logon credentials using the logon form.

To avoid this issue, use unique cookie path and name attributes on the <forms> element for each application, and also use separate machine keys for each application.

Versions 1.1 and 2.0 of the .NET Framework support the IsolateApps setting shown below.

This ensures that each application on the machine uses a separate key for encryption and validation of Forms authentication cookies and view state.

With version 1.0 of the .NET Framework, you cannot use IsolateApps and you must manually generate <machineKey> elements. For more information about this issue, see the following articles in the Microsoft Knowledge Base.

• 313116, "PRB: Forms Authentication Requests Are Not Directed to loginUrl Page"
• 312906, "How To: Create Keys by Using Visual C# .NET for Use in Forms Authentication"

UNC Share Hosting

If you run an application with its content on a Universal Naming Convention (UNC) share, the credentials used to access the share are either the credentials of the application or of the authenticated client. This is configured in IIS by an administrator.

When an application is configured in this manner, ASP.NET impersonates the security context of the token it receives from IIS. This is not configurable with the <identity> tag unless explicit credentials are provided.

With version 1.0 of the .NET Framework, use Mscorcfg.msc to create a code group based on the URL and to grant it full trust.

When you use a virtual directory that points to a remote share to host an ASP.NET application, you may receive a security exception. For more information, see Microsoft Knowledge Base article 320268, "PRB: System.Security.SecurityException: Security error."

Summary

If you host multiple ASP.NET applications on a single Web server, you need to consider how applications are isolated from one another and from shared system resources such as the file system, registry, and event logs. Without adequate isolation, a rogue or badly developed application can adversely affect other applications on the server.

On Windows Server 2003, use the multiple worker process model supported by IIS 6 to provide operating system process isolation for applications. On Windows 2000, process isolation is not possible, although multiple applications can be configured to use separate anonymous user accounts. This provides separate application auditing and supports independent application authorization.

On both platforms you can use the resource constraint model provided by code access security as an additional control to restrict which applications have access to which resource types. The use of code access security with ASP.NET applications requires .NET Framework 1.1 or 2.0.

Securing Your ASP.NET Application and Web Services

Summary: This Article describes how to apply ASP.NET configuration to secure ASP.NET Web applications and Web services. It includes an overview of ASP.NET and .NET Framework configuration for administrators who are new to .NET and it explains the structure and operations of .NET Framework configuration files. The Article explains the security related configuration settings and describes how they should be configured. The Article also shows you how to secure ASP.NET session state, and remote data access from an ASP.NET application.

---