Due to strict requirements of security for finance businesses, a finance company’s network should be isolated from outside environment. This has the effect of shielding making the entire software infrastructure less prone to software invulnerabilities and thus external attacks. However, this does not eliminate the need for software updates since the network’s operation can still be disrupted by internal sabotage or worm infection from careless users.
Since large financial institutions often have management workflows, updates are subject to prior approval by the management and not all updates maybe approved. The process of maintaining software updates manually, which includes downloading, tracking, approving and installing’s cost could escalate as vulnerabilities are discovered over time and software enhancements are made.
As a major software manufacturer, Microsoft is aware of this issue and have developed Windows Software Update Service (WSUS) as a solution for the update management problem. WSUS allows for approval, mass install, provides a central configuration point and thus reduces the maintenance cost.
This document tried to summarize the knowledge needed for installing and applying WSUS’s update model to an isolated network. This includes:
1. The requirements and how to install WSUS under the isolated model.
2. Configuring WSUS and the approval workflow with WSUS.
3. Synchronize update databases between computers.
4. Configure clients to receive intranet software updates.
Figure 1 A typical corporate intranet
The picture above describes a typical “closed-circuit” corporate network, which connects computers within a branch and branches together. This network is isolated from outside environment (e.g. the internet or other non-corporate affiliated networks).
Two servers, disconnected model
Because the update server must be connected to the internet somehow (to receive updates from the root update server – Microsoft’s), the safest model for this application is to utilize two server – one to receive updates from outside and one to propagate updates inside the intranet. Data would be manually synchronized between the two machines by various means like tapes, external HDDs or an ad-hoc network. Tape and HDD synchronization theoretically is the most secure option, since no connection is required between two machines and thus, makes data leaks and network penetrations almost impossible (data can only go in and can’t go out). Also, update package’s integrity is always verified with digital signatures from Microsoft so they can’t be compromised.
Figure 2 Two servers model
Package approvals can be made on the internal server. Subsequent package updates from the external server will not affect existing approvals.
Although being the most secure option, this model is costly to deploy:
- It requires an additional server to receive updates from the internet.
- It requires additional data containing medium (tapes, HDDs) to synchronize the servers securely.
- It takes time to synchronize (updates are usually large – to the extent of terabytes and external storage media is usually slow)
This technical note is focused primarily on how to configure and make servers perform this role.
One server, switching connection model
Figure 3 Switching connection model – update phase
Figure 4 Switching connection model – distributing phase
To avoid the cost of an additional server and updating time, this one-server model can be used. The update server could switch between two connections: one to the internet (to download updates) and one to the internal network (to distribute updates). The switch could be made at anytime because WSUS itself could handle partial downloads.
With this model, penetrations and leaks may occur if a malicious party could install a drone in the update server to execute predetermined commands or probe for data from the internal network. Therefore t is advised that the update server be carefully firewalled and allow only the update service to access the network interface.
Also, the update server must be dedicated to the role can can’t perform other server roles since it could be disconnected from the internal network at any time.
One server, always on model
Figure 5 One server, always on model
This model is similar to the one server, switching model except that both the connection to the internal network and the internet is always on to the update server. This way, the update server can continuously update its repository and distribute the update to internal computers. The update server acts similar to a router that allow the computers in the internal network to access the internet, except that the only kind of data that can get through is updates and this data also subjects to approval in WSUS.
This model requires an additional interface for the update server. However, the server can also perform other roles for the internal network, since it is always connected.
This model is the least secure of all three. It poses a serious security threat to the internal network in case the update server is compromised by a malicious party. Therefore, making sure the update server itself is up-to-date with the latest security patches and strict firewall configuration is a must.
Comparison between models
||One server, switch
||One server, always on
||Medium (Two servers and transfer media setup)
||Low (One server and firewall setup)
||High (Update approval on internal server and decide when to sync.)
||Medium (Need to decide when to switch)
||Low (Update approval only)
||High (Manual sync.)
||Medium (Manual/Automatic switch required)
||Low (Usual security and maintenance checks only)
Configuring WSUS servers
WSUS setup process is straightforward. A configuration wizard is started after WSUS installation is completed to help users configure WSUS. This wizard can be accessed later through the option item in WSUS configuration snap-in (Control panel à Administrative tools à Microsoft Windows Server Update Services)
Figure 6 Options item
WSUS can be configured to pull data from another WSUS server instead of the default Microsoft server (useful when deploying the two server model, connected with an ad-hoc network). Other configuration options are visible on Figure 6 and to the left of Figure 7. It should be noted that this wizard should not be followed on the internal server in the two server model since it requires a direct connection to the upstream update server to continue past step 4. Actually no configuration is needed in this case.
Figure 7 Update source configuration screen
Managing approvals and installing updates
Computers in the internal network could be configured into groups to manage which update should or should not be installed on them. WSUS can only manage clients which have reported to it. Refer to section “Configuring clients” for details on how to configure clients.
Figure 8 Client management screen, listing all active clients
Figure 9 Update approval / rejection
Figure 10 Detailed status report for a client, with report viewer installed
After being properly configured, clients will automatically pull updates from the WSUS server and install them if those update packages are approved and have not been installed already.
Synchronizing update repositories
Deploying the two servers model with tapes and external HDDs require manual export and import of update data. “Update data” includes:
- Package executables themselves, which are saved as files in WSUS’ update repository (the default folder is C:WSUSWsusContent and can be changed during WSUS’ setup). This is synchronized simply by copying the content of the entire folder.
- Information about the packages such as checksum and verification data, termed “metadata”. See “Exporting metadata” and “Importing metadata” for details.
WSUS requires both kind of data to be synchronized to work.
Usually, the list of available updates and their metadata is downloaded before the update packages themselves. WSUS will not distribute such incomplete packages.
Figure 11 Warning when package’s files have not been downloaded
Syntax: wsusutil export <datafile> <logfile>. This will produce a metadata container file (.cab) and a log file (.log). Both are needed for metadata import. The exporting process could take a while.
Figure 12 Exporting metadata
Syntax: wsusutil import <datafile> <logfile>.
Figure 13 Metadata import
To make client update through the new WSUS server instead of the default (Microsoft’s server), the policy for the domain should be modified as in Figure 14 to point to the new WSUS server: http://<servername>.
Figure 14 Client configuration (illustrated with local policy editor)
To edit corporate policy, you con either use the Group Policy Management Console, right click the OU you want to apply WSUS policy and select create policy, you should now see he Group policy object editor similap to tho above screenshot.
Alternatively, you can open Active Directory users and computers, open the properties windows for the OU you want, select the policy tab and click Add (or edit an existing policy).
After policy modification, it may be necessary to:
- Forces refresh the active policy with gpupdate /force (which will be automatically refreshed in 15 minutes anyways).
- Clear Internet Explorer’s cache on the client to force reload of update configuration files downloaded from the previous update server.
- Reauthorize Automatic updates on the client so it is registered on the update server with wuauclt.exe /resetauthorization /detectnow.
- Make sure that Automatic Update for the client is enabled.
Figure 15 Windows XP Automatic updates configuration screen (My computer à Properties)
Upon successful configuration, the client will appear on WSUS configuration snap-in as in Figure 8.
1. WSUS 3.0 SP2: Main WSUS Component.
2. Update fix for WSUS 3.0 SP1: WSUS 3.0 SP1 is known to have a bug that make some client unable to download updates.
3. Microsoft report viewer 2005: Required to view detailed reports.
4. Windows Installer 3.1: WSUS perquisite.
5. .net Framework 2.0 SP1: WSUS perquisite.
6. Background intelligent transfer service 2.0 update: WSUS perquisite.
7. Windows Server 2003 SP2: WSUS perquisite.
1. Microsoft Windows Server Update Services 3.0 SP2 Deployment Guide
2. Microsoft Windows Server Update Services 3.0 SP2 Operations Guide
Registered trademarks are property of respective owners. This document contains no sensitive or specific information about any corporate entity.