Administering the Server

Many developers are clueless about any of the responsibilities of administering a server. The reasoning is that a good developer can write secure programs without learning these administration tasks by using good coding practices. The fact that many of the security tools in use today don’t work and many applications circumvent reasonable security measures points to the fact that this line of reasoning is absurd. A good developer not only employs the best coding practices, but also understands how the application and its security features work in the Web environment. In short, you don’t have to be a perfect administrator, but you have to know the tools an administrator uses and understand how they work. This section provides an overview you can use for further exploration of the administration side of your Web server.

Tip

The numbers of types of threats to Web servers increases daily. The task of classifying these threats so that you can do something about them can quickly get out of hand. Microsoft provides a convenient method of classifying most server threats using the acronym STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege). Learn more about this technique at http://msdn.microsoft.com/library/en-us/vbcon/html/vbconOverviewOfWebApplicationSecurityThreats.asp.

Microsoft is attempting to provide tools and checklists that network administrators and developers can use to secure their systems. Part of the problem is that many of those who are responsible for maintaining security don’t know the tools exist, don’t know how to use them, or don’t use them often enough to make a difference. Of course, the other part of the problem is that Microsoft often fails to admit to bugs in their products and refuses to acknowledge security problems until the issue is painfully obvious to everyone. However, Microsoft does provide a list of tools and checklists that you should consider at http://www.microsoft.com/technet/security/tools/tools.asp.

Using the Microsoft Baseline Security Analyzer

The Microsoft Baseline Security Analyzer (MBSA) helps you locate, categorize, and track security problems on your server or development machine. This tool can scan one or more machines during a single session. Microsoft has mixed new functionality with existing tools in this product and performed the task well. You can find MBSA at http://www.microsoft.com/technet/security/tools/tools/mbsahome.asp.

When you start MBSA, the tool will ask whether you want to scan a single or multiple machines. Figure 9.5 shows a typical example of the single machine scanning setup. To scan a single machine, you choose a specific machine name or enter an IP address. It’s also important to check the scanning options. It’s usually best to scan for all vulnerabilities because the check on a single machine doesn’t take very long.

Figure 9.5: Select the identity and scanning options for the test system.

Scanning multiple machines means telling MBSA specifically what you want to scan. For example, you can type a domain name or a range of IP addresses. Typing a domain name means that MBSA will scan every machine in the domain, which can require a substantial amount of time. Selecting an IP address range is reasonable only if you know the current addresses of the machine—depending on how you set your server up, these addresses could change. If I’m only concerned about the two machines I’m using for development, I normally perform two single scans. Once you choose the identity of the machines that you want to check, you can select from the same options shown in Figure 9.5. It’s often more efficient to select specific options when scanning multiple machines, rather than perform the entire test.

After you select the machine identity and options you want, click Start Scan to begin the scanning process. Figure 9.6 shows typical output from this program. You might be surprised at the number of security problems your development server and workstation have.

Figure 9.6: Typical output from MBSA after a security scan

MBSA also includes a command line interface through MBSACli.EXE so you can use it within scripts. The default setup uses command line features that emulate the standard MBSA interface. If you don’t select a particular feature, then MBSA will choose defaults. For example, if you type MBSACli alone, the program will perform a complete check of the local system.

Note

MBSA tries to download a copy of the MSSecure.XML every time you start the program. If MBSA can’t find an Internet connection or it can’t contact the Microsoft Web site for some reason, the program will still work, but the results could be outdated. The best policy is to run the scans from a machine with an active Internet connection so MBSA can provide the latest results.

In many respects, MBSA overlaps the functionality provided by another tool, HFNetChk (see http://www.microsoft.com/technet/security/tools/tools/hfnetchk.asp for details). If you want to emulate the behavior of the older HFNetChk tool, you can use MBSACli /hf in the script file. MBSA can use any HFNetChk command line option, which means MBSA is extremely flexible.

Using the IIS Lockdown Tool

One of the tools that you’ll see mentioned as part of your MBSA scan is the IIS Lockdown Tool. This tool helps you reconfigure your system for maximum security. It uses a number of templates to automate the task, or you can choose to perform the process by answering questions.

When you start the IIS Lockdown Tool, it asks you to agree to the usual licensing statement and then displays a list of templates similar to the ones shown in Figure 9.7 if it detects a copy of IIS on the local machine. Unlike MBSA, you must run the IIS Lockdown Tool on the host machine.

Figure 9.7: The IIS Lockdown Tool uses templates to make the configuration process easier.

Notice the View Template Settings option at the bottom of the dialog box in Figure 9.7. It usually pays to check this option so you can validate that the template settings are going to work for your system. When you select this option, you see a series of screens such as the one shown in Figure 9.8. The screens take a while to read and verify, but you’ll receive better results from the configuration if you take the required time.

Figure 9.8: Use the supplied template screens to customize the template configuration.

The IIS Lockdown Tool also offers to install URLScan (see http://www.microsoft.com/technet/security/tools/tools/urlscan.asp for details). Essentially, this tool uses a rule base to block harmful requests from reaching the server. In general, if you install URLScan on your production systems, you should also include it on your development machine. The fact that this tool blocks certain requests means that you could run into situations where an application works fine on a development machine, but doesn’t work at all on the production system. An URLScan problem can prove difficult to find because the tool blocks the request before it reaches the Web server. Consequently, many of the troubleshooting techniques you normally use won’t work (including remote debugging).

Once you decide on the various settings (including the URLScan installation), the IIS Lockdown Tool displays a summary of the tasks that it will perform on your system. Use the Back button to change any settings that don’t appear to fit within the security guidelines for your company. Click Next to begin the lockdown process. The IIS Lockdown Tool displays status information as it completes the task. At some point, the process will complete—simply follow the prompts to finish the process.