Windows 2000 and IIS Security Overview


Windows 2000 and IIS Security Overview

As this book is about ASP.NET, we'll only be providing an overview of the features in the Windows operating system and IIS for securing your web pages and web applications. Though we will be concentrating on Windows 2000, Windows XP, and Windows 2003 Server here, the concepts, configuration, and usage of these features is virtually unchanged from previous versions of ASP. However, they do provide the basis on which .NET security techniques are founded. If you are not familiar with the material in this section, you may wish to consult other documentation or books to gain a broader understanding.

Important

Securing your applications or web sites is one of the most important factors when connecting your server to the Internet. While the basics described here and the techniques you use to control access will provide a secure environment, you must still implement all the other measures that are required for protecting your servers and applications against intruders. This includes physical security (for example, locked doors and windows), internal user security (such as keeping passwords secret and monitoring usage), virus protection, prompt installation of operating system updates and patches, and so on.

The Need for Security

When you secure your applications, you must first think about what it is you are actually trying to achieve. For example, does your application contain highly sensitive information, or allow users to perform tasks that you absolutely must protect against misuse “ such as a bank providing online account access to clients . Or, is the information less sensitive but still valuable , such as content you want visitors to pay a subscription to access.

In the end, it all comes down to quantifying the risks involved and the effect of a security breach. Securing applications is more difficult than allowing everyone access, and can involve using extra hardware to build complex multi-layer systems with firewalls, demilitarized zones, and all kinds of other high security features. However this type of approach is normally used only when the highest levels of security are required, such as when you are protecting whole networks from access by external intruders.

Security, as it concerns the ASP.NET applications, will normally be limited to the configuration of the machine(s) on which they run, and the connected resources such as database servers, etc. This generally involves limiting access to specific folders, files, components , and other resources, to only the appropriate users. These topics are the real focus of this chapter.

If you are building an application that requires the utmost protection from intruders, you must base the ASP.NET servers in a secure environment, as well as configure them correctly. This involves the kinds of extra equipment mentioned earlier, and a thorough understanding of the risks involved. Books such as Designing Secure Web-based Applications for Windows 2000 (ISBN 0-7356-0995-0) from MS Press are useful. If in doubt, however, employ an experienced professional to design and secure your network and servers as well.

Security Concepts

The basic concepts for securing your applications consist of four main topic areas:

  • Authentication :The process of discovering the individual identity of users, and making them prove that they are who they say they are.

  • Authorization :The process of determining if a particular user is entitled to access the resource they've requested .

  • Impersonation :The process whereby the resource can be accessed under a different identity, usually the context of a remote user.

  • Data or functional security :The process of securing the system through physical means, operating system updates, and use of robust software (this topic is not covered in this chapter).

Many elements of the operating system, IIS, and the .NET Framework combine to provide the features required to implement the first three topics in the preceding list. For example, Windows uses its own list of user accounts to help identify and authenticate users. IIS also identifies users based on the information provided by Windows as they access a web site, and it passes this information on to ASP.NET where it can be used as part of the overall authorization process.

Let's look at these three topics in detail. Just remember that they are all part of the same chain of events involved in allowing or denying users access to resources.

Authentication

To be able to limit access to specific users, you have to be able to identify them. This doesn't mean you need to know everything about them “ as in some big-brother scenario “ but you do need to be able to tell each user apart, and identify those that should have access and those that should not.

Authentication involves challenging a user to prove that they are who they say they are “ usually by means of a username and password, a digital certificate, or perhaps even a smart card or a fingerprint reader. In theory, if they can provide a valid username and password combination or some other user- specific property that can be identified, then they must be who they say they are. You depend on only one person having access to that particular property.

In the most common case, a user provides their username and matching password when prompted, either when they log onto a machine or when they access the resource. If these details are valid, the user has been identified “ they are authenticated.

Authorization

Once you know who the user is, you can find out whether they have permission to access the resource they requested. This is done in a range of ways, depending on the resource. In Windows-based systems most resources have an Access Control List ( ACL ) that lists the users allowed to access a resource. The list will usually also specify what kind of access each user has (for example, whether they can read it, write to it, modify it, delete it, and so on).

For example, if they request an ASP page, the operating system will check to see if they have read access to the page. If so, it will allow IIS to fetch the page. However, IIS also has authorization settings that control what a user can do with a resource. If it's an ASP page, they will only be able to execute the script in that page if IIS has script execute permission set for the web site, folder or page.

So, in traditional ASP environments, several layers can be involved in the authorization process. If the identified user has permission to access the resource in the way they've requested, the process succeeds “ they have been authorized . If not, they receive an error message of some type, generated by the layer that refused them access to the resource.

Impersonation

There are times when a user will access a resource as though they were someone (or something) else. Microsoft defines this process in the .NET SDK as, "ASP.NET applications can optionally execute with the identity of the client on whose behalf they are operating." When impersonation is enabled for a site, ASP.NET accesses the resources requested by the client using the client's credentials rather than its own.

To understand this, think about when there is no access control in place for a web page “ in other words it allows any users to access it. In fact, this is an over-simplification, because Windows never allows anonymous access. All users must be authenticated and authorized using an existing account.

For HTML pages, ASP pages and components in ASP version 3.0 and earlier, this is achieved through the two accounts named IUSR _ machinename and IWAM _ machinename . These accounts are set up when IIS is installed, and are automatically added to all the folders in every web site on the server. These accounts still exist in Windows 2003 Server, though (as you'll see later) the accounts that are used for anonymous access are different “ depending on the configuration of IIS. In this general discussion of the way that security works in Windows, we'll refer to these accounts as the anonymous accounts .

If you allow anonymous access to a resource in IIS, every user will look the same “ you won't be able to tell who is who. When IIS receives a request for a web page or other resource for which anonymous access is permitted, it uses its anonymous accounts to access the resources on the user's behalf.

In contrast, ASP.NET “ when impersonation is turned off “ makes all access to resources under the context of a special ASP.NET process account. When you turn impersonation on, ASP.NET executes every resource under the account of a specified user that is authenticated by IIS when the request is made.

As in a COM+ application running under Windows 2000 or in MTS under Windows NT4, you can specify the account that will be used. If you specify one of the anonymous accounts, ASP.NET will behave like previous versions of ASP, as far as the permissions for accessing resources is concerned .

Important

One vital point to bear in mind is that the authentication process used by ASP.NET only applies to resources that are associated with ASP.NET. In other words, access control is only applied to files that are defined as 'application' files in the IIS Application Mappings dialog. By default this includes .aspx and .asax pages, .ascx components, .vb and .cs code files, web service files, and other resources that are mapped to aspnet_isapi.dll . It does not apply to resources such as images, Word documents, zip files, PDF files, and other types of files. These types of files must be protected using standard Windows techniques such as ACLs. You'll see all these topics discussed later in this chapter.

Security within ASP.NET

From the preceding chapters, you saw how many of the configuration settings (that you used to make within IIS under previous versions of ASP) are now made through one or more instances of the new configuration file named web.config . This applies to most of the settings in the Internet Services Manager interface (within the MMC), because web.config replaces the metabase contents that this interface is used to manipulate.

However, security settings made in IIS are still effective in many areas. This is because, unlike the configuration of application settings, custom errors, etc., IIS is still actively managing the request and performing the base security process in conjunction with the operating system itself. In effect, a request for an ASP.NET page is received by IIS, which in turn uses the application mappings defined for the site containing that page to direct the request to ASP.NET.

You can see the application mappings if you open the Application Configuration dialog from the Home Directory page of the Properties dialog for a site or directory in Internet Services Manager, as shown in Figure 14-1. The application mappings for all the ASP.NET resource types point to a file named aspnet_isapi.dll stored in the .NET Frameworks folder:

click to expand
Figure 14-1:

As you can see from Figure 14-1, the application mappings rely on file extensions. This is why you can still run existing ASP 3.0 pages on the same server as ASP.NET (they have a different file extension), and (of course) publish other resources such as HTML pages, zip files, documents, and so on that aren't processed by ASP.NET.

IIS first authenticates a user, and then passes the request on to ASP.NET where it can perform its own security processes. The schematic in Figure 14-2 shows the overall flow of the request, and we'll briefly see how each part of the process is carried out in the following sections of this chapter:

click to expand
Figure 14-2:

Authentication in Windows

The Windows security system maintains a list of users that are allowed to access resources on a machine. This is either stored on the machine itself, or on a domain controller elsewhere. The list is managed through the Computer Management MMC snap-in tool (as in Figure 14-3), or through the Active Directory Users and Computers snap-in tool on a domain controller.

click to expand
Figure 14-3:

You can see the IUSR and IWAM accounts that are used by IIS when anonymous access is enabled in Figure 14-3 (the machine name is SUNDIVE-W2003). Depending on the operating system version and other software you have installed, you'll probably see several other accounts listed as well.

User Groups

The Computer Management and Active Directory Users and Computers snap-in tools also provide a list of account groups on the local machine. You can see this list in Figure 14-4, together with the Properties dialog for the group named IIS_WPG. This dialog displays a list of the members of the selected group:

click to expand
Figure 14-4:

The screenshot in Figure 14-4 is taken from a Windows Server 2003 machine, and the special account group IIS_WPG is created automatically on installation. You can see that it contains the IWAM account (as used for anonymous access to COM and COM+ components under ASP 3.0), plus the LOCAL SERVICE and SYSTEM accounts. There is another account in the list, which is created by default only in Windows Server 2003, named NETWORK SERVICE. You'll see how this is used by ASP.NET later in this chapter.

You can create your own account groups, and add new and existing users to them. All accounts are automatically added to the default users group as well. Allocating users to groups provides a way of minimizing the amount of work required to change permissions. For example, if you have 500 users who can access a particular set of resources, you can allocate them all to one group and then give that group permission to access those resources.

The alternative would be to add all 500 users to each resource individually. And any changes to the permissions afterwards would mean changing them for all 500 users, rather than just once for the group as a whole.

Groups are also useful when you use programmatic security. You can detect whether a user is a member of a specific group, and make decisions based on the result. This means that you don't have to hardcode all of the usernames into your application (just the group name), and you don't have to change the code to add or remove individual users. Just configure the group in the ACL for the resource to add users to, or remove them from the group.

Authentication in IIS

When a user requests a resource over the web, IIS receives the request and performs the initial authentication of the user. IIS also performs other checks before deciding whether the user will be allowed access to the resource. We'll look at these next .

IP Address and Domain Name Restrictions

In Windows 2000 Server, Windows Server 2003, and Windows NT4 (but not Windows 2000 Professional or Windows XP Professional), you can specify the IP addresses or domain names of clients that will be allowed access or denied access.

This is achieved using the IP Address and Domain Name Restrictions dialog, shown in Figure 14-5, which is available from the Directory Security page of the Properties dialog for a site or directory. This is useful if you always access the restricted site from a single machine, or if all your users come from a specific set of IP addresses or set of domains.

click to expand
Figure 14-5:

Using Certificates to Authenticate Users

You can also use the Properties dialog to set up server certificates that are to be used for a site or directory. As well as enabling secure communication through SSL, these certificates can be used in conjunction with client certificates to identify the machine that is accessing your server. For example, Figure 14-6 shows a configuration where clients can provide a certificate to access the site. We've created a rule so that, if the organization that issued the certificate to the client is our own certificate server, the user will automatically be authenticated using an account named TestUser from a domain named DANDARE:

click to expand
Figure 14-6:
Note

You can also access the content of a client certificate using code in an ASP.NET page, through the Request.ClientCertificate collection.

Specifying the Authentication Method

The third option in the Directory Security page of the Properties dialog for a site or directory enables you to specify the authentication method that should be used. The Authentication Methods dialog provides several options:

  • Anonymous Access :Any user can access the WWW service provided that the settings for their IP address and domain name restrictions don't prevent them. IIS then accesses resources on their behalf using the appropriate anonymous account (such as the IUSR account), and so they will be able to access all resources for which these accounts are valid.

  • Basic Authentication :If anonymous access is disabled, users will be presented with a logon dialog generated by their browser or their client-side user agent application. The username and password they provide are Base64-encoded and passed to IIS. It then looks up this account in Windows (on the server), and will only allow the user to access the resource if the account is valid and has the appropriate permission for that resource. Base64 encoding is not very secure, and so this option is not suitable for high-security applications.

  • Digest Authentication :If anonymous access is disabled, users will be prompted for their credentials (their logon information). The browser combines this with other information stored on the client, and sends an encoded hash (or digest) of it to the server. The server already has a copy of this information, and so can recreate the original details from its own hash and authenticate the user. This method only works with Internet Explorer and .NET web services, but will pass through firewalls, proxy servers, and over the Internet. It is also very secure. The user will be able to access the resource they requested only if the specified account exists in Windows, is valid, and has appropriate permission for that resource.

  • Integrated Windows Authentication :This is the same method as when you log onto your local network. Sometimes called "NTLM" authentication or "Challenge Response" authentication, it can work with Windows NTLM or Kerberos. It also uses a hash algorithm to code and decode the client's credentials. It will not work through most proxy servers and firewalls, or through some routers, and so is not generally suitable for use on the Internet. However, it usually works fine on an Intranet or a corporate network. Like digest authentication, this is also a very secure technique. The user will be able to access the resource they requested only if the specified account exists in Windows, is valid, and has appropriate permission for that resource.

  • .NET Passport Authentication (Windows Server 2003 only):The Microsoft Passport service is used to authenticate users, and hence provides a single-sign-on facility for your site and all other sites that support Passport authentication. You must sign up for the Passport service as a provider, and then implement access control appropriate to the various users who visit your site using the same system of permissions as for any other authentication method.

    Note

    If anonymous access is disabled and the other methods are all enabled, IIS will attempt to use Integrated Windows authentication first, followed by digest authentication, with basic authentication used only as a last resort if the client does not support the other two methods.

You can also use the Authentication Methods dialog to specify which account is used for anonymous access. In Figure 14-7, from a Windows 2000 machine named DANDARE, you can see that the default is the machine's IUSR account:

click to expand
Figure 14-7:

When set, the checkbox marked Allow IIS to control password in Figure 14-7 specifies that IIS will automatically extract the correct password for the IUSR account from Windows and use it when requesting resources on behalf of the user. It is checked by default, which means that you won't break the WWW service if you change the password for this account in the Computer Management tool at some point in the future.

Figure 14-8 shows the Authentication Methods dialog in Windows Sever 2003, on a machine named SUNDIVE-W2003. You can see that the .NET Passport authentication option is available in this dialog:

click to expand
Figure 14-8:

Authorization in Windows

So, assuming that your user has been successfully authenticated, what happens next? We mentioned in the previous section that a user will only be able to access the resource they requested if the account they were authenticated with has appropriate permission for that resource. These permissions are held in Access Control Lists (ACLs) that are allocated to every resource.

ACLs are managed in a range of ways “ for example, Windows Explorer is used to manage the ACLs for files and folders on local and network drives . Open the Properties dialog for any file or folder in Windows Explorer and select the Security page, as shown in Figure 14-9 (this is a Windows 2000 machine, Windows Server 2003 is slightly different in appearance but works fundamentally the same way).

click to expand
Figure 14-9:

This dialog shows the accounts and groups that have access to the selected file or folder, and the permissions for each one. The Advanced button allows you to control the options in more detail, giving up to 13 different read/write/delete combinations, and the ability to propagate the permissions to child objects and inherit permissions from parent folders.

Other applications and services also rely on Windows accounts. For example, as shown in Figure 14-10, Microsoft SQL Server allows permissions to be set up for any Windows account. This means the account that the user is authenticated with can often be used to access all the resources they need:

click to expand
Figure 14-10:

Authorization in IIS

There is one other area where security is applied to a web application or web site. IIS accesses resources on behalf of the user with either its own anonymous access account, or with the account credentials that the user provides when anonymous access is disabled. However, on a different level, it also specifies what they can do with the resource they have accessed.

The central section of the Home Directory page of the Properties dialog for a web site or directory specifies the type of operation that the user can perform within this site or directory. As shown in Figure 14-11, you can specify Script source access, Read, and/or Write permissions. The default is just Read:

click to expand
Figure 14-11:

Remember, however, that this is separate from the ACLs that Windows applies to that resource. Also, this setting is applied on a web site or directory basis, and not on a per-user basis. The settings here affect all users.

These settings offer an added layer of protection. For example, by default, users are prevented from writing to a web site directory through IIS, and they are also prevented from downloading any script files. These can only be executed, so that the source code is not visible. Of course, you can change these settings (and the others shown in this dialog) to suit your own application requirements.

However, if you decide to offer Write access for example, you must also set the appropriate permissions on the Windows ACL for the disk folders. As in all security scenarios, when settings for a resource conflict like this, the most restrictive ones will be applied. In other words, if the ACL says you can't write to the folder, allowing write access in IIS will have no effect.




Professional ASP. NET 1.1
Professional ASP.NET MVC 1.0 (Wrox Programmer to Programmer)
ISBN: 0470384611
EAN: 2147483647
Year: 2006
Pages: 243

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net