Per la sicurezza delle piattaforme è necessario valutare attentamente l’installazione per bloccare eventuali pericolose aperture.
Uno degli errori di valutazione più comuni nell’amministrazione di un’infrastruttura riguarda la fase post installazione di un sistema operativo, di un network device o di un’applicazione. Quando si procede ad un lavoro di questo genere, il programma di setup non è orientato alla messa in sicurezza della piattaforma, bensì a una configurazione quanto più aderente ai principi basilari dell’amministrazione.
È questo uno dei motivi per cui si parla di esigenze di hardening, cioè di rafforzamento delle piattaforme installate dal punto di vista della security. Un altro motivo di necessità di questa operazione riguarda il fatto che i firewall non proteggono gli obiettivi dagli attacchi mirati alle debolezze architetturali di questi ultimi.
Prendiamo come esempio un Web server. La protezione perimetrale su questo può mitigare alcune violazioni legate agli accessi indesiderati, ma esistono altri tipi di attacco in grado di agire direttamente sull’obiettivo a seguito di un bug di piattaforma o un errore di configurazione.
Un primo approccio all’hardening
Per alcune correnti della letteratura l’hardening è un ulteriore livello di sicurezza, quasi l’ultimo ad essere applicato, dal punto di vista cronologico. La procedura non riguarda esclusivamente la parte tecnica ma anche quella di metodica di utilizzo , di politiche di sicurezza e via dicendo.
Fondamentalmente l’hardening può essere delle seguenti tipologie:
– One Time Hardening. Viene effettuato solo una volta e dopo il primo setup e la relativa immissione del modulo nel ciclo biologico aziendale (per esempio, l’installazione di un mail server).
– Multiple time hardening. Viene effettuato più volte durante la vita della piattaforma, e la sua ripetizione nel tempo dipende da due fattori fondamentali che sono il rilascio di service pack o major upgrade o l’aggiunta di moduli complementari a quello installato di base o modifiche architetturali.
La prima attività che viene effettuata riguarda l’identificazione della piattaforma, distinta per tipologia di appartenenza. Di solito si identificano per prime le apparecchiature di rete (Network Devices). Si tratta di hardware (e di software che lo gestisce) effettivamente in prima linea, cioè esposto e visibile in percentuale molto elevata. Impossessarsi di un dispositivo di rete, per esempio expoitando una debolezza architetturale o una configurazione di default, è un’attività abbastanza frequente e molto dannosa per il proprietario del target.
Altrettanto a rischio è il software di sistema. Un sistema operativo funziona ( ed interagisce con il resto della struttura) mediante una serie sterminata di servizi e utility. Questo significa che ognuna di queste componenti è in grado di fornire uno spunto di attacco ad un soggetto interessato. Molto spesso, infatti, anche se non lo si sa, alcune delle sopra citate utility di sistema hanno dei privilegi molto alti e, naturalmente, se viene trovato un bug, la piattaforma sottostante è compromessa.
Esistono, poi, due sottosistemi di estremo interesse, appartenenti a segmenti ben specifici. Il primo è quello del file system. Quest’ultimo è responsabile della gestione delle componenti cruciali di un sistema, come configurazioni, permessi, password. Una protezione non adeguata costituisce un ulteriore spunto di debolezza.
Il sottosistema utente (user) è strettamente correlato a quello di cui abbiamo appena parlato e riguarda i privilegi di utilizzo dei singoli utilizzatori della piattaforma. In questo caso specifico, l’hardening è finalizzato alla protezione di password e al controllo dei privilegi associati ad un singolo account, con particolare riferimento a scadenze e robustezza all’atto della creazione dell’elemento.
Un ultimo, ma non meno importante, fattore è dato dalla robustezza fisica del componente informativo. L’hardening di questa tipologia di piattaforma riguarda la parte di gestione della corrente elettrica, disastri naturali, ma non solo: massima attenzione viene data anche ad elementi quali: hard disk removibili, accesso a floppy disk, funzioni di reboot delle macchine in modalità maintenance e via dicendo.
Alcuni consigli di base per affrontarlo correttamente
La prima attività che è effettuata riguarda la rimozione di servizi e software non utilizzati. Tralasciando le installazioni Windows, di solito sono le macchine Linux a creare i dubbi più importanti. A volte, specie nelle realtà molto grandi, si “tirano su” delle macchine per il solo servizio di posta, ma si omette di effettuare il controllo degli altri eventuali servizi e degli script associati all’installazione. Sono questi a creare dei problemi.
Una volta “isolati” servizi e processi necessari, eliminando tutto quelo che non è strettamente necessario, è opportuno studiarne a fondo le caratteristiche, in quanto il rafforzamento andrà granularizzato sulle componenti in questione. Uno degli obiettivi fondamentali è quello del cosiddetto hiding, cioè del nascondere al potenziale attacker le informazioni di importanza strategica di cui può approfittare.
La letteratura consolidata in materia prescrive una suddivisione della procedura complessiva in quattro step fondamentali:
– Identificazione dei punti a rischio. Nel caso specifico si dovranno enucleare, tra l’altro, gli obiettivi che la piattaforma intende raggiungere (per esempio: mail server aziendale). Particolare attenzione va prestata in caso di upgrade di piattaforme già esistenti.
Molto spesso questi aggiornamenti creano problemi di sicurezza ormai consolidati e, inoltre, possono fungere da grimaldello per rendere l’host ove si installano l’ennesima testa di ponte.
Le domande che spesso ci si pone quando si effettua un’operazione di questo genere riguardano il fine operativo per cui una piattaforma viene installata, la definizione del responsabile di amministrazione, i servizi necessari per “far girare” la piattaforma, accessi e privilegi, logistica di base e così via.
– Assessment. Questa operazione viene effettuata dopo quella di identificazione e contiene i riferimenti per verificare la corrispondenza tra i criteri di implementazione attuale (in pratica è un’analisi del setup) e quelli oggettivamente riconosciuti dalla pratica.
In questo caso non sono previste le attività complesse e caratteristiche dell’analisi dei rischi, bensì delle checklist contenenti una serie di controlli da effettuare quali l’inventario delle porte e dei servizi necessari, utenti e processi.
– Preparazione delle operazioni. Detta anche fase di design, questa parte consiste nel definire i requisiti di dettaglio in ordine a cinque differenti aree di intervento.
Esse sono: networking, software di sistema, file system, utenti e sicurezza fisica. Ogni area viene esaminata a mezzo di questionari che considerano vari punti di rischio quali, per esempio, l’aggiornamento dei sistemi (può accadere nel setup dei sistemi operativi: per esempio, dopo la data di creazione del Cd di setup sono usciti 3 Service pack), la verifica della situazione della physical security (locali di custodia, criteri di accesso).
Al termine dei questionari si ha un elenco delle procedure di cui si ha bisogno realmente.
– Esecuzione delle operazioni. Qui si tratta del vero e proprio atto pratico. Esso si può estrinsecare in due modi: lavoro diretto su una risorsa installata ex novo, o lavoro di adeguamento di una struttura già esistente.
Le operazioni possono essere effettuate in un’unica soluzione o in maniera ripetuta. Questa seconda metodica viene sempre più utilizzata.
Nella seconda parte dell’articolo analizzeremo alcuni piccoli consigli per l’effettuazione di alcuni esempi pratici di quella che è la chirurgia informatica del futuro.
