Palisade Magazine

 
September 2006

Securing IIS Web Servers

by Siddharth Anbalahan |  Discuss this article »» (2)

In our previous article we showed how to securely deploy one of the most popular web servers, i.e. Apache web server. In this article we cover how we can secure the IIS 6.0 web server.

Microsoft’s initiative towards security, Trustworthy Computing, is based on four pillars as defined by Microsoft:

  1. Secure by design
  2. Secure by default
  3. Secure by deployment
  4. Communication

Secure by design

Security is a consideration in the design of a product; IIS 6.0 comes with a new architecture which greatly enhances the security for future IIS web servers.

Secure by default

Products are configured with very few features enabled by default thus reducing the attack surface, IIS 6.0 is not installed by default in Windows 2003. Even after installation, it serves only static content; it is left to administrator to turn on features as required.

Secure by deployment

Guidelines to setup secure websites and applications are available readily at http://technet.microsoft.com .

Communication

Microsoft commits itself to provide timely information on latest security patches and vulnerabilities to its customers. For information on Trustworthy computing refer to http://www.microsoft.com/mscorp/innovation/twc/.

In order to secure any application running on Windows servers, it is necessary to harden the underlying operating systems. We first look at security best practices in the following areas of Windows security:

  1. Networking environment
  2. Windows services
  3. File system
  4. Auditing and logging

Networking environment

Some of the different networking hardware and software applications to protect the network include routers, firewalls and IDS. Windows 2003 comes with a built in firewall called the Internet Connection Firewall (ICF) and can be configured to disable protocols access to IIS, though using ICF is suitable for only for mid-sized web applications and sites. Some of the best practices can be listed as below:

  • Filter traffic based on protocols and ports. For IIS web servers serving only web pages, enable only HTTP and HTTPS protocol traffic.
  • Disable ICMP requests, thus minimizing “Ping of Death” attacks on web servers.
  • Disable NetBIOS over TCP/IP. NetBIOS ports (Port 139) on Internet facing servers are the most susceptible to worm attacks, attackers can also use enumeration tools to find out users that are currently logged on to the server. Additionally, ensure that port 139 is filtered at the firewall too.

Windows Services

By default Windows provides more services than required by a web server. By disabling unwanted services, the attack surface can be reduced a great deal. Some of the services that are not required by the web server are SMTP, Network Information Service, Telnet, Print spooler etc. To enable or disable a particular service go to Start | Administrative Tools | Services. Do not install third-party tools or applications compilers or software development tools.

File System Security

Format each partition using NT file system format. NTFS format allows ACL’s to be specified at folder and file level which makes it easier for administration as it is possible to group similar file types and resources into a folder and further customize NTFS permissions on folders and files. Some of the other best practices include, deploying an antivirus solution to prevent permanent loss of data and have a virus free file system, restrict Everyone group’s access to important files and folders. In addition to NTFS permissions, IIS configures web permissions which further determine whether HTTP requests from specific users or IP addresses are allowed or rejected.

Auditing and Logging

Logging keeps track of all accesses and request made at the server. Auditing as a process provides valuable information about possible attacks on the server which are useful during incident handling. Logging resources at the server include the

  • Event viewer, which records all service events, and is categorized as system, application, security.
  • IIS Site activity which records client access requests, includes details like IP address, user account, timestamp, server status of reply to the request, amount of bytes in the request, requested resource location.
  • URLScan is an Internet Server API(ISAPI) filter that monitors incoming HTTP requests, if requests do not comply with rules set by URLScan then IIS replies with a “404 File Not Found” error to the client and makes an entry into the URLScan log file. Some of the best practices include, enable auditing for failed login attempts and access to important system files.

Secure IIS log files with NTFS permissions, audit log files on a routine basis.

It is noteworthy that when IIS6.0 is first installed in windows 2003, it is initially in a locked down state. The web server only serves static pages and command line tools are restricted to run only by the administrator. Buffer overflow protection, restricting anonymous users write access to web server content, enabling and disabling only specific file extensions(both pre-defined and custom) are some of the features enabled in IIS6.0. Ahead we look at some basic IIS web server security configurations.

Access Control

Configure web server extensions at the Web Server

A more pro-active means of defending against attackers is by disabling file extensions at the Web server. These are commonly called as web service extensions, and they restrict dynamic applications that can be run on the web server. The pre-defined web service extensions include, ASP, ASP.NET, Front Page Server extensions, Internet Data Connector(IDC), Server Side Include (SSI) etc. Perform following steps to enable or disable built-in web extensions.

  1. In the IIS manager, expand the local computer and click Web Service Extensions.
  2. In the right-hand details pane, click the web service extension that needs to be enabled or disabled.
  3. To enable an extension, click Allow, to disable click Prohibit.

It is recommended to enable on those extensions that have a corresponding application or web service hosted on the web server. Moreover, it is recommended not to enable All Unknown ISAPI extensions or All unknown CGI extensions .

Configure MIME types

Multipurpose Internet Mail Exchange Types (MIME) define browser and mail client behavior for data files sent by the server. To view/ add/ remove MIME type go to IIS manager expand local computer, right-click and select properties. The local computer properties dialog box will be displayed with the MIME types button. Click the button and MIME types dialog box will be visible listing all supported MIME types.

By default IIS6.0 only servers registered MIME types. Option to register wildcard ‘*’ as a MIME type should never be exercised as this would enable IIS6.0 to serve any file type (including .ini, .bat) to the client.

Configure Web Site Permissions

After limiting types of applications that can be run on the server and the type of files that can be served by IIS server, we now look at restricting access to the web site itself. These permissions are different from NTFS permissions, any conflict between the two types of permissions leads to the more restrictive permission being applied. Website permissions can be applied at file and virtual directory level and include the following permissions:

  • Read - Enabled by default users can view directory or file content.
  • Write - Users can modify file or directory content.
  • Script source access - Users can access source code for scripts.
  • Directory browsing - Users can view directory listing.
  • Log visits - Enabled by default records a log entry for each visit of the content.
  • Executable permissions
    • None - Users cannot run program or scripts,
    • Script only - Users can run only scripts( PERL),
    • Scripts and Executables - Users can run scripts and windows binaries.

Some of the best practices related to Website permissions are as follows:

Grant least privileges - Read & Log visits are all the permissions that need to be configured. In case of script engine applications, script only permission needs to be additionally configured.

High privileges must be granted on need basis - Write - this permission can help attackers to upload malicious scripts at the server, Script source access - Access to script source files may reveal application and business login details, database connection details of an application, Script and Executables - Allows attackers to execute windows command shell executables to gain access to the Host operating system.

Group executable files - By putting all executable and script files in one directory it becomes easier to configure access permissions and audit special access permissions.

Group anonymous users and deny write access - Different websites being hosted one the same server, may need different anonymous users. It is recommended to create a user group for all required anonymous users and deny write access to the website virtual directories and files to this user group.

In order to configure website permissions on IIS manager inside local computer’s Web Sites node and right-clicking the appropriate website and selecting properties.

Configure IIS User Accounts

IIS 6.0 can be configured in two major application processing modes: IIS6.0 worker process isolation mode and IIS5.0 isolation mode (for backward compatibility). In the first mode web applications are assigned web application pools and each pool can be configured with a separate process identity. In the second mode web applications can run either inside core IIS process (as LocalSystem account) or in a separate dllhost.exe process and each can be again given a separate process identity. IIS 6.0 provides three pre-configured user accounts that can be used as process identity when used in the worker process isolation mode. These accounts include

  • LocalSystem - a built in account and part of the administrators group, possesses a grave security risk if any worker process runs under this account (some worker processes like enabling digest authentication requires to run under this account)
  • Network Service - a built in account with fewer permissions on the system, it is also the default process identity for any newly created worker process
  • Local Service - a built in account with same privileges as the Network Service account on the local machine but cannot access resources across the network.
  • IIS_WPG group - this is a user group assigned minimum permissions, this can be used as a windows group for separate custom user accounts which are to be used as process identities for worker processes. All accounts that start worker processes must be part of this group.

In order to change the process identity of a web application pool Go to IIS Manager expand Application Pools node, Right-Click the required web application pool and select properties. On the Identity tab, select any one of the pre-configured user accounts or use the Configurable option to specify a custom user account.

Finally if anonymous authentication is configured then IIS impersonates the configured anonymous user account i.e. IUSR_<machinename> by default so that user requesting resource from IIS do not have to provide user credentials. By default ASP.NET do not use this user but use the process identity of the web application pool they are in. Adding the entry <identity impersonate =”true”> in the web.config file makes ASP.NET applications use anonymous user account.

In order to configure the anonymous user account, Go to IIS manager, Right-click on website file or folder or for all websites right-click the Websites node. Click Directory security or File security tab. To disable anonymous access for the resource, disable the Enable Anonymous Access option. To change the anonymous user account, enter the Username of the user account and the Password.

If IIS6.0 is running in IIS5.0 isolation mode then two accounts are of importance,

  • IWAM_<machinename> - used when an application is set to out of process mode, it starts worker processes and is part of IIS_WPG group.
  • ASPNET - a built in account to run the ASP.NET worker process in IIS5.0 isolation mode.

Security Enhancements in IIS6.0

  • IIS6.0 comes with a new architecture which includes a kernel mode HTTP protocol stack(HTTP.sys), WWW service Administration and Monitoring Component (w3svc service), Worker Processes (w3core), and Inetinfo.exe, these process greatly increase the scalability and performance of the IIS server and make buffer overflow exploits more difficult. This is because latter three processes are user-mode processes and do not directly communicate with the hardware (only the HTTP.sys does), this allows for segregation between actual website code processing and web server operation.
  • Worker process isolation mode allows different Web applications to be hosted by w3wp.exe processes. This enables further segregation between the application pools, thereby poor code execution in one application pool does not affect the operation of other application pools and prevents from IIS server from crashing. The process identity of the application processes running is changed from high privileged LocalSystem account to a relatively lower privilege Network Service account.
  • Anonymous users IUSR_ no longer have NTFS write permissions on the default web root folder. By default the anonymous user accounts have execute rights on cgi files(.exe, .dll, .cmd) and read rights on scripts(.asp, .vbs), include and static html files. Anonymous access to command line utilites located in system folder is prohibited. In case if a website requires write access to internet users on a particular directory then configure a custom user account as the anonymous user account for a particular website and provide write permissions to the appropriate folders.
  • The ASP Parent Path method is disabled in IIS6.0. This method allows use of “.." in ASP scripts to refer to files relative to current directory. This directory navigation capability possessed security risk especially if web applications where present in system drive.

References

Guidelines on Securing Public Web Servers, by Miles Tracy, Wayne Jansen, and Mark Mclamon, NIST

Security Elements of IIS 6.0, by Anthony Devoto, SANS Reading Room

Securing IIS 6.0, by Chun Hai, Ken Schaefer, Chris Peiris, Syngress Publishers

Discussion is open for this article — there are 2 reader comments. Add yours.