Da Alessandro Perilli - Security
Oggi più che mai la battaglia per la sicurezza si gioca sul campo applicativo.
Dieci anni fa o meno attaccare un sistema Windows 95 o 98 non era così facile. Pochi servizi di rete da bersagliare, poche applicazioni Internet-dipendenti da torchiare. Invece di sfruttare le vulnerabilità di questi limitati punti d’innesto, gli attaccanti consideravano più proficuo crearne di nuovi. E così cavalli di Troia come SubSeven hanno cominciato a diffondersi a macchina d’olio sui sistemi Windows, arrivanddo via email, chat, controlli ActiveX, ovunque.
Questi server piccoli e non autorizzati garantivano nuove vie d’accesso per raggiungere le vittime in ogni momento.
Da allora molte cose sono cambiate: mentre i sistemi operativi Microsoft acquisivano un’enorme quantità di servizi di rete, la cultura del firewall raggiungeva le masse, nuovi e più efficienti strumenti di sicurezza cominciavano ad apparire, praticamente tutte le applicazioni diventavano network-oriented, la percezione della sicurezza informatica delle persone aumentava lievemente.
In queste nuove condizioni, con cavalla di Troia non più efficaci, gli attaccanti hanno dovuto trovare nuovi metodi per raggiungere i bersagli designati. In realtà non c’è stata veramente una ricerca in tal senso dal momento in cui piattaforme come Windows 2000 o XP hanno cominciato ad offrire un numero notevole di servizi pronti ad essere bombardati da dati malformati, garantendo accessi non autorizzati.
Per non parlare delle migliaia di applicazioni, dai news aggregator ai clienti P2P fino ad arrivare ai giochi online MMORPG, contro le quali è possibile inviare pacchetti opportunamente forgiati per ottenere il controllo del computer remoto.
I giorni dei cavalli di Troia non sono ancora finiti ma la maggior parte degli attacchi odierni è basata sullo sfruttamento della vulnerabilità applicative.
Perchè? Gli sviluppatori hanno cominciato a produrre applicazioni più insicure? No, piuttosto il contrario. Semplicemente gli attaccanti hanno cominciato a focalizzarsi sulle applicazioni, mettendo a nudo quello che c’è sempre stato: gli errori di sviluppo.
Gli errori di sviluppo sono sempre esistiti e esisteranno sempre. Sono il prodotto di comportamento tipico di una mente umana: dare delle cose per scontato. Gli sviluppatori a volte dimenticano di controllare gli input, sicuri che gli utenti forniranno le informazioni in ingresso nella forma corretta, e i dati malformati bloccano le loro applicazioni o le fanno agire in maniera incontrollata, usandole come vettore per l’accesso al sistema operativo sottostante con massimi privilegi.
I cosiddetti validation input errors sono piuttosto probabili nelle moderne applicazioni di rete. Più complessa è l’applicazione più facile sarà dimenticare qualcosa.
Anche se oggi le aziende hanno cominciato a produrre le applicazioni su nuovi modelli di sviluppo sicuro dovremo gestire i validation input errors ancora per molti anni e forse per sempre.
In questa pagina
.gif)
Come può aiutarci l’hardening
L’hardening può essere una pratica pericolosa
Esplorando il Security Configuration Wizard
Best practice
Conclusioni
Come può aiutarci l’hardening
Il modo migliore che abbiamo oggi per ridurre l’intriseca insicurezza delle applicazioni è di applicare una procedura di hardening ai nostri sistemi, sperando che nuove tecnologie come l’endpoint security offrano presto una soluzione più efficace per difenderci.
Porre in hardening un sistema significa limitare il numero di servizi in ascolto, o il numero di applicazioni installate, o il modo in cui le applicazioni gestiscono dati in ingresso. In altri termini hardening significa ridurre la superficie d’attacco al sistema. Di solito l’hardening è qualcosa che si applica ai sistemi operativi ma dovrebbe essere considerato un approccio sistematico da usare con qualunque server di back-end o applicazione desktop.
Oggi abbiamo linee guida per l’hardening scritte da riconosciuti esperti di sicurezza e organizzazioni di fama mondiale (come il NIST), e abbiamo strumenti di hardening semi-automatico, che possono modificare vari aspetti del sistema operativo.
Microsoft ha incluso il suo strumento ufficiale di hardening, chiamato Security Configuration Wizard (SCW), nel Service Pack 1 di Windows Server 2003.
Altri sistemi operativi hanno similari strumenti di hardening semi-automatico come JASS per Sun Solaris o Bastille per le distribuzioni Red Hat Linux.
L’hardening può essere una pratica pericolosa
Le procedure di hardening esistono da molti anni ma sono difficili da applicare.
Per fermare un servizio o modificare una chiave del Registro gli amministratori dovrebbero avere una profonda conoscenza del sistema. E anche in questo caso delle modifiche troppo stringenti potrebbero compromettere il funzionamento di un’applicazione già installata, che magari accede raramente alle parti disabilitate del sistema.
Inoltre una configurazione di hardening può funzionare per un sistema che svolge un compito specifico e non altrettanto bene per un altro compito. Ogni piattaforma ha bisogno dell’opportuno aggiustamento nella procedura, cosa estremamente lunga e soggetta ad errori. Basti considerare che perfino mettendo in hardening due sistemi identici si può dimenticare qualcosa. E se il ruolo della piattaforma cambia o cambiano le applicazioni installate al suo interno, sarà necessario rivedere la configurazione di hardening e modificarla opportunamente. E’ un processo di sicurezza molto complesso da portare avanti anche in una piccola server farm.
Infine va tenuto in considerazione che mettere in hardening un sistema può invalidare il supporto del produttore per un certo prodotto installato perchè è stato modificato in maniera essenziale l’ambiente per il quale si fornisce supporto garantito.
Esplorando il Security Configuration Wizard
Distribuito per la prima volta con il Service Pack 1 di Windows Server 2003, l’SCW è uno strumento potente e flessibile per automatizzare parzialmente l’hardening del sistema operativo Microsoft, risolvendo gran parte dei problemi descritti sopra.
L’SCW ci permetterà di approcciare l’hardening in due maniere: per-ruolo e custom.
Scegliere un hardening per ruolo significa che sarà sufficiente specificare quale tipo di server di back-end e di applicazione il sistema operative si troverà ad eseguire.
Per esempio è possibile dichiarare il ruolo SQL Server 2000 role e il ruolo ISA Server 2004, ma anche dichiarare che il sistema si comporterà come un client DNS.
.jpg)
A seconda del ruolo che è stato selezionato la procedura assistita di hardening proporrà una configurazione sicura dove i servizi e chiavi di Registro non necessari sono stati disabilitati.
Questo è in assoluto il miglior modo di cominciare per una persona inesperta nell’hardening.
Scegliere un hardening custom significa invece che sarà necessario scegliere ogni singolo dettaglio da modificare nel sistema.
La configurazione risultante sarà un ruolo ibrido perfettamente adattata alle peculariatà del sistema. Questo è l’approccio avanzato e dovrebbe essere adottato con molta cautela.
I servizi e le chiavi di Registro non sono gli unici dettagli di configurazione che l’SCW può modificare. Sarà richiesto di prendere una decisione sulle Local Policy, sui filtri IPSec, sui filtri in ingresso del Windows Firewall e sulle web extensions di IIS (se si sta mettendo in hardening un web server).
Il volume complessivo di impostazioni che si possono controllare è impressionante e richiederà un notevole quantitativo di tempo e test prima di raggiungere configurazioni ottimali.
Ogni impostazione viene elencata con una breve spiegazione per aiutare gli utenti a scegliere. In questo modo l’SCW diventa facilmente anche uno strumento per approfondire la conoscenza del sistema.
A differenza di prodotti simili, l’SCW offre una funzione di ripristino vitale, capace di riportare l’ambiente al suo stato precedente, prima dell’hardening.
Questa caratteristica è praticamente indispensabile dal momento in cui fare troubleshooting di un servizio o di una applicazione malfunzionante può essere piuttosto complesso. E se tutte le modifiche di hardening sono state applicate nello stesso momento, come fa l’SCW, può diventare impossibile.
Quando qualcosa che è stato disabilitato o rimosso previene il funzionamento corretto di un servizio dipendente, il problema non viene sempre riportato nell’Event Log di Windows, o in certi casi viene riportato con un messaggio incomprensibile.
Ripristinare un ambiente funzionante può salvare una quantità notevole di tempo e evitare la mancata disponibilità dei servizi.
In ogni caso la funzionalità di ripristino offre sempre una comparazione tra lo stato attuale e lo stato originario pre-hardening: in questo modo è eventualmente possibile invocare la procedura senza portarla a termine, solo per cercare di rendersi conto dove potrebbe essere il problema.
Una delle caratteristiche più interessanti dell’SCW è il suo file di configurazione.
Alla conclusione della procedura il template per l’hardening viene salvato come un file XML. Questo permette di distribuirlo su ogni macchina nella server farm senza ripetere la lunga procedura di creazione, evitando errori di digitazioni e risparmiando molto tempo.
L’intera operazione viene effettuata semplicemente digitando un singolo commando:
scwcmd.exe configure /p:my_policy.xml
E se si lavora in un ambiente Active Directory c’è un ulteriore vantaggio: si può assegnare il file di configurazione XML ad una Group Policy e applicare l’hardening a tutti i server di una Organizational Unit (OU) in un solo momento.
Come già detto l’SCW permette di modificare una grande quantità di impostazioni ma in certi casi potrebbe esserci la necessità di intervenire su un aspetto del sistema non incluso nella procedura standard, o addirittura si potrebbe voler mettere in hardening una applicazione proprietaria.
In questo caso si può creare un set di configurazione custom, controllando totalmente la piattaforma.
L’SCW è distribuito gratuitamente ma non funzionerà su sistemi diversi da Windows Server 2003 SP1.
Una decisione che penalizza gli utenti e sulla quale si spera che Microsoft ritornerà nella prossima versione.
Best practice
Anche se l’SCW semplifica notevolmente la procedura di hardening molte cose possono ancora andare male.
Su un singolo computer una configurazione di hardening potrebbe funzionare fintanto che non venga invocata qualche funzione di una specifica applicazione (per esempio alcune misurazioni effettuate dal Performance Monitor).
Quindi prima di agire è necessario aver studiato approfonditamente e aver controllato le dipendenze dei servizi e le necessità delle applicazioni. In particolare quelle proprietarie.
Negli ambienti Active Directory una configurazione di hardening applicata a server apparentemente simili potrebbe produrre risultati differenti e eventualmente causare il down-time dei servizi (per esempio nei casi di server simili non installati in modalità unattended).
Quindi se si intende distribuire un template SCW ad una intera OU, sarà meglio definire un sottoinsieme di modifiche di hardening comune a tutti i membri della OU. E poi applicare le modifiche specifiche in maniera indipendente per ogni server.
Il consiglio principale e sempre valido è: fare moltissimi test in un ambiente di laboratorio con cloni delle machine di produzione prima di applicare i template SCW. Inoltre bisogna ricordare di documentare dettagliatamente ogni scelta e aggiornare la documentazione in caso di variazioni.
L’ultimo accorgimento fondamentale è pianificare una revisione periodica dei template di hardening per adattarli alle nuove conoscenze e alle nuove necessità.
Conclusioni
L’SCW è un grande passo avanti nella sicurezza dei sistemi Windows. Svolge gran parte del lavoro, offre una documentazione di base su cosa si sta modificando e risolve diversi problemi legati all’hardening su vasta scala.
Ma in ogni caso richiede una buona conoscenza del comportamento di Windows e una significativa quantità di test prima della messa in produzione. Va considerato ancora come un tool per esperti.