Come controllare il tuo PC dal tuo cellulare utilizzando PowerShell Remoting

Potresti già automatizzare molte attività con PowerShell localmente, ma dove lo fai realmente? PowerShell Remoting fa la differenza Si verifica quando si eseguono comandi su macchine remote, siano esse poche o centinaia, in modo interattivo o in parallelo. Questa tecnologia, disponibile da Windows PowerShell 2.0 e migliorata dalla versione 3.0, si basa su WS-Management (WinRM) e converte PowerShell in un canale di gestione remota robusto, scalabile e sicuro.

Innanzitutto è importante comprendere due idee chiave: cmdlet con -Parametro NomeComputer (ad esempio, Get-Process o Get-Service) non sono il percorso a lungo termine consigliato da Microsoft e PowerShell Remoting non funziona come un "hack". Infatti, impone l'autenticazione reciproca, registra gli audit e rispetta le tue consuete autorizzazioni, senza memorizzare credenziali o eseguire magicamente nulla con privilegi elevati.

Che cos'è PowerShell Remoting e perché utilizzarlo?

Con Comunicazione remota PowerShell puedes eseguire quasi tutti i comandi da remoto che è possibile avviare in una sessione locale, dall'interrogazione dei servizi alla distribuzione delle configurazioni, e farlo su centinaia di computer contemporaneamente. A differenza dei cmdlet che accettano -ComputerName (molti usano DCOM/RPC), Remoting viaggia tramite WS-Man (HTTP/HTTPS), che è più compatibile con i firewall, consente il parallelismo e trasferisce il lavoro all'host remoto, non al client.

Ciò si traduce in tre vantaggi pratici: migliori prestazioni nelle esecuzioni massicce, meno attriti nelle reti con regole restrittive e un modello di sicurezza coerente con Kerberos/HTTPS. Inoltre, non dipendendo da ogni cmdlet per implementare il proprio remoto, Remoting Funziona per qualsiasi sceneggiatura o ruolo disponibile a destinazione.

Per impostazione predefinita, i server Windows più recenti sono dotati di Remoting abilitato; in Windows 10/11 lo attivi con un singolo cmdlet. E sì, puoi usare credenziali alternative, sessioni persistenti, endpoint personalizzati e altro ancora.

Nota: il comando remoto non è sinonimo di apertura di tutto. Per impostazione predefinita, solo amministratori Possono connettersi e le azioni vengono eseguite sotto la loro identità. Se è necessaria una delega più dettagliata, gli endpoint personalizzati consentono di esporre solo i comandi essenziali.

Come funziona all'interno: WinRM, WS-Man e porte

PowerShell Remoting funziona secondo un modello client-server. Il client invia richieste WS-Management tramite HTTP (5985/TCP) o HTTPS (5986/TCP)Sulla destinazione, il servizio Gestione remota Windows (WinRM) è in ascolto, risolve l'endpoint (configurazione della sessione) e ospita la sessione di PowerShell in background (processo wsmprovhost.exe), restituendo risultati serializzati al client in XML tramite SOAP.

La prima volta che si abilita Remoting, vengono configurati i listener, viene aperta l'eccezione firewall appropriata e vengono create le configurazioni di sessione. A partire da PowerShell 6+, coesistono più edizioni e Abilita-PSRemoting Registra gli endpoint con nomi che riflettono la versione (ad esempio, PowerShell.7 e PowerShell.7.xy).

Se consenti solo HTTPS nel tuo ambiente, puoi creare un ascoltatore sicuro con un certificato rilasciato da una CA attendibile (consigliato). In alternativa, un'altra alternativa è quella di utilizzare TrustedHosts in modo limitato e consapevole dei rischi, per scenari di gruppi di lavoro o computer non appartenenti a un dominio.

Si noti che Powershell Remoting può coesistere con cmdlet con -ComputerName, ma Microsoft spinge WS-Man come metodo standard e a prova di futuro per l'amministrazione remota.

Abilitazione della comunicazione remota di PowerShell e parametri utili

Su Windows, basta aprire PowerShell come amministratore ed eseguire Abilita-PSRemotingIl sistema avvia WinRM, configura l'avvio automatico, abilita il listener e crea le regole firewall appropriate. Sui client con un profilo di rete pubblica, è possibile consentire deliberatamente questa operazione con -Salta il controllo del profilo di rete (e poi rinforzare con regole specifiche):

Enable-PSRemoting
Enable-PSRemoting -Force
Enable-PSRemoting -SkipNetworkProfileCheck -Force

 

La sintassi consente inoltre, -Confermare y -Cosa succede se per il controllo delle modifiche. Ricorda: È disponibile solo su Windowsed è necessario eseguire la console con privilegi elevati. Le regole create differiscono tra le edizioni Server e Client, soprattutto sulle reti pubbliche, dove per impostazione predefinita sono limitate alla subnet locale, a meno che non si espanda l'ambito (ad esempio, con Set-NetFirewallRule).

Per elencare le configurazioni di sessione già registrate e confermare che tutto è pronto, utilizzare Ottieni-PSSessionConfigurationSe vengono visualizzati gli endpoint PowerShell.x e Workflow, il framework Remoting è operativo.

Modalità di utilizzo: sessioni 1 a 1, 1 a molti e persistenti

Quando hai bisogno di una console interattiva su un singolo computer, rivolgiti a Enter-PSSessionApparirà il prompt e tutto ciò che eseguirai verrà indirizzato all'host remoto. Puoi riutilizzare le credenziali con Get-Credential per evitare di doverle reinserire costantemente:

$cred = Get-Credential
Enter-PSSession -ComputerName dc01 -Credential $cred
Exit-PSSession

Se quello che stai cercando è inviare comandi a più computer contemporaneamente, lo strumento è Invoke-Command con uno scriptblock. Per impostazione predefinita, avvia fino a 32 connessioni simultanee (regolabile con -ThrottleLimit). I risultati vengono restituiti come oggetti deserializzati (senza metodi “live”):

Invoke-Command -ComputerName dc01,sql02,web01 -ScriptBlock { Get-Service -Name W32Time } -Credential $cred

Hai bisogno di invocare un metodo come .Stop() o .Start()? Fallo. all'interno dello scriptblock nel contesto remoto, non nell'oggetto deserializzato locale, e questo è tutto. Se esiste un cmdlet equivalente (Stop-Service/Start-Service), di solito è preferibile utilizzarlo per maggiore chiarezza.

Per evitare i costi di avvio e fine delle sessioni a ogni chiamata, creare un PSSession persistente e riutilizzarlo in più invocazioni. Utilizza New-PSSession per creare la connessione e Invoke-Command-Session per riutilizzare il tunnel. Non dimenticare di chiuderlo con Remove-PSSession al termine.

Serializzazione, limiti e buone pratiche

Un dettaglio importante: quando si viaggia, gli oggetti si "+appiattiscono" e arrivano come snapshot deserializzati, con proprietà ma senza metodi. Questa scelta è intenzionale e consente di risparmiare banda, ma significa che non è possibile utilizzare membri che eseguono la logica (come .Kill()) sulla copia locale. La soluzione è ovvia: invocare quei metodi. da remoto e se hai bisogno solo di determinati campi, filtra con Select-Object per inviare meno dati.

Negli script, evitare Enter-PSSession (destinato all'uso interattivo) e utilizzare Invoke-Command con blocchi di script. Se si prevedono più chiamate o è necessario preservare lo stato (variabili, moduli importati), utilizzare sessioni persistenti e, se applicabile, disconnetterli/riconnetterli con Disconnect-PSSession/Connect-PSSession in PowerShell 3.0+.

Autenticazione, HTTPS e scenari fuori dominio

In un dominio, l'autenticazione nativa è Kerberos E tutto scorre. Quando il dispositivo non riesce a verificare il nome del server, o ci si connette a un IP CNAME o a un alias, è necessaria una di queste due opzioni: 1) Listener HTTPS con certificato rilasciato da una CA di cui ti fidi, oppure 2) aggiungi la destinazione (nome o IP) a TrustedHosts e utilizzare le credenzialiLa seconda opzione disabilita l'autenticazione reciproca per quell'host, riducendo così l'ambito al minimo necessario.

Per configurare un listener HTTPS è necessario un certificato (idealmente proveniente dalla tua PKI o da una CA pubblica), installato nell'archivio del team e associato a WinRM. La porta 5986/TCP viene quindi aperta nel firewall e utilizzata dal client. -UsaSSL nei cmdlet remoti. Per l'autenticazione del certificato client, è possibile mappare un certificato a un account locale e connettersi con -CertificatoImpronta digitale (Enter-PSSession non accetta questo comando direttamente; creare prima la sessione con New-PSSession.)

Il secondo salto e la delega delle credenziali

Il famoso “doppio salto” si verifica quando, dopo essersi connessi a un server, si ha bisogno che quel server acceda a un terza risorsa per tuo conto (ad esempio, una condivisione SMB). Esistono due approcci per consentirlo: CredSSP e delega Kerberos vincolata basata sulle risorse.

Con CredSSP Si consente al client e all'intermediario di delegare esplicitamente le credenziali e si imposta una policy (GPO) per consentire la delega a computer specifici. È una soluzione rapida da configurare, ma meno sicura perché le credenziali viaggiano in chiaro all'interno del tunnel crittografato. Limitare sempre origini e destinazioni.

L'alternativa preferita nel dominio è la delega Kerberos vincolata (delega vincolata basata sulle risorse) nell'AD moderno. Ciò consente all'endpoint di affidarsi alla ricezione della delega dal punto intermedio per servizi specifici, evitando di esporre l'identità dell'utente alla connessione iniziale. Richiede controller di dominio recenti e un RSAT aggiornato.

Endpoint personalizzati (configurazioni di sessione)

Una delle gemme del Remoting è la possibilità di registrare i punti di connessione con capacità e limiti su misuraPer prima cosa si genera un file con New-PSSessionConfigurationFile (moduli da precaricare, funzioni visibili, alias, ExecutionPolicy, LanguageMode, ecc.), quindi lo si registra con Register-PSSessionConfiguration, dove è possibile impostare Esegui come credenziale e permessi (interfaccia SDDL o GUI con -ShowSecurityDescriptorUI).

Per una delega sicura, esporre solo ciò che è necessario con -VisibleCmdlets/-VisibleFunctions e disabilitare lo scripting libero se appropriato con LinguaModalità Lingua Limitata o NoLanguage. Se si esce da FullLanguage, qualcuno potrebbe usare un blocco di script per richiamare comandi non esposti, che, combinati con RunAs, sarebbe un bucoProgettare questi endpoint con la massima attenzione e documentarne l'ambito.

Domini, GPO e Groupware

In AD è possibile distribuire Powershell Remoting su larga scala con GPO: consentire la configurazione automatica dei listener WinRM, imposta il servizio su Automaticoe crea l'eccezione del firewall. Ricorda che i GPO modificano le impostazioni, ma non sempre attivano il servizio all'istante; a volte è necessario riavviare o forzare un gpupdate.

Nei gruppi di lavoro (non di dominio), configurare Remoting con Abilita-PSRemoting, imposta TrustedHosts sul client (winrm set winrm/config/client @{TrustedHosts=»host1,host2″}) e utilizza credenziali locali. Per HTTPS, è possibile montare certificati autofirmati, sebbene si consigli di utilizzare una CA attendibile e convalidare il nome che utilizzerai in -ComputerName nel certificato (corrispondenza CN/SAN).

Cmdlet chiave e sintassi

Una manciata di commando copre il 90% degli scenari quotidianiPer attivare/disattivare:

Enable-PSRemoting    
Disable-PSRemoting

Sessione interattiva 1 a 1 ed esci:

Enter-PSSession -ComputerName SEC504STUDENT 
Exit-PSSession

1 a molti, con parallelismo e credenziali:

Invoke-Command -ComputerName dc01,sql02,web01 -ScriptBlock { Get-Service W32Time } -Credential $cred

Sessioni persistenti e riutilizzare:

$s = New-PSSession -ComputerName localhost -ConfigurationName PowerShell.7
Invoke-Command -Session $s -ScriptBlock { $PSVersionTable }
Remove-PSSession $s

Test e WinRM Utile:

Test-WSMan -ComputerName host
winrm get winrm/config
winrm enumerate winrm/config/listener
winrm quickconfig -transport:https

Note pratiche su firewall, rete e porte

Aprire 5985/TCP per HTTP e 5986/TCP per HTTPS sul computer di destinazione e su qualsiasi firewall intermedioNei client Windows, Enable-PSRemoting crea regole per i profili di dominio e privati; per i profili pubblici, è limitato alla subnet locale, a meno che non si modifichi l'ambito con Set-NetFirewallRule -RemoteAddress Any (un valore che è possibile valutare in base al rischio).

Se si utilizzano integrazioni SOAR/SIEM che eseguono comandi remoti (ad esempio da XSOAR), assicurarsi che il server abbia risoluzione DNS agli host, connettività a 5985/5986 e credenziali con sufficienti autorizzazioni locali. In alcuni casi, l'autenticazione NTLM/Basic potrebbe richiedere una modifica (ad esempio, utilizzando un utente locale in Basic con SSL).

Parametri Enable-PSRemoting (Riepilogo operativo)

-Conferma chiede conferma prima di eseguire; -Forza ignora gli avvertimenti e apportare le modifiche necessarie; -SkipNetworkProfileCheck abilita il Remoting sulle reti client pubbliche (limitato per impostazione predefinita alla subnet locale); -WhatIf mostra cosa accadrebbe senza applicare le modifiche. Inoltre, come qualsiasi cmdlet standard, supporta parametri comuni (-Verbose, -ErrorAction, ecc.).

Ricorda che "Abilita" non crea listener HTTPS o certificati per te; se hai bisogno della crittografia end-to-end fin dall'inizio e dell'autenticazione basata su certificato, configura l'ascoltatore HTTPS e convalida CN/SAN rispetto al nome che utilizzerai in -ComputerName.

Comandi utili per WinRM e PowerShell Remoting

un po ' articoli essenziali da comodino Per tutti i giorni:

winrm get winrm/config
winrm enumerate winrm/config/listener
Set-NetFirewallRule -Name 'WINRM-HTTP-In-TCP' -RemoteAddress Any
Test-WSMan -ComputerName host -Authentication Default -Credential (Get-Credential)
New-PSSession -ComputerName host 
Enter-PSSession -ComputerName host 
Enable-PSRemoting -SkipNetworkProfileCheck -Force

Nella gestione di Windows su larga scala, il Remoting consente di passare da un approccio "computer-to-computer" a un approccio dichiarativo e sicuro. Combinando sessioni persistenti, autenticazione avanzata (Kerberos/HTTPS), endpoint con restrizioni e tracce chiare per la diagnostica, guadagni velocità e controllo Senza sacrificare la sicurezza o l'audit. Se standardizzi anche l'attivazione dei GPO e gestisci i casi speciali (TrustedHost, doppio hop, certificati), avrai una solida piattaforma remota per le operazioni quotidiane e la risposta agli incidenti.