Installing and Securing IIS Servers

Easy to use, easy to hack. Indeed, the ease of installation can further tempt users to overlook careful planning, adequate fundamental security measures or patching holes when they emerge. Such a default installation is massively vulnerable and it is no wonder that attackers are finding IIS to be "the easiest pickings" of all Web servers. Something must be going on if one considers the outburst of CodeRed infection. If so, what can be done to prevent the problem? The most important aspect of any security countermeasure is, knowing what to look for and where to look for it.

The Internet Information Services is a suite of tools and services for creating, managing, and securing Web sites that is included with Windows NT operating systems (also Windows 2000, XP and .NET). The IIS services are tightly integrated with the operating system and therefore all IIS versions are Windows-dependent, namely:

• IIS 5 - is associated with Windows 2000 (all versions)
• IIS 5.1 - is associated with Windows XP Professional
• IIS 6 - is associated with Windows .NET Server
• IIS versions 3 and 4 are designed for Windows NT 4.0, (technical support for this is expected to be terminated by the end of 2002)[1].

The IIS Versions designed for workstations (that is IIS5 in Windows 2000 Professional and IIS5.1 in Windows XP Professional) have limited functionality as compared with their server versions (IIS5 on Windows 2000 Server and IIS6 on Windows .NET Server). This limited functionality relates, for example, to a maximum of 10 concurrently handled HTTP requests, the possibility of running a single Web site only, lack of host IP-based access control list, no Connection Limit extension. Therefore, IIS workstations are not suitable for serving up fully functional web sites - this limitation continually triggers the irritating "403 Too many users" message, despite the fact that the logs show that there are fewer than 10.

(Fig.1 Whether our site is reaching its maximum popularity or our server is experiencing difficulties to handle requests?)

Since Windows .NET Server (together with IIS6) is at the moment undergoing finishing touches and unavailable for purchase as yet, we will focus below on Windows 2000 Server IIS Version 5. This is because this version is currently the most suitable to be a powerful server for a new generation of Web applications. Moreover, given the availability of downloadable patches being of vital importance for web server security, we will deal further with the English Version of Windows 2000 Server.

Getting installed with IIS

All IIS services are installed in the same manner as any other Windows component - through the Control Panel: select "Add/Remove Programs", then click on "Add/Remove Windows Components". The screen will appear that allows you to install new Windows components - this requires caution, because an operating system connected to the Internet is particularly vulnerable to attacks. Therefore DO NOT install IIS together with services that are of key importance for LAN functionality or security. Locate the Internet Information Services (IIS) entry and then click on the Details button to select the necessary IIS pieces of functionality. They are:

• Common Files - that is, the main files and services included with IIS,
• Documentation - files of the Default Web Site, files containing IIS error messages and the basic HTML documentation (C:\WINNT\Help\iisHelp directory),
• Internet Information Services Snap-In - an application for managing IIS from the Microsoft Management Console (MMC),
• World Wide Web Server - which provides Hyper Text Transfer Protocol (HTTP) services compiled in a user-friendly manner.

Other IIS components that may deserve further attention are as follows:

• File Transfer Protocol (FTP) Server - included in the system provides support for an FTP account. Remember however, that the FTP service lets you force anonymous logons because it does not use encryption for authentication. You should also be very restrained when considering other options that require logons (web site update, sharing files).
• NNTP Service - to host newsgroups. It can be utilized, for example, for client-to-server and employee communications, but it is not recommended to use the USENET features (that is the commonly available newsgroup hierarchy) because of their limitations.
• SMTP Service - the email server. Being an SMPT server, it provides only mail delivery functionality. It is not intended to aid in receipt of emails, but with its Collaboration Data Objects (CDO) component it is able to forward messages from WWW sites. Remember, however, to ensure that your spam-borne mailing service will be appropriately secured to avoid this nuisance i.e. preventing your server from being used to relay spam! [2]

There are also components that when installed, may be risky from the security point of view and are therefore not recommended, please consider:

• FrontPage 2000 Server Extensions - this is a special communication protocol that supports authoring and administering Microsoft FrontPage webs,
• Internet Service Manager (HTML) - is designed to configure and monitor IIS using WWW pages,
• Visual InterDev RAD Remote Deployment Support -this is a sub-component that assists in the development of web applications via Visual InterDev.

While installing IIS remember, that any subsequently added service will imply the need for proper configuration and maintenance of its security environment otherwise problems may occur and worse, persist. On poorly secured and/or configured servers everything may happen quickly: unauthorized third party relaying, illegal contents, mail viruses and hacking attempts, potentially involving "ritual" problems, with possible legal risks for you, as the owner of the server. Depending on the scale of your web site, installation of the previously mentioned IIS components, SMPT and anonymous FTP may be enough.

(Fig. 2 Installing IIS)

The general approach involves closing down the connections to the Internet while installing web services - once installed, IIS can potentially expose your server to unfriendly forces. Of course, a complete firewall solution or a NAT device may be enough to deny incoming traffic as appropriate. In fact, further sections of this article will be devoted to some security countermeasures allowing a safe installation of IIS components while still allowing Internet connectivity and access to your WWW pages.

Security considerations

The first step in securing your server is to download the most updated Service Pack (currently Service Pack 3 [3]) and current IIS patches (MS02-062 is the recent patch concurrent with this article [4]). The system administrator, should also download other patches as required for Windows 2000 [5] (at least consider seriously their implementation) and Internet Information Services 5.0 [6]

(Fig. 3 Windows 2000 Patches & Updates).

In addition, don't forget to register so that you will automatically receive Microsoft security bulletins [7]. This is of fundamental importance because procurement and installation of any update patches is a must from time to time in order to keep the server operating securely (hackers and viruses like to find out where "lousy software" is!). Don't forget to confirm your subscription by replying to the email with the instructions included.

In the next step, setting up the computer is important enough to not be ignored [8]. The simplest way is to get HiSecWeb.exe file from the Microsoft Web site [9], unpack it to the C:\WINNT\Security\Templates and follow the instructions given in [10]. Open it in mmc.exe (using the "Security Configuration and Analysis" application to be downloaded from the Console > Add/Remove Snap-In menu) and run (being prompted to import hisecweb.inf, select "Analyze Computer Now" from Action menu, and then "Configure Computer Now." Remember that HiSecWeb is designed for dedicated Web servers and it disables all services that are not associated with web access services. The HiSecWeb package does not alter the permissions within the file structure on the system partition [11], while the WWW files are to be installed on a non-system partition, the hardening of which will be discussed later. 

Post installation

Once all necessary patches and updates have been applied and the system settings chosen, you must disable access to the default Web site that has been installed concurrently with the IIS documentation. To do this, run "Internet Services Manager" (within administrative tools, that is Programs > Administrative Tools). This program is an MMC application that was been previously installed under the name "Internet Information Services Snap-In". Once started, choose a name for the server, right mouse click on "Default Web Site", and then select "Properties" from the popup menu.

In order to disable the default web site, assign it to the localhost address (that is 127.0.0.1) - in the "IP Address" box (the "Web Site" tab) delete "(All Unassigned)" and insert 127.0.0.1, and then click "OK"

(Fig. 4 assigning the default web site to the localhost address).

This will cause the default web site to only be accessed from the web browser running on the server, not from the network. It is better to leave the default web site disabled rather than remove it, as it may come in handy later. Right mouse-click on the Default Web Site and select "Stop" in popup menu (instead using the right mouse button, you may use "Action" menu). Naturally, if you plan not to use the default web site anymore, for example to check location of IIS installed files or to read IIS documentation, you can remove it (from popup menu). So far, no other changes to the IIS configuration are necessary, but you can review all tab settings. As you can simply check, directories (and even individual files) can have their own settings within the IIS configuration.

In the next step related to the IIS hardening, you should set master properties for the WWW services. Contrary to the default web site configuration, the IIS configuration is a hierarchical one, that is, any changes to the IIS configuration associated with the WWW Service Master Properties (W3SVC for short) can be inherited through the hierarchy of the embedded system components (sites, applications, directories and files). When you configure properties at the level of the IIS server, certain security-related settings will become the default settings for all web sites (the existing ones and those which are to be created). Before attempting to change settings, ensure that you make a backup copy of the metabase (i.e. the IIS configuration). To do this, in the "Internet Services Manager" application, right mouse- click the server (not the web site!) and click on "Backup/Restore Configuration". The backup IIS copy management window will appear. Click on "Create backup " , and insert the backup copy name (for example "Manufacturer's Configuration") and click OK. The backup copy has been stored to the file in the C:\WINNT\system32\inetsrv\MetaBack directory.

(Fig. 5 the first IIS configuration backup copy).

After making the backup copy, close the "Configuration Backup / Restore" and configure the W3SVC services. Right mouse click on the computer name and select "Properties". Under "Master Properties", click "Edit " next to the "WWW Service" tab. The window similar to the web site configuration will appear - it has its "Service" tab. Pay attention, that certain components are disabled (because they are consistent with individual web sites only). On the "Web Site" tab, select the "Enable Logging" check box and then select the format (I recommend that you select "W3C Extended Log File Format"). Pressing the "Properties" button can modify both the file rollover period (preferably leave "Daily") and the location of the log directory. Because a typical server can have logs measuring dozens of MB daily, it is a good idea to choose a directory on a dedicated disk, for example E:\LogFiles (remember to establish an appropriate directory on the selected partition). You may also enable local time logging (I don't recommend this), and select the scope of the logged information. My advice is to select all boxes excluding "Process accounting" on the "Extended Properties" tab. These options are useful at troubleshooting, detecting intrusions, examining traffic etc. The "Process Accounting" boxes allow one to analyze the server load resulting from individual HTTP requests, but I do not recommend that one use them during a normal operation of the server.

(Fig. 6 Details of WWW Server logins).

After enabling the logging feature (in the master properties of the W3SVC), change the Home Directory settings. In the "WWW Service Master Properties" window, select the "Home Directory" tab and then click on "Configuration ". The "Application Configuration" window will appear, it allows you to set up dynamic WWW pages that are files with specific extensions. Whenever they are called from the Web, they will be passed through the W3SVC service for execution by ISAPI applications, that is additional programs (more specifically - DLLs) installed on the WWW server. These programs are, for example, C:\WINNT\System32\inetsrv\asp.dll, ism.dll, httpodbc.dll, ssinc.dll and C:\WINNT\System32\msw3prt.dll, idq.dll and webhits.dll (within the same directory). You must remove all said programs, leaving only those using asp.dll (and also ssinc.dll if it is considered useful) - all others were used in the past for breaking into the IIS servers and infecting them with viruses (for example CodeRed that uses a known buffer overflow vulnerability contained in the idq.dll). Of course, given all these patches and updates installed previously, it is quite impossible to feel unsecure even with the entire set of ISAPI programs enabled. However, an experienced system administrator would know the old German saying, "once lost, confidence does not easily return" - particularly when the ism.dll application had "lost confidence" with its record-breaking negative events. One is advised to only leave enabled for use the asp.dll and possibly ssinc.dll - since they both also had security-related problems, but of considerably less importance and which were far more difficult to be exploited by hackers.

Files with .inc extensions will not be compiled, executed, or served with the default installation of IIS. In order to have ASP pages served, you will need to give all include files a .ASP extension and add these extensions to the Web Service Extensions list. Otherwise whenever any request is made for an .inc suffixed page, its code will be revealed for public viewing instead of executing it (even with errors, it is far better than publicizing dynamic pages code). Of course, the same procedure should be followed for any other extension scripts. Those who save ASP customization in the .txt files deserve to be given special attention from the system administrator.

In order to setup the extension service via ISAPI applications, click on the "Add" button and then fill in the boxes:

• Executable: C:\WINNT\System32\inetsrv\asp.dll
• Extension: .inc
• Limit to: POST, GET, and HEAD

It is a good idea to provide each extension (those default included) with the "Check that file exists" option enabled - this setting implies that if the requested file doesn't exist, the usual error processing occurs ("404 Not Found") instead of producing the ISAPI application error.

(Fig. 7 Adding ISAPI scripting environment).

The ISAPI msw3prt.dll functionality is dependent both on the IIS and "Web-based printing" setup in the group policy (defined on a local computer and the relevant GPO). It also depends on Print Spooler functionality - which was disabled while launching hisecweb.inf. When you intend to upgrade a Service Pack (sooner or later), the installer activates the Print Spooler service if it's not already running. However, if you have disabled the start-up type for this service, the service will fail to start. This is a strange but consistent requirement associated with the installation of all existing Windows 2000 upgrade packages.

The next important applications to be set up are listed in the tabs of the "Application Configuration" window. On the "App Options" tab, clear the "Enable parent paths" setting to ensure that the FileSystemObject started by an ASP application is limited to that application's defined directory. Another possible service to disable is the "Enable session state" to avoid overloading the server's memory at any ASP request. (Encourage the Webmaster to accept this change). On a cluster of Web servers (where many Web servers share the responsibility for responding to user requests), a Web page will not always function properly. This is because a single user session cannot be created on one server and then read and modified on another. With the advent of IIS 6 and its user session synchronizing support, this limitation will not longer be maintained.

On the "Process Options" tab you can either modify or disable the ASP file cache size - I would discourage you from enabling "Cache all requested ASP files" as the usage of server RAM for ASP session variables could become quite significant.

Lastly, on the "App Debugging" tab, ensure that the debugging options are unchecked and change "Send detailed ASP error messages to client" to "Send text error message to client". This will prevent potential attackers from compromising your website and then provide a simple text for error of WWW services with a possible email address included for reporting problems. With all applications set up as desired, click OK.

If at anytime during these steps you see the "Inheritance Overrides" properties box, this means that certain W3SVC components (web site etc.) have their own settings that are different from the master properties being applied. As you may remember, settings are inheritable, therefore you must decide whether to delete or maintain invariant certain settings as replicated ones. As the default web site is of concern, I suggest not to change anything, whilst for your own web sites use the documentation you are maintaining as guidance. Just click the OK button - do not touch the list! - The master properties will be modified but those previously set will remain unchanged.

(Fig. 8 Changing Master Properties; the Default Web Site settings remain unchanged)

After defining the default application settings, go to change the default WWW site settings. Select the "Directory Security" tab in the "WWW Service Master Properties" window, click on the upper button marked "Edit". The "Authentication Methods" window will appear with their enabled "Anonymous access" and "Integrated Windows authentication" options. It is advisable to uncheck the latter option in respect to commonly accessible WWW pages - it may allow "brute force" attacks from the Internet, targeted at unscrambling server (or related network) user passwords in transit. Unfortunately, this option is to be recurrently disabled, since it is activated by default whenever any new domain is opened. Also remember to uncheck the authentication options after installing SMTP and/or FTP services - this issue will be discussed later. After pressing OK, and then "Apply" you will again see the "Inheritance Overrides" window - do not enable any component belonging to the default web site (for example the .in. file localstart.asp file) and click OK again. The "Edit" button underneath allows defining of appropriate IP and domain restrictions - you might use it for a server that by default is designed for access by a selected group of users only (for example Intranet users or your company partners connected via ISDN). Remember that IP restrictions do not ensure high security level - today's IP protocol does not provide fully secure authentication of the connection source. If you want to have your server accessible from trusted sites only, take advantage of a Virtual Private Network (VPN) solution. On the "Documents" tab you can define default documents. If a domain or directory contains a file with its filename not listed here, the user will see the "403 Forbidden" error message (or the content of the entire directory if the "Directory browsing" has been enabled in the Home Directory option). It is good practice to consult the Webmaster about filenames to be placed on the list - for example, it may be required to add a name index.html.

Generally speaking, your IIS server is now fully set up. However don't forget to look at other tabs to ensure that the "Home Directory" tab has unchecked the "Read", "Write" or "Directory browsing" options, that the "Execute Permissions" (related to dynamic pages) are set to "None", and that "Log visits" is ON. As for the "Home Directory" settings, they will be re-visited after a new WWW site has been established.

Creating Web pages

When creating web pages, it is important to be aware of a problem when starting the work: you should provide a separate partition for WWW pages. Create separate partitions for your NT and Internet data. This suggestion is subtle but important. If you place each logical group of files or each independent directory structure on a separate partition (separate logical disk drives); you reduce the risk of contamination. For example, if you store your Web pages and your Web scripts in the same directory, hackers can break into your Web page area and easily contaminate your scripts.

This can be the same partition you use to store logs - pay attention not to store operating system programs on it (preferably no other programs if possible). Why this requirement? Unfortunately, IIS has a history of problems regarding improper access to programs outside the directory of WWW pages; and still there are many strange entries like "/scripts/../../winnt/system32/cmd.exe+/c+dir+\" found in server logs worldwide. Bugs in ".."path handling that were allowed to pass from the site directory to the operating system directories and run the programs residing under these directories were responsible for this. These bugs could be exploited to launch attacks from the sites hosted on the operating system partition. All other situations where relevant partition-related security recommendations were observed i.e. that used separate partitions for the operating system and WWW pages and with the "Default Web Site" disabled were immune to attacks despite the same IIS holes, because a potential attacker could not redirect his request between various disks. Due to a hard time learning slowly from our own mistakes - this costly experience can be avoided by following the said recommendation, (in addition to disabling the default web site, removing unnecessary ISAPI services and setting restrictive file access policies) that is one of the key IIS related security issues. It is an obvious choice, and is included as one of the options when you set up each IIS directory. Any directory you want to protect must be on a NTFS partition - for example E:\WebFiles and subdirectories of individual domains, for example E:\WebFiles\W3SVC2. Make sure you set out appropriate file access permissions: right click on the disk with your domain content and select the "Security" tab. Be aware, that IIS is particularly sensitive to the presence (or absence) of group "Everyone". Remove this hacker invitation from your server, then click "Add " and enable access for Administrators, SYSTEM and Authenticated Users. Then, still on the "Security" tab associated with Administrators and SYSTEM activate maximum permissions with "Full Control", whilst for Authenticated Users, uncheck all, leaving only "List Folder Contents". Confirm your disk security settings by pressing OK. Then mouse select the WebFiles directory, again open the "Properties" window with right mouse click and on the "Security" tab give the Authenticated Users permissions under "Read & Execute" (and also "Read" by default). It is suggested that such an entire set of file access permissions, simplified but conceptually sufficient, is as follows:

• For Administrators: Full Control,
• For Authenticated Users: List Folder Contents,
• For SYSTEM: Full Control,
• For Authenticated Users: Read & Execute.

Now, with such an "over-hardened" dedicated partition you have a certain margin for loosening restrictions on any other directory, that from time to time may share the disk with WWW sites content. If the log directory is placed on the same partition, you should add the users appropriate read access:

• The log directory - Users: Read

After setting the directory for all sites, you should set a subdirectory for your new site. Let's name it W3SVC2 - because it is a directory designed for the second site (W3SVC services). The same naming convention is used by the IIS service to name subdirectories containing the web site logs - of course, you may not use it if you don't wish to, but this solution can facilitate log interpreting when more web sites exist. The next thing to do is associated with the well-known "Internet Services Manager" program: run it and halt the default web site selecting the "Stop" option in the popup menu - if this has not been carried out before. Upon completion of these preparatory activities, create a new IIS web site. Right mouse click on the server name and from the popup menu, select New, and then select "Web Site" from the respective submenu. The "Web Site Creation Wizard" window will appear. Click "Next >" on the Welcome screen, then place a short description of your site (it may resemble the WWW address)

(Fig. 9 A short description of your site).

On the next screen, specify the IP address of your website (among those configured at the server - alternatively, you can use any of those available). Then the TCP port (it is recommended to use the 80 port only - using non-standard ports does not enhance security but rather makes more difficult to use web services) and, if you wish, the Web address of your site. This last box is to be filled in if you wish to have multiple sites running on a single IP address, differentiated only by their DNS names.

(Fig. 10 [...] Your Web site address).

Once again click "Next >" and locate your "elaborated" Home Directory - in this example E:\WebFiles\W3SVC2

(Fig. 11 [...] location of files).

Leave the "Allow anonymous access to this Web site" enabled and go to the last web site configuration screen to complete settings for the new web site. Here, leave the "Read" and "Run scripts" boxes enabled as they are. The first is designed to allow reading of static web site files- that is HTML, graphics, style spreadsheets, presentations, that is the files that are sent to Web users with no additional server operation required. Dynamic web pages (that is the scripts activated by ISAPI applications already set up under "Application Configuration") use the settings established in "Run scripts" - if using ASP pages is required, make sure that this box remains checked. Answering the question "Do I really need the "Execute" enabled? Is your next step. This option allows running of programs via the IIS server interface (including EXE files and DLLs, also called ISAPI applications) located in the web site - it is very likely to be exploited by enemies, because these powerful programs, if buggy, may be exploited by a hacker. Another threat but even more concerning is associated with the "Write" setting - all publicly available web sites should not be write-accessible and in this example this requirement has been fulfilled by appropriate file access restrictions settings. Enabling the Browse functionality will provide users with access to your web site as to a common FTP server. You can also enable it, if both names and contents of your files can be publicized (for example, if it is required to have an anonymous file server accessed via HTTP). Of course, you can apply such a setting for a chosen site subdirectory not to worsen aesthetic quality of your Home Page.

(Fig. 12 [...])

Finally, go to set up permissions for Internet users. After clicking on the "Next >" button, press "Finish" on the final screen - you will see the web site launched in the IIS server environment. Right click on it and select Properties tab followed by the "Home Directory" tab. The same tab is available at the settings of any web site subdirectory, so you will be able to individually set up access permissions in respect to specific directories depending on their content. The following options are seen while creating the web site:

• "Script source access" allows access to dynamic pages source code via HTTP; it is better not to use this option.
• "Read" allows reading of web site files. If the web site or a subdirectory contain solely dynamic page scripts, you may disable this option;
• "Write" allows writing of files via HTTP. If your server is accessible on the Web, uncheck this option;
• "Directory browsing" enables a user to navigate through your WWW server directory structure (names of all files). It can be activated from a subdirectory performing the role of an anonymous file server. If you decide to enable this option, you will be likely to need to uncheck the "Enable Default Document" option on the "Documents" tab;
• Options "Log visits" and "Index this resource" - the first one should always be enabled, the second one not, unless the file indexing service has been installed on your server;
• "Execute Permissions"- when enabled, it is an equivalent to the "Run scripts" and "Execute" options together, being visible on the final screen while creating web sites. "None" corresponds to non-selecting any of the said options. "Scripts only," means the same as "Run scripts" enabled, whilst "Scripts and Executables" - corresponds to both options enabled. For directories containing static files only, (for example a directory with graphics or a file server) select "None", whilst for typical directories with ASP pages set "Scripts only"; May I suggest that you do not use the third alternative if possible
• "Application Protection" box - you can select a process that will be responsible for running ASP sites - preferably Medium or High to be checked. Do not enable "Low (IIS Process)", because you will be at heavy risk of possible running dynamic WWW under SYSTEM user privileges! Setting to "Medium" will place your ASP in a "pooled application" process. Selecting "High" will allow you to run an ASP "on its own" thereby enhancing security by separating web sites. Additionally;
• "Configuration" button allows one to modify ASP settings. If you have selected a high level of application separation (option "High" as described above), you will have access to an additional tab named "Process Options" in the "Application Configuration". This window has been already described when describing the server global configuration procedures. "Remove" (or "Create") - you can use it to create/delete ASP applications on the web site or its subdirectories. My advice is to not delete the application belonging to the web site!
• "Unload" button allows one to momentarily reduce server burden from ASP pages by removing ASP application from the memory
• The final setup component is associated with the location of web site files (it is provided in the upper portion of the window) - you can change the location of the Home Page directory or activate redirecting to another web site. Do not use the "A share located on another computer" option - this may imply a heavy overhead to the file server service and "unexplainable" lowering of your server performance. [12] [13] [14] [15]

The above settings are documented in the IIS popup help facility (use Shift-F1 while previewing setup windows) and also in the Microsoft Knowledge Base [11] [16]. Moreover, the TechNet Whitepaper available at the Microsoft Web site may be helpful [17] [18].

Having completed the preview of the Home Page settings, go to enhance security parameters on the "Directory Security" tab - click on the upper button marked "Edit", then in the "Authentication Methods" window only leave enabled the "Anonymous access" option. You will need to remove the "Integrated Windows authentication" option that is unfortunately activated by default (you don't want to risk successful brute force attacks, do you?)

(Fig. 13 the final patch).

The same applies for other IIS server services - if you have installed the FTP service, enable the anonymous FTP user. In the "Internet Services Manager" application, click on "Default FTP Site" and select Properties from the popup menu. In the "Default FTP Site Properties" go to the "Security Accounts" tab and check the "Allow only anonymous connections" option. In this manner you will cause the FTP to be prevented from hacking away at usernames and passwords. If you have installed the SMTP service, also ensure that you disable this opportunity - click on "Default SMTP Virtual Server", and select Properties from the popup menu. In the "Default SMTP Virtual Server Properties" select the "Access" tab and click on "Authentication". You will see the user authentication access mode window - delete all options except for the highest one ("Anonymous access"). Of course, you can set up your services so that they will be accessible to trusted users of your network (offering them extra services, for example, accessing confidential files), but this is associated with some additional operations to enhance security of passwords involved. 

What about the web sites?

If you want to see your new site in the web browser, you have to add some files to it, at least a notepad-created default.html. You may manually copy the files from a CD-R, e-mail or a diskette, sent you by the Webmaster. This is an often-used solution allowing for documentation of the changes effected on the Web site. It is however possible that you would have to allow the Webmaster to save the files directly to the web site. Firstly you have to create an account for him. If the WWW server belongs to a Windows NT or an Active Directory domain, you may use a domain account. You should take note of the fact that the Ethernet card receiving HTTP tasks from the Internet must not be connected to the internal network - they have to be separate network interfaces. Then, you modify the authorizations in the file system, attributing the Webmaster the right of writing and modifying the files of the chosen web site (in our case of the E:/WebFiles/W3SVC2 directory). If you have a local area network and a WWW server belonging to the domain, you may define the access as a simple network share on the directory that contains the Web site's files (E:/Webfiles). Otherwise, you may define a new virtual FTP site (choose New -> FTP Site in the IIS server's popup menu). Your FTP 'site' has to be accessible from a trusted network only! To achieve this objective you should use the other Ethernet card installed in the server or the firmware VPN (or an IPsec tunnel) - it is important that the card's IP is not at all accessible from the Internet. While setting up a virtual FTP server you should choose this IP address. E:/WebFiles will be the home directory of the FTP 'site'. You should authorize the Webmaster to write in the directory, too, with the use of the 'Write' option on the last screen of the FTP site creation process. Additionally, the FTP server's setup should block any access coming from IP addresses not belonging to the VPN and/or the local area network. This is an extra means of security, which could save you from some consequences of the mistakes made in the process of connecting the server to the network. A more important way of securing yourself is a trusted network interface, accessible from the local area and/or VPN network, but inaccessible from the Internet. Its trust should not be based on the computer's configuration but on the topology and means of security of the network it is connected to. This is however a topic for another article. And now you can finally connect your new WWW server to the Internet!

Installing and Securing IIS Servers

 

Probably sooner or later someone will ask you, ‘You know, I’d like that directory/website to be only password-accessible. Could you do it?’ You could willingly go to the ‘Directory Security’ tab of the website’s (or directory’s) setup menu, turn the ‘Integrated Windows authentication’ or the ‘Basic authentication’ option on. Click OK, and? Perhaps your server has just become ‘slightly more’ vulnerable to attacks. Most likely causes of the problem are:

• Password eavesdropping or cracking
• Brute-force password guessing attacks
• Unsuccessful attempts to guess the password may block the account

Of course, these dangers are trivial. However, this doesn’t change the fact that these are genuine dangers and that is why they should be analyzed. These hints may be helpful:

• Never use the ‘Basic authentication’ option. It causes the sending of the user’s password through the Internet with no safeguards and may be used later by the nosy guys from the network in which the user’s browser is working at the moment. However, the Internet services managing program warns you that this is not a secure option.

(Fig. 1 – What’s it all about?)

• If you want to use ‘Digest authentication’ method, your server has to belong to an Active Directory domain where the users’ passwords have to be saved in a decipherable form. Moreover, the password will be vulnerable to ‘replay’ attacks, i.e. those attacks in which the eavesdropper repeats the complete URL with the password,
• The authentication should not take place in an account set (i.e. in a domain) intended for other tasks. Separating a domain devoted only to online Internet authentications and placing it with your Web Server in an isolated area of the network is a good idea even though it is expensive.
• Try to limit the access to the sites that allow the IP-authentication of the user. It is not a strong safeguard but it helps to prevent the accounts from being attacked,
• Don’t grant accounts to all willing people. Otherwise you’ll quickly lose control of who can and who can’t use the restricted-access WWW sites. Create a hard copy of who, when and why has an account and its expiry date,
• If your service is to be accessible for accounts that can be created without the administrator’s involvement, you have to use application-level authentication, e.g. with the use of a database including a list of accounts which would be used by the ASP site that authenticates the passwords. Of course, such authentication is processed in plain text, so you could consider encoding it with the use of the secure http (HTTPS) protocol. Your decision should depend on the value of the password-protected data stock - Instead of granting an account and a password, you may allow the user access on the basis of their certificate (the electronic signature). Unfortunately, this solution requires HTTPS protocol (i.e. HTTP encrypted by SSL protocol). This way you can log a user into a Windows account and with the use of the own application authorization as well. The inexistence of the password would surely be comfortable and would enhance the security.

This is how to encrypt the WWW user’s connection with the server. Contrary to the well-known opinion, the HTTPS protocol is not the only way of ensuring that the WWW session remains confidential, nor is it a perfect solution to all the security problems. It is however popular, because it has undeniable merits:

• It makes the eavesdropping of server-client (WWW browser) communication impossible,
• It allows for unequivocal identification of the server to the client so that the client is sure that he/she communicates with the right server,
• In adequate circumstances it allows authenticating the client to the server without using passwords (on the basis of a PKI certificate, i.e. the electronic signature installed in the user’s WWW browser).

Unfortunately, this is where the HTTPS’ advantages end. The problems you would have to face when using this protocol are:

• The necessity of buying a server certificate. The price may be over several hundred euros for a certificate with a one-year expiry date. After having expired it has to be bought anew which requires a similar amount of money to be spent. Of course, there is a possibility of drawing the certificate up by yourself or by a friendly network administrator. However this way would make the user lose his certainty about communicating with the right server. How should he or she know that the certificate is secure if a trusted company has not issued it? Nevertheless, this is a cheap solution, which allows you to keep the remaining advantages of the HTTPS protocol (its confidentiality and the users’ authentication), which why it will be presented in the next article.
• The need to devote a dedicated IP number for the HTTPS-available WWW service. Using the host-headers for servicing a number of HTTPS sites on one IP number is impossible. You may assign port numbers, which differ from the standard 443. A few years ago that requirement was no problem but now there are very many servers and the volume of the IP protocol address space has not grown. Moreover, increasingly often, companies decide to place their WWW servers at their Internet Providers whose IP address pools are not big enough.
• Lack of a possibility to monitor the communication. The system, which should protect from attackers eavesdropping, also prevents intrusion detection systems from tracing hack attempts.
• A heavily loaded WWW server. If the traffic on your website reaches hundreds of thousands HTTP requests, you surely can’t afford an HTTPS service for the whole site. This is caused by the fact that the encryption service (running an SSL session and encoding the data) burdens the CPU very heavily and significantly slows down communication with the client. [1][2]

Of course, one has to bear in mind the fact that in no case does the HTTPS substitute the basic safeguards of a WWW server. Using the HTTPS protocol is not a ‘magical’ way of limiting the hackers’, viruses’ and other unwelcome guests’ access to your website. The connections to the website with the use of the HTTPS protocol may be less popular but that does not exclude the possibility of using them for attacks!

Is in this case is HTTPS worth using? Yes, but you have to be aware of the limitations mentioned earlier and counteract them. An option for HTTPS is VPN – the Virtual Private Network.

These are the differences between these technologies:

1. Primarily, a VPN user has to obtain a password to the network, secondarily he has to connect to it with the use of appropriate software, like Windows2000-built-in IPSec service. This excludes the high availability of services because you must not give away the password to a secured network to anyone who asks for it. Otherwise, sooner or later, the VPN users’ accounts will run beyond your control and the safeguard will become horizontal, which would be even more dangerous than its inexistence. Contrary to the VPN, the HTTPS protocol allows encoding of data independently from user authentication. Admittedly, it is possible to force the authentication of the other side in the IIS setup, but this setting is optional and unnecessary for the HTTPS to work.
2. VPN gives access not to a particular service, but to a chosen address or group of addresses on the protected network. Should you decide to use VPN, you have to consider how wide the users’ access to the VPN-safeguarded network should be. This may be a single server, a small group of them, or – sometimes – a larger part of the network. Moreover, you have to consider the ways of dividing the network – will the VPN definitely allow blocking of access to particular IP numbers? The CISCO devices block them taking advantage of the IPSec protocol options. Unfortunately, some programs that establish the connection using the IPSec protocol do not recognize these options. In this case you could efficiently limit the network’s accessibility by installing additional routers, dividing the network into segments.
3. The high price. Frankly speaking, an ordinary computer equipped with Windows 2000 Server installed, providing RRAS services may become a VPN appliance. In most cases, however, that is not enough. Running the VPN on a firewall allows for securing of the network more precisely but the price of such a device may be higher than the price of the dedicated computer.
4. Lack of possibility to authenticate a VPN client towards a Web Server with a certificate. Obviously, the VPN connection itself may be using the certificate, which won’t be presented to the server because it couldn’t read it without using the HTTPS. You may run an HTTPS connection inside the VPN but in this situation it would be safer and less expensive to do without the VPN at all.

Another possibility is ‘delegating’ the HTTPS encoding to other devices, so-called SSL accelerators. They take on the service of the incoming HTTPS demands and they transfer ordinary HTTP demands to the WWW server. Due to this, monitoring server traffic with the use of intruder-tracing tools, as well as, relieving the servers of CPU-power-expensive encryption operations is possible. Unfortunately, using the SSL accelerators makes it more difficult (or even impossible) for the Web Server to read the users’ certificates. The other serious disadvantage is the price involved. [3]

In many situations, you could give up encryption completely, but do remember the fact that the transmitted information may be eavesdropped. Infer possible consequences  - not all information in the encrypted connection is worth burdening the processors with extra load J. A hint for webmasters: the javascripts, pictures and style sheets, i.e. all the elements downloaded by the browser for displaying the website, will also be encrypted. The greater their number and volume, the more expensive cryptography becomes – taking into consideration CPU usage and transfer time. Obviously, only some elements of the website may be encoded but such a situation will confuse the users’ trust: should they trust the captions? And not the graphics? Or maybe the DHTML scripts shouldn’t be trusted, either?

Let us finish this theoretical dissertation and start installing the HTTPS safeguards on your website. To do this, you should use a test certificate, issued by VeriSign Incorporated. However this certificate will not make your server credible to your users, because you, yourself may issue it for your own system. Unfortunately, you have to issue a fee for authenticating your own server [4][5]. Let us find the website [6] of VeriSign Incorporated which describes the website security products. Click the ‘Try’ button underneath the product located second from the top.

(Fig. 2. Here is where your adventure with HTTPS starts)

Subsequently, you’ll have to answer a short questionnaire and transfer it by clicking the ‘Submit’ button. After having submitted the questionnaire, you’ll see an information site. Before clicking the ‘Continue’ button try to read it with total comprehension. The next step is generating a certificate request – to obtain it, go to the earlier presented MMC ‘Internet Server Manager’ application (while leaving the Internet Explorer window open all the time), click the right mouse button on the name of your company and open the ‘Properties’ window. Having passed to the ‘Directory Security’ tab, click the ‘Server Certificate…’ button in the lowest of sections, ‘Secure communications’. From the ‘IIS Certificate Wizard’ homepage go to the operation choice and search for the ‘Create a New Certificate’ option. The next screen will allow you to choose only one option: ‘Prepare the request now but send it later.’ Then fill in the fields necessary for the certificate – the name should be the same as the DNS’ name of your website, while the length shouldn’t be smaller than 1024 bits.

 (Fig. 3 Generating the CSR)

On the subsequent screen, fill in the “Organization” and “Organizational unit” boxes (the first box should contain your company name, the second one should bear the name of a department or location respectively). On the next screen, type the full DNS name of your website (in my example this will be www.company name.pl, but the reader should naturally enter the fully qualified name of the server as accessible from the Internet or Intranet). Click Next and enter information regarding your organization  - remember to place your country name (PL for Poland etc.), also type the state/province and city or locality. At the last screen, select a location and file name to save your request to – select Desktop of the current user for your convenience. After pressing Next, you will be presented with the identification information that is seen on your server’s certificate – this information will be accessible for any user who has access to the HTTPS connection with your server. If you buy the certificate, make sure that it includes data to be certified as valid by the certificate provider − you can go back to correct data if necessary. After clicking Next you will see the certreq.txt file. Go back to the VeriSign enrolment center and click “Continue”. You will be prompted to submit the Certificate Signing Request (CSR) followed by a large text box to copy and paste the contents of the previously generated certreq.txt file.

(Fig. 4   Submitting a CSR  to VeriSign)

After clicking the “Continue” button, you will be taken to the information of your CSR previously typed in the IIS. You should complete the enrolment form with additional root contact information. After you've read the test certificate agreement, click on the “Accept” button. You will be provided with information on certificate processing. After the certificate has been approved, VeriSign will return the signed certificate to you via electronic mail. Before you check your email box, you must install the Test CA Root Certificate on your WWW Server and on any browser that will use HTTPS communications (this is a disadvantage of test and free downloadable certificates − commercially distributed certificates are usually installed by default in Internet browsers and on an IIS server). Select the “Frequently Asked Questions” link and you will again see the VeriSign’s Certification Practice Statement regarding the use of a Test Certificate − you are informed that “VeriSign makes no representation or warranty to any person that any subscriber to which it has issued a test certificate is in fact” and does not verify the certificate user authentication (the next disadvantage of test certificates). Click the “Accept” button to open the box to save the “getcert.cer” file − locate it, for example, on the active user desktop.

(Fig. 5 Getting the VeriSign Test CA Root Certificate...)

Then you can open it in a normal way and see the signing certificate for your server. Now you should install it on your Web Server - to do this, click on the “Install Certificate...” button and click Next on the first page of the “Certificate Import Wizard”. In the next page, select the “Place all certificates in the following store” option and click on the”Browse...” button. You will be presented with the certificate destination selection box  - you should select the “Show physical stores” option and then select “Trusted Root Certification Authorities > Local Computer".

(Fig. 6 ... followed by its installation)

Then continue – on the last page of the wizard click the “Finish” button to quit the wizard. You will get a message box confirming that the certificate was created. If you close the certificate page now and re-run it, you will see that the certificate is highlighted without the cancellation mark - this means that the import of the certificate was successful and from now on your computer will trust this CA certificate and any other signed by the same Authority. 

(Fig. 7  Your website is now secured by a trusted VeriSign Test CA Root Certificate).

Having the test phase completed you must uninstall the Test Root Certificate to avoid having “trusted” communications with other servers that use the same Test CA Root Certificate.

Now you can check your email − VeriSign is expected to send a message about the new certificate for your server within one hour at the latest. At the end of the certificate you will see a portion delimited with “-----BEGIN CERTIFICATE-----“ and “-----END CERTIFICATE----“.

(Fig. 8  You have obtained the certificate!)

To copy the server certificate, add the begin certificate and end certificate lines into a text editor such as Notepad. Save the server certificate as a text file (with a .cer file extension for your convenience) and go back to the “Directory Security” tab of your website configuration page and click the “Server Certificate” button again. This time, select the “Process the pending request and install the certificate" operation. On the subsequent  wizard’s window, select the certificate file you previously saved on the disk and confirm the certificate information. Lastly, click on the “Finish” button. Now you can check the SSL settings for your website. On the “Directory Security” tab, underneath the “Server Certificate” button, you will see two boxes which have been highlighted: “View Certificate” (presenting the same certificate contents as that available for the server’s users) and “Edit” (to change the HTTPS bridging settings in a current website, directory or file). Before you connect to the Web Server via an encrypted connection, you should attach a port and ID to your website. Select the “Web Site” tab, click on the  “Advanced...” button to open a window that gets you to the procedure of IP number attaching to the website (and also for attaching names such as host−headers). The window holds two lists, the upper one containing the unencrypted website data, and the lower one related to SSL secure connections. Click on the Add button underneath the lower list and in the “Advanced Web Site SSL Identification”, select the IP address and type the port number as well (typically 443). Naturally, it can be the same IP address that has been assigned to a unencrypted website. Lastly, you should confirm the changes you’ve made.

(Fig. 9     Connecting your website using VeriSign SSL)

Now you can connect to the Web Server via HTTPS. Remember, that such a connection must comply with the following requirements:

• Communications between the server and the browser user are secured by the same root certificate (a root certificate, because it authenticates the owners of other certificates) − in the example included; this is VeriSign Test CA Root;
• The server has been provided with the certificate issued by the authority that is the owner of the said root certificate;
• The WWW service runs on a secure SSL port and  is accessible from a user’s WWW browser;
• The user communicates with the server using the same DNS name as that placed in the server’s certificate. Naturally, it is enough if the server name is “dissolved” by the client using an entry in the local Hosts file (for Windows 2000 it is the c:\winnt\system32\drivers\etc\host file) – you can check your certificate without the use of a DNS server.

If everything has been specified properly, on starting the HTTPS connection with your server you should see your Home Page provided with a characteristic small locked padlock indicating a secure connection. 

(Fig. 10   Your HTTPS is now working!)

What is the best way to enable certificate-based user authentication? Use the HTTPS settings. Click on the “Edit” button under “Secure communications” and in the “Directory Security” tab you will see the “Secure Communications” box.

(Fig. 11 The HTTPS settings)

You can select among the following options:

• Require secure channel (SSL) − this setting implies that the website (or a page/directory) will be accessible over an encrypted connection only. Any attempt to activate an HTTP connection will generate a "403 SSL required" message error. You can also establish a 128-bit minimum encryption strength (in terms of a symmetric key), using the “Require 128-bit encryption” option.
• Client certificates - it allows one to read or even enforce authentication of the user using his own SSL certificate. Setting to “ignore” causes the IIS not to read the contents of the client certificates. Setting to “accept” will allow it to read the contents of the certificates in the WWW application (i.e. ASP pages) − using the Request.ClientCertificate Collection [7] and certain fields of the Request.ServerVariables Collection [8]. If you have enabled this latter option based on the SSL authentication, you can also select the “require client certificate” option − the users not certificate-authenticated will receive the “403 Client certificate required” message error.
• Enable client certificate mapping − it allows one to login Windows user accounts using certificates i.e. without the need to send the password to the user. This setting may be of concern, if you intend to secure the server resources using an ACL - for example, restricting access to the website files for selected users. If you intend to use this option you should define the certificate mapping rule − click on the “Edit...” button to open the relevant box.

Two certificate mapping rules are possible:

• 1-to-1: One-to-one is the mapping of a single user certificate to a single user account (it is enough to use the public part only, for example, taken from an electronically signed message). This certificate can be used to map it to the user account for authentication. A user can now use Secure Socket Layer (SSL) to connect to the web page securely from anywhere, provide his or her client certificate to the web server, and be logged on using his or her own user account. Whenever a user changes his account, you will have to re-configure the   mapping..
• Many-to-1 : you can set a rule that maps all certificates issued by that CA. This mapping rule means that many certificates can be mapped to a single user account and no configuration change is required whenever the user changes his certificate – it is sufficient that the essential certificate data remains unchanged. You can verify the data provided in the Subject field (certificate owner’s information) and  Issuer (the certificate issuer’s information).  An exemplary Many-to-1 mapping is illustrated in Figure 12.

(Fig. 12   An exemplary Many-to-1 mapping)

Whilst a very simple ASP page to read a certificate is presented in the default. asp file.

(Fig. 13   A certificate-based authentication).

Remember that with user certificates it may be required to install additional certificates on the server − the ones that have been used to sign the user certificates. If you take advantage of free downloadable certificates such as Thawte Freemail [9], you should also download the “Personal Free mail RSA 2000.8.30” certificate, which is a CA Thawte Freemail certificate used to sign and encrypt email – otherwise you will not be able to identify the signer. This operation is neither necessary nor risky – intermediate certificates automatically inherit the trust
settings of their roots that are installed by default in your operating system.

If you want to restrict user certificates to root CA certificates, utilise the lowest option in the  “Secure Communications” window:

• Enable certificate trust list: here you can select a list of trusted CA certificates. Click on the “New...” button to create a specific list, choosing CA certificates from both local “Trusted Root Certification Authorities” (this is the same list you used to place the Thawte CA Root Test Certificate) and from the file system.

If you use certificate mapping, you will obviously take advantage of Windows accounts – but many applications do not require this. A certificate can be verified and read without mapping of certificates – as is presented in the default.asp listing. In this way, a certificate of the user can be used for example, to authenticate users in the account listing stored in the database – without utilising user passwords! Because a certificate is verified by IIS, it is enough to read the "Flags" field (that should be equal to 1), and "Issuer" and "SerialNumber" (or "Issuer" and "Subject") – that can be then used as a key for a unambiguous indication of a user in your application account list.

Installing and Securing IIS Servers

 

If you missed the first two parts in this series, click here to read "Installing and Securing IIS Servers (Part 1) and here to read "Installing and securing IIS Servers (Part 2).

Most configuration settings for IIS reside in a storage facility or data repository called metabase [1]. The metabase is organized into a hierarchical structure that mirrors the structure of the IIS installation. From the physical point of view it is a single file: -C:\WINNT\system32\inetsrv\MetaBase.bin, however it cannot be edited with the current IIS version (from IIS version 6 onwards, the metabase will be an XML "editable" file for processing with the use of an ordinary text editor). In IIS 5.0, to access the specific metabase content, you can only use the IIS Admin Base Object that is a COM object that enables your application to manipulate IIS configuration. It is not a ProgId object (hence it cannot be used, for example, with the "CreateObject" of a VBScript command), neither allows you to invoke objects via IDispatch - it is therefore inaccessible for script languages. Instead, the IIS Admin Base Object can be used to modify (using programming languages, e.g. in C++ applications) the metabase. The SDK Platform provides a wealth of information on using the IIS Admin Base Object to develop applications for IIS manipulation [2] [3]. In addition, IISAdmin provides an interface named ADSI to administer IIS Admin Objects. And like each ADSI provider, it is available from the level of script languages - This is a simple example of VBScript that employs the IIS Admin Object:

Set IIsObject = GetObject("IIS://localhost/w3svc")

Wscript.Echo IIsObject.Get("LogFileDirectory")

Set IIsObject = Nothing

Similarly, the SDK Platform also provides detailed information about this object [4]. There is a metabase manipulation script that is far more sophisticated than the one above. It runs under Windows 2000 and requires the installation of IIS. The file is called ADSUTIL.VBS and is usually located in the C:\Inetpub\AdminScripts directory. If you want to execute this script quickly via WSCRIPT.EXE and don't want to type any parameter you will be prompted in a suitable window to set the CSCRIPT.EXE as a default script interpreter. The ADSUTIL.VBS syntax is very simple: it takes the operation name as the first parameter, the selected location within the metabase as the second parameter and the value as the third parameter to loop the whole set. For more information about the ADSUTIL.VBS utility, see the Microsoft site [5] [6] and the IIS Server tutorial given under the C:\WINNT\Help\iisHelp\iis\htm\adminsamples directory. The same directory gives details of other administration scripts included in the C:\Inetpub\AdminScripts directory. Similar to the ADSUTIL.VBS but a much more powerful tool for metabase manipulation is the MDUTIL.EXE file utility that is included on the Windows 2000 CD-ROM as a zipped file. In order to install it on your computer, simply insert the Windows 2000 installation CD and execute a simple command:

expand -r d:\i386\mdutil.ex_ c:\winnt

[Figure 1. Installing the MDUTIL.EXE tool]

Although both the MDUTIL and ADSUTIL use a similar syntax, certain metabase elements may be named differently - this is because the MDUTIL uses the IIS Admin Base Object (which, as we remember, is not supported by the scripts, including ADSUTIL) [7].

MetaEdit is a very convenient metabase editing tool. To install it, first download the MTAEDT22.EXE installation file that is available on the Microsoft Knowledge Base site [8]. Once you have installed it, you will be in the license window. Click Yes if you agree with the terms of the license agreement and after a while you will see the application program of the Visual Basic application. There is no important option to select, so you can simply press Enter all the way through. However I suggest that if during the installation you are prompted to overwrite a newer DLL with an older one, click Enter. On completion of the installation you will see a message "MetaEdit 2.2 (x86) Setup was completed successfully". The program you have installed is located in the Administrative Tools menu (the administration tools). Once have you run the program, you will see a familiar Explorer-like window split in two panes. The left pane holds the two top metabase keys:

• LM (Local Machine) - configuration data that is associated with all IIS elements is stored here
• Schema - it contains so called "schema" that is the references that are necessary for the IISAdmin to manage information contained in the LM key. You must not modify this information!
  You can expand metabase keys as you wish and read information they contain but use caution whenever you edit the metabase directly. Configuring properties in the metabase incorrectly can cause problems, including the unrepairable failure of the IIS.

[Figure 2. A portion of default MetaEdit settings]

A hierarchical arrangement of the metabase is clearly seen; in addition, most of the metabase keys contain the property "KeyType" which has a specific importance. The property list seen in the right pane has the following columns:

• Id this is the number identifier of the property; it is a unique attribute of the property
• Name is a name of the property; certain properties may have no name assigned
• Attributes mean property attributes; "Inh" is the most important attribute for article, since it is an advantage which makes the inheritance of key values intuitive (metabase subkeys embedded in keys with properties will inherit these properties)
• UT (User Type) indicates an application of the property, for example, a server, files, WAM (Web Application Manager), ASP applications.
• DT (Data Type) is related to the kind of data (for example, numeric, character, list of characters, binary data etc.)
• Data, i.e. the data itself.

Among properties is one called "Key Type" (ID = 1002) that is the name of the metabase object (class) that defines that key. Similar to the meaning used in object-oriented programming languages, the class means a set of attributes collected in a specific location and describing a single specific object. Each key in the metabase is an instance of an object whilst the inheritance of properties is a consequence of subkey embedding. For more details about the metabase hierarchical structure and classes refer to the SDK Platform [9] [10]. Here, the following classes are of great concern: IIsWebService, IIisWebServer and IIsWebVirtualDir. It is also worth mentioning the IIsWebDirectory and IIsWebFile classes - which include properties of an individual Web directory and a file respectively. Listed below are selected class attributes that are important from the IIS customization and tuning point of view.

DisableSocketPooling

IIS 5.0 version has been enhanced by the addition of a so-called connection pooling, a technique used for sharing TCP sockets among many sites [11] [12]. This enhancement allows IIS to employ all available IP addresses - including those not having any site configured. Therefore, a single Windows 2000 server cannot run other IIS services that use the same port numbers concurrently - even if the IP addresses designed for them are not utilized by IIS. An example is Apache running with IIS on the same server. Since IIS with connection pooling enabled occupies port 80 on all IP addresses, (not only those used for sites based on IP addresses), the Apache server will be forced to use another port number - for the sake of user's convenience. By default, socket pooling is enabled, but you can disable it by setting the DisableSocketPooling appropriately in the IIsWebService and IIisWebServer classes. In order to disable connection pooling for all IIS based sites, in the c:\inetpub\adminscripts\cscript directory execute the command:

adsutil.vbs set w3svc/disablesocketpooling true

and then restart the W3SVC service. After doing this, you can run Apache on the same Windows 2000 server that runs the IIS - making port 80 available to both these services (of course, under different IP addresses).

LogonMethod, Realm

If you are about to restrict access to your Web pages using Windows password and account facilities, then you must consider the risk that you may introduce by sending passwords in cleartext over the Internet. However, if you have configured the HTTPS service, you may eventually apply "Basic Authentication" to it. But there are a couple of catches: -

• User privileges to log on to the Web server. When a user connects to a Web site using Basic authentication, IIS gets the username and password, calls the Windows API LogonUser and impersonates the user. This function provides a mode of authentication - interactive logon is the default (LOGON32_LOGON_INTERACTIVE). Giving users this privilege allows them to log on to the Web server if they have physical access to the server (i.e. also to the ASP sites) or to another remote computer. For example access to SQL, utilizing the user's own account, not an extra one, which may be embedded in the ASP script. However this causes a problem - users must have "Log on locally" privileges on the server, which is not necessarily the most secure option. Another option is to allow the user to access the server under the authentication in the call to LogonUser - via the LogonMethod attribute.
• password pass through. The Web browser prompts a user to enter his credentials and after the site has authenticated the user, the credentials are used for each subsequent page of the website. This is a normal solution to free the user from the need to renew authentication each time he wishes to browse the site. If the user authentication is secured by an encrypted connection, there is no problem. However if the user goes beyond a secure area, or a given site has unsecured elements, (which is definitely not recommended), the browser will continue to send the username and password in clear text over the Internet! This is a serious security risk. A solution is to set the so called "realm" property for various portions of a Web site for security purposes. By default, the realm used in IIS is the name of the domain - but you can set your own realm on any metabase key as desired. The realm will be valid for the key (node) of the respective directory and for all elements (directories and files) of the key.

[Figure 3 "A standard Realm setting..."]

[Figure 4 "... and a modified one"]

Both settings can be modified as required, using the ADSUTIL.VBS. With the LogonMethod, the following options are available (below please find the logon notions specified for LogonUser):

• 0 (default setting) IIS will use interactive authentication, therefore the user must have the "Log on locally" privileges on the Web server, by which IIS can make requests for secured resources on a remote computer on behalf of the user (for example, ASP pages or named components);
• 1 - authentication for application

 (LOGON32_LOGON_BATCH). This logon type is intended for batch servers, where processes may be executed on behalf of a user without their direct intervention. This means without the need to have the "Log on locally" permits, but rather the "Logon on as a batch job" right (used, for example, by COM+ applications). Similarly to the default setting, applications might use cache credentials

• 2 - network authentication (LOGON32_LOGON_NETWORK); this logon is intended for users having the right to log on to servers via the network (Access this computer from the network). This function does not cache credentials for this logon type.
• 3 - network authentication that preserves the credentials (LOGON32_LOGON_NETWORK_CLEARTEXT) - this logon type is not included in the SDK Platform document [13]. The user is only required to have the network authentication privilege (see 2, above), but the server is allowed to accept user's credentials, call LogonUser, verify that the user can access the Web server across the network and still communicate with other servers (similarly to the 0 and 1 situations).

Figure 5 illustrates exemplary settings for logon authentication. For more details on Web site authentication, please refer to the Knowledge Base [14]

[Figure 5 "LogonMethod and Realm" settings]

UNCAuthenticationPassthrough

If you decide to move your Web site content to a different server, click the Home Directory tab, and then select A share located on another computer and define the IIS account to be used for network connections. Or you may alternatively enable the UNCAuthenticationPassthrough parameter in the metabase (for more details, see Microsoft Knowledge Base [15]. With this parameter enabled, the account used in "Connect As" will be overridden by the credential of the actual user logging on. Basic authentication with this parameter enables administrators to control ACLs for specific users, but this process increases overheads on the Web server.