Export (0) Print
Expand All

Techniques for Patching New Computers

Published: August 03, 2005
By Tony Northrup
Tony Northrup

I've Been Hacked Already?

A few years ago, I was doing systems engineering work for a technology firm when a UNIX systems administrator asked me to help him with a problem. He used a computer running the Microsoft Windows operating system and connected to the public Internet for testing, and that computer was behaving strangely. I took a quick look at it and immediately recognized the problem: The computer was infected with a worm.

"Okay. Now how do I get rid of it?" he asked.

"The computer doesn't belong to you anymore; it belongs to the bad guys now. You don't know what they might have done with it. Reformat it, re-install Windows, and get it patched."

He rebuilt it and came back to me in about an hour. His computer had become infected with the same worm while he was trying to install the security updates.

According to Sophos research published July 1, 2005, there's a 50 percent chance that an unpatched computer running the Windows operating system will be infected with a worm within 12 minutes of being connected to the Internet. That's bad news, because downloading and installing all the latest updates takes longer than 12 minutes. If you're deploying hundreds of computers, you really have no chance. So, how can you keep your new computers from being attacked before you can update them?

Protect Your Network

Your first line of defense against worms is network security. However, simply connecting new computers to your internal network and protecting them with a perimeter firewall isn't enough. Perimeter firewalls keep worms on the Internet from connecting directly to computers on your internal network, but they can't stop worms on your internal network from spreading. If a user brings his or her notebook to a wireless hotspot at a coffee shop and becomes infected with a worm, that worm will try to spread throughout your internal network when the user returns to the office. As the worm replicates, the time it takes for new computers to become infected drops. As a result, new computers can be infected in minutes when connected to many internal networks, even those protected by perimeter firewalls.

For optimal protection for computers during deployment, connect them to an isolated network that contains only those computers required for the deployment process. I describe this network architecture in more detail in the "Protecting Deployment Staging Areas" section of the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) Security Feature Team Guide, version 2.5 (Standard Edition, Enterprise Edition).

In addition to relying on network security, you should update new computers as quickly as possible—preferably before you even install the operating system. The sections that follow describe two complimentary techniques: updating new computers before setup and after setup.

Installing Operating System Updates Before Setup

When you install the Windows operating system from a CD-ROM, you get the original, unpatched version unless the CD-ROM specifically says that it includes a service pack. The "RO" in CD-ROM stands for read only, so you obviously can’t update the original installation media with the latest updates. However, if you copy the contents of the CD-ROM to a shared folder, you can update the Setup files both with service packs and with other updates, and those updates will automatically be applied to all new installations. If you create an integrated setup with Microsoft Windows XP Service Pack 2 (SP2), you can even automate the configuration of Windows Firewall, Microsoft Internet Explorer, and other security features.

Recent service packs and updates that include Update.exe version 5.4.15.0 or later have a special command-line parameter, /integrate, that you can use to update a shared folder containing operating system Setup files. For example, if you copied the Windows XP Setup files to the shared folder Z:\, you would run the following command from a folder containing the SP2 update file:
XPsp2.exe /integrate:Z:\

The next time you install a new computer from those Setup files, the new computer will automatically have SP2 installed. Updates work the same way. For example, to add update KB894391 to a Windows XP installation located at Z:\, you would run the following command:
WindowsXP-KB894391-x86-ENU.exe /integrate:Z:\

Note: Updates use the naming convention KB######, where KB refers to a Microsoft Knowledge Base article identified by a unique number. You can find Knowledge Base articles at http://support.microsoft.com.

Earlier versions of Update.exe are not as easy to integrate. Refer to the Microsoft Knowledge Base article How To Integrate Software Updates into Your Windows Installation Source Files for more information. For detailed instructions on creating an integrated setup, refer to "Creating a Slipstream Version of Windows XP" in the Solution Accelerator for BDD Computer Imaging System Feature Team Guide.

Installing Operating System Updates After Setup

Ideally, all updates would be integrated into the Windows Setup files so that new computers benefit from them immediately. However, such integration isn’t always practical or possible. Updating Setup files can be time-consuming, especially if you maintain many different versions of Setup files for different languages, processors, and operating systems. If you use imaging to deploy operating systems, you would also need to rebuild your operating system images.

When you don’t have the resources to integrate updates into the original files, you can install them automatically after setup using a simple batch file. A batch file is a simple list of commands that Windows runs as if you had typed them at a command prompt. You can install any Microsoft update from a command prompt, which means that you can create a batch file that installs a series of updates without requiring user intervention. If you place this batch file in a shared folder and configure new computers to run the batch file automatically, you can install updates on new computers without modifying Setup files or images.

Consider the following batch file, which would install updates KB894391, KB890923, and KB883939 from a shared folder named updates on a server named server. You could save this file as post-setup-updates.bat and schedule it to run automatically after Setup is complete by adding it to the [GuiRunOnce] section of your unattend.txt file:

@echo off
setlocal
set PATHTOFIXES=\\server\updates

%PATHTOFIXES%\WindowsXP-KB894391-x86-ENU.exe /quiet /norestart
%PATHTOFIXES%\WindowsXP-KB890923-x86-ENU.exe /quiet /norestart
%PATHTOFIXES%\WindowsXP-KB883939-x86-ENU.exe /quiet /forcerestart

Note: Updates use the file naming convention OperatingSystem-KB######-Platform-Language.exe.

Note that the first two updates use the /norestart parameter. The final update uses /forcerestart. This parameter tells the computer to restart only once, which allows the updates to take effect immediately and eliminates the need for multiple restarts. Refer to the documentation included with each update to determine whether a restart may be required before applying other updates.

For detailed information about command-line parameters for Microsoft software update packages, read The Guide for Installing and Deploying Updates for Microsoft Windows XP Service Pack 2. Also refer to “Patching the Windows Source Files” in the Solution Accelerator for BDD Computer Imaging System Feature Team Guide.

Installing updates after setup has a drawback: It takes longer to install updates after setup than it does if the update is integrated into the Setup files. Therefore, this method slows your deployment process. Additionally, if you need to restart a new computer multiple times while installing updates, you will need to develop more complex batch files that automatically schedule the next batch of updates to run before restarting the computer.

Be sure to use file permissions to restrict write access both to your batch file and to all the update executable files. Additionally, you should regularly audit the infrastructure to ensure that no one has maliciously changed the batch file or replaced an update executable file with malicious code. Users who modify these files could grant themselves administrative privileges on the computer, install key-logging software, or perform other malicious acts.

Note: Don’t forget about your applications. Most applications do not support integrating updates with Setup source files. Instead, you need to rely on installing application updates after setup. If your application vendors provide Windows Installer files, you can easily automate the installation by using the Msiexec tool.

Best Practices

Most likely, you will need to use a combination of pre- and post-setup updates to ensure that new computers are protected as quickly as possible from known vulnerabilities. Immediately after your patch team determines that an update must be applied to existing computers and verifies that the update does not conflict with your applications, you should add the update to a post-setup batch file so that it is automatically installed on new computers. Once every three to six months, you should integrate updates into your Setup files and, if necessary, rebuild images.

Even when you apply all recent updates before or immediately after setup, you should take care to build new computers on isolated networks. Worms and other threats almost certainly reside on your internal network, and they can exploit a new computer in minutes without any visible warning. Follow all these best practices, and you can minimize the risk of infected computers in your organization.

For More Information

Discussions in Desktop Deployment
Ask your desktop deployment questions here. Discuss deployment tips and best practices with your peers, and give feedback on articles that are featured in the Desktop Deployment Center.

About the Author
Tony Northrup, CISPP, MCSE, and MVP, is a consultant and author living in the Boston, Massachusetts, area. Tony is the author of many books and articles about Windows and networking, including the Microsoft Windows Server 2003 Resource Kit Troubleshooting Guide and portions of the Microsoft Solution Accelerator for Business Desktop Deployment. For more information about Tony, see his complete bio, visit http://www.northrup.org, or contact him at tony@northrup.org.


Print This Page Print This Page

Rate This Page Rate This Page

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft