The bottom line, of course, is that you must protect your servers, so the question isn't whether to apply hotfixes, but when to apply them. Remember, too, that although staying up-to-date is important, you won't get a medal simply for being the first administrator to apply a hotfix. To the contrary, Microsoft sometimes recalls or reissues patches because of implementation problems. So, you need to balance all the factors, then determine when to deploy the fixes. If your risk is great, you should apply the patches as soon as you can schedule the necessary downtime. If you determine that the hotfix isn't urgent, you might decide to wait for Microsoft to issue the next OS service pack. Service packs usually include all security hotfixes that Microsoft has issued since the previous service pack.
Mapping the Course
After setting your timetable, you need to determine how to deploy the fix. Microsoft security patches come in a prepackaged, compressed executable file consisting of hotfix.exe, hotfix.inf, and the replacement files. Hotfix.exe installs the patch, and hotfix.inf contains instructions for modifying certain files and registry settings when you apply the fix. Microsoft releases a hotfix in different versions for Win2K and NT. When hotfix.exe runs, it determines whether the service pack that's currently on the system is older than the hotfix you're applying and whether the language is the same. By performing this check, hotfix.exe can determine whether someone installed the patch as part of a previous service pack.
If your server passes both of these checks, hotfix.exe installs the update. If the service pack is newer than the hotfix you're applying, the install process quits. During the update, hotfix.exe creates a registry subkey in Win2K and NT at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Hotfix\Qxxxxxx, where Qxxxxxx refers to the Microsoft article associated with the patch. In Win2K, the hotfix also adds the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Windows 2000\SPx\Qxxxxxx subkey, where SPx stands for the service pack designation.
When you download patches, you'll find that different types of patches use different naming formats. Some NT patches have an eight-character name that resembles the name of the vulnerability (e.g., tearfixi for the Teardrop Attack). Other patch names use a form that references the relevant Knowledge Base article and hardware platform (e.g., q123456i). The naming scheme that Win2K patches use is the easiest to understand and conveys quite a bit of information. Win2K patch names consist of the article number, the OS, the service pack level that will incorporate the patch, the hardware platform, and the language (e.g.,q294391_w2k_sp3_x86_en.exe).
Although deploying patches manually is common practice, scripting patch deployment is a better solution. You script patches by using hotfix.exe's -m switch. Figure 1 shows the Win2K hotfix.exe switches; the switches for NT are the same. You can also use the -x switch to extract the files and see exactly which files the hotfix updates.
The problem with applying patches is that you usually have to reboot after every patch you apply. Although some servers boot relatively quickly, others take time because of BIOS hardware checks. Rebooting one server a few times might not be a problem, but if you manage hundreds of servers, rebooting each becomes an exhausting process that involves extended downtime. Microsoft addressed this problem in 2001 with the release of Qchain. This utility lets you install multiple hotfixes without rebooting between installations. For more information about how to use Qchain in a script to deploy multiple hotfixes, see the sidebar "Using Qchain."
Deployment
Although you can deploy hotfixes manually, you probably don't want to if you have a lot of servers. If you're looking for a way to avoid visiting every server, consider using Telnet. Win2K has built-in Telnet services; NT administrators can find Telnet on the Microsoft Services for UNIX (SFU) product. You might also want to look at a system that helps manage the process. Microsoft Systems Management Server (SMS) and St. Bernard Software's UpdateEXPERT are both products that provide a framework for automating deployments to your servers. If you have test servers, apply the patch on them first, then test the patch. Managers have little tolerance for untested patches.
No matter how you deploy your hotfix, make the process as easy as possible. You should coordinate all deployments with your security committee and technical staff. As a part of deployment, you should also prepare an exit strategy for a worst-case scenario and make sure that you have current backups of the servers you're upgrading. And always document every step of every change that you make.
Monitoring
After deploying patches, monitor upgraded servers for unusual behavior that the patch installation might be causing. Monitor Microsoft and third-party sites for patch updates, and watch for reports of unanticipated problems that the patch causes. In some cases, you might find that you need to uninstall the patch.
When you install a patch, the hotfix creates uninstall directories in \%systemroot%\$NtUninstallQxxxxx$, as Figure 2 shows. You can uninstall most patches from the Control Panel Add/Remove Programs applet in Win2K and NT. You can also uninstall patches from the command line for both Win2K and NT by running hotfix.exe with the -y and -m switches from the patch uninstallation directory. The -y switch performs an uninstall and can be used with the -m switch for an unattended uninstallation. A few patches don't have an uninstall procedure.
Taking the Necessary Steps
Microsoft administrators need to devote more time to security, whether it's for servers or workstations. Start by locating timely, reliable sources of information about vulnerabilities, then use those resources regularly to stay up-to-date. Coordinating a patch rollout can be difficult, so start now to develop a plan to ease the process. Then, when you learn of vulnerabilities that might affect you, simply follow your plan.
End of Article
Prev. page
1
[2]
next page -->
