Consulenze tecnologiche e informatiche
Autotask e Powershell

Autotask e Powershell

Nei precedenti articoli relativi ai componenti di Autotask Endpoint Managment (AEM), abbiamo visto sempre l’esecuzione di procedure in riga di comando DOS, mai eseguite con le funzionalità della più potente Powershell.

La scelta non è stata casuale ed è principalmente legata alla presenza di sistemi Microsoft Windows con versioni che non supportano in modo nativo questo tipo di shell, oppure che ne richiedevano l’installazione, per non parlare poi del fatto che per ragioni di sicurezza l’esecuzione di una quota parte delle direttive da remoto è di default bloccata.

Il tempo passa e bisogna andare avanti, quindi ecco arrivare un componente ibrido, che permette di determinare l’installazione della Powershell, la sua versione e l’impostazione di sicurezza per l’esecuzione.

Il componente è da me definito ibrido prendendo spunto da una versione presente nel ConStore di AEM, ovvero Powershell Execution Policy.

 

Le policy di esecuzione della Powershell

 

La capacità di azione della Windows Powershell è molto estesa e in grado di agire sui livelli più bassi del sistema operativo, permettendo di interagire anche con le componenti hardware e la gestione del intero sistema, dischi inclusi.

Per tale ragione esistono delle limitazioni di esecuzione degli script, per evitare che una azione virale possa mandare in esecuzione del codice pericoloso, ovviamente come per tutte le protezioni anche questi aspetti di configurazione possono essere modificati, anche attraverso uno script.

I livelli di permesso disponibili per l’esecuzione degli script sono quattro:

  • Restricted – Non possono essere eseguiti script e la Powershell è utilizzabile solo in interattivo.
  • AllSigned – Possono essere eseguiti solo gli script firmati da un autore attendibile.
  • RemoteSigned – Gli script scaricati devono essere firmati da un autore attendibile prima di essere eseguiti.
  • UnrestrictedNessuna restrizione.

Per poter operare con degli script eseguiti dall’esterno dobbiamo disporre dei privilegi più estesi, ovvero Unrestriceted.

Per assegnare una policy direttamente dalla Powershell possiamo usare il comando:

Set-ExecutionPolicy Unrestricted

I comandi sono rigorosamente case-sensitive.

Per visualizzare la policy attiva possiamo invece usare il comando:

Get-ExecutionPolicy

Nel caso di modifica dei permessi di esecuzione è opportuno ripristinare il default, ovvero Restricted, al termine dell’esecuzione degli script.

 

La versione della Powershell

 

Per avere un’idea delle cmdlet usabili possiamo determinare la versione di Powershell installato avvalendoci dell’aiuto del comando Get-Host, dal quale avremo un output di questo tipo.

Name             : ConsoleHost

Version          : 5.0.10586.672

InstanceId       : 79674aee-ec25-4358-8eaa-d7b2fb62076c

UI               : System.Management.Automation.Internal.Host.InternalHo

CurrentCulture   : it-IT

CurrentUICulture : it-IT

PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy

DebuggerEnabled  : True

IsRunspacePushed : False

Runspace         : System.Management.Automation.Runspaces.LocalRunspace

Salvo eccezioni particolari con aggiornamenti specifici in un sistema operativo Microsoft Windows 7 troveremo generalmente la versione 2 di Powershell, mentre in Microsoft Windows 10 troveremo la versione 5.

Ad ogni nuova versione sono state aggiunte delle funzionalità, pertanto nello sviluppo di un componente dovremo tener conto delle differenze di gestione e gestirle in modo appropriato, o attraverso una distinzione del codice in base alla versione oppure mantenendo le direttive della versione più vecchia sul mercato.

 

Il componente Powershell check and execution policy [WIN]

 

Il Componente è stato pensato per fornire alcune informazioni di base prima di programmare l’esecuzione di altri componenti o monitor basati su Powershell, prima di tutto determinare se è installata sul dispositivo remoto e quindi se la versione è compatibile con lo script che stiamo pensando di eseguire.

Solo in ultima istanza si è pensato di integrare la possibilità di modificare la policy, utilizzando il già esistente componente Powershell Execution Policy.

Il componente utilizza una variabile di configurazione ed esegue un controllo di post esecuzione, il controllo verifica la presenza di una particolare stringa nello stdout, la presenza della stringa è indice della mancanza di Powershell sul dispositivo e provoca la comparsa di una barra arancione nel report di esecuzione, dando un rapido riscontro.

La variabile di configurazione:

  • policy_level – richiede il livello di policy che si intende configurare tra le quattro possibili, ovvero Restricted, AllSigned, RemoteSigned, Unrestricted, Skip. La quinta non è una policy, il valore di default Skip richiede solo la verifica dell’installazione di PowerShell, la sua versione e la policy configurata.

L’azione di post esecuzione controlla se è presente una particolare stringa nello stdout del componente, per il caso specifico la stringa cercata per attivare l’azione è Powershell NOT installed, ovvero il messaggio impostato come risposta se la PowerShell non è installata. La presenza di questa stringa permette di avere una visualizzazione immediata dei dispositivi sprovvisti della utility, infatti nel report del componente all’interno della console di AEM avremo questi dispositivi visualizzati con la barra di esecuzione in colore arancio.

Analizziamo ora il componente.

  1. IF NOT EXIST C:\windows\System32\WindowsPowerShell\ (
  2. echo Powershell NOT installed
  3. goto END
  4. ) ELSE (
  5. echo Powershell installed
  6. )
  7. echo Powershell execution policy set to:
  8. powershell -noprofile -command “& {ExecutionPolicy}”
  9. echo Powershell version:
  10. powershell -noprofile -command Get-Host
  11. IF NOT %policy_level%==Skip (
  12. powershell -noprofile -command “& {Set-ExecutionPolicy %policy_level%}”
  13. ECHO Powershell execution policy set to:
  14. powershell -noprofile -command “& {ExecutionPolicy}”
  15. ) ELSE (
  16. echo Execution Policy Unchanged
  17. )
  18. :END

Dalla Riga 1 alla Riga 4 il componente determina l’esistenza di PowerShell cercando la sua cartella di installazione, in sua assenza la Riga 3 chiude la procedura con la stringa di errore che innesca il controllo di post esecuzione.

Nel caso in cui la PowerShell è installata abbiamo il messaggio di conferma indicato alla Riga 5.

La Riga 8 esegue un comando PowerShell all’interno di una sessione CMD, nello specifico richiede la Policy di Esecuzione configurata.

La Riga 10 esegue un comando PowerShell all’interno di una sessione CMD, nello specifico le informazioni di versione.

Dalla Riga 11 alla Riga 15 viene impostata la nuova policy di esecuzione come specificato con la variabile policy_level, i contenuti di questa variabile sono strettamente case sensitive, quando il valore della variabile è impostato a Skip si viene rimandati al messaggio di chiusura della Riga 15, senza apportare modifiche.

 

Scarica il componente di base.

 

Buon lavoro!

 

Se sei interessato ad approfondire questi contenuti o ad avere nella tua aziende questi strumenti o i prodotti menzionati, contattaci attraverso la pagina di contatto di questo sito, o se preferisci cercami attraverso la pagina FaceBook o il mio profilo Linkedin.

Per essere informato sui nuovi articoli e contenuti puoi anche iscriverti alle nostre newsletter.

 

 

 

 

Categorie
Archivi
Count per Day
  • 253Questo articolo:
  • 172849Totale letture:
  • 28Letture odierne:
  • 281Letture di ieri:
  • 21 novembre 2016Dal:
Iscriviti alla Newsletter
Iscriviti alla nostra newsletter ed unisciti ai nostri iscritti.

Seleziona lista (o più di una):




Trattamento dei dati