Sicurezza

Gestione del firewall di Windows Vista

Jesper M. Johansson

 

Panoramica:

• Tipi di regole e scenari
• Profili di firewall
• Regole di isolamento del dominio
• Il problema con il filtro in uscita

Poco tempo fa ho scritto un articolo nel mio blog sul firewall di Windows Vista. In quell'articolo ho semplicemente evidenziato alcune funzioni che ritenevo importanti ma senza scendere nel merito dello sviluppo.

In questo articolo, approfondisco alcune delle funzioni del firewall di Windows Vista® pensate in modo specifico per facilitare la gestione aziendale. Fornirò anche consigli su come usarle per semplificare il lavoro e garantire una maggiore protezione agli utenti.

L'ultimo rilascio del Service Pack 1 per Windows Vista potrebbe far pensare che le aziende si decidano a implementare Windows Vista (generalmente le aziende aspettano il rilascio del primo Service Pack prima di migrare a un nuovo sistema operativo). I professionisti IT che stanno prendendo in seria considerazione Windows Vista per l'ambiente aziendale dovrebbero esaminare più a fondo il firewall. Una volta capito cosa può fare il firewall di Windows Vista, è possibile rinegoziare il contratto con terze parti per la suite di protezione e rimuovere il firewall dal pacchetto.

Breve storia dei firewall di Windows fino a oggi

Il firewall nella versione originale di Windows® XP lasciava molto a desiderare. Sebbene rispondesse bene alla funzionalità di protezione tipica dei firewall basati su host allora in commercio, non aggiungeva niente di nuovo o innovativo.

La versione in dotazione con Windows XP SP2 venne completamente modificata proprio per facilitare la gestione aziendale. Il firewall di Windows XP SP2 ha molti pregi in quanto è leggero, gestibile a livello centrale, efficace e non invadente. Ma soprattutto protegge il sistema all'avvio.

Questa caratteristica è cruciale. Ho visto molti sistemi in passato infettarsi durante l'avvio anche con un firewall in funzione. Infatti, al culmine dell'epidemia di Blaster, la frequenza degli attacchi era di uno in quattro minuti. In altre parole, se avessimo lasciato un computer senza protezione in Internet, sarebbero bastati quattro minuti per infettarlo. E se stavamo usando un firewall che non proteggeva il sistema all'avvio, un sistema su 12 sarebbe stato infettato al riavvio. Sono state queste cifre a far sì che Microsoft garantisse la protezione del sistema all'avvio con il firewall di Windows XP SP2.

In Windows Vista il firewall è stato completamente trasformato. La modifica più ovvia, dal punto di vista della gestione, è stata la fusione delle interfacce di gestione del protocollo IPsec (Internet Protocol Security) con il firewall. Si tratta di una modifica molto logica. IPsec e il firewall sono progettati entrambi per bloccare elementi non consentiti. La differenza è che nel firewall i parametri che definiscono cosa è permesso non sono molto granulari mentre in IPsec il blocco o l'ammissione di grandi porzioni dello spazio degli indirizzi è scomodo.

Grazie alla compresenza delle due funzioni in una singola interfaccia di gestione, gli amministratori possono usare entrambe le tecnologie senza problemi e senza preoccuparsi troppo se applicare una regola IPsec o un filtro firewall. In sostanza, si ha una vista unica della superficie di attacco della rete del sistema e quindi si riduce il rischio di errori.

Il Service Pack 1 per Windows Vista aggiunge alcuni miglioramenti dell'affidabilità alle funzioni del firewall. Aggiunge anche nuovi algoritmi, in particolare gli algoritmi Suite B adatti a IPsec. Si tratta di una serie di algoritmi basati sulla crittografia, compresi AES (Advanced Encryption System, ECC (Elliptic Curve Cryptography) e SHA (Secure Hash Algorithm) 256 e 384.

Ma più importante di tutti è il fatto che il Service Pack 1 aggiunge il supporto per NAP (Network Access Protection). NAP è uno strumento di applicazione dei criteri che garantisce che i client gestiti e non compromessi vengano aggiornati con i criteri di protezione, gli aggiornamenti e le definizioni antimalware più recenti prima che possano connettersi alla rete. NAP non può impedire agli host pericolosi di connettersi alla rete ma assicura che tutti gli host gestiti siano completamente conformi purché non vengano attivamente compromessi.

Il firewall di Windows Vista, chiamato Windows Firewall with Advanced Security, è incluso anche in Windows Server® 2008. Inoltre tutte le funzioni possono essere gestite in remoto e configurate in una rete mediante criteri di gruppo.

Tipi di regole e scenari

La combinazione delle funzionalità del firewall e di IPsec nell'interfaccia di gestione comporta due tipi diversi di regole: regole direzionali e regole di connessione. Le regole direzionali sono regole standard del firewall che definiscono quale traffico consentire nella giusta direzione. Le regole di connessione definiscono i parametri di protezione per le connessioni tra i computer. Per fare un'analogia, le regole direzionali sono un poco simili alle regole dei firewall precedenti mentre le regole di connessione sono più simili alle regole IPsec usate insieme al firewall in Windows XP SP2.

Combinando il firewall e IPsec nella stessa interfaccia, si aprono diversi scenari molto interessanti. Ad esempio, uno dei concetti sulla protezione oggi più preziosi è l'isolamento di ogni sistema nella rete. Questo concetto in Microsoft è chiamato "isolamento di dominio e server".

L'isolamento di dominio e server usa la funzionalità sia di IPsec che del firewall. Pertanto la nuova interfaccia di gestione del firewall include funzionalità specifiche per le regole di isolamento. Ciò è valido se, ad esempio, si intende limitare la connessione in base agli attributi dei sistemi di origine o destinazione, come l'appartenenza a un dominio.

Come si vede nella Figura 1, la Creazione guidata nuova regola di protezione della connessione inizia chiedendo che tipo di regola si intende creare. Se si sceglie l'isolamento, la procedura guidata preconfigura determinate impostazioni che sono appropriate a una regola di isolamento.

Figura 1** Uso della Creazione guidata nuova regola di protezione della connessione per creare una regola di isolamento **(Fare clic sull'immagine per ingrandirla)

Nella Figura 1 è inoltre possibile notare che la regola di isolamento riguarda anche lo stato di integrità. Le regole usate per l'isolamento di dominio e server sono effettivamente le stesse regole usate per NAP.

Non è possibile applicare l'autenticazione ad alcuni tipi di traffico. Ad esempio, probabilmente non si desidera richiedere l'autenticazione per la risoluzione dei DNS. Per gli endpoint di quel tipo di traffico è necessaria una regola di esenzione dell'autenticazione. Un regola di esenzione dell'autenticazione esenta il traffico dai requisiti IPsec.

Il nome della regola di connessione tra server può essere fuorviante: sebbene usata più spesso con i server, può essere usata anche con i client. Una regola di connessione tra server semplicemente configura una connessione che richiede l'autenticazione. Si differenzia da una regola di isolamento in quanto quest'ultima non solo richiede l'autenticazione ma richiede anche il rispetto di determinati altri criteri come l'appartenenza a un dominio e lo stato di integrità.

Una regola di tunneling sostanzialmente definisce una VPN (Virtual Private Network) da sito a sito e il tunnel tra i gateway. Le regole di tunneling sono usate di rado con Windows Vista, in quanto è improbabile che si usi Windows Vista in una capacità gateway. È possibile creare regole del tutto personalizzate. Pertanto è possibile personalizzare ogni parametro della regola.

Ordine delle regole

A un primo sguardo l'ordine delle regole sembra un poco complicato. Il segreto per capirlo è proprio dimenticare il concetto di ordine, in quanto si tratta più di una selezione di corrispondenze (rispetto dei requisiti di una regola) che di un ordine vero e proprio. Consideriamo il traffico in entrata come esempio. Il traffico in entrata che non soddisfa nessuna regola viene bloccato per impostazione predefinita. Questa assunzione potrebbe essere considerata come un ordine secondo cui le regole di autorizzazione vengono per prime, ma non sarebbe corretto. Se un determinato pacchetto soddisfa sia una regola di autorizzazione che una regola di blocco, prevale la regola di blocco. Spieghiamo in parole semplici la corrispondenza:

1. Regole di blocco. Se un pacchetto o una connessione soddisfa una regola di blocco viene scartato.
2. Regole di autorizzazione. Se un pacchetto o una connessione soddisfa una regola di autorizzazione viene permesso.
3. Comportamento predefinito del profilo direzionale. Se non viene rispettata nessuna regola di blocco o di autorizzazione, il traffico verrà considerato secondo il comportamento specificato in quel profilo come predefinito per il traffico in quella direzione. Nella direzione in entrata in tutti i profili, il traffico viene bloccato in una configurazione predefinita. Nella direzione in uscita, per impostazione predefinita il traffico viene autorizzato nella configurazione predefinita.

Il processo di corrispondenza è moderato dalle regole IPsec di bypass autenticato. Usando quel tipo di regola, tutto il traffico autenticato che soddisfa gli altri parametri della regola viene autorizzato indipendentemente dal fatto che soddisfi o meno altre regole. Le regole di bypass autenticato sono regole direzionali in cui è selezionata l'opzione per ignorare le regole di blocco, come mostrato nella Figura 2. Queste regole vengono considerate per prime per permettere al traffico autenticato di raggiungere sempre il sistema. Ciò è essenziale per facilitare l'autorizzazione del traffico da host autenticati e il blocco del traffico proveniente da altre origini. Questa regola può essere considerata la 0 nell'ordine. Di conseguenza l'elenco dell'ordine completo delle regole somiglia al seguente:

Figura 2** Selezione dell'opzione per ignorare le regole di blocco per configurare una regola di bypass autenticato **(Fare clic sull'immagine per ingrandirla)

0. Regole di bypass autenticato

1. Regole di blocco

2. Regole di autorizzazione

3. Comportamento predefinito del profilo direzionale

L'eventuale presenza di più regole in ogni classe che rispondono al modello di traffico non è veramente importante. Non appena viene stabilita una corrispondenza tra una regola e il traffico, l'elaborazione della regola viene interrotta.

Pubblico, privato e di dominio

Risorse sulle connessioni in rete

• TechNet Security Center (in inglese)
• Using the Netsh Advfirewall Command-Line Tool (in inglese)
• Regole di protezione per Windows Firewall e per connessioni basate su IPsec in Windows Vista e in Windows Server 2008
• Security Watch Using SCW on Windows Server 2008 (in inglese)

Il nuovo firewall ha tre profili: pubblico, privato e di dominio. Il firewall di Windows XP SP2, invece, ha due profili di rete: standard e di dominio. Il profilo di dominio viene richiamato automaticamente quando il computer è in grado di trovare il controller del dominio. Diversamente, in Windows XP veniva usato il profilo standard. Questo profilo forniva una potente funzionalità grazie alla quale un amministratore della protezione poteva bloccare completamente il computer quando questo eseguiva il roaming e permettere comunque tutte le funzionalità di gestione in remoto necessarie quando era presente nella rete di un'organizzazione. Ma questo approccio presentava determinati problemi ad alcuni utenti: in particolare a coloro con reti personali domestiche. Poiché veniva sempre usato il profilo standard se il sistema non era in grado di raggiungere il controller del dominio, il sistema veniva bloccato dall'abitazione dell'utente.

Il nuovo profilo privato incluso in Windows Vista aiuta a risolvere questo problema. Ora quando si connette il sistema a una nuova rete, viene chiesto se la rete è pubblica (pubblico è semplicemente il nome nuovo del procedente profilo standard) o privata e il sistema viene configurato appropriatamente. Il sistema lo ricorda ogni volta che si collega a quella particolare rete, in base ai parametri presentati dai server dell'infrastruttura nella rete. Non è una soluzione perfetta ma è comunque utile perché consente di bloccare meglio più reti.

È stata migliorata anche la logica di rilevamento della presenza del sistema nel dominio. Di conseguenza la transizione è più veloce e affidabile e c'è un numero minore di sistemi che ritengono di dover usare profili pubblici o privati quando in realtà si trovano nel dominio.

È possibile associare le regole a un determinato tipo di rete per impedire al sistema di fornire spontaneamente troppe informazioni e di tentare la connessione a sistemi in rete non attendibili. Questa è un'area in cui l'integrazione del firewall e IPsec si dimostra particolarmente valida.

Usando queste nuove regole, è possibile porre alcune limitazioni in precedenza impossibili. Ad esempio, da molti anni gli hacker inducono gli utenti a fare connessioni di rete Windows SMB (Server Message Block) a host non attendibili e quindi li costringono a una sequenza di autorizzazioni challenge-response che può essere usata per individuare le password. Anche le versioni più vecchie di questo attacco sono state usate per il downgrade, in modo da cancellare l'autenticazione del testo o da riflettere la coppia challenge-response dell'utente nel computer di origine. La tecnica più vecchia è stata smantellata anni fa. Quella più recente è stata mitigata da Windows XP SP2, ma non dobbiamo dimenticare che non è mai prudente fornire spontaneamente coppie challenge-response.

Per impedire questo rischio è possibile usare una nuova funzione nel firewall di Vista: il filtro in uscita. Ad esempio, un amministratore potrebbe decidere di bloccare tutte le connessioni SMB in uscita (quelle che terminano alle porte TCP 135, 139, 445 e UDP 137, 138, 445) nel profilo pubblico. In questo modo diventa più difficile usare un sistema in un attacco mirato a ottenere coppie challenge-response o si impedisce al sistema di accedere a condivisioni file di Windows non attendibili in Internet.

Anche questa soluzione non è infallibile. Ad esempio, se il sistema è già compromesso, questa regola non gli impedisce di comunicare, dato che potrebbe essere semplicemente disattivata dall'kacker. Tuttavia può rivelarsi molto utile come misura di protezione di sistemi sani ma potenzialmente esposti.

È importante sottolineare che in questo contesto, proprio come in Windows XP SP2, può essere attivo un solo profilo alla volta in Windows Vista e Windows Server 2008. Se nel sistema convivono due interfacce di rete e una si trova nel dominio mentre l'altra in una rete pubblica, a entrambe verrà applicato il profilo di firewall pubblico. Verrà usato sempre il profilo più restrittivo. Come si può immaginare, il profilo pubblico è più restrittivo di quello privato e quest'ultimo è più restrittivo di quello dominio. Pertanto tenere presente che la regola di blocco SMB in uscita può interrompere molto del traffico nelle connessioni VPN.

Per consentire il traffico in una connessione VPN quando il computer è in una rete pubblica o privata, vengono create le regole direzionali che valgono solo per le interfacce VPN. Affinché queste regole funzionino, le interfacce VPN devono essere riconosciute in quanto tali da Windows. Se non si usa il server VPN dei servizi Routing e Accesso remoto di Microsoft®, provare questa funzionalità prima di distribuirla su larga scala. È un problema che riguarda principalmente il traffico in entrata nel client e le regole personalizzate per il traffico in uscita eventualmente create.

Creazione di regole del firewall

La creazione di una regola è molto più facile nel nuovo firewall. La Creazione guidata nuova regola, mostrata nella Figura 3, consente di definire tutti i tipi generali di regole. Include anche regole predefinite per determinati servizi.

Figura 3** Regole predefinite nella Creazione guidata nuova regola **(Fare clic sull'immagine per ingrandirla)

Le regole predefinite sono particolarmente importanti. L'isolamento del server consiste essenzialmente nel limitare determinati servizi, rendendoli disponibili solo per quei sistemi che necessitano di usarli. Per facilitare questa operazione nel caso dei prodotti server, è possibile usare la Configurazione guidata impostazioni di sicurezza di Windows, sebbene non senza qualche difficoltà (ho parlato di questa procedura nell'edizione di marzo 2008 di TechNet Magazine).

Finora le versioni client di Windows non hanno avuto una funzionalità simile. Quando si usa il tipo di regola predefinita, gran parte del lavoro più impegnativo, cioè la determinazione di quali endpoint vengono usati da un servizio, viene svolta automaticamente. Il firewall non solo è in grado di riconoscere quale programma il servizio iSCSI rappresenta ma contiene anche regole predefinite che descrivono una determinata funzionalità. Ciò consente di concentrarsi su quali computer devono essere considerati in una regola. Quest'attività è comunque difficile e lunga ma almeno è esclusiva del proprio ambiente.

Esiste anche una regola personalizzata (nascosta dal menu a discesa nella Figura 3) che offre tutta la flessibilità che ci si aspetta da un firewall di autenticazione. Ad esempio, se si desidera definire una regola che consente solo il traffico crittografato IPsec, è possibile selezionare l'opzione che autorizza solo le connessioni protette, nella pagina Azione della procedura guidata, mostrata nella Figura 2.

Quando si seleziona questa opzione è possibile anche attivare la crittografia. Se non si seleziona questa opzione, il traffico userà ESP-NULL (Encapsulated Security Payload con una chiave NULL). Se si intende usare IPsec per l'autenticazione, si consiglia di adottare questo metodo in quanto consente a molti strumenti di gestione della rete di continuare a operare, visto che il traffico sta attraversando la rete in chiaro e, se si vuole usare la crittografia, basta selezionare la casella.

In molte situazioni, crittografare il traffico della rete non è efficace come rifiutare tutto il traffico proveniente da host pericolosi. Con la crittografia del traffico della rete si blocca un utente malintenzionato che ha ottenuto l'accesso alla rete autonomamente guardando il contenuto del pacchetto. L'obbligatorietà dell'autenticazione può impedire innanzitutto l'invio del pacchetto e quindi l'attacco. Ci sono molte situazioni in cui la crittografia a livello di rete è importante ma ci sono anche molte altre situazioni in cui solo l'autenticazione è efficace.

Creazione di regole di isolamento del dominio

In molti ambienti, può essere necessario limitare il numero di computer in grado di inviare traffico a una workstation. Come minimo, tutte le workstation dovrebbero essere configurate con regole di isolamento del dominio. Questa operazione era complicata in Windows XP ma è facile in Windows Vista.

Innanzitutto aprire lo strumento di gestione che si preferisce, quindi selezionare il nodo Regole di protezione delle connessioni. Quindi fare clic con il pulsante destro del mouse sul nodo e selezionare Nuova regola; verrà visualizzata la finestra di dialogo mostrata nella Figura 1. Selezionare la regola Isolamento e fare clic su Avanti. A questo punto occorre selezionare se si desidera l'applicazione della regola. In molte workstation può essere necessario esigere l'autenticazione per il traffico in entrata. In questo modo si impedisce a eventuali computer non appartenenti al dominio di inviare traffico alla workstation. Tuttavia, per richiedere i servizi dall'infrastruttura, il sistema deve autorizzare il passaggio in chiaro di un certo traffico in uscita. La scelta migliore, pertanto, è esigere l'autenticazione per le connessioni in entrata e valutare l'autenticazione delle richieste di connessioni in uscita a seconda dei casi.

Quindi scegliere il metodo di autenticazione. La selezione predefinita non ha un nome particolarmente utile. È possibile configurare il metodo di autenticazione predefinito per ogni computer nelle proprietà IPsec (a cui si accede facendo clic con il pulsante destro del mouse sul nodo Windows Firewall con protezione avanzata e selezionando Proprietà). Il metodo di autenticazione predefinito è sempre Kerberos dato che è quello più semplice e sicuro. Tuttavia, per chiarezza, consiglio di selezionarlo effettivamente quando si creano le regole. Di solito si desidera autenticare solo il computer e non anche l'utente. Se è necessario autenticare entrambi, si potrebbe non essere in grado di accettare determinati tipi di traffico, come il traffico SNMP trasmesso in modo anonimo.

Dopo aver selezionato il metodo di autenticazione, è sufficiente selezionare i profili in cui dovrà essere disponibile questa regola. Poiché si tratta di una regola che si applica ai computer appartenenti al dominio, con l'eventualità della presentazione di un ticket Kerberos, non ha senso aprire questo varco nei profili privati o pubblici. Per finire salvare la regola.

Le regole di isolamento di base ora non sono più complicate. Tuttavia, per sfruttare la potenza di IPsec per l'isolamento, è necessario implementare l'isolamento del server anche nelle workstation. In questo modo è possibile impedire alle workstation l'ascolto di altri client e fare in modo che rispondano solo alle stazioni di gestione appropriate. È facile immaginare di quanto si ridurrebbe l'impatto delle varie interruzioni dovute a malware se i sistemi client si rifiutassero di ascoltare altri client.

Scrittura dello script del firewall

Il nuovo firewall è dotato di una solida API che consente di codificare sia la distribuzione che la valutazione. L'ideale sarebbe usare i criteri di gruppo per la distribuzione ma, poiché i criteri di gruppo non sono sempre disponibili, è importante disporre di un'impostazione API appropriata per configurare il firewall. Le API sono raggruppate nell'insieme INetFWPolicy2. Il Software Development Kit e MSDN® Library contengono dettagli più completi su come usarle ma è utile comunque fare alcuni esempi.

Un esempio comune riguarda la necessità di determinare se un gruppo di regole è attivato. Supponiamo, ad esempio, che un'applicazione o un amministratore debba determinare se la condivisione file e stampanti è permessa da un sistema. A questo scopo si usa INetFWPolicy2::IsRuleGroupCurrentlyEnabled. La Figura 4 presenta uno script VBScript che esemplifica questa funzione.

Figure 4 Uso di INetFWPolicy2::IsRuleGroupCurrentlyEnabled

' Create the FwPolicy2 object.
Dim fwPolicy2
Set fwPolicy2 = CreateObject("HNetCfg.FwPolicy2")

' Get the Rules object
Dim RulesObject
Set RulesObject = fwPolicy2.Rules

'Create a profile object
Dim CurrentProfile
CurrentProfile = fwPolicy2.CurrentProfileTypes

'Check whether File and Printer Sharing is on, and turn it on if not
if fwPolicy2.IsRuleGroupEnabled(CurrentProfile, "File and Printer Sharing") <> TRUE then
    fwPolicy2.EnableRuleGroup CurrentProfile, "File and Printer Sharing", TRUE
end if

Ora, se la condivisione file e stampanti è disattivata ed è necessario attivarla, prima di tutto è necessario assicurarsi che sia fattibile e che non prevalgano i criteri di gruppo. A questo scopo si usa l'API INetFWPolicy2::LocalPolicyModifyState. Di seguito è riportato un esempio che può essere completato con il codice vero e proprio:

Const NET_FW_MODIFY_STATE_OK = 0
Const NET_FW_MODIFY_STATE_GP_OVERRIDE = 1
Const NET_FW_MODIFY_STATE_NO_EXCEPTIONS = 2

Dim PolicyModifyState
PolicyModifyState = fwPolicy2.LocalPolicyModifyState
Select Case PolicyModifyState
  Case NET_FW_MODIFY_STATE_OK
  Case NET_FW_MODIFY_STATE_GP_OVERRIDE
  Case NET_FW_MODIFY_STATE_NO_EXCEPTIONS
End Select

Riga di comando e tipi di interfaccia

Nessun firewall sarebbe completo senza un'appropriata riga di comando per la gestione. In netsh è presente un contesto secondario chiamato advfirewall. Il contesto advfirewall fornisce l'accesso dalla riga di comando per compiere tutte le operazioni che è possibile eseguire nella GUI. Ad esempio, se si desidera implementare il blocco in uscita sulla porta 445, è possibile eseguire il comando seguente da un prompt dei comandi con privilegi elevati:

netsh advfirewall firewall add rule name="Block CIFS Out in the Public profile"
dir=out action=block enable=yes profile=public
localIP=any remoteIP=any remoteport=445 protocol=TCP interfacetype=any

Quindi è necessario eseguire lo stesso comando, sostituendo TCP con UDP per completare il blocco. A questo punto, è stata completata l'implementazione della regola.

Una funzione speciale del firewall è la capacità di configurare le regole in base al tipo di interfaccia di rete. Il richiamo di queste regole può influire sulle connessioni VPN. È possibile usare questo tipo di regola per escludere il traffico in quell'interfaccia purché Windows riconosca l'interfaccia come interfaccia VPN:

netsh advfirewall firewall add rule name="Allow CIFS on VPN interfaces"
dir=out action=allow enable=yes profile=public localIP=any
remoteIP=any remoteport=445 protocol=TCP interfacetype=RAS

Questa operazione può essere eseguita anche nella GUI ma solo dopo la creazione della regola. Quindi è necessario fare clic con il pulsante destro del mouse sulla regola, selezionare Proprietà e fare clic sulla scheda Avanzate. In questa scheda c'è una sezione con i tipi di interfaccia che è possibile selezionare.

Filtro in uscita

La mancanza di un filtro in uscita nel firewall di Windows XP SP2 è stata vista come la prova principale che il firewall incorporato non era adatto alla protezione. Ci saranno migliaia di articoli in cui si sostiene che il firewall di Windows XP SP2 non è sicuro a causa dell'assenza del filtro in uscita, nonostante il fatto che in effetti nessun firewall in Windows XP potrebbe fornire in modo sicuro un filtro in uscita.

La funzionalità essenziale alla trasformazione di un filtro in uscita da mero aspetto legato alla velocità, o strumento di applicazione dei criteri come ho fatto io in precedenza, a un'utile funzione di protezione, semplicemente non esiste in Windows XP. Esiste invece in Windows Vista. È una logica conseguenza che il nuovo firewall usi questa funzionalità. Per impostazione predefinita, viene bloccata la maggior parte del traffico in entrata e viene consentita la maggior parte del traffico in uscita.

Per impostazione predefinita, il filtro in uscita nel nuovo firewall di Windows Vista blocca solo il traffico inutile proveniente dai servizi. Questo è il massimo che si può fare effettivamente per la protezione, considerando l'host che fornisce i filtri in uscita e l'inutilità di ciò in Windows XP.

I servizi in Windows Vista possono essere eseguiti con un token molto limitato. In sostanza, ogni servizio ha un proprio esclusivo identificativo di sicurezza (SID). Questo SID può essere usato per limitare l'accesso alle risorse, ad esempio le porte di rete. Si tratta della stessa funzionalità che abbiamo visto prima quando abbiamo parlato della limitazione del traffico agli utenti. Ciò significa che, anche se due servizi possono essere eseguiti come NetworkService, non possono gestirsi reciprocamente i processi e il firewall può essere configurato solo su uno di essi per comunicare. Se il servizio che viene bloccato è compromesso, non può assumere il controllo del servizio consentito e usarne la porta per comunicare in quanto l'accesso alla porta si basa sul SID del servizio.

Questa è un'altra delle funzionalità notevoli aggiunte a Windows Vista ed è usata dal nuovo firewall per garantire una reale protezione tramite il filtro del firewall in uscita.

Infatti, per impostazione predefinita, nel nuovo firewall è attivato il filtro dei SID dei servizi. In ogni caso non c'è nessuna GUI per fare questa configurazione. Le regole sono predefinite nella chiave del registro di sistema HKLM\System\CurrentControlSet\services\sharedaccess\parameters\firewallpolicy\RestrictedServices. Prestare comunque molta attenzione a modificare manualmente questa chiave perché non è un'operazione comprovata.

Quanta protezione può dare il filtro in uscita?

Un argomento piuttosto controverso nella comunità che si occupa di sicurezza è il livello di protezione effettivamente offerto dal filtro in uscita. Ho accennato a due scenari che forniscono la protezione per mezzo del filtro in uscita ma entrambi si fondano sulla nuova funzionalità in Windows Vista che non era disponibile in precedenza. Nonostante ciò, si è diffusa la sensazione che il filtro in uscita sia generalmente valido e dovrebbe costituire un fattore chiave nella decisione di acquistare il firewall.

Paradossalmente, in molte organizzazioni le capacità del filtro in uscita hanno determinato la decisione di acquistare il firewall ma poi il filtro in uscita non è stato usato una volta implementato il firewall. Questa impressione è fuorviante e comporta uno spreco di denaro e fatica da parte del gruppo addetto alla protezione delle informazioni. Sembra motivata più dal desiderio di sentirsi a posto con la coscienza facendo qualcosa per la protezione che non da un'analisi effettiva di una minaccia reale. Troppo spesso questo desiderio fa prendere decisioni che invece andrebbero prese basandosi sui fatti.

C'è un fatto molto semplice che riguarda il filtro in uscita che i suoi fautori non sono riusciti a prendere in considerazione. L'argomento addotto solitamente dai fornitori di firewall basati su host è che, se un sistema è compromesso, sia da un worm che da un utente malintenzionato interattivamente, il filtro in uscita impedirà al worm di infettare gli altri sistemi o all'hacker di comunicare. Non è vero.

È vero, fermo restando quanto detto finora, che un filtro in uscita avrebbe bloccato alcuni storici programmi malware. Tuttavia, se Windows XP avesse avuto il filtro in uscita, è molto più che probabile che i worm che abbiamo conosciuto sarebbero stati scritti in modo da disattivare il filtro o comunque da eluderlo.

In Windows XP (e nelle versioni precedenti di Windows) avrebbe potuto farlo qualsiasi worm in esecuzione come servizio (e tutti i worm comunemente noti che sono saltati fuori funzionavano come un servizio). L'unico motivo per cui non lo hanno fatto è che praticamente non esisteva nessun ambiente con il filtro in uscita e quindi non c'era necessità di disattivarlo. In un attacco interattivo, l'hacker può eludere i filtri in uscita a suo piacimento. È facile se l'hacker è in grado di eseguire un codice arbitrario. Ma se necessario, l'hacker può anche indurre l'utente a eludere i filtri.

I filtri in uscita dei firewall basati su host possono essere elusi in vari modi, a seconda dello scenario dell'attacco. Il modo più semplice consiste nel "chiedere" a un utente con i massimi privilegi di farlo per lui. In troppi ambienti gli utenti operano come amministratori. Questi utenti hanno l'autorizzazione a eludere i criteri di sicurezza a proprio piacimento. Tutto quello che deve fare l'hacker è presentare all'utente una scelta tra qualcosa che sia un beneficio immateriale e non immediato per la sicurezza e qualcosa a cui l'utente tiene di più: il classico paradosso dei "dancing pigs".

In molti casi, l'utente è talmente sommerso da questi tipi di finestre di dialogo che fa subito clic senza comprendere veramente ciò che sta succedendo. Questo è il problema principale con i filtri in uscita. Quando si tratta di scegliere tra la sicurezza e gratificazioni sufficientemente allettanti, ad esempio i cosiddetti "dancing pigs", vincono sempre questi ultimi dato che la maggior parte delle finestre di dialogo che chiedono agli utenti di prendere decisioni in merito alla sicurezza è priva delle informazioni che consentirebbero agli utenti di prendere effettivamente quella decisione.

Presentare finestre di dialogo, che chiedono di prendere una decisione sulla sicurezza, con un numero sufficiente di informazioni su cui basare quella decisione è molto più difficile di quanto sembri: richiederebbe che il prodotto addetto alla protezione, ad esempio il firewall, non solo riconoscesse porte, protocolli e l'applicazione che sta facendo la richiesta, ma anche cosa stia tentando di fare la richiesta e il relativo significato per l'utente. È molto difficile reperire queste informazioni a livello di programma. Ad esempio, il fatto che Microsoft Word tenti di stabilire una connessione in uscita non è tanto interessante quanto il fatto di cosa Word stia tentando esattamente di fare con quella connessione.

Dobbiamo ridurre il numero di finestre di dialogo senza senso e non aumentarlo; in questa direzione i firewall con i filtri in uscita non aiutano. Per avere un'idea del livello attuale della capacità di fornire informazioni preziose all'utente, ho esaminato la documentazione delle vendite di uno dei principali fornitori di firewall basato su host. Vengono pubblicizzate le capacità di filtro in uscita e di consigliare del firewall. La capacità di consigliare consiste nel rilevare quello che l'utente sta tentando di fare e dare il consiglio appropriato. Più o meno questa è la teoria. Il testo nella brochure era accompagnato da una schermata con un contenuto simile a questo: "Non sono disponibili consigli per questo programma. Scegliere o fare clic su Altre informazioni per assistenza". Sembra che neanche nei materiali marketing i fornitori siano in grado di produrre finestre di dialogo informative.

Poiché gli utenti non hanno informazioni sufficienti per prendere le decisioni giuste per la sicurezza, tocca all'amministratore configurare interamente il filtro in uscita in quanto l'utente finale non è in grado di farlo. In questo modo il carico di lavoro dell'amministratore aumenta a dismisura.

Anche se l'utente fa clic sull'opzione per ricordarlo in seguito alla richiesta del firewall, il malware di solito può aggirare il firewall. Finché l'utente per cui è in esecuzione il codice dannoso può aprire connessioni in uscita su una porta, è sufficiente che il codice dannoso usi quella porta. Pertanto qualsiasi processo può essere trasportato su un processo esistente. Ciò è permesso nei sistemi operativi di basso livello. A partire da Windows Vista, i processi possono essere adeguatamente sottoposti a limitazioni, motivo per cui i servizi, che sono gli unici a essere soggetti a limitazioni per impostazione predefinita, vengono bloccati usando i filtri in uscita per impostazione predefinita.

Purtroppo molte persone ritengono che il filtro in uscita dei firewall basati su host impedisca a una risorsa capitale compromessa di attaccare le altre risorse. Questo non è possibile. Adottare misure protettive per una risorsa capitale compromessa e aspettarsi che questa non comprometta tutte le altre risorse è un metodo che semplicemente non funziona. La protezione appartiene alla risorsa che si sta tentando di proteggere e non a ciò contro cui ci si sta proteggendo! Chiedere ai ladri di non rubare dopo che già sono entrati a casa nostra è improbabile che sia efficace quanto impedire loro di irrompere in casa.

Jesper M. Johansson, Software Architect, si occupa dei problemi di protezione software e collabora con TechNet Magazine in qualità di redattore. Ha conseguito un dottorato in gestione dei sistemi informatici, vanta un'esperienza più che ventennale sul tema della sicurezza ed è Microsoft MVP per la protezione delle aziende. Il suo ultimo libro è Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.