Secure Your WSUS Deployment

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2, Windows Server Update Services

This guide includes three ways to further enhance the security of your WSUS server:

  • Recommendations for hardening your Windows Server 2003 running WSUS.

  • Recommendations for adding authentication between chained WSUS servers in an Active Directory environment.

  • Recommendations for implement 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 D: Security Settings. These recommendations include hardening a number of Windows Server components as well as IIS 6.0 and SQL Server 2000. If you are not running Windows Server 2003 or if you are not using SQL Server 2000 as your database software for WSUS, you may not be able to utilize all of these settings.

Adding Authentication Between 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. Also, 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. First, you create a list of downstream WSUS servers allowed to authenticate with this WSUS server; add this list to a text file that was created when you originally installed WSUS. Second, in IIS, you 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:

%ProgramFiles%\Update Services\WebServices\Serversyncwebservice\Web.config

Use the <authorization> element to define an authentication list. You must add the <authorization> element below the <configuration> and <system.web> elements.

Consider the example below:

<configuration>
<system.web>
<authorization>
<allow users="domain\computer_name,domain\computer_name" />
<deny users="*" />
</authorization>
</system.web>
</configuration>

Within 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.

The XML schema for this list can be found on an MSDN Web site at https://go.microsoft.com/fwlink/?LinkId=47691.

Step 2: Configure IIS

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

  1. On the Start menu, point to Programs, point to Administrator Tools, and then click Internet Information Services Manager.

  2. Expand the local computer node.

  3. Expand the WSUS Web site node.

  4. Right-click SeverSyncWebService, and then click Properties.

  5. On the Directory Security tab, under Authentication and access control, click Edit.

  6. In the Authentication Methods dialog box, clear the Enable anonymous access check box and select the Integrated Windows authentication check box.

  7. Click OK twice.

Securing WSUS with Secure Sockets Layer

You can use 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 metadata passed between clients and downstream WSUS servers. Note that WSUS only uses SSL for metadata. This is also the way Microsoft Update distributes updates.

As discussed earlier in this guide, updates consist of two parts: metadata that describes what an update is useful for, 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 tampered with, it is not installed.

Limitations of WSUS SSL Deployments

There are two limiting issues that administrators considering WSUS SSL deployments need to know about.

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 metadata sent over the wire.

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 Deployment page offers guidance on 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 encrypting metadata with HTTPS and one for clear HTTP. When you configure IIS to use the certificate, 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 only encrypts metadata traffic. When a client computer or another WSUS server attempted to get update files from WSUS, the transfer would fail because there is no way for WSUS to distribute the file by using plain HTTP.

    To keep WSUS Web site as secure as possible, only require SSL for the following virtual roots:

    • SimpleAuthWebService

    • DSSAuthWebService

    • ServerSyncWebService

    • WSUSAdmin

    • ClientWebService

    To keep WSUS functioning, you should not require SSL for the following virtual roots:

    • Content

    • ReportingWebService

    • SelfUpdate

  • The certificate on downstream WSUS servers has to be imported into either the Local Computer's Trusted Root CA store or Windows Server Update Service's Trusted Root CA store. If the certificate is only imported to the Local User's Trusted Root CA store, the downstream WSUS server will fail server authentication on the upstream server.

  • 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 the 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.

Note

If you change the port number or want to use HTTPS to access the WSUS administration console, you have to create a new shortcut on your Start menu with the new URL in order to access the WSUS administration console from the Start menu. See Help and Support in Windows Server 2003 for information about creating shortcuts.

Sample SSL URLs to Access WSUS Administrative Console

This section includes sample URLs to use for accessing the WSUS administrative console when you have configured WSUS to use SSL.

Accessing WSUS Administrative Console by Using Industry Standard Port Assignments for SSL

If you were to install WSUS to the default site, and then set up SSL to use industry standard port assignments, you would use the following URL to access the WSUS administrative console over a secure connection:

https://WSUSServerName/WSUSAdmin/

Note

Remember that if you change WSUS port assignments after installation and you are using SSL, WSUS uses the rules noted above to assign a port for the HTTP protocol.

Accessing WSUS Administrative Console by Using Custom Port Assignments for SSL

If you were to install WSUS to the custom site, and then set up SSL to use a custom port assignment of 8531 for the SSL port, you would then use the following URL to access the WSUS administrative console by using a secure connection:

https://WSUSServerName: 8531/WSUSAdmin/

Note

You do not have to use 8531 for the SSL port. You can use any free port, but WSUS requires two ports for SSL: the port that you assign and the port that numerically precedes it. For example, if you pick 2424 for SSL port, WSUS would use 2424 for HTTPS and 2423 for HTTP.

Configuring SSL on Client Computers

There are two important caveats when configuring client computers:

  • You must include a URL for a secure port that the WSUS server is listening on. 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.

    For example, you might use https://ssl-servername:3051 to point clients to a WSUS server that is using a custom SSL port of 3051.

    Likewise, you might use https://ssl-servername for a WSUS server that is using port 443 for HTTPS.

    For more information about how to point client computers to the WSUS server, see "Specify intranet Microsoft Update service location" in Configure Automatic Updates by 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 only imported 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" later in this section.

Sample SSL URLs to Point Automatic Updates to WSUS

This section includes sample URLs to use to point Automatic Updates to WSUS when you have configured WSUS to use SSL.

Point Automatic Updates to WSUS Using Industry Standard Port Assignments for SSL

If you were to install WSUS to the default site, and then set up SSL to use industry standard port assignments, you would use the following URL to point Automatic Updates to WSUS server:

https://WSUSServerName

Point Automatic Updates to WSUS Using Custom Port Assignments for SSL

If you were to install WSUS to the custom site, and then set up SSL to use a custom port assignment of 8531 for the SSL port, you would use the following URL to point Automatic Updates to WSUS server:

https://WSUSServerName: 8531

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 connect a downstream server to an upstream server set up to use SSL

  1. In the WSUS console toolbar, click Options, and then click Synchronization Options.

  2. In the Update Source box, click Synchronize from an upstream Windows Server Update Services server, enter 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.

  3. Under Tasks, click Save settings, and then click OK when the confirmation dialog box appears.

Further Reading on 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 on how to install certificates and set up your environment, see the following pages on the Microsoft Web site.