La sicurezza nella Conservazione Sostitutiva in Outsourcing – Terza Parte

La considerazione della fine della seconda parte, ci permette di introdurre la seconda parte di questa guida. La sicurezza dei sistemi Unix/Linux.

In questi ultimi anni si sta diffondendo in maniera esponenziale, l’uso di sistemi Unix anche da parte di grandi aziende e multinazionali quali IBM,Novell, Oracle, Sun. Questo è dovuto per tre motivi principali : il primo è essenzialmente economico, poiché con i sistemi open source le aziende non devono comprare le licenze; il secondo motivo riguarda la possibilità di personalizzazione e implementazione delle tecnologie open source; mentre l’ultimo concerne proprio la sicurezza e la stabilità che questi sistemi offrono. Ed è su questo che questa guida si concentra.

I sistemi Unix hanno la capacità di segmentare perfettamente i privilegi dei processi. Il più elevato di tutti è il monumentale utente root. In Unix l’utente root ha il controllo totale del sistema e può configurare i vari livelli di protezione a suo piacimento, molto di più di un sistema Microsoft.

Come per i sistemi Microsoft anche per quelli Unix, lo scopo di un attacco hacker è quello di aver accesso remoto. Ci sono molti tipi di exploit per Unix, da quello di un servizio in ascolto, passando per il routing attraverso un sistema, fino all’exploit di un processo o di un programma che comunica con la scheda di rete in modalità promiscua. Ancora una volta, ribadisco come un firewall non fornisca un livello di protezione assoluto. Infatti grazie all’ IP forwarding è possibile raggirare un firewall ed entrare all’interno del kernel unix. Come sempre, anche per Unix il primo maggiore attacco è quello relativo alla scoperta della password d’amministrazione e si può utilizzare l’ utility THC-Hydra per portare attacchi di forza bruta. Un valido strumento di contromisura è sicuramente Secure Remote Password della Standford. Ricordo comunque che nel percorso fisico /etc/default/passwd o simili, è possibile rafforazare le configurazioni riguardanti l’utilizzo e le policy delle password. Una delle falle di sicurezza micidiali è sicuramente quella dovuta ad FTP. Gli hacker potrebbero leggere file di configurazioni protetti, come /etc/passwd ed altri. Per i responsabili della conservazione sostitutiva è certamente sconsigliato l’uso di FTP per lo scambio dei documenti del cliente. Non si dovrebbe mai utilizzare il servizio FTP per l’invio di informazioni sensibili. Quindi l’unica contromisura è chiudere tale servizio. La stessa considerazione può essere fatta per il servizio di Mail Transfer Agent.

Tempo fa la Sun introdusse un servizio molto utile : RPC. Il Remote Procedure Call è una tecnologia che consente ad un programma di eseguire codice su un sistema remoto. Purtroppo sin dalla sua nascita, sono stati riscontrati molti bug. Per penetrare RPC, basta effettuare un attacco di buffer overflow o di validazione di input. Ma di questi due attacchi ne parleremo nella terza parte di questa guida. Comunque sia bucare RPC, significa avere accesso al sistema come utente root. Per coloro i quali non posso fare a mano di RPC, consiglio l’utilizzo di Secure PRC, molto più affidabile.

Un’implementazione molto usata nei sistemi Unix è quella di BIND per il servizio DNS. Acune versioni di BIND possono essere attaccati facilmente con l’ avvelenamento della cache DNS, di cui parleremo più avanti ed il sempre citato buffer overflow. Consiglio l’uso di BIND 9 e successivi per proteggersi da questi attacchi e l’avvio del servizio named associato come utente non root. Un altro servizio molto usato ma non privo di bug, è OpenSSH. Uno di questi bug, è l’attacco di tipo integer overflow. In effetti durante la gestione delle risposte ricevute nella procedura di autenticazione, un hacker da remoto potrebbe essere in grado di eseguire codice con privilegi di root. Anche in questo caso conviene utilizzare almeno OpenSSH versione 3.4.0 o successive. Anche per OpenSSL valgono le stesse considerazioni, e si consiglia l’utilizzo della versione 0.9.6e o successive.

Un’opzione molto utile per i sistemisti e gli amministratori di rete, in Unix, è quella di poter utilizzare la modalità nascosta sulla scheda di rete. Questa soluzione, che ad esempio è molto facile da implementare in Solaris ed Open Solaris della Sun, garantisce un livello di protezione molto alto. Una scheda di rete per essere nascosta, deve essere in modalità promiscua, in questo modo non possiede un vero e proprio indirizzo ip e quindi si impedisce ad un hacker di comunicare via IP con il sistema oggetto dell’attacco. In Unix, tutti i i file hanno un SUID (Set user ID) e un SGID (Set Group ID). SUID e GUID definiscono gli attributi e i privilegi dei files da parte degli utenti del sistema.

Per questo motivo, si consiglia vivamente di avviare pochissimi processi come utente root. Questo perchè un hacker potrebbe trovare molti file con SUID e GUID root e quindi attaccarli. La migliore precauzione è quella di rimuovere i bit SUID e GUID dal maggior numero di files. Per visualizzare quali files siano SUID o meno, basta utilizzare il comando find di unix e successivamente consultare la documentazione predisposta, per rimuovere ove possibile il bit SUID dal file/processo. Concludiamo questa seconda parte dedicata ai sistemi Unix, fornendo una serie di risorse per la sicurezza di questi sistemi : il Solaris Secutiry Toolkit, l’OpenBSD Security e il Linux Security HOWTO.

Siamo giunti alla terza ed ultima parte di questa guida. Di seguito verranno descritti gli attacchi al codice ed alle applicazioni web che si appoggiano su un web server. Sicuramente questa parte della guida è forse di più interesse per gli operatori della conservazione sostitutiva in outsourcing, rispetto alle precedenti.

Incominciamo col dire subito che non esiste un software privo di bug. E’ impossibile sviluppare un software che sia privo di errori da parte dei programmatori e degli ingegneri del software che progettano l’architettura. Sopratutto in questi periodi, in cui l’esigenze del business prevalgono sui tempi di sviluppo di un software, che dovrebbero essere molto più lunghi.

E allora, bisogna accettare passivamente questo problema ? Assolutamente no, ci sono tantissime soluzioni da applicare e contromisure che vanno fatte nel tempo, anche dopo aver sviluppato un software. Ed è quello che fanno tutte le aziende e multinazionali produttrici di software. Di seguito non saranno indicate contromisure proprie del programmatore, quindi che devono essere applicate in fase di sviluppo, ma saranno descritte tecniche che si riportano al software che è già in fase di distribuzione. Vediamone qualcuna.
Uno dei rischi maggiori per chi sviluppa software è sicuramente quello del buffer overflow. La tipologia di attacco per buffer overflow è quella di sovvertire la funzione di un programma privilegiato in modo che l’attaccante possa prendere il controllo di quel programma, controllando anche l’host. Una forma d’attacco di questo tipo combina la tecnica d’iniezione con la corruzione dei records. Ovvero si trova una variabile soggetta ad overflow e si inserisce l’attacco per avere controllo del programma. Una soluzione a questo problema è semplice : realizzare buoni programmi. Cosa più facile a dirsi che a farsi. In effetti il buffer overflow si appoggia sull’utilizzo delle variabili che sono memorizzate all’interno dello stack. Lo stack altro non è che la memoria del computer utilizzata per l’esecuzione dei programmi. Un importante contromisura, quindi, è quella di utilizzare la protezione dall’esecuzione sullo stack, attivabile su quasi tutti i sistemi operativi in commercio.

Ovvio che tutte le contromisure, quali ad esempio, la validazione dell’input, la canonicalizzazione, l’utilizzo delle giuste opzioni dei compilatori (come ad esempio /GS e /SAFESEH per Visual C++), URLScan per ISS ed altre, sono tutte valide misure di protezione, che tutti i programmatori dovrebbero applicare, ma che in questa guida non verranno approfondite.