Condividi tramite

Considerazioni sulla sicurezza per la comunicazione remota di PowerShell tramite WinRM

La comunicazione remota di PowerShell è il modo consigliato per gestire i sistemi Windows. La comunicazione remota di PowerShell è abilitata per impostazione predefinita in Windows Server 2012 R2 e versioni successive. Questo documento illustra i problemi di sicurezza, le raccomandazioni e le procedure consigliate per l'uso della comunicazione remota di PowerShell.

Che cos'è il Remoting di PowerShell?

La comunicazione remota di PowerShell usa Windows Remote Management (WinRM) per consentire agli utenti di eseguire comandi di PowerShell su computer remoti. WinRM è l'implementazione Microsoft del protocollo Web Services for Management (WS-Management). Per altre informazioni sull'uso della comunicazione remota di PowerShell, vedere Esecuzione di comandi remoti.

La comunicazione remota di PowerShell non equivale all'uso del parametro NomeComputer di un cmdlet per eseguirlo in un computer remoto, che usa Remote Procedure Call (RPC) come protocollo sottostante.

Impostazioni predefinite per la comunicazione remota di PowerShell

La funzionalità di comunicazione remota di PowerShell con WinRM ascolta sulle seguenti porte:

  • HTTP: 5985
  • HTTPS: 5986

Per impostazione predefinita, la comunicazione remota di PowerShell consente solo le connessioni dai membri del gruppo Administrators. Le sessioni vengono avviate nel contesto dell'utente, quindi tutti i controlli di accesso al sistema operativo applicati a singoli utenti e gruppi continuano ad applicarle durante la connessione tramite la comunicazione remota di PowerShell.

Nelle reti private la regola predefinita di Windows Firewall per la comunicazione remota di PowerShell accetta tutte le connessioni. Sulle reti pubbliche, la regola predefinita del Firewall di Windows consente connessioni Remoting di PowerShell solo dall'interno della stessa subnet. È necessario modificare in modo esplicito tale regola per aprire la comunicazione remota di PowerShell a tutte le connessioni in una rete pubblica.

Avvertimento

La regola del firewall per le reti pubbliche è destinata a proteggere il computer da tentativi di connessione esterna potenzialmente dannosi. Prestare attenzione quando si rimuove questa regola.

Isolamento dei processi

La comunicazione remota di PowerShell usa WinRM per la comunicazione tra computer. WinRM viene eseguito come servizio con l'account del servizio di rete e genera processi isolati in esecuzione come account utente per ospitare istanze di PowerShell. Un'istanza di PowerShell in esecuzione da un utente non ha accesso a un processo in cui è eseguita un'istanza di PowerShell da un altro utente.

Log eventi generati dal remoting di PowerShell

I ricercatori di Mandiant hanno presentato una sessione alla conferenza BlackHat che fornisce un buon riepilogo dei registri eventi e altre prove di sicurezza generate dalle sessioni di comunicazione remota di PowerShell. Per ulteriori informazioni, vedere Indagine sugli attacchi PowerShell.

Protocolli di crittografia e trasporto

È utile considerare la sicurezza di una connessione remota di PowerShell da due prospettive: l'autenticazione iniziale e la comunicazione continua.

Indipendentemente dal protocollo di trasporto usato (HTTP o HTTPS), WinRM crittografa sempre tutte le comunicazioni remote di PowerShell dopo l'autenticazione iniziale.

Autenticazione iniziale

L'autenticazione conferma l'identità del client al server e idealmente il server al client.

Quando un client si connette a un server di dominio usando il relativo nome computer, il protocollo di autenticazione predefinito è Kerberos. Kerberos garantisce sia l'identità utente che l'identità del server senza inviare alcuna sorta di credenziale riutilizzabile.

Quando un client si connette a un server di dominio usando il relativo indirizzo IP o si connette a un server del gruppo di lavoro, l'autenticazione Kerberos non è possibile. In tal caso, la comunicazione remota di PowerShell si basa sul protocollo di autenticazione NTLM . Il protocollo di autenticazione NTLM garantisce l'identità utente senza inviare alcuna sorta di credenziale delegabile. Per dimostrare l'identità utente, il protocollo NTLM richiede che sia il client che il server calcolano una chiave di sessione dalla password dell'utente senza mai scambiare la password stessa. Il server in genere non conosce la password dell'utente, quindi comunica con il controller di dominio, che conosce la password dell'utente e calcola la chiave di sessione per il server.

Il protocollo NTLM non garantisce tuttavia l'identità del server. Come per tutti i protocolli che usano NTLM per l'autenticazione, un utente malintenzionato con accesso a un account computer aggiunto a un dominio potrebbe richiamare il controller di dominio per calcolare una chiave di sessione NTLM e rappresentare il server.

L'autenticazione basata su NTLM è disabilitata per impostazione predefinita. È possibile abilitare NTLM configurando SSL nel server di destinazione o configurando l'impostazione TrustedHosts WinRM nel client.

Uso dei certificati SSL per convalidare l'identità del server durante le connessioni basate su NTLM

Poiché il protocollo di autenticazione NTLM non è in grado di garantire l'identità del server di destinazione (solo che conosce già la password), è possibile configurare i server di destinazione per l'uso di SSL per la comunicazione remota di PowerShell. L'assegnazione di un certificato SSL al server di destinazione (se emesso da un'autorità di certificazione attendibile anche dal client) abilita l'autenticazione basata su NTLM che garantisce sia l'identità utente che l'identità del server.

Ignorare gli errori di identità del server basati su NTLM

Se la distribuzione di un certificato SSL in un server per le connessioni NTLM non è possibile, è possibile eliminare gli errori di identità risultanti aggiungendo il server all'elenco di TrustedHosts WinRM. L'aggiunta di un nome server all'elenco di TrustedHosts non deve essere considerata una forma di dichiarazione di attendibilità degli host stessi, perché il protocollo di autenticazione NTLM non può garantire che ci si stia connettendo all'host a cui si intende connettersi. È invece consigliabile considerare l'impostazione TrustedHosts come l'elenco degli host per cui si desidera eliminare l'errore generato non essendo in grado di verificare l'identità del server.

Comunicazione in corso

Al termine dell'autenticazione iniziale, WinRM crittografa la comunicazione in corso. Quando ci si connette tramite HTTPS, WinRM usa il protocollo TLS per negoziare la crittografia usata per il trasporto dei dati. Quando ci si connette tramite HTTP, WinRM usa la crittografia a livello di messaggio negoziata dal protocollo di autenticazione iniziale.

  • L'autenticazione di base non fornisce alcuna crittografia.
  • L'autenticazione NTLM usa una crittografia RC4 con una chiave a 128 bit.
  • Il etype nel ticket TGS determina la crittografia di autenticazione Kerberos. Questo è AES-256 nei sistemi moderni.
  • La crittografia CredSSP usa la suite di crittografia TLS negoziata nell'handshake.

Fare il secondo hop

Per impostazione predefinita, la comunicazione remota di PowerShell usa Kerberos (se disponibile) o NTLM per l'autenticazione. Entrambi questi protocolli eseguono l'autenticazione al computer remoto senza inviare le credenziali. Si tratta del modo più sicuro per l'autenticazione, ma poiché il computer remoto non dispone delle credenziali dell'utente, non può accedere ad altri computer e servizi per conto dell'utente. Questo problema è noto come secondo problema hop.

Esistono diversi modi per evitare questo problema. Per le descrizioni di questi metodi e i vantaggi e i svantaggi di ognuno di essi, vedere Creazione del secondo hop nella comunicazione remota di PowerShell.

Riferimenti

  • Last updated on