Maintaining Security by Implementing, Managing, and Troubleshooting Service Packs and Security Updates

This chapter is from the book

MCSA/MCSE Implementing and Administering Security in a Windows 2000 Network Exam Cram 2 (Exam Cram 70-214)

Learn More Buy

This chapter is from the book

This chapter is from the book 

MCSA/MCSE Implementing and Administering Security in a Windows 2000 Network Exam Cram 2 (Exam Cram 70-214)

Learn More Buy

Determining the Status of Service Packs and Security Updates

Two Microsoft tools are available to help determine the status of the service packs and security updates on Windows computers: Microsoft Baseline Security Analyzer (MBSA) and hfnetchk.

MBSA

MBSA is a GUI tool that can report the status of several security settings and uses a version of the command-line tool hfnetchk to determine the patching status of a specific machine or an entire network of machines. Reports can be archived, and notes in the reports explain the missing patches or point to Web-based repositories for further information and download. Used on a single machine, MBSA can serve as a diagnostic tool and can update the system. In the version of the tool that is available at the time of this writing, multiple machine updates directly from the tool are not possible.

MBSA also has a command-line version that you execute by typing mbsacli.exe at the command prompt. Table 3.1 describes the command-line switches that can be used with this command.

Table 3.1 mbsacli.exe Command-line Switches

MBSA can be freely downloaded from Microsoft's site. The following sections discuss the requirements for running MBSA, how MBSA works, and how to use the reports that it provides.

MBSA Requirements

In order for MBSA to run, it must be installed on a Windows 2000 or Windows XP computer. It can, however, scan Windows NT 4.0 Service Pack 4 and above, Windows XP, and Windows 2000 computers. (Only local scans can be executed against a Windows XP Home Edition computer or a Windows XP Professional Edition computer using simple file sharing.) In addition, MBSA scans for problems with SQL Server, Microsoft Office, Windows Media Player, Exchange Server 5.5 and 2000, Internet Explorer (5.01 or later), and IIS (4.0 or later) if these applications are present.

The following are additional requirements for running MBSA:

• Internet Explorer 5.01 or greater must be installed, or you must have the XML parser.

• An XML parser (such as MSXML version 3.0, Service Pack 2) is needed. If a system is not running Internet Explorer 5.01 or greater, you need to download and install an XML parser. You can do this during setup.

• IIS common files are needed on the computer on which the tool is installed, if MBSA will be used to scan IIS computers.

In order to use MBSA to scan a computer, the computer must meet the following requirements:

• Internet Explorer 5.01 or greater must be installed.

• The user doing the scanning must have administrative privileges on each computer being scanned, whether the scan is local or remote.

• The server service must be running and Remote Registry Service must be running on Windows 2000 and Windows XP computers.

How MBSA Works

MBSA scans computers for common security misconfiguration problems and hotfix installations. It then reports the results. MBSA uses a custom version of hfnetchk for its hotfix analysis and downloads a current copy of the mssecure.xml file from Microsoft when it is run.

The following parts of the MBSA scan are optional and can be turned off in the interface prior to the scan:

• Windows operation system checks

• IIS checks

• SQL checks

• Hotfix checks

• Password checks

Figure 3.1 displays the MBSA options and shows how a computer can be selected for a scan.

Figure 3.1 MBSA options.

Scan reports are stored on the computer on which the tool is installed, in the %userprofile%\Security Scans folder. Each computer scanned produces its own report.

During the scan, vulnerability tests and security status checks are made (the items marked with asterisks (*) are critical checks):

• Tests for weak passwords by attempting to log on with a blank password, password, PASSWORD, the username, and the administrator name. This check notifies you of any locked out or disabled accounts.*

• Checks for missing service packs or hotfixes.*

• Checks for the number of members in the local Administrators group. If more than two are identified, this fact is listed.*

• Checks to see that all volumes use NT File System (NTFS).*

• Checks to see if autologon is enabled.*

• Tells you whether the guest account is disabled.*

• Checks the setting on restrict anonymous.*

• Checks to see if auditing is enabled.

• Checks the services.txt file (part of the MBSA program) and advises whether these potentially unnecessary services are running.

• Lists the shares available on the computer. It indicates that these shares exist even if file sharing has been disabled.

• Lists the Windows version.

• Checks Internet Explorer security zones and alerts to see if they differ from the defaults. (MBSA will note if your settings are different, even if your settings may be more secure.)

• Checks PowerPoint, Excel, Word, and Access for macros protection.

• Checks the version of Windows 2000 Server.

• Provides an overall security assessment in the form of a risk factor, such as Severe Risk or Low Risk.

MBSA Reports

MBSA reports are used for several things, including the following:

• The overall rating may be used to identify systems that benefit most from security configuration. The higher the overall risk reported, the more work that needs to be done to secure them. You should use caution. You need to weigh the risk factor reported against the role of the computer. In most circumstances, a critical server should be dealt with before a user's desktop, even if MBSA gives the desktop a higher risk factor.

• Each vulnerability assessment can be explored for information on what was scanned, what the results were, and what to do to correct the problems that might show up in the reports. Often, explanations and pointers to further reading allow exploration of the topic. For a small business or for a user with a single desktop system, this might be the only exposure to security issues; therefore, the explanation and steps to improve security are valuable.

• Notification of missing hotfixes is a good indicator of the hotfixes that need to be downloaded and installed. The tool does not provide a way to automate hotfix application updates to multiple systems or to easily apply multiple hotfixes. However, you can use it to download and install one hotfix at a time. The tool identifies each missing hotfix and provides a link to the security bulletin and download path.

• Because scans can be run remotely and reports can be stored at a central location (they are stored on the computer the scan is run from), they can provide a picture of security across a domain or network without requiring a visit to each individual machine. This audit does not need to occur at the same time that the scan is run.

• If old reports are kept, improvement over time can be noted, although there is no automated way to compare report results.

Figure 3.2 displays a portion of a report that indicates the major security checks and the options available for discovering what was scanned and what to do about the results. In this example, the system failed one or more of the critical security checks, resulting in a rating of Severe Risk.

Figure 3.2 An MBSA Severe Risk report.

hfnetchk

The Microsoft Network Security Hotfix Checker, hfnetchk, is a command-line utility that can be used to determine the patch status of a Windows computer. It can be used to examine Windows XP, Windows 2000, Windows NT 4.0, Microsoft SQL Server, and IIS 4.0 and 5.0. It does not display hotfix information for Exchange Server or other Microsoft products. The requirements for running hfnetchk are the same as those for running MBSA.

How hfnetchk Works

hfnetchk uses a combination of approaches to determine whether a security hotfix has been applied. It searches registry keys, checks file versions, and compares file checksums. If the information is missing or incorrect, hfnetchk reports the fix as not being installed. If there is a mismatch (for example, a registry key exists, a file checksum is incorrect), hfnetchk says that the hotfix is not installed and perhaps gives a warning status. In some cases, hfnetchk cannot determine whether a fix has been applied. The information may not be accessible, the fix may be a configuration, or there may be some other action that the tool cannot reliably check. These items are reported as note messages. In this case, a note explains the issue or points to a solution, which in most cases allows the administrator to determine patch status.

When you run hfnetchk, the tool automatically downloads the mssecure.xml file from Microsoft. This file is kept up-to-date and indicates the current hotfix requirements. The date on this file is displayed when you run hfnetchk.

You can run hfnetchk on isolated computer systems (those not connected to the Internet) or on systems that you do not want to access the Internet for this purpose by downloading a copy of the mssecure.xml file to another computer, placing a copy on the isolated computer, and using the –x switch. When hfnetchk is run using the –x switch, it does not attempt to access the file on Microsoft's site; it instead uses the local copy of mssecure.xml.

By default, hfnetchk requires access to the Internet in order to access information on the most recent updates. However, a copy of the update file can be downloaded from Microsoft from a computer that you use to access the Internet and then used on computers that do not have Internet access. The mssecure.xml file can reside on the local computer system, a network share, or an intranet Web site.

To use a local network share, you use this command:

hfnetchk –v –z –x s:\security\mssecure.xml

In this command, s:\security\mssecure.xml is the local path to the file.

To use an intranet site, you use this command line:

hfnetchk –v –z –x http://mysite.abc/mssecure.xml

In this command,

http://mysite.abc/mssecure.xml

Many other switches are available, as listed in Table 3.2.

Table 3.2 hfnetchk Switches

The following command line, for example, uses a local copy of mssecure.xml and puts the output in tab-delimited form in the scan.txt file. It also disables registry checks and lists the specific reason for the failed check:

hfnetchk –v –z –x mssecure.xml –f scan.txt -otab 

hfnetchk Requirements and Common Usage Mistakes

When hfnetchk was first released, a large number of problems were reported. Fortunately, most of them could be traced to two factors: Administrators were not accustomed to command-line tools, and administrators did not read the documentation. Using and troubleshooting hfnetchk is very simple if you understand these issues. First, the administrator must understand that clicking the executable in the GUI does not run the program. The administrator must use the command line and add switches and the appropriate values. Second, if the administrator reads the documentation, he or she will find that several requirements must be fulfilled. Understanding these requirements and making sure they are met will prevent most common problems from occurring. Finally, reading the report and the documentation it lists for further guidance will answer many common questions. Table 3.3 lists hfnetchk requirements and common problems as well as their resolution or where to find additional information.

Table 3.3 hfnetchk Problems and Requirements