skip to primary navigationskip to content

Maintaining IIS Security

Maintaining an IIS server is no different from maintaining any other system; it needs to be patched and updated.  

Anyone running and maintaining SQL back-ends to sites are advised to make that SQL is also patched and access to the SQL management interface is restricted appropriately. 

You must:

  • Respond to security issues
  • Be aware of security updates and keep the system up-to-date
  • Monitor the system and IIS logs
  • Test changes for security issues. This is particularly important with server-side includes (eg ASP and Active X controls etc).

Respond to Security Issues

If you receive an email from, you have a problem! The process of dealing with a hacked server is important. Often the first warning you get is an email from CERT; you should do what CERT advises immediately.

For information on Cambridge CERT see

Security Updates

To avoid a CERT email telling you to unplug your server from the network, patching the system is essential.

Currently Microsoft release patches on the second Tuesday of the month. Windows-Support email an alert to the IT-Supporters list when patches are released and available from our WSUS server. As a Techlink you should receive these mails or, if you are not a Techlink, then your local CO or Techlink should be advising you about these updates. If you are not the Techlink for your department or College then you should inform them that you are running a web server. If you are uncertain who this is then the Computing Service Help-Desk should be able to inform you.

If you are contacted by your Computer Officer or receive an email notification from Windows-Support about an IIS or Microsoft system vulnerability please take the appropriate action (normally means applying the appropriate patch) as soon as possible. Zero day exploits are not uncommon, which means that there could be code available to hack your unpatched system the next day. Serious hackers don't necessarily believe in holidays.

If you do not understand how to install Service Packs or hotfixes (collectively known as patches) please email for assistance. Whatever you do, when you have finished applying a patch, reboot the system immediately!

You should configure your system to use Automatic Updates (once a day preferably)

Apply the patches as soon as is practical. Production servers are vulnerable, especially if you are not using any kind of connection filtering (ie your webpages can be accessed by anybody). You should schedule downtime as soon as possible after the patch release day to apply and test patches (since Microsoft normally stick to a regular monthly patch release schedule except for emergencies, you should be able to timetable this on a regular basis). In emergencies Microsoft may release a patch on a one-off basis so you should be prepared to update your systems then as well.

Monitor System and IIS Logs

Both the Windows system and IIS logs need to be monitored. They will provide troubleshooting and security warning and help. It is essential that they are monitored regularly.

Windows System Logs

You should have enabled auditing on your server. Auditing can be found under Administrative Tools>Local Security Policy. The exact level of auditing is up to you but as a minimum you should be auditing:

  • Account logon events (failure)
  • Logon events (failure)
  • Object access (failure)
  • System events (failure)

Note: Auditing successes can quickly fill up your logs and may not be needed unless you require an audit trail (for whatever reason). Test your settings to find the best balance between useful data and ability to search and maintain the logs. The general rule for Microsoft logs is to audit for failure where space is at a premium.

IIS Logs

IIS log information can be found in IIS Manager. Display the Web site's Properties In the bottom section of the Web site tab you will see the tick box to enable logging and a Properties button.

In the log properties area you are able to set:

  • New log schedule - the default creates a new log each day(recommended)
  • Tick box for Use local time for file naming and roll over. The default is unticked (We Recommend its is ticked)
  • Log file directory - the default is C:\WINDOWS\system32\LogFiles

The logs should be monitored on a regular basis. Look for illicit login attempts (Administrator is usual but other accounts will also be tried). There are a number of additional things you can log which can provide useful information by viewing the Advanced tab

Some of the more useful advanced logging are:

  • Server name - useful if you are using multiple virtual site
  • Bytes sent/received - traffic log, more useful for ftp sites

If you did not set up the machine you are maintaining and cannot find the logs, then do a search for *.log files, remembering to make sure you look for hidden and system folders and make sure the machine is displaying file extensions (see For example a file called ex060810.log is the IIS 6 logfile for the 10th August 2006 (American-style dates).

The log files are plain text files, and can be read most safely by using Notepad.

If you see see anything suspicious or out-of-the-ordinary (and after you have run your server for a couple of weeks you will have a general idea of the type of traffic which is normal for your site), then it's worth checking previous logs for a pattern. If you are really concerned, contact for further assistance. However be aware that any website accessible outside of the cam domain will be constantly probed, this is not something you need to tell us about!

Test Changes for Security Issues

You should always check any configuration changes as soon as they are made. It is frightingly easy to allow open access to something when you did not want to!

While it is very easy to create scripts and Active X controls for IIS, it is also very easy to write insecure ones! There is plenty of information on the Internet and the Microsoft web site on avoiding the most common mistakes and pitfalls.

Security Probing Software

UIS run a security probing suite which checks for known system vulnerabilities. Details can be found here. If you receive an email from your Techlink or Computer Officer referring to this and saying that you are vulnerable, please take appropriate action.If you do not understand the output, or what you are supposed to do about it, then please email the UCS Service Desk for assistance.

If you feel that this is all too much for you

Then you should not be running IIS or possibly a webserver at all. There is the option of the managed web service which would probably be much more suitable for the inexperienced, or people who do not have the time to check server security on a regular basis.

If you have any doubts or worries then please email We would much prefer you talked to us before setting up a server to be hacked!