Secure WSUS 3.0 Deployment
This guide includes three ways to enhance the security of your WSUS server:
- Recommendations for hardening your WSUS server.
- Recommendations for adding authentication between chained WSUS servers in an Active Directory environment.
- Recommendations for implementing the Secure Sockets Layer protocol on WSUS.
Hardening your Windows Server 2003 running WSUS
You can find recommended settings for hardening your WSUS server in Appendix E: List of Security Settings. These recommendations include hardening a number of Windows Server components, as well as IIS 6.0 and SQL Server 2005.
Adding authentication for chained WSUS Servers in an Active Directory environment
You can add authentication for server-to-server synchronization.
There are some limitations to enabling authentication. Any WSUS server you want to authenticate must be in an Active Directory environment. If the WSUS servers are in different forests, there has to be trust between forests for this authentication method to succeed.
Enabling authentication is a two-step process:
- Create a list of downstream WSUS servers allowed to authenticate with this WSUS server, and add this list to a web.config file.
- In IIS, disable anonymous access to the WSUS server.
With completion of these two steps, only the downstream computers listed can synchronize with the WSUS server. Each of these steps is detailed below.
Step 1: Create an authentication list
WSUS setup creates a configuration file that enables you to add an explicit list of computers that have access to WSUS. You can find this file in the file system of the WSUS server at:
<authorization> element to define an authentication list. You must add the
<authorization> element below the
Consider the example below:
<configuration> <system.web> <authorization> <allow users="domain\computer_name,domain\computer_name" /> <deny users="domain\computer_name,domain\computer_name" /> </authorization> </system.web> </configuration>
Within the opening and closing
<authorization> tags, you specify a list of computers that are allowed a connection to the Web service. You must enter these computers as
domain\computer_name. If you want multiple computers, use a comma to separate the names. You can also specify an explicit list of computers that are denied access. Order in this list is important, as the evaluation stops with the first item that applies to the user. If the
<allow users> element is absent or empty, all servers are allowed.
The XML schema for this list can be found on the MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=47691.
Step 2: Disable anonymous access to the WSUS server
The next step is to configure IIS to disable anonymous access to the ServerSyncWebService virtual directory and enable Integrated Windows authentication.
To configure IIS to disable anonymous access and enable Integrated Windows authentication for the WSUS ServerSynchWebService
On the Start menu, point to Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
Expand the local computer node.
Expand the WSUS Web site node
Right-click ServerSyncWebService, and then click Properties.
On the Directory Security tab, under Authentication and access control, click Edit.
In the Authentication Methods dialog box, clear the Enable anonymous access check box, and then select the Integrated Windows authentication check box.
Click OK twice.
Securing WSUS with the Secure Sockets Layer Protocol
You can use the Secure Sockets Layer (SSL) protocol to secure your WSUS deployment. WSUS uses SSL to allow client computers and downstream WSUS servers to authenticate the WSUS server. WSUS also uses SSL to encrypt the metadata passed between clients and downstream WSUS servers. Note that WSUS uses SSL only for metadata, not for content. This is also the way Microsoft Update distributes updates.
Updates consist of two parts: the metadata that describes the update, and the files to install the update on a computer. Microsoft mitigates the risk of sending update files over an unencrypted channel by signing each update. In addition to signing each update, a hash is computed and sent with the metadata for each update. When an update is downloaded, WSUS checks the digital signature and hash. If the update has been altered, it is not installed.
Limitations of WSUS SSL deployments
There are two limiting issues that administrators considering WSUS SSL deployments need to take into account.
- Securing your WSUS deployment with SSL increases the workload of the server. You should plan for about a 10 percent loss of performance because of the additional cost of encrypting all the metadata sent over the network.
- If you are using remote SQL, the connection between the WSUS server and the server running the database is not secured with SSL. If the database connection must be secured, consider the following recommendations:
- Put the database on the WSUS server (the default WSUS configuration).
- Put the remote server running SQL and the WSUS server on a private network.
- Deploy Internet Protocol security (IPsec) on your network to secure network traffic. The Overview of IPsec offers guidance about how to deploy IPsec in your environment.
Configuring SSL on the WSUS server
The most important thing to remember when configuring the WSUS server to use SSL is that WSUS requires two ports in this configuration: one for encrypted metadata using HTTPS and one for HTTP. When you configure IIS to use SSL, keep the following points in mind:
You cannot set up the entire WSUS Web site to require SSL. This would mean that all traffic to the WSUS site would have to be encrypted, but WSUS encrypts only update metadata. If a client computer or another WSUS server attempts to get update files from WSUS on the HTTPS port, the transfer will fail.
To keep the WSUS Web site as secure as possible, require SSL only for the following virtual roots:
To keep WSUS functioning, you should not require SSL for the following virtual roots:
On the WSUS server, run the command:
wsusutil configuressl certificateName
where certificateName is the DNS name of the WSUS server. For example, if clients will connect to https://myWSUSServer, then certificateName should be myWSUSServer. If clients will connect to https://myWSUSServer.myDomain.com, then certificateName should be myWSUSServer.myDomain.com.
The certificate of the certification authority must be imported into either the local computer's Trusted Root CA store or the Windows Server Update Service's Trusted Root CA store on downstream WSUS servers. If the certificate is imported only to the Local User's Trusted Root CA store, the downstream WSUS server will not be authenticated on the upstream server. For more information about SSL certificates, see How to implement SSL in IIS (KB 299875) (https://go.microsoft.com/fwlink/?LinkId=86176).
You must import the certificate to all the computers that will communicate with the server, including all clients, downstream servers, and computers running the administration console remotely. Again, the certificate should be imported into the local computer's Trusted Root CA store or the Windows Server Update Service's Trusted Root CA store.
You can use any port you like when you configure IIS to use SSL. However, the port you set up for SSL determines the port that WSUS uses for clear HTTP. Consider the following examples:
- If you use the industry standard port of 443 for HTTPS traffic, then WSUS uses port 80 for clear HTTP traffic, which is the industry standard for HTTP.
- If you use any other port for HTTPS traffic, WSUS assumes that clear HTTP traffic should be sent over the port that numerically precedes the port for HTTPS. For example, if you use port 8531 for HTTPS, WSUS uses 8530 for HTTP.
You must re-initialize ClientServicingProxy if ServerName, SSL configuration or port number are changed.
Configuring SSL on client computers
There are two important caveats when configuring client computers:
You must include a URL for a secure port on which the WSUS server is listening. Because you cannot require SSL on the server, the only way to ensure that client computers use a secure channel is to make sure they use a URL that specifies HTTPS. If you are using any port other than 443 for SSL, you must include that port in the URL, too.
https://<ssl-servername>specifies a WSUS server that is using port 443 for HTTPS; however, while
https://<ssl-servername>:3051specifies a WSUS server that is using a custom SSL port of 3051.
For more information about how to point client computers to the WSUS server, see "Specify intranet Microsoft Update service location" in Configure Clients Using Group Policy later in this guide.
The certificate on client computers has to be imported into either the Local Computer's Trusted Root CA store or Automatic Update Service's Trusted Root CA store. If the certificate is imported only to the Local User's Trusted Root CA store, Automatic Updates will fail server authentication.
Your client computers must trust the certificate you bind to the WSUS server in IIS. Depending upon the type of certificate you are using, you may have to set up a service to enable the clients to trust the certificate bound to the WSUS server. For more information, see "Further reading about SSL" later in this section.
Configuring SSL for downstream WSUS servers
The following instructions are for configuring a downstream server to synchronize to an upstream server that is using SSL.
To synchronize a downstream server to an upstream server that is using SSL
In the WSUS Administration snap-in, click Options, and then click Update Source and Proxy Server.
In the Update Source box, select Synchronize from another Windows Server Update Services server check box, type the name of the upstream server and the port number it uses for SSL connections, and then select the Use SSL when synchronizing update information check box.
Click OK to save the settings.
Further reading about SSL
Setting up a Certification Authority (CA), binding a certificate to the WSUS Web site, and then bootstrapping client computers to trust the certificate on the WSUS Web site are complex administrative tasks. The step-by-step procedures for each task are beyond the scope of this guide.
However, several articles on the subject are available. For more information and instructions about how to install certificates and set up your environment, see the following pages on the Microsoft Web site.
- The Windows Server 2003 PKI Operations Guide (https://go.microsoft.com/fwlink/?LinkId=83159) provides a guide for administrators about how to configure and operate a Windows Certification Authority.
- How to Set Up SSL on a Web Server offers step-by-step instructions for setting up SSL on a Web site.
- Certificate Autoenrollment in Windows Server 2003 (https://go.microsoft.com/fwlink/?LinkId=17801) offers instructions about how to automatically enroll client computers running Windows XP in Windows Server 2003 Enterprise environments integrated with Active Directory.
- Advanced Certificate Enrollment and Management (https://go.microsoft.com/fwlink/?LinkId=83160) offers guidance about how to automatically enroll client computers in other environments.