HTTP-Proxy and Windows Updates

Windows updates through the HTTP-Proxy and the webfilter

Last adaptation to the version: 12.6.0

New:

Updated to Redesign of the webinterface

notempty

This article refers to a Resellerpreview

11.7

Introduction

Some Microsoft servers are called up for Windows updates, which make the individual files available. If a Windows client is directly connected to the Internet, this is not a problem as there are no rules that regulate website calls.

In a network environment, these rules can quickly have negative effects, so it is advisable to filter data traffic via port filters and proxies in order to offer malware as little attack surface as possible.

A good firewall configuration is characterized by the fact that each client only gets the permissions it really needs. For most users who access websites on the Internet, this means that they are routed via the HTTP proxy so that website calls are regulated via the webfilter and the data packets are scanned for viruses.

Windows uses a system account to connect to the Microsoft servers and download updates. It is neither possible to enter a proxy nor to use authentication against the HTTP proxy.

In the following documentation, we present three scenarios that allow the Windows update via the HTTP proxy and the webfilter if the UTM is entered as a proxy in the Windows Internet settings or the individual applications, i.e. it is not interposed as a transparent proxy.

Scenario 1: Standard proxy without authentication

Webfilter

Add rule set UTMuser@firewall.name.fqdnApplicationWebfilter Copy rule set Webfilter rule

In this case, the HTTP proxy is used in transparent mode for the system accounts of the clients, in which only the websites required for the Windows update are released in the Webfilter.
A list of the pages to which access is required can be found on these pages:

*windowsupdate.microsoft.com/*
*update.microsoft.com/*
*.windowsupdate.com/*
*download.microsoft.com/*
*test.stats.update.microsoft.com/*
www.msftncsi.com/ncsi*
*ntservicepack.microsoft.com/*
*.delivery.mp.microsoft.com/*

The asterisks before and after the URLs are wildcards.

Webfilter UTMuser@firewall.name.fqdnApplication Webfilter Log Webfilter profile with rule

After the corresponding URLs have been added via the URL field of the rule set, they are switched to allow.
As the last entry in the list, two asterisks ** are entered in the URL field and the rule is set to block. This blocks all URLs that are not entered as permitted before the last rule in the rule set.
This rule set is saved and added to the profile of the internal-networks network group in our example.
The security rule set can be removed in this profile, as all other URLs are not permitted by this rule set anyway.
The menu for the web filter can be found under the Applications menu item.
The HTTP proxy menu is also called up under Applications. Here you must first check whether the transparent mode is activated and whether there is a rule with which data packets from the source internal-network with the destination internet and the protocol HTTP are to be routed via the proxy.

Virus scanner

HTTP Proxy UTMuser@firewall.name.fqdnApplication HTTP-Proxy Log Virus scanner whitelist

Just like the updates of the local virus scanners, the Microsoft update packages do not like to be checked by a virus scanner.

This is why the URLs of the Microsoft update servers must also be added to the whitelist of the virus scanner. It should be noted at this point that these are regular expressions, in which some characters have additional meanings. These special meanings are removed with a backslash \ in front of the character. For example, a dot can be a placeholder for any character.

A list of the pages to which access is required can be found on these pages:

^[^:]*://[^\.]*\.windowsupdate\.microsoft\.com/
^[^:]*://[^\.]*\.update\.microsoft\.com/
^[^:]*://[^\.]*\.download\.microsoft\.com/
^[^:]*://[^\.]*\.windowsupdate\.com/

Scenario 2: Standard proxy with authentication via NTLM

Authentication exception

HTTP Proxy UTMuser@firewall.name.fqdnApplication HTTP-Proxy Log Webfilter profile with rule

The webfilter and virus scanner are configured in the same way as in scenario 1, but authentication exceptions are required, as the Windows system account cannot authenticate itself to the proxy. Therefore, the URLs called up must also be defined here again. This is also done using regular expressions:
In this case, the HTTP proxy is used in transparent mode for the system accounts of the clients, in which only the websites required for the Windows update are released in the Webfilter.

A list of the pages to which access is required can be found on these pages:

.*\.update\.microsoft\.com
.*\.windowsupdate\.microsoft\.com
.*\.windowsupdate\.com
.*\.download\.microsoft\.com
www\.msftncsi\.com

As the HTTP or HTTPS protocol is no longer taken into account at this point, these expressions are somewhat shorter than in the virus scanner.

Szenario 3: Standard proxy with authentication via NTLM and use of SSL interception

SSL-Interception

HTTP Proxy UTMuser@firewall.name.fqdnApplication HTTP-Proxy Log SSL interception exceptions

If the SSL interception is used to also check the encrypted data packets for malware, the Microsoft servers must also be stored here as Exceptions for SSL interception'.
The same expressions are used for this as for the authentication exception.
In this case, the HTTP proxy is used in transparent mode for the system accounts of the clients, in which only the websites required for the Windows update are released in the Webfilter.

A list of the pages to which access is required can be found on these pages:

.*\.update\.microsoft\.com
.*\.windowsupdate\.microsoft\.com
.*\.windowsupdate\.com
.*\.download\.microsoft\.com
www\.msftncsi\.com

HTTP-Proxy and Windows Updates

Contents

Introduction

Standard proxy without authentication

Webfilter

Virus scanner

Standard proxy with authentication via NTLM

Authentication exception

Standard proxy with authentication via NTLM and SSL interception

SSL-Interception