IIS Answers -

Key Links

IISTraining.com
hands-on, fast track, up-to-date training on IIS 5 and 6

IIS Lists
moderated email discussions on IIS related topics

IIS Boards
online IIS bulletin boards

About Brett Hill

Advertising Info
if you're interested in reaching thousands of IIS administrators.

Privacy Statement

IISAnswers Articles
IIS - The Rock!
by Brett Hill

I was invited to secure an IIS 5 server for an event called the TechMentor Security Summit in Seattle held July 10-12, 2002. This conference was unique. Rather than doing the standard "speaker lectures to students" format, a team was assembled to design and implement a network for the conference. The network was then made available to the internet to see if it could be hacked. The IIS server in the DMZ hosted a basic ASP guestbook program that connected to a SQL server through an ISA firewall protecting the internal network.

There was a couple of design restraints placed on the security team. We had to use the Security Operation Guide from Microsoft (see link on www.iisanswers.com) and we could not use 3rd party (i.e., non-Microsoft) security tools other than anti-virus software and a PIX firewall on the frontend. I was charged with hardening the IIS 5 server and then saying to the world, "come and get it."

The basic design of the network was:

Internet to Pix.
PIX to Hub.
Hub to IIS, monitoring system (to capture network traffic for analysis), and ISA
ISA to internal network containing SQL server, Exchange 2000, and workstations/file servers.

Connecting the PIX to the Hub was a bit risky, since this provided a direct path to the inner firewall. ISA server, however, was also a rock and as penetrated despite many attempts. The rationale for using a hub was to place a network monitoring station in the DMZ and analyze traffic.

The servers and workstations were hardened using the Microsoft Security Operations Guide as a blueprint. It's surprisingly useful and and includes some aggressive templates for use. The IIS server in this situation was stand alone, so I could really clamp it down.

The PIX firewall was configured in a very loose manner. We didn't want the focus of the conference to be hacking the firewall so all upper ports plus RPC, SMTP, and HTTP traffic were available. Many of the features you would normally enable were left off.

While I'd like to go into a ton of detail, I'll focus in the IIS configuration strategy:

1. Applied the Security Operations Guide baseline template.

2. Applied the Security Operations Guide iis-incremental template modified to apply account/password permissions and disable services not required for a member server

3. Configured IPSEC to port filter all but port 80 on the public IP and to require certificate based authentication to communicate with ISA. A companion rule was configured on ISA to require a certificate from IIS. ISA would then accept connections from IIS and pass them the SQL server on the internal network. The created an encrypted, mutually authenticated connection IIS and ISA.

4. Placed Web content in a WebRoot folder on partition D with SYSTEM+ADMINS - full control, Authenticated Users - read, Web Publishing Group - Modify, Web Anon Users group - deny write.

5. Two Web sites were created on the IIS server; one for public access that allowed only anonymous access. One for private access that did not allow anonymous access. The private site was used for WebDAV publishing to update the site content. It permitted only Integrated Windows authentication and NTLMv2 was required.

6. Ran the IIS Lockdown tool disabling application mappings except for ASP, removed all default folders, and applied tighter permissions.

7. Installed URLScan 2.5 with a slightly modified urlscan.ini file that allows WebDAV, ASP, and static content only. Also configure URLScan to reject long URLs or queries.

Of course, all service packs and hotfixes were applied and there were some other modifications (such as applying MDAC 2.6) but the above were the highlights. All of this took about 20 minutes at best for the IIS side. This doesn't include time preparing for the event and fixing up the templates.

The real workhorse in this event was URLScan. By allowing only ASP, WebDAV, and static files, all other efforts were rejected. Attempts to jam the server with long and malformed URL's were rejected outright. This in and of itself prevented IIS from even seeing many of the hacking efforts.

URLScan combined with IPSec and judicious use of authentication and permissions, proved to be a solid server.

I would be remiss to omit that Ted Malone was the chief architect of the SQL server configuration and the ASP application residing on the IIS server. According to Ted, even if users had obtained the SQL logon username and password which was in clear text in the global.asa file, the SQL server would not have been compromised. Furthermore, he did not inspect each field for validity in the ASP form which you would always do in practice. But for our purposes, and to make a point of how simple this is, he defeated SQL injection strategies with the command Replace(strXX,"'","''") where XX is the string name. This causes a SQL string placed into a form field to be seen as an embedded quote on the SQL server. Clever, that Ted guy.

The bottom line is that without any intrusion detection, serious firewall configuration, or 3rd party software the IIS server and the internal network was not hacked despite thousands of attempts by those in attendance and across the globe.

Now, I fully realize the limitations of the experiment and do not claim this proves anything other than this particular network in these particular circumstances proved resistant to the particular attacks launched against them. There were numerous other issues we did not address which are essential, such as effective intrusion detection, monitoring, recovery plans, security plans, and a particular weak spot at this event was physical security.

But, it does show that IIS5 on W2K, when properly configured using Microsoft standard tools, is a much stronger system than is commonly accepted.

Team members included Steve Riley (Exchange), Laura Robinson (Domain Controllers), Roberta Brag (internal network File Server and Workstation), Joern Wettern (ISA), Brian Komar (IPSec), and Ted Malone (SQL) so we had some excellent advice.