Quali sono i pro / contro di bloccare l'esecuzione di un programma in% appdata%,% temp%, ecc.?


13

Durante la ricerca di modi per prevenire CryptoLocker , ho visto un post sul forum che mi consigliava di utilizzare Group Policy Objects (GPO) e / o software antivirus per bloccare l'accesso alla corsa nei seguenti percorsi:

  1. % Appdata%
  2. % Localappdata%
  3. % Temp%
  4. %Profilo utente%
  5. Archivi compressi

Ovviamente, qualsiasi cosa scritta in un forum dovrebbe essere presa con cautela. Vedo vantaggi nel fare questo, tuttavia, principalmente perché al malware piace eseguire da queste posizioni. Naturalmente, ciò potrebbe avere un impatto anche sui programmi legittimi.

Quali sono gli svantaggi nel bloccare l'accesso in corsa a queste posizioni?

Quali sono i vantaggi?


3
Of course, this could impact legitimate programs as well.- leggermente ...
TheCleaner,

1
Ad esempio, GitHub si è installato da solo in% APPDATA% e quando il mio amministratore di sistema ha imposto recentemente le nuove regole per bloccare i file eseguibili per l'esecuzione da quella posizione, GitHub per Windows non può più avviarsi. git.exe in% APPDATA%, originariamente installato da GitHub - un po 'fastidioso, ovviamente ...
Jim Raynor

Risposte:


12

Il motivo per cui al malware piace eseguire da queste posizioni è perché al software legittimo piace eseguire da queste posizioni. Sono aree alle quali l'account dell'utente dovrebbe aspettarsi di avere un certo livello di accesso.

Basato su un rapido grep del mio sistema e un account utente finale casuale sulla nostra rete:

%appdata%

In questo momento, ho Dropbox , il programma di installazione per Adobe AIR e alcune probabilità di Microsoft Office e termina in questa cartella.

%localappdata%

join.me e SkyDrive sembrano vivere qui, o almeno essere passati di recente.

%temp%

Molti programmi, legittimi o meno, vorranno essere eseguiti da questa cartella. Gli installatori in genere si scompattano in una sottocartella di questo quando si esegue setup.exesu un archivio di installazione compresso.

%Profilo utente%

In genere sarà sicuro a meno che l'utente non abbia particolari requisiti, sebbene si noti che almeno alcune delle cartelle sopra potrebbero essere sottoinsiemi su una rete con profili di roaming.

Archivi compressi

Non eseguire direttamente il codice, invece in genere estrarre %temp%ed eseguire da lì.

Se devi bloccare queste aree o meno, dipende da cosa stanno facendo i tuoi utenti. Se tutto ciò che devono fare è modificare i documenti di Office, giocare a Minesweeper durante il pranzo e forse accedere a un'app LOB tramite un browser, ecc., Potresti non avere troppi problemi a bloccare gli eseguibili in almeno alcune di queste cartelle.

Chiaramente lo stesso approccio non funzionerà per le persone con carichi di lavoro meno definiti.


Anche Chrome vive in%appdata%
Juri Robl l'

5
@JuriRobl solo la versione consumer, la versione aziendale di Chrome ha un comportamento molto migliore.
GAThrawn

@JuriRobl - Chrome sul mio PC di lavoro è in C: \ Programmi (x86) \ Google \ Chrome \ Application. La versione aziendale come dice GAThrawn. Inoltre, stavo tentando di fornire esempi basati su cosa sul mio sistema, non per produrre alcun tipo di elenco esaustivo.
Rob Moir,

6

Professionisti:

I malware che tentano di eseguire da tali posizioni non saranno in grado di essere eseguiti.

Contro:

I programmi legittimi che tentano di eseguire da tali posizioni non potranno essere eseguiti.


Per quanto riguarda quali programmi legittimi hai nel tuo ambiente che necessitano di diritti di esecuzione in quelle directory, solo tu puoi dirlo, ma vedo che RobM ha appena pubblicato una risposta con una panoramica di alto livello . Il blocco dell'esecuzione da queste directory ti causerà problemi, quindi devi prima eseguire alcuni test per determinare quali problemi avrai e come risolverli.


3

Tali raccomandazioni funzionerebbero perfettamente nel mio ambiente. NESSUN utente è autorizzato ad installare software e NESSUNO del software approvato viene eseguito dalle posizioni menzionate. Le stazioni di lavoro hanno il software approvato preinstallato nell'immagine della stazione di lavoro e aggiornato tramite script.

Dropbox, Chrome, Skype, ecc. Possono essere riposizionati durante l'installazione in una posizione di installazione "Programmi" più accettabile.

Fintanto che hai una detrazione per amministratori o amministratori di dominio (e forse un account "Installer" specifico) per poter eseguire aggiornamenti e aggiungere software approvato, accetto le raccomandazioni.


2

Suppongo che tu voglia negare l'esecuzione non solo a queste cartelle ma all'intero albero a partire da esse (altrimenti non ha senso fare ciò che vuoi fare).

La conseguenza - ovvia - sarà che qualsiasi eseguibile che si trova in questi non verrà eseguito.

Sfortunatamente, questo includerà un numero piuttosto elevato di applicazioni legittime.

% localappdata% e% appdata% sono i più problematici: Dropbox, Chrome, SkyDrive, ad esempio, non funzioneranno. Anche la maggior parte dei caricatori automatici e molti installatori non funzioneranno.

% UserProfile% è anche peggio poiché include sia% localappdata% e% appdata%, nonché un numero di altre cartelle.

In breve: se si impedisce l'esecuzione delle applicazioni da queste cartelle, il sistema potrebbe diventare praticamente inutilizzabile.

% temp% è diverso. Mentre di tanto in tanto potresti avere programmi legittimi in esecuzione da lì, è abbastanza raro e di solito è facile aggirare. Sfortunatamente,% temp% si espande in diverse cartelle a seconda del contesto dell'utente da cui lo si sta espandendo: potrebbe finire in% localappdata% \ temp (nel contesto di un utente) o% SystemRoot% \ temp (nel contesto di il sistema), quindi dovrai proteggere ogni posizione individualmente.

% temp% è anche un buon candidato perché è lì che la maggior parte dei programmi di posta salverà gli allegati prima di aprirli: ciò aiuterà in molti casi di software malevoli basati sulla posta.

Un buon trucco è cambiare le premesse sulle cartelle C: \ Users \ Default \ AppData \ Local \ temp e C: \ Users \ DefaultAppPool \ AppData \ Local \ Temp quando si configura il sistema (e, ovviamente,% SystemRoot% \ temp). Windows copierà queste cartelle quando crea nuovi profili e quindi i nuovi utenti avranno un ambiente protetto.

Potresti voler aggiungere% UserProfile% \ Download al tuo elenco: è qui che la maggior parte dei browser eseguirà lo stesso file scaricato dall'utente e negare l'esecuzione da lì aumenterà anche la sicurezza.


2

Negli ultimi tre mesi sto correndo con una configurazione simile sulla mia workstation principale. Il mio utente principale ha i permessi di esecuzione su una directory o di scrittura ma mai entrambi.

Ciò significa che questo account non può introdurre nuovi eseguibili. Questo è il pro, posso eseguire programmi già sul sistema o installati da altri account, ma non riesco a scaricare alcun nuovo programma ed eseguirlo, questo significa che qualsiasi malware che arriva attraverso un browser o altri mezzi ha un tempo molto più difficile da eseguire sul mio sistema, anche la semplice iniezione DLL non funziona.

Come altri hanno sottolineato, il problema principale è che alcuni software legittimi utilizzano le posizioni che ho bloccato. Nel mio caso:

  • Google Chrome: ho installato la versione msi
  • qualsiasi applicazione per app portatili - che ora eseguo con un altro utente
  • Process Explorer - Uso direttamente la versione a 64 bit estratta
  • dism.exe: esegui come amministratore, che devo fare comunque la maggior parte delle volte.

Quindi sostanzialmente sto usando tre account, uno con cui ho effettuato l'accesso, un altro account utente normale per eseguire determinati programmi convalidati e un account amministratore per installare un nuovo software per gli altri due.

Mi piace il fatto che mi costringe a testare qualsiasi nuovo software scaricato in una VM.

Inizio la maggior parte dei miei programmi tramite PowerShell e ho tre shell, una per ogni account va bene per me. Se questo funziona davvero per te dipende dalla quantità di software che usi che deve essere trattata in modo diverso.

Su una macchina sviluppatore questo non funziona davvero perché devo compilare il mio codice e quindi eseguirlo. Quindi ho fatto un'eccezione per la mia directory di codice su un'unità dati, il malware potrebbe scansionare tutte le unità e trovarlo.

Sto usando ACL NTFS piuttosto che politiche per far rispettare questo. Questo impedisce l'esecuzione di qualsiasi programma, ma posso comunque creare uno script PowerShell e quindi eseguirlo e può fare abbastanza danni.

Quindi, mentre rende le cose più difficili, non è sicuro al 100% ma ti proteggerebbe comunque dalla maggior parte dei malware attuali.


0

Puoi cercare quelle cartelle, ma la maggior parte sono dati, esattamente come la cartella prende il nome. Ad esempio, vedrai Chrome, ma l'eseguibile effettivo si trova nella cartella c: \ programmi.

Impedisco a tutti gli eseguibili di funzionare ovunque sul computer tranne le cartelle del programma. Consentito temporaneamente solo quando devo installare qualcosa e non ho mai avuto problemi.


-1

Consiglierei una rapida ricerca delle directory per vedere cosa hai in ognuna di esse al momento. Se non sta eseguendo nulla da loro ora segui le indicazioni nel forum. Se dovessi riscontrare un problema in futuro, allora valuta semplicemente le tue opzioni. La maggior parte di questi non dovrebbe comunque contenere file eseguibili.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.