adOpenStatic Logo
Navigation
Home
FAQ
Ken's Blog
Resources
Contact Ken
Copyright 2000 -



Securing Your Webserver
There have been a rash of exploits discovered for sites where a default installation of IIS has been used. Code Red and Nimda have been two of the most recent (and notorious). Many of the exploits available attack vulnerabilities in services which the average website never uses, however many small or amateur run websites do not have the expertise, or the necessary management will, to secure their sites leading to wide-spread server compromise, and potentially devestating results.

The following is not intended to be a definitive list of steps that you can take to secure your site. However, there are some pointers as to where you can get more detailed information. Remember security is not a destination, it is a journey, and as such constant vigilence is required.

  • Apply the latest Service Pack for your OS. Whilst there have been a number of problems discovered in various Windows Service Packs, these pale in comparison to the benefits that are achieved. Numerous bug-fixes, security patches and so forth that have been regression tested are rolled into a Service Pack release.

  • Remove all unneeded extension mappings. Multiple vulnerabilities have been discovered in dlls that process esoteric extensions that most websites never need - in particular for Index Server. In your IIS MMC Snapin, edit the properties for the master website and remove mappings like .idx, .idq, .htw etc that are not required.

  • Do not install samples or admin tools or any unnecessary features onto production machines and remove all unnecessary virtual directories (such as /msadc/) . The more you load onto a production machine, the more critical it becomes that you remain on top of all issues that could affect each and every component. As well, it means that there is a greater possiblity that a fix of a particular problem might cause problems with some other fix or component.

  • Firewall your machine or network if you do not wish your webserver to be accessible to outsiders. This really applies only to development machines, in particular those that you might have on home computer which are also connected to the internet. A firewall is not going to able to differentiate a legitimate request for a resource from your webserver, and a request that is designed to exploit a vulnerability in your webserver software, but if you block all requests for resouces on port 80 and 443 (SSL), except for those coming from 127.0.0.1 (your local loopback address), then you will avoid some problems.

  • Disable the default site on a Server OS webserver. Create other sites in non-default directories, and use host-headers for each site. Host-headers are supported by all HTTP clients that support HTTP v1.1 which is just about everything these days. Since most automated exploits work by randomly attacking IP addresses, none of your host-header enabled sites will ever respond to such an attack. Additionally, exploits like the IIS/Sadmind exploit assumed that your website was installed in the default c:\inetpub\wwwroot\ folder, allowing it to then traverse the physical file structure to c:\winnt\cmd.exe. Placing your website on a non-system partition helps avoid (in part) these problems.

  • Do not use Frontpage Server Extensions (FPSE) on a production machine, or take the time to understand how FPSE security works. A failure to configure FPSE properly could mean that anyone with a copy of Frontpage can edit your site. Microsoft has information on FPSE in a resource kit available online here. MS KB article Q278432M shows how to read FPSE authoring logs.

  • Use the Microsoft provided security tools to determine what hotfixes and patches you require. The Microsoft Security site has this page which allows you to enter your OS version, SP level, and IIS software and it will provide a list of hotfixes required. Additionally, the HFNetChk tool can be used offline to determine hotfixes required on your network.
  • Signup for security bulletins from Microsoft, and other vulnerability lists such as NTBugtraq and BugTraq. Also worth mentioning are SANS and CERT. ASPFriends.com also has a list devoted to ASP Security issues.

Guide Homepage | Back | Next