Applocker vs politica di restrizione del software

L'obiettivo è impedire agli utenti di eseguire programmi indesiderati su un server terminal.

Ho letto molti articoli di Microsoft e di altri che affermano che la nuova funzionalità di Applocker è migliore del 100% rispetto alla vecchia politica di restrizione del software ed è raccomandata in sostituzione di quest'ultima.

Non sono sicuro di comprendere i vantaggi reali di Applocker oltre all'esecuzione in modalità kernel. La maggior parte delle sue funzionalità può essere riprodotta con la politica di restrizione del software.

Allo stesso tempo ha un GRANDE svantaggio che lo rende piuttosto inutile: non è estensibile e non è possibile aggiungere estensioni di file personalizzate che si desidera limitare.

Quali sono i vantaggi di Applocker rispetto a SRP e cosa consiglieresti per il controllo del software?

La politica di restrizione del software è deprecata da Microsoft (la tecnica sostiene che SRP non è supportato ), poiché Windows 7 Enterprise / Ultimate ha introdotto AppLocker.

In pratica SRP ha alcune insidie, sia per i falsi negativi che per i falsi positivi. AppLocker ha il vantaggio di essere ancora attivamente gestito e supportato. Se AppLocker è un'opzione, potrebbe essere quella più economica, dopo aver tenuto conto del tempo e dei rischi assunti. È anche possibile che ci sia un'alternativa di terze parti adatta (ma questa domanda non includeva quell'opzione :).

Spero che otterresti una perfetta comprensione delle insidie ​​di SRP prima di cadere in una di esse </sarcasm>. Alcuni di essi sono descritti in un bell'articolo sulla sicurezza di Vadims Podāns .

Insidie ​​note

1. Per impostazione predefinita, \Windowsè consentita l'esecuzione dalla cartella. Alcune sottocartelle possono essere scritte dagli utenti. Applocker è lo stesso, ma almeno la documentazione ufficiale menziona questa limitazione .

   EDIT: "Per enumerare tutte le cartelle con gli utenti l'accesso in scrittura è possibile utilizzare, ad esempio, l'utilità AccessEnum dal pacchetto Sysinternals." (o AccessChk ).

   Tecnicamente la documentazione mette anche in guardia contro l'override delle regole predefinite . EDIT: un documento NSA fornisce 16 esempi di cartelle da inserire nella blacklist con SRP , sebbene le regole del percorso del registro utilizzino le barre rovesciate in modo errato, quindi devono essere corrette (vedere il punto sui percorsi del registro di seguito) e avverte di una voce della lista nera troppo ampia comune.

   La domanda ovvia è perché non stiamo inserendo nella whitelist attentamente i singoli percorsi \Windows. (Incluso l' \Windows\*.exeeredità System32\*.exe, ecc.). Non ho notato alcuna risposta a questo da nessuna parte :(.

2. Utilizzando variabili di ambiente come %systemroot%, SRP può essere bypassato dagli utenti cancellando la variabile di ambiente. EDIT: questi non sono utilizzati nelle impostazioni predefinite suggerite. Tuttavia potrebbero essere allettanti da usare. Questo footgun è stato corretto in AppLocker, perché non esamina mai le variabili di ambiente.

3. Le impostazioni predefinite suggerite trascurano di consentire i due diversi \Program Filesutilizzati nelle moderne installazioni a 64 bit. Quando si risolve questo problema utilizzando i "percorsi di registro" più sicuri, vengono segnalati falsi rifiuti in situazioni casuali, che potrebbero essere facilmente persi nei test. ad es. vedere i commenti su SpiceWorks SRP howto . EDIT: Questo ha a che fare con le applicazioni a 32 bit che leggono i percorsi rilevanti dal nodo WOW6432 del registro: la risoluzione è quella di aggiungere entrambi questi percorsi a SRP per consentire a tutti i programmi di funzionare su macchine a 32 e 64 bit come illimitato se avviato da un processo host x64 o x86:%HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)% %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%
4. Le estensioni predefinite trascurano di vietare gli script PowerShell (* .PS1) supportati da Windows . (Vedi video ). E anche APPX ... anche secondo la tabella comparativa di Microsoft, SRP non è in grado di gestire "App in pacchetto" in Windows 8, non ho idea di cosa significhi.
5. Regole di percorso del Registro di sistema non devono avere tagli immediatamente dopo l'ultimo segno di percentuale (pur essendo inclusi in Microsoft proprio built-in regole per XP / Server 2003) e le barre rovesciate devono essere sostituiti con forwardslashes in ordine per la regola di lavoro ( 1 / 2 / 3 ).
6. Delle fonti che ho trovato per SRP, nessuna ha messo insieme l'elenco completo sopra per te. E ho scoperto l'articolo di Vadims Podāns solo per caso. Cos'altro si nasconde là fuori?
7. Molte fonti consigliano semplicemente di rimuovere i file LNK dall'elenco. (E scorciatoie Web per evitare di rompere i Preferiti ?!). Stranamente, nessuna fonte sembra discutere delle vulnerabilità di LNK ... o indurre gli interpreti di script a eseguire file con un'estensione imprevista, ad esempiowscript /e ... o forse a inserire abbastanza shellcode in un parametro di script inline ... ecc.
8. Se si tenta di scendere a compromessi consentendo i file LNK sul desktop e si lascia agli utenti l'accesso in scrittura al desktop, ora possono ignorare completamente i criteri. Delizioso consiglio di Vadims Podāns di nuovo. Si noti che la spiegazione si applica all'utilizzo di qualsiasi estensione in una regola del percorso. Microsoft presenta numerosi esempi di ciò *.Extension, incluso , senza preavviso. Quindi non puoi fidarti della documentazione ufficiale e sembra improbabile che venga riparato ora.
9. [Svantaggio potenziale di AppLocker]. Vadims Podāns segnala che le voci SRP che utilizzano unità mappate non funzionano. È invece necessario utilizzare il percorso UNC. Forse si applicherebbero quindi all'accesso tramite un'unità mappata? non è chiaro al 100%. Apparentemente AppLocker era diverso: non funzionava con nessuno dei due :(. "A causa di un motivo sconosciuto, i percorsi UNC non funzionano in Applocker! Ciò significa che se l'applicazione è installata in rete, è necessario creare hash o regole del publisher ".

Approccio pragmatico

La whitelisting software è potenzialmente una difesa molto potente. Se diventiamo cinici: questo è esattamente il motivo per cui Microsoft deprezza le versioni più economiche e inventa quelle più complesse.

Forse non sono disponibili altre opzioni (includere soluzioni di terze parti). Quindi un approccio pragmatico sarebbe quello di provare a configurare SRP nel modo più semplice possibile. Trattalo come un ulteriore livello di difesa, con buchi noti. Abbinando le insidie ​​sopra:

1. Inizia dalle regole predefinite (dall'era pre-Win7 :).
2. Preferisco non utilizzare le variabili di ambiente, ad es %systemroot%.
3. Aggiungi regole per assicurarti che entrambe le \Program Files\directory siano consentite sui moderni computer a 64 bit. I "percorsi di registro" extra che dovrai aggiungere \Program Files\sui computer a 64 bit sono %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir (x86)%e %HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramW6432Dir%.
4. Quando si aggiungono le regole del percorso di registro, escludere qualsiasi barra rovesciata immediatamente dopo il segno di percentuale e sostituire eventuali altre barre rovesciate \con le barre rovesciate /(ad es. %HKEY_LOCAL_MACHINE\Software\CompanyName\CustomApps%App/Bin/start.exe)
5. Aggiungi PS1 all'elenco di estensioni controllate.
6. Comprendi che una configurazione SRP gestibile non è sicura nei confronti di un utente determinato a sconfiggerla. L'obiettivo è aiutare / incoraggiare gli utenti a lavorare all'interno della politica, per proteggerli da attacchi come "download drive-by".
7. Consenti file LNK. (Preferibilmente rimuovendolo dall'elenco delle estensioni, non tramite una regola del percorso).
8. Vedi sopra :).
9. Assicurarsi che la cartella degli script di accesso sia consentita. Il documento della NSA suggerisce di aggiungere \\%USERDNSDOMAIN%\Sysvol\. (Vedi punto 2, sospiro, quindi vedi punto 6).

Sono d'accordo che SRP ha alcune funzionalità aggiuntive di cui AppLocker potrebbe davvero beneficiare.

Detto questo, vedo i grandi vantaggi di AppLocker (come documentato da questo confronto ) come:

• Le regole di AppLocker possono essere indirizzate a un utente specifico o a un gruppo di utenti, mentre SRP viene applicato su tutto il computer.
• AppLocker supporta la modalità di controllo in modo che le regole possano essere testate in produzione prima di essere applicate. SRP non ha una modalità di solo log equivalente.

Il più grande vantaggio per me è la possibilità di autorizzare gli eseguibili firmati dall'editore. Dai un'occhiata a questo http://technet.microsoft.com/en-us/library/ee460943(v=ws.10).aspx

Non ci sono vantaggi di AppLocker, le bugie palesi pubblicate da Microsoft: 1. Gli oggetti Criteri di gruppo con regole SAFER possono essere collegati a utenti e gruppi di utenti; 2. Windows Vista ha introdotto più oggetti Criteri di gruppo locali che ottengono lo stesso risultato senza un controller di dominio; 3. La modalità di controllo è disponibile tramite la funzionalità di registrazione estesa senza applicazione.

Uso Applocker all'interno della mia azienda. La strategia che utilizziamo è: Nega tutto come base (in realtà: l'impostazione predefinita Applocker), quindi fai ciò che è stato suggerito: crea una regola che consenta solo applicazioni firmate (ufficio, Adobe, Wintools, Axe ecc.). La maggior parte, forse tutto il malware non è un software firmato, quindi non verrà eseguito. Non richiede quasi manutenzione. Ho dovuto consentire solo 3 app legacy extra.

Inoltre non posso confermare che non si possano usare percorsi UNC. In alcune regole di negazione della sicurezza extra utilizzo con successo il percorso UNC. La trappola sta nell'usare le variabili d'ambiente: non funzionano per Applocker. Usa * caratteri jolly. Lo uso su Windows 2008 R2 e Windows 2012 R2.

Mi piace molto: non c'è quasi nessun calo di prestazioni. Come dice la documentazione: Applocker si affida al servizio Identità applicazione (assicurarsi che si avvii automaticamente).