06- IIS on Windows Server 2008

Preparation

We will assume that we have an existing infrastructure in place, including Active Directory and DNS. In the example, the Active Directory domain will be named cs, and the nameserver will be located at 192.168.1.191

Configure the networking for the new server; in this example we set the IP address of the web server to 192.168.1.194 and disable IPv6.

We also configure the name and domain of the server; in the example, the web server will be named iis.cs. We will join the web server to our domain.

All other settings are in their default state. In particular, we have not added any additional roles to our server.

Installation

Run the Add Roles Wizard (which can be found on Initial Configuration Tasks), select Web Server (IIS). It will ask to also install some additional features (Windows Process Activiation Service), we will do so. There are a number of potential roles this system can take on. All of the default features will be accepted (Static Content, Default Document, Directory Browsing, HTTP Errors, HTTP Logging, Request Monitoring, Request Filtering, Static Content Compression, IIS Management Console). We will add the following:

• Logging Tools
• Basic Authentication
• Windows Authentication
• URL Authorization
• IP and Domain Restrictions
• IIS Management Scripts and Tools

Note that we will not be discussing important topics like ASP, ASP.NET, CGI scripts, and ISAPI. Sorry.

If you want to install FTP on the machine, this is where you do that as well. We won’t.

Install. Grab a coffee. Back already? Go back out and grab a burrito.

The basics

The primary tool for managing your IIS web site is the IIS Manager. To find it, navigate Start -> Administrative Tools -> Internet Information Services (IIS) Manager. Expand the tree on the left. First view the node IIS (CS\user) [The text CS\user will be replaced by your particular domain & user combination.] This gives you the data for the IIS installation as a whole.

Expand the Sites node. Now you see a list of all of the sites running on that
server. A Default Web Site already exists.

Expand the Default Web Site node. Notice that many of the icons are the same as the icons for the IIS installation as a whole.

Let us add some content to the default web site. The default directory for the IIS web site is c:\inetpub\wwwroot. You can visit that site directly in file explorer; you can also open that folder directly from the action pane in IIS Manager. From the tree on the left, select IIS -> Sites -> Default Web Site. From the action pane on the right side, click the link “Explore”. The default install has two documents- an image (welcome.png) and a web page (iisstart.htm). View the contents of iisstart.htm, both in a browser and in a text editor. Does the image have any intreresting properties?

Create a web page, called index.html and place it in the c:\inetpub\wwwroot directory. Verify that this document is served.

Though there is a default web site already set up, let’s build a second.
Navigate Sites (rt click) -> Add Web Site. Set the Site name: WebTest, and set the Physical path: C:\WebTest. You will need to create this folder- it does not yet
exist. Set the Host name: webtest.cs, and start the web site immediately

In c:\webtest, create the default file index.html. Ensure that the group IIS_IUSRS has access to the directory (Read & execute; List folder contents; Read). To do this, select the folder (right click) -> Security -> Edit. Be sure that you are selecting from the local users and groups, not from the domain.

When IIS is installed, it creates the user IUSR_<computername> and the group IIS_USRS. Use of the IUSR account is deprecated and it is only kept for backward compatibility. Any user or account belonging to the group IIS_USRS can be used as the anonymous account for IIS to access file data. By default, the IIS_USRS group has no members.

Now we should verify that we have our permission set correctly. Navigate IIS Manager -> IIS -> Sites -> WebTest. From the action pane on the right side, select
Basic Settings; then select “Test Settings”. You should receive no errors and only one warning. The warning will exist because, by default IIS will use pass-through authentication for the web site, meaning that the user that will be used to authenticate to the file system will be selected at run time. The validity of this user cannot be determined statically.

How do we account for the fact that our web server already has a web site? We will give our IIS machine a second IP address, with a second DNS entry. Go to network properties (e.g. Network & Sharing Center -> View Status -> Properties -> Internet Protocol Version 4 -> Properties -> Advanced -> IP Settings -> Add) and add a second IP address to this NIC- say 192.168.1.195. In the DNS server, add the entry webtest.cs @ 192.168.1.195. Run ipconfig from the command line, and note any differences from what you may have expected.

We could simplify somewhat if we kept the single IP address, but set up a second cname in the DNS server.

Go to another machine & visit the page http://webtest.cs. The test page you created should appear.

Go to another machine & visit the page http://192.168.1.195. What page appears? Did you expect that result? Clearly, there is more to learn.

The IIS Manager interface

Default document
If no document is specified in a URL, then the IIS will attempt to return a default document. The precise document is specified by the Default Document. The default settings include 5 documents. What are they?

If your site uses a particular document as its index, then that document should be at the top of the list for performance reasons. When IIS looks for a default document, it looks through this list, in the specified order. It will not go on to the next item in the list until it is satisfied that the current list item does not exist, so if your default document is at the top of the list, then IIS will spend less time searching through the list. The ordering can be sepcified at the server level. If so,
this will propogate out to the individual sites.

Verify this by changing the order of the default document at the server level. Examine the default document order on the two web sites, and verify that the order of the documents has changed.

The ordering can also be specified at the site level. Verify this by changing the order of a site. Note that you will be warned that it will no longer inherit changes made by the parent. Note also that there is an option in the action pane to revert to the inherited default document. See also https://www.iis.net/ConfigReference/system.webServer/defaultDocument

Directory browsing
By default, if a directory is requested (e.g. http://webtest.cs/) and no default page exists (as described above), then IIS will return a 403 error. If directory browsing is enabled, then in this case IIS would return a listing of the files in the given directory.

Directory browsing can be enabled at either the server level or at the level of individual sites. To see how this occurs, rename the index.html file for
the webtest site to something else- say indx.html. Load the page http://webtest.cs both with and without directory browsing enabled.

As an added bonus- What are the contents of the file web.config? Will that page be served? See also http://www.iis.net/ConfigReference/system.webServer/directoryBrowse

Custom error pages
IIS can be set to provide customized error pages. By default, it provides an error page customized to the language of the browser. These error pages can be set at the server level or at the site level.

We saw above that, if directory browsing is not enabled and if no default page is present in a directory, then IIS will return a 403 error. Modify your system so that
it returns a page of your choice when it encounters a 403 error, and verify that this works as expected from a machine other than the server.

In the action pane, notice the link for Edit Feature Settings. It gives three options for error responses

• Custom error pages
• Detailed errors
• Detailed errors for local requests and custom error pages for remote requests.

Earlier you modified your system so that IIS would return a 403 error, as your directory has no default document and directory browsing is turned off. View that same page, but now from a browser on the server. Note the difference that detailed error make. Note also the security implications of running a site where detailed errors are sent back to remote users. For more details, see http://learn.iis.net/page.aspx/267/how-to-use-http-detailed-errors-in-iis-70/

Bindings
Bindings are set on a per-site level, and determine to which requests a particular web site will respond. To see the bindings for a site, click on the site in the IIS manager, and then select bindings from the action pane. View the bindings for the default web site. Select the edit button to note that

• Protocol is http
• IP address is all unassigned
• Port (TCP) is 80
• Host name is unspecified

View the bindings for the new web site we created, webtest. Select the edit button to note that

• Protocl is http
• IP address is all unassigned
• Port is 80
• Host name is webtest.cs

Recall the odd behavior we saw above, where we got the right web site if we specified the right name but the IP address always resolved the default web site. Use bindings and correct this issue. [This may not be as obvious as you think! Be sure to test out each of the following cases

• http://iis.cs
• http://webtest.cs
• http://192.168.1.194
• http://192.168.1.195

You should get the correct web site each time. To guide your decisions, consider the following questions: To which IP should each site respond? Does the name of the site matter?

Limits
You can set limits on the network resources available to a particular site on your IIS server. To do so, select Limits from the action pane.

Limit bandwidth usage (in bytes) refers to the number of bytes per second of bandwidth for that site; the default is 4294967295.

Connection time-out specifies the time that IIS will wait before it disconnects a connection that is considered inactive. The default is 2 minutes.

Limit number of connections refers to the maximum number of allowable simultaneous connections to the site. The default is 4294967295.

Advanced topics

Application pools
The official documentation at IIS.net says “An application pool defines a group of one or more worker processes, configured with common settings that serve requests to one or more applications that are assigned to that application pool. Because application pools allow a set of Web applications to share one or more similarly configured worker processes, they provide a convenient way to isolate a set of Web applications from other Web applications on the server computer. Process boundaries separate each worker process; therefore, application problems in one application pool do not affect Web sites or applications in other application pools.” (http://www.iis.net/ConfigReference/system.applicationHost/applicationPools)

We do not have sufficient time to discuss complex web applications in IIS, so we are going to leave this topic here.

Virtual directories
Virtual directories can be used in IIS in roughly the same fashion as we used aliases in Apache. In IIS, a virtual directory is a URL path that is mapped to a portion of the file system.

Let us illustrate this with an example. Create the directory c:\webtest\dir1 and put an index file in that directory. Verify that the URL http://webtest.cs/dir1 can be used to retrieve that file.

Create the new directory c:\outside and put an index file in that directory. Note that this is now outside the document root for either of our web sites.

From IIS manager, right-click on the web site WebTest, and select Add Virtual Directory. For the alias, select dir2, and for the physical path, select c:\outside.
Verify that the URL http://webtest.cs/dir2 now retrieves the index.html document from C:\outside.

Investigate the question how IIS was able to gain file access to that file. Hint- if no other user is specified, the system uses the local user “Network Service” to
access the file system. What are the effective permissions for that user?

Command Line tools- appcmd.exe

This program is located in %SystemRoot%\system32\inetsrv\Appcmd.exe. This is not part of the system path, so the file must be started directly from this directory, or the path variable must be modified.

This is _the_ command line tool for working with IIS

It must be run from an administator level command prompt. Note that, just because you started a command prompt as an administrator, this does not mean that you have an administrator command prompt. You must right-click on the entry in the Start Menu, and select “Run as administrator”

As a simple example of the use of appcmd, run the command

c:\Windows\system32\inetsrv\appcmd.exe list sites

Can you determine what the tool did?

In general, Appcmd looks for a verb and a noun

Noun	Verbs
site	list set add delete start stop
app	list set add delete
apppool	list set add delete start stop recycle
vdir (virtual directories)	list set add delete
config	list set search lock unlock clear reset migrate
wp (worker processes)	list
request	list
module (web server modules)	list set add delete install uninstall
backup	list add delete restore
trace	list configure inspect

As examples, try
To list all of the sites that IIS is serving:

c:\Windows\System32\inetsrv>appcmd.exe list sites

To stop IIS serving a particular site

c:\Windows\System32\inetsrv>appcmd.exe stop site "WebTest2"

To have IIS start serving a particular site

c:\Windows\System32\inetsrv>appcmd.exe start site "WebTest2"

To have IIS list all of the virtual directories in use

c:\Windows\System32\inetsrv>appcmd.exe list vdir

Suppose that we want to change the default document to home.html. Create the document home.html in the main web site (C:\inetpub\wwwroot\home.html); then run the following

c:\Windows\System32\inetsrv> appcmd.exe set config
"Default Web Site" /section:defaultDocument /enabled:true
/+files.[value='home.html']

Check that the default web page has been changed by viewing your default site in a web browser. Go to the Default Document section for the Default Web Site in the IIS Manager and verify that the configuration there has changed.

Let’s enable directory browsing in the default web site. Rename any default documents in your document root (like home.html above); run the following

c:\Windows\System32\inetsrv> appcmd.exe set config
"Default Web Site" -section:system.webServer/directoryBrowse
/enabled:"True" /showFlags:"Date, Time, Size, Extension"

Verify the change, both by loading the page and by examining IIS manager.

Just about anything that can be done through IIS manager can be done through appcmd.exe

Configuration files.

The configuration files are kept in a few location in .xml format. IIS is tightly integrated with the .NET framework (which we cannot cover in any significant detail.)

The .NET framework global settings for the server is

%SystemRoot%\Microsoft.NET\Framework\<version>\CONFIG\machine.config

Though this is a .NET file, this lets IIS 7.0 share configuration information with ASP.NET

The IIS 7.0 global configuration are in:

%SystemRoot%\System32\Inetsrv\config\applicationHost.config

This file has two important sections: <system.applicationHost> and <system.webServer>. This file is only modifiable by machine administrators. This is the main configuration file for IIS

Each web site has its own file web.config in its root directory. This file may be hidden and you may need to enable “Show hidden files and folders” (File Explorer -> Tools -> Folder Options -> View -> Advanced Settings) to see
it. If you compare the web.config file for the Default Web Site and the web.config for webtest, you will see which (if either) allows directory browsing.

There is a file to allow IIS 7.0 to load its configuration from a remote location. This way multiple servers can share the same configuration. The file is

%SystemRoot%\system32\inetsrv\config\redirection.config

There is a separate file to configre IIS manager; it is

%SystemRoot%\system32\inetsrv\config\administration.config

We will not need to edit these files manually.

Security techniques

Because IIS is tightly integrated with the .NET framework, this means that IIS applications need to be carefully secured- including focusing on design, least privilege, and isolation. This will not be discussed in this course.

One can deny access to the entire web site or just to a directory (including a virtual directory) or to an application by IP address range. Go to IIS manager and select the component (web site / directory / etc.), then select IPv4 Address and Domain Restrictions. Rules to allow or deny connections can then be simply set
from the action pane. Rules will match in the order specified in the configuration.

A rule at one level that contradicts a rule at a lower level appears to cause the server to throw an error (Code 500 rather than 403.6 is sent; checking the rules set will inform you that an error condition exists.)

Note that if the server is accessible via IPv4 and IPv6 then denying an IPv4 host may let them simply connect via IPv6. It is possible to do IPv6 denials, but not using the tool in IIS manager.

Try out the feature- choose one web site, and choose two systems to use to browse your site. Add a rule that disallows one site to view the site, and verify that this
works as expected.

A valuable IIS Security tool is UrlScan. The current version is 3.1, which supports IIS 5.1, 6.0 and 7.0. It is available on the labshare.

To install URLScan, we need to install IIS Metabase. This is an IIS 6 feature that we have not yet installed. Navigate Start -> Administrative Tools -> Server Manager. From the tree, select Server Manager -> Roles -> Web Server. Under Role Services, select “Add Role Services” and choose IIS 6 Metabase Compatibility.

Once Metabase is installed, URLScan can be installed by simply running the installer.

The program is located in c:\Windows\System32\inetsrv\urlscan and the main configuration file is UrlScan.ini, in the same directory. A reasonably complete reference to the structure of that file can be found at
http://learn.iis.net/page.aspx/938/urlscan-3-reference/

Let us set up one of our web sites to use UrlScan. To do so, we first need IIS to use ISAPI Filters. This is another feature we have not yet installed. Navigate Start -> Administrative Tools -> Server Manager. From the tree, select Server Manager -> Roles -> Web Server. Under Role Services, select “Add Role Services”
and choose ISAPI FIlters.

With the ISAPI filters installed, Go back to IIS Manager, and choose one of your web sites (or the entire IIS installation). Double-click on ISAPI Filters. From the action pane for ISAPI filters, select Add. Give this filter a name (UrlScan); for the executable select c:\Windows\system32\inetsrv\urlscan\urlscan.dll
The page http://learn.iis.net/page.aspx/476/common-urlscan-scenarios/
describes some common ways in which UrlScan can be used.

UrlScan can be used to filter requests based on the URL. Suppose that we want to automatically drop any request that contains the string “notnow”. First, create the file notnow.html in your default web site, and verify that it is served. Open the UrlScan.ini file. In the section [Options] add the line

RuleList=TestRule

This is case sensitive; don’t put blank spaces around the equals sign. It is easiest to do this on line 175. Read lines 118-173 to understand the syntax of the change we plan to make. Create the section [TestRule]:

[TestRule]
AppliesTo=.htm,.html
DenyDataSection=TestRule Data
ScanURL=1
ScanAllRaw=1
ScanQueryString=1
ScanHeaders=
DenyUnescapedPercent=0

For the data, we create the section [TestRule Data]:

[TestRule Data]
notnow

Save the results.

Now any request that has the text “notnow” in the URL will be filtered. Verify this by requesting the notnow.html page you just created.

After veriyfing these results, examine the log data, in c:\windows\system32
\inetsrv\urlscan\logs

Suppose that you wanted to try to prevent SQL injection by scanning the query string to filter any request that contains any of the following

• select
• insert
• update

What UrlScan rule could you write? [The page http://learn.iis.net/page.aspx/476/common-urlscan-scenarios/ contains an even broader rule.]

Authorization

In IIS authorization is the process of determining whether or not IIS is
allowed to access a particular resource. Unlike Apache, IIS can run different portions as different users. We saw this when we created a virtual directory for
example, when we create a virtual directory, we can specify the credentials that are going to be used to access that resource. (We simply selected Application user, rather than specifying a different user.)

Choices are:

• NTFS ACL based authorization. This approach uses the file system to determine whether access to a resource is to be allowed. The user identity must have a Windows token. Note that forms (e.g. ASP.NET forms) cannot provide such a token.
• URL Authorization. This is not installed by default, though we did install it. It is a new feature of IS 7.0. This also integrates with ASP.NET. Authorization rules are stored in the configuration rather than the file system. Rules can be set directly from IIS manager. They can also be set with Appcmd.exe from the command line.

  Appcmd.exe set config /section:system.webServer/security/authorization
  "/+[users='string',roles='string',verbs='string',accessType='enum']"
  

• ASP.NET URL Authorization. Applications in ASP.NET integrated mode can let ASP.NET provide the authorization system.

Authentication

This is the process of determining the identity of a user requesting an IIS resource. In some cases, this will let IIS impersonate that user to access resources (c.f. Authorization above). Choices are:

• Anonymous authentication. This provides an identity for users who do not present
  credentials. The authenticated user identity will be a Windows anonymous user account. There are now three choices:
  • The built-in IUSR_ComputerName account (deprecated).
  • A custom account that you specify.
  • The identity of the IIS worker process that is processing the request (usually Network Service).

  If you do not want a portion of your web site accessed by anonymous users, then you must disable anonymous authentication for that portion of the web site- even if
  you enable other forms of authentication.

• Basic authentication. This is the same RFC 2617 HTTP protocol based technique we
  we discussed for Apache. In particular, credentials are sent in plain text. This is not part of the default IIS install; we did install it. Users must authenticate with a valid local or domain account.
• Digest authentication. This is part of the same RFC 2617 protocol based technique we we discussed for Apache. Because it is not commonly implemented, we will not
  discuss it in detail.
• Windows authentication. This uses windows techniques for authentication (NTLM or
  Kerberos). This is not part of the default IIS install; we did install it. This does work on e.g. Firefox on Linux or Chrome on Windows (tested) but fails on Konqueror on Linux. This uses a challenge-response system that is more resistant to sniffing. (e.g. Cain & Abel did not sniff the hashes from FF/Linux -> IIS).

  When using Windows authentication, you should know what types of authentication the server accepts. Navigate Control Panel -> Administrative Tools -> Local Security Policy -> Local Policies -> Security Options -> Network Security:
  LAN Manager authentication level. For highest security, you want to refuse LM and
  NTLM so that NTLMv2 is forced.

• Client certificate mapping authentication or IIS Client certificate mapping authentication. Neither of these were installed on our test system. These map SSL certificates to particular windows accounts which are then used to perform authorization. We will not discuss these in detail.

To illustrate these principles, let us apply some test cases to our default web site.
From IIS Manager, select the Dfeault Web Site, then select the Authentication button. Notice that three types of authentication are listed (Anonymous, Basic, and Windows) and that two of the three are disabled.

Disable Anonymous Authentication, and try to load a page from the web site. What occurs?

Enable Basic Authentication to the web site and try again. For credentials, try a local account on your IIS Server. Between each attempt, close and restart your
browser; you do not want to be sending or using cached credentials.

For credentials, try a domain account, but specify the domain [e.g. for the username, use domain\username]

Repeat, but for credentials, try a domain account without specifying
the domain.

Use a sniffer to watch this traffic. Can you find the passwords in cleartext? [Hint- Yes.]

Disable Basic Authentication and enable Windows Authentication. Does anything change?

Now enable both Anonymous Authentication and Basic Authentication. What behavior do you observe?

SSL

Let us create a certificate request, get it signed by our CA, and install it.
Navigate IIS Manager -> IIS, and select Server Certificates. Select Create Certificate Request from the Action Pane. Complete the form, but be sure to use your host name (e.g. iis.cs) as your Common Name. Select Microsoft RSA SChannel Cryptographic Provider and 1024 bits. Specify the name of the request, say ms_ssl.csr. If you don’t specify a directory, the file ends up in C:\Windows\System32

Open the file in notepad and note how this is essentially the same format we saw for Apache.

Copy the csr to your CA, say to /home/user/Desktop. Sign the certificate as we did in Week 7; e.g.

[root@centos1 certs]# openssl x509 -req -days 365 
-in /home/user/Desktop/ms_ssl.csr -CA /root/certs/ca.crt
-CAkey /root/certs/ca.key -set_serial 01
-out /home/user/Desktop/ms_ssl.cer

Copy the signed certificate back to the IIS server.

Back in IIS Manager -> IIS, Server Certificates, select Complete Certificate Request from the Action Pane. Complete the form, including the location of the certificate and a “Friendly name” for the result- say SSLTest. At this point, the SSLTest certificate should appear in the list of server certificates; it should be listed as issued to the common name you selected earlier (ssl.cs) and issued by the common name of the CA, which we called centos1_ca.class in our Week 7 notes.

Now let us create a new site that will use SSL and the certificate we just installed.
To create a new site, we use IIS Manager, and from the tree select IIS -> Sites (right click) -> Add Web Site. Complete the form. Use any Site name you wish, say SSL-Testing.

Let’s create a new directory (C:\SSL) to hold our site. We can continue to use pass-through authentication. Change the binding to use https, on port 443. Select the certificate SSL Test we had signed earlier.

Add some content to our web site- say an index.html page

Be sure to require SSL to visit the site; navigate IIS Manager -> Web Site -> SSL Settings; select “Require SSL”.

Client certificates allow the server to trust the client rather than the (traditional) other direction. The client will need a certificate signed by a CA
that the server trusts. Visit the web page from a browser that has the centos_CA
certificate listed as trusted. Be sure to specify https in the address!

Hey- how do we get internet explorer to import our certificate? Navigate IE -> Tools -> Internet Options; Content -> Certificates then select Import. Leave the Intended Purpose as <All>. From the Certificate Import Wizard, select the file that contains the certificate for the CA (This is the ca.crt file from Week 7) DO NOT ACCIDENTALLY USE THE KEY (ca.key) from Week 7.

For the purpose of our class, you can use as your certificate store the Trusted Root Certification Authorities. Note that Windows will be unable to automatically
validate the certificate.

Logging

Logging can be configured at the site level or at the IIS level. Select Logging from the IIS Manager, either for a site or for the IIS installation as a whole.

The default location for the logs is %SystemDrive%\inetpub\logs\LogFiles. The logs are plain text files, stored either as UTF-8 (default) or ANSI (which is a superset of ISO 8859-1).

There are a number of log file formats.

• W3C (default). You can specify what is logged from the following list
  1. Date
  2. Time
  3. Client IP
  4. User name
  5. Service name
  6. Server name
  7. Server IP
  8. Server port
  9. Method
  10. URI stem
  11. URI query
  12. Protocol status
  13. Protocol substatus
  14. Win32 status
  15. Bytes sent
  16. Bytes received
  17. Time taken
  18. Protocol version
  19. Host
  20. User agent
  21. Cookie
  22. Referer
• NCSA format is a fixed format that record remote host name, user name, date, time, request type, HTTP status code, and the number of bytes sent by the server. Items are separated by spaces; time is recorded as local time.
• IIS format is an extension of NCSA that also records elapsed time, number of bytes sent, action and target file. The items are separated by commas.
• It is possible to use other logging formats by creating a new COM component that implements the ILogPlugin or ILogPluginEx interface. We did not install this feature.

Logs can also be sent directly to a database via ODBC logging. We did not install this feature.

Logs can be centralized by having them written to a remote network share.