WUS (Windows Update Services)
WUS (Windows Update Services)
What is it?
WUS is the acronym for Microsoft Windows Update Services. WUS is currently in BETA and is NOT supported by Microsoft, yet. SUS (Software Update Services) was WUS’s predecessor. However, SUS is not as flexible as most network and security administrators would like. SUS lacks reporting, groups, ability to choose which types of updates, details about the updates, the platforms for which updates you are interested in, successful or failed installs, and a couple other useful features that are introduced into WUS. The two major features that were missing, in my opinion, were reporting and groups. SUS has a decent following and has prompted some home brew solutions to cope with SUS’s shortcomings. If you are currently using SUS and don’t want to deploy WUS because it is still in beta, then I suggest you check out the following homebrew “tools”:
http://singe.rucus.net/sus/
http://www.susserver.com/Software/SUSreporting/
http://forums.susserver.com/index.php?showtopic=4107
http://forums.susserver.com/index.php?showtopic=638
WUS’s current role in network security is to handle the ever-increasing amount of service packs and patches for Microsoft’s 2K/XP/2K3 operating systems along with the XP/2K3 office suites. As everyone with dial up knows, these patches can be several megabytes to hundreds of megabytes in size. I believe that it would take a dial up user more than 10 hours on a 56k connection to download Windows XP Service Pack 2. However, those of us who have larger pipes can download them in 30 min or less.
Why do I care?
Since I have a large pipe, I can download the largest updates in 30 minutes. Does that mean that we want to download a service pack or patch from Microsoft’s Windows Update website hundreds or even thousands of times via Automatic Update? No! What a waste of bandwidth! Do I want untested patches deployed without my approval? No! We want to test the patches within our test environment and then deploy. Who has the time to walk around to so many machines manually installing updates on a weekly or monthly basis?
What am I going to do about it?
This is going to change depending on the size of your company or network. You can even set this up at home on a machine that is not a server. You just have to hack up the install package a bit. It will run just fine on a 2K workstation or XP Pro Workstation. (Note: SUS would run fine; however, I have only tested WUS on a 2K Server.)
I recently setup WUS on a client’s network. This network has over a hundred workstations. I needed an inexpensive and reliable solution that I have control over. With WUS, I could create groups and assign the computers into the groups. (This can also be done with Active Directory.) I took a couple of workstations from each department and put them in the test group. If all is well, and updates don’t break programs they use, then I’ll deploy them to all the workstations. Some critical security vulnerabilities require us to bypass the testing phase and deploy right away. However, if you are on a private network and you have multiple layers of security, there is little reason you shouldn’t be able to test most of the updates. I don’t recommend updating drivers.
Again, keep in mind that this is still beta. We are aware of this and so far we have had no problems. All machines get all updates just like planned. We will upgrade the WUS server as Microsoft releases updates.
Minimum requirements for WUS:
Microsoft recommends having 30 gigs of available disk space. They also recommend 1GB RAM and a minimum of 1 GHz Processor. The server I setup for my home network had the following specifications: 1.5 GHz processors, 768 MB RAM, 160GB OS partition. The WUS install took about 2 gigs of hard drive space for the WUS content and the free SQL server (MSDE2000). By today’s standards, those requirements are miniscule.
Setting up the servers:
First and foremost: Read the documentation! Deploying WUS on your network has a great impact on your bandwidth. Each network is different, and you need to determine how you are going to deploy WUS. I certainly don’t have the bandwidth to deploy patches over a WAN. I need a WUS server for each of my remote sites. Then I can sync the servers at night when the bandwidth is not being utilized. One nice thing is that you can specify where you are going to store the content. So, after you have one server setup, you can burn the content to CDs or DVDs and copy them to the server without downloading all of the updates.
Installation:
I’m not going to walk you through the install phase. Microsoft has been kind enough to provide a document that will do just that. You can find it on the WUS homepage. It is called “Step-by-Step Guide to Getting Started with Microsoft Windows Update Services”. http://www.microsoft.com/wus
Note: If you are installing on 2K Server, you have to install MSDE yourself. The setup for 2K3 will automatically install and configure it for you. It is pretty easy to do though. If MSDE doesn’t fit your requirements, then you’ll have to specify some other SQL server. You don’t have to run SQL locally; you can use a remote database server.
Setting up the clients:
If you use Active Directory, then this should be a breeze. Create groups based on your workstations in various departments. You’ve probably already done this for security policies anyway. Keep in mind that it is smart to have a test group if you have the resources. Your test subjects should not the 70-year-old receptionist who barely knows how to move the mouse. They should be somewhat technically literate. They should know when something is wrong and promptly report it to the IT department. This is so you know when a patch breaks a commonly used or business critical program. You can then find a workaround for it or decline the update before you have hundreds of users breathing flames through the phone and into your ear.
If you don’t use Active Directory, then this process is a bit more difficult. You’re going to have to manually set the computer’s local policy to download from your internal server, rather than to download it from Windows Update. This is very easy and self-explanatory. However, make sure that you get the latest ADM file.
If you are upgrading from SUS to WUS, the clients will automatically get an updated copy of the Windows Update ADM snap-in file.
Server Security:
The WUS server (or database server) will have to be one of the tightest boxes you have on your network. If someone were to get access to this server, they can pretty much get the info to access to any of the other boxes on your network. There are other methods of doing this too, but why just give it to them? This would be the ultimate footprinting tool. They will have access to your database! From your database, they can find out which machines have which patches. From that, they can easily choose which canned exploit to launch against the unpatched machine(s).
By default, only Admins can access the WUS homepage. I’ve taken it a step further and set ACLs on which IP addresses can access the WUS admin page.
SSL should also be enabled so connections to the WUS server can’t be sniffed. By default, WUS uses HTTP which is transferred in clear text.
To ensure that the updates have not been tampered with, Automatic Update checks the cyclical redundancy check (CRC).
For more information on SUS or WUS security, please visit: http://www.microsoft.com/resources/d...h_sus_zvfp.asp
I have put this same document up on my school site. It has screenshots. The screenshots are not very good quality due to word reformatting them. For this reason, I will also include just the screen shots in a different .zip file. I'll have to do that later this evening though. For the original doc, check out http://user.dtcc.edu/~f1189/ao/wus.doc
