07- IIS on Windows 2008 R2

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 unseen.disc.tu, with domain controllers ephebe.unseen.disc.tu at 192.168.1.30 and klatch.unseen.disc.tu at 192.168.1.31.

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

We also configure the name and domain of the server; in the example, the web server will be named hublands.unseen.disc.tu. 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). In Windows 2008 (not R2) It will ask to also install some additional features (Windows Process Activation 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.

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 (UNSEEN\administrator) [The text UNSEEN\administrator 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 local group HUBLANDS\IIS_IUSRS has access to the directory (Read & execute; List folder contents; Read)(Replace HUBLANDS by the name of your host). To do this, select the folder (right click) → Security → Edit.

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.40.

Since our web server is joined to a domain that is also running a DNS server, the server will automatically add both a A and a PTR record matching the hostname with the new IP address. Indeed, looking at the DNS Manager, we will see both addresses:

A lookup for this hostname will return both IP addresses:

[vimes@pseudopolis ~]$ nslookup hublands
Server:		192.168.1.30
Address:	192.168.1.30#53

Name:	hublands.unseen.disc.tu
Address: 192.168.1.39
Name:	hublands.unseen.disc.tu
Address: 192.168.1.40

Of course, this is not the behavior we want. Instead, we will delete the both the original name and the duplicate from the DNS server (from both the forward and the reverse lookup zones), and add new records (both A and PTR) for webtest.unseen.disc.tu at IP address 192.168.1.40 and for hublands.unseen.disc.tu at 192.168.1.39. When we are finished, we can verify that the nameserver works as we expect:

[vimes@pseudopolis ~]$ nslookup hublands
Server:		192.168.1.30
Address:	192.168.1.30#53

Name:	hublands.unseen.disc.tu
Address: 192.168.1.39

[vimes@pseudopolis ~]$ nslookup webtest
Server:		192.168.1.30
Address:	192.168.1.30#53

Name:	webtest.unseen.disc.tu
Address: 192.168.1.40

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

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

The IIS Manager interface

Let us spend some time learning about the different features of the IIS Manager.

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. This can be set at the web server level, or at the level of the individual sites. From IIS Manager, select either the web server (HUBLANDS in this example) or the individual web sites (Default Web Site or WebTest in this example). In each case, you will be able to modify the Default Document. Settings made at the server level will propagate to the individual sites.

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.

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.unseen.disc.tu/) 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? (If you have done everything described above, the file will exist. If not, well, is that my fault?) 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.

From this, we see that

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

Now view the bindings for the new web site we created, webtest.

Here we see that for the WebTest site,

• 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://hublands.unseen.disc.tu
• http://webtest.unseen.disc.tu
• http://192.168.1.39
• http://192.168.1.40

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.unseen.disc.tu/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:\Users\administrator>c:\Windows\System32\inetsrv\appcmd.exe list sites
SITE "Default Web Site" (id:1,bindings:http/192.168.1.39:80:,state:Started)
SITE "WebTest" (id:2,bindings:http/192.168.1.40:80:,state:Started)

To stop IIS serving a particular site

C:\Users\administrator>c:\Windows\System32\inetsrv\appcmd.exe stop site 
"WebTest"
"WebTest" successfully stopped

To have IIS start serving a particular site

C:\Users\administrator>c:\Windows\System32\inetsrv\appcmd.exe start site 
"WebTest"
"WebTest" successfully started.

To have IIS list all of the virtual directories in use

C:\Users\administrator>c:\Windows\System32\inetsrv\appcmd.exe list vdir
VDIR "Default Web Site/" (physicalPath:%SystemDrive%\inetpub\wwwroot)
VDIR "WebTest/" (physicalPath:C:\WebTest)
VDIR "WebTest/dir2" (physicalPath:C:\Outside)

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:\Users\administrator>c:\Windows\System32\inetsrv\appcmd.exe set config 
"Default Web Site" -section:system.webServer/directoryBrowse /enabled:"True"
/showFlags:"Date, Time, Size, Extension"
Applied configuration changes to section "system.webServer/directoryBrowse" 
for "MACHINE/WEBROOT/APPHOST/Default Web Site" at configuration commit path 
"MACHINE/WEBROOT/APPHOST/Default Web Site"

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.

UrlScan

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. Choose either the 32 bit or the 64 bit version as appropriate.

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” in the URL. First, create the file notnow.html in your default web site, and verify that it is served. Open the file C:\Windows\System32\inetsrv\urlscan\UrlScan.ini.

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 as different users.

Choices are:

• NTFS ACL based authorization. This approach uses the file system to determine whether access to a resource is to be allowed. This requires IIS to have a valid Windows identity to determine if it has access to the file system. Because this approach uses file system permissions, it makes migrating sites from one host to another more complex.
• URL Authorization. This is a new feature of IIS 7.0; it is not installed by default, though we did install it. In this approach, 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.

We do not have sufficient time to really discuss these different authorization methods in more detail.

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).
• 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 Default 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? Does it matter if you are using a Windows machine or a Linux machine?

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

SSL

Getting a certificate

Let us create a certificate request, get it signed by our CA, and install it.

First, we need to make sure that our CA is going to be trusted by the server. In Week 6, we stored the certificate (not the private key!) in the file /etc/pki/CA/certs/ca.crt. Copy that file from the CA to the web server.

Installing this certificate in Windows 2008 R2 is much more challenging than it has been in earlier versions of Windows Server. From the Start menu, select Run and choose "mmc"


From mmc, select Add/Remove Snap-in, and select Certificates. You want the snap-in to manage certificates for the Computer account for the Local Computer. Select OK to be presented with a Window like the following.

Right-click on Trusted Root Certificates → All Tasks → Import. From the Certificate Import Wizard, select the certificate CA.crt that you brought over from the CA. Be sure that you store the result in the Trusted Root Certification Authorities store.

Now that we have told the system to trust certificates signed by our CA, we need to create a certificate signing request (.csr) as we did in Apache. To do so, navigate IIS Manager → IIS, and select Server Certificates; this is done at the server level- not the site level. Select Create Certificate Request from the Action Pane. Complete the form, but be sure to use your host name for your site (e.g. hublands.unseen.disc.tu) as your Common Name. Select Microsoft RSA SChannel Cryptographic Provider and choose a bit length. Specify the name of the request, say hublands.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. Sign the certificate as we did in Week 6; e.g.

[root@dragonslanding certs]# openssl x509 -req -days 365 
-in /home/vimes/Desktop/hublands.csr -CA /etc/pki/CA/certs/ca.crt
-CAkey /etc/pki/CA/private/ca.key -set_serial 01 
-out /etc/pki/CA/newcerts/hublands.crt

Signature ok
subject=/C=US/ST=MD/L=Towson/O=Towson University/OU=Security
Lab/CN=hublands.unseen.disc.tu
Getting CA Private Key
Enter pass phrase for /etc/pki/CA/private/ca.key:
[root@dragonslanding certs]#

Copy the signed certificate hublands.crt back to the IIS server.

Return to IIS Manager → Server Certificates and 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 HublandsSSL.

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 (hublands.unseen.disc.tu) and issued by the common name of the CA, which
we called dragonslanding.cosc.tu.


Creating the site

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 HublandsSSL

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. Be sure to select the IP address that matches the host name = common name you selected for your certificate. Speaking of that certificate, select the certificate HublandsSSL 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. These are rare, and we can happily ignore them.

Visit the web page from a browser that has the CA’s 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 (ca.crt).

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; this is expected behavior.

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.

Web Application Firewall

We have seen the value of a web application firewall in our discussion of ModSecurity for Apache. Unfortunately, most of the web application firewalls for IIS are commercial products of one sort or another; however AQTRONIX has an Open Source product called Web Knight.

To install the tool, download the archive, either from the labshare or directly. Unzip the archive in a convenient location. Since our demonstration machine is Windows 2008 R2 on a 64 bit architecture, run the installer Setup\x64\WebKnight.msi. This will install the tool in the directory C:\Program Files\AQTRONIX Webknight.

From that directory, run the Config.exe tool to configure the tool. The file WebKnight.xml contains the primary configuration information; the file Robots.xml can essentially be ignored in our laboratory setting.

Once the configuration variables are set to your satisfaction, save the result. These changes will not be implemented however until IIS is restarted. This can be done directly from the action pane in IIS manager.

Accept the default settings (for now) and restart IIS. Then visit the SSL enabled site we created earlier, and notice that WebKnight has blocked the request.


To determine the cause, run the tool C:\Program Files\AQTRONIX Webknight\LogAnalysis.exe and open your log files. From there we see the following entry:

We see that the trouble is that the directory c:\SSL that we created to house our SSL protected site is not in our allowed path list. Indeed, if we run the configuration tool again and select Mapped Path from WebKnight Configuration, we see that the list of allowed paths for IIS does not include c:\SSL.


Adding the directory C:\SSL to the list of allowable directories will solve the issue.