Taking the First Step: Patch Management

Microsoft is spending a lot of time and money to increase the security of its products. Nowhere is this investment more visible than in Windows Server 2003, which includes a host of security improvements that I m not going to discuss in detail here. However, these efforts also include a vigorous program of identifying and fixing security problems (and plain old bugs ), then releasing patches that you can apply. These efforts by Microsoft to build patches and get them to you don t do any good unless you take the time to keep your systems patched. Microsoft had a number of large enterprise customers that were unaffected by Slammer, CodeRed, and Nimda. Why? Because these customers took the time to secure their systems, including locking down access control lists (ACLs) on system files, removing unnecessary services, and installing security patches when the patches were released , not after the attacks had started. For a relatively small investment of time and effort, you can gain a great degree of security. That s why I cover patch management first ”good security policies and great intentions are worthless if you have unpatched vulnerabilities on your servers!

Where Patches Come From

Before discussing the details of patch management, let me briefly digress to describe how patches are created and distributed. During the Windows 2000 Server development process, Microsoft launched an internal program called the Secure Windows Initiative (SWI). The goal of SWI was to strengthen Windows security by cleaning up past implementation flaws in Windows components , as well as instituting new policies and procedures to help reduce future flaws. Concurrently, Microsoft beefed up the staffing and authority of the Microsoft Security Response Center (MSRC), the folks who write the security bulletins Microsoft uses to tell us about new vulnerabilities or patches.

Patches are created to address specific vulnerabilities. These vulnerabilities can be identified through several methods :

• Internal efforts (one example is the early-2002 security push that took all 8,500 Windows developers away from new product development to focus on bug fixing)

• Customer reports (Microsoft averages more than 500 e-mail reports a month, many of which are duplicates or the result of configuration problems)

• Reports from external researchers, or even black hats, on public security mailing lists and discussion forums

No matter the source of the report, when a vulnerability is reported the MSRC studies it to figure out whether it s really a vulnerability. (More than 98 percent of the reports they get are duplicates or bogus .) If the vulnerability is real, and not the result of a configuration issue, the MSRC prioritizes the flaw according to its seriousness and works with the development team to build a fix for it. For serious flaws, Microsoft will immediately issue a security bulletin covering the issue in detail and discussing workarounds or alternate protections . For flaws that can be quickly patched, the bulletin and patch are released at the same time.

Note  

To read an interesting document that explains in great detail how the MSRC works and what they do, visit http://www.microsoft.com/technet/ columns /security/ essays /sectour.asp .

Once the patch is completed, it s made available in several ways: through the Windows Update and Software Update Services Web sites (more on those in a minute), through direct download from the Microsoft download center, and through direct distribution to customers who ve purchased Microsoft Premier or Alliance Support agreements. Critical fixes might be released as quick-fix engineering (QFE) patches, better known as hotfixes. Hotfixes differ from regular security patches in that they undergo hundreds of hours of testing, not the thousands of hours that go into complete service packs ”but if the flaw is dangerous enough, an immediate fix that hasn t been completely regression- tested is much better than no fix at all.

Note  

If you know what an RSS aggregator is, you ll be happy to know that at least one company (Thundersite) is providing a Really Simple Syndication (RSS) feed listing the most recent downloads at the Microsoft Download Center. Point your aggregator to http://www.thundermain.com/rss/ .

No matter how you get the fix, you re still stuck with the task of testing the patch in your environment and deploying it on your systems. However, before you can do that, you must decide which systems need which patches ”a process that begins with the risk assessments you should have done after reading Chapter 4, Threats and Risk Assessment, and Chapter 5, Physical and Operational Security.

Figuring Out What Needs Patching

In a perfect world, there would be no need for security systems or patches ”code would be perfectly secure, and no one would ever attack computer systems. The next -best scenario would be to have each system that required a patch alert us that a patch was necessary ” sort of like the Check Engine light in your car. Unfortunately, we don t live in a perfect world, so it s up to us as administrators to track which systems need to be patched and then get the job done. This can be a huge hassle, especially when dealing with large numbers of machines, but it s a crucial task. Failing to patch one machine can make the entire network vulnerable! An attacker needs to find only a single weak spot in your defenses to gain entry, so you have to close every entry point for an attack. Fortunately, Microsoft is shipping free tools that reduce this hassle by letting you know what needs to be patched and helping you patch it.

Note  

Remember, patching is just the first line of a solid defense in depth . Your defensive strategy should also include components such as strong password policies, reducing the surface area of your servers by disabling unnecessary components, firewalls, access controls, and encryption systems. Defense in depth makes things much harder for an attacker, because penetrating one layer of security doesn t give him or her entry to your whole network.

Stop, Drop, and Bulletin!

It s tempting to get your security news from mass media outlets ”that way, you can find out about new security holes as you check the stock market s performance and find out which Hollywood stars are abusing which substances. However, you ll be better off getting your security advisories from a more trustworthy (and technically accurate) source than the New York Times , CNN, the Wall Street Journal , or sites maintained by random Internet publishers (many of whom regularly amplify rumors or half-facts into full blown controversies), all of which have flubbed security disclosures in the past. What source do I recommend? Microsoft.

The MSRC-produced bulletins are available for free from a number of sources. The Microsoft bulletin site ( http://www.microsoft.com/technet/security/current.asp ) is the most authoritative , and it allows you to subscribe to a service that e- mails new bulletins to you as soon as they re released. A surprisingly small number of administrators use the service, which means that many people are missing out on a free, simple way to get immediate notification of new bulletins ”don t be one of them! A number of reputable security- related mailing lists (including NTbugtraq and Bugtraq) republish and rebroadcast these bulletins, often with commentary providing more detail on the threat level. However, this additional commentary sometimes delays the bulletins arrival in your inbox, and the mail-list processing strips off the Pretty Good Privacy (PGP) signature you would normally use to verify the bulletins authenticity.

Why am I interrupting the chapter to tell you all this? Because it s important. Right now, put this book down and go sign up to receive security bulletins through e-mail . Signing up only takes a short time and virtually guarantees you won t be taken unaware by future problems.

 

Security bulletins tell you which version of the product needs to be patched (for example, Exchange 2000 Server with Service Pack 2, Windows 2000 Server with Service Pack 4, and so on). They generally don t tell you which specific files or services need fixing, but that isn t particularly useful information anyway. (If you re interested in those details, check the associated Microsoft Knowledge Base article released with the patch ” that s where the file-by-file details reside.) You can check the version information for individual dynamic-link libraries (DLLs) or executables by opening the file s properties in Windows Explorer and clicking the Version tab. However, this is about as much fun as eating sand, particularly when you don t know which files need to be patched ”and you won t! The best way to scan systems to ensure they have the right patches is to use the Microsoft Baseline Security Analyzer (MBSA), which I ll discuss in a moment.

Tip  

The easiest way to know which version of Exchange a server is running is to open Exchange System Manager, select the Servers container in the server s Admin group , and look in the right content pane ”the server version will be clearly displayed. For example, a machine running Exchange Server 2003 RTM will show up as Version 6.5 (Build 6944.4).

Using the Microsoft Baseline Security Analyzer

The MBSA is a security scanning and analysis tool that checks for a wide range of vulnerabilities, from configuration mistakes to missing hotfixes and patches. It can scan a single machine or a range of Internet Protocol (IP) addresses (although it can check only machines to which you have administrator access), and it produces a variety of useful reports. Figure 6-1 shows a sample report produced by scanning my Microsoft Windows XP Professional laptop ”note that MBSA flagged a hotfix whose presence it couldn t confirm, but everything else is solid.

Figure 6-1: This machine came out looking like a winner after its MBSA scan.

Note  

As of this writing, MBSA is at Version 1.2. Version 1.0 checks the configuration of Microsoft SQL Server 7.0, SQL Server 2000, Information Server 4.0, Internet Information Server 5.0, Windows NT 4, Windows 2000 Server, Windows XP, and desktop applications (Microsoft Internet Explorer 5.01 and later versions, Microsoft Office 2000, and Office XP). MBSA version 1.1.1 adds support for scanning Windows Server 2003, Microsoft Exchange 5.5, and Exchange 2000 Server; it also checks for security updates to Microsoft Windows Media Player 6.4 and later. Version 1.2 adds a new version of the HFNetChk engine and provides support for scanning Exchange 2003, BizTalk, Office, MSXML, and a few other products.

The scanning and comparison process is driven by an Extensible Markup Language (XML) file, Mssecure.xml, that contains a list of all existing patches. When you launch MBSA, its first task is to see whether there s a newer version of the XML file available from Microsoft. If so, MBSA downloads it from the Microsoft public site. Once the most recent patch list has been loaded, MBSA can begin checking for missing security updates. Actually, it checks several distinct areas:

• Known Windows vulnerabilities These vulnerabilities include the use of file allocation table (FAT) file systems, too many local Administrator accounts, enabled Guest accounts, and so on. Note that this scan is looking for configuration mistakes that lead to vulnerabilities, not the presence or absence of specific patches. As a bonus, the scanner can check for configuration vulnerabilities in Internet Explorer 5.01 and later versions.

• Missing security updates This scan compares the list of hotfixes you should be running (according to the defaults included in Mssecure.xml) to the list of hotfixes actually installed on the target machine. All hotfixes are weighted equally, so a patch to a service you don t run will still show up with a red X if you don t install it. You ll have to perform your own risk assessment to ensure MBSA s recommendations are appropriate for you. The scanner can scan Windows NT 4 (Service Pack 4 or later), Windows 2000 Server, Windows XP, and Windows Server 2003 systems (although the scans of Windows XP Home computers are somewhat more limited than the others). However, it runs only on Windows 2000 Server and later systems.

  How does MBSA know whether a particular patch is installed? It makes that decision based on three factors. The first factor is the registry key that each hotfix adds to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates key. This registry key is enough to indicate whether a particular hotfix has ever been installed, but it doesn t indicate whether it s still installed ”it s possible for the updated files to be overwritten after the hotfix is applied. Worse, there have been cases in which one hotfix accidentally tromps on the Updates key for another, so this method isn t completely reliable by itself. Because hotfixes are sometimes revised after release, MBSA also checks the version of the files installed by the hotfix. As a third check, it computes a checksum of the installed patch and compares it to the corresponding checksum in the patch list. This check prevents an attacker from depatching a computer by reinstalling an old version of a patched component. If the registry key, checksum, file versions, or file dates of an installed patch don t match the patch list, MBSA flags the patch as missing.

• Weak account passwords In this context, weak refers to passwords that match the username, a few well-known words (such as administrator and password ), or blank passwords. This quick check is useful, but it s no substitute for enforcing a strong password policy. This check doesn t mount a full dictionary attack, although you should certainly consider doing so on your own to sniff out dictionary-based passwords.

• Internet Information Services (IIS) vulnerabilities This scan checks whether IIS Lockdown has been run on the machine by looking for the configuration files that IIS Lockdown leaves behind, as well as by looking for potential danger points such as the existence of exploitable IIS samples or parent paths. The scanner works against IIS 4 and later.

  Note  

  The Oblt-log.log files are what allow IIS Lockdown to uninstall itself and restore the settings you had in place before it was installed. Removing them means you lose the ability to uninstall, but it also denies an attacker a potential way to learn what security changes you ve made.

• SQL Server vulnerabilities The SQL scanner checks for common vulnerabilities in SQL Server 7.0 and SQL Server 2000, including the notorious blank SA password. If there are multiple SQL instances on the server, they ll all be scanned.

• Exchange Server vulnerabilities The Exchange scanner checks Exchange 5.5, Exchange 2000 Server, and Exchange Server 2003 to make sure that they have the correct set of security fixes.

  Note  

  Sharp-eyed users will probably notice that there s no separate check box for Exchange scanning. MBSA 1.1 and later do check Exchange for security hotfixes and proper configuration settings, but inexplicably there s no option in the MBSA graphical user interface (GUI) to control whether Exchange gets scanned or not: if you run MBSA against an Exchange server, Exchange will be scanned, period.

It s worth noting a few things that MBSA doesn t do. First and foremost, MBSA is a read-only tool ”it does not configure or change any machine settings during or after a scan. It does not use dictionary lists to detect passwords that could be cracked by brute force attacks. It only checks for the most commonly occurring vulnerabilities publicly announced by Microsoft. Even though Microsoft has been very diligent about keeping MBSA up to date, new exploits against particular services or configurations won t be scannable until the Mssecure.xml file is updated, which usually happens when the hotfix that closes the vulnerability becomes available.

Downloading and Installing MBSA

MBSA itself is packaged as a Windows Installer (.msi) file you can obtain from http://www.microsoft.com/technet/security/tools/Tools/MBSAhome.asp . Any user who has the ability to install programs can install MBSA; however, you can scan only the machines on which you have administrative rights, and that includes the local machine. This restriction is an important safety feature; because MBSA can scan IP ranges and domains, you wouldn t want anyone using it for nefarious purposes.

To install the product, just download the package to your local computer, saving it somewhere that you can find it again. Alternatively, when your Web browser asks whether you want to open or save the file, you can choose to open it to install the package without saving it locally.

Because MBSA is built as a Windows Installer package, you can make it available through Active Directory Group Policy Objects (GPOs). Doing so allows you to automatically install the tool on multiple computers. This can be useful in circumstances in which you don t have, and can t get, administrative access to every machine. Use MBSA in multiple-computer mode to scan machines you do have access to, and then install it locally on the others so that the local administrators can scan for flaws themselves .

Installation is simple: you are presented with a summary page and then the ever- popular end user license agreement page (EULA). Once you ve agreed to the EULA, you ll be asked to personalize MBSA with your name and organization, and to choose whether you want MBSA to be available to everyone on the computer or just to the account you re installing it with. Consider this question carefully . If an attacker actually gets on your machine and can elevate his or her privileges to admin level to run MBSA, he or she might be able to get a list of all of the potential vulnerabilities in your domain ”because administrators often configure systems identically (or close to it). This information could be very useful to an attacker. For this reason, we recommend that you restrict MSBA access to essential people only. After indicating your preference, there are a few more pages to click through ”including one on which you specify the install location ”but they re so simple there s no real point in discussing them.

Running MBSA

Once MBSA is installed, you re ready to run it. MBSA contains both a command-line interface (Mbsacli.exe) and a GUI (Mbsa.exe). The first time MBSA is launched (using either the shortcuts it installs or by running either of the mentioned executables), it attempts to download the current version of Mssecure.xml over a local Internet connection. It does so by contacting the Microsoft Download Center Web site and downloading a digitally signed .cab file that contains a compressed version of the XML file. After verifying the signature, the .cab file is decompressed and the local copy of the XML file is used until the next time MBSA is launched. Each time you run it, the tool checks the Download Center to see whether a newer version of the XML file is available. This might cause you to see notifications like the one shown in Figure 6-2, indicating that a new version of the .cab file is being downloaded.

Figure 6-2: If you have good security settings in Internet Explorer, you ll be notified whenever a signed ActiveX component or .cab file is downloaded.

Note  

If your network requires the use of a proxy server, MBSA might not be able to download Mssecure.xml. You can always download it manually from http://download.microsoft.com/download/xml/security/1.0/nt5/en-us/mssecure.cab . If you download the file manually, you ll need to move it to the MBSA installation folder, which is also where the uncompressed file ends up.

Starting a Scan

When you first launch MBSA, you ll see a window with three choices:

• Scan A Computer allows you to scan a single machine. You can specify its IP address, its machine name, or a combination of its name and the name of the domain it s in. You can specify a format for the name of the generated scan report. MBSA defaults to a combination of the domain, the machine name, and the scan date. All MBSA reports are stored in the SecurityScans folder in the currently logged-on user s profile directory.

• Scan More Than One Computer allows you to specify a range of IP addresses to scan, along with a domain. (See Figure 6-3.) MBSA pings each machine in the range you specify. Machines that respond to the ping will be scanned, though of course, non-Windows machines will ignore the scan requests . MBSA can scan up to 20 machines concurrently. Microsoft recommends that for performance reasons you include no more than a few hundred machines in a single scan. As with the one machine scan, you can change the way MBSA generates names for the saved reports. Some customization here can help you keep track of which machines in which domains were scanned. Because all the reports will by default go in your profile directory, you might want to use a script to periodically move them to a safer location so that you can archive and analyze them. (This is an ideal application for the Systems Management Server [SMS] Feature Pack if you re using SMS.)

  
  Figure 6-3: The MBSA scanning interface is very straightforward.

• View Existing Security Reports allows you to view the results of previous scans. You get a nicely formatted list of scan reports, sorted by computer name, IP address, scan date, or risk level. Each individual report is stored as an XML file in the MBSA installation directory. MBSA displays the reports in a nice-looking format (which is great, because even nontechnical users can scan their machines and get understandable results), but the real win here is that because the files are XML, you can easily write code to parse them however you like. For example, it would be simple to write a script that would load each file in the directory and parse it, sending you e-mail with a list of all machines that hadn t been scanned in the last seven days and all machines with any missing hotfixes.

Choosing Scan Options

The five check boxes on the Pick A Computer To Scan and Pick Multiple Computers To Scan pages are simple to understand: all they do is implement the scan types I described earlier. If you want to scan a machine for SQL problems, make sure the Check For SQL Vulnerabilities check box is selected, and so on for the other check boxes. Remember, because MBSA checks for weak passwords by attempting to change passwords for each account, the weak password check can take a long time on machines with lots of accounts, such as domain controllers. That s no excuse not to run the test, though!

Note  

Checking for blank or nonexpiring passwords is really important, which is why MBSA does it. You should run such a scan as soon as you can to flag accounts that might be vulnerable to compromise. After you fix them, scan again to verify the fixes. Once MBSA reports no problem accounts, you can run the other scans without a password test; however, you should still run a password test periodically to catch any infractions.

Editing Services.txt

As part of the Windows vulnerability test, MBSA checks for unnecessary services. The goal of this check is to get you to turn off every possible service, because services that aren t running cannot be compromised (think of this as the principle of least services ). You can customize the list of services that MBSA checks for. By default, it only includes five services: File Transfer Protocol (FTP), IIS, Simple Mail Transfer Protocol (SMTP), Telnet, and the Remote Access Services (RAS) manager ”none of which are necessary on standard member servers. However, the configuration for Exchange will of course be somewhat different, as you ll need to have IIS and SMTP running on Exchange servers, along with the Exchange services themselves. You can customize Services.txt so that it checks for the proper set of services on your Exchange servers. As you ll learn in Chapter 14, Securing Outlook Web Access, front-end servers can get by without many of the conventional Exchange services, and all Exchange servers can do without some of the standard Windows services.

Note  

The Windows Server 2003 Security Guide ( http://go.microsoft.com/fwlink/?LinkId=14845 ) provides a comprehensive list of Windows Server 2003 services, explaining what each service does and when it s OK to turn it off. You should read it and apply its recommendations for reducing the attack surface of your servers.

Using MBSA From the Command Line

MBSA s scanning has always been based on the HFNetChk engine (a commercial version of that same engine, with several useful added features, is available from Shavlik Technologies, at http://www.shavlik.com ). When MBSA was first released, it had some command-line options, but its primary value was in the fact that it provided a graphical interface, more detailed reporting, and the ability to scan multiple machines. HFNetChk had many more command-line switches, making it the tool of choice for command-line scanning.

Tip  

The Security Operations Guide for Microsoft Windows 2000 Server (Microsoft Press, 2002) contains some useful HFNetChk scripts that can easily be adapted for use with MBSA and Exchange 2003.

With the release of MBSA 1.1, Microsoft has unified the two tools. You can still use MBSA as described earlier if you want a GUI interface. If you prefer a command- line interface, you get not one, but two choices: you can use the original set of MBSA command-line switches or the ones from HFNetChk. In either case, you run the Mbsacli.exe tool and specify the options you want. The next two sections describe these switches; the only thing to remember before reading them is that you must include the /hf switch in your command line. This switch tells MBSA that you re using the old-school HFNetChk format for your commands.

MBSA Command-Line Switches

Table 6-1 shows the MBSA command-line options. These options simplify the process of using MBSA from the command line, although they don t eliminate the need for you to understand how to use the command-line interpreter.

Table 6-1: MBSA Command-Line Options

Command-Line Switch	What It Does	Notes
/c domainName\ computerName	Scans the named computer only.	Use this switch to specify a single remote computer to scan.
/d domainName	Scans all computers that are members of domainName .	Use this option to scan all member computers in a domain (provided that the account you re using has appropriate privileges).
/e	Shows all errors found in the latest scan.
/f "filename"	Redirects MBSA s output to the specified file.	MBSA will always produce a report file. This switch controls where its progress information goes.
/i ipAddress	Scans the specified IP address.
/l	Lists all reports in the SecurityScans folder of the logged-in user s profile directory.	Use this option to see which reports are available (and thus when scans were run in the past).
/ld "reportName"	Shows the detailed version of the specified report. The detailed version includes descriptions of each reported problem and its meaning.
/lr "reportName"	Shows abbreviated overview of the report named reportName . The overview only summarizes those problems that were found.
/ls	Lists reports associated only with the latest scan.
/n scanType	Skips the specified scan type: Hotfix , IIS , OS , Password , and SQL are valid scan types. These can be concatenated (for example, "/n IIS+SQL" skips SQL and IIS checks on the target machines).
/O "filenameTemplate"	Specifies the format of report file names. You cannot include a path , but you can include static text and the %domain% , %date% , and %computername% variables . (Note that the %date% variable produces reports with slashes in their name, which causes problems for a number of command-line tools and scripts.)	If you re going to use this option, make sure you use it on all machines so that all reports, domain-wide, follow a common standard.
/qX	Be quiet! /q suppresses all output. /qp hides progress information, /qe suppresses errors, and /qr doesn t list reports.
/r "startIP - endIP"	Scans all computers in the range between startIP and endIP . Don t forget the dash between the two addresses!
/sus URL	Tells MBSA to verify that the computers being scanned have all of the patches approved for release by the Software Update Service (SUS) server at the specified URL.	This option makes it easy to verify that your machines have the correct set of patches as staged on your SUS server.

Using HFNetChk-Style Command-Line Switches

The HFNetChk style of command-line options give you somewhat more flexibility than the MBSA-style options, at the cost of learning a more complicated syntax. You can use these options by specifying the /hf switch, followed by the switches you want to use. Because the MBSA GUI does a lot of the work for you, don t be surprised if your HFNetChk-style command lines are longer than their MBSA equivalents.

Choosing Which Machines to Scan

The first step to using HFNetChk-style command lines with MBSA is specifying which machines you want to scan. You can scan individual machines, lists of machines, or ranges of IP addresses. The options that accept lists require you to create a file with one machine IP address or NetBIOS name per line, with no more than 256 entries in each file. Here s how to specify which machines get scanned:

• -h hostname This switch scans the host with the NetBIOS name hostname.

• -fh hostListPath This switch scans the hosts whose NetBIOS names appear in the file specified by hostListPath .

• -i ipAddress This switch scans the host at the specified IP address.

• -fip hostListPath This switch takes the list of IP addresses in the specified file and scans each machine.

• -r startIP-endIP This switch scans all machines in the inclusive range between startIP and endIP .

• -d domain This switch scans all member computers in the named domain. You can specify a NetBIOS domain name or a DNS-style name.

• -n This switch scans all hosts that are visible in Network Neighborhood.

Controlling the Scanner s Behavior

The HFNetChk engine has many switches that can be used to tweak the scan settings; in HFNetChk mode, MBSA can use these, too. The most useful of these are probably “Z, which suppresses checking the registry of remote machines for hotfix information, and “nosum, which tells MBSA not to compute checksums for files it scans.

The “b switch performs a baseline check: it scans for the minimum required set of hotfixes, as described by the MSRC. Using “b is a good way to get a quick read on the security level of a group of machines (for example, your Exchange servers) without taking the time to do a complete scan.

There are some other useful miscellaneous switches, too. The “x dataSource switch specifies a Uniform Resource Locator (URL) or path name for a .cab file or XML file containing the patch list. By default, Mbsacli.exe always fetches the Mssecure.cab file from http://download.microsoft.com/download/xml/security/1.0/NT5/EN-US , but you can override this (perhaps editing the file to include information on patches for installed applications). The “u and “p switches let you specify a username and password to use when connecting to remote machines. If you use “u, you must also specify “p; the program won t prompt you for a password like net use does.

Finally, you can control the number of concurrent threads used to perform multimachine scans with the “t switch, up to a maximum of 128 (for example, “t 96 bumps the thread count from the default of 64 up to 96).

Controlling Reporting

MBSAcli s reports are much less attractive than those produced by the full MBSA tool, but you get more flexibility in customizing them. The first step is understanding the difference between a NOTE message (information that s nice to know but perhaps not critical) and a WARNING (which means, fix this or you ll be sorry ). By default, MBSAcli produces both types of messages. The “s switch takes either 1 or 2 as arguments: “s 1 hides all NOTE messages, and “s 2 hides NOTE and WARNING messages ”useful for scans in which you want a simple informational summary of your systems state.

The “f switch redirects output to a file that you specify. This switch is obviously useful when running MBSA in batch mode. (The commercial version of HFNetChk Pro can also produce XML output directly, a useful feature if you want to build scripts or code that processes the reports.)

By default, MBSAcli doesn t explain why it thinks a particular patch is missing or invalid. If you specify the “v switch, which puts MBSAcli in verbose mode, each NOTE or WARNING is accompanied by an explanation of why the patch is tagged as missing. For example, this output explains exactly why a certain hotfix is marked as missing:

 Patch NOT Found MS02-008        Q318203 File C:\winnt\system32\msxml3.dll has an invalid checksum and its file version is equal to or less than what is expected. 

MBSAcli reports are normally formatted for humans to read; they re nicely word- wrapped. However, if you re running the tool to get a set of data that you can process with a macro or script, it s more useful to be able to get tab-delimited output. The “o switch controls this; “o tab produces tabular output (for each machine, the machine name, security bulletin number, Knowledge Base article number, and reason are listed), whereas “o wrap produces word-wrapped reports.

A Few Useful Examples

To get a sense for what you can easily do with MBSAcli, here are a few sample commands to help you get started:

• MBSAcli -hf -b -n does a baseline scan of all the machines your computer can see on the network. Note that because HFNetChk depends on Windows name resolution, it might attempt (and fail) to scan computers that aren t currently on your network.

• MBSAcli -hf -fip exchServers.txt -b -s 1 -f auditFile.txt takes a list of the IP addresses of your Exchange servers and runs a baseline scan on them, saving the results to AuditFile.txt. This would make a terrific scheduled task for you to run against your servers.

• MBSAcli -hf -fh exchServers.txt -u adminAccount -p mySecretPassword -f exchange-08-02- 02.txt scans the specified list of Exchange servers using the administrative account and password, redirecting the results to a file. (Why is this useful? Well, you shouldn t be logged in as an administrator for ordinary tasks ” remember the principle of least privilege!)

Automating Patch Distribution

The topic of how to get patches (or other software, for that matter) distributed to the right place at the right time is worthy of a book on its own. There are several methods available; which ones you use will depend on how many machines you have to manage and how much time you have to manage them.

Tip  

Many administrators prefer to install operating system and application service packs on test machines first to see if they cause any problems. This is a sensible approach, and I endorse it ”as long as you actively check for problems and move to install the service packs on your production machines within a reasonable timeframe. Most sites test for a maximum of about two weeks, although you can lengthen or shorten the interval depending on your specific site s needs. Don t be like the many sites that skipped installing Service Pack 3 for Exchange 5.5 because they were trying to freeze their configurations for Y2K!

The tried-and-true method of patch distribution for small numbers of machines, of course, is just to apply patches manually. As long as you have a small number of servers and are diligent about applying patches when they re released, this might not be a bad option. However, what happens if you re on vacation and a critical patch hits the streets ? Will anyone else install it? What if you have a patch that has to be installed on every machine on your network? How long will it take to deploy?

The next step up is the Windows Update service that Microsoft offers. On the plus side, Windows Update is easy to use and is supported by Microsoft Windows 98 and later. Unfortunately, it still requires users to install things manually. In fact, the wide range of non-patch-related stuff (including Microsoft Windows Media Player, MSN Messenger, device drivers, and various beta versions of software that you might not want on your servers) is often a fatal temptation to users, and might make an administrator s job more difficult. Windows Update is still quite useful for updating small numbers of machines, as long as you can control who performs the updates and when. Because it s free, and because it s part of the operating system, it s always available, and that can make it a handy solution for some situations. (Of course, by using Active Directory GPOs, you can turn off Windows Update for machines in a selected site, domain, or organizational unit [OU].)

Using the Microsoft Software Update Services

Shortly before the release of Windows 2000 Server Service Pack 3, Microsoft released the Software Update Services (SUS) package, a radical upgrade to the Windows Update engine. Where Windows Update was originally targeted at individual users of any of the Windows family of operating systems, SUS is targeted squarely at medium- sized corporate and institutional networks that are using Windows 2000 Server, Windows XP, and Windows Server 2003 as their base operating systems. Since then, they ve released Service Pack 1 for SUS 1.0, which is the version I ll talk about in the remainder of this section.

The basic idea behind SUS is simple: it s designed to quickly deliver critical updates to machines inside your firewall. It does this by allowing you to set up a synchronization server on your network that periodically synchronizes itself with the master Windows Update catalog. This master server downloads critical updates and makes them available on your internal network (see Figure 6-4). As an administrator, you control which updates are copied to the synchronization server and when they re released to servers and desktops on your network. Those servers and desktops, in turn, can pull updates from your intranet s SUS servers (think of these machines as your own personal Windows Update machine) on a schedule you specify. You can set up a single SUS server that all clients use, or you can have a single server that pulls critical fixes from Windows Update and distributes them to a set of staging servers, from which clients get updates.

For example, you can set a schedule that tells the SUS client on your Exchange servers to automatically download and install any needed updates at 2 A.M. local time each day, rebooting if necessary. If you re the hands-on type, you could set a policy that would allow the Exchange servers to download the patches so that you could install them yourself.

Note  

If you prefer, SUS can be set to automatically install patches. However, you ll almost certainly be happier , and safer, if you manually install patches on a test server, evaluate their impact, and then push those patches (and only those patches) to your internal SUS server for distribution to your production machines.

Figure 6-4: The SUS server pulls data from Windows Update and makes it available on your intranet, subject to the policies you define.

The complete deployment and installation process for the SUS update servers you ll need on your network is straightforward; rather than go over it chapter and verse, I m going to outline the basic steps.

1. Decide which machines will act as SUS servers. SUS itself is fairly lightweight, so it doesn t require a superpowerful machine. However, even though you can make your Exchange servers act as SUS distribution points, I don t recommend this. Keep them separate, because both SUS and Exchange are providing security-sensitive services.

2. Download and install the SUS server, which you can get from http://go.microsoft.com/fwlink/?LinkId=6930 . The download package actually includes both SUS and Service Pack 1, so you don t need a separate download. Installing SUS actually installs three main components: the Windows Update Synchronization Service downloads content to the SUS server, an IIS subweb accepts client requests, and a separate subweb provides a Web-based administrative interface to SUS. As part of the SUS installation, Windows 2000 Server machines automatically get IIS Lockdown 2.0 (and its buddy, URLScan 2.5) installed. This might have side effects on other applications running on the same server, so be careful. Microsoft explicitly says that ASP.NET, SharePoint Team Services, and the FrontPage Server Extensions are known to work on the same server with SUS; for other applications, you re on your own.

3. Configure the SUS server. You do this through the SUS Web interface (available from http://yourServerName/SUSAdmin/ ); the basic steps are pretty simple. If your server requires a proxy server to get to the Internet, you can specify the server s location; you can also specify the DNS name of the SUS server so that clients can reach it. The most important step in this process is probably specifying where your SUS server should get content. You can allow it to pull data directly from Windows Update, or from another server inside your firewall. You can also specify what should happen to patches that are updated after they ve been installed, how you want patches stored, and what languages your clients need.

4. Synchronize the server by selecting Synchronize Server in the navigation pane of the SUS Administrative page, then click Synchronize Now. You should expect synchronization to take a while; Microsoft estimates that a single language worth of SUS updates takes up approximately 150 MB of disk space. Approve or reject the individual updates retrieved by the synchronization so that when clients begin to connect, they ll get the baseline patch set you want applied.

5. Set a synchronization schedule to control when your SUS server will pull updates from Microsoft. By default, synchronization occurs daily, but you can customize this. Note that this synchronization period is different from the interval at which clients will ask the SUS server for updates.

6. Install the SUS client on your machines. Windows XP Service Pack 1 and Windows Server 2003 already include the SUS client; Windows 2000 Server systems need Service Pack 3 or later. The SUS client is actually an extension of the base Windows Update client from Windows XP; it adds support for downloading from SUS instead of Windows Update and for scheduling automatic installations, as well as some additional Group Policy-based controls. On machines that don t already have the client, you ll need to install it somehow. Active Directory s software installation features are a great way to accomplish this.

7. Decide how you want to configure the clients. SUS includes a Group Policy template (WUAU.adm) you can use to distribute SUS settings using Active Directory. This method is the simplest and most flexible; it gives you the ability to set different SUS policies for different OUs, Active Directory sites, or Active Directory domains. If you prefer, you can create registry subkeys beneath the HKEY_LOCAL_MACHINE\SOFTWARE\ Policies\Microsoft\Windows\WindowsUpdate\AU key .

   Note  

   The Deploying Microsoft Software Update Services white paper (available from http://www.microsoft.com/windowsserversystem/sus/susdeployment.mspx ) describes the registry keys you can use to configure SUS manually.

8. Set your SUS client policies. These policies can include the following:

   • Which update server should be used to pull updates. If none is specified or if the specified server can t be reached, the client will use the public Windows Update site.

   • How often updates will take place. By default, each SUS client will poll approximately once per day (every 22 hours, minus a random time offset to avoid load surges on the server).

   • What happens when updates that require rebooting are sent to clients. By default, when SUS installs a component that requires a reboot to completely install, it will automatically reboot the machine, but you can change this.

   • How updates will be downloaded. You can specify three policies: notify for download and notify for install, download automatically and notify for install, or download automatically and schedule install. These policies do exactly what you d expect, and nonadministrative users cannot change these options.

     Tip  

     You can use GPOs to specify that SUS be used, but did you know that there s already a Group Policy setting that blocks users from using Windows Update? In Windows XP, the Remove Access To Use All Windows Update Features Group Policy setting (located in User Configuration\Administrative Templates\Windows Components\Windows Update) blocks user access to Windows Update. Combine the two to automatically push patches to workstations and servers without giving even local administrators the ability to fool around with Windows Update.

Using Microsoft Systems Management Server

Microsoft Systems Management Server (SMS) is an extremely powerful product usually found in medium-scale to large-scale enterprise networks, where it is normally used to inventory software and operating system configuration and push predefined sets of applications and components to machines based on their role, physical location, or network location. The big difference between SMS and SUS is that the latter is designed only for pushing out critical software updates, whereas the former is a general-purpose tool for distributing arbitrary bits to machines on your network. SMS has some additional capabilities, too: it can target updates to machines based on their IP subnet, group, or OU membership, and it understands the concept of Active Directory sites and the links between them, making it useful for large wide area network (WAN) environments with varying kinds, speeds, and latencies of communication links.

Note  

The easiest way to distribute security fixes with SMS is to use the SMS Feature Pack. For more information on how to do this and how to configure SMS to push security patches, see the SMS Web site at http://www.microsoft.com/smserver/ .