E’ in distribuzione da qualche giorno la beta di AVG Antivirus (e Internet Security) versione 9.0 che ho deciso di testare.

Come prevedibile il download si è ulteriormente gonfiato arrivando a toccare i 90 Mb  (quanta malinconia nel ricordare i tempi in cui AVG pesava poco più di 30 Mb).

Ho deciso di installare la Beta sopra una esistente installazione di AVG Internet Security 8.5 (ultima build) all’interno di una macchina virtuale (VirtualPc) dotata di Windows XP Pro SP3 completamente aggiornato e con solo AVG installato (a parte ovviamente il sistema operativo). Caratteristica particolare della mia installazione è il fatto che la mia AVG Internet Security è connessa ad un DataCenter AVG (residente su un’altra macchina di rete) versione 8.5.276.

Ho scelto di eseguire l’installazione personalizzata (non quella standard) selezionando TUTTI i componenti del pacchetto Internet Security, compresa la libreria di comunicazione per l’amministrazione remota.

La procedura di installazione non ha dato problemi di sorta : il primo impatto per l’utente è quello di un’interfaccia grafica ritoccata secondo i più moderni canoni gloss. Al momento della richiesta parametri per la stringa di connessione al datacenter, tuttavia, non è stata recuperata la stessa impostazione della vecchia 8.5. Inserendola manualmente comunque viene accettata lo stesso anche se poi, come vedremo avanti, non funzionerà.

Molto apprezzabile il nuovo wizard di prima configurazione del firewall che, con uno stile molto Windows, propone domande molto più intuitive sullo stato di connessione in rete (Computer Autonomo / In Rete / Con Dominio).

Ecco quindi la classica schermata di stato di AVG dopo l’installazione.

Come appare evidente la struttura è molto simile a quella della 8.5 a parte un po’ di restyling delle icone.

Aprendo il taskmanager ecco quello che appare dell’elenco di tutti i servizi riconducibili ad AVG.

In effetti l’occupazione di memoria sembra davvero notevole: tuttavia, come ben specificano quelli di AVG, diversi servizi utilizzano aree di memoria condivisa per cui è impossibile determinare l’occupazione reale di RAM facendo la mera somma della memoria allocata da ogni servizio.

Ma cosa cambia nella sostanza ? In generale il prodotto è stato reso, se possibile, ancora più user friendly (anche se aborro questa definizione).
La prima caratteristica che apprezzeranno sicuramente gli utenti meno esperti riguarda il firewall : le classiche domande che venivano poste da AVG sulla necessità di aprire le porte per questo o quel servizio sono state largamente automatizzate mediante l’utilizzo di un database interno di servizi “attendibili”. Per questo, in numerose occasioni (vedasi il primo avvio di Internet Explorer, o Firefox, o l’apertura di una connessione FTP ecc.) la regola viene creata automaticamente con una notifica simile alla seguente:

Resta comunque la possibilità di configurare manualmente le regole del firewall mediante il solito menu Strumenti -> Impostazioni Firewall che ora, finalmente, riporta il dettaglio del solo profilo attivo, non di tutti.

Un’altra annoyance rimossa è l’inserimento automatico, una buona volta, del servizio Condivisione File e Stampanti per i computer inseriti in dominio.

Apprezzo molto poi il fatto che nelle impostazioni della protezione residente/permanente, l’impostazione predefinita NON prevede la scansione dei file archivio (zip, rar ecc.) che è assolutamente inutile dato che i file vengono poi sottoposti a scansione dopo la loro estrazione.

La velocità di scansione mi è sembrata grossomodo invariata mentre, per quanto riguarda l’efficacia di rilevamento, non so dire se questa sia migliorata o meno, non avendo a disposizione un database di malware adeguato.

Per quanto riguarda l’area di quarantena poi è stata introdotta una modifica: il vecchio percorso “C:\$AVG\$VAULT” all’interno del quale venivano salvate le copie criptate dei file infetti messi in quarantena è stata sostituita dalla creazione di un nuovo nome casuale e i file non sono più inseriti singolarmente con estensione .fil bensì in contenitori di estensione .dat

La cosa che mi terrorizza è, come detto all’inizio dell’articolo, la mancata connessione di AVG 9.0 al datacenter di AVG 8.5: temo infatti che, come per il passaggio dalla 7.5 alla 8, cambi il protocollo di comunicazione e, verosimilmente, anche la porta rendendo quindi impossibile una migrazione trasparente dei client AVG da 8.5 a 9.0 in ambienti di rete di grandi dimensioni.

Ho ricevuto molte richieste su come sia possibile avviare in automatico una macchina virtuale di VirtualPc all’avvio del computer host.
Va subito premesso che VirtualPc non può essere avviato come servizio di sistema e quindi non può eseguire la propria attività in background, in modo invisibile all’utente, come farebbe VMWare per intenderci.

Ciò nonostante VirtualPc dispone di un discreto set di switch da riga di comando che possono essere utili per il caso specifico. Per un dettaglio completo delle opzioni disponibili da riga di comando è disponibile l’aiuto in linea di Virtual Pc : Menu ? -> Guida in linea Virtual Pc  e quindi navigando al percorso Virtual Pc \ Concetti su Virtual Pc \ Amministrazione di Virtual Pc \ Gestione di Virtual Pc dalla riga di comando \ Informazioni di riferimento sull’utilità della riga di comando per Virtual PC.

Il giochino consiste nel creare un file batch che contenga le istruzioni per l’avvio della macchina virtuale e quindi di inserire questo file nella cartella “Esecuzione Automatica” di Vista in modo che, subito dopo aver effettuato la procedura di login, venga avviato il pc virtuale in automatico.

Nell’immagine qui sotto è rappresentata la tipica console di VirtualPc con alcune delle macchine virtuali cha abitualmente utilizzo.



Volendo avviare automaticamente, per esempio, la prima macchina dell’elenco, che si chiama “Windows XP Pro” dovrò:

1. Aprire notepad
2. Inserire nella prima riga il seguente testo (tutto su una riga):
   "%ProgramFiles%\Microsoft Virtual Pc\Virtual Pc.Exe" -singlepc -quiet -pc "Windows XP Pro" -launch
3. Salvare il file con nome “Lancia XP Pro.bat” (o altro nome che preferite basta che l’estensione sia .bat o .cmd)
4. Spostare il file appena salvato nella cartella “Esecuzione Automatica” del menu di avvio

Con questo esempio, dopo il login, viene avviata la macchina “Windows XP Pro” senza che venga avviata la console di VirtualPc

Tra le salienti che potete utilizzare ve ne è una in particolare che è davvero utile in ambienti ad alto rischio (per esempio volete utilizzare il pc per testare l’antivirus su dei nuovi virus): l’opzione è -extnetworking e va inserita dopo il nome della macchina virtuale. Con questo switch attivo tutte le comunicazioni di rete della macchina virtuale avvengono solo con l’ambiente esterno al pc fisico impedendo qualsiasi contaminazione del sistema operativo host.

Quante volte avete inserito un cd o una chiavetta USB nel computer e automaticamente è stata avviata l’esecuzione di un programma contenuto su quel supporto ? E’ il caso classico dei cd di installazione dei programmi. Ma cosa avviene in realtà ? E’ molto semplice : Windows, per impostazione predefinita, ogni volta che viene inserito un nuovo media (un supporto magnetico come un cd oppure una pen-drive o anche un floppy) va a vedere se sul supporto esiste un file (che potrebbe anche essere nascosto) che si chiama Autorun.inf e, se presente, esegue le istruzioni che vi sono contenute.

Il file autorun.inf è un normalissimo file di testo (visualizzabile e modificabile con un semplice notepad) la cui struttura è identica a quella dei file .ini. Per avere qualche informazione in più sul file autorun.inf potete consultare questa pagina di wikipedia.

Il file autorun.inf non è pericoloso di per se, contrariamente a quello che orrendamente ho sentito qualche volta dire (“ti sei beccato il virus autorun.inf …”): può essere pericoloso il contenuto che viene eseguito dalle istruzioni contenute in autorun.inf. Di seguito riporto, a puro titolo di esempio, un possibile contenuto per il file autorun.inf:

[autorun]
open=install\setup.exe
icon=icona.ico


In questo esempio dunque, il sistema operativo Windows, legge il file autorun.inf (che deve trovarsi nella radice principale del supporto inserito) ed esegue automaticamente il programma setup.exe contenuto nella sottocartella install del supporto, e rappresenta il file autorun.inf con l’icona contenuta nel file icona.ico (sempre all’interno del supporto). Fin qui nulla di male se non fosse per il fatto che il file setup.exe potrebbe essere infetto da virus o potrebbe installare qualcosa, che non vogliamo, in modo totalmente silente ed invisibile.

Ed è proprio la tecnica che ha utilizzato per la propria propagazione il virus Conficker (altrimenti noto come Downadup). Quindi, oltre alla solita raccomandazione di utilizzare sempre un buon antivirus costantemente aggiornato, può essere una buona idea aumentare la propria sicurezza disabilitando questa caratteristica di esecuzione automatica intrinseca a Windows Explorer.

Per quanto attiene a questo specifico aspetto, Windows Vista ha migliorato la sicurezza : l’esecuzione di autorun.inf (o meglio delle istruzioni che vi sono contenute) non avviene più in modo completamente automatico. Al contrario viene attivata una finestra di dialogo, detta Autoplay, che richiede se l’utente intenda eseguire le azioni di autorun.inf oppure qualcosa d’altro. Ma per le versioni precedenti di Windows (XP e 2003) l’impostazione predefinita è quella di una esecuzione cieca di autorun.inf
Tuttavia, sebbene Vista si riveli un pochino più sicuro, questa sicurezza svanisce rapidamente se l’utente, alla prima esecuzione di Autoplay, spunta il controllo di impostazione predefinita per evitare che venga riproposta in futuro la domanda.

Per disattivare o modificare questo comportamento esistono due strade. La prima è completamente manuale e NON permanente: in pratica bisogna avere l’accortezza di tenere premuto il tasto SHIFT ogniqualvolta si inserisce (o si collega) un nuovo supporto: in questo modo Windows XP non eseguirà in automatico le azioni di autorun.inf

La seconda strada è permanente e comporta la manipolazione del registro di sistema che può essere ottenuta mediante policy (gli amministratori di sistemi sanno di che parlo) oppure mediante una modifica diretta del registro di sistema tramite lo strumento regedit.

Questa seconda via può essere, a sua volta, divisa in due. Un metodo grezzo che disattiva l’esecuzione di autoun.inf indipendentemente dal tipo di unità inserita ed in tutte le condizioni. Questo primo metodo si basa su un invalidamento del file autorun.inf per cui il sistema non è più in grado di “gestire” questo tipo di file. Questa tecnica, detta IniFileMapping prevede la scrittura della seguente chiave/valore all’interno del registro di sistema:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"


Questo metodo è piuttosto grezzotto perchè non interviene in alcun modo sulla catena di eventi che portano all’esecuzione dell’attività di autorun e si limita a reinviare la mappatura delle chiavi che dovrebbero definire le API di manipolazione di autorun.inf ad una posizione inesistente che ovviamente non ne definisce alcuna. In pratica è come se Windows, una volta inserito il nuovo supporto, cercasse comunque di eseguire l’attività di esecuzione automatica ma, una volta trovato il file autorun.inf, non sapesse cosa farci.

Il secondo metodo è più elegante anche se più macchinoso e tiene in considerazione il modo in cui Windows cerca di capire se la funzionalità di autorun debba essere eseguita o no: ogni volta che viene inserito un nuovo supporto, Windows interroga dua chiavi specifiche di sistema per capire se su quella lettera di unità o su quello specifico tipo di unità debba essere eseguito, o meno, autorun. Queste due chiavi sono NoDriveAutorun e NoDriveTypeAutorun. Ognuna di queste chiavi può trovarsi alternativamente nel ramo HKLM (Local Machine) o HKCU (Current User) del registro: se vengono trovate in entrambi i rami allora assume rilevanza quella del ramo HKLM mentre quella nel ramo HKCU viene ignorata.

NoDriveTypeAutorun

Questa chiave si trova (o va creata) a seconda delle esigenze alternativamente in uno di questi percorsi:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Il tipo della chiave è REG_DWORD (DWORD a 32 bit). Il valore esadecimale da inserire viene calcolato utilizzando una sequenza di 8 bit dove :

• La posizione del bit indica il tipo di drive (vedi tabellina sotto)
• Il valore del bit 0 (zero) significa funzionalità attiva, il valore del bit 1 (uno) significa funzionalità disattivata

La seguente immagine rappresenta l’ordine dei bit.

Un piccolo esempio aiuta a comprendere. Volendo disattivare la funzionalità di autorun sulle sole unità di tipo CD o DVD dovrò attivare il bit 1 nella posizione 5 lasciando tutti gli altri a zero il che mi porta al valore binario 00100000 che in esadecimale è il valore 20 che andrà inserito nella chiave. Volendo disabilitare la funzionalità autorun per tutti i tipi di drive dovrò attivare il bit 1 in tutte e 8 le posizioni ottenendo il valore binario 11111111 che corrisponde al valore esadecimale FF (ovvero il decimale 255). Nella chiave DWORD inserirò quindi il valore risultante da questo semplicissimo calcolo per il quale potete farvi aiutare dalla semplice calcolatrice di Windows in modalità scientifica: inserite, in modalità binaria, gli zeri e gli uno secondo l’ordine di attivazione (o disattivazione) della funzionalità autorun per i vari tipi di drive e quindi passate alla modalità esadecimale per ottenere il valore risultante.

NoDriveAutorun

La seconda chiave che Windows interroga per determinare se autorun debba essere eseguito o meno è NoDriveAutorun. A differenza della precedente, questa chiave non considera il tipo di unità bensì la lettera dell’unità.

Questa chiave si trova (o va creata) a seconda delle esigenze alternativamente in uno di questi percorsi:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer

Il tipo della chiave è REG_DWORD (DWORD a 32 bit). Il valore esadecimale da inserire viene calcolato utilizzando una sequenza di 26 bit ognuno dei quali rappresenta una sequenza dell’alfabeto : il primo bit rappresenta la lettera A mentre il 26° rappresenta la lettera Z.

----------1---------2-----
01234567890123456789012345
ABCDEFGHIJKLMNOPQRSTUVWXYZ


Volendo, per esempio, disattivare le funzionalità di autorun per tutti i drive successivi alla lettera H dovremo creare un valore binario nel modo seguente lasciando il bit a zero per le unità su cui autorun potrà essere eseguito e mettendo il bit a 1 per le unità su cui autorun NON deve essere eseguito.


ABCDEFGHIJKLMNOPQRSTUVWXYZ
--------------------------
00000000111111111111111111  <- Valore Binario

La conversione in esadecimale di questo valore binario è 3FFF che è il valore che inseriremo nella chiave. Per disabilitare l’esecuzione di autorun su tutte le possibili lettere di unità inseriremo invece il valore 3FFFFFF che corrisponde al binario 11111111111111111111111111 (ovvero una sequenza di 26 volte 1). Va da se che se non desideriamo inibire autorun su nessuna lettera di unità possiamo alternativamente inserire il valore 0 (zero) oppure omettere direttamente la chiave.

Conclusioni

L’utilizzo delle chiavi di registro NoDriveTypeAutorun e NoDriveAutorun consente una regolazione fine dell’attivazione/disattivazione delle funzionalità di autorun in contrapposizione al metodo di inibizione tout-cour del file autorun.inf descritta più sopra. Per esempio è possibile lasciare attiva la funzionalità sulle lettere fisiche di unità e disattivarla sulle lettere “alte” ovvero quelle assegnate automaticamente in seguito all’inserimento di pen-drive o alla mappatura di unità di rete.