Novick Software
SQL Server Consulting • Design • Programming • Tuning

  andy novick is a sql server mvp



Protecting Your IIS Server and Web Application

Originally Published October 2001

 After the recent destruction of IIS based Web sites by the CodeRed and NIMBDA viruses, insuring security for Web applications has become everyone's job.  This article gives a plan for recovering from virus attacks, securing the server and protecting from further attacks.  It points the user directly resources that can speed the process.  The outline of the plan is:

  1. Recover from Infection or Rebuild

  2. Install Operating System Upgrades and Patches

  3. Verify that the system is up to date.

  4. Protect the system from Other Attacks, Old and New

  5. Monitoring

  6. Stay Informed

Throughout the article, I'll refer to various files that you can download from Microsoft.   Since NIMBA, Microsoft has become more serious about security.  They've instituted a new security program called the Strategic Technology Protection Program (STPP).  It includes free technical support to recover from a virus attack and the Microsoft Security Toolkit.  The toolkit is a collection of system upgrade files and protection tools including the tools discussed in this article.  They also provide a blueprint for recovery and protection.  Start at  I've ordered the CD and it's on backorder.  It may be available by the time you read this.

However you get the files, by CD or download, let's get started.

Recover from Infection or Rebuild

If you have an infected IIS Server, the first step is to pick between recovery and rebuilding.  Recovery involves cleaning viruses from your system and repairing any damage.  Rebuilding means starting from scratch using trusted media. 

Recovery is not insured and various authoritative sources (CERT, Microsoft, Symantec) recommend that servers that have been exposed to the public Internet be rebuilt from scratch.  Yikes!  They mean well but they don't have to do the work.  Rebuilding isn't fun but it gives the best insurance that you’re not leaving problems on your system.  In some cases, enough files in the operating system have been destroyed that rebuilding is the only course of action.  I’ve done both a recovery and a rebuild and both seem to have worked.  If you want to be safe, rebuild.


Assuming you decide to recover your the first step in protecting your system is to remove any infection.  During this step clean the system of viruses and take some steps to preventing instant reinfection. These steps should be performed:


  • Until the system is protected, stop the World Wide Web Service and set it to not start automatically.  Use the Control Panel/Services Applet.
  • Install a virus scanner/cleaner from a company like Symantec, McAfee, etc.  Download the latest virus definitions and scan your whole system.  If you find any infection, consider a rebuild.
  •  Remove any unnecessary file shares including any default shares on the roots of the drives
  • NTFS volumes are easier to protect than FAT volumes.   Convert all volumes on your system to NTFS, including the system volume.   When rebuilding, format drives as NTFS during the installation.

Whether you've cleaned your infection or rebuilt your system from scratch, you can proceed safely.

Install Operating System Upgrades and Patches

The best way to upgrade is by using Windows Update from the IE Tools menu.  Be prepared for some long downloads and to reboot often.  I suggest the following sequence of upgrades:

  • The latest OS service Pack (NT 4-SP6a or W2K-SP2)
  • Critical Updates (Patches since the Service Pack)
  • The latest version of your browser (IE 5.5 SP2 or 6). Don't use anything less.
  • Windows Critical Update Notification: This tool is applies only to NT Workstation or W2K Professional.  It checks every day for a critical update and pops up an offer to update your system.  I mention it in case you're running IIS on an applicable OS.  See for a complete description.
  • IIS Updates.  See the security bulletin MS01-044 and install the patches associated with your OS.
  • Outlook.  Outlook shouldn't be on a IIS server. Remove it and Outlook Express while you're at it.  You can delete the exe files.
  • Install the Resource Kit for your OS.  Some of it's tools will be used later when securing your system.

Verify that the System is Up to Date

Once you’ve used Windows Update to install the critical fixes, verify that you’re up to date.  While you can use Windows Update every day, there's a better tool: Network Security Hotfix Checker aka hfixchk.exe.  Download it by starting at:

Hfixchk.exe checks that you’ve installed available hot fixes for NT or W2K, IIS and IE.  It can be used to check all the computers in a domain, a subject that is beyond the scope of this article.  Run IE's Windows Update until hFixchk.exe shows that, “All necessary hot fixes have been applied.”

Unfortunately, on NT 4 Server it isn't possible get hfixchk to report that are patches installed. Even after the latest critical update packages have been installed, the HFixChk continues to report specific patches that have not been applied.  These have to be checked by hand.  The following bullets may help you with the details of some of these hot fixes. The bulletins can be read at:

Where YY-XXX is the year and number of the Bulletin.

  • MS98-001 - Relates to an ability on non-administrators to create groups.  See Q169556.  Fixed by running "Createals.exe -a" from the NT Resource Kit.
  • MS99-025 - Relates to disabling the RDS DataFactory.  There are various ways to disable it, including removing the MSADC virtual directory.  LockDownIIS, described in the next section, takes care of it.
  • MS99-036 - Relates to unattended installation of Windows NT.  If you use unattended installation, and more power to you, check this out.
  • MS00-025 - This relates to the file dvwssr.dll, which is used by Visual Interdev.  It can be removed from non-development servers.  Be sure it’s gone from your system.
  • MS00-028 - Relates to the file htimage.exe and imagemap.exe, which should be removed from your system unless you're supporting imagemaps on very old browsers.
  • MS00-041 - Relates to a RAS security.  Only runs if RAS is installed.
  • MS00-081 - Relates to a Microsoft Java Virtual Machine vulnerability.  Bulletin leads to new Java VM install.  Important if you're executing server side Java, otherwise not essential.
  • MS01-022 - Applies only to servers with the default language is Japanese, Chinese, or Korean.  Enough said.
  • MS01-048 - This one is new and deserves everyone’s attention.  Read the bulletin and apply its patch.  However, as the text of the bulletin points out the best protection against attack on the RPC mechanism is a properly configured firewall.

Protect the system from Other Attacks, Old and New

URLScan: Don't leave home without it!

This is a powerful tool for protecting your IIS.  It examines every HTTP request before it is handed to IIS, which normally responds by returning the requested HTML file or running the requested ASP page.  Before a request is allowed through to IIS, URLScan checks it for:

·       Malformed URLs such as binary data in the URL.

·       Attempts to run restricted file extensions such as EXE, HTA, IDA, etc.

·       Restricted HTTP Request types.  Only GET, POST AND HEAD are needed by most sites.

The default settings allow most HTML and ASP based applications to run without problems.  Get URLScan at: Configuration is done using an INI file.

Figure 1 shows how URLScan blocked a typical series of attacks from a NIMBDA infected system somewhere on the Internet.  The IP addresses have been XXXed out for security reasons.  There are plenty of infected computers out there on the net and I see a sequence like this every day.

Figure 1

[Tue, Oct 09 2001 - 12:05:32] Client at XXX.XXX.XXX.XXX: Sent verb 'OPTIONS', which is not specifically allowed. Request will be rejected.     

[Wed, Oct 10 2001 - 11:08:53] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected.  Raw URL='/download/win32/en/ie5setup.exe'

[Thu, Oct 11 2001 - 09:53:58] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected.  Raw URL='/scripts/root.exe'

[Thu, Oct 11 2001 - 09:53:58] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected.  Raw URL='/MSADC/root.exe'

[Thu, Oct 11 2001 - 09:53:59] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected.  Raw URL='/c/winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:01] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected.  Raw URL='/d/winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:03] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected.  Raw URL='/scripts/..%255c../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:04] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected.  Raw URL='/_vti_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:08] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected.  Raw URL='/_mem_bin/..%255c../..%255c../..%255c../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:09] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected.  Raw URL='/msadc/..%255c../..%255c../..%255c/..%c1%1c../..%c1%1c../..%c1%1c../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:09] Client at XXX.XXX.XXX.XXX: URL contains '.' in the path. Request will be rejected.  Raw URL='/scripts/..%c1%1c../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:13] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected.  Raw URL='/scripts/..%c0%2f../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:14] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected.  Raw URL='/scripts/..%c0%af../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:18] Client at XXX.XXX.XXX.XXX: URL contains extension '.exe', which is disallowed. Request will be rejected.  Raw URL='/scripts/..%c1%9c../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:19] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected.  Raw URL='/scripts/..%%35%63../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:23] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected.  Raw URL='/scripts/..%%35c../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:26] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected.  Raw URL='/scripts/..%25%35%63../winnt/system32/cmd.exe'

[Thu, Oct 11 2001 - 09:54:29] Client at XXX.XXX.XXX.XXX: URL normalization was not complete after one pass. Request will be rejected.  Raw URL='/scripts/..%252f../winnt/system32/cmd.exe' 

Install LockDownIIS

LockDownIIS uses the existing facilities of NT and IIS to protect it from CodeRed, NIMBDA and other attacks, known and unknown.  It does this by applying available security settings and installing a 404.dll file to protect from undesirable hits.   Get it at

When run on Windows NT 4, LockDownIIS depends on the InetPub tree residing on a NTFS volume, so you haven't already converted to NTFS, start by converting all volumes on your system to NTFS.  

LockDownIIS is a rather blunt tool. If allowed to, it turns off everything dangerous.  That includes all the useful stuff Microsoft has added to IIS over the last six years.  Unless you're using just plain HTML pages, use the Custom Installation option and keep features that your application uses.  For example, if you're using ASP pages in your site, be sure to allow ASP pages to be run.  Many of the protections implemented by LockDownIIS overlap with those of URLScan, but there’s no harm in that.

 IIS Security Check List

Microsoft provides an extensive security checklist that it recommends for sites that are exposed to the public Internet.  It took about 6 hours to perform the 50-step list for IIS 4, test that the application still worked, and adjust the settings to allow the application to function.  URLScan and LockDownIIS, referenced above, implement many of the steps, so you should run them first.  However, many steps secure NT and IIS in additional ways, such as protecting individual registry keys.  Having done it once, and given what I know of IIS attacks, I’m pretty sure that implementing the check list would have protected IIS from the CodeRed and NIMBDA viruses. 

Due to the number of steps, I can’t give step-by-step instructions here.  Using the checklist requires knowledge of your server and your web applications. Some of my notes from the installation process are:

  • The NT Event logs should have the Log Setting changed to allow for 10 Megabytes of log file and choose "Overwrite Events as Needed".  Do this for all three logs.
  • You'll be moving CMD.EXE.  Be sure to set up shortcuts for the interactive user so a Command Prompt can be run when performing maintenance interactively.
  • Since you'll be moving CMD.EXE and other powerful commands from their default location, you may want to put the path to their new location into the path of the Login ID used for routine maintenance.  This login ID shouldn't be "Administrator".
  • If your application uses a database, when configuring TCP/IP filtering, be sure you don't prevent your application from reaching the database.  I did and the application couldn't get past the login screen. Of course, you must also allow other traffic needed by your application as FTP or SMTP.
  • Use ACLs and File Protection (the good old ReadOnly attribute) to protect your Web pages from modification.  One of NIMBDA's innovations is modifying HTML and ASP pages to insert a small JavaScript that downloads and runs a virus program.
  • Turn on security auditing and logging wherever possible.  It should be turned on for NT, IIS and your database.  You'll need them for daily monitoring discussed later.

 You can find the security checklist for your OS by following links from

 Install a Firewall and set narrow rules

A properly configured firewall offers an enormous degree of protection from attacks against your IIS.  It should be configured to allow access only to ports 80 (HTTP) and, if you are using it, port 443 (HTTPS aka SSL).  Doing so blocks ICMP traffic, such as PING that is frequently used in attacks.  As with TCP/IP filtering mentioned above, be sure to allow any legitimate traffic on other ports.

If you're running an Extranet used by a limited number of business partners, consider restricting access to the IP address ranges of just those partners.  Be sure to create rules to allow traffic to the backup servers.


Virus attacks and downed servers get attention and everyone knows that you have to fix them and protect from future attacks. Now comes the hard part: monitoring your server.  It's hard because someone has to do it every day.  Not every week.  Every day.  Anything less leaves gaps in coverage that are just to long.  NIMBDA spread across the world in less than 24 hours.

 As you monitor you're going to look for unusual activity.  What's unusual?  To know what's unusual, you have to know what is usual.  To know what's is usual you have to establish a baseline.  I'll discuss creating your base line in each of the detail sections that follow.

 Virus Check

Start by checking to see if any viruses have been found in the last 24 hours.  In addition to running the real-time virus protection, I schedule a complete virus scan every night around 1AM when system usage is low. For good measure, I run my virus scanner's update program to check for new virus definitions fifteen minutes before starting the scan. Your baseline for viruses is zero.  There should be no viruses found.

NT Event Logs

  All three logs should be checked.

  • The Security log should be checked for failed logins, unusual levels of activity and for modifications to the system's security configuration.
  • The System log should be checked for usual activity such as browser requests from unknown systems or incomplete data packets intercepted on the network.
  • The application log should also be checked for unusual activity.

Is your System Software up to date?

Not only is the world supplied with an abundance of hackers, it's also has an abundance of security consultants hunting for new vulnerabilities and publicizing them.  Microsoft has been keeping up with new vulnerabilities by issuing a stream of Hot Fixes to Windows, IIS, IE and Office.  You can't wait for a service pack to come out.  There have been 52 security bulletins with fixes so far in 2001 with out a service pack.  Recently Microsoft has also made an effort to get the security consultants to stop publicizing new vulnerabilities.

 As discussed above, there are two tools available for checking updates on a server:

  • Network Security Hotfix Checker; and
  • Windows Update from the IE Tools menu.

Pick one or the other or both to do your daily monitoring.

With Network Security Hotfix checker your baseline is the list of Bulletins that are reported as necessary but that you've determined are not needed, or don't show up as handled because their solution is manual.  On Windows 2000, this list is usually nothing.  On NT 4 Server, I always seem to have eight of these.

To be able to monitor this every day, create a baseline report using the command line:

hfixchk > HotFixBaseLine.log

Next, create a CMD file with these two lines:

hfixchk > TodaysHotFix.log

fc /L HotFixBaseLine.Log TodaysHotFix.Log

Point a shortcut to the CMD file, run it, and you'll know in a few seconds if you're up-to-date.  You'll have to update HotFixBaseLine.Log after any updates are applied.

When using IE's Windows Update I always install everything in the Critical Update category and most things in the Recommended category. If you don't install them, they continue to show up in their respective list.  The list can be customized so you aren't reminded to install support for the Hungarian language, etc.

URLScan Log Check, Web Log Check

These two logs go together because they're reporting on the same traffic, your HTTP hits to your web server.   Start with URLScan.  If a request is blocked by URLScan, it never gets to the web server.

My baseline for URLScan entries is 15 entries for the day.  URLScan adds all new entries to the end of one file URLSCAN.LOG.  You have to open it up and jump down to the bottom to see the new entries.

IIS logs every web request to a log file that you can configure using Internet Services Manager.   Set it to create a new log file every day.  A simple but effective baseline is the number of kilobytes in the log.  Either a spike or a trough in the size of this file would be a signal for concern.

Read the IIS log to get an idea about what's happening in your application and how your users use it.  Some things to look for are application errors and visits to a login page without successful login.

In the IIS log will be the probes by the bots, spiders, crawlers, and other programs trying to index the entire web.  This type of probe is important for your site to show up in search engines and you may want to encourage it.  On the other hand, if your application isn't open to the public you might want to discourage it entirely. 

Web indexing programs query a file named robots.txt in the root directory of your site.  This is based on the Robot Exclusion Standard. Using robots.txt they can be directed to the files you want indexed.  To turn off all indexing, put the following two lines into your robots.txt file:

# Discourage all web indexing

User-agent: *

Disallow: /

A through explanation of the robots.txt file can be found at     Another good explanation is available from:

Performance Monitor Alerts

NT's PerfMon and Windows 2000 can be set to create a log of activity instead of showing the current activity on the screen.   By continuously gathering statistics about a system, unusual activity can be spotted.  Alerts can also be configured and these alerts directed to the Event Log.  This limits the need to examine the log every day.  Just look in the Event Log.  Start by logging processor usage, ASP, IIS and IP activity.    You'll need to establish a baseline for your system before adding alerts.  Once you're familiar with what's usual, add alerts that spot the unusual.  Figures 2 and 3 show how alerts look in PerfMon and in the NT Event Viewer.  These CPU alerts correspond to the nightly virus scans on that system.  If IIS is compromised by a CodeRed type virus, its CPU usage shoots to the sky as your server is used to attack other systems.

Figure 2

IIS Security, Windows Event Log


Figure 3

IIS Security, Windows Performance Monitor

Database Log files

This one is going to depend on the capabilities of your Database.  For SQL Server 2000 all logins/logouts can be audited in the system log files.  If you want to go even further, you can create a baseline using the Profiler to record all Audit events into a table that can be used later for comparison to a running system.


Even more important! Check that your database backups are performed as scheduled and that the database can be restored from the backup. 

Stay Informed

Real-time security notifications

To keep up to date with the most important developments in Internet security, subscribe to two mailing lists:


Web Resources

Start with Microsoft’s site:

There’s a good article about the top vulnerabilities of IIS web servers in

The site has plenty of useful IIS administration information.

Another one is .  In particular, has extensive information and links about CodeRed and it’s variants.

More Security information including the list of Top 20 Internet security holes can be found at

I also get great explanations about how various attacks are performed and free tools to investigate security issues at Gibson Research's site:


Designing Secure Web-Based Applications for Microsoft Windows 2000

By Michael Howard with Marc Levy and Richard Waymire. Published by Microsoft Press in 2000.  ISBN 0-7356-0995-0

Hacking Exposed: Network Security Secrets & Solutions Second Edition by Joel Scambray, Stuart McClure and George Kurtz. Published by Osborne/McGraw-Hill in 2001. ISBN 0-07-212748-1


Are you exhausted yet?  I'm wearing out and I haven't even touched the subject of writing a secure application!  That's a topic for another article some day.  In the mean time I monitor my systems every morning, continue to read about security topics, and work to improve the security of my applications in every way possible.  Unless the application developers and network administrators of the world are vigilant about security, the terrorists of the Internet will destroy the Internet's potential for improved productivity, convenient commerce, knowledge sharing and just plain fun.  I for one don't want that to happen.


Personal Blog

New Tips:

Use dsinit to set the SQL Server instance for Windows Azure dev storage


Nov 7, '12
Loser: DB

Full Schedule