Objective 3.4: Designing Security for IIS

IIS provides many services in Windows Server 2003. It supports Web, FTP, SMTP, and NNTP services. Web sites can be configured as Internet sites, intranet sites, or extranet sites. Some contents of intranet sites need to be available as content for extranet sites. Therefore, it is a tedious task to design security to address every one of these implementations. Let s detail some of the most common security implementations .

The most common Web sites are public Internet sites. These have to be enabled for public access by default. Therefore, we need to enable anonymous login for all the public Web sites. We need to take extra caution to ensure the IUSR_ComputerName account is not mishandled. The IUSR_ComputerName account should only belong to the Guests Windows group ; it should never be a part of the Administrators or Power User groups. These groups access will severely compromise IIS security. The IUSR_ComputerName account should not have any write access either, only read access. We should also enable IIS logging on all public Web sites.

Intranet sites are internal to an enterprise. Therefore, we can leverage the existing security architectures for an intranet site. We can use integrated Windows authentication, digest authentication, or basic authentication as our authentication mechanisms. The user should already have a Windows account to log on to desktops and servers of the enterprise. We can use this account for basic authentication to integrated Windows authentication. Integrated Windows authentication is the preferred option. However, we need to enable Kerberos to implement integrated Windows authentication. Most large organizations have Active Directory implementations. We can leverage this Active Directory implementations to use digest security for our intranet sites. The enterprise DCs will oversee the intranet site communications. Therefore, the best place to start troubleshooting the intranet security breaches is the event log of the IIS servers and DC machines.

Extranet sites are similar to intranet sites, except that they are for an external audience. This is a mechanism of sharing business information with business partners . We will not have the luxury of enterprisewide Active Directory or network implementations of intranet sites under extranet implementations. The two organizations will have different IT systems on different IT platforms in most cases. Therefore, integrated Windows authentication or digest authentication will be difficult to implement. (It will be a tedious task even if both organizations are on Windows platforms. We need to create two-way trust bridges to communicate from one organization to another.) The best authentication technique will be basic authentication. However, we need to implement an SSL encryption to secure the clear text credential communication between the two organizations. We should also enable IIS logging on every extranet site to facilitate debugging of IIS security breaches. Let s look at how to secure IIS 6.0 installations.

Objective 3.4.1: Securing IIS Installations

IIS is not installed by default in the Windows Server 2003 setup, except in the Web Server Edition. There are three different ways to install IIS:

• Use the Configure Your Server Wizard

• Use the Add or Remove option from the Control Panel

• Use the Unattended Setup

Head of the Class
Default IIS Access Options

All of the installation methods described here will install IIS in locked mode. That means you only get access to static Web material. All the ASP.NET scripts, Server Side Includes, WebDAV access and Front Page Extensions will be disabled by default. If you try to access any of these facilities, you will get a 404 (Page not found) error. You must enable these features through Web Services Extensions node in IIS Manager if you want to use them.

If you enable these features, you can disable them later to increase security. This involves using the Web Service Extensions node in the IIS MMC. Any Web service extension can be enabled or disabled individually as long as it s registered in the Web Service Extensions node, or you can prohibit all extensions from running. You can also add new extensions, and you can figure IIS so that a specific application will be able to use the Web Service Extensions.

Web Service Extensions is a new feature in IIS 6.0. This utility will give a Control Panel-like functionality to your IIS components. We will be able to allow, prohibit, or change the properties using this tool. This will also let you add new IIS extensions (ISAPI applications and third-party IIS tools) to the IIS 6.0 server. You can also enable or disable all Web Service Extensions by using this MMC. Here is a list of components the Web Service Extensions can enable or disable:

• ASP.NET executions

• ASP executions

• CGI and ISAPI applications

• Front Page Server Extensions 2000 and 2002

• WebDAV support for IIS directories

  We can get to the Web service extensions by using Start Administrative Tools IIS Manager and clicking on the Web Server Extensions node on a selected server name . Figure 6.21 is similar to a default view of the Web Service Extensions window.

  
  Figure 6.21: Web Service Extensions View

 

Installation best practices will ensure the optimum scalability and performance of IIS 6.0. Here are some of the important steps to ensure maximum security with IIS:

• The file system onto which you install IIS should be NTFS. If the partition is not already formatted as NTFS, upgrade the FAT32 file system to NTFS prior to installation or during the upgrade process.

• The Configure Your Server Wizard will let you install multiple application server components (DNS, file server, and so forth). Therefore, you can install other components parallel to IIS 6.0 setup.

• Use unattended setup to install IIS on multiple machines. (This mechanism will use a script file to install IIS. We do not need to run the installation wizard manually.)

• Make sure the Internet Connection Firewall (ICF) is enabled and configured properly unless you will be relying on a separate firewall product. Let s spend some more time on this new topic in Windows Server 2003.

Internet Connection Firewall

Windows Server 2003 comes with a very basic internal software firewall called the Internet Connection Firewall (ICF). This facility is disabled by default. If you enable it, the firewall can be configured to enable or disable protocol access through IIS. (The protocols in question that relate to IIS are HTTP, HTTPS, FTP, and SMTP.) IIS 6.0 will not function correctly if the ICF is enabled and the relevant protocols are disabled (for example, the IIS 6.0 Web server will not function if the HTTP and HTTPS protocols are disabled). You basically have two options when it comes to the ICF:

• Disable the firewall and use an existing firewall mechanism.

• Enable the firewall and filter the correct protocols.

Designing & Planning
Firewall Protection for Web Servers

Microsoft recommends that you use the ICF for small to medium- sized Web project developments if you do not have a more sophisticated firewall solution (such as Internet Security and Acceleration Server) deployed. ICF is adequate to protect Internet traffic on most Web sites. However, large organizations should consider ISA or another heavy-duty firewall product. You do not need to enable the ICF if you have a corporate firewall to protect your Web servers.

It is common to place Web servers that are to be accessed from the Internet in a demilitarized zone (DMZ) or perimeter network (also called a screened subnet). This can be done in one of several ways. You can configure a tri- homed DMZ in which you have a firewall server (such as ISA) with three interfaces (an internal network interface to the LAN, a public interface with a public IP address, and a DMZ interface with a public address). Alternatively, you can configure a back-to-back DMZ, where you have both an external and internal firewall server.

 

The most cost-effective method is to use the second option and maximize Windows Server 2003 s built-in functionality. Exercise 6.08 shows you how to configure the protocols.

Exercise 6.08: Configure Protocols in Internet Connection Firewall

1. Open Start Control Panel Network Connections Local Area Connection .

2. Navigate to the Advanced tab and select the Protect my computer and network by limiting or preventing access to this computer option from the internet check box (see Figure 6.22).

   
   Figure 6.22: Enabling the Internet Connection Firewall

3. Click the Settings button and navigate to the Services tab. This will bring up a window to select or deselect the access protocols to your server. This is the list of protocols the IIS server will understand to process user requests . Select the correct check box next to the protocol name to enable requests using the particular protocol. You can disable the protocol access by clearing the check box. Your screen should be similar to Figure 6.23.

   
   Figure 6.23: Available Protocol Configuration Window

4. Select the appropriate protocols for your organization. Most organizations will enable HTTP, HTTPS, SMTP, and FTP access through the firewall. Each time you select a protocol, a small window will appear, prompting you to enter the machine name or IP address of the server that hosts the service. Figure 6.24 shows the entry to enable HTTPS access to a machine called home-net.

5. Click OK and repeat the process for all other protocols.

   When you complete these steps, you have enabled the correct access to your organization through the ICF.

 

Risks to IIS Servers and How to Harden IIS Against Them

We have discussed the IIS installation risks and their remedies in the pervious section. Let s now discuss some security risks to the IIS servers. We will concentrate on an operational IIS Web server and its challenges. We will use a fictitious AllWebRequest online shopping site as an example to illustrate the scenarios.

The AllWebRequest online shopping site sells bicycles and bicycle accessories. This Web site is hosted on a Windows Server 2003 IIS 6.0 implementation. The scripting is done using ASP.NET pages that are written in C# language. The users will use a third-party e-commerce gateway for checkout facilities. We have used basic authentication as our preferred authentication method to implement the e-commerce shopping site.

Figure 6.24: Entering Machine Name or IP Address to Configure the Firewall

The first risk is the non-HTTP requests that are directed to the IIS server. We need to disable all non-HTTP and HTTPS data. We do not need to open any ports other than port 80 and 443 for this public Web site. (Intruders can penetrate the system if other ports are open. For example, intruders can mimic sales orders or purchase orders if we open port 21, which is used for e-mail access. If an intruder writes an e-mail from port 21, it can be forwarded to the third-party e-commerce gateway to transfer funds to bogus accounts. The third-party e-commerce gateway will authorize the transaction since it arrived from our servers. The remedy for this is to enable The ICF or use the corporate firewall to filter all non-HTTP and non-HTTPS data to the server.)

The next risk to the AllWebRequest IIS server is the authentication mechanism. The Web site is hosted internally within the enterprise. However, the payment e-commerce gateway is an external entity. Therefore, there are two risks here. The online user will use clear text to transfer credentials to the IIS server. The IIS server will also transmit clear-text payment details to the payment gateway. Both of these transactions are risks to the enterprise. An intruder can intercept either of these transmissions with the help of packet-snooping software. Therefore, we need to encrypt both these communication lines with SSL.

We should also be careful of the file structure of the AllWebRequest online shopping site. The third-party e-commerce gateway broker will be an executable or a DLL. Therefore, we need to assign execute permission at the Web site level to proceed to the payment gateway. We need to assign execute permission to the entire root directory if we mount this DLL or .EXE on the root directory. This is not a recommended practice. The complete root directory will have execute access, which is not a healthy scenario for the IIS server. We should minimize write and execute access as much as possible on IIS servers. The best way to get around this problem is to copy the DLL or exe to a new directory and only assign execute access to that new directory (and leave the root directory with read access).

We also need to factor the ASP.NET scripting manipulations (ASP.NET code can be scripted in a malicious way to harm the IIS 6.0 servers). This is another risk to the enterprise. We should not use any HTTP GET methods to post data to the server in our client-side scripting. This will display the form tag information on the URL box of the browser. A clever intruder can piece together some malicious request by observing these requests. Therefore, we should use the HTTP POST form method to direct HTTP requests to the IIS server. The Intruders can also pass in JavaScript <script> code </script> tags in the URL string. This is picked up by the URLScan algorithm in IIS 6.0. We should also be careful of the SQL injection issues with IIS. This is similar to the previous JavaScript mechanism. The key difference is that the code fragments are SQL database commands. These commands are generated by the hackers by observing HTTP GET entries to the Web site. (HTTP GET posts are appended to the URL query string and are displayed to the user. The user can change the URL query string and re-post the data to observe a different outcome of the same Web page.) Therefore, we should never display database table names in the query string. We can stop these SQL injections with URLScan and configuring the SQL database to best practices. (URLScan is can algorithm that every oncoming request is subject to in IIS 6.0. This will scan the URL query string for invalid characters and <Script> tags and filter them from the query string.) We can also minimize the query string manipulations by assigning execute permissions to a small number of directories. Some other IIS best practices are:

• Log on with the least credentials Do not log on as Administrator to the IIS servers. This will enable the servers to configure software with fewer credentials. Use the RunAs command if you want to run IIS Manager as an administrator.

• Disable the unwanted services in IIS 6.0 Disable the FTP, NNTP, or SMTP services that are not used on the server. This will save valuable resources to be dedicated to the WWW service.

• Keep virus scanners up to date A virus scanner compares its virus signature database with file system folders. This signature database needs to be updated regularly, since new viruses are introduced frequently. Therefore, we need to make sure these signature databases are up to date to protect our IIS and Web site files from viruses.

• Keep all software patches up to date Windows Server 2003 comes with Auto Update version 1.0. This will inform server administrators when new patches become available.

Now let s investigate how to secure other IIS 6.0 components; specifically , FTP, NNTP, and FTP.

Securing FTP

The File Transfer Protocol (FTP) is a valuable component of IIS 6.0. FTP is used to swap or share files between servers and clients . This could be dangerous practice for businesses with sensitive information. Most large organization firewalls will block FTP access. (It is unhealthy for the organization; for example, a disgruntled employee could FTP out sensitive data to its competitors .)

We can create individual accounts for each FTP user using IIS Manager. We also need to provide a username and password to initiate the FTP transfer. These credentials are passed as clear text from the client to the FTP server, which is not secure for the enterprise. An intruder can sniff these packets and obtain the credentials. The intruder can use these credentials to download sensitive information or upload malicious content to the server.

Therefore, how do we secure FTP communication? We need to implement FTP communication over a secure channel like VPN. VPNs use the Point-to-Point Tunneling Protocol (PPTP) or Secure Internet Protocol (IPSec) to encrypt data and facilitate secure FTP communication. We can also use SSL encryption on WebDAV supported directories for the same purpose.

Securing NNTP

The Network News Transfer Protocol (NNTP) is another important component of IIS 6.0. The default settings will enable any user to connect to the newsgroups without any authentication process. The users can request to view all newsgroups and subsequently subscribe to them anonymously. In some cases, we need to restrict access to the newsgroups to protect sensitive information. We can increase security on our NNTP implementation by:

• Enabling basic authentication or integrated Windows authentication on the NNTP Service We need to create user accounts and add them to appropriate groups initially. Then we need to grant access to the correct News folder directories to enable authentication. We need to be careful regarding the local service account that NNTP uses. This account needs to be granted access to the complete NNTP directories to manage the NNTP implementation correctly.

• Restricting NNTP access by IP address All IP addresses have access to NNTP by default. We can configure NNTP to grant or deny according to a specific IP address in IIS 6.0. We can also use wildcard characters to specify a subnet mask to deny or grant access. We can use domain names also. However, domain name wildcards will need to do an additional Domain Name Service (DNS) lookup. Therefore, it will be slower than the previous method.

• Restricting the number of NNTP operators Operators are the administrators of the NNTP service. Windows Server 2003 enables all the users in the Administrator group as NNTP operators. We need to configure this setting to prevent all Administrator group access. We should only let a small number of operators manage the NNTP service.

• Using SSL to encrypt the communication We can also use SSL at the server and the client. The SSL certificate needs to be installed at the server. The client newsgroup reader (for example, Outlook Express) should support SSL communication to facilitate this.

Securing SMTP

The Simple Mail Transfer Protocol (SMTP) service is responsible for e-mail communication between IIS 6.0 and its clients. Most e-commerce sites use the SMTP service to send and receive purchase orders. Therefore, we need to protect our SMTP service from malicious attacks. Here are some ways to secure the SMTP service in IIS 6.0:

• Minimize the number of operators that can manage the SMTP service This is similar to NNTP service operators. We need to enable a small team or a designated Windows account group to manage the SMTP operator access.

• Use Transport Layer Security (TLS) We can configure SMTP to use TLS on all incoming mail connections. TLS is similar to SSL. It will secure the connection between the SMTP server and the mail client. However, it will not authenticate users to the SMTP services. We need to generate key pairs at the SMTP servers to implement TLS and share them with the incoming mail clients.

• Restrict IP and network access This is similar to NNTP service IP restrictions. We can grant or deny access on an IP address or a subnet mask.

• Set basic authentication or Windows integrated authentication on outbound messages This is also similar to the NNTP implementation.

The preceding are some ways to secure all IIS 6.0 components. Let s now investigate the new security features in IIS 6.0.

New Security Features in IIS 6.0

IIS 5.0 and earlier versions were constantly patched by hotfixes from Microsoft. IIS was once considered one of the main security holes in the Windows architecture. This was a major deterrent to using IIS as a commercial Web server. IIS 6.0 comes with an impressive list of new security features designed to win back commercial users. You will learn about these new features in the next sections.

Advanced Digest Authentication

Advanced digest authentication is an extension of Digest Security . Digest Security uses MD5 hashing to encrypt user credentials.(username, password, and user roles). So, what s the purpose of MD5 hashing? Basic authentication sends the username and password details over the network medium in base-64 encoded format. These details can be easily sniffed (captured with a protocol analyzer) and decoded by an intruder, who could then use the credentials for nefarious purposes. The MD5 hash enhances security by applying more sophisticated, more difficult to crack cipher algorithms to deter these intruders. An MD5 hash is made up of binary data consisting of the username, password, and realm . The realm is the name of the domain that authenticates the user. All of this means that Digest Security is more secure than basic authentication.

Exam Warning  

An MD5 hash is embedded into an HTTP 1.1 header. This is only supported by HTTP 1.1-enabled browsers. Digest or advanced digest authentication mechanisms cannot be enabled if the target browsers do not support HTTP 1.1. Internet Explorer 5.0 and later support HTTP 1.1, as well as recent versions of Netscape, Opera, Mozilla, and other popular browsers.

Advanced Digest Security takes the digest authentication model a bit further by storing the user credentials on a DC as an MD5 hash. The Active Directory database on the DC is used to store the user credentials. Thus, intruders would need to get access to the Active Directory to steal the credentials. This adds another layer of security to protect access to Windows Server 2003 Web sites, and you do not need to modify the application code to accommodate this security feature.

Test Day Tip  

Both digest and advanced digest authentication only work on Web Distributed Authoring and Versioning (WebDAV) enabled directories. WebDAV is a file sharing protocol that is commonly used in Windows Internet- related applications. WebDAV was previously referred to as Web Folders. It is a secure file transfer protocol over intranets and the Internet. You can download, upload, and manage files on remote computers across the Internet and intranets using WebDAV. WebDAV is similar to FTP. WebDAV always uses password security and data encryption on file transfers (FTP does not support these tasks ).

Server-Gated Cryptography

Communication between an IIS Web server and the Web client is done using the HyperText Transfer Protocol (HTTP). These HTTP network transmissions can be easily compromised due to their text-based messaging formats. Therefore, we need to encrypt these HTTP calls between the client and the server. Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are the most common encryption mechanism used on Web sites. SSL/TLS enables secure communication by encrypting the communication channel with a cipher algorithm. TLS is the later version of the SSL protocol.

IIS 5.0 and earlier versions included SSL/TLS for secure communication between the Web client and the server. Server Gated Cryptography (SGC) is an extension of SSL/ TLS. It uses a strong 128-bit encryption mechanism to encode the data. SGC does not require an application to run on a client s machine. It was available since IIS 4.0. SCG needs a valid certificate at the client Web browser, which can be encoded and decoded. A special SGC certificate is needed to enable SGC support built in to IIS 6.0. We can obtain a certificate by contacting a CA. This certificate can be added to IIS as any other certificate. IIS 6.0 supports both 40-bit and 128-bit encryption sessions. This means your old 40-bit SGC certificates are still valid in IIS 6.0. SGC is commonly used for financial sector applications (banking and financial institutions) to protect data.

Test Day Tip  

Forty-bit SGC certificates in IIS 6.0: If you try to open an existing 40-bit SGC certificate, you might get a The certificate has failed to verify for all of its intended purposes warning. These certificates are targeted to Windows 2000 servers. Thus, you can have a valid certificate and can be misled by this warning. Windows 2000 only supports 40-bit encryption, and Windows Server 2003 supports both 40-bit and 128-bit encryption.

Selectable Cryptographic Service Provider

SSL/TLS offer a secure environment in which to exchange data. The downside is performance. SSL/TLS are very CPU intensive . IIS 6.0 comes with a new feature called the Selectable Cryptographic Service Provider (CSP) that lets the user select from an optimized list of cryptography providers. A cryptographic provider will provide you with an interface to encrypt communication between the server and the client. CSP is not specific to IIS and can be used to handle cryptography and certificate management. Microsoft implements two default security providers: the Microsoft DH SChannel Cryptographic provider and the Microsoft RSA SChannel Cryptographic provider. The Microsoft implementations are optimized to IIS 6.0 for faster communications. The private keys for these Microsoft implementations are stored in the Registry. The Microsoft Cryptographic API (Crypto API) for every provider contains identical interfaces for all providers. This will enable developers to switch between providers without modifying the code. Each provider will create a public and a private key to enable data communication. The private key is stored on hardware devices (such as PCI cards, smart cards, and so forth) or in the Registry. The other CSP keys can also be stored in the Registry. It makes more sense to store private keys as Registry settings for computer access to the server. The private key will be stored on smart cards and other portable devices if we have a mobile distribution environment. (This is similar to Plug and Play support for devices in Windows 2000 and Windows Server 2003 environments.) The CSP can be configured using the Welcome to the Web Server Certificate Wizard (click Properties of a Web site, select the Directory Security tab, and then click the Server Certificate button).

Configurable Worker Process Identity

One of the most serious problems with previous IIS versions was the instability of the World Wide Web Publishing Service (WWW). The failure of this service could result in the shutdown of the machine. IIS 6.0 runs each Web site in an isolated process environment. This isolated process environment is called a worker process . Therefore, a Web site malfunction could be limited to its process environment (and hence will not lead to a Web server shutdown). IIS 5.0 did not implement a worker process model. IIS 6.0 can also run an IIS 5.0 isolated environment. The IIS system administrator can choose between the worker process model or the IIS 5.0 isolation model by selecting the correct option from Services tab by right-clicking on Web Sites . You can click the Run WWW service in IIS 5.0 isolation mode option box to run IIS in IIS 5.0 isolation mode. IIS will run on the worker process model if you do not check the box. IIS can run only at one mode at a time. Therefore, we will not be able to run worker process model Web sites and IIS 5.0 isolation mode Web sites simultaneously .

The worker process can be run with a lower level of permission than the system account. The worker process will shut down the application if the IIS server is targeted with malicious code. IIS 6.0 can detect malicious code by observing the rapid fail-over mechanism. This process will be explained later in the chapter. The rapid fail-over program will restart IIS 6.0 when the system has generated a specified number of errors in a specified amount of time. IIS 6.0 (which is by default run by the local system account) is not affected since the worker process can be configured to run under a less privileged account.

Default Locked Down Status

The default installation of IIS 6.0 will result in a lightweight Web server. The only default feature available will be the access to static content. This is to deter any malicious access by intruders. This restricted functionality is referred as Default Locked down status. This feature will force the system administrators to manually enable and disable the features that are necessary for the applications. They can do this through the Web Services Extensions node of the IIS Manager.

New Authorization Framework

Authorization refers to the concept of confirming a user s access for a given resource. (Authentication refers to obtaining access to the resource. When a user is authenticated, we need to make sure whether he or she is authorized to perform any tasks on the resource. This is the basis of authorization.) There are two types of ASP.NET authorization options available for IIS 6.0:

• File authorization The FileAuthorizationModule class is responsible for file authorization on Windows Server 2003 systems. The module is activated by enabling Windows authentication on a Web site. This module does access control list (ACL) checks on the authorization access on an ASP.NET file for a given user (it could be either .asmx file for ASP.NET application, or a .asmx file for a Web service) . The file is available for the user if the ACL confirms the user access to the file.

• URL authorization The URLAuthorizationModule class is responsible for URL authorization on Windows Server 2003. This mechanism uses the URL namespace to store user details and access roles. The URL authorization is available to use at any time. The authorization information is stored in a text file on a directory. The text file will have an <authorization> tag to allow or deny access to the directory (this will apply to the subdirectories if not specified). Here is a sample authorization file:

   <authorization>     <allow users="Chris"/>     <allow roles="Admins"/>     <deny users="Gayan"/>     <deny users="?"/> </authorization> 

  This file will enable Chris to access its content. It will also allow anyone with an Admins user role. The user Gayan is denied access. Anyone else will not be able to gain access to this directory (indicated by the ? wild card).

Objective 3.4.2: Designing a Monitoring Strategy for IIS

We have learned to implement security measures to protect IIS 6.0 from intruders. These security measures need to be monitored frequently to detect any compromise of these mechanisms. Therefore, we should also spend some time designing a monitoring strategy for IIS 6.0

There are several ways of monitoring IIS 6.0 security measures. All Windows Server 2003 service calls can be monitored through the event logs. We can also use the Network monitor for this purpose. We should also enable logging on all of the IIS activities. This will enable us to backtrack to the original intrusion using the chronological entries. All these measures should be implemented as baseline requirements to facilitate all IIS 6.0 servers in the enterprise. Let s discuss how to implement a monitoring baseline now. We will first detail all the baseline requirements and then discuss how they help to identify the intruders in the section Identifying a Security Incident .

Objective 3.4.3: Creating a Monitoring Baseline

Implementing a monitoring baseline is an important element of enterprise architecture. This will set security standards for the organization and act as the minimum security requirements for the enterprise. We can do the following to create a monitoring baseline. All these tools are available in Windows Server 2003 or native in IIS 6.0. We will discuss each item in detail in subsequent sections.

• Configure IIS logs

• Enable Security Auditing

• Monitor Event log activities

• Enable Heath Detection

• Monitor Network Monitor and System Monitor activities

Configure IIS Logs

We can enable logging on Web sites and FTP sites. This will record user and server activity. These log files will enable system administrators to regulate access to content, evaluate the popularity of different Web sites, plan security requirements, and troubleshoot potential security breaches. We can use several log formats to record data. IIS logging can be enabled or disabled with IIS Manager on demand. Although logs can be read by a text editor, there are specialized third-party software tools to analyze these logs. We can also use Object Database Connectivity (ODBC) connections to log the IIS entries to SQL server databases.

Test Day Tip  

IIS 5.0 logs record the encrypted requests when we log SSL connections. IIS 6.0 logs the decrypted amount of bytes (which reflect the actual request size , not the SSL encryption additions). IIS 5.0 only logs entries in ASCII format, while IIS 6.0 logs entries in both ASCII and UTF-8. The time taken for the Web request is measured by HTTP.Sys. It will activate the time mechanism when the first byte of the request arrives. It will calculate the time span when the last byte is sent to the client.

We can record logs in many formats: W3C log file, IIS log file, and NSCA log file. W3C log file format is an ASCII format that can be customized. The other log file formats are not customizable. Here is a sample W3C log file entry:

 #Software: Internet Information Services 6.0  #Version: 1.0 #Date: 2003-12-26 17:42:15 #Fields: time c-ip cs-method cs-uri-stem sc-status cs-version 17:42:15 172.11.255.255 GET /test.htm 200 HTTP/1.0 

The first three lines define the IIS server settings and time stamp. The fourth line describes the log file captions (the description of the fields that we are logging information on). The last line is the actual log entry. The log entry was made at 17.42.15 from the machine 172.11.255.255. The client sends a GET HTTP request to the server to the test.htm page. This call is successful and returns a 200 response (200 means success). The communication was done using HTTP 1.0. Now let s learn how to enable logging in IIS 6.0 and customize log fields.

Exercise 6.09: Configure IIS Logging

1. Open IIS Manager ( Start Administrative Tools IIS Manager ).

2. Navigate to the Web site or the FTP site. Select Web Sites and then Default Web site for this demonstration.

3. Right-click on the Default Web site and select Properties .

4. Select the Web Site tab. Click the Enable logging option box. Your screen should be similar to Figure 6.25.

   
   Figure 6.25: Enable Logging for Default Web Site

5. Click the Properties button to customize log entries. The Logging Properties window will appear. The General tab will enable you to modify the log filename and the frequency that the log is written (for example, hourly, daily, monthly, and so forth).

6. Click the Advanced tab and you can select the fields you want to log in the IIS logs. It is good practice to log the date, time, server IP, host, URI query, username, and client IP address as minimum requirements to investigate security breaches. Your screen should be similar to Figure 6.26. Click OK when finished customizing the log fields.

   
   Figure 6.26: Customizing Log Fields

 

Enable Security Auditing

Security events are logged in the Security log, accessible by administrators via the Event Viewer. An audit entry can be either a Success or a Failure event in the Security log. A list of audit entries that describes the life span of an object, file, or a folder is referred to as an audit trail. The primary types of events that you can choose to audit include:

• Computer logons and logoffs.

• System events (when a computer shuts down or reboots, or something happens that affects system security, such as the audit log being cleared, system time is changed, or an invalid procedure call port is used to try to impersonate a client).

• User and computer account management tasks (such as the creation of accounts or changes to account status or permissions).

• Access to files, folders, and objects.

Configuring security auditing will help you track potential security issues and provide evidence in relation to security breaches. It is best practice to create an audit plan before you enable auditing on your system. The audit plan will detail the purpose and objectives of the audit. The audit plan should contain the following:

• The type of information you want to audit

• How much time you have to review audit logs

• The resources you have for collecting and storing audit logs (disk space, memory, and processor usage)

• The intended scope of the audit

You ll need to ask yourself some questions as you prepare the audit plan. Is the purpose of the audit plan to prevent security breaches from unauthorized sources? If so, you need to enable the audit failure events on logons and collect information on it. Is the objective of the auditing to get a snapshot of the organization s activities for forensic purposes? In that case, you need to enable both success and failure events to collect data on all applications.

It is important to remember that the audit trail information can result in a very large amount of data if both the success and failure audits are enabled. Too wide a scope for the audit can also make it difficult for you to find the information you re looking for within a huge file that records thousands of events.

The Audit Account Logon Events and Audit Logon Events items are enabled for auditing by default in Windows Server 2003. By default, object access auditing is not enabled. You can view the security audit entries under the Security section of the Event Viewer .

Head of the Class
Periodically Back Up Audit Information

The administrative account or administrative privileges are a prime target for hackers so there is always the possibility of intruders gaining administrator access to your system. With these privileges, an intruder can do malicious damage to your system and delete the audit events from the event log. If this happens, there will not be an audit trail to determine the cause and the damage to the system. To minimize the damage that would be caused by such an attack, you need to duplicate the audit information periodically. You can use the Microsoft Operations Manager (MOM) to copy audit events periodically and store them in a secure network drive; this provides a backup of the audit trail information.

MOM is a monitoring and management tool released by Microsoft in 2000 and used for a variety of enterprise-level management tasks. You can download a trial version from Microsoft s Web site at www.microsoft.com/_MOM/default.asp.

 

Let s learn how to define an audit policy on a local computer. The local audit policy dictates the audit procedures on the local machine. It does not dictate the audit policy for the rest of the network computers. Exercise 6.09 walks you through the steps required to enable the auditing policy on the local computer. You need to have administrator access to perform any of the auditing policy changes.

Exercise 6.09: Enabling Audit Policy on a Local Machine

1. Click Start Programs Administrative Tools Local Security Policy .

2. In the left pane of the console, expand Local Policies and click Audit Policy . Your screen should look similar to Figure 6.27.

   
   Figure 6.27: Local Audit Policy Settings

3. In the right details pane, select and double-click the option for which you want to define audit policy. For this exercise, select the Audit object access option. You see a dialog box similar to Figure 6.28. Here you can choose to enable success and/or failure audits by checking the option box(es).

   
   Figure 6.28: Enable Success or Failure Audit Options

4. Click OK or the Apply button. Now we can enable auditing on objects, files, and folders on the local computers.

 

Monitor Event Log Activities

The Event Viewer is used to monitor many different aspects of server activity. To access this tool, click Start Programs Administrative Tools Event Viewer . The Event Viewer is displayed as an MMC that is stored at SystemRoot\System32\_eventvwr.mmc . The Everyone user group has read and execute access to manipulate the Event Viewer. The Administrator group and the System account have full control (full control consists of read, write, modify, and execute permissions).

Event log data is displayed in the Event Viewer. There are at least three different event log files: the Application, Security, and System logs. Your Event Viewer can display additional logs, depending on applications and services you have installed on the server. For example, if the computer is configured as a DNS server, it will have a DNS log in addition to the three default logs. There are five major event types. The error, warning , and information types occur in the Application and System logs. The Success Audit or Failure Audit types occur in the Security log. Following are descriptions of each event type and its function:

• Error Indicates a significant problem in the system. This can have adverse effects on the application or operating system if ignored (for example, the DHCP service not starting at reboot can lead to the lack of IP assignment for the network computers).

• Warning Indicates the possibility of future errors to come, but conditions do not pose an immediate threat to the system (for example, e.g., l ow disk space is a warning that can lead to various errors if ignored, but does not indicate an immediate threat).

• Information Describes a successful operation of the system or an application (for example, SQL Server logs an information event when the SQL server starts up correctly).

• Success Audit All audited security events that are completed successfully will be logged in this category, (for example, a successful user logon when security auditing is enabled).

• Failure Audit All audited security events that fail will be logged here (for example, you will receive an authorization error if you try to log on to a shared drive to which you don t have access. This will result in a failure audit entry in the Security event log).

The event log service is automatically started when the Windows Server 2003 system starts. There are three default log files available in Windows Server 2003. These same logs were also available in Windows NT, 2000, and XP. The default logs are:

• Application log This log is available for application developers and system administrators. The developers can monitor their application activities in this log. The system administrator can trace and monitor the applications and how they interact with each other using this utility. It can be used to record application errors, warnings, and information events. Scripting languages (such as C#, C++, VB 6.0, and so forth) include Application Programming Interface (API) calls to log entries in the Application log. This log can be used to display a myriad of application errors (for example, the application can record a Source file not found error when files needed to complete a transaction are missing).

• Security log Events that affect system security are logged in this event log. These events include failed or successful logon attempts, creating, opening or deleting files, changing properties or permissions on user accounts and groups, and so forth. We will be using this log to monitor IIS security closely.

• System log Events related to Windows system components are stored in this log file. This includes entries regarding failure of drivers and other system components during startup and shutdown.

Enable Health Detection

Health detection simplifies IIS Web site management. Health detection is performed by IIS over all its worker processes. This adds another level of reliability to the Web applications. The inetinfo.exe process (IIS) will check the availability of each worker process (different Web sites) periodically. This time limit can be configured by IIS Manager (240 seconds by default). Therefore, IIS will maintain a heart beat between its worker processes. (Heart beat is similar to the ping facility. The IIS server will try to communicate with worker processes to make sure they are alive .)

Health detection enables IIS to monitor its worker process functionality. We can enable pinging and configure rapid application fail-over (discussed later in the chapter). You can also set the startup and shutdown time for a worker process using the option.

Exercise 6.10: Enable Health Detection

You can enable health detection by following this process. This process only works if you re running in worker process isolation mode.

1. Start IIS Manager ( Start Administrative Tools IIS Manager ).

2. Select Application Pools .

3. Navigate to the correct Web site.

4. Right-click on the site and click Properties .

5. Select the Health tab and enter your proffered settings. Your screen should be similar to Figure 6.29.

   
   Figure 6.29: Enable Health Detection

6. You can configure the ping interval using the Enable Pinging group box. This interval describes the timeframe to contact a worker process to make sure it functions accordingly . The default setting is 240 seconds. (Rapid-fail protection is initiated by IIS when too many application pool errors are generated for specified timeframe. The default is five errors occurring in five minutes. This scenario will trigger the IIS to restart and issue a 503 error to the client.) You can also configure the worker process a startup time (if the worker process restarts) and a shutdown time (if the worker process gets into a deadlock position) using this screen.

7. Click OK or the Apply button to apply the changes.

 

We can also use the Network Monitor and System Monitor to analyze abnormal activity in your network and system, respectively. Let s discuss how we identify these security breaches.

Identifying a Security Incident

Most intruders will not have a valid username or a password to hack in to the enterprise systems. They will use sophisticated random password generators to find the correct password. (The username may be compromised earlier. Most enterprises will have a policy that will force employees to change their passwords monthly. Therefore, obtaining the password is harder than obtaining the username.) IIS 6.0 authentication can be configured to stop any user if he or she is not able to provide the correct password in three attempts. If the user is unsuccessful after three attempts, the logon details will be written to the Security log. Therefore, we can use the following mechanisms to identify the security breach:

• Analyze Security log and investigate the user access. We can investigate the user s abnormal activities and disable the user account.

• The entries will also be logged at IIS logs. We can analyze the IIS logs and obtain more user details and the client IP address data. Then, we can restrict access to them using our Restrict user on IP address mechanisms.

• We can also use the Security Auditing information as evidence against the intrusion. We should have a security trail of all objects since we changed the local audit policy in the previous section.

• Some of these security breaches might be able to corrupt the worker process and stop the Web site. It will be difficult to pinpoint the exact server that is affected by this in a large Web farm. We can use health detection in IIS 6.0 to recover from this scenario. It will be able to inform the IIS administrators very quickly since there is a heart beat between all the servers.

• Most of these intrusions are carried out during nonbusiness hours. Therefore, we can use Network Monitor to analyze network traffic and suspicious client IP activities during these hours.

• Most organizations will build a custom authentication DLL to facilitate application access. This DLL can integrate into System Monitor to analyze the authentication calls and network traffic that is generated by the incoming clients. We can measure the activity with the help of performance counters and analyze the results.

Objective 3.4.4: Design a Content Management Strategy for Updating an IIS Server

Content is the greatest driver for a successful Web site. The Web site content needs to update very frequently in the current Web sites. Most Web sites are operated as Web farms. (A Web farm is a collection of multiple IIS servers that are load balanced to facilitate higher throughput of Web requests simultaneously.) Therefore, we need to deploy content to these multiple IIS servers quickly and efficiently . We also need to manage the content and its deployment (for example, roll back or schedule content deployment on a specific timeframe).

There are several tools available to deploy content to Web farms. Microsoft Content Management Server (CMS) is a dedicated server that manages Web content. We can specify the source content directories and destination directories in a GUI interface. CMS will manage the deployment or the rollback of the content. We will also have a GUI interface to view the logging details of the job. Microsoft Site Server 4.0 also came with a content management project. This is also similar to CMS functionality. There are also several third-party content management tools (for example, Vignette) available that will plug in to IIS 6.0. Sharepoint Portal Server can also be configured to take a role as content management server if necessary.

We can also use the virtual directory concept to centralize important information and minimize deployment. We will be able to point all the Web farm machines to a single machine to avoid content deployment to all servers. This method will consume valuable network resources since all the servers need to obtain data form this single point. We might also need to provide for a backup server if this single content point goes offline.