Tài liệu Module 5: Implementing Security on a Web Server ppt

Overview Using IP Address and Domain Name Restrictions Configuring Access Permissions for a Web Server Configuring Authentication for a Web Server Using Client Certificates Securing

Multimedia: Overview of IIS Security 30

Lab A: Securing Web Resources Using

Securing Web Communications Using SSL 52

Lab B: Configuring and Managing an

Using Local Security Policies on a

Configuring Security on an FTP Site 68

Review 72

Module 5: Implementing Security on a Web

Server

to represent any real individual, company, product, or event, unless otherwise noted Complying with all applicable copyright laws is the responsibility of the user No part of this document may

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2001 Microsoft Corporation All rights reserved

Microsoft, Active Directory, ActiveX, BackOffice, FrontPage, MS-DOS, Outlook, PowerPoint, SQL Server, Visual Basic, Visual InterDev, Visual SourceSafe, Visual Studio, Windows, Win32, Windows Media, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries

Other product and company names mentioned herein may be the trademarks of their respective owners

Instructor Notes

This module provides students with the knowledge and skills necessary to

implement security on a Web server

After completing this module, students will be able to:

Configure Internet Protocol (IP) address and domain name restrictions for a Web server

Configure access permissions for a Web server

Configure authentication for a Web server

Use client certificates

Secure Web communications by using Secure Sockets Layer (SSL)

Use local security policies on a Web server

Configure security on a File Transfer Protocol (FTP) site

Configure auditing for Microsoft® Internet Information Services (IIS) 5.0

Materials and Preparation

This section provides the materials and preparation tasks that you need to teach this module

Required Materials

To teach this module, you need the Microsoft PowerPoint® file 2295A_05.ppt

Preparation Tasks

To prepare for this module, you should:

Read all of the materials for this module

Complete the labs

View the multimedia “Overview of IIS Security.”

Presentation:

120 Minutes

Labs:

45 Minutes

Module Strategy

Use the following strategy to present this module:

Using IP Address and Domain Name Restrictions Discuss how IP address and domain name restrictions can be used to increase security For example, denying permissions to all IP addresses except for the firewall or proxy server and database servers connected to IIS can make it much more difficult to gain unauthorized access to the Web server

Configuring Access Permissions for a Web Server Discuss the need for security on a Web server Emphasize that effective security employs a variety of interdependent technologies Explain the use

of IP addresses and domain name restrictions by using example scenarios when possible Discuss the differences between Web-based and the NTFS file system permissions When discussing the Permissions Wizard, create a new test Web site and demonstrate the various ways to use the wizard Also,

discuss the settings on the Security Settings page Explain how NTFS is

essential to secure both IIS log files and Web Distributed Authoring and Versioning (WebDAV) access

Configuring Authentication for a Web Server Explain each of the authentication methods with an emphasis on Anonymous, Basic, and Integrated Windows Create a chart on a whiteboard that illustrates the benefits, requirements, and restrictions of authentication methods Fill in the chart as you discuss each method Discuss various scenarios and the impacts of using combinations of authentication methods

Multimedia: Overview of IIS Security Explain that the multimedia presentation provides an overview of the various security features in IIS, when each security feature is used, and how they work together to grant or deny access to Web server resources After the presentation, ask if there are any questions and discuss problem areas as necessary

Using Client Certificates Explain how to obtain client certificates and how to set up a Web site to require their use Demonstrate the one-to-one and one-to-many mapping options in IIS as part of the client certificate mapping Be sure to explain that using certificate mapping in Active Directory™ directory services is preferable to implementing it in IIS

Classroom Discussion Engage students in a classroom discussion on the best way to secure the Web site that is presented in the scenario Have students go to Appendix A,

“Classroom Discussion,” in Course 2295A, Implementing and Supporting

Microsoft Internet Information Services 5.0, and use the table provided to

help them in the discussion Explain that the worksheet contains choices that will assist them in determining what types of Web-based permissions, authentication, and NTFS permissions are needed to fulfill the requirements

of the scenario

Securing Web Communications Using SSL Because of required prerequisites for this course, you should not need to define certificates or go into detail about the mechanics of the Secure Sockets Layer (SSL) protocol Demonstrate using the Web Site Certificate Wizard and emphasize that SSL cannot be employed on host header Web sites Demonstrate requiring an SSL connection and the errors that occur if you then attempt an HTTP connection Explain the problems with self-signed certificates and the potential for browser security warnings

Additionally, mention that the Security Wizard may interfere with permissions that are managed by Microsoft FrontPage® Server Extensions

Using Local Security Policies on a Web Server Explain where to find the local security policies on the server Focus on the Log on Locally and Access This Computer from the Network user rights and remind students how these policies relate to authentication Load the hisecweb.inf policy template in the Security Analysis and Configuration Tool and review the template settings

Configuring Security on an FTP Site Show how to configure authentication for an FTP site Explain that FTP communications are in clear text and the SSL cannot be used

Configuring Auditing for IIS Review standard auditing procedures in Microsoft Windows® 2000 with an emphasis on events that are relevant to a Web server Include the

importance of budgeting time for log reviews in Information Technology (IT) departments

Overview

Using IP Address and Domain Name Restrictions

Configuring Access Permissions for a Web Server

Configuring Authentication for a Web Server

Using Client Certificates

Securing Web Communications Using SSL

Using Local Security Policies on a Web Server

Configuring Security on an FTP Site

Configuring Auditing for IIS

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Having the correct security settings on your Web servers can safeguard against security threats such as unauthorized individuals trying to gain access to restricted information and well-intentioned users who might accidentally alter

or delete important files Balancing the need for security with ease of use and the demand on server resources is one of the key tasks of a Web server administrator

Security in Microsoft® Internet Information Services (IIS) 5.0 is an interaction

of permissions, policies, authentication methods, and secure communications protocols By configuring security correctly on your Web server, you can ensure that your servers are protected from unauthorized access

After completing this lesson, you will be able to:

Use Internet Protocol (IP) address and domain name restrictions for a Web server

Configure access permissions for a Web server

Configure authentication for a Web server

Explain client certificate mapping

Secure Web communications by using Secure Sockets Layer (SSL)

Use local security policies on a Web server

Configure security on a File Transfer Protocol (FTP) site

Configure auditing for IIS

In this module, you will learn

how to secure your Web

servers from unauthorized

access

Using IP Address and Domain Name Restrictions

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

You can configure IIS to grant or deny access to specific IP addresses, a network address, or a Domain Name System (DNS) name If you configure IIS

to grant access to all IP addresses except those that you list as exceptions, then access is denied to any computer with an IP address that is included in the exception list Conversely, if IIS is configured to deny all IP addresses, access

is denied to all remote users except those whose IP addresses have been specifically granted access

When using a domain name restriction, IIS must perform a DNS reverse lookup on every user’s request for access to determine if the requesting

IP address belongs to a restricted domain The reverse lookup will have a significant negative effect on server performance Also, if the restricted domain does not have reverse lookup enabled, the user may gain access to the Web server

Topic Objective

To explain how you can

restrict access by using IP

address and domain name

restrictions

Lead-in

You can restrict access by

using IP address and

domain name restrictions

Important

When a Web user passes through a proxy server or firewall, the user’s IP address is replaced by the IP address of the proxy server or firewall Therefore, the incoming connection to your Web server will be that of the proxy server or firewall Consequently, you can increase security by using IP address

restrictions to ensure that IIS will accept only connections from the proxy server or firewall

To restrict access by using IP address or domain name restrictions:

1 Click Start, point to Programs, point to Administrative Tools, and then click Internet Services Manager

In Administrative Tools, the IIS console is called Internet Services Manager; however, when you open the console, it is called Internet Information Services, also known as the IIS snap-in

2 In the IIS snap-in, right-click the Web site that you want to configure, and

then click Properties

3 On the Directory Security tab, in the IP Address and Domain Name Restrictions box, click Edit

4 In the IP Address Access Restrictions box, click Denied Access

This option restricts access to all computers that you do not name in the

Except those listed below list

5 Click Add, and then, in the Grant Access On dialog box, type the IP

address of the computer to which you will be granting access If you do not

know the IP address and want to search by DNS name, click DNS Lookup, type the name of the computer, and then click OK

6 Repeat step 5 for each IP address to which you want to grant access Click

OK to close the IP Address and Domain Name Restrictions dialog box, and then click OK

Configuring Access Permissions for a Web Server

Using Web-Based Permissions

Using NTFS Permissions

Special Users and Groups

Using the Permissions Wizard

Securing Permissions for WebDav

Setting Permissions on Log Files

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Permissions are the access rights that you give a specific user, or group of

users, that allow them to gain access to and manipulate data on a server By effectively managing permissions, you can control a user’s actions on Web server content

IIS uses several types of permissions and restrictions to determine if a user is allowed to gain access to resources on the Web server IIS uses both its own permissions, including some Transmission Control Protocol/Internet Protocol (TCP/IP) application-level permissions, known as Web-based permissions, and the Microsoft Windows® 2000 NTFS file system permissions IIS includes a Permissions Wizard to set both Web-based and NTFS permissions for files that are associated with a Web site

Permissions should not be confused with authentication Authentication

determines the identity of a user Permissions determine what a valid user can access

In addition to securing Web sites, it is also important that you set appropriate permissions on system resources such as log files, and that you configure permissions for Web Distributed Authoring and Versioning (WebDAV) by effectively using a combination of Web-based and NTFS permissions

Topic Objective

To understand the various

methods for setting

permissions on a Web

server and how these

methods work together

Lead-in

There are several methods

for controlling access to IIS,

and these methods work

together to create a secure

Web server

Note

Using Web-Based Permissions

General Access Permissions

General Access Permissions

Execute Permissions

Execute Permissions

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

To better control security, IIS enables you to configure access permissions on your Web server for specific Web sites, directories, and files These

permissions can be categorized into two general groups:

General access permissions

Execute permissions

These permissions together are called Web-based permissions because they are

applied at the Web server level, which equates to the application layer of TCP/IP As a result, Web-based permissions are enforced equally to all users who are granted access to the Web server, directory, or file For example, you cannot grant Write permissions to one group and Read permissions to another group by using Web-based permissions

Using General Access Permissions

General access permissions can be set at the Web site, directory, and file levels These permissions are:

Read When enabled, users can gain access to static files, such as html or

.txt files, by using a Web browser or Web folder Disabling Read permissions effectively prevents anyone from viewing your Web site’s htm files

Write When enabled, users can change file content and properties on a Web

site This is most commonly accomplished by using a Web folder or a browser capable of posting to a Web site

Topic Objective

To explain how to use

Web-based permissions

Lead-in

Web-based permissions are

one type of permissions that

you can use in IIS

Read and Write permissions affect only requests to static files such

as htm or txt files They have no effect on scripts or executable files In other words, disabling the Web-based Read permissions does not prevent Microsoft Active Server Pages (ASP) scripts or executable files from running Also, disabling the Write permission does not prevent ASP pages or executables from writing to the Web site

Directory browsing Typically, when you first gain access to a Web server

the default document is displayed If the default document is not defined or

is absent, an error is returned to the client computer However, if Directory browsing is enabled, the directory listing for the home folder will be shown instead of an error To display the contents of a Web site by using a Web folder, or WebDAV, you must enable Directory browsing

Script Source Access This option is available only if either the Read or

Write permissions are enabled If Read permissions are enabled, a user can read the source code and if Write permissions are enabled, a user can write

to the source code For example, to write an ASP page to a Web site from a Web folder, you must enable both Write permissions and Script Source Access Additionally, Script Source Access controls whether or not users can copy scripts from or write to the Web site by using WebDAV

When you select Script Source Access, users may be able to view sensitive information, such as a user name and password, from the scripts in

an ASP page, Perl, or other script-based application

Using Execute Permissions

You can set Execute permissions on a per-Web-site and per-directory basis Thus, you can control whether programs and scripts are allowed to run in a specific Web or directory Execute permission settings are:

None This option does not enable any programs or scripts to run in the

specified Web or directory

Scripts only This option enables applications that are mapped to a script

engine to run in the specified directory without having the Execute permission set The Scripts only permission is significantly more secure than the Scripts and Executables permission For example, you can run ASP pages from a Web site or directory that is secured by using the Scripts only permission, but you cannot execute exe or dll files

Scripts and Executables This option enables any application to run in the

specified directory, including applications that are mapped to script engines, Windows binaries, and dll and exe files It is suggested that you use this option with care because, when this option is enabled, a user who has Write access can upload and execute potentially harmful programs

To set Web-based permissions on your Web server, open the IIS snap-in, click the server on which you want to add Web-based permissions, and then

right-click Properties On the Home Directory tab, select the permissions that you

want

Important

Caution

Using NTFS Permissions

Use NTFS Permissions to Define Specific Users and Groups That Can Gain Access to Web Content

Create Security Areas

Secure Your Web Server When Setting NTFS Permissions

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

IIS provides added security by relying on the NTFS permissions that are provided in Windows 2000 Unlike Web-based permissions, which apply to all users equally, you can use NTFS permissions to define which users and groups can gain access to Web content and how those users are allowed to manipulate that content

For example, you can group Web server content into directories, or security areas, and then apply NTFS permissions to the directories so that users have the minimum permissions that they need Additionally, you can use built-in user accounts and groups in Windows 2000 to assist you in granting the minimum permissions possible

Before a user can gain access to any resources on a Web server, IIS first ensures that the user has the appropriate Web-based permissions, and then

Windows 2000 verifies that the user has the correct NTFS permissions

When a user attempts to log on to your Web server, Web-based permissions are applied before NTFS permissions When you combine Web-based and NTFS permissions, the most restrictive permissions apply

Creating Security Areas

Effective application of NTFS permissions is one of the key elements of security in IIS The essential rule for a Web server, particularly one that is accessible from the Internet, is to give users only the minimum permissions for the type of access that they need To help provide minimum permissions, you can group Web server content into directories, such as Scripts, Programs, and Graphics, and then grant permissions on each of those directories accordingly

Thus, each directory acts as a security area For example, permission to execute

programs would be limited to only those folders that contain programs

The following table illustrates a sample Web site structure and NTFS permissions for each zone

Folder type File type Web-based permissions Sample NTFS permissions

Home folder (C:\Inetpub\Wwwroot\Myserver)

Static content (.txt, gif, jpg, html)

Read Execute: None

Everyone (Read) Administrators (Full Control) System (Full Control) Scripts

Home folder\scripts

Script files (.asp) Include files (.inc, shtm, shtml)

Read Execute: Scripts only

Everyone (Read) Administrators (Full Control) System (Full Control) Programs CGI (.exe, dll,

.cmd, pl)

Read Execute: Scripts and Executables

Everyone (Execute) Administrators (Full Control) System (Full Control)

Any section of the server’s file structure that does not require access for users needs to have Full Control permissions for only Administrator and System accounts

Effectively using NTFS permissions on a Web server is not often as simple as applying the most restrictive permissions to a folder There are other

considerations that must be managed to implement a secure and functioning Web server For example, it is common for an HTML file or ASP page to have

a link or reference to another file that is located on another drive or server, or in another folder This situation creates a chain of potentially scattered files, which requires the user to have appropriate NTFS permissions on each file

The minimum system requirements for the Winnt, Winnt\System32, and Winnt\System32\Inetsrv folders are the Read and Execute (RX) permissions

because IIS may need to access these resources on behalf of the user

Securing Your Web Server When Setting NTFS Permissions

There are some special considerations for setting NTFS permissions on any server running Windows 2000 that will help you to secure your Web server For example, grant the Administrators group and the System account Full Control permissions to all disk resources unless you have special security concerns Also, the file system automatically gives the users in the Everyone group Full Control permissions to all new drives When you create new directories, those directories will inherit the Everyone group Full Control permissions Be certain

to change this setting to one that offers better security In addition, if you remove the Everyone group from a resource, replace it with another user or group Finally, do not remove all access to a resource because it will become a block of unusable space on your hard drive However, the owner of the resource will still be able to change permissions and provide access at a later time

Note

Special Users and Groups

IUSR_computer_name

IWAM_computer_name

Interactive

Network

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

When you install Windows 2000 with IIS, several special user accounts and groups are created that can assist you in granting the minimum permissions possible

Windows 2000 includes several built-in group accounts that assist you in granting the minimum permissions possible These include the Interactive and

Network groups Additionally, when IIS is installed, the IUSR_computer_name and IWAM_computer_name user accounts are created for use by IIS

IUSR_computer_name

You may not want to require users who gain access to your public Web sites to provide a user name and password before making a connection to the server

Therefore, a special account is created when you install IIS called the Internet

Guest Account The Internet Guest Account is named IUSR_computer_name

(where computer_name is the name of the computer on which IIS is running),

and it is used to provide anonymous access to a Web site, directory, or file Anonymous authentication is enabled by default

Managing NTFS permissions for the Internet Guest Account is critical to the security of your Web server and network The Internet Guest Account should be permitted only the minimum permissions necessary to gain access to the Web server Anonymous authentication is covered in detail in Using Anonymous Authentication in this module

IWAM_computer_name

The IWAM_computer_name account is also created by IIS and is used solely

for programs that run in Medium or High application protection In some cases, you will need to provide appropriate NTFS permissions to server resources for this account For example, if there is a program gaining access to a database on behalf of a user and that program is running in Medium or High application protection, you will need to provide appropriate NTFS permissions to this account

Topic Objective

To explain the special users

and groups that are created

by Windows 2000 to help

assign permissions

Lead-in

Windows 2000 contains

several built-in user

accounts and groups that

can assist you in granting

the minimum permissions

possible

Interactive

The Interactive group is a built-in, automatically maintained group in Windows 2000 that consists of all users who are logged on locally A local logon is one that appears to the server to have occurred on the server itself instead of remotely Before a user or group can perform a local logon, they must have the Log on Locally user right The Interactive group enables you to restrict or permit access to all users that are authenticated by Basic

authentication

Network

The Network group is a built-in, automatically maintained group in Windows 2000 that consists of all users who are logged on to the server over the network Before a user or group can perform a network logon, they must have the Access This Computer from the Network user right The Network group enables you to control access for all users that are authenticated by Digest

or Integrated Windows authentication

Using the Permissions Wizard

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Setting combination NTFS permissions, Web-based permissions, and authentication can be overwhelming The Permissions Wizard helps simplify the process of setting permissions The Permissions Wizard will set the permission on the root of a Web or FTP site according to the settings that you designate or according to a predefined template By using a predefined template, you can easily bring the security settings of a Web or FTP site and its contents to a known security configuration The predefined templates are:

Public Web Site This configuration is intended for public use over the Internet It uses Anonymous authentication and enables users to view all files and gain access to ASP pages or applications on your Web server It also gives administrators complete control over the site

Secure Web Site This configuration is used for corporate extranets, which

are intranets that you gain access to over the Internet Information on this site is restricted It uses either Basic, Digest, or Integrated Windows authentication if specific types of browsers or proxy servers are used It also gives administrators complete control over the site

When using the wizard, record the security settings on the virtual directories, file system directories, and files before changing them Therefore, if you need

to restore these settings, it will be an easier process After you change the security settings for the files and directories, you will not be able to undo the changes Also, the Permissions Wizard changes both Web-based and NTFS permissions for the directories and files that are involved If you have security concerns regarding these resources, set the Web-based and NTFS permissions manually, rather than by using the wizard

The choices given in the wizard are limited to make it simple to use However, you may want to create your own templates To do this, you must use the IIS

Permissions Wizard Template Maker, which is available in the Microsoft

Windows 2000 Server Resource Kit Review the security settings for both Web

sites and file systems if you have any special security needs

Topic Objective

To explain how the

Permissions Wizard works

Lead-in

The Permissions Wizard

enables you to easily reset

or modify permissions on a

Web site

Delivery Tip

Create a new test Web site

and use it to demonstrate

the Permissions Wizard and

how it works Also, discuss

the settings on the Security

page Do not use a Web site

or folder that is created

during setup

To use the Permissions Wizard:

1 Open the IIS snap-in, right-click the Web or FTP site that you want to

configure, point to All Tasks, and then click Permissions Wizard

2 In the Permissions Wizard, click Next

3 On the Security Settings page, click Inherit all Security Settings or Select new Security Settings from a Template, and then click Next

4 Follow the steps of the wizard, and when you get to the Security Summary

page, review your security settings

5 Click Next, and then click Finish

If you run the Permissions Wizard for a Web site and choose to inherit all security settings, users might be denied access to the Web site To restore users’

access to the Web site, open the Home Directory property page for the Web site, and then select Read and Scripts only permissions When prompted,

designate that all virtual directories and files inherit these settings

Securing Permissions for WebDAV

Control WebDAV Access by Controlling:

Web-based permissions

NTFS permissions

Authentication

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Web Distributed Authoring and Versioning (WebDAV) extends the HTTP 1.1 protocol to enable users to publish, lock, and manage resources on a Web site Accessing a Web site by using WebDAV enables you to manage the files on a remote Web server as if the files were located locally on your desktop

Furthermore, because WebDAV is an extension of Hypertext Transfer Protocol (HTTP), it is often not blocked at firewalls Typically, when a user gains access

to a Web server by using Web folders, that access occurs by using WebDAV

WebDAV capability is enabled by default

Controlling WebDAV access is essentially the same as controlling normal access to Web server content by using Web-based permissions, authentication, and NTFS permissions

The difficulty with controlling WebDAV security lies in Web-based permissions If you have a group of developers who want to use WebDAV to publish content to a Web site, you must enable the Web-based Write

permissions for the Web site Web-based permissions cannot be granted to a single user or group like NTFS permissions, so if the NTFS default permission

of Everyone Full Control is in effect, anyone gaining access to a enabled application can write to the Web site

WebDAV-If you have a Web site, virtual directory, or file that enables a user to make changes by using WebDAV, you must manage security by using NTFS permissions

Topic Objective

To explain how to secure

permissions for WebDAV

Lead-in

Controlling WebDAV access

is essentially the same as

controlling normal access to

Web server content by using

Web-based permissions,

authentication, and NTFS

Note

Setting Permissions on Log Files

Use Log Files to Monitor Web Server Activity Including:

The IP address of the client

The time that the access occurred

The file name that is requested

Place Log Files on a Different Volume Than the Web Server Content

Use Appropriate Permissions to Secure Log Files

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Log files record Web server activity including the IP address of the client computer, the time that an access occurred, and the requested file name It is essential that you secure the IIS server log files because, if hackers gain access

to them, they can potentially delete or alter log files that recorded their actions, leaving virtually no trace of who they are or the files to which they gained access

To prevent hackers from gaining access and to increase performance, it is a good idea to place log files on a different volume than the Web server content

so that the log files can be more tightly secured By default, log files that are generated are located in %SystemRoot%\System32\LogFiles, but they can be relocated to any local drive

The following permissions will help to secure your log files:

Administrators (Full Control)

System (Full Control)

Everyone (Read Write Change)

Topic Objective

To explain how to set

permissions on log files

Lead-in

It is important to set

permissions correctly on log

files so that hackers cannot

delete or alter the log files

that recorded their actions

For Your Information

Log files require Read,

Write, and Change

permissions for users In

some cases, IIS writes the

log files in the security

context of the user

Configuring Authentication for a Web Server

Using Anonymous Authentication

Using Basic Authentication

Making Basic Authentication More Secure

Using Digest Authentication

Using Integrated Windows Authentication

Using Kerberos V5 Protocol vs NTLM in Integrated Windows Authentication

Using Multiple Authentication Methods

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Before a user can gain access to a server running Windows 2000, that user must

be authenticated to a user account in Windows 2000 The first step in authentication is presenting credentials, followed by system validation of those credentials After the credentials are validated, the user can gain access to the resources for which they have been authenticated, provided that they have sufficient NTFS permissions

IIS supports several types of authentication including Anonymous, Basic, Digest, and Integrated Windows, which includes the Kerberos V5 protocol When you configure authentication for a Web server, it is important to know the advantages and limitations of each type of authentication so that you can use the method that best meets your security needs

Each of these methods provides a means by which a user can log on to the Web server by using a Web browser The user account is then used to check NTFS permissions to determine if access will be permitted or denied These

authentication options offer varying degrees of security and compatibility, and they have different system requirements

Topic Objective

To explain how to configure

authentication for a Web

server

Lead-in

IIS supports several types of

authentication

Web server authentication is a communication between the browser and the server that uses HTTP headers and error messages

The flow of communication follows these steps:

1 The Web browser makes a request to a Web server, and then the Web server performs an authentication check If the Web server does not permit

anonymous access, it sends back an error message, usually 401—Access Denied

2 The Web browser prompts the user for a user name and password, which is used to construct a new request to the Web server that contains the

Using Anonymous Authentication

No User Name or Password Required

IIS Can Authenticate Anonymous Users

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Because the Internet is extremely anonymous, and it is uncommon to make users authenticate before giving them access to public Web sites, IIS enables

you to configure Anonymous authentication Anonymous authentication enables

users to gain access to the public areas of your Web site without being prompted for a user name or password Also, when using Anonymous authentication, you do not need to create a user account for each user

Authentication, like many of the features in IIS, can be set at the Web site, directory, or file level

How Anonymous authentication works:

• When you configure your Web site for anonymous access and a user attempts to connect to your public site, IIS will automatically authenticate

the user by using the Internet Guest Account (IUSR_computer_name) The

Internet Guest Account has two characteristics: it is granted the Log on Locally permission, and it is a member of both the Guests and Everyone groups in Windows 2000

By default, all Web sites are configured to use the same Internet Guest Account This configuration enables anonymous users who authenticate to one Web site

to be able to browse another Web site However, IIS enables you to designate a different Internet Guest Account for any Web, directory, or file

allows users to access your

Web site without a user

name or password

The Internet Guest Account is part of the Guests and Everyone groups in Windows 2000 Therefore, you should carefully review the file permissions that you give to these groups to ensure that the permissions are appropriate for your anonymous users By using NTFS, you can specifically deny the Internet Guest Account access to sensitive information if it is not appropriate for anonymous users

Because the name of the Internet Guest Account is always

IUSR_computer_name, it is known to hackers and can therefore be a security risk If you consider IUSR_computer_name a security risk, you can designate a

different account to use for anonymous logons and then deny the

IUSR_computer_name account access to Web resources Designating a

different account to use for anonymous logons will also enable log files and audit recordings to contain more specific information, and NTFS permissions to

be more specific Also, the Internet Guest Account is persistent in IIS, so if you delete or rename the account, it will be recreated the next time the server restarts

Caution

The Allow IIS to Control Password Option

Windows 2000 is designed with the ability to authenticate users who attempt to access the server However, Windows 2000 has the ability to delegate that logon process to other services This is known as subauthentication

IIS has the ability to perform the subauthentication for the anonymous user

You can control this capability by using the Allow IIS to Control Password

option

The Allow IIS to Control Password option is enabled by default

Enabling the Allow IIS to Control Password Option

When the Allow IIS to Control Password option is enabled, IIS authenticates

an anonymous request with the Internet Guest Account, also known as

IUSR_computer_name, and the anonymous user password that is stored in the

metabase IIS then informs Windows 2000 that the authentication has occurred

When you use the Allow IIS to Control Password option, the Internet Guest

Account is authenticated as a network logon, which requires the Access This

Computer from the Network user right Enabling Allow IIS to Control Password has a significant security benefit because users who gain access to a

server through a network logon cannot gain access to remote network resources This is because IIS does the authentication instead of the server running

Windows 2000; therefore, user access is limited to the resources on the IIS server

The Internet Guest Account must have either the Log On Locally or Access This Computer from the Network user right The user right that is

required depends on whether the Allow IIS to Control Password option is

enabled

Disabling the Allow IIS to Control Password Option

Conversely, if you disable Allow IIS to Control Password, IIS does not

perform the subauthentication, but instead allows Windows 2000 to authenticate the user This is a local logon and requires the Log On Locally user

right IIS grants the Log On Locally right to the IUSR_computer_name

account

Because the anonymous user is authenticated as a local logon, the anonymous user credentials can be forwarded to other servers for authentication In other

words, Allow IIS to Control Password enables you to control whether or not

your anonymous users have access to network resources

Note

Note

Using Basic Authentication

Has Widespread Support and Compatibility

Sends Passwords Over the Network in an Unencrypted Form

Requires Users to Have the Log on Locally User Right

Provides Ability to Set Default Logon Domain

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Basic authentication is an authentication protocol defined as part of the

HTTP1.0 protocol and is supported by the majority of browsers Its largest advantage is its widespread support and compatibility The disadvantage of Basic authentication is that passwords are sent over the network in an unencrypted form by using Base64 encoding

Basic authentication is widely used on the Internet because it is easy to implement This protocol is also used when higher levels of security are not needed You could use Basic authentication when you need to have the widest possible compatibility, to authenticate through a proxy server, or to allow the authenticated user to gain access to network resources that are not on the Web server Although Basic authentication is widely compatible, it must be used with caution because someone could easily intercept and decipher passwords by monitoring communications on your network

All authentication methods require that the user enter a valid user name and password for an active user account in Windows 2000 Enabling Basic

authentication does not create those accounts, but enables a method to

authenticate to the accounts by using the Web server

How Basic authentication works:

1 The user’s Web browser displays a dialog box in which users can enter their assigned Windows 2000 user names and passwords

2 The Web browser then attempts to establish a connection with the Web server by using this information The password is Base64 encoded before being sent over the network

3 If the server rejects the information, the Web browser will display the authentication dialog box up to three times unless the user either enters a valid user name and password or closes the dialog box

4 When the Web server verifies that the user name and password correspond

to a valid Windows user account, a connection is established

Basic authentication has

widespread support and

compatibility, but passwords

are sent over the network in

an unencrypted form

Basic authentication is a local logon that requires users to have the Log on Locally user right A user who has the Log On Locally user right and can obtain physical access to the computer that is running the Web server will be permitted

to log on to the server Be aware of this potential security issue when determining where to physically locate the server

Additionally, users that are authenticated by Basic authentication must log on

by using a valid Windows user name and password The user name usually includes a Windows domain name and an account user name

These components of the user name identify a computer or group of computers that are administered by the Web server as a single entity For example, a user who logged on by using an account called User1 on the Sales1 domain would log on as Sales1\User1

By default, the Web server enables users to log on by using the local account database If you want users to log on to a domain controller, they must provide the domain name in addition to the user name By using Basic authentication, you can set a default logon domain so that IIS will enable users to log on to the domain controller instead of the local server Thus, users do not need to provide

a domain name when they log on

To set the default logon domain:

1 In the IIS snap-in, right-click the Web site on which you want to set the

default logon domain, and then click Properties

2 On the Directory Security tab or, for a file, on the File Security tab, under Anonymous access and authentication control, click Edit

3 In the Authentication Method dialog box, select the Basic Authentication check box, and then click Edit

4 In the Basic Authentication Domain dialog box, either type or browse to a new default logon domain Click Use Default to use your Web server’s default domain name, and then click OK

Making Basic Authentication More Secure

Basic Authentication Alone Not Suitable for Widespread Use on the Internet

Use SSL to Make Basic Authentication More Secure

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

By itself, Basic authentication is not suitable for widespread use on the Internet However, you can make Basic authentication more secure by combining it with encryption through the SSL protocol SSL is an industry standard protocol that encrypts all communication between the client computer and the server Using an SSL connection will secure Basic authentication by encrypting the logon transaction However, using SSL for only the initial logon is insufficient

to secure this kind of authentication After the user has logged on, the browser continues to send the user name and password to the server for every requested file Consequently, if an administrator enforces SSL only for the logon and not for subsequent access requests, the non-SSL communications can easily be captured, thus revealing the user name and password SSL will be covered in detail in the Securing Web Communications Using SSL topic

Topic Objective

To explain that if you use

Basic authentication, you

need to make it more

secure

Lead-in

If you use Basic

authentication, it’s a good

idea to make it more secure

by using SSL

Using Digest Authentication

Does Not Send Passwords Over the Network

Uses a Form of Non-reversible Encryption

Works Through Firewalls and Proxy Servers

Requires Users to Have the Log on Locally User Right

Requires That Specific Conditions Be Met

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Digest authentication is a solution to many of the disadvantages of Basic

authentication, and it involves a different way of transmitting authentication credentials When you use Digest authentication, passwords are not sent over the network Instead, the browser takes both the user’s password and other

information about the user’s request to the Web server and creates a hash, a

form of non-reversible encryption, which it then sends it to IIS Because

nonreversible encryption is encryption that is not mathematically feasible to

decipher, the original text cannot be deciphered from the hash

Like Basic authentication, Digest authentication can work through proxy servers, and users are required to have the Log On Locally user right

Additionally, IIS uses a subauthentication process for Digest authentication logons As described in Anonymous authentication, this sub-authentication process results in the users’ credentials being unable to leave the IIS server so that the user cannot gain access to remote network resources

How Digest authentication works:

1 The Web server sends specific information that is used in the authentication process to the Web browser The browser takes the user name, password, and other pertinent information and creates a hash The additional information will help prevent someone from copying the hash value and reusing it

2 The resulting hash is sent back over the network to the Web server along with the additional information

3 The server then performs an identical hash operation by using a plain text copy of the user’s password The user’s account must be enabled for this capability

4 The server then compares the hash value that it received from the client computer with the one it produced with the plain text copy of the user’s password Both hashes will be identical if the user provided the correct password

Topic Objective

To explain what Digest

authentication is and how it

Conditions for Using Digest Authentication

For Digest authentication to work, the following conditions must be met:

IIS is configured for Digest authentication

The browser must support Digest authentication Currently, only Internet Explorer version 5 or later meets this criterion

The IIS server is either running the Active Directory™ directory service or is

a member of a domain and has access to a server that is running Active Directory

All user accounts that use Digest authentication must be configured to have

the Store Passwords Using Reversible Encryption option enabled This

option is on each user object in Active Directory, and setting this option will store a reversible encrypted copy of the user’s password in Active

Directory

To configure IIS for Digest authentication:

1 Open the IIS snap-in, right-click the Web site on which you want to add

Digest authentication, and then click Properties

2 On the Directory Security tab, under Anonymous access and authentication control, click Edit

3 Select the Digest Authentication check box, and then click OK

If the server is already running Active Directory, perform these steps to set up a Windows 2000 user account for Digest authentication:

1 In Administrative Tools, click Active Directory Users and Computers

2 Open the domain that you want to administer, and then double-click the user name that you want to use with Digest authentication

3 On the Account tab, select the Store password using reversible encryption check box, and then click OK

4 Right-click the user name in the directory, click Reset Password, and then click OK

When you enable Store passwords using reversible encryption, you must

manually change the user’s password or force the user to change the password At that time, the clear text copy of the password is recorded in Active Directory

Anytime a password is stored in reversible encryption it creates a

security risk, so Store Passwords Using Reversible Encryption is disabled by

default If you decide to enable it, be certain that your servers are well protected from attack

Warning

Using Integrated Windows Authentication

Uses One of Two Types of Authentication Methods

NTLM

Kerberos V5 protocol

Only Supported by Internet Explorer Version 2.0 or Later

Does Not Work Through a Proxy Server or Firewall

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Integrated Windows authentication is a more secure authentication in IIS

because user names and passwords are not sent across the network Integrated Windows authentication actually uses one of two types of authentication methods The first is the Challenge/Response authentication in Microsoft Windows NT®, also known as NTLM The second is the Kerberos V5 protocol

If possible, IIS will use the Kerberos V5 protocol; otherwise, it will use NTLM

In Integrated Windows authentication, the browser attempts to use the current user’s credentials Using the current user’s credentials makes Integrated Windows ideal for an intranet in which users have already provided a domain logon

How Integrated Windows authentication works:

1 Unlike Basic authentication, Integrated Windows authentication does not initially prompt users for a user name and password The client computer uses the current Windows user information for Integrated Windows authentication

2 If the authentication exchange initially fails to identify the user, the browser will prompt for a user name and password, which it will process by using Integrated Windows authentication

3 Internet Explorer will continue to prompt the user until the user either enters

a valid user name and password or closes the dialog box

Even though Integrated Windows provides more than adequate security, you should keep these points in mind: only Microsoft Internet Explorer version 2.0

or later supports this authentication method, and Integrated Windows authentication does not work through a proxy server or firewall

secure authentication in IIS

because user names and

passwords are not sent

across the network

Using Kerberos V5 Protocol vs NTLM in Integrated Windows

Authentication

Kerberos V5 Protocol :

Users have access to network resources located on other servers in the domain

Specific conditions must be met

Has many advantages over NTLM

NTLM:

Users only have access to resources on the IIS server

Has disadvantages over Kerberos V5 Protocol

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

To effectively manage security, it is important to know the differences between the Kerberos V5 protocol and NTLM when using Integrated Windows

authentication because these protocols provide different capabilities For example, if users are authenticated by using the Kerberos V5 protocol, they will have access to network resources located on other servers in the domain If users are authenticated by using NTLM, they cannot be authenticated to other servers, and thus may only have access to resources on the IIS server

The Kerberos V5 Protocol

When Integrated Windows authentication is enabled, the Kerberos V5 protocol will be used if all of the following conditions are met:

IIS is configured to use Integrated Windows authentication

The client computer is running Windows 2000 Server and Internet Explorer version 5 or later

The server is running Windows 2000 Server and IIS or later

The client computer and the server are in the same Windows 2000 domain

or in trusted domains

If the Web site name does not match the server name, you must register the Web site name as the Service Principal Name For example, if the Web site name is www.contoso.msft and the server name is

Development.contoso.msft, you must register www.contoso.msft as a Service Principal Name To perform the registration, use the Setspn tool

from the Microsoft Windows 2000 Server Resource Kit compact disc

Topic Objective

To explain the difference

between Kerberos V5

Protocol and NTLM when

using Integrated Windows

authentication

Lead-in

It is important to know the

differences between the

Kerberos V5 protocol and

Advantages of the Kerberos V5 Protocol

The Kerberos V5 protocol is the preferred method for authentication because it offers the following advantages over NTLM:

More secure The Kerberos V5 protocol is built on a standard that is more cryptographic and functional than NTLM Kerberos V5 authentication involves a complex series of authentications and encryptions that permit a user to gain access to a resource By contrast, NTLM authentication is less complex, so passwords that are sent through NTLM can be compromised

Mutual authentication The Kerberos V5 protocol authenticates both the server and the client computer NTLM authenticates only the client computer, which means that the client computer is not assured that the authenticating server is not being impersonated

Improved reconnection time After you have authenticated to a server, if you disconnect and then reconnect within the default time of eight hours, you do not need to re-authenticate

Permits delegation Delegation is the passing of a user’s credentials to other

network resources This occurs, for example, when a user requests access to

a resource on IIS that requires IIS to contact another server on behalf of the user

NTLM

When conditions are not present for the Web server to use the Kerberos V5 protocol, IIS will authenticate by using NTLM

NTLM is similar to Digest authentication because it transmits the users’

credentials using a hash The passwords are never transmitted across the network, which makes it much more secure than unencrypted Basic authentication Unlike Digest authentication, however, you don’t have to specially configure user accounts

Limitations of NTLM

Some limitations of NTLM are:

NTLM does not work through a proxy server

The only browser that supports NTLM is Internet Explorer version 2.0 or later, which makes NTLM unfeasible for most sites offering access to the general public over the Internet

It is not possible for you to choose whether IIS uses the Kerberos V5 protocol

or NTLM by using the IIS snap-in You specify Integrated Windows authentication and then IIS chooses which protocol to use based on negotiations with the browser This negotiation process requires additional network

resources

Using Multiple Authentication Methods

Anonymous and Integrated Windows Are Enabled by Default

Both Digest and Integrated Windows Take Precedence Over Basic Authentication

Digest and Integrated Windows Cannot Be Used with FTP Sites

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

When a browser makes a request to a Web server, it always interprets the first request as anonymous Therefore, the browser does not send any credentials If the server does not accept anonymous users or if the Internet Guest Account on the server does not have permissions to gain access to the file that the user requests, IIS responds with an Access Denied error message and sends a list of the authentication types that are enabled

If Anonymous authentication is the only authentication method that you enable, all users will be permitted access However, if you place a file or directory on the Web server that you want to secure by using NTFS permissions, access to that resource will fail because only Anonymous authentication is permitted Consequently, you typically configure IIS to use more than one authentication method Anonymous and Integrated Windows are enabled by default, which permits anonymous users to gain access to the site and then be prompted for credentials when they request access to a secure resource

If you want to authenticate users by using a browser that does not support Integrated Windows authentication, you must use Basic authentication

However, you can elect to enable both Integrated Windows and Basic authentication If both Integrated Windows and Basic authentication are enabled, the browser determines which method to use If the browser supports the Kerberos V5 protocol or NTLM, it uses Integrated Windows; otherwise, it uses Basic authentication If you also require Digest authentication, the browser will use Basic first, and then Digest authentication

Topic Objective

To explain that multiple

authentication methods can

be used to secure the IIS

server

Lead-in

For the most security, it’s a

good idea to use multiple

authentication methods

Keep in mind the following points when you enable multiple authentication methods:

If Anonymous and one or more other forms of authentication are selected, the other forms of authentication will be used if Anonymous authentication fails, or if NTFS permissions do not permit access to files and directories for the Internet Guest Account

Your Web server will use the Basic, Digest, or Integrated Windows authentication methods only if Anonymous access is not selected

Both Digest and Integrated Windows authentication take precedence over Basic authentication To ensure that users are authenticated with only Basic authentication, you must disable all of the other authentication methods

Digest and Integrated Windows authentication cannot be used with FTP sites

IIS 5.0 also supports Fortezza, which is the U.S government security

standard and is used in high-security environments

Note

Multimedia: Overview of IIS Security y

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

IIS provides several different security features; therefore, it is important to know when each security feature is used and how they work together to grant or deny access to Web server resources

IIS provides the following security features:

This presentation provides

an overview of the various

security features in IIS,

when each security feature

is used, and how they work

together to grant or deny

access to Web server

resources

Lab A: Securing Web Resources Using Permissions and Authentication

***************************** ILLEGAL FOR NON - TRAINER USE ******************************

Objectives

After completing this lab, you will be able to:

Use the IIS Permissions Wizard

Set specific authentication methods for a Web site

Use NTFS permissions to require authentication

Use Web-based permissions to control access to content

Enable Execute permissions

Prerequisites

Before working on this lab, you must have:

Knowledge about NTFS permissions and how they are used to secure files

An understanding of the differences between Anonymous, Basic, and Integrated Windows authentication

Experience using Internet Explorer

Estimated time to complete this lab: 30 minutes

Topic Objective

To introduce the lab

Lead-in

In this lab, you will secure

Web resources on a folder

by using permissions and

authentication

Exercise 0

Lab Setup

The Lab Setup section lists the tasks that you must perform before you begin the lab

1 Log on as Administrator

with a password of

password

a Log on as Administrator with a password of password

2 Run the batch file

Exercise 1

Using the IIS Permissions Wizard

In this exercise, you will create the Security Lab Web site, examine the NTFS permissions on the

Home folder, and run the IIS Permissions Wizard to set security for the Web site

Scenario

You have been assigned the task of creating and securing a Web site You decide to use the IIS

Permissions Wizard to set permissions and authentication for the site

1 Create a Web site using the

b In the IIS snap-in, in the console tree, expand server_name (where

server_name is the name of your server)

c Right-click server_name, point to New, and then click Web Site

d In the Web Site Creation Wizard, click Next

e On the Web Site Description page, in the Description box, type

Security Lab and then click Next

f On the IP Address and Port Settings page, in the Host Headers for

this site box, type SecurityLab and then click Next

Double-check this entry If it is incorrect, your Web site will not be accessible

g On the Web Site Home Directory page, in the Path box, type or browse to D:\Inetpub\SecurityLab_Home and then click Next

h On the Web Site Access Permissions page, verify that the Read and

Run scripts check boxes are selected, click Next, and then click Finish

2 Check the NTFS

permissions that were

granted for the Home folder

of the Security Lab Web

site

a In the IIS snap-in, right-click the Security Lab Web site, and then click Explore

b In Windows Explorer, in the left pane, right-click the

SecurityLab_Home folder, and then click Properties

c In the SecurityLab_Home Properties dialog box, on the Security tab,

view the listed permissions

Tasks Detailed steps

What permissions are granted to the SecurityLab_Home Properties folder and do they create a secured site?

Everyone – Full Control

No Anyone can write and delete files or execute programs in the folder

3 Close the

SecurityLab_Home

Properties dialog box, and

then close Windows

Explorer

a In the SecurityLab_Home Properties dialog box, click Cancel

b Close Windows Explorer

4 Run the Permissions Wizard

and use the following

settings:

• Select new security

settings from a template

• Scenario: Public Web

Site

• Replace all directory

and file permissions

(recommended)

a In the IIS snap-in, right-click the Security Lab Web site, point to All

Tasks, and then click Permissions Wizard

b On the Welcome to the IIS 5.0 Permissions Wizard page, click Next

c On the Security Settings page, click Select new security settings

from a template, and then click Next

d On the Site Scenario page, in the Scenario list, click Public Web Site Read the resulting description, and then click Next

e On the Windows Directory and File Permission page, read the recommended permissions Verify that Replace all directory and file

permissions (recommended) is selected, and then click Next

f On the Security Summary page, carefully review the list of changes that are about to be made, and then click Next

g On the You have successfully completed the IIS 5.0 Permissions

Wizard page, click Finish

5 Again, check the assigned

NTFS permissions for the

Home folder of the Security

Lab Web site

a In the IIS snap-in, right-click the Security Lab Web site and then click

Explore

b Right-click the SecurityLab_Home folder, and then click Properties

c On the Security tab, examine the listed permissions