- Overview
- Installation
- WWW Service
- FTP Service
- Exploit Scanners
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
WWW Service
The WWW service is the most commonly installed component of IIS. This service accepts incoming requests from the Internet or local network, processes the request, and sends the respective Web pages back to the client. This includes processing any programming, database connections, encryption, or any other service required by its clients.
Because the client computer accesses resources on the IIS, there are numerous security issues that need to be addressed to ensure a client is properly restricted from system files, password files, and other important data that should not be passed via the WWW service.
The first step in securing the WWW server is to configure the global settings upon which the rest of the WWW configurations are based. To do this, right-click on the Web Site folder and select Properties. This will open a screen similar to Figure 13.17.
)
Figure 13.17 Web Sites Properties.
Master Web Site Properties
The WWW service is configured in several layers. At the top is the Master Web Site properties that are inherited by any specific sites. Using a setup like this, an Administrator can ensure that any newly created Web site is secure. The following describes each of the tabs and their sections as they apply to security.
ISAPI Filters
This is the first property sheet visible upon opening the Master Web Site properties. While the settings on this tab are not direct security concerns, knowing the purpose of this sheet is important. Each of the filters listed represents a .dll file that gives functionality to the Web server. In the case that a vulnerability is discovered that exploits one of these files, you will need to use this page to remove or change the settings for the Web server. These files can only be installed and adjusted from this window.
Home Directory
The next tab in the properties window is Home Directory. This window, as seen in Figure 13.18, is used to control the global default settings for each Web site under its control. We recommend that you enable Log visits and leave the rest of the options unchecked. The following discusses each of the options in detail and our suggested setting for them.
)
Figure 13.18 Web Sites Properties.
Permissions
Read (Disabled): While a Web site will need to be configured as Read to allow users to view any resources, we suggest that each site be manually configured to allow read access after the site is created. This will ensure no access is granted until the site is ready for clients.
Write (Disable): This option should always be disabled, unless you want to give users the ability to write to all Web sites. This setting can be enabled, if required, at the site level.
Directory Browsing (Disable): This option should always be disabled. By allowing this, you give users the ability to view all the file names and folders in a Web site. This only serves to provide hackers with more information they can exploit.
Logging (Enable): This will enable logging on each Web site you add later. While not necessary for operation, it is best to maintain vigorous logging in case a hack attempt occurs.
Index this Resource (Disable): This option should remain disabled at the global level. If searching ability is requested by individual Web sites, it can be enabled at the local level.
Execute Permissions (None): This will ensure that no users can run script files or programs by default. If individual sites require this, it can be enabled at the local level.
Application Settings
By default this section is correctly set up, with the exception of the sheets settings available by clicking on the Configuration button. The Application name: should remain blank and Execute Permissions: should be kept at None.
TIP
Unmap any unnecessary file extensions. This will limit the risk of the Web server falling victim to new vulnerabilities.
Application Configuration: This set of property sheets controls the internals of the Web server. It is important to understand how the Web server will respond to requests. Every time a client requests an ASP page from IIS, it must first process the file using a program. The application configuration is responsible for controlling this. In addition, the IIS server must be configured for debugging, timeouts, and more. If the server is configured properly at the Master level, the lower levels will inherit the settings.
Mappings: This sheet, shown in Figure 13.19, is used to link all file extensions to the files responsible for their processing. It is recommended that you remove any extensions you will not want the Web sites to incorporate into their services. (e.g., .htr files are used to perform remote password administration).
Figure 13.19 WWW Master Site Application Configuration—Mappings sheet.
Options: The Options sheet, shown in Figure 13.20, is used to set the timeout settings for both the session and the script. The default settings are adequate. However, if you are experiencing a DoS (Denial of Service) attack, you may want to decrease the timeout settings. What could be a simple programming error on a Web page can be misinterpreted as a DoS attack. These settings need to be a balance between programming needs and security threats. In addition to timeout settings, ensure the Enable parent paths is disabled. If enabled, a hacker could exploit folder traversing vulnerabilities.
Figure 13.20 WWW Master Site Application Configuration—Options sheet.
CAUTION
Be careful in limiting the default timeout settings. If an ASP script exceeds the timeout, it will return as "failed." This could prevent an application from operating properly.
Debugging: This sheet, shown in Figure 13.21, defines the debugging options for the WWW server. While useful in development machines, sending detailed ASP errors back to the requesting client could reveal sensitive information. In situations of high security, it is recommended that a generic message is sent instructing the user to contact the Webmaster.
Figure 13.21 WWW Master Site Application Configuration—Debugging sheet.
Cache Options: This sheet, shown in Figure 13.22, controls the speed in which ASP scripts are processed by the IIS. If the results of the ASP script can be stored, the next time the script is called it will not have to be processed.
Figure 13.22 WWW Master Site—Application Configuration Cache Options sheet.
Process Options: This sheet, shown in Figure 13.23, is set up correctly by default. It holds two important settings that should be left as is. The Write unsuccessful client requests to event log should be enabled because it will capture a hacker performing a brute force or scan attack on a server. Finally, the CGI script timeout follows the same suggested guidelines as the ASP script timeout configured in the Options sheet.
Figure 13.23 WWW Master Site—Application Configuration Process Option sheet.
)
Figure 13.19)
Figure 13.20)
Figure 13.21)
Figure 13.22)
Figure 13.23Directory Security
The other important properties sheet of the WWW Master Site, with respect to security, is the Directory Security tab (see Figure 13.24). This tab is used to control the access level and authentication methods for all users who request information from the Web site.
)
Figure 13.24 WWW Master Site Properties—Directory Security sheet.
Anonymous Access and Authentication Control
This section is used to configure the accounts that are used to access the IIS server resources. To adjust the settings, click the Edit button.
The Authentication Method the Web site(s) use to control user access is mainly determined by whether the site is on the Internet or an Intranet. If the Web site is to be used solely by users on a Windows-based Intranet, a domain controller should control their access. Therefore, Anonymous Access should be unchecked. This allows greater access control, as individual accounts can be granted access to Web server resources. However, if the Web server is primarily to be used for sites that will be accessed via the Internet, it is recommended that Anonymous Access remain checked.
Although not typically required, you can change the account used to control anonymous access to the server. Using the Browse button, you can select another account through which access is allowed. You can also uncheck the Allow IIS to control password option and enter your own password.
Changing the Anonymous account is often done because the IUSR_computername resets the Log on as batch job and Access this computer from the network rights each time the computer is rebooted or the IIS server is restarted.
The final setting that can be adjusted, depending on your needs, is the Authenticated access setting. More information on authentication methods follows this section.
Authentication Overview
Digest Authentication for Windows Domain Servers
This is used only if the Web server is operating on a Windows 2000 Server or .NET Server and the passwords must be stored in a file on the local server. However, this adds an extra complication to the Web server configuration and is not completely secure.
While similar in features to Basic authentication, Digest authentication uses a more secure means of passing credentials. For a client to gain access, the following must occur:
Server passes some data to client.
Client combines server information with username, password, and some extra data to create a hash.
Hash is sent to server with client's data and it too creates a hash.
If the hash matches, the client is granted access.
When this option is selected, it is important to note that the Administrator must have a password policy in effect and evoked. Without this requirement met, Digest authentication will not work.
There are also weaknesses with the Digest Authentication RFC that make it vulnerable to several types of attack. However, if the only other option is Basic Authentication, Digest should be used. Microsoft cannot patch the weaknesses, as they are design errors that were in place before Microsoft adopted it. Any changes by Microsoft would make Digest noncompliant with RFC standards.
Basic Authentication
This authentication method sends passwords in clear text. While it does provide a measure of protection, a rogue sniffer on the network could capture the passwords and provide a hacker with an easy target.
If this authentication option is your only choice, it should be used in conjunction with SSL. To use SSL, you must obtain a Server Certificate, require a specific port to use for data transfer, and disable all other forms of authentication.
)
Figure 13.25 WWW Master Site Properties—Directory Security—Authentication Methods sheet.
Integrated Windows Authentication (Figure 13.25)
This option is the best for any time anonymous access is disabled or access is restricted using NTFS access control lists. It uses Windows NT Challenge/Response and Kerberos v5 protocol. However, in order to use this type of authentication the client must be using Internet Explorer.
One or all of these types of authentication can be used. The client will first try Anonymous authentication, and if that fails the server will send a list of all the accepted types of authentication. The client will try each acceptable type until the list is complete or access is granted.
Default Web Site Properties
If the Master Web Sites Properties were configured according to the previous instructions, every individual Web site should be locked down by default. This ensures that you control who has access to what and removes the threat that an important setting is forgotten. With the exception of ISAPI Filters and Web Site, the property sheets are similar at the Site/folder/file level; therefore, you can use the following recommendations throughout.
To access each site's individual properties, right-click on the root folder of the Web site (e.g., Default Web Site) and select Properties. This will open a window similar to Figure 13.26.
)
Figure 13.26
Default Web Site Properties.
Web Site
The first properties sheet you will see is labeled Web Site. This sheet controls various settings that are important to configure properly in order to keep a site secure. The following will describe each part and its security implications.
Web Site Identification (Figures 13.27, 13.28)
)
Figure 13.27 Use the Advanced Multiple Web Site Configuration sheet for adding virtual hosts.
)
Figure 13.28 Enter Host Header Name, port, and IP address to define a virtual host.
Description: This is the name that will be used in the ISM tree to identify the Web site.
IP address: This is the IP address through which the Web site will be accessed. If the server hosts several sites for several networks, and one site needs to be accessed explicitly from one network, the IP address for that network can be selected. This allows access only on the selected NIC.
TCP/SSL port: This allows you to configure a Web site to run on a custom port. This provides a small measure of protection if the Web site needs to be hidden from casual surfers, or if there are multiple Web sites operating through one NIC.
Advanced: This allows you to configure a site's specific access options. If the Web hosts more than one site, the Advanced options allow the administrator to use either the Host Name Header or the IP address to control access to additional sites. This allows more than one site to run on one NIC with one IP address.
Connections
Connection timeout: This setting controls how long a client's session will remain open if there is no activity. Keep this setting at or under 900 to reduce the chance of an inadvertent Denial of Service (DoS) condition, which could occur if several connections were established at one time and then left inactive. Due to the limited number of open connections, an abundance of inactive sessions will cause a server to stop responding.
HTTP keep-alives: HTTP keep-alives are used to keep a session active across several requests. This keeps the number of sessions per client at a minimum and reduces the threat of an inadvertent DoS condition.
Enable Logging
Logging should always be enabled. In case of an attack, the logs will help you patch holes quickly.
Active log format: This setting should always be kept on its default setting, "W3C Extended Log File Format." This type of logging allows for more customization of the items recorded.
Properties:
The General Properties sheet allows you to configure various options. Typically, you should keep the default settings, with the exception of the log file location. By changing the log file location, you provide an extra layer of protection in case the server is hacked. Any good hacker will remove all trace of himself or herself; thus, making the log files difficult to locate will also help to keep them intact.
The Extended Properties sheet allows you to adjust what information you want logged. If you suspect a hacker or need to troubleshoot an error, enabling more options may provide the missing piece of information you need (Figures 13.29, 13.30).
Figure 13.29 Extended Logging Properties sheet.
Figure 13.30 Extended Logging Properties sheet.
)
Figure 13.29)
Figure 13.30Home Directory
The Home Directory is the second of four key sheets that will need adjusting. This sheet controls the general access permissions for the Web site, where the Web site is physically located, and more. The following will review the purpose and recommended settings for each area on this sheet.
When connecting to this resource, the content should come from
This part of the sheet directs incoming requests to the physical location. This can be used to send a user's request to a different drive, a different computer on the network, or even to another URL. While space limitations may require this setting to be adjusted, all resources are typically located on the same computer running the server software.
Local Path
This is the physical path to the resources being served to connecting clients. Previously, we discussed that resources should be stored at a location other than the root drive of the host computer. If this is not the case, you can select a location using the Browse button.
In addition to the path, this area of the sheet is used to control the general permissions given to the Web site. The only options that should be checked are that of Read and Log Visits. Providing any more permission at this level can inadvertently cause a misconfigured folder that could be used by a hacker to gain unauthorized access to the computer. Control the other access levels at the folder or file level, not the Web site level.
Application settings.
These settings are used to configure the permissions needed for scripts, executables, and dll files. There are several very important considerations to be made regarding these settings.
Execute Permissions: This setting tells the server how to interpret scripts and executables located on the site or individual folder.
None—If there are no scripts located in the Web site, this is the preferred selection. With this set, any executable or script file will be simply read as it is written.
Scripts only—This is used if the Web site requires scripting to access databases or process information. This setting should only be set if the Read permissions are disabled. This is to prevent a client from reading the source code in the script file and gleaning user names and/or passwords that may exist.
Scripts and Executables—Allows any executable, dll, or script to be run. This should only be used in the case that the Web server or clients require the support of an executable file. Ensure the folder does not have NTFS Write permissions set or else a hacker could upload a file to the server and execute it remotely.
Application Protection: This option should always be set at medium or high. Using medium will prevent IIS applications from interfering with each other, and using high will cause all applications to run in their own memory space. This will avoid crashing and buffer overflow problems.
TIP
Server-side includes (SSI) and Internet Database Connector applications cannot be run in a separate memory space from the Web server's memory space.
Application Configuration: By clicking this button, you can access the details of the Web applications settings. Adjusting these options properly can help to secure a Web server. Upon opening this sheet, you will be able to adjust application mappings, debugging options, and execution options (Figure 13.31).
Figure 13.31 Default Web Site Properties—Home Directory sheet.
Mappings—This sheet, shown in Figure 13.32, is used to control the actions a Web server takes when a file is executed. When a resource is called upon, its extension is compared to the Mappings list to determine if a .dll or .exe file is used to process the information. The Mappings are important to monitor and control to reduce the risk of a hacker exploiting a new or known vulnerability.
Figure 13.32 Default WWW Site Properties—Home Directory—Application Configuration—Mappings sheet.
Options—This sheet, shown Figure 13.33, has two important settings. The first is the Session timeout length. This option is used to control how long a user has access to Web site resources after the first request. By reducing this time, a user is forced to revalidate herself. Although reducing this time can increase security in case a session is hijacked, it can also annoy users if the session time is set too low.
Figure 13.33 Default WWW Site Properties—Home Directory—Application Configuration—Options sheet.
The second option that should be adjusted is that of Enable parent paths. This option should be disabled to prevent a hacker from traveling up or down a folder and accessing a folder with permissions that could allow a hacker to write or execute a file.
Debugging—This sheet, shown in Figure 13.34, is used to configure settings related to how the Web server reacts to an error. The only setting that should be adjusted on this page is Send detailed ASP error messages to client. If this is not required, it is best to disable this option. ASP error messages can reveal information useful to a hacker, such as full file paths. If there are no ASP applications under development, or being debugged, this option can be disabled.
Figure 13.34 Default WWW Site Properties—Home Directory—Application Configuration—Debugging sheet.
)
Figure 13.31)
Figure 13.32)
Figure 13.33)
Figure 13.34Documents
The Documents properties sheet, shown in Figure 13.35, is important to security for one reason: the Enable Default Document option. This option should be checked to force any client computer to view one of the listed files. If this is not checked, a client could view the directory structure of the Web site or folder they are requesting. This could give a client information about file names, which could be exploited by other attacks.
)
Figure 13.35 Default WWW Site Properties—Documents sheet.
Directory Security
This tab, shown in Figure 13.36, is available at the master site, Web site, directory, virtual directory, and file level. The security properties are relatively the same at each level, and can be adjusted to meet the requirements.
)
Figure 13.36 Directory Security Properties screen.
The property sheet is split up into three main sections. Each section is important to security and will be discussed in detail.
Anonymous access and authentication control. The Authentication Methods the Web site uses to control user access is mainly determined by whether the site is on the Internet or an Intranet. If the Web site is to be used solely by users on a Windows-based Intranet, a domain controller should control their access. Therefore, Anonymous Access should be unchecked. This allows greater access control, as individual accounts can be granted access to Web server resources. However, if the Web server is primarily to be used for sites that will be accessed via the Internet, it is recommended that Anonymous Access remain checked (Figure 13.37).
)
Figure 13.37 Default WWW Site Properties—Directory Security—Authentication Methods sheet.
Although not typically required, you can change the account used to control anonymous access to the server. Using the Browse button, you can select another account through which access is allowed. You can also uncheck the Allow IIS to control password option and enter your own password.
Changing the Anonymous account is often done because the IUSR_computername resets the Log on as batch job and Access this computer from the network rights each time the computer is rebooted or the IIS is restarted.
The final setting that can be adjusted depending on your needs is the Authenticated access setting. More information on authentication methods can be found under the Master WWW Properties section.
IP Address and Domain Name Restrictions (Figures 13.38, 13.39). This option is used to designate who can (or cannot) access the Web site as defined by the client's IP address and/or host name. By selecting Granted Access or Denied Access, the list will either allow or prohibit incoming requests. Granted Access allows access ONLY to those listed, while Denied Access restricts access to those listed. Of the two, Granted Access provides the greatest level of security, but it is so restrictive that it can only be used within a local network or in very specific cases.
)
Figure 13.38 IP Address and Domain Name Restrictions.
)
Figure 13.39 Deny Access On.
There are several options available that can be used to filter the incoming requests. They are:
Single computer: This option uses a list of specific IP addresses.
Group of computers: This option uses a network ID and subnet mask as its filter.
Domain name: This verifies the client's IP address against a list of accepted domain names. This option will degrade the performance, as each connection must be verified by a DNS reverse lookup.
Secure Communications. This option is used to configure the settings used when a Secure Socket Layer connection is made between the client and the host. Using secure certificates, an encrypted connection can be established between a client and host, thus ensuring that sensitive data (e.g., credit card numbers) is not captured by a network sniffer.
IIS supports the use of Server Certificates to ensure that data transferred between it and clients on the Internet remains secure. The following instructions will describe how to set up and enable SSL on your computer.
Under the Directory Security tab, click Server Certificate.
Click Next at the Welcome screen.
Select Create a new certificate option, shown in Figure 13.40.
Figure 13.40 IIS Server Certificate select window.Select Prepare the request now, but send it later, shown in Figure 13.41.
Figure 13.41 IIS Certificate Wizard request method window.
)
Figure 13.40)
Figure 13.41You can select the other option if available. This will automate the sending of the output file to your selection of certificate vendors, as long as it is on the list provided by the IIS Certificate Wizard.
Enter a name for the certificate.
This name should be easy to remember. While a small business may only use one certificate, ISPs have hundreds of certificates they have to manage. It is important for the name to convey its intent (See Figure 13.42).
)
Figure 13.42 IIS Certificate Wizard name settings window.
Select a bit length option for the certificate.
CAUTION
Before selecting an option, ensure the vendor will support the level of encryption required. In addition, the longer the bit length, the longer data transmission will take. Only select the amount of encryption that is required.
If required, check the Server Gated Cryptology (SGC) or Cryptographic Service Provider (CSP) options.
SGC: Commonly used in banking environments, SGC is a Microsoft encryption solution that provides an additional type of security for online data transfer.
CSP: When a certificate is created it is passed to a program stored on the computer called the CSP. The CSP then creates either a private/public key pair used in software authentication, or it instructs any hardware authentication devices (such as a Smart Card) to create the private/public key pair.
Enter the organization name and department to which the SSL certificate will belong, as shown in Figure 13.43.
Figure 13.43 IIS Certificate Wizard organization information window.TIP
The information entered as part of the SSL certificate setup will be verified by a certificate authority (i.e., VeriSign).
Enter the domain name of the Web site to use the certificate.
CAUTION
You must enter the exact name of the Web address to be protected. Otherwise any visitor who wants to use SSL will see that the certificate does not match the Web site for which it was created.
Enter a common name (i.e., domain name), as shown in Figure 13.44.
Figure 13.44 IIS Certificate Wizard domain name window.Enter the country, state, and city of the company headquarters to which the SSL certificate will be provided. See Figure 13.45.
Figure 13.45 IIS Certificate Wizard geographical information window.CAUTION
Ensure that you enter the entire state name. Abbreviations are not allowed.
Enter the location where the certificate request file is to be saved. This should be local and secure. See Figure 13.46.
Figure 13.46 IIS Certificate Wizard file output window.Click Next and Finish to finalize the creation of the certificate.
)
Figure 13.43)
Figure 13.44)
Figure 13.45)
Figure 13.46At this time the certificate request has been generated. Send the file to a certificate authority (i.e., Verisign.com), which will validate the information and provide you with a secure certificate to use for the Web server. To install the certificate, simply click Server Certificate again and select Process the pending request and install the certificate, shown in Figure 13.47. This will complete the SSL install.
)
Figure 13.47 IIS Certificate Wizard Pending Certificate Request window.
Upon completing the installation of the certificate, the Web server will have SSL capability. To use it, simply use the "https" protocol type in place of the standard "http" that is typically used to request a Web page. This will automatically tell the Web server to redirect the connection to another port (typically 443) and use SSL to transfer data back and forth from the client.