Condividi tramite

Considerazioni sulla sicurezza per la comunicazione remota di PowerShell con WinRM

  • Articolo

La comunicazione remota di PowerShell è il metodo 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, i suggerimenti e le procedure consigliate per la comunicazione remota di PowerShell.

Informazioni sulla comunicazione remota di PowerShell

La comunicazione remota di PowerShell usa Gestione remota Windows (WinRM) per consentire agli utenti di eseguire comandi di PowerShell nei computer remoti. WinRM è l'implementazione Microsoft del protocollo Web Services for Management (WS-Management). È possibile trovare altre informazioni sull'uso della comunicazione remota di PowerShell in Esecuzione di comandi remoti.

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

Impostazioni predefinite della comunicazione remota di PowerShell

La comunicazione remota di PowerShell (e WinRM) esegue l'ascolto delle porte seguenti:

  • HTTP: 5985
  • HTTPS: 5986

Per impostazione predefinita, la comunicazione remota di PowerShell consente connessioni solo dai membri del gruppo degli amministratori. Le sessioni vengono avviate nel contesto utente, quindi tutti i controlli di accesso del sistema operativo applicati a singoli utenti e gruppi continuano a essere applicati con la comunicazione remota di PowerShell.

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

Avviso

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

Isolamento del processo

La comunicazione remota di PowerShell usa WinRM per la comunicazione tra computer. WinRM viene eseguito come servizio dell'account del servizio di rete e genera processi isolati eseguiti come account utente per ospitare le istanze di PowerShell. Un'istanza di PowerShell in esecuzione per un solo utente non ha accesso a un processo che esegue un'istanza di PowerShell con un altro account utente.

Registri eventi generati dalla comunicazione remota di Powershell

FireEye ha fornito un ottimo riepilogo dei registri eventi e di altre prove relative alla sicurezza generato dalle sessioni di comunicazione remota di PowerShell, disponibile in Investigating PowerShell Attacks (Ricerche sugli attacchi a PowerShell).

Protocolli di trasporto e crittografia

È 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, l'identità del server al client.

Quando un client si connette a un server di dominio usando il proprio nome di computer, il protocollo di autenticazione predefinito è Kerberos. Kerberos garantisce l'identità dell'utente e l'identità del server senza inviare credenziali riutilizzabili.

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 questo caso la comunicazione remota di PowerShell si basa sul protocollo di autenticazione NTLM, che garantisce l'identità dell'utente senza che sia necessario inviare credenziali delegabili. Per dimostrare l'identità dell'utente, il protocollo NTLM richiede che sia il client che il server calcolino una chiave di sessione dalla password dell'utente senza mai scambiare la stessa password. 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 con tutti i protocolli che usano NTLM per l'autenticazione, un utente malintenzionato con accesso all'account computer di un computer aggiunto al dominio può richiamare il controller di dominio per calcolare una chiave di sessione NTLM e quindi rappresentare il server.

L'autenticazione basata su NTLM è disabilitata per impostazione predefinita, ma è ammessa una configurazione di SSL nel server di destinazione o la configurazione dell'impostazione TrustedHosts di WinRM.

Uso di 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 che anche il client considera attendibile, consente l'autenticazione basata su NTLM, che garantisce l'identità sia dell'utente che del server.

Ignorare gli errori di identità del server basata su NTLM

Se la distribuzione di un certificato SSL a un server per le connessioni NTLM non è applicabile, è possibile eliminare gli errori di identità risultanti aggiungendo il server all'elenco TrustedHosts di WinRM. Si noti che l'aggiunta di un nome server all'elenco TrustedHosts non deve essere considerata come una forma di dichiarazione di attendibilità degli host stessi, perché il protocollo di autenticazione NTLM non può garantire che ci si stia effettivamente connettendo all'host a cui si intende connettersi. In alternativa, considerare l'impostazione di TrustedHosts come elenco degli host per i quali eliminare l'errore generato dall'impossibilità di verificare l'identità del server.

Comunicazione continua

Dopo aver completato l'autenticazione iniziale, WinRM crittografa tutte le comunicazioni continue. Quando si esegue la connessione tramite HTTPS, il protocollo TLS viene usato per negoziare la crittografia usata per il trasporto dei dati. Quando si esegue la connessione tramite HTTP, la crittografia a livello di messaggio è determinata dal protocollo di autenticazione iniziale usato.

  • L'autenticazione di base non prevede alcuna crittografia.
  • L'autenticazione NTLM usa la crittografia RC4 con chiave a 128 bit.
  • La crittografia di autenticazione Kerberos è determinata da etype nel ticket TGS. È AES-256 nei sistemi moderni.
  • La crittografia CredSSP usa il pacchetto di crittografia TLS negoziato nell'handshake.

Esecuzione del 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. Ciò è noto come "problema del secondo hop".

Ci sono diversi modi per evitare questo problema. Per le descrizioni di questi metodi e dei vantaggi e svantaggi di ogni metodo, vedere Creazione del secondo hop nella comunicazione remota di PowerShell.

Riferimenti