6. Make Good Use of Web Service Extensions in IIS 6.0
Web Service Extensions in IIS 6.0 is a mighty ally in the fight for security. This feature prevents executable content from being delivered unless it is explicitly allowed by full path name. By default, IIS 6.0 will not deliver any executable content! This means that if you want to allow ASP to run you must configure Web Service Extensions to permit ASP.dll to execute. As a result, even if you granted a Web site the NTFS permission of Everyone—Full Control, and an attacker placed an executable in the Web site, they still could not run the executable from a URL. A 404—File not Found error would be returned. Figure 3 shows the default configuration that allows only static content to be delivered.
Figure 3 IIS Manager
This feature can be disabled by electing to allow “All Unknown ISAPI” and “All Unknown CGI”. You may find yourself doing this when troubleshooting in order to remove potential problems. You will also find that developers who use IIS 6.0 will disable this feature as it can be quite annoying to have your most recent executables blocked every time you create a new one. This may be fine for your developers, but it is not fine on your production server.
7. Use Host Headers
This one surprises most administrators, but I recommend using host headers on your public-facing Web sites, even if you don’t need them. A host header is the HOST field that is part of the HTTP request sent from the client when contacting IIS. This field is required as part of the HTTP 1.1 specification. When you assign a host header to a site, the site must be accessed by the name entered in the host header field.
For example, if I assign contoso.com to a Web site’s host header field, then the user must type in http://contoso.com (which, of course, must resolve to the correct IP address) in order to connect to the server. If they type in http://www.contoso.com, the connection will fail. As a result, in the Advanced Configuration you should enter every name for which you have DNS configured to resolve to the IP address of the server.
I know you’re wondering why you should bother. The most aggressive and famous attacks in Internet history have all succeeded by finding servers to infect through some automated IP address scanning process. If you use host headers, your Web sites will not respond to an IP address. In other words, the Web site Contoso.com is always available when using Contoso.com or www.contoso.com, but if you use http://192.168.1.1 (the IP address of contoso.com) the connection is refused because the IP address does not match the host headers you entered for the site.
In this way, any future worms using an IP address scanning engine will miss you completely. This will not interfere with SSL as long as you have a unique IP address for each Web site.
8. Scrub Your Apps
I’d be remiss if I did not point out that the most likely point of attack on IIS these days is not the server itself, but the applications you host. After you’ve tightened up your server and you are successfully channeling all the untrusted traffic to port 80 on your Web server, you may still be hosting exploitable applications, in which case you’ve got a different kind of problem. This is not one that administrators can do much about. It would be a good idea, however, to check on your software design policy and be certain that it contains this directive: all user input is considered bad or malicious. This means that your applications must enforce validation of every entry in every form, every request to a service, and any other way the user has of entering content into the application. An attacker will try to enter all kinds of content into every field of an application to see what happens. A persistent hacker will not miss any of them, so you can’t either.
9. Keep Your Server Updated
Of course you must keep your server current with the latest updates for Windows Server 2003 as well as those for any other apps. The good news is that, as of this writing, IIS 6.0 has required zero critical security updates since it was released. This is an outstanding record that Microsoft is proud of and intends to continue. For more best practices, see “Checklist: Securing Your Web Server”.
This article from:
http://blog.csdn.net/yjz0065/archive/2006/08/02/1011222.aspx