Informazioni tecniche sulle connessioni agentless per i sistemi Windows

Le connessioni agentless sui sistemi Windows si basano sul protocollo di connessione remota WinRM. Questo protocollo deve quindi essere attivato sugli asset da monitorare.

Per impostazione predefinita, questo protocollo utilizza la porta 5985 in modalità WinRM HTTP e la 5986 in modalità WinRM HTTPS.

Il corretto funzionamento delle connessioni agentless su Windows può richiedere alcuni passaggi di configurazione descritti di seguito.

Prerequisiti necessari per l’utilizzo delle connessioni agentless

L’account utilizzato da Cyberwatch deve essere membro del gruppo Administrators locale degli asset, poiché gli script di analisi richiamano metodi che richiedono privilegi:

• utilizzo di DISM (Deployment Imaging and Servicing Management) - recupero delle versioni delle KB installate -
• utilizzo dell’API WUA (Windows Update Agent) - eliminazione / download / gestione del file .cab, gestione dei servizi WUA, distribuzione degli aggiornamenti -
• accesso alle directory soggette a privilegi - %APPDATA% di tutti gli utenti per il recupero delle versioni delle applicazioni installate -
• privilegi potenzialmente necessari per l’esecuzione degli script di analisi della conformità

Utilizzare un account di dominio (consigliato)

Sugli asset aggiunti a un dominio Active Directory, utilizzare un account di dominio dedicato a Cyberwatch, membro del gruppo Administrators locale degli asset da monitorare. Questa appartenenza può essere distribuita tramite una GPO, con i «Gruppi con restrizioni» o con le preferenze di Criteri di gruppo «Utenti e gruppi locali».

Nella credenziale salvata WinRM con HTTP Negotiate, inserire l’account nel formato DOMINIO\utente. Questo connettore si autentica tramite NTLM. Se il dominio limita NTLM, utilizzare il connettore WinRM con Kerberos descritto nella sezione «Utilizzo di WinRM-Kerberos» riportata di seguito.

Un account di dominio presenta due vantaggi rispetto a un account locale:

• resta utilizzabile sugli asset che rifiutano la connessione di rete agli account locali
• non richiede la chiave di registro LocalAccountTokenFilterPolicy, poiché l’UAC non filtra il token di un account di dominio durante una connessione remota

Utilizzare un account locale

Sugli asset non appartenenti a un dominio (gruppo di lavoro), creare un utente locale Cyberwatch membro del gruppo Administrators locale, utilizzando ad esempio il comando seguente:

$UserPassword = Read-Host -AsSecureString       # Une fois la commande validée, saisir un mot de passe pour l'utilisateur Cyberwatch
New-LocalUser "Cyberwatch" -Password $UserPassword
Add-LocalGroupMember -Group 'Administrateurs' -Member Cyberwatch -Verbose

Su un sistema in lingua inglese è necessario utilizzare Administrators.

Un account locale richiede inoltre la chiave di registro LocalAccountTokenFilterPolicy, descritta nella sezione Attivazione di WinRM.

Un asset può rifiutare qualsiasi connessione di rete agli account locali, con il diritto utente «Nega accesso al computer dalla rete» (SeDenyNetworkLogonRight) contenente Account locale o Account locale e membro del gruppo Administrators. Questa impostazione è richiesta dalla regola SBP-WIN-04-007 del framework Security_Best_Practice_Windows, nonché dalle baseline di sicurezza Microsoft e CIS. Su questi asset, una connessione agentless con un account locale non riesce: utilizzare un account di dominio o l’agent Cyberwatch.

Gli utenti membri dei gruppi Protected Users o gMSA non possono utilizzare il servizio WinRM. È quindi necessario fare attenzione a non includere l’account utilizzato da Cyberwatch, di dominio o locale, in uno di questi gruppi.

Attivazione di WinRM

Il comando PowerShell seguente attiva il servizio WinRM se è disattivato e configura di conseguenza il firewall di Windows:

Enable-PSRemoting -Force

Con un account locale, la sola attivazione di WinRM non è sufficiente: è necessario autorizzare gli account amministratore locali a connettersi tramite WinRM, altrimenti Cyberwatch riporterà l’errore WinRM::WinRMAuthorizationError durante la creazione della connessione agentless. Questo passaggio non è necessario con un account di dominio.

A tal fine, è necessario aggiungere la chiave seguente nel registro di sistema:

New-ItemProperty -Name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1

Questa chiave disattiva il filtro del token da parte dell’UAC per le connessioni di rete degli account locali. Fa fallire la regola SBP-WIN-05-005 «Ensure UAC token filtering is not disabled for network logons» del framework Security_Best_Practice_Windows. Un account di dominio evita questa impostazione.

Infine, il comando seguente consente di verificare che il servizio WinRM sia avviato e lo avvia se ciò non è stato effettuato correttamente:

winrm quickconfig

Autenticazione Basic e traffico non crittografato

Nessun connettore WinRM di Cyberwatch ha bisogno dell’autenticazione Basic né del traffico non crittografato. I connettori WinRM con HTTP Negotiate e WinRM con Kerberos crittografano ogni messaggio, e il connettore WinRM con SSL passa inoltre per TLS. Il connettore WinRM con Plaintext tramite HTTPS crittografa solo tramite TLS e ripiega sull’autenticazione Basic quando il servizio propone solo quella: preferirgli WinRM con SSL.

Non eseguire i comandi Set-Item WSMan:\localhost\Service\Auth\Basic $true e Set-Item WSMan:\localhost\Service\AllowUnencrypted $true, né i loro equivalenti winrm set winrm/config/service/auth @{Basic="true"} e winrm set winrm/config/service @{AllowUnencrypted="true"}, spesso proposti da guide di terze parti. Insieme, consentono l’invio delle credenziali in chiaro sulla rete (autenticazione Basic su HTTP). Ciascuno fa fallire la regola SBP-WIN-08-002 «Ensure WinRM does not allow Basic authentication or unencrypted traffic» del framework Security_Best_Practice_Windows.

Le due impostazioni valgono false per impostazione predefinita. I comandi seguenti, in un prompt PowerShell avviato come amministratore, le visualizzano e poi le ripristinano:

Get-Item WSMan:\localhost\Service\Auth\Basic, WSMan:\localhost\Service\AllowUnencrypted
Set-Item -Path WSMan:\localhost\Service\Auth\Basic -Value $false
Set-Item -Path WSMan:\localhost\Service\AllowUnencrypted -Value $false

Se una GPO impone queste impostazioni, Set-Item non riesce: la correzione va fatta nella GPO. Impostare su «Disattivata» i parametri «Consenti autenticazione di base» (Allow Basic authentication) e «Consenti traffico non crittografato» (Allow unencrypted traffic), nei modelli amministrativi, sotto Windows Components > Windows Remote Management (WinRM) > WinRM Service.

Facoltativo - Disattivare manualmente il firewall per WinRM

Talvolta può essere necessaria una disattivazione manuale del firewall di Windows nonostante le operazioni precedenti, in particolare sulle macchine AWS-EC2. In questo caso, l’errore riportato da Cyberwatch è Connection expired.

Il comando PowerShell seguente consente di autorizzare le richieste TCP in ingresso sulla porta 5985 a livello del firewall di Windows:

netsh advfirewall firewall add rule name="WinRM-HTTP" dir=in localport=5985 protocol=TCP action=allow

Facoltativo - Utilizzo di WinRM-Kerberos

Il connettore WinRM con Kerberos richiede un account di dominio. Sostituisce il connettore WinRM con HTTP Negotiate quando il dominio limita l’autenticazione NTLM.

Kerberos è un protocollo di autenticazione basato sul principio di una terza parte attendibile. Il suo funzionamento si basa su un centro di distribuzione delle chiavi (KDC), che consente di emettere ticket che autorizzano l’utente ad accedere alle risorse di rete. Il funzionamento è simile a quello dei sistemi di autenticazione SSO.

Il processo di autenticazione Kerberos è il seguente:

• Il client avvia una richiesta di autenticazione presso il KDC
• Se le informazioni vengono convalidate dal KDC, questo emette un ticket di concessione ticket (TGT)
• Il client presenta quindi il TGT per richiedere l’autenticazione su un servizio
• Il servizio in questione invia il TGT al KDC per la convalida
• Una volta convalidato, il KDC emette un ticket finale che consente l’autenticazione del client sul servizio

Per poter utilizzare questo protocollo, è necessario inserire diversi elementi:

• Dominio: dominio in cui sono raggruppate le risorse Kerberos. Nel caso di un’autenticazione WinRM, rappresenta il dominio di Active Directory
• KDC: server attendibile che consente la distribuzione dei ticket. In un dominio Active Directory, corrisponde al FQDN del domain controller
• Server di amministrazione: server attendibile che consente la concessione dei ticket di servizio ai client. In un dominio Active Directory, corrisponde al FQDN del domain controller

È quindi necessario fornire una coppia nome utente/password autorizzata ad autenticarsi sul dominio Active Directory indicato.

Prerequisiti per l’utilizzo di WinRM-Kerberos

Il server Cyberwatch deve essere in grado di risolvere i nomi di dominio:

• del KDC (Key Distribution Center)
• del server di amministrazione
• di ciascun asset da monitorare