Come e perché Windows e PowerShell impediscono l'esecuzione dello script.
PowerShell è effettivamente la shell dei comandi e il linguaggio di scripting che è destinato a sostituire CMD e script batch su sistemi Windows. In quanto tale, uno script PowerShell può essere configurato per fare qualsiasi cosa tu possa fare manualmente dalla riga di comando. Ciò equivale a rendere praticamente possibile qualsiasi modifica sul tuo sistema, fino alle restrizioni sul tuo account utente. Quindi, se potessi semplicemente fare doppio clic su uno script di PowerShell ed eseguirlo con i privilegi di amministratore completi, un semplice elemento di questo tipo potrebbe rovinarti la giornata:
Get-ChildItem '$env:SystemDrive' -Recurse -ErrorAction SilentlyContinue | Remove-Item -Force -Recurse -ErrorAction SilentlyContinue
NON eseguire il comando sopra!
Questo passa semplicemente attraverso il file system e cancella tutto ciò che può. È interessante notare che questo potrebbe non rendere il sistema inutilizzabile il più rapidamente possibile, anche quando viene eseguito da una sessione elevata. Ma se qualcuno ti chiama dopo aver eseguito questo script, perché improvvisamente non riescono a trovare i loro file o eseguire alcuni programmi, "spegnendoli e riaccendendoli" probabilmente li condurrà semplicemente a Ripristino all'avvio di Windows dove gli verrà detto che c'è nulla che possa essere fatto per risolvere il problema. Quello che potrebbe essere peggio è, invece di ottenere uno script che semplicemente distrugge il loro file system, il tuo amico potrebbe essere indotto a eseguire uno che scarica e installa un keylogger o un servizio di accesso remoto. Quindi, invece di farti delle domande su Startup Repair, potrebbero finire per chiedere alla polizia alcune domande sulle frodi bancarie!
Ormai dovrebbe essere ovvio il motivo per cui alcune cose sono necessarie per proteggere gli utenti finali da se stessi, per così dire. Ma gli utenti esperti, gli amministratori di sistema e altri fanatici sono generalmente (anche se ci sono eccezioni) un po 'più diffidenti nei confronti di queste minacce, sapendo come individuarle e evitarle facilmente, e vogliono solo continuare a portare a termine il loro lavoro. Per fare ciò, dovranno disabilitare o aggirare alcuni blocchi stradali:
- PowerShell non consente l'esecuzione di script esterni per impostazione predefinita. L'impostazione ExecutionPolicy in PowerShell impedisce l'esecuzione di script esterni per impostazione predefinita in tutte le versioni di Windows. In alcune versioni di Windows, l'impostazione predefinita non consente affatto l'esecuzione di script. Ti abbiamo mostrato come modificare questa impostazione in Come consentire l'esecuzione degli script di PowerShell su Windows 7, ma lo esamineremo anche su alcuni livelli.
- PowerShell non è associato all'estensione del file.PS1 per impostazione predefinita. L'abbiamo portato inizialmente alla nostra serie PowerShell Geek School. Windows imposta l'azione predefinita per i file.PS1 per aprirli in Blocco note, anziché inviarli all'interprete dei comandi di PowerShell. Questo per impedire direttamente l'esecuzione accidentale di script dannosi quando vengono semplicemente fatti doppio clic.
- Alcuni script PowerShell non funzioneranno senza le autorizzazioni di amministratore. Anche con un account a livello di amministratore, è comunque necessario passare attraverso il controllo dell'account utente (UAC) per eseguire determinate azioni. Per gli strumenti da riga di comando, questo può essere un po 'macchinoso per non dire altro. Non vogliamo disabilitare UAC, ma è ancora bello quando possiamo renderlo un po 'più facile da gestire.
Questi stessi problemi sono riportati in Come utilizzare un file batch per rendere gli script di PowerShell più facili da eseguire, in cui ti guidiamo attraverso la scrittura di un file batch per aggirarli temporaneamente. Ora, vi mostreremo come impostare il vostro sistema con una soluzione a più lungo termine. Ricorda che in genere non dovresti apportare queste modifiche a sistemi che non sono utilizzati esclusivamente da te; in caso contrario, stai mettendo gli altri utenti a più alto rischio di incorrere negli stessi problemi che queste funzionalità sono destinate a prevenire.
Modifica dell'associazione file.PS1.
Il primo, e forse il primo, fastidio di andare in giro è l'associazione di default per i file.PS1. Associare questi file a qualcosa di diverso da PowerShell.exe ha senso per prevenire l'esecuzione accidentale di script indesiderati. Tuttavia, considerando che PowerShell è dotato di un ISE (Integrated Scripting Environment) appositamente progettato per la modifica degli script di PowerShell, perché dovremmo voler aprire i file.PS1 in Blocco note per impostazione predefinita? Anche se non sei pronto per passare completamente all'attivazione della funzionalità di doppio clic per eseguire, probabilmente vorrai modificare queste impostazioni.
È possibile modificare l'associazione di file.PS1 con qualsiasi programma desiderato con il pannello di controllo Programmi predefiniti, ma scavando direttamente nel Registro di sistema si otterrà un maggiore controllo sul modo esatto in cui i file verranno aperti. Ciò consente anche di impostare o modificare le opzioni aggiuntive disponibili nel menu di scelta rapida per i file.PS1. Non dimenticare di fare un backup del registro prima di fare questo!
Le impostazioni del registro che controllano il modo in cui vengono aperti gli script di PowerShell sono archiviati nel seguente percorso:
HKEY_CLASSES_ROOTMicrosoft.PowerShellScript.1Shell
Per esplorare queste impostazioni prima di cambiarle, dai un'occhiata a quella chiave e alle sue sottochiavi con Regedit. La chiave Shell dovrebbe avere solo un valore, "(Predefinito)", che è impostato su "Apri". Questo è un puntatore all'azione predefinita per fare doppio clic sul file, che vedremo nelle sottochiavi.
Espandi la chiave Shell e vedrai tre sottochiavi. Ognuna di queste rappresenta un'azione che è possibile eseguire e che è specifica per gli script di PowerShell.
- 0 - Esegui con PowerShell. "Esegui con PowerShell" è in realtà il nome di un'opzione già presente nel menu di scelta rapida per gli script di PowerShell. Il testo viene semplicemente estratto da un'altra posizione anziché utilizzare il nome della chiave come gli altri. E non è ancora l'azione di doppio clic predefinita.
- Modifica - Apri in PowerShell ISE. Questo ha molto più senso del Blocco note, ma è comunque necessario fare clic con il pulsante destro del mouse sul file.PS1 per farlo in modo predefinito.
- Apri - Apri nel blocco note. Si noti che questo nome chiave è anche la stringa memorizzata nel valore "(Predefinito)" della chiave Shell. Ciò significa che fare doppio clic sul file lo "aprirà" e che l'azione è normalmente impostata per utilizzare Blocco note.
Se si desidera mantenere le stringhe di comando predefinite già disponibili, è sufficiente modificare il valore "(Predefinito)" nella chiave Shell in modo che corrisponda al nome della chiave che corrisponde a ciò che si desidera fare con un doppio clic. Questo può essere fatto facilmente da Regedit, oppure puoi usare le lezioni apprese dal nostro tutorial sull'esplorazione del registro con PowerShell (più un piccolo tweed PSDrive) per iniziare a creare uno script riutilizzabile che possa configurare i tuoi sistemi per te. I seguenti comandi devono essere eseguiti da una sessione PowerShell elevata, simile alla CMD in esecuzione come amministratore.
Innanzitutto, devi configurare un PSDrive per HKEY_CLASSES_ROOT poiché non è configurato per impostazione predefinita. Il comando per questo è:
New-PSDrive HKCR Registry HKEY_CLASSES_ROOT
Ora puoi navigare e modificare chiavi e valori di registro in HKEY_CLASSES_ROOT proprio come faresti con i normali PSDrive HKCU e HKLM.
Per configurare il doppio clic per avviare direttamente gli script di PowerShell:
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 0
Per configurare il doppio clic per aprire gli script di PowerShell in PowerShell ISE:
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 'Edit'
Per ripristinare il valore predefinito (imposta il doppio clic per aprire gli script di PowerShell nel Blocco note):
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1Shell '(Default)' 'Open'
Questo è solo il fondamento della modifica dell'azione di doppio clic predefinita. Andremo più in dettaglio sulla personalizzazione di come vengono gestiti gli script di PowerShell quando vengono aperti in PowerShell da Explorer nella prossima sezione. Tenere presente che l'ambito impedisce a PSDrives di persistere tra le sessioni. Pertanto, probabilmente vorrai includere la riga New-PSDrive all'inizio di qualsiasi script di configurazione che hai creato per questo scopo, o aggiungerlo al tuo profilo PowerShell. Altrimenti, dovrai eseguire quel bit manualmente prima di provare a fare le modifiche in questo modo.
Modifica dell'impostazione ExecutionPolicy di PowerShell.
ExecutionPolicy di PowerShell è un altro livello di protezione contro l'esecuzione di script dannosi. Ci sono più opzioni per questo, e un paio di modi in cui può essere impostato. Dal più al meno sicuro, le opzioni disponibili sono:
- Limitato: non è consentito l'esecuzione di script. (Impostazione predefinita per la maggior parte dei sistemi). Ciò impedirà anche l'esecuzione dello script del profilo.
- AllSigned: tutti gli script devono essere firmati digitalmente da un editore attendibile per essere eseguiti senza chiedere conferma all'utente. Gli script firmati da editori definiti in modo esplicito come non attendibili o script non firmati digitalmente non verranno eseguiti. PowerShell chiederà all'utente di confermare se uno script è firmato da un editore non ancora definito attendibile o non affidabile. Se non hai firmato digitalmente lo script del tuo profilo e hai fiducia in quella firma, non sarà possibile eseguirlo. Fai attenzione a quali editori ti fidi, dato che puoi ancora eseguire script dannosi se ti fidi di quello sbagliato.
- RemoteSigned: per gli script scaricati da Internet, questo è effettivamente lo stesso di "AllSigned". Tuttavia, gli script creati localmente o importati da fonti diverse da Internet possono essere eseguiti senza alcuna richiesta di conferma. Qui, dovrai anche prestare attenzione a quali firme digitali ti fidi, ma anche a prestare attenzione agli script non firmati che scegli di eseguire. Questo è il livello di sicurezza più alto in base al quale è possibile avere uno script di profilo funzionante senza doverlo firmare digitalmente.
- Senza restrizioni: tutti gli script possono essere eseguiti, ma per gli script da Internet è richiesta una richiesta di conferma. Da questo momento in poi, spetta esclusivamente a te evitare di eseguire script non affidabili.
- Bypass: tutto funziona senza avviso. Stai attento con questo.
- Non definito: nessuna politica è definita nell'ambito corrente. Viene utilizzato per consentire il fallback delle politiche definite in ambiti inferiori (ulteriori dettagli di seguito) o ai valori predefiniti del sistema operativo.
Come suggerito dalla descrizione di Non definito, le politiche precedenti possono essere impostate in uno o più di diversi ambiti. È possibile utilizzare Get-ExecutionPolicy, con il parametro -List, per vedere tutti gli ambiti e la loro configurazione corrente.
- MachinePolicy rappresenta un criterio di gruppo in vigore a livello di computer. Questo è generalmente applicato solo in un dominio, ma può essere fatto anche localmente.
- UserPolicy rappresenta un criterio di gruppo in vigore per l'utente. Questo è in genere utilizzato solo negli ambienti aziendali.
- Processo è un ambito specifico per questa istanza di PowerShell. Le modifiche al criterio in questo ambito non influiranno su altri processi PowerShell in esecuzione e saranno inefficaci dopo il termine di questa sessione. Questo può essere configurato dal parametro -ExecutionPolicy quando viene avviato PowerShell oppure può essere impostato con la sintassi Set-ExecutionPolicy appropriata all'interno della sessione.
- CurrentUser è un ambito configurato nel registro locale e si applica all'account utente utilizzato per avviare PowerShell. Questo ambito può essere modificato con Set-ExecutionPolicy.
- LocalMachine è un ambito configurato nel registro locale e applicabile a tutti gli utenti del sistema. Questo è l'ambito predefinito che viene modificato se Set-ExecutionPolicy viene eseguito senza il parametro -Scope. Poiché si applica a tutti gli utenti del sistema, può essere modificato solo da una sessione elevata.
Poiché questo articolo riguarda principalmente la sicurezza per facilitare l'usabilità, siamo solo preoccupati per i tre ambiti inferiori. Le impostazioni di MachinePolicy e UserPolicy sono davvero utili solo se si desidera applicare una politica restrittiva che non sia semplicemente ignorata. Mantenendo le nostre modifiche al livello di processo o al di sotto, possiamo facilmente utilizzare qualsiasi impostazione di politica che riteniamo appropriata per una data situazione in qualsiasi momento.
Per mantenere un certo equilibrio tra sicurezza e usabilità, la politica mostrata nello screenshot è probabilmente la migliore. L'impostazione del criterio LocalMachine su Restricted generalmente impedisce l'esecuzione di script da parte di chiunque tranne te. Naturalmente, questo può essere aggirato dagli utenti che sanno cosa stanno facendo senza troppi sforzi. Ma dovrebbe impedire agli utenti non esperti di tecnologia di attivare accidentalmente qualcosa di catastrofico in PowerShell. Avere il CurrentUser (cioè tu) impostato come Senza restrizioni consente di eseguire manualmente gli script dalla riga di comando come preferisci, ma mantiene un avvertimento di cautela per gli script scaricati da Internet. L'impostazione RemoteSigned a livello di processo dovrebbe essere eseguita in un collegamento a PowerShell.exe o (come faremo di seguito) nei valori di Registro di sistema che controllano il comportamento degli script di PowerShell. Ciò consentirà una facile funzionalità double-click-to-run per tutti gli script scritti, mettendo al contempo una barriera più forte contro l'esecuzione involontaria di script (potenzialmente dannosi) da fonti esterne. Vogliamo farlo qui poiché è molto più semplice accidentalmente fare doppio clic su uno script di quanto non lo sia in genere per chiamarlo manualmente da una sessione interattiva.
Per impostare i criteri CurrentUser e LocalMachine come nella schermata sopra, eseguire i seguenti comandi da una sessione PowerShell con privilegi elevati:
Set-ExecutionPolicy Restricted Set-ExecutionPolicy Unrestricted -Scope CurrentUser
Per applicare il criterio RemoteSigned sugli script eseguiti da Explorer, dovremo modificare un valore all'interno di una delle chiavi del Registro di sistema che stavamo guardando in precedenza. Ciò è particolarmente importante perché, a seconda della versione di PowerShell o di Windows, la configurazione predefinita potrebbe ignorare tutte le impostazioni di ExecutionPolicy, ad eccezione di AllSigned. Per vedere qual è la configurazione corrente per il tuo computer, puoi eseguire questo comando (assicurandoti che l'HKCR PSDrive sia mappato per primo):
Get-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand | Select-Object '(Default)'
La tua configurazione predefinita sarà probabilmente una delle seguenti due stringhe, o qualcosa di abbastanza simile:
(Visto su Windows 7 SP1 x64, con PowerShell 2.0)
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-file' '%1'
(Visto su Windows 8.1 x64, con PowerShell 4.0)
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' 'if((Get-ExecutionPolicy ) -ne 'AllSigned') { Set-ExecutionPolicy -Scope Process Bypass }; & '%1''
Il primo non è male, dato che tutto ciò che fa è eseguire lo script con le impostazioni ExecutionPolicy esistenti. Potrebbe essere migliorato, imponendo restrizioni più severe per un'azione più incline agli incidenti, ma questo non era originariamente previsto per essere attivato con un doppio clic e il criterio predefinito di solito è Restrito dopo tutto. La seconda opzione, tuttavia, è un bypass completo di qualsiasi ExecutionPolicy che è probabile che sia in atto, anche limitato. Poiché il bypass verrà applicato nell'ambito del processo, influisce solo sulle sessioni avviate quando gli script vengono eseguiti da Explorer. Tuttavia, questo significa che potresti finire per lanciare script che altrimenti potresti aspettarti (e vuoi) che la tua politica proibisca.
Per impostare la Process ExecutionPolicy a livello di processo per gli script avviati da Explorer, in linea con lo screenshot precedente, è necessario modificare lo stesso valore di registro appena interrogato. Puoi farlo manualmente in Regedit, cambiandolo in questo:
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1'
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1''
Esegui script PowerShell come amministratore.
Così come è una cattiva idea disabilitare completamente il controllo dell'account utente, è anche una cattiva pratica di sicurezza eseguire script o programmi con privilegi elevati, a meno che non siano effettivamente necessari per eseguire operazioni che richiedono l'accesso come amministratore. Pertanto, non è consigliabile creare il prompt UAC nell'azione predefinita per gli script di PowerShell. Tuttavia, possiamo aggiungere una nuova opzione del menu contestuale per permetterci di eseguire facilmente gli script in sessioni elevate quando è necessario. Questo è simile al metodo utilizzato per aggiungere "Apri con Blocco note" al menu di scelta rapida di tutti i file - ma qui stiamo andando solo a scegliere gli script di PowerShell. Riporteremo anche alcune tecniche utilizzate nell'articolo precedente, in cui abbiamo utilizzato un file batch anziché gli hack del Registro di sistema per avviare il nostro script PowerShell.
Per fare ciò in Regedit, torna nella chiave Shell, a:
HKEY_CLASSES_ROOTMicrosoft.PowerShellScript.1Shell
In là, crea una nuova sottochiave. Chiamalo "Esegui con PowerShell (amministratore)". Al di sotto di questo, crea un'altra sottochiave chiamata "Comando".Quindi, imposta il valore "(predefinito)" sotto Comando a questo:
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList '-ExecutionPolicy RemoteSigned -File '%1'' -Verb RunAs}'
New-Item 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)' New-Item 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' Set-ItemProperty 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList ''-ExecutionPolicy RemoteSigned -File '%1''' -Verb RunAs}''
Inoltre, prestate molta attenzione alle differenze tra la stringa che viene inserita in PowerShell e il valore effettivo che entra nel registro. In particolare, dobbiamo racchiudere il tutto in virgolette singole e raddoppiare le virgolette interne, al fine di evitare errori nell'analisi dei comandi.
Ora dovresti avere una nuova voce del menu contestuale per gli script di PowerShell, chiamata "Esegui con PowerShell (Admin)".
Ritocchi finali.
Ci sono ancora un paio di ritocchi per rendere la vita un po 'più semplice. Per uno, che ne pensi di eliminare completamente la funzione Blocco note? Basta copiare il valore "(Predefinito)" dal tasto Comando sotto Modifica (sotto), nella stessa posizione sotto Apri.
'C:WindowsSystem32WindowsPowerShellv1.0powershell_ise.exe' '%1'
Oppure, è possibile utilizzare questo bit di PowerShell (con Admin e HKCR, ovviamente):
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellOpenCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell_ise.exe' '%1''
Un altro fastidio minore è l'abitudine della console di scomparire una volta che una sceneggiatura è completa. Quando ciò accade, non abbiamo alcuna possibilità di rivedere l'output dello script per errori o altre informazioni utili. Questo può essere risolto mettendo una pausa alla fine di ciascuno dei tuoi script, ovviamente. In alternativa, possiamo modificare i valori "(Default)" per le nostre chiavi di comando per includere il parametro "-NoExit". Di seguito sono riportati i valori modificati.
(Senza accesso amministratore)
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-NoExit' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1'
(Con accesso amministratore)
'C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList '-NoExit -ExecutionPolicy RemoteSigned -File '%1'' -Verb RunAs}'
E naturalmente, ti daremo anche quelli nei comandi di PowerShell. Ultimo promemoria: Elevation & HKCR!
(Non-Admin)
Set-ItemProperty HKCR:Microsoft.PowerShellScript.1ShellCommand '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-NoExit' '-ExecutionPolicy' 'RemoteSigned' '-file' '%1''
(Admin)
Set-ItemProperty 'HKCR:Microsoft.PowerShellScript.1ShellRun with PowerShell (Admin)Command' '(Default)' ''C:WindowsSystem32WindowsPowerShellv1.0powershell.exe' '-Command' ''& {Start-Process PowerShell.exe -ArgumentList ''-NoExit -ExecutionPolicy RemoteSigned -File '%1''' -Verb RunAs}''
Prendendo per un giro.
Per verificarlo, utilizzeremo uno script in grado di mostrarci le impostazioni di ExecutionPolicy e se lo script è stato avviato con autorizzazioni di amministratore. Lo script sarà chiamato "MyScript.ps1" e verrà memorizzato in "D: Script Lab" sul nostro sistema di esempio. Il codice è sotto, per riferimento.
if(([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] 'Administrator')) {Write-Output 'Running as Administrator!'} else {Write-Output 'Running Limited!'} Get-ExecutionPolicy -List
Utilizzando l'azione "Esegui con PowerShell":
Add-Content -Path 'D:Script LabMyScript.ps1' -Value '[ZoneTransfer]`nZoneId=3' -Stream 'Zone.Identifier'
Zone.Identifier può essere rimosso con questo:
Clear-Content -Path 'D:Script LabMyScript.ps1' -Stream 'Zone.Identifier'
Riferimenti utili:
- Esecuzione di script PowerShell da un file batch: il Blog di programmazione di Daniel Schroeder
- Verifica delle autorizzazioni di amministratore in PowerShell - Hey, Scripting Guy! blog
