Microsoft TechNet provides a Security Bulletin Search, the ability to sign up for future security bulletins as well as the ability to search for the patches you need based on the Product and Service Pack a company is running. The following link gives more complete details:

This link outlines some of the steps that should be taken to secure a Windows2000 Server that is running IIS 5.0 on the Internet. It goes through 5 steps: general information, background work, IIS 5.0 Settings, and the necessary steps to install scanner/intrusion Software. The following link gives more complete details:

Microsoft provides a 9-page document on "Authentication and Security for Internet Developers". This article explains Windows NT security as it relates to IIS, so security-related problems trouble-shooting can be happen effectively. The article covers three forms of authentication, how they differ, several ways of controlling access to key areas on a Web Server, and the important but almost universally misunderstood concept of "delegation". Understanding delegation is mandatory for anyone building a data-driven Web site using IIS. Understanding how Windows NT handles different users will save potentially days, or even weeks of troubleshooting. The following link gives more complete details:

Default.htm, default.asp, and so forth are prime targets. Pnc_start.asp is a great example. That stands for "private naming convention start asp." Of course, I just made that up. That's the point. The Code Red attack replaced the predictable files (prime targets), but completely missed the varied names.

Preferably, this drive would include only INETPUB and related files. System files, logs, and data files (databases, etc.) should not be on the same drive, even if they are on the same machine. The end game here is that Code Red is a "malformed URL" attack, which uses a tactic confuse the web server that is very much dependent on the critical and dangerous files being in a predictable location. Moving them confuses the attacker right back.

Those that map to shares on other computers or paths outside the web server realm might need special attention (for instance, many might map to paths under \WINNT\SYSTEM32, which should be very carefully secured).

Include the directories per the previous item. Consider the misuse of these files. For instance, perl.exe is routinely placed in reach of the web server so scripts can be run. However, perl.exe can be used to run arbitrary commands as well, so this setup works but is not at all secure. Code Red copied a command processor (cmd.exe) from its normal location to a spot within the reach of the web server, which it did to ensure easier future attacks. It copied it as "root.exe" which should have raised red flags just because it was a .exe file within the reach of the web server. For situations like perl.exe, application mappings are a better alternative. (See the next item)

Under the server or application's Properties, Home Directory, Configuration, this will show which other file extensions will cause IIS to run another program to process the file.

The names of these Packages/COM+ Applications start with IIS. Specifically note the information in their Properties page, on their "Identity" tab. Much emphasis is given to the IUSR_<computername> account, which is the identity assumed by all anonymous connections. Web sites that are not anonymous assume the identity of the user that logs in, which you would assume, is the basis for security in those cases. However, any site, anonymous or not, that uses a COM package (which is the majority of the major ones, since this is Microsoft's prime web architecture) can be configured to run the objects under a specific user context. Refer to Microsoft's knowledge base articles if you have COM objects that are used, but don't seem to be in a package (as they actually are, you just need to identify which one). The user contexts specified under "Identity" are many times off everyone's radarscope.

Use the previous items as a discovery process that will provide a better understanding of the identities involved in web transactions and where they need access.

For instance, if the users link to http://serverfarm1.yourcompany.com/appstart.asp (which no one ever types directly), http://serverfarm1.yourcompany.com: 82/appstart.asp will probably work fine. This is another tactic that will thwart blanket attacks.