GuardShell: proteggere i programmi con password e passfile

In Windows, non è sempre facile o attuabile l'impostazione dei giusti permessi di accesso ai programmi, differenziando in modo granulare quali applicazioni condividere e di quali limitare l'utilizzo, soprattutto se tali programmi non prevedono autenticazione all'avvio o se si condivide l'account con altre persone o se si tratta di programmi non ancora installati. Altre volte si potrebbe voler impedire a processi noti (non di sistema) di partire in automatico in background, senza che l'utente possa intervenire. In tutti questi casi, per impostare dei blocchi che richiedano autenticazione, senza addentrarsi nella gestione dei permessi di Windows, senza bisogno di essere admin e senza ricorrere a programmi di terze parti, è possibile usare GuardShell (disponibile anche in versione italiana).

GuardShell è uno script PowerShell per Windows 10, che consente all'utente di generare un altro script (lo "script di protezione", il nome è a scelta) che gestisce la protezione di processi e programmi (e un po' anche delle cartelle, come vedremo in seguito) tramite password e/o passfile (non inteso semplicemente come file usato al posto della password; verrà chiarito meglio a breve). La protezione può essere usata per proteggere ad esempio l'accesso a un browser o ad altri programmi di lavoro, ma non deve essere usata su processi cruciali di sistema, altrimenti si rischia di destabilizzare o compromettere l'intero sistema operativo.

Utilizzo

Per applicare la protezione a un programma è necessario conoscere il nome del principale processo corrispondente; per farlo è possibile utilizzare il seguente comando: Get-Process | Where-Object {$_.MainWindowTitle -match "..."}, sostituendo ai puntini di sospensione una parola significativa presente nell'intestazione della finestra del programma, e poi premere invio; nella colonna ProcessName avremo il nome da immettere in GuardShel. Ad esempio Get-Process | Where-Object {$_.MainWindowTitle -match "malwarebytes"} (o la forma contratta ps | ? {$_.MainWindowTitle -match "malwarebytes") se vogliamo sapere quale è il nome del processo di Malwarebytes:

Una volta individuato il nome esatto del processo, possiamo avviare GuardShell. Come ogni script PowerShell, per essere eseguito richiede sia settata una adeguata execution policy. Probabilmente il metodo più rapido è: aprire PowerShell nella cartella in cui è stato salvato lo script, premendo SHIFT + tasto destro del mouse con il cursore posizionato nella cartella; cliccare su Apri finestra PowerShell qui; digitare: powershell.exe -ep bypass .\GuardShell.ps1 e premere invio.

Se il bypass fosse stato bloccato da policy di sistema, è possibile utilizzare il comando Set-ExecutionPolicy -Scope CurrentUser RemoteSigned per impostare la policy "remote signed" (gli script creati in locale possono essere eseguiti anche se non digitalmente firmati). Non resta allora che copiare il contenuto dello script in un file di testo creato ad hoc, e poi salvarlo come .ps1; cliccarci con il tasto destro e poi su Esegui con PowerShell.

Le informazioni richieste da GuardShell sono quelle presenti in questo esempio:

Non tutti i campi vanno compilati, è possibile scegliere di usare solo la password o solo il passfile, oppure la password per i processi e il passfile per una cartella (plausibilmente quella che contiene lo script, ma volendo anche un'altra).

Qualora si scelga di usare la password, va considerato che si avranno 5 secondi a disposizione per scriverla, sebbene possa essere comunque copiata e incollata (eventualmente la clipboard history va gestita di conseguenza). Quando si proverà ad avviare un programma monitorato, comparirà una piccola finestra in cui inserire la password; potrebbe essere necessario cliccarci per poterci scrivere, mentre non è invece necessario premere OK (è stato messo solo per abbreviare l'eventuale attesa):

Se si è optato per usare solo (o anche) il passfile e la passfolder(una cartella a scelta), questo è il loro semplice funzionamento: se il passfile scelto è nella passfolder scelta, la protezione è disattiva; se il passfile non è nella passfolder, la protezione è attiva (proprio come il rapporto fra chiave e serratura, fermo restando che poi la chiave-passfile deve essere quella giusta). L'idea di fondo è quindi di tenere il passfile non nella passfolder (in un dispositivo esterno? nel cloud? in una cartella compressa?) e, quando è necessario, fare una sua copia nella passfolder.

Il passfile è valido finché non viene alterato il suo hash (viene usato lo SHA1); il file può quindi essere rinominato o anche manipolato, è importante che, al momento dell'uso, i dati non siano stati alterati rispetto a quando è stato creato lo "script di protezione". Da considerare che quando è attiva la protezione con passfile, a differenza di quella con password, non ci saranno avvisi o interazioni con gli utenti e sarà poi necessario ricordarsi di ripristinare la protezione, cancellando la copia o rispostando altrove il passfile.

In generale, per essere sicuri che la protezione sia stata ripristinata, dopo aver chiuso un processo sbloccato con la password, oppure aver rimosso il passfile dalla passfolder, è bene attendere circa 5 secondi (se tale intervallo di default non è stato modificato manualmente nello script).

Una volta che lo "script di protezione" è stato creato, è possibile (oltre che attivarlo manualmente) anche usarlo come attività pianificata all'avvio, all'accesso di un utente o al verificarsi di un evento. In merito rimandiamo a quanto spiegato qui per CanaryShell, ricordando che è anche possibile impostare l'attività come nascosta e, se siete admin, come task da eseguire con massimi privilegi. Oltre al consueto -ExecutionPolicy Bypass, i parametri aggiuntivi -WindowStyle Hidden -NoLogo -NonInteractive -NoProfile (da inserire in "Aggiungi argomento (facoltativo)" prima di -File [percorso script]) impediscono allo script di lasciare aperta una finestra PowerShell all'avvio.

FAQ

• Come essere sicuri che lo "script di protezione" sia stato adeguatamente configurato?

Prima di creare lo "script di protezione", GuardShell controlla che le cartelle indicate esistano e che non ci siano informazioni necessarie mancanti. Bisogna comunque fare attenzione a ricordarsi quale sia il passfile, poiché è salvato nello script solo con il rispettivo hash. La blocklist con i processi da monitorare, la password e il percorso della passfolder sono in chiaro nello script e possono quindi essere recuperati (e per questo è importante proteggere la cartella dello script, v. sotto).

• Come prevenire la manomissione dello "script di protezione"?

Il modo migliore è impostare adeguati permessi, sia per l'esecuzione dello script che per l'accesso alle cartelle coinvolte. In generale, è buona prassi includere fra i processi monitorati anche "taskmgr" e "mmc" così che lo script non sia facilmente arrestabile usando "Gestione attività" o "Utilità di pianificazione" (considerando tuttavia che mmc viene è alla base anche di "Visualizzatore Eventi", "Gestione Dischi", "Gestione Dispositivi", etc.). Oltre a scegliere percorsi e nomi delle cartelle insospettabili, è anche possibile. come mostrato nell'esempio sopra, impostare un passfile e una passfolder per ostacolare l'accesso alla cartella dello "script di protezione". Tenere il passfile fuori dalla passfolder, impedirà ad Esplora file (e solo ad esso) di aprire quella cartella. Questa debole protezione può essere applicata, sempre dallo "script di protezione", anche ad altre cartelle, anche senza impostare processi da monitorare (basta premere Invio quando vengono richiesti).

• Perché, dopo aver rimosso la protezione (con password o passfile), il programma si avvia ma il file non viene aperto?

Va ricordato che sbloccare un processo, con entrambi i metodi, non apre direttamente il file da cui è partita la chiamata. Ad esempio, se proviamo ad aprire "note.txt" e Notepad è fra i processi controllati, quando sblocchiamo la protezione, Notepad si aprirà vuoto: sarà necessario aprire "note.txt" dalla GUI di Notepad oppure semplicemente ricliccare sul file (senza chiudere Notepad, se stiamo usando la protezione tramite password: almeno un'istanza di Notepad deve essere aperta e sbloccata, per evitare un repentino ripristino della protezione). Ulteriori esempi: ciò non accadrà con "Gestione attività", ma con "Utilità di pianificazione" invece sì (prima si aprirà una console MMC e poi sarà possibile avviare la consueta finestra).

• Reinstallare il programma controllato dallo script, aggirerà il monitoraggio?

Lo "script di protezione" monitora i processi attivi cercando quelli nominati nella blocklist, non è rilevante se i programmi da bloccare vengano reinstallati o non siano nemmeno installati; appena verrà rilevato un processo presente nella blocklist (che non sia stato già inserito nella safelist, v. sotto), la protezione si attiverà.

• Cosa accade nella cartella dello "script di protezione" durante il monitoraggio?

Nella cartella dello "script di protezione", lo script verrà nascosto e sarà visibile il file "safelist.txt", usato automaticamente dallo script (l'utente non deve modificarlo) per archiviare temporaneamente i processi autorizzati a seguito della corretta password; se tale file venisse cancellato, verrà rigenerato vuoto.

• Quali comportamenti anomali può avere lo script?

GuardShell e le sue possibili combinazioni di "script di protezione" sono stati testati su Windows 10 Pro, anche con account non admin, e hanno funzionato regolarmente. Può succedere che un programma controllato riesca ad apparire sullo schermo prima di essere chiuso dallo script e dalla eventuale richiesta di password; se si preferisce evitarlo, vanno ridotti nello "script di protezione" i 5 secondi di intervallo fra i controlli di password e/o passfile. Se lo "script di protezione" è stato impostato come attività pianificata, è normale che il terminale PowerShell compaia per un momento all'avvio. Su Windows 11, GuardShell richiede che in Sistema / Per sviluppatori / Terminale sia impostato Windows console host.