The first step in locking down a Web server is to make sure the administrator has the institution's backing via a security policy. It doesn't make sense to lock down a machine if the higher-ups haven't recognized the Web server as an asset to be protected. Securing a server takes continual time and effort. If that time is not supported in the budget and/or is not part of long-term strategic IT plans, then an administrator who is spending valuable hours securing the server is doing so without the necessary support of management.

What can happen as a result is that after an administrator sets up security for various resources, a particularly adventurous user will get locked out. The user subsequently will complain to management, who then comes to the administrator and asks what is going on. At this point, the admin will have no documentation to support the (well-meaning) security actions that have been taken. Thus, a conflict occurs.

With a written security policy that documents the need for a certain level of Web server security and availability, an administrator is ready to implement the many software tools provided with the operating systems.

IIS security tips
IIS servers are especially vulnerable because of the many weapons designed to target Microsoft products. Knowing that, administrators must be ready to implement a variety of security measures. What I would like to provide here is a checklist that a server operator might find useful.

1. Maintain Windows updates: Staying on top of critical updates and security patches is the easiest security measure to take. Consider downloading updates to a dedicated machine on your network and pushing out the updates to the Web servers from that machine. By doing so, you can prevent your Web server from ever engaging in direct Internet browsing.

2. Use the IIS lockdown tool: There are some nice benefits to this tool. There are some drawbacks, however, so use it cautiously. If your Web server interacts with other servers, test the lockdown tool to make sure it is configured so that connectivity to backend services is not lost.

3. Remove the default Web site: Many attackers target the inetpub folder to drop in little goodies that can bring your server to a screeching halt. One way to prevent this attack is to disable the default Web site that installs with IIS. Then, as surfers try to access your Web site by IP address (as one address in a list of tons of IPs they are hitting in a day), the request will die. Point your true Web site to a folder on a back partition, with secure NTFS permissions (more on NTFS later).

4. Uninstall FTP and SMTP if you don't use them: The easiest way into a machine is via FTP. FTP was designed for easy read/write access, and if you try to implement authentication, you'll find that your usernames and passwords are going across the Internet in clear text. SMTP is another service that allows write access to its folders. By disabling those two services, you'll take away a lot of easy fun for hackers.

5. Check your Administrators group and list of services regularly: One day I came into our classroom and found a new user in our Administrators group. By the time someone has gotten this far into your system, he or she has usually dropped in some little time bomb that either can eventually destroy your system or take up all of your bandwidth for the hacker's use. Hackers also tend to leave behind a helper service. Once that has happened, it is probably too late to do anything but reformat your hard drive and restore from the server backup that you should be making each day. Make it a part of your daily/weekly routine to check the list of services on the IIS server(s) and make sure as few as possible are running. You should memorize the ones that should be there. The Windows 2000 Resource Kit comes with a utility called tlist.exe that lists the groups of services running under each instance of svchost. Running that utility may find some hidden services you need to know about. Here's one hint: Any service with the word "daemon" in its name probably isn't native to Windows and shouldn't be on an IIS server. For a list of Windows services and what they do, click here.

6. Regulate write access to server: This sounds simple, but, on a college campus, a Web server has many "authors." Faculty members want to make classroom information accessible to remote students. Staff members want to share job information with other employees. This can be a nightmare of permission levels for each folder on the server. One way to get around that is to install a second server for share and storage purposes only. Then configure your Web server to point to folders on the share server. This one step can allow an administrator to limit write access on the Web server itself to only the administrators group.

7. Implement complex passwords: I came into a classroom recently and found evidence in the Event Viewer of a would-be hacker. He or she had gotten into our lab domain structure far enough to run password-cracking software on each domain user in alphabetical order. If there were any users with weak passwords (such as "password" or changeme" or any dictionary word), then this hacker would have quickly and easily procured access to those users' accounts.

8. Reduce/eliminate shares on Web servers: If administrators are the only users with permission to write to a Web server, then there is no reason to have any shares. Shares are a great enticement to attackers. Again, by running a simple, looping batch file, a hacker can go down a list of IP addresses with the \\ command looking for shares that have been left open to Everyone/Full Control.

9. Disable NetBIOS over TCP/IP: This is a tough one. Many authors want to be able to access the Web server through the UNC pathname. With NetBIOS disabled, they won't be able to do that. On the other hand, with NetBIOS disabled, hackers won't be able to see resources on your LAN, either. It's a tradeoff. If an administrator implements this tool, then the next step is to educate Web authors on how to engage in Web publishing without NetBIOS available.

10. Use TCP port blocking: This is another tough tool. If you know every possible TCP port that is used to access your server for legitimate reasons, then you can go into the properties of your network adapter card's binding with TCP/IP and block all ports but the ones you need. Use this tool with caution, though, because you don't want to lock yourself out of the Web server, especially if you're accessing it remotely. For the latest listing of TCP ports, click here.

11. Check *.bat and *.exe files regularly: Make it a once-a-week practice to run a search of *.bat and *.exe files to see if there are any executables on the Web server(s) that may be a hacker's delight and your worst nightmare. Among these bad guy files, there may be some *.reg files. If you right-click these and choose "edit," then you can see what registry hacks may have been made that enable a hacker access to your system resources. You can then delete keys that serve no purpose to anyone but the person who infiltrated your system.

12. Manage IIS directory security: IIS directory security allows you to deny specific IP addresses, a subnet, or even a domain name. Alternatively, I use a tool called WhosOn (it costs about $200), which lets me know what IP addresses are attempting to access specific files on a server. WhosOn gives a list of "Exceptions," which are cases where more investigation is needed because, for a variety of reasons, the browser is suspect. Once you find a bad guy trying, for instance, to access your cmd.exe, then you can choose—while you are in the program—to exclude the user from further use of the Web server. Of course, on a busy Web site, this could end up being a full-time job! Keep in mind that the server takes a performance hit when you use these tools, especially when you deny an entire domain name. Name resolution has to happen with each visitor to make sure that the user is not part of the denied domain. However, in the case of an intranet, this tool is invaluable. You can make in-house resources available to all users of the LAN and only a few select others.

13. Use NTFS security: By default, your NTFS drives are open to EVERYONE/Full Control until you lock them down. The key is to not lock yourself out. Everyone should be unclicked for all levels of access. Administrator needs full control, your backdoor admin account (if you have one) needs full control, and System and Services each need a level of access, depending on each file. The most important folder is System32, and as few permissions as possible should be allowed on that folder. Using NTFS permissions on a Web server can help lock down the files and applications that Web surfers do not need to be able to access.

14. Manage user accounts: If you have IIS installed, you probably have a TSInternetUser account. Disable it, unless you really need it. This user is easily infiltrated and is a big target for hackers. To help manage user accounts, make sure your local security policy is as tight as possible. The IUSR should have as few rights as necessary.

15. Audit your Web server(s): Auditing takes a big hit on your machine's performance, so don't do it if you aren't going to check it regularly. If you do use it, audit for system events and add audit tools as you need them. If you are using the WhosOn tool mentioned above, then the auditing isn't as important. IIS is always logging access, by default. WhosOn will turn those logs into a very readable database that you can open via Access or Excel. If you just read the Exceptions database regularly, you will have a really good idea about how vulnerable your Web server is at any given time.