Windows Server: Introduzione ad AppLocker

Windows Server

Una delle features più interessanti presenti in Windows Server 2008 R2, portata anche nelle versioni successive, è sicuramente AppLocker. Ai tempi di 2003, ma anche con 2008 RTM, l’unico modo per bloccare i software indesiderati era fare delle regole con le Software Restriction Policies, scegliendo tra una regola di Hash o una regola legata al path di installazione.

Entrambe le regole sono aggirabili, la prima attraverso il rilascio di una nuova versione e la seconda installando il software in una cartella diversa da quella che si aspetta di solito. Benchè gli utenti siano configurati come classici Users, e quindi privi di qualsiasi permesso di installazione, esistono dei software che sono capaci di eludere questa cosa, come per esempio Google Chrome: il browser di Big G viene distribuito attraverso ClickOnce, utile componente realizzata da Microsoft e disponibile in Visual Studio, capace di distribuire un software senza che quest’ultimo installi chiavi nel registro di configurazione, registri DLL e, soprattutto, senza che l’applicazione finisca nella cartella Programs Files.

AppLocker funziona in un modo più avanzato rispetto alla SRP, dando la possibilità di filtrare eseguibili, script o file di installazione; nel caso dei file eseguibili, argomento preso in considerazione in questo articolo, viene analizzato il file sorgente, recuperando tutta una serie di informazioni utili ad ampliare il raggio d’azione per permette il blocco di un’applicazione attraverso questi criteri:

  • Publisher
  • Product Name
  • File Name
  • File Version

2011_07_08_applocker-01

Figura 1 – Criteri di blocco di AppLocker

Un esempio di blocco è quello di filtrare tutte le applicazioni che sono distribuite da un determinato produttore software. AppLocker è recuperabile tramite le Group Policy ed è una regola che si applica solo a livello Computer – vedi figura 2.

2011_07_08_applocker-02

Figura 2 – AppLocker nelle GPO

I benefici che se ne traggono sono tanti, per esempio quando viene rilasciato un nuovo aggiornamento dell’applicazione, non bisognerà fare niente perchè se la regola prevede il blocco di tutte le versioni di quel software, niente potrà scavalcare la regola. Un altro vantaggio è legato al discorso della sicurezza: se in azienda viene utilizzato un software che nella build 2.0 presenta dei bug, sarà possibile impostare il blocco per le versioni inferiori alla versione 3.0.

Prima di creare una regola di AppLocker è consigliato creare le Default Rule – figura 3, che impostano delle regole predefinite per avviare tutte le applicazioni che si trovano nella Programs Files e nella cartella Windows. Una volta fatta questa operazione e creata una regola di blocco, sarà obbligatorio impostare l’enforce di AppLocker, recuperabile nelle proprietà della policy – figura 4.

2011_07_08_applocker-03

Figura 3 – Regole di Default

2011_07_08_applocker-04

Figura 4 – Enforce delle Regole

Tutto pronto all’uso? No, perchè bisogna ancora attivare il servizio che gestisce l’enforcement. Nella stessa policy dove sono state create le varie rule di blocco, bisogna posizionarsi nella sezione dei Services ed attivare il servizio Application Identity. Da questo momento in avanti, tutti i client appartenti all’Organizzation Unit che contiene questa regola, saranno interessati dai blocchi impostati.

Purtroppo è da far presente che questa features è disponibile solo per Windows 7 o superiori, nelle versioni Enterprise, escludendo la versione più comune in certi ambienti, ovvero la Professional.