Application vulnerabilities account for the vast majority of web server attacks. OS and web server vendors have worked hard to make their products less exploitable but, in general, application developers tend to be under trained in security. To be fair, most managers are more focused on delivering applications on time than with developing and testing the security defense of the application against some "theoretical" attack.

Application vulnerabilities are often caused by incorrect permission setting, scripting errors, design faults, inadequate input parameter checking, and by coding errors in general.

No software programmer is perfect. All programmers make design or coding errors. It's a factor of being human. Coding errors are often measured in bugs per thousands of lines of code (or bugs per kloc). The average number of bugs per kloc for a programmer is thought to be between 50–150/kloc, according to several studies. One study (www.sei.cmu.edu/news-at-sei/columns/watts_new/2004/3/watts-new-2004-3.htm) of 800 industrial programmers revealed in a 120 bugs/kloc average. The top 1 percent most accurate coders had 11 bugs/kloc.

Microsoft has worked hard to reduce the number of bugs through better programmer training, manual and automated code review, and financial incentives. According to David LeBlanc, Senior Software Development Engineer in the Office Division of Microsoft, the results are paying off. Microsoft believes their core programmers program to a 5 bugs/kloc standard, the best of any large company. Of course, Windows Vista contains over 50,000,000 lines of code. If you assume 5 bugs/kloc average, it means Vista could be estimated to have 250,000 programming bugs. Still, most of them are not security issues. They are more likely to be reliability and user-friendliness issues.

Proof of Microsoft's software quality engineering processes is that IIS 6 has had only three known bugs (as of April 2007) since its release in March 2003, and neither was used a lot in the wild. Microsoft SQL, often paired with IIS, hasn't had a major exploit since the SQL Slammer worm in April 2003, and even that bug had been patched for over six months before the worm got out.

All web server software runs on top of a host operating system. Accordingly, any successful attack against the underlying host OS is a successful attack against the web server. With the notable exception of OpenBSD (www.openbsd.org) every host OS has multiple vulnerabilities, including Windows. A web developer must take great care in hardening the underlying OS to minimize overall vulnerabilities.

Back-end databases, such as MS-SQL, MySQL, PostGres, and Oracle, are frequently the targets of intruder attacks because they often directly interface with front-end web servers. Although MS-SQL hasn't had a major system vulnerability in over three years, many other database suites, including Oracle and MySQL, have.

More often, application-level vulnerabilities (SQL injection attacks, scripting subsystem holes, and so on) allow the attacker to compromise the back-end database server and then use the data connection to compromise the web server.

Web servers use a number of network, transport, and session protocols. The two most popular protocols used are Hypertext Transfer Protocol (HTTP) and HTTP over SSL (HTTPS). However, it would not be an exaggeration to say that a web server can utilize dozens of other protocols (and file formats) to serve up a standard application. Each protocol and the subsystem that interacts with the client is a potential attack vector.

Even when the protocol doesn't have known public vulnerabilities, web developers can implement them insecurely. It is not uncommon for Web sites claiming to have HTTPS encryption and authentication to send all resulting data streams in clear-text and unauthenticated.

Like any input-accepting application, web server software can be buffer overflowed. The most famous IIS buffer overflow was the Code Red worm of July 2001 (www.cert.org/advisories/CA-2001-19.html). Affecting IIS versions 4 and 5, its worldwide spread led to a major loss of consumer confidence in IIS. Microsoft responded by making the next release of IIS one of its most secure products in history. In over four years, only three holes have been found, none of which were used widespread.

The last one of those vulnerabilities (as of the book's publication date) was a buffer overflow exploit in July 2006 (www.microsoft.com/technet/security/Bulletin/MS06-034.mspx). IIS purists don't consider this an IIS buffer overflow because the exploit is located in the potentially separate ASP.NET subsystem. However, both products are made by Microsoft and are meant to be run together, although ASP.NET is not installed by default in IIS 6 unless intentionally enabled. Either way, it was not popularly exploited. Apache 2.0 web server, a popular open source web server, has had 4 buffer overflow vulnerabilities (out of 33 total known vulnerabilities) in roughly the same time period. Buffer overflows are a potential problem for all web servers.

Directory traversal is an attack method in which the intruder uses malformed (or unexpected) input to "jump" out of the drive folder containing the web server program or application into more privileged areas. For instance, the default location for IIS application files is %Systemroot%inetpubwwwroot. A directory traversal attack would attempt to break out of the wwwroot folder into the root directory, Windows, or WindowsSystem32, where unauthorized access can be more successful and fruitful. Directory traversal attacks normally contain strings of characters (for example, http://../../../../../../../../) that attempt to confuse the web server into offering up an unauthorized default directory outside the normal web server boundary (see Figure 9-1). The attack allows the intruder to traverse various directories, go up to the root, and then back down into the drive's directory structure to execute contained commands.

Figure 9-1. Representative example of a directory traversal attack

Although IIS has not experienced a successful directory traversal attack in many years, such attacks used to be a frequent method of exploitation in the days of Windows NT and IIS 4.

Unless the Web site uses HTTPS, the traffic to and from the web server is often sent in plain text. If the attacker can intercept the network streams, information can be sniffed and analyzed. Figure 9-2 shows a login name and password sniff from an HTTP session. Many users do not realize how frequently their confidential information is transmitted in clear text across the Internet.

Figure 9-2. Example of clear text password caught in HTTP traffic

Denial of service (DoS) attacks have been a big threat to web servers. Attackers, using armies of compromised machines, can send millions of rogue packets per second to a web server, denying legitimate access and business. DoS attacks are among the most popular attacks against popular, commercial web servers, and are rather difficult to prevent. Indeed, in some sense, they are impossible to prevent, as every communication begins with a request that causes a response. If an attacker can cause more malicious requests to come in than the host machine can adequately respond to, a DoS attack occurs. With the rise of botnets, networks of computers exploited and controlled by hackers, Distributed denial of service (DDoS) attacks make it possible for attackers to bring down even sites with large bandwidth pipes.

Many Web sites, especially gambling and pornography sites, which make tens of thousands to millions of dollars a day from online customers, have been extorted by cyber criminals to pay up to $100,000 to avoid getting a targeted DoS attack. These Web sites find it cheaper to pay the ransom than to lose the business that would result from the DoS. While many security companies are developing better anti-DoS capabilities to protect popular Web sites, the default anonymous nature of the Internet makes stopping DoS attacks difficult. Microsoft has responded by intentionally hardening the Windows TCP/IP network stack against specific types of DoS attacks, improving IIS's performance under heavy loads, and in setting performance thresholds.

Many web servers are compromised because the administrators configure them with weak passwords. Most web servers contain either HTML-enabled logon screens or remote admin consoles. Attackers can often guess against these logon prompts using automated password guessing tools (such as Hydra) or by using manual methods. Even moderately complex passwords (for example, eight characters with multiple character sets) can be guessed by an attacker given enough time. Unfortunately, many web administrators don't even attempt to use long or complex passwords, so guessing the correct admin password doesn't take a significant amount of effort.

A great discussion of web server vulnerabilities is maintained at Open Web Application Security Project (OWASP) at www.owasp.org. Their top ten web server security errors list (www.owasp.org/index.php/OWASP_Top_Ten_Project) is a great list to review. While the list is terrific, it's depressing to see that the list hasn't changed much over the years, and it appears we are no closer to better securing web servers than we were in January 2003 (when the OWASP top ten list was first released). The next two sections will introduce IIS in general and then discuss the new features of IIS 7.

When IIS 7 is installed and active, the Http.sys kernel mode driver installs as the default HTTP protocol stack listener and intercepts and caches incoming HTTP requests. It also provides caching, logging, quality of service, and bandwidth throttling for the web server. Every active Web site registers itself with the HTTP protocol stack. The Http.sys driver includes built-in support for HTTPS, SSL, and TLS, instead of requiring a separate service (i.e., HTTP SSL), as was the case in IIS 6.

Net.Tcp is a protocol listener supporting a new feature called Net.TCPPort Sharing, a part of the Windows Communication Foundation (WCF). Like Http.sys, it allows multiple applications to share a single TCP network port. Http.sys relies on the HTTP protocol, whereas Net.Tcp can be used with any protocol over any TCP port, and with any application. Not enabled by default, the Net.Tcp Port Sharing service accepts inbound connections using the net.tcp protocol and forwards them to their destination application. URLs utilizing Net.Tcp will look something like net.tcp://x.x.x.x/default.aspx, and will always use the TCP protocol. The Net.Tcp Port Sharing Service service must be started for this protocol listener to work. The Net.Tcp Listener Adapter service must be enabled for the Net.Tcp listener to be able to forward to WAS.

The Net.Pipe protocol listener relies upon the Named Pipes protocol, which has long been a part of Microsoft Windows. The best short explanation of Named Pipes is that it is a file sharing and communication protocol for applications, much like NetBIOS/SMB is for users. Behind the scenes of many Windows applications, Net Pipes is used to communicate between different processes. Now Named Pipes can be used to interact with IIS and WAS, although it is reserved for local inter-process communications. The URL moniker for the Net.Pipe protocol listener is net.pipe://. The Net.Pipe Listener Adapter service must be active in order to use Net.Pipe services.

Peer-to-Peer (P2P) services were originally added to Windows XP Pro SP1 and later Windows operating systems. Windows Vista offers up new native P2P services and networking transports. The Net.P2P protocol listener can be used by clients by utilizing the URL moniker for the Net.P2P protocol listener of net.p2p://(for more information, see http://msdn2.microsoft.com/en-gb/library/system.servicemodel.netpeertcpbinding.scheme.aspx).

The Net.MSMQ protocol listener is useful for advanced applications requiring message queuing. Microsoft Windows includes a robust message queue handling service, which helps triage large amounts of incoming data and to ensure the completeness of complex transactions. Developers can create their own custom message queuing protocol listeners as well. Custom MSMQ protocol listeners normally have the name of msmq.<customname>. The URL moniker for the Net.Msmq protocol listener is net.msmq://. The Net.Msmq Listener Adapter service must be started in order for the Net.MSMQ protocol listener or any msmq customer listeners to be able to pass traffic to WAS.

IIS protocol listeners forward client requests to the associated Web site's worker process. In IIS 7.0, Windows Activation Service (WAS) manages application pool configuration and worker processes instead of WWW Service. The worker process is user mode–based code that does the actual handling, delivery, and response to the incoming request for a particular Web site. For example, a worker process may retrieve HTTP content and send it to the requesting client, call an ISAPI filter to handle a particular type of request, or run a scripting engine.

Each Web site runs in an application pool, which is a named worker process and logical memory allocation where one or more Web sites or applications reside. Application pools can be shared by Web sites and applications or used to isolate sites and applications from each other (more on this in the "Defending IIS" section later in this chapter).

When IIS 7 is installed, two application pools, called the DefaultAppPool and Classic .NET AppPool, are created (see Figure 9-5). IIS 6 did not have the latter application pool, but Classic .NET AppPool behaves in the same way as IIS 6's DefaultAppPool. Application pools can be configured to run with or without (i.e., no managed code) .NET Framework (see Figure 9-6). The Managed pipeline mode refers to whether the developer wants ASP.NET and non-ASP.NET requests to be processed together (i.e., Integrated), which is a new IIS 7 feature, or separately (i.e., Classic) using Aspnet_isapi.dll for the ASP.NET requests.

Figure 9-5. Default IIS application pools

Figure 9-6. Choosing between managed and unmanaged environments

Additional application pools can easily be created, and each Web site and directory can belong to one or more application pools. Additional application pools can be created in IIS Manager by clicking the Add Application Pools option under Application Pools leaf object. Additional application pools can also be created using the command line as well. Here is the command and syntax:

appcmd add apppool /name:string /managedRuntimeVersion:.string
/managedPipelineMode: Integrated | Classic

Placing different Web sites in different application pools isolates what corruption or damage can be done by one site to another. A web server administrator can run high-risk applications in their own application pool, separate from the main Web site. If a malicious action happens to a Web site in one application pool, the vulnerability does not immediately compromise Web sites in other application pools.

In IIS 7's default mode (called worker process isolation) there is a separate worker process for each application pool. Each runs in the W3wp.exe process, which runs in the Network Service security context by default. In previous IIS versions (or a Web site running in IIS 5 isolation mode), Dllhost.exe is the default single instance worker process for all Web sites. Applications and Web sites running in Low Application Protection mode (for example, ASP) use the Inetinfo.exe worker process, which as stated previously, runs in the Local System security context. This means that in previous versions of IIS, a single compromise could allow easy access to all Web sites on the server.

Each worker process and associated application pool runs in the security context of an application pool identity. The identity is a user or service account used to run the worker process and application pool (i.e., the security context that the worker process and application pool run in). The default identity for both default application pools is Network Service.

Introduced in XP Pro, the Network Service account has permissions similar to the Authenticated Users group, but accesses network resources using the web server's computer account. The Network Service account has the following privileges:

You can choose the more secure Local Service account if your application pool does not need to access other network services or computers. The Local Service account, also introduced in XP Pro, has permissions similar to the Authenticated Users group, but accesses any network resources using an anonymous null session because it does not have the "Impersonate a client after authentication" privilege. In XP Pro and above, network resources cannot be accessed using a null session, except to domain controllers. The Local Service account has the following privileges:

If a Web site doesn't need access to other network resources (i.e., besides the normal remote requesting clients), the Web site administrator can change the worker process identity to Local Service.

You can create or use a custom user or service account (i.e., Specific User) for the application pool identity (see Figure 9-7). The pool will then have access only to the resources and permissions of the custom identity account. If you create a custom identity account, add it to the IIS_IUSRS group, which assigns the necessary permissions and privileges to allow the account to function as an IIS application pool identity. You then need to add the other NTFS file and folder permissions to the resources used by the web application.

Figure 9-7. Setting a custom application pool identity

You can also choose the LocalSystem account for the identity if the application pool needs Administrator-level privileges and permissions. This is not recommended unless absolutely needed. If a hacker is successful in compromising a web application running in an application pool with the LocalSystem identity, he or she has far more potential to be damaging than if the application pool ran under Local Service or Network Service.

If the Web site using a custom application pool identity is also involved in delegation to another back-end server (for example, IIS front end authenticating users for an MS-SQL back-end database), a Service Principal Name (SPN) must be created for the custom identity. Specifically, the administrator can use Microsoft's SetSPN.exe utility (http://technet2.microsoft.com/WindowsServer/en/library/b3a029a1-7ff0-4f6f-87d2-f2e70294a5761033.mspx) to create the new SPN. The syntax would be similar to this for a Web site located at www.example.com using a custom user identity called custom in a domain called Contoso:

setspn.exe -A HTTP/www.example.com contosocustom

One of the biggest past criticisms of IIS was that it was difficult to give an IIS developer the permissions and privileges he needed to manage the Web site, without giving him control over the entire server. Or it was difficult to configure IIS so that one user had complete control over her Web site, and did not have control on other Web sites located on the same IIS server.

IIS 7 solves this problem with Feature Delegation and Administrator Lists. Unfortunately, Vista contains only the first feature, which is only half the solution. Using Feature Delegation, web administrators can set what features are modifiable on a web server basis (this should be expanded to be configurable on a per Web site or per application basis in future IIS versions). It is standard in the Windows environment that the delegation set for parent objects is inherited by child objects. Longhorn server will contain the Administrator Lists, which will then allow each allowed or denied feature set to be tied to a particular user or group. For now, Vista users will have to be happy with Feature Delegation by itself.

To use Feature Delegation, the user must be an Administrator for the parent object being delegated (i.e., Administrator for server or web administrator for Web site or application pool). The administrator does the following:

Figure 9-10. IIS Manager with feature delegation option selected

Figure 9-11. Choosing the default delegation state

Each feature can then be set to one of four states:

If a feature or configuration item is set to Read Only, it cannot be modified. If a feature or configuration option is set to Read/Write, it can be modified. Remove Delegation removes any specifically set previous delegation. Reset to Inherited lets the parent object's settings follow down into the child object for that feature.

The Feature Delegation affects only what can or can't be set using the IIS Manager GUI. The users wishing to read or modify the web server, Web site, or application pool must also have the desired NTFS permissions on the ApplicationHost.config file (for the web server) and/or Web.config (for the related Web site).

When a browser connects to IIS without supplying user credentials, which is often the case when a browser connects to a public Web site, IIS allows the user to access the Web site with the permissions assigned to the related IIS anonymous user account. Any account intended to be used as an IIS anonymous account should be in the IIS_IUSRS group.

Membership in the IIS_IUSRS group gives contained accounts Read and Execute permissions to Inetpubwwwroot, the default Web site location. If the referenced Web site is not located there, the anonymous account or the IIS_IUSRS group will need to be given the necessary permissions to the referenced content locations.

A new important change in IIS 7 is that anonymous web content can now be more easily run in the context of the site's application pool identity instead of the anonymous user. This could be accomplished in IIS 6 as well, but required more steps. Figure 9-14 shows the application pool and its identity being used instead of the defined anonymous user account.

ASP.NET Impersonation allows a developer to run their ASP.NET application in the security context of an authenticated Active Directory or local account user, or as another specific user (see Figure 9-15). ASP.NET Impersonation is disabled by default, and if enabled, defaults to the authenticated user option.

Figure 9-14. Enabling Web Application pool identity instead of IIS Anonymous User

Figure 9-15. Configuring the ASP.NET Impersonation setting

Basic Authentication is an older but widely supported HTTP standard that allows the user to log on using a SAM or Active Directory account. The user is prompted to input his or her logon name and password, and the browser encodes the information using Base64 encoding and transmits it to the server. Although Base64 encoding is not plain-text, it is near enough, and extremely easy to decode back to its plain-text original. Basic Authentication should not be used except in cases where backward compatibility is needed. You can enable Basic Authentication for compatibility reasons and use SSL/TLS (or another protective tunnel such as IPsec) to strongly protect the authentication stream.

Digest Authentication allows remote clients to use Active Directory user accounts to authenticate if the web server is a member of an Active Directory domain. The server must use Windows 2000 and IIS 5 or above and the client must be IE 5.0 or above. The user's account must also have the "Store passwords using reversible encryption" option enabled. When enabled, clients can authenticate using their normal user account, and the authentication transaction does not transmit the users in plain-text (unlike Basic Authentication).

Forms authentication is a new IIS 7 logon feature that can be installed on a web page by including a file called Login.aspx or its related code into an existing web page. When a user connects to a referenced document, it presents them with a login name and password prompt screen that will then pass the credentials from IIS to an external authentication database, such as Microsoft SQL or Oracle, or to any installed security provider. You can do this with ASP.NET applications prior to IIS 6. However, in IIS 6, it works for ASP.NET content only. In IIS 7, it will work for all content.

Windows Authentication (formerly called Window Integrated Authentication or Integrated Windows Authentication) allows a client to connect using one of the normal Windows logon authentication methods (LM, NTLM, NTLMv2, or Kerberos). This method requires that the client and IIS server reside in the same domain, and for that reason Windows Authentication does not normally work over the Internet. NTLM and NTLMv2 can get past a firewall but are generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.

Windows Authentication is intended for internal intranet sites, where the user should not be bothered by being asked to re-authenticate when they connect to the intranet server. Any Web site in the user's intranet sites zone using Windows Authentication will not prompt the user for logon credentials unless the logon credentials are valid. The default option of whether to always be prompted or not is set under each security zone's settings in Internet Explorer (covered last chapter). The remaining authentication methods will always prompt the user for logon credentials and pass them to the web server.

SSL/TLS Client Side Mapping is another potential default IIS authentication method. If SSL/TLS is enabled on a Web site, the Web site can also require that the client provide an authenticated SSL certificate, as well. The client's SSL/TLS certificate can be stored in Active Directory (i.e., mapped), so that when the Web site requests it, it can be retrieved from the user's Active Directory user object and handed to the server for validation. This is a very secure form of authentication but requires heavy initial and ongoing administrative use of a PKI infrastructure.

In previous versions of IIS, all of the authentication methods came as one default package. If IIS was installed, then all of these methods could be used. Only the anonymous user was enabled by default on the Default Web Site, but any authentication method could be turned on with a simple mouse click. In IIS 7, each individual authentication method can be enabled or disabled on a per module basis. For example, if the Web site doesn't use Basic Authentication, the administrator can remove the Basic Authentication module, and the code will not even be available in IIS for use or exploitation.

Table 9-3 summarizes the basics of each IIS authentication method.

Table 9-4 discusses the various advantages and disadvantages of the authentication protocols requiring logon credentials.

It's also important to remember that most of the IIS logon authentication methods are more concerned with transmitting authentication credentials between the remote client to the server and are not as concerned with integrity and confidentiality issues. To ensure those latter points, use an adjunction protection tunnel such as SSL/TLS or IPsec.

Internally, IIS divides its own permissions into two subsets, Resource and Execution permissions. IIS has its own handler permissions that apply to each Web site, virtual directory, folder, and file, or to the web server as a whole. Permission applied to parent objects is inherited by the child objects unless more specific settings are applied to the child object. The IIS handler permissions are:

Read permissions allow a client to download a web page, view or download files, navigate folders, serve up default documents, or allow directory browsing. Read is the default permission for all Web sites, pages, files, and folders. If you disable this permission, static content cannot be displayed, although scripts, ISAPI filters, and other executables will still be active and able to render if they have the other appropriate permissions. Script permissions allow scripts (ASP, CGI, and so on) to run. If the user needs to see content returned by the script, you should also enable Read permissions. Execute permissions allow executable content (ISAPI filters, applications, DCOM objects, and so on) to be executed.

To set handler permissions, select the web server object you want to set the permission on in IIS Manager (Web site, folder, file, virtual directory, and so on), and then double-click the Handler Mappings icon under Features view (see Figure 9-16).

Next, select Edit Handler Permissions in the Actions pane. Choose the appropriate permissions for the web server object selected (i.e., Read, Script, Execute) as shown in Figure 9-17.

Figure 9-16. Selecting Handler Mappings in the IIS Manager

Figure 9-17. Choosing the appropriate Handler permission

You can double-click on each Handler Mapping (StaticFile, CGI-Exe, and so on) and choose whether the referenced handler handles files, folders, or both (see Figure 9-18).

Figure 9-18. Choosing handler focus

You can also click the Verb tab and choose which HTTP verbs are valid when used against a particular handler and its related content (see Figure 9-18). This was a feature previously available only if you installed URLScan (www.microsoft.com/technet/security/tools/urlscan.mspx) or the IIS Lock-down Tool (www.microsoft.com/downloads/details.aspx?FamilyID=dde9efc0-bb30-47eb-9a61-fd755d23cdec&DisplayLang=en) for legacy systems on IIS hosts. It is a very important, secure setting.

HTTP verbs, known as HTTP methods in RFC 2616 (http://tools.ietf.org/html/rfc2616), which defines the current HTTP 1.1 specification, determine whether users can request (GET) or write (PUT or POST) information to a Web site. Current HTTP verbs include:

IIS allows you to specify which HTTP verbs are allowed to be used in a connection string (i.e., request) from a client (see Figure 9-19). Officially, per the RFC, GET and HEAD (which allow the client to request the server's identifying information) must be enabled on all Web sites to be RFC-compliant. Other verbs should be disabled unless needed.

Figure 9-19. Configuring HTTP verbs

Three previous IIS permissions that some administrators may expect to be present are no longer available in the handler's permission configuration location. They are Write, Script Source Access, and Directory Browsing. Write is tied to WebDAV (along with Script Source Access), which has not yet been added to IIS 7. WebDAV will eventually be added back in as a separate module. Write permission access is now handled by the underlying NTFS permissions. Write allows the connecting user to upload and modify content. This permission should not be given unless writing and modifying content (via HTTP PUTor POST verbs, or WebDAV) are allowed. In some cases, write permissions may not be required when using a program specifically designed for this purpose, such as FrontPage Server Extensions or a custom application.

Script Source Access allows the client to read the web page's source code. This is normally okay, but you may want to disallow this if revealing the web page's source code or scripts can inadvertently reveal sensitive information (such as passwords).

Directory Browsing is now a separate feature available in the Features view in IIS (see Figure 9-20). The Directory browsing permission has always been a unique one. If selected, browser clients will not download and display HTML content as they normally would. Instead, if the specific document requested is not available, the directory is shown along with a listing of its contained files and folders (much like how an FTP directory might be displayed). Most Web sites normally do not have this permission enabled, and it is disabled by default in IIS 7. However, enabling directory browsing is a convenient way to allow users to view, upload, and download files. To enable Directory Browsing, select the web server object you want to allow Directory Browsing on (typically a Web site, folder, or virtual directory), and double-click on the Directory Browsing feature. Then click the Enable button in the Action pane. You can then modify the file attributes shown in the Directory Browsing window (see Figure 9-21). Directory Browsing is commonly enabled on intranet platforms and applications.

Figure 9-20. The Directory Browsing Feature in IIS Admin

Figure 9-21. Modifying Directory Browsing attributes

Administrators looking for an alternative to secure FTP, which has had trouble becoming a commonly supported standard, should consider using directory browsing instead. Secure FTP clients and servers that talk to one another without issues are hard to find. Instead, enable directory browsing on an HTTPS Web site containing the needed files and folders. Every user's browser will be able to connect and the content and authentication credentials will be authenticated and encrypted by default. Users will be able to right-click and Save As any file and they can drag-n-drop upload files (or save directly to the Web site using their local application if WebDAV is also enabled). Table 9-5 summarizes IIS permissions and their customary use.

NTFS permissions play a huge role in IIS. Ultimately, if the connecting client "breaks out" of IIS, the NTFS permissions assigned to the web pool identity and impersonated user account are the security mechanism of last resort. All of this assumes you install IIS and the Web site content on an NTFS partition. And you should never install IIS on anything but an NTFS partition!

Web server content files are installed to Inetpubwwwroot by default. Default permissions are:

When creating any Web site, the NTFS permissions assigned should be the bare minimum needed by the connecting user, impersonated account, and web application pool identity to reflect the Web site accurately and thoroughly. Although this might seem confusing at first, the effective permission security of any IIS Web site is determined by the union of:

Understanding the effective outcome of these permissions on each folder and file in each IIS Web site is essential to being a knowledgeable IIS administrator. Read only Web sites should be restricted by Read only NTFS permissions. If executable program files are not needed, the execution permissions should not be set to Scripts and Executables. Permissions are at the core of IIS security, but the features and functionality that IIS is running also play a huge part.

Here are the summarized steps that need to be performed to strongly harden an IIS server:

Intranet web servers or sites with reduced exposure risk may not need a web server hardened beyond the Microsoft defaults. IIS is very secure out-of-the-box. However, following these recommended steps will result in a significantly harder-to-attack IIS web server and offer additional defense-in-depth responses if other parts of the web server or defense fail. Now, we'll cover each of those steps in detail.

Before hardening IIS can even begin, an administrator must make sure the network that is installed is safe and secure. The network should be free of rogue software, malicious mobile code, and malicious network sniffers. Any perimeter firewalls or routers should allow only the bare minimum of TCP/IP ports to or from the server. In most cases, that means just allowing TCP port 80 and maybe 443 (for HTTPS) from the Internet to the server. If the web server serves up normal WWW traffic only, the perimeter filters should not allow any other port, except maybe the remote management port, to access the server.

No port traffic should be allowed from the web server to the Internet, by default, unless it is a part of the web server's function. Temporary exceptions may be made for port 80 traffic (for browsing the Web to get patch updates) and port 53 (for DNS queries). However, many Web sites have these ports open from the web server to the Internet all the time, and this is allowing too much access. If a hacker is successful in placing and executing a rogue program, and egress ports are allowed through the filter, the hacker may be able to send a command shell back from the server to his remote location over the open ports.

The web server computer should be in a physically secure location. Unauthorized users should not have physical access to the computer. Consider buying a computer that allows physical access to be controlled by a physical mechanism (for example, lock or Smart card). The computer should have a locking case that prevents easy theft of the hard drive.

Unless otherwise contraindicated IIS should always be installed on a dedicated computer. Any IIS server invites increased hacking attempts and makes any computer it is installed on a higher risk of successful exploitation. And any other application may make IIS vulnerable to a side-channel attack.

Prevent booting from anything but the primary boot drive. This will prevent local attacks that attempt to circumvent regular Windows security mechanisms. It will also prevent boot viruses and other types of malware. Disable any unused USB, serial, and printer ports. Then password-protect the BIOS so that the configuration can be maintained. Use a BIOS password that is long and complex, but one that is not the same as your normal admin passwords.

Don't forget to check for and install updated hardware drivers for your computer's BIOS, motherboard, interface cards, video card, and hard drive controller cards. It is the rare computer that arrives with all the drivers updated. It would be a shame for a web server to get exploited or for its data to become corrupt because the server's hard drive controller card had a bug.

To prevent directory traversal attacks, IIS should be installed on a system with two separate, clean hard drives, each formatted with NTFS; or at least create two separate logical volumes. IIS has not been the victim of a directory traversal attack in many years, but in the event that a hacker develops a successful one, having the IIS server software and content installed on one hard drive and the Windows operating system installed on another will prevent future traversal attacks.

Install the Windows operating system as you normally would. Most web servers should be installed as standalone servers, unless the web server will be participating in domain authentications (for example, Windows Authentication). Unless you are dealing with an extranet server, most public facing web servers don't need Active Directory. If Active Directory is accessible through the web server (either because it is a domain member or domain controller), a successful hacker will be able to gather much more information. IIS should never be installed on a Domain Controller.

You want to install the OS with the minimal settings, with the minimal applications, and the minimal services loaded. If possible, load the OS with a static IP address. Dynamic IP addressing might give the hacker a way to exploit the server. Optimally, the web server would not be connected to the network until after all patches were installed.

As soon as the OS is installed, install a host-based firewall on the operating system. You want to protect the web server from remote exploitation. The built-in Windows Firewall is a good choice. It does a fine job at protecting Windows by preventing all inbound connections not initiated by an outbound connection, or by using rule exceptions.

Keep the firewall enabled with no port exceptions until OS and IIS patching have occurred. When the server is ready for operations, enable the firewall for only the port exceptions needed to run the web server. Often these exceptions would be ports 80, 443 (if HTTPS is needed), and a remote management port.

While any remote admin tool (PC Anywhere, VNC, and so on) can be used, Remote Desktop is an excellent choice for remote administration on Windows computers. However, because web servers are high risk attack targets, risk can be minimized by making the changes described here.

First, make sure the latest RDP client, which has improved security and authentication, is being used. On the web server, change the default RDP port from TCP 3389 to another number that is random and high. By not running RDP on the default port, it makes it harder for remote attackers to detect and abuse RDP The web server's RDP listening port can be changed using a regedit modification to the HKEY_LOCAL_MACHINESystemCurrentControlSetControl Terminal ServerWinStationsRDP-Tcp value. Change the value to decimal (versus hexadecimal) and input the new port. On the client-side, from which the remote admin is connecting, the RDP client connection string must include a port number at the end of the connection string to connect to indicate the non-default port number used (for example: www.example.com:33089). See http://support.microsoft.com/?id=187623 for more details.

There are other RDP changes you should make to the Terminal Services (which RDP uses) settings on the web server. Specifically deny access to IIS anonymous user accounts and the anonymous null session. This can be done by adding the related user accounts (or the IIS_IUSRS group) to the "Deny logon through Terminal Services" privilege in the Group Policy or the Local Computer Policy at Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment.

Enable high-level encryption under Computer ConfigurationAdministrative TemplatesWindows ComponentsTerminal ServicesEncryption and SecuritySet client connection encryption level. In the same area, enable "Delete temporary folders on exit, Use temporary folders per session," disable the Active Desktop, set the permission capability to Full Security, and restrict each user to one session.

Force the RDP users to close the session after disconnecting. These options are available in the Terminal Services Configuration console or in an Active Directory domain, under the remote admin user's Sessions tab in their User Account properties.

Enable "Do not allow an initial program to be launched. Always show desk-top" in the Terminal Services Configuration console. In the console, disable all mappings except the clipboard under Client Settings.

Once these changes are made, RDP can be confidently used for remote administration of IIS web servers.

Install IIS with the default options. IIS needs to be installed so patches can be applied against it. Many patching tools, including Windows Update, WSUS, and other Microsoft patching tools, require that the software they are patching be installed and active before the missing patches can be detected and applied. At the same time, installers need to minimize available attack vectors until after the patches are applied. After hardening the OS and installing patches, any additional IIS functionality needed can be installed.

Install all OS and application patches, being sure to install service packs before other patches. This may be complicated by the fact that the server may not be connected to the network or a filtering device may be blocking access to Windows Update from the server (as previously recommended). Install as many patches as you can without connecting to the network. In most cases this means downloading OS and IIS patches from another already patched computer and then installing them manually on the server. If you must open port 80 to run Windows Update and download the patches from Microsoft, open only ports 80 and 53 outbound (if needed). Windows Firewall should automatically open the needed ports when needed. Run Windows Update or any other trusted patching tool, install the missing patches (or service packs), and then disconnect. Continue running the patching routine until no more patches are missing. It is not unusual for it to take two or three complete patching cycles.

Administrators may want to consider enabling the Automatic Updates service. If so, AU should download the patches, but never automatically install. Consider installing and using Microsoft Baseline Security Analyzer (MBSA) to check for any missing patches. If not connected to the Internet, you can download MBSA and the latest Mssecure.xml file from another patched machine and manually install and test. Delete any temporary folders used by the patches and reboot the server as required.

Now is the time to harden the underlying OS. You want to disable or remove any service or feature that is not needed to support the web server, its applications, or its administration. This section will discuss an example scenario demonstrating how to harden a standalone web server needing a bare minimum of services. Web servers with complex requirements (such as down-level client compatibility, domain membership, dynamic content, and so on) will not be able implement all suggestions.

A standalone web server facing the Internet and not needing domain authentication needs only the following services enabled:

Every service should be disabled unless explicitly needed. Uninstall or remove all other non-needed applications and services. Use Local Computer Policy or Group Policy to obtain the following settings:

Reboot the system and troubleshoot any resulting error messages.

Now that the OS is hardened, let's turn our attention to IIS. Following are web server–specific changes to make (as compared to Web site changes).

IIS 7 Modules

IIS 7 has broken down key functionality into dozens of task-specific DLL modules. These modules can be loaded and unloaded globally, per Web site, or per application. Remove unused modules. For example, if none of your Web sites will ever use SSL client certificate mapping, you can unload the Authmap.dll. Table 9-6 shows some of the security modules that can be loaded or unloaded.

Table 9-6. Sampling of IIS 7 Security Modules

MODULE NAME	DESCRIPTION	MODULE DLL
AnonymousAuthModule	Performs Anonymous authentication when no other authentication method succeeds.	InetsrvAuthanon.dll
BasicAuthModule	Performs Basic authentication.	InetsrvAuthbas.dll
CertificateMapping-AuthenticationModule	Performs Certificate Mapping authentication using Active Directory.	InetsrvAuthcert.dll
DigestAuthModule	Performs Digest authentication.	InetsrvAuthmd5.dll
IISCertificateMapping-AuthenticationModule	Performs Certificate Mapping authentication using IIS certificate configuration.	InetsrvAuthmap.dll
RequestFilteringModule	Performs URLScan tasks such as configuring allowed verbs and file extensions, setting limits, and scanning for bad character sequences.	InetsrvModrqflt.dll
UrlAuthorizationModule	Performs URL authorization.	InetsrvUrlauthz.dll
WindowsAuthModule	Performs NTLM integrated authentication.	InetsrvAuthsspi.dll

This information is taken from www.microsoft.com/technet/prodtechnol/windowsserver2003/library/iis7/TechRef/67f99d86-04ab-4140-8718-e873cc1e4b80.mspx.

You can enable and disable various modules by using the IIS Manager and clicking on the Modules icon (see Figure 9-22), and then adding and removing the various modules as desired (see Figure 9-23). Remove all modules not needed to support the Web site and application.

Figure 9-22. Selecting Modules Feature in IIS 7

Figure 9-23. Enabling or disabling specific modules in IIS 7

<configuration>
    <system.webServer>
        <security>
            <requestFiltering>
                <requestLimits>
                    maxAllowedContentLength="10000000"
                    maxUrl="200" maxQueryString="35"
                </requestLimits>
                <denyUrlSequences>
                    <add sequence=".."/>
                </denyUrlSequences>
                <verbs>
                    allowUnlisted="false"
                   <add verb="GET" allowed="true" />
                </verbs>
            </requestFiltering>
        </security>
    </system.webServer>
</configuration>

Now that the overall web server is secured, the following settings should be made to each Web site:

Inetpubwwwroot
InetpubwwwrootExamplecom
InetpubwwwrootExamplecomMain
InetpubwwwrootExamplecomCompany Structure
InetpubwwwrootExamplecomMission
InetpubwwwrootExamplecomRecruiting

TempWeb
TempWebExamplecom
TempWebExamplecomHTML content
TempWebExamplecomHTML contentMain
TempWebExamplecomHTML contentCompany Structure
TempWebExamplecomHTML contentMission
TempWebExamplecomHTML contentRecruiting

TempWebExamplecomScripts
TempWebExamplecomScriptsMain
TempWebExamplecomScriptsCompany Structure
TempWebExamplecomScriptsMission
TempWebExamplecomScriptsRecruiting

TempWebExamplecomExecutables
TempWebExamplecomExecutablesMain
TempWebExamplecomExecutablesCompany Structure
TempWebExamplecomExecutablesMission
TempWebExamplecomExecutablesRecruiting

TempWebExamplecomPictures
TempWebExamplecomPicturesMain
TempWebExamplecomPicturesCompany Structure
TempWebExamplecomPicturesMission
TempWebExamplecomPicturesRecruiting

When setting up and patching any new computer, there are bound to be temporary files and folders left around. For example, you should delete the wutemp folder left over by patching. Look for other temporary files and delete them, too. Then empty the Recycle Bin. Then reboot once more. Check error logs after bootup for any messages to investigate.

Now for the even harder part: Securing an OS and IIS server is easy compared to installing a secure application. Many penetration experts swear they have never met a secure web application. Applications should be modeled and protected using the Security Development Lifecycle (http://msdn2.microsoft.com/en-us/library/ms995349.aspx). There are many books, articles, and classes on this subject. In a nutshell, SDL attempts to anticipate all the threats that are possible against a particular application, and builds in the security defenses as a part of the development lifecycle. SDL makes secure design a key part of the project and makes sure it is not "bolted on" at the end of the project. Every application undergoing SDL review at Microsoft has resulted in significantly fewer vulnerabilities, and the vulnerabilities that were found were less critical in nature.

Coders and the web server administrator should work together to ensure that a secure application gets installed on IIS, and that the bare minimum permissions have been defined and configured as discussed previously.

Open up the appropriate web server ports on the host-based firewall to allow for internal penetration testing. Penetration tests, regardless of whether they use their own wits or automated tools, should test the OS, IIS, and the application. Two good, free web server penetration testing tools are Nessus (www.nessus.org) and Nikto (www.cirt.net/code/nikto.shtml). Nessus comes in both Linux and Windows versions, and in both free and commercial forms. Nikto is an open source tool that requires Linux or Cygwin (www.cygwin.com/) to run in Windows environments. Nessus actually uses Nikto for its web penetration testing. Both products run hundreds of vulnerability tests on web servers. Any noted deficiencies should be corrected before go-live. Lessons learned should be incorporated into future roll outs.

Open the appropriate web server ports on the perimeter firewall and expose the Web site to the world. You've done your job well and there is little to worry about. Every Web site can be hacked, but yours should be one that is not easily cracked. You can also open the Web site to external penetration testing if another round of testing is required.

Last, monitor the firewall and log files located in the centralized log directory. Investigate critical or persistent threats.