How many of you were burned by Sobig, Klez, Welchia, or the Blaster viruses? Even if you are diligent about downloading and applying your virus definition updates, you can still be infected because the definitions can only protect against viruses they know about. The majority of viruses exploit known vulnerabilities in operating systems. These viruses typically come out three days after a vulnerability is announced, and anti-virus companies respond to the new viruses a couple of days after that.
One way to protect your computers against these viruses is to keep your operating system and software security updates current. This limits the impact of viruses that exploit vulnerabilities and keeps you working on value-added activities. If you are diligent about patching, you can defend yourself several days before anti-virus definitions are released for a new virus!
One of the biggest security exposures companies face is their Microsoft Windows systems. Almost weekly, Microsoft announces new vulnerabilities in the form of weaknesses or flaws in the operating system or software. Hackers use these vulnerabilities to compromise your security, submit denial-of-service (DoS) attacks, perform remote code execution, and generally wreak havoc on your system.
In order to remove these vulnerabilities, Microsoft offers hot fixes, patches, and security roll-ups that need to be installed on each system you maintain, including all your desktops and Windows-based servers. If you do not have a change management system like IBM's Tivoli or Microsoft's Systems Management Server (SMS), keeping your systems up-to-date can be time-consuming. The result is that workstations and servers often remain vulnerable to these weaknesses for extended periods of time.
As part of Microsoft's Strategic Technology Protection Program (STPP), the company has released Software Update Services (SUS) to help organizations keep security up-to-date. It allows users of Windows 2000 and later systems to download their security patches from a centrally managed server. It also provides the flexibility to be n-tiered to conserve bandwidth across multiple locations.
In this article, I will review SUS, examine the architecture, and explain how to set up and configure both the clients and the server.
Architecture
SUS (formerly known as Windows Automatic Updates) has been operating centrally for quite some time. If you notice a globe at the bottom of your screen from time to time that says "New updates are ready to install," that's SUS. Within the last year, Microsoft has given organizations the ability to install free of charge a version of SUS that lets companies tailor what gets pushed out to workstations and servers.
There are three components to SUS: Microsoft, the SUS server, and your clients (which could be servers and/or workstations). Microsoft provides patches on its centrally managed cluster of SUS servers. When new patches become available, they're bundled, digitally signed, and registered in the SUS servers. Once a patch is in Microsoft's SUS servers, it is available for you to download.
The SUS server you maintain is configured to first synchronize with the Microsoft SUS servers and then download patches as they become are available. You can select from a number of language preferences, and only patches that apply to the languages you select are synchronized.
You can also force synchronization outside of the regular schedule, which you may want to do in case a patch becomes available and you cannot wait for the next scheduled synchronization. Once new patches have been downloaded, you must approve the updates before your clients can download them. This is important if you have a standardized desktop and you test each patch before allowing the general public to install it.
The client was made available in Windows 2000 Service Pack 2 and Windows XP Service Pack 1. All versions afterward include the SUS client, including Windows Server 2003. You can download a SUS client for Windows 2000 pre-SP2 and Windows XP pre-SP1 but not for other versions, such as Windows NT, ME, 98, or 95.
The client provides the ability to automatically download and install the updates. You can manage the configuration of the SUS client centrally through Group Policy Objects or individually through registry entries. There are various options that let you define when updates are downloaded, what notification is provided, and which SUS server to use.
To the Nth Degree
The architecture of SUS allows you to have many layers to your SUS configuration. A SUS server can be configured to download updates from Microsoft or from a server you set up. At each level, you can stipulate which updates are released to your clients. This provides the ability to stage the installation of patches and/or conserve bandwidth.
Lets look at an example in which a company has standard desktops and wants to test new patches. The company sets up two servers. The first server downloads updates from Microsoft; the second downloads updates from the first server. A single test client downloads the patches from the first server as a test bed. Patches are automatically approved on the first server so that the test client is able to test the updates. Once the administrators have agreed that the new patches do not pose any risk, the patches are approved on the second server.
In a different example, you have a hub-and-spoke WAN with one Internet connection and several frame relay- or DSL-connected sites. There are two areas in which bandwidth can be conserved. The first is that you have SUS servers at each site so that your internal frame connections do not become saturated. Your clients download the updates from the local server (not the Internet) or your hub site over the frame link. The second is that the SUS servers at each location download from a central SUS server so that updates are downloaded only once over your Internet connection.
A side benefit is an option that allows you to adopt the approved updates from the central server automatically. If the central data center approves the updates, why not? After using this software for about a year and not testing a single patch, the company I work for has yet to have a problem!
Server Configuration
Configuration of SUS is performed through a Web site set up in Microsoft's Internet Information Server (IIS) 5.0 or later. When the server has been installed, you simply point your browser to http://SUSServerName/SUSAdmin and start configuring. See Figure 1 for an illustration of the initial Web page you see when you go to this site.
Figure 1: Start your SUS configuration from this screen. (Click images to enlarge.)
You'll notice that you are not prompted for a user ID and password when you access this site. Because the configuration system is a standard Web site, Microsoft leaves it to you to figure out how you want to secure it. Through the IIS Administration Application on your SUS server, you can stipulate whether you want authentication and/or encryption for this site. Refer to the IIS documentation or Microsoft for specifics.
The minimum requirements for SUS are a Pentium III 700 Mhz with 512 MB of RAM and 6 GB of hard drive space for new updates as they come in. This hardware must be running Windows 2000 Server with at least Service Pack 2 or Windows Server 2003, which comes with SUS. Other requirements are IIS 5.0 or later and Internet Explorer 5.5 or later. With this configuration, Microsoft indicates that you can support 15,000 clients.
Configuration of the server is very straightforward; there are only a few configurable options. We'll go through them one at a time.
The first option is your proxy server configuration, which is required only if you are using this server to connect to Microsoft for updates and if you use a proxy server to connect to the Internet. Within this option, you can set credentials for accessing the proxy server, allowing you to schedule a job to run in batch nightly to download the updates. Because you are not doing this interactively and there is the possibility that the proxy server requires authentication, you can place the user ID and password here. This option is not available in the client, which is another reason to consider installing SUS server.
The second option requires you to enter the name that clients will use to connect to this SUS server. I cannot for the life of me figure out why this is required, since the server can get this information from the TCP/IP settings. Anyway, you should put the name of the server here. In our organization, we called our server SECURITY-SRV, as reflected in the text box in Figure 2.
Figure 2: This is the first set of options you can configure for MS SUS Server.
If you are implementing multiple SUS servers, the next option is important to you. This stipulates whether this server is downloading updates from Microsoft or from one of your other servers. If it is from one of your other servers, enter the name of the server here to ensure that you are able to PING that server name from this server. This ensures that you can resolve the name to an IP address and that there is network connectivity. No sense in setting up tiers if your child servers cannot communicate with the parent server!
The option "Synchronize list of approved items updates from this location (replace mode)" allows you to automatically approve all the updates from your parent server so that you do not have to do this manually. This works well in corporate environments where one governing body approves the updates and mandates that all child servers accept those approvals.
Microsoft often updates previously released patches to fix a fix that did more harm than good or that now fixes additional vulnerabilities. The next option allows you to approve updated fixes either automatically or manually before they are made available to the general public. Figure 3 (a continuation of Figure 2) illustrates these two options.
Figure 3: The second set of options identify what action to take on previously approved updates and which languages to download.
The final option shows us how many different client languages are supported by SUS server. Click all that apply to your environment. The more you select, the longer it will take to synchronize updates with Microsoft and child servers if they have those languages as well. Also remember that if you are setting up the parent server in, say, a hub-and-spoke model, you must download the client versions that your child servers may have to support.
Synchronizing
Once your server is configured, you need to synchronize with Microsoft or your internal update server. Perform this step by clicking on the Synchronize Server link on the left of the main menu. Figure 4 shows the options available for this task. You can either choose Synchronize Now or set up a synchronization schedule.
Figure 4: You can schedule the synchronization or perform it interactively.
You will typically perform a Synchronize Now if you are made aware of a critical patch that affects your systems and you can't wait until the next synchronization schedule. This initiates a connection to the Internet and downloads any patches, fixes, or security roll-ups that your server has not downloaded. Figure 5 shows you what a Synchronize Now should look like if it occurs successfully.
Figure 5: Here's a sample of what the interactive synchronization looks like.
But, instead of having to remember to Synchronize Now, you may want to set up a schedule. We download updates at 6:00 a.m. every day so that if patches are made available overnight, we have them downloaded before people start working at 8:00 a.m. However, when you schedule it is up to you. I recommend that you perform the synchronization daily. Figure 6 illustrates how to set up the schedule for daily updates at 6:00 a.m.
Figure 6: We perform synchronizations at 6:00 a.m. every day, which is illustrated here.
Once you have set up a schedule, review the status of the scheduled synchronizations by clicking on the View Synchronization Log link at the left. Figure 7 shows you our log as of October 28, 2003. You will notice that, while no new updates were downloaded, there is an updated or "reissued" update. Because I set up our system to automatically approve reissued updates, I do not have to go in and approve this update.
Figure 7: The synchronization log will tell you whether your interactive or batch synchronization attempts were successful.
Approving Updates
Our next server-side task is approving updates. To approve updates, click on the Approve Updates link on the left menu. You will see a rather lengthy list of updates that have been synchronized either from Microsoft or one of your internal servers. For each update available, you will see a description, the platform, the date it was released, and a link to details of the update. To approve the update, simply click the checkbox on the left of the update and click the Approve button at the bottom right of the window.
For certain updates, you will be asked to approve an End User License Agreement (EULA), which will appear in a pop-up window. You may see a few of these the first time you approve updates. Once you have agreed to all EULAs and the server has processed your approvals, a window should appear that's similar to Figure 8, which shows the updates that you have approved. Any updates that have not been approved are shown at the top of the list for easy access.
Figure 8: After running SUS for awhile, the list of updates becomes lengthy.
At this point, your server is ready to go. The only thing you need to do is to configure your clients.
Client Configuration
Client systems supported by SUS are Windows 2000 Professional (prior to Service Pack 2, there is a client you must install), Windows 2000 Server, Windows XP Home and Professional, and Windows 2003 server.
There are three ways to configure the client Automatic Update component. The first is by altering the registry manually. This is not a recommended solution, but you can do it during the beta test phase of your implementation. Edit the registry by running REGEDIT.EXE or REGEDT32.EXE, whichever you are more comfortable with. The registry entries can be found under HKEY_LOCAL_MACHINESOFTWAREMicrosoftCurrentVersion WindowsUpdateAuto Update.
The Control Panel provides an Automatic Update applet that lets you choose some of the options you can set in the registry. However, it does not allow you to stipulate an internal update server, so it defeats the purpose of this article.
Below, I've listed six registry entries that will cover most of what you will want to do on the client. You'll notice there are more registry options than I'm defining here. For more information, refer to the Additional Reading section at the end of this article.
AUOptions: This registry entry configures when updates are downloaded and applied to your client computers. An entry of 2 notifies you when updates are ready to be downloaded. Once acknowledge by a locally signed-on administrator, the updates are downloaded and installed. An entry of 3 downloads the updates automatically and prompts you to acknowledge the install. A dangerous entry of 4 automatically downloads and installs the updates and performs a reboot if required.
ScheduledInstallDay: This entry takes a value of 0-7, which stipulates what day the updates will be installed on. Choosing 0 will install every day, whereas 1-7 specifies a day of the week, starting with Sunday (1).
ScheduledInstallTime: This is the hour of the day (from 0-23) when updates will be installed. We have it set for 13 so the updates are installed at 1:00 p.m.
UseWUServer: This is very important. A 1 tells Automatic Update to use an internal update server, as specified in the next two options.
WUServer: This entry tells Automatic Update what SUS server to use. Microsoft documentation indicates that you should use a URL such as http://security-srv. However, using just the server name--as shown in Figure 8--works as well.
WUStatusServer: This specifies what server to use for the SUS statistics server. This is typically the same as the WUServer entry.
With these six options set, your client is configured. However, doing this at each client is time-consuming. The second method of configuring the clients is to configure and test one computer and then make a backup of the registry pertaining to the Automatic Update client. This will create a filename.reg file that you can run on all other computers. When you run a .reg file, it updates the registry with the entries that are contained in the .reg file.
The third way is through a Windows Active Directory Group Policy. When the Automatic Update client is installed it creates a WUAU.adm file on your computer. This file can tell your Active Directory implementation the options that are available for centrally configuring your Automatic Update clients. The next time your computers sign into the Active Directory, these options are automatically downloaded. I won't go into detail about this, as many companies are finding Active Directory too complicated and I'm running out of space. So, to stay in the good standings of my wonderful editor, we can discuss this in the forum associated with this article if you like! (See the "Discuss this article" link at the end of the article.)
Extending SUS and Automatic Update Clients
When Microsoft makes new updates available, they are digitally signed. If a SUS server or Automatic Update client receives an update that is not properly signed, the update is automatically discarded. Consequently, you cannot create packages to be distributed to your clients through SUS server. This feature ensures that hackers who compromise your SUS server cannot create malicious software and have it distributed to all your workstations and servers.
Downside
The big downside to SUS is that you cannot centrally see who has and has not installed the patches. If you configure new patches to be installed automatically, you may have systems that reboot without warning. If you don't do this, you may have users who never install the updates and end up with vulnerable systems.
To mitigate this exposure, we performed training with users to explain the ease with which they can do this and the benefits they receive as a result (better stability, faster system, etc.). In addition, we have a preventative maintenance schedule in which we install the patches on systems for the users have not done so.
A smaller downside is the fact that SUS will not deploy service packs. In my opinion, you do not want to perform service pack updates automatically. They should be planned properly, with alternate plans in place in case the service pack does not work.
Wrap-Up
We have been very happy with our implementation of SUS. Since the beginning, we apply critical patches as per corporate mandates, and we have seen no successful penetrations from hackers. In addition, we have blindly approved all updates as soon as they came in from Microsoft and have not yet had a problem. If you add the fact that the server is free from Microsoft, you can't go wrong.
Recent Developments
Microsoft's SUS is now offering full Service Packs. Windows 2000 Service Pack 4 is available in addition to Windows XP Service Pack 1. While this is another avenue of install, I recommend caution in approving these service packs as they exceed 100 MB and can take close to 30 minutes to install, depending upon the speed of your computer and network.
Additional Reading
Microsoft has published a Software Update Services Deployment White Paper. It is a pretty easy read, has various usage examples, and is a one-stop shop for implementing SUS (outside of this article, of course!).
Chris Green is a Senior Network Support Specialist located in Toronto, Ontario, Canada. He has eight years experience focusing on the iSeries and networking technologies. Utilizing this experience, he has authored over 30 articles and several white papers and has co-authored an IBM Redbook entitled Securing Your AS/400 from Harm on the Internet. Most recently, he has achieved Security Essentials (GSEC) certification from the SANS Institute. For questions or comments, you can email him at
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online