Dic0820178 Dicembre 20178 Dicembre 20170Commentidi Ermanno Goletto

Windows 10 e Windows Update lento

Pubblicato in IT, Security

Circa dalla versione 1703 di Windows 10 ho riscontrato una lentezza è talvolta impossibilità di eseguire Windows Update in scenari in cui i client accedono ad Internet tramite un proxy e non sono in grado di eseguire query DNS per risolvere nomi di dominio esterni.

Lo scenario tipico in cui ho osservato tale problematica è quello in cui i client non a dominio accedono ad Internet tramite ForeFront TMG e utilizzano come DNS i Domain Controller che non sono in grado di eseguire la risoluzione dei nomi di dominio esterni, utilizzano i forwarder solo per risolvere i nomi di alcuni domini esterni necessari al funzionamento di determinati applicativi aziendali.

Come ho già detto la problematica è probabilmente sorta con la versione 1703 di Windows 10 in quanto con Windows 10 1607 LTSB nel medesimo scenario non era mai stata registrata la problematica di lentezza o impossibilità da parte di Windows Update. Anche con Windows Server 2016 ho registrato problemi simili che descritto nel post Windows Server 2016 e Windows Update tramite proxy, ma le soluzioni che avevo proposto in quel post sarebbero state troppo impattanti da applicare.

Dopo alcune analisi tramite il tool DNSQuerySniffer di NirSoft ho capito che il problema risiedeva nel fatto che il client falliva alcune risoluzioni verso domini esterni di Microsoft e quindi utilizzava server di download per gli aggiornamenti probabilmente congestionati. In questo modo gli aggiornamenti venivano scaricati ma in modo estremante lento tale da generare spesso errori.

Un’altra possibile causa di questa problematica è fornita nella KB3084568 – Can’t download updates from Windows Update from behind a firewall or proxy server in cui viene riportato che Windows utilizza Microsoft Windows HTTP Services (WinHTTP) per comunicare con i Microsoft Update servers e il Background Intelligent Transfer Service (BITS) e varie possono essere le ragioni per cui il client non riesce a fare chiamate esterne come il blocco del traffico sulle porte TCP 80 (HTTP) e TCP 443 (HTTPS), impostazioni non corrette del client proxy o il mancato supporto al da parte del proxy o del firewall al TLS 1.2 che è un prerequisito per l’utilizzo degli Update Services da parte del Windows Update client nelle versioni:

  • Windows 7 SP1: 7.6.7600.320
  • Windows 8: 7.8.9200.16924
  • Windows 8.1: 7.9.9600.17122
  • Windows 10 RTM

Tornando allo scenario che ho analizzato per risolvere il problema, partendo dalle indicazioni fornite nella KB3084568 relative agli URL che devono essere consentiti per comunicare con i Microsoft Update services, ho fatto in modo che i client riuscissero a risolvere tramite i Domain Controller i dominii Microsoft necessari.

Scendendo nel dettaglio partendo dal fatto che gli URL utilizzati dai Microsoft Update services sono:

  • update.microsoft.com
  • *.update.microsoft.com
  • download.windowsupdate.com
  • *.download.windowsupdate.com
  • download.microsoft.com
  • *.download.microsoft.com
  • windowsupdate.com
  • *.windowsupdate.com
  • ntservicepack.microsoft.com
  • wustat.windows.com
  • login.live.com (richiesto se si è connessi tramite un Microsoft Account)
  • mp.microsoft.com
  • *.mp.microsoft.com

Ho configurato sui Domain Controller mediante forward la risoluzione DNS per i seguenti dominii:

  • microsoft.com
  • windows.com
  • windowsupdate.com

Analizzano le query fallite sui client ho rilevato anche altri dominii Microsoft su cui viene tentata una risoluzione e l’accesso anche se non sono correlati all’uso dei Microsoft Update services, ma li riporto lo stesso per completezza:

  • msftconnecttest.com
  • msftncsi.com

A riguardo si veda la sezione Network Connection Status Indicator descritta in Manage connections from Windows operating system components to Microsoft services:

Network Connection Status Indicator (NCSI) detects Internet connectivity and corporate network connectivity status. NCSI sends a DNS request and HTTP query to http://www.msftconnecttest.com/connecttest.txt to determine if the device can communicate with the Internet. For more info about NCSI, see The Network Connection Status Icon.

In versions of Windows 10 prior to Windows 10, version 1607 and Windows Server 2016, the URL was http://www.msftncsi.com.

Ossevazioni conclusive

L’utilizzo della tecnica di impedire ai client la risoluzione di nomi di dominio esterni anche tramite DNS interni che eseguono il forward verso DNS in grado di risolvere nomi pubblici deriva da un approccio di anni fa in cui si tendeva a far sì che i client indirizzassero tutto il traffico verso destinazioni esterni al proxy che si occupava di consentire l’accesso e di gestire le risoluzioni di nomi necessarie in modo controllato. Questo approccio avevo lo scopo di limitare eventuali accessi da parte del malware a destinazioni Internet tramite nomi di dominio esterno. Ormai però tale approccio è del tutto sorpassato in quanto i malware odierni sono pienamente in grado di utilizzare eventuali proxy per l’accesso a Internet, è meglio controllare in modo centrale le query DNS utilizzando sistemi aggiornati che impediscano risoluzioni verso nomi di dominio malevoli o compromessi.

A riguardo si veda anche l’Alert TA15-240 dello US-CERT – Controlling Outbound DNS Access: e, come indicato nell’Alert, la NIST Special Publication 800-81-2 – Secure Domain Name System (DNS) Deployment Guide:

Implement the recommendations below to provide a more secure and efficient DNS infrastructure. Please note that these recommendations focus on improving the security of outbound DNS query or responses and do not encompass all DNS security best practices.

  • Configure operating systems and applications (including lower-tier DNS servers intended to forward queries to controlled enterprise DNS servers) to use only authorized DNS servers within the enterprise for outbound DNS resolution.
  • Configure enterprise perimeter network devices to block all outbound User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) traffic to destination port 53, except from specific, authorized DNS servers (including both authoritative and caching/forwarding name servers).
    • Additionally, filtering inbound destination port 53 TCP and UDP traffic to only allow connections to authorized DNS servers (including both authoritative and caching/forwarding name servers) will provide additional protections.
  • Refer to Section 12 of the NIST Special Publication 800-81-2 for guidance when configuring enterprise recursive DNS resolvers.