PowerShell Remoting (PSRemoting) è una delle funzionalità più utilizzate in PowerShell. Perché? Perché è estremamente utile! Utilizzando un singolo comando, puoi connetterti senza soluzione di continuità a uno o migliaia di computer remoti ed eseguire comandi.
In questa Guida definitiva, approfondirai PSRemoting. Imparerai cos’è, come funziona e tutte le varie tecnologie che rendono possibile l’utilizzo di PSRemoting. Questa guida non spiegherà come utilizzare PSRemoting. Troverai molti riferimenti alle nostre guide pratiche nel corso del testo.
Come funziona PSRemoting
In poche parole, PSRemoting ti consente di eseguire comandi su computer remoti come se ti trovassi di fronte ad essi. PSRemoting fornisce un insieme di funzionalità che consentono di connettersi e autenticare un utente, eseguire comandi remoti e restituire eventuali output di tali comandi al computer locale.
Pensa a PSRemoting come a telnet, SSH o anche psexec. È solo un modo per eseguire comandi sui computer tramite PowerShell.
PSRemoting si basa ampiamente su un concetto chiamato sessione. Una sessione è un termine utilizzato per descrivere una shell remota che esegue comandi al suo interno. Il processo per creare una di queste sessioni passa attraverso vari passaggi in background.
Quando avvii una sessione PSRemoting, vengono eseguiti approssimativamente i seguenti passaggi:
- Il client tenta di connettersi al server di destinazione su un listener WinRM (più dettagli sui listener WinRm di seguito). Un listener WinRM è un piccolo servizio web che viene eseguito sul server di destinazione. WinRM è l’implementazione di Microsoft di uno standard chiamato WSMan. WSMan è uno standard aperto creato con molte altre grandi aziende tecnologiche dell’epoca come Dell, Intel e Sun Microsystems.
- Quando il client si connette al listener tramite il protocollo HTTP o HTTPS, inizia il processo di autenticazione. Tutti i dettagli di ciascun metodo di autenticazione saranno trattati in seguito, ma per ora, sappiate solo che il client deve passare le credenziali al server in qualche modo.
- Dopo che il client si è connesso e autenticato al server, PSRemoting crea una sessione.
- Una volta che PSRemoting crea la sessione, questa è pronta per essere utilizzata. A questo punto, il client può iniziare a inviare informazioni al server, che restituirà eventuali output necessari noti come serializzazione. Questa comunicazione è tipicamente crittografata.
Listener WinRM: Disponibile per la connessione
A client needs somewhere to connect to when coming in from over the network. The client needs to “talk” to something that’s “listening” on the other side; that “listening” is the role of the WinRM listener.
È possibile scoprire tutti i listener WinRm in esecuzione su qualsiasi computer Windows utilizzando il comando winrm di seguito.
I listener WinRm hanno alcuni componenti importanti. Hanno:
- A listening address – The listening address is the IP address that they bind to. This is the IP address that a client connects to.
- Il tipo di trasporto – Ogni listener WinRM ha bisogno di un modo per comunicare con il client; lo fanno tramite un trasporto utilizzando HTTP o HTTPS.
- Un thumbprint del certificato opzionale – Quando un listener WinRM utilizza HTTPS per il trasporto, deve sapere quale chiave privata utilizzare per autenticare il client; questa chiave viene trovata utilizzando un thumbprint del certificato.
Utilizzare un listener HTTPS quando possibile. Configurare il trasporto HTTPS aumenta la sicurezza garantendo la validità del server e crittografando sia l’autenticazione che il traffico di trasporto. Quando si emette un certificato, utilizzare un certificato affidabile da un’autorità di certificazione, quando possibile, anziché un certificato autogenerato.
Host attendibili: convalida di un server
Come funziona l’autenticazione PSRemoting tramite WinRM
Come indicato in precedenza, uno dei primi passaggi che PSRemoting compie è l’autenticazione. L’autenticazione è una delle parti più complesse ma essenziali di PSRemoting.
Quando PSRemoting è stato introdotto per la prima volta, aveva solo un meccanismo di autenticazione, Windows Remote Management (WinRM), ma oggi è possibile autenticarsi anche utilizzando SSH, come vedrete in seguito.
WinRM supporta due tipi distinti di autenticazione; un nome utente e una password o un certificato con vari tipi di autenticazione per una combinazione nome utente/password.
Autenticazione di base
Iniziando con il tipo più semplice, ma anche più insicuro di autenticazione, abbiamo l’autenticazione di base. Questo tipo di autenticazione è uno standard incorporato nel protocollo HTTP. L’autenticazione di base invia una copia codificata in base64 del nome utente e della password nell’intestazione HTTP dal client al listener.
Poiché l’autenticazione di base codifica solo il nome utente e la password e non li crittografa, è banale intercettare le credenziali sulla rete.
Non utilizzare l’autenticazione di base a meno che non sia assolutamente necessario. Ci sono molti altri metodi più sicuri con cui WinRM può autenticare!
Autenticazione Kerberos
Sia il client che il server sono in un ambiente Active Directory? In tal caso, stai già utilizzando l’autenticazione Kerberos su molti dei tuoi servizi di rete.
Quando il client WinRM tenta di connettersi a un listener WinRM tramite Kerberos:
- Il server cerca innanzitutto di recuperare una chiave di sessione o un ticket di concessione per il client da un controller di dominio.
- Il controller di dominio verifica il client e il server e, se entrambi sono validi e attendibili, emette il token.
- Il server quindi convalida la connessione del client utilizzando il token attendibile anziché il nome utente e la password.
Durante l’autenticazione Kerberos, il controller di dominio convalida sia il client che il server durante le fasi di recupero del ticket, impedendo a un potenziale malintenzionato di impersonare il server.
Kerberos è un metodo di autenticazione maturo e sicuro ed è il tipo di autenticazione predefinito quando un client e un server sono entrambi membri di un dominio Active Directory. Tuttavia, richiede che sia il client che il server siano uniti allo stesso dominio Active Directory o che sia stata configurata una trust tra i domini.
Autenticazione di negoziazione
WinRm può anche tentare di utilizzare Kerberos e, se non disponibile, passare a un protocollo di autenticazione chiamato NT Lan Manager (NTLM).
Quando si utilizza NTLM:
- Il server invia al client una stringa.
- Il client quindi crittografa la stringa con l’hash della password dell’utente.
- La stringa crittografata viene quindi inviata al server, che invia il nome utente, la stringa originale e la stringa crittografata a un controller di dominio.
- Il controller di dominio quindi ricerca l’hash della password per quell’utente e ripete lo stesso processo di crittografia sulla stringa per verificare che corrisponda.
NTLM è buono per la convalida del client, ma a differenza di Kerberos, non convalida il server. Ciò apre la porta a molteplici attacchi in cui il server potrebbe essere impersonato da un attaccante.
È possibile migliorare la sicurezza di NTLM convalidando anche il server mediante un certificato di autenticazione del server e assegnandolo a un listener WinRM HTTPS. In questa configurazione, il client viene autenticato con NTLM contro il controller di dominio e il server viene autenticato con un certificato attendibile. Sebbene questa configurazione fornisca sia l’autenticazione del client che quella del server, il protocollo NLTM utilizza una cifra di crittografia più datata con una dimensione chiave obsoleta.
Per questi motivi, NLTM è utilizzabile solo se si aggiunge il server all’elenco degli host attendibili o si utilizza un listener HTTPS.
Autenticazione Digest
Uno dei metodi di autenticazione meno comuni da utilizzare in WinRM è l’autenticazione Digest. NTLM e Digest sono metodi di autenticazione simili. Come NTLM, Digest genera una stringa unica che viene crittografata con l’hash della password dell’utente. La password non deve quindi essere inviata al server.
Digest utilizza l’algoritmo di hash MD5 per crittografare la password. A causa di questa scelta di algoritmo, Digest è generalmente considerato obsoleto e non dovrebbe essere utilizzato. MD5 presenta varie vulnerabilità note che lo rendono inadatto all’uso crittografico.
Fornitore di supporto alla sicurezza delle credenziali (CredSSP)
Non è necessario approfondire i dettagli di CredSSP. Perché? Perché, quando si tratta di PSRemoting e WinRM, CredSSP viene implementato tipicamente per un solo motivo, ovvero il “problema del secondo salto” di cui parleremo di seguito.
Quando viene configurata l’autenticazione CredSSP, il client e il server WinRM utilizzano entrambi l’autenticazione Negozia per autenticare sia l’utente che il client. Ma una volta completato il processo, la password dell’utente viene inviata al server.
Poiché la password viene inviata dopo il completamento del processo di autenticazione, è ora criptata. CredSSP cripta anche la password con le chiavi di sessione TLS in modo che la stringa criptata sia univoca tra le sessioni.
CredSSP è utile perché, dopo l’autenticazione, il server può connettersi a qualsiasi altro servizio per tuo conto. Tuttavia, in questo caso, ti stai fidando completamente del server a cui ti sei connesso con la password utente.
Autenticazione basata su certificato
Indubbiamente, il metodo di autenticazione più sicuro da utilizzare con PSRemoting è l’autenticazione basata su certificato. In questo metodo di autenticazione, avviene uno scambio di chiavi tra una chiave privata e una chiave pubblica sul client e un server che convalida il certificato.
WinRM autentica l’utente mappando un utente sul server all’interno di WinRM. Durante il processo di autenticazione viene passata solo la chiave pubblica, quindi è un modo molto sicuro per autenticarsi
Anche se è il metodo più sicuro, l’autenticazione basata su certificato non è molto comune. Perché? Semplicemente a causa del lavoro necessario per configurarla. Devi:
- Creare un’autorità di certificazione
- Creare un certificato di autenticazione utente
- Condividere la chiave pubblica
- Utilizzare un account utente locale con le autorizzazioni appropriate (probabilmente il gruppo Amministratori)
- Configurare un listener HTTPS
- …e altri passaggi.
Non è possibile utilizzare un utente di dominio per autenticarsi con i certificati, anche se il client e il server fanno entrambi parte di Active Directory.
Impostazioni predefinite di autenticazione di Windows OS
Ora che hai visto che ci sono molte opzioni di autenticazione disponibili, come puoi sapere quali sono disponibili di default? Di seguito troverai una tabella con due colonne che indicano se il client WinRM, per impostazione predefinita, è abilitato e se quel tipo di autenticazione in particolare è abilitato per impostazione predefinita.
Tutti i tipi di autenticazione sopra citati sono configurabili, ma utilizzando la tabella sottostante avrai un’idea di ciò che dovrai configurare tu stesso.
| Method | Client | Service |
| Basic | Enabled | Disabled |
| Kerberos | Enabled | Enabled |
| Negotiate | Enabled | Enabled |
| CredSSP | Disabled | Disabled |
| Digest | Enabled | Disabled |
| Certificate | Enabled | Disabled |
Il problema del secondo hop o doppio hop
Uno dei problemi più grandi con PSRemoting è noto come “problema del secondo hop” o “doppio hop”. Questa situazione si verifica quando ti connetti a un sistema remoto tramite PSRemoting e successivamente devi connetterti a un altro computer remoto.
Questa situazione è problematica perché quando il client WinRm si autentica al primo computer remoto, il server verifica solo l’identità del client di origine senza inviare la password al server. Quando si tenta di connettersi al secondo computer dal server della prima connessione, il server finale non ha un modo per verificare l’identità dell’utente.
È possibile risolvere il problema del doppio hop in diversi modi, utilizzando CredSSP o Delega Kerberos.
Utilizzo di CredSSP
Il modo più comune per superare il problema del doppio hop è utilizzare CredSSP. L’autenticazione CredSSP risolve questa situazione memorizzando una credenziale utente sul primo server remoto, che il server trasformato in client può quindi passare al secondo server remoto.
C’è però una cosa da tenere presente nell’utilizzo di CredSSP. La credenziale utente memorizzata sul primo server remoto può essere memorizzata in testo normale, introducendo così una preoccupazione di sicurezza evidente. Nei sistemi operativi più recenti viene utilizzato un hash della password e del Kerberos Ticket Granting Ticket (TGT). Questi possono essere utilizzati insieme per autenticarsi come utente ovunque nella rete, proprio come una password in testo normale, ma riducono leggermente il rischio.
Con la negoziazione, il client e il server si scambiano informazioni per validare la loro identità, ma la password dell’utente non è mai accessibile. A causa di questa caratteristica di sicurezza, il primo server non può autenticarti quando ti connetti al secondo server.
Utilizzando la delega Kerberos
Il Kerberos, come accennato in precedenza, è un modo comune per configurare il PSRemoting. Essendo parte dell’onnipresente Active Directory e già configurato di default, è estremamente comune. Anche se da solo, il Kerberos è un modo valido per autenticare il WinRM, non risolve il problema del doppio hop.
Per risolvere il problema del doppio hop, è possibile utilizzare un secondo tipo di autenticazione noto come delega Kerberos. Anche se esistono molte varietà di delega Kerberos, l’unica varietà in grado di costituire un’alternativa sicura al CredSSP è chiamata delega Kerberos vincolata specificamente a risorse.
La delega Kerberos vincolata a risorse è una forma di delega dei token di autenticazione Kerberos basata su risorse di dominio, come i computer, in questo caso, che è vincolata a un elenco specifico di oggetti Kerberos (Active Directory).
Per configurare questa delega Kerberos, è necessario modificare l’oggetto ADComputer del terzo computer nella catena. Ad esempio, se stai per connetterti da ClientA a ServerB a ServerC, devi modificare l’oggetto ADComputer per ServerC, ma devi anche sapere quale sarà ServerB. Per questo esempio, esegui il comando PowerShell di seguito:
Utilizzare la Delega Kerberos basata su risorse funziona per connessioni remote come … o …, ma non funzionerà con PSRemoting. Non sarà possibile connettersi a un terzo computer quando si è connessi a un computer tramite WinRM usando PSRemoting.
Configurare la Delega Vincolata Kerberos basata su risorse è un comando PowerShell di una sola riga utilizzando il cmdlet Set-ADComputer. Se, ad esempio, sei connesso a ServerB da ClientA tramite PSRemoting e desideri connetterti a ServerC con …, puoi farlo eseguendo il seguente comando PowerShell.
WinRm memorizza le connessioni fallite per 15 minuti. A causa di questa funzionalità, potresti non riuscire a connetterti al terzo computer anche dopo aver configurato la Delega Vincolata Kerberos basata su risorse. Per rimediare, attendi o esegui il comando
klist purge -LI 0x3e7sul terzo computer per eliminare i token Kerberos non riusciti.
Come funziona l’autenticazione PSRemoting su SSH
Anche se l’autenticazione di WinRm è il metodo più comune di autenticazione per PSRemoting, a partire da PowerShell v6, hai un’altra opzione; SSH. Utilizzare SSH come metodo di autenticazione ti permette di utilizzare PSRemoting con Linux.
SSH, a differenza di WinRm, richiede alcune configurazioni aggiuntive sia sul client che sul server, come l’installazione di un client SSH sul client Windows e …
Utilizzare SSH per gestire l’autenticazione significa essere limitati ai tipi di autenticazione supportati da SSH. Questo restringe l’elenco con i principali due che sono basati su password e basati su chiave pubblica.
Ci sono altri tipi di autenticazione supportati da SSH, ma di solito sono considerati meno sicuri rispetto alle opzioni basate su password e chiave pubblica, quindi ci concentreremo solo su queste due.
Autenticazione tramite Password
Il modo più semplice per configurare l’autenticazione SSH con PSRemoting è con l’autenticazione basata su password. L’autenticazione basata su password ti consente di fornire una password per convalidare la tua identità.
Nel processo di autenticazione SSH, la password viene scambiata dopo che la connessione SSH è stata stabilita e la password viene crittografata durante la trasmissione. A differenza di alcuni metodi di autenticazione utilizzati da WinRM, come Kerberos, questo metodo di autenticazione invia l’intera password al server.
Puoi quasi confrontare l’autenticazione della password SSH con il metodo di autenticazione di base di WinRM utilizzando un listener HTTPS. La password stessa non è protetta in modo significativo, ma l’intera connessione, compresa la password, è crittografata e il server viene convalidato in base a un certificato.
Autenticazione basata su certificati
Mentre l’autenticazione basata su password è facile da configurare e semplice da utilizzare, presenta due problemi.
- Innanzitutto, non esiste un modo per autenticarsi in modo sicuro in un formato non interattivo.
- L’autenticazione mediante password invia comunque una password attraverso la rete. Sebbene la password sia crittografata all’interno della connessione SSH, il server riceve l’intera password. Se il server viene compromesso in qualche modo, potrebbe rappresentare un problema di sicurezza.
L’autenticazione basata su certificati, invece, non invia alcun dato sensibile attraverso la rete come la password. Invece, il server ha una copia di una chiave pubblica, il client ha una copia della chiave privata e le negoziazioni avvengono sul server.
A rough workflow goes as follows:
- Quando il client tenta di autenticarsi, invia l’ID o l’impronta digitale della chiave pubblica al server.
- Se il server ha la chiave pubblica elencata come autorizzata, risponde con una stringa crittografata con la chiave pubblica.
- Il client quindi decifra la stringa con la chiave privata.
- La chiave privata viene poi hashata con un ID di sessione.
- L’ID di sessione viene rispedito al server, che poi lo confronta con l’hash generato utilizzando la stringa originale e l’ID di sessione.
- Se l’hash dell’ID di sessione dal client e l’ID di sessione sul server corrispondono, il client viene autenticato ed è autorizzato a connettersi.
Qualsiasi cosa cifrata con la chiave pubblica può essere decifrata solo con una chiave privata associata. Qualsiasi cosa cifrata con la chiave privata può essere decifrata solo con la chiave pubblica. L’ID di sessione è anche incluso per fornire quello che si chiama Perfect Forward Secrecy (PFS).
Il PFS offre sicurezza se la chiave privata viene compromessa, l’attaccante non sarebbe in grado di decifrare tutti i messaggi che sono stati scambiati. Un ID di sessione unico significa che il segreto condiviso usato per cifrare la comunicazione è diverso per ogni sessione.
L’autenticazione basata su certificati con SSH, come WinRm, richiede uno sforzo aggiuntivo per essere impostata, come la generazione della coppia di chiavi privata/pubblica e l’autorizzazione della chiave pubblica sul server remoto.
Diritti Utente Necessari per Connettersi
Per impostazione predefinita, due gruppi locali di utenti possono connettersi a un server in remoto usando PSRemoting; Amministratori e Utenti Gestione Remota.
Mentre è possibile aggiungere gli account utente al gruppo Amministratori locale su un server remoto, è sempre consigliabile fornire il minor accesso possibile. Se un utente ha semplicemente bisogno di connettersi tramite PSRemoting a un computer remoto, è possibile aggiungere l’account utente al gruppo Remote Management Users, non a Amministratori.
Per controllare ulteriormente l’accesso a PSRemoting, è possibile utilizzare una funzionalità chiamata Just Enough Administration (JEA). JEA consente agli utenti non amministratori di eseguire solo comandi specifici come amministratori in PowerShell’s constrained language mode.
Accesso Implicito vs. Remoting “Esplicito”
Se hai già utilizzato PSRemoting in precedenza, probabilmente sei familiare con comandi come Invoke-Command, New-PSSession, Enter-PSSession, ecc. Quando esegui questi comandi, è chiaro che ti stai connettendo in qualche modo a un computer remoto. Stai usando PSRemoting in modo esplicito.
Quando esegui comandi specifici di PSRemoting, stai eseguendo quei comandi in modo esplicito, ma sapevi che c’è un altro modo? Invece di invocare direttamente Invoke-Command e altri cmdlet, puoi sfruttare PSRemoting in modo implicito.
L’Implicit PSRemoting potrebbe sembrare come se stessi eseguendo i comandi localmente all’interno della sessione PowerShell, ma in realtà vengono eseguiti su una macchina remota. Un buon esempio di ciò è l’uso di un modulo che non è installato sul tuo sistema. Invece di installarlo localmente, puoi esportare i comandi da una PSSession che ti consentirà di eseguirli come se fossero installati localmente.
Nella schermata sottostante puoi vedere che non ho il comando Test-PendingReboot. Quindi mi sono connesso a una macchina remota e ho esportato quel comando.
Successivamente, se quel modulo viene importato, posso eseguire il comando Test-PendingReboot. Questo è mostrato di seguito, ma noterai che viene indicato che il nome del computer nell’output non è il nome del dispositivo da cui PowerShell sta eseguendo, ma il dispositivo da cui è stato importato il comando.
