[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ successivo ]

Securing Debian Manual
Capitolo 9 - Prima della compromissione


9.1 Aggiornare continuamente il sistema

Bisognerebbe eseguire spesso gli aggiornamenti per la sicurezza. La maggior parte degli exploit deriva da vulnerabilità conosciute cui non sia stato posto un rimedio tempestivo, come spiega il saggio di Bill Arbaugh presentato al Simposio sulla sicurezza e la riservatezza dell'IEEE nel 2001. Gli aggiornamenti sono descritti in Eseguire un security update, Sezione 4.2.


9.1.1 Controllo manuale degli aggiornamenti di sicurezza disponibili

Debian ha uno strumento specifico per controllare se occorra aggiornare un sistema (si veda più sotto Tiger), anche se molti utenti preferiranno il controllo manuale degli aggiornamenti di sicurezza disponibili per il loro sistema.

Se avrete configurato il sistema come mostrato in Eseguire un security update, Sezione 4.2, basterà dare il comando:

     # apt-get update
     # apt-get upgrade -s

La prima linea scaricherà la lista dei pacchetti disponibili tra quelli presenti sul sistema e configurati; l'opzione -s simulerà l'esecuzione, cioè non scaricherà o installerà i pacchetti ma piuttosto, comunicherà quali sarebbero scaricati/installati. Dal risultato, si potrà dedurre quali pacchetti siano stati corretti da Debian e siano disponibili come aggiornamento di sicurezza. Per esempio:

     # apt-get upgrade -s
     Reading Package Lists... Done
     Building Dependency Tree... Done
     2 packages upgraded, 0 newly installed, 0 to remove and 0  not upgraded.
     Inst cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
     Inst libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)
     Conf cvs (1.11.1p1debian-8.1 Debian-Security:3.0/stable)
     Conf libcupsys2 (1.1.14-4.4 Debian-Security:3.0/stable)

In questo esempio, si vede come il sistema necessiti di essere aggiornato con i nuovi pacchetti cvs e cupsys trovati nell'archivio della sicurezza di woody; se si vuole capire perché tali pacchetti siano necessari, puntate il vostro browser presso http://security.debian.org e controllate i più recenti Avvisi sulla Sicurezza di Debian relativi a questo argomento, presso: DSA-233 (per cvs) e DSA-232 (per cupsys).


9.1.2 Controllo automatico degli aggiornamenti con cron-apt

Un altro metodo per l'aggiornamento automatico per la sicurezza è l'uso di cron-apt, strumento per aggiornare il sistema a intervalli regolari (con l'impiego di cron), che, in modo predefinito, aggiornerà la lista dei pacchetti e scaricherà i nuovi; può essere configurato anche per inviare messaggi all'amministratore di sistema.

Se si vuole aggiornare automaticamente il proprio sistema (anche solo scaricando dei pacchetti), prendete in considerazione l'opportunità di controllare la versione della distribuzione, come descritto in Controllare i rilasci della distribuzione, Sezione 7.4.3; in mancanza di questo controllo, non potrete essere sicuri che i pacchetti provengano da fonte fidata.


9.1.3 Usare Tiger per controllare automaticamente gli aggiornamenti per la sicurezza

Se state cercando uno strumento per un controllo veloce e che riporti le vulnerabilità di sicurezza del sistema, provate il pacchetto tiger. Questo pacchetto è un insieme di script di shell Bourne, programmi C e file di dati usati per eseguire dei controlli di sicurezza. Il pacchetto di Debian GNU/Linux ha degli accorgimenti addizionali orientati fortemente alla distribuzione Debian, che forniscono più funzionalità che gli script di Tiger forniti da TAMU (o persino TARA, una versione di Tiger distribuita da ARSC). Leggete il file README.Debian e la pagina di manuale di tiger(8) per più informazioni.

Una di queste aggiunte è lo script deb_checkadvisories. Questo script prende una lista di DSA e controlla i pacchetti installati, riportando alla versione precedente tutti i pacchetti che sono vulnerabili, in accordo con il Debian Security Team. Ciò è leggermente differente, un approccio più generale è implementato dallo script check_signatures di Tiger, che controlla l'MD5sum di pacchetti dalle vulnerabilità note.

Poiché Debian attualmente non possiede una lista con gli MD5sum dei pacchetti dalle vulnerabilità note (utilizzata da altri sistemi operativi come Sun Solaris), è utilizzato il metodo controllo-contro-DSA (check-against-DSA). L'approccio del DSA e quello MD5sum soffrono entrambi del problema che la firma deve essere aggiornata frequentemente.

Ciò è attualmente risolto facendo una nuova versione del pacchetto Tiger, ma il manutentore del pacchetto potrebbe non creare una nuova versione ogni volta che un DSA viene annunciato. Un'aggiunta interessante, che non è ancora implementata, dovrebbe essere di fare quest'operazione prima delle altre. Cioè, scaricare il DSA via web, produrre la lista e poi eseguire il controllo. Il DSA è attualmente aggiornato con l'aggiornamento del codice WML usato per la costruzione di http://security.debian.org (il web server, proprio così) dal locale CVS del manutentore.

Sarebbe necessario un programma che analizzi i DSA pubblicati, sia ricevuti via mail che disponibili in security.debian.org e che poi generi il file usato da "deb_checkadvisories" per confermare che le vulnerabilità siano state notate. Speditelo come un bug per tiger.

Il controllo menzionato dovrebbe essere eseguito attraverso la configurazione standard del programma una volta installato (vedete /etc/tiger/cronrc):

     # Check for Debian security measures every day at 1 AM
     #
     1 * *   deb_checkmd5sums deb_nopackfiles deb_checkadvisories
     #

C'è un controllo ulteriore che si potrebbe voler aggiungere, che non è ancora parte degli standard degli script di cron. Questo controllo è lo script check_patches, che funziona nel seguente modo:

Se state utilizzando un sistema stable e avete aggiunto la sorgente security.debian.org per apt al vostro /etc/apt/sources.list (come descritto in Eseguire un security update, Sezione 4.2), questo script sarà in grado di avvisarvi se ci sono nuovi pacchetti che avete bisogno di installare. Poiché gli unici pacchetti che cambiano in questa configurazione sono gli aggiornamenti di sicurezza, allora avrete proprio ciò che desiderate.

Naturalmente, questo non funzionerà se state utilizzando testing o sid/unstable, poiché attualmente, i nuovi pacchetti sono probabilmente più numerosi di quelli di sicurezza.

Potete aggiungere questo script ai controlli eseguiti da cron (nel file di configurazione precedentemente indicato) e tigercron spedirà una mail (a qualunque Tiger_Mail_RCPT sia stato configurato in /etc/tiger/tigerrc) con i nomi dei nuovi pacchetti:

     # Check for Debian security measures every day at 1 am
     #
     1 * *   deb_checkmd5sums deb_nopackfiles check_patches
     #

9.1.4 Altri metodi per effettuare aggiornamenti per la sicurezza

Potete anche considerare un programma non ufficiale, scritto da Fruhwirth Clemens, per aggiornamenti di sicurezza dal sito security.debian.org con firma controllata: secpack.


9.1.5 Evitare di usare il ramo instabile

A meno che non vogliate dedicare tempo a riparare i pacchetti da soli quando sorge una vulnerabilità, dovreste non usare il ramo instabile di Debian per sistemi di produzione. La principale ragione per questo è che non ci sono aggiornamenti di sicurezza per unstable (Vedete Come viene gestita la sicurezza in testing ed unstable?, Sezione 11.3.7).

Il fatto è che alcuni problemi di sicurezza potrebbero apparire nella distribuzione unstable e non nella stable. Questo è dovuto alle nuove funzionalità costantemente aggiunte alle applicazioni lì fornite, come anche nuove applicazioni che vengono incluse e non hanno avuto ancora un test approfondito.

Allo scopo di eseguire aggiornamenti di sicurezza nel ramo unstable, dovreste aggiornare interamente alle nuove versioni (che vengono aggiornate più che i pacchetti in questione). Sebbene ci siano alcune eccezioni, le patch di sicurezza vengono solitamente riportate nel ramo stable. L'idea primaria è che tra gli aggiornamenti non venga aggiunto nuovo codice, ma che vengano solamente risolti i problemi importanti.


9.1.6 Evitare di usare la distribuzione testing

Se utilizzate la distribuzione testing, ci sono dei problemi che occorre considerare circa la disponibilità di aggiornamenti di sicurezza:


9.1.7 Aggiornamento automatico in un sistema Debian GNU/Linux

Per cominciare gli aggiornamenti automatici non sono del tutto consigliabili, visto che gli amministratori dovrebbero leggere gli annunci del DSA e comprendere l'impatto di ogni aggiornamento di sicurezza.

Se volete aggiornare automaticamente il vostro sistema occorre:

Un'alternativa più sicura potrebbe essere usare l'opzione -d (o --download-only), che scaricherà ma non installerà i pacchetti necessari. L'aggiornamento si farà manualmente se l'esecuzione di cron mostra che il sistema deve essere aggiornato.

Per eseguire questi compiti il sistema deve essere propriamente configurato per scaricare gli aggiornamenti di sicurezza come visto in Eseguire un security update, Sezione 4.2.

Ad ogni modo questo procedimento non è consigliabile per unstable senza prima un'accurata analisi, perché potreste rendere il vostro sistema inusabile se qualche bug pericoloso si insinuasse in un pacchetto importante e venisse installato nel sistema. Testing è un po' più sicura da questo punto di vista, dal momento che le possibilità di scoprire i bug più gravi prima che il pacchetto sia inserito in testing sono maggiori (tuttavia potreste non avere alcun aggiornamento di sicurezza disponibile in questo caso).

Se avete una distribuzione mista, cioè una distribuzione stable con alcuni pacchetti presi da testing o unstable, potete utilizzare i pinning o l'opzione --target-release di apt-get per aggiornare solo quei pacchetti. [33]


9.2 Pianificare la ricerca di intrusi

In Debian GNU/Linux sono presenti molti programmi che servono ad individuare intrusi nel sistema, essi possono scovare delle attività malevole sul vostro sistema personale, oppure negli altri sistemi della vostra rete. Questo tipo di difesa è importante sia che nel sistema siano residenti informazioni riservate sia che voi siate veramente paranoici in fatto di sicurezza. I più comuni metodi per individuare degli intrusi sono: l'individuazione di anomalie e la ricerca mediante l'uso di espressioni regolari.

Si deve essere consapevoli che la sicurezza del sistema viene migliorata con l'introduzione di questi programmi, avrete bisogno di avere un meccanismo di allerta e risposta configurato correttamente. La ricerca di intrusi senza un valido sistema di allerta diviene completamente inutile.

Quando viene scoperto un particolare attacco, molti di questi programmi sono configurati per inviare un log con syslogd oppure per inviare un e-mail all'amministratore (le intestazioni delle e-mail sono solitamente configurabili). L'amministratore ha la facoltà di configurare questi strumenti. I sistemi di avviso di attacco avvenuto possono essere inutili se vengono generati un giorno dopo che l'attacco è avvenuto. Siamo sicuri che questa sia la politica di sicurezza migliore, è però importante che gli strumenti per migliorare questa politica siano implementati.

Un'interessante fonte di informazioni è il CERT lista delle intrusioni accertate (CERT's Intrusion Detection Checklist).


9.2.1 Individuazione delle intrusioni sulla rete

Gli strumenti che controllano le intrusioni lo fanno sul traffico di un segmento di rete e usano le informazioni come un database. Specificatamente, vengono esaminati i pacchetti in rete e si controlla che essi abbiano un certificato valido.

Snort è uno sniffer che scova gli attacchi usando un dizionario di "firme" di precedenti attacchi. Può controllare una gran varietà di attacchi e scansioni, come: i buffer overflow, la scansione delle porte, attacchi CGI, indagini SMB e molti altri. Tra le altre cose Snort possiede la qualità di avvisare l'amministratore in tempo reale. Potete usare Snort per testare una serie di computer che si trovano nella vostra rete, come se si trattasse di uno solo. Basta installare pacchetto con il comando apt-get install snort, è importante rispondere alle domande e guardare il log.

Il pacchetto snort presente in Debian possiede molte opzioni di sicurezza attivate in maniera predefinita. Ma potete anche configurare a piacimento la configurazione aggiungendo semplicemente un servizio attivo sulla vostra macchina. Potete altresì ricercare pacchetti addizionali specifici per un particolare servizio.

Esistono altri semplici programmi che possono venire usati per ricercare attacchi provenienti dalla rete. Ad esempio portsentry è un interessante pacchetto che permette di chiudere le porte sottoposte a scansione sul vostro computer. Altri programmi come ippl oppure iplogger scovano attacchi portati mediante il protocollo IP (TCP e ICMP), anche se non sono provvisti di molte delle tecniche avanzate presenti in snort.

Potete testare questi tools usando idswakeup presente in Debian, esso è uno script di shell che genera dei falsi allarmi ed include molti comuni attacchi.


9.2.2 Sistemi per individuare gli intrusi

I sistemi per individuare gli intrusi controllano chi usa i file di log e/o i sistemi di verifica come se fossero una sorgente dati. Controllano i processi sospetti, l'accesso al sistema e possono riportare dei cambiamenti ai file fondamentali per il sistema.

Tiger è un vecchio strumento per scoprire gli intrusi ed è ben integrato in Debian sin da Woody. Tiger si prende cura di verificare i classici problemi che riguardano la sicurezza, come la sicurezza delle password, possibili problemi ai file system, processi di comunicazione e qualsiasi altro possibile compromesso. Sono presenti in questo pacchetto nuove verifiche di sicurezza specifiche per Debian come: verifica MD5sums dei file installati, localizzazione dei file che non appartengono ai pacchetti e analisi dei processi in ascolto. L'installazione normale di tiger è attiva ogni giorno e genera un rapporto che viene spedito all'amministratore concernente i possibili file compromessi del sistema.

I programmi di controllo dei log come ad esempio logcheck possono essere usati per scovare dei tentativi di intrusione. Al riguardo potete leggere in Usare e personalizzare logcheck, Sezione 4.12.1.

In più esistono programmi che controllano l'integrita dei file systems (leggete in Controllare l'integrità del file system, Sezione 4.16.3) che sono abbastanza utili nella ricerca di anomalie in un sistema sicuro. È molto probabile che un vero intruso modifichi alcuni file nel file system locale allo scopo di aggirare la politica di sicurezza, installare dei cavalli di Troia, oppure creare utenti. Questi eventi vengono ricercati dai programmi atti a controllare l'integrità dei file system.


9.3 Evitare i root-kit


9.3.1 Moduli del kernel caricabili (LKM)

I moduli caricabili del kernel sono file che contengono componenti del kernel per espanderne le funzionalità, caricabili in modo dinamico. Il principale vantaggio nel loro impego sta nella possibilità di aggiungere apparecchi addizionali, come una scheda sonora o una Ethernet, senza apportare correzioni al sorgente del kernel e senza ricompilarlo interamente. Però, al momento, i cracker li sfruttano per i loro root- kit (usurpando l'account di root (knark e adore)) e aprire porte segrete (le cosiddette "back door") nei sistemi GNU/Linux.

Le porte segrete aperte tramite LKM sono più sofisticate e meno rilevabili rispetto ai tradizionali tentativi di usurpare gli strumenti di root. Possono nascondere processi, file, cartelle e perfino connessioni, senza modificare il codice sorgente dei binari. Per esempio, un LKM maligno può obbligare il kernel a nascondere processi specifici da procfs, cosicché una copia del binario ps, ritenuta fedele, non fornirebbe, invece, informazioni precise sugli attuali processi in atto nel sistema.


9.3.2 Scoprire i root-kit

Ci sono due approcci per difendere il sistema contro i root-kit a mezzo LKM: la difesa preventiva e quella reattiva. Il lavoro di ricerca può essere semplice e indolore, o difficile e faticoso, a seconda dell'approccio.


9.3.2.1 Difesa proattiva

Il vantaggio di questo tipo di difesa è che in primo luogo previene danni al sistema. Una siffatta strategia consiste nel motto arrivateci per primi, cioè, caricare un LKM atta a proteggere il sistema da altri LKM maliziosi. Una seconda strategia è quella di rimuovere completamente la possibilità dei moduli del kernel caricabili. Si noti, comunque, che esistono rootkit che potrebbero funzionare anche in questo caso, ce ne sono alcuni che manomettono direttamente /dev/kmem (la memoria del kernel) per non essere scoperti.

Debian GNU/Linux ha alcuni pacchetti che possono essere utilizzati per creare una difesa proattiva:

Se non si hanno affatto bisogno di molte caratteristiche del kernel sul proprio sistema GNU/Linux, si può disabilitare il supporto ai moduli caricabili durante la fase di configurazione del kernel. Per disabilitare questo supporto, impostate CONFIG_MODULES=n durante la fase di configurazione per la creazione del vostro kernel, oppure nel file .config. Questo annullerà i tentativi dei rootkit LKM, ma si perderà questa potente caratteristica del kernel Linux. Inoltre, disabilitare il supporto per i moduli caricabili a volte potrebbe appesantire il kernel, rendendo il supporto ai moduli necessario.


9.3.2.2 Difesa reattiva

Il vantaggio di una difesa reattiva è che non sovraccarica le risorse del sistema. Funziona confrontando la tabella delle chiamate di sistema con una copia sicura in un file del disco, System.map. Ovviamente, una difesa reattiva si limiterà ad avvisare l'amministratore di sistema dopo che il sistema è già stato compromesso.

Il controllo contro alcuni rootkit in Debian può essere realizzato con il pacchetto chkrootkit. Il programma Chkrootkit ricerca le firme di svariati rootkit noti sul sistema ma non è certo un test definitivo.

Un altro tool d'aiuto è KSTAT (Kernel Security Therapy Anti Trolls) del gruppo S0ftproject. KSTAT controlla l'area di memoria del kernel (/dev/kmem) alla ricerca di informazioni che riguardano l'host obiettivo, in modo da assistere l'amministratore di sistema a trovare e rimuovere LKM maliziosi.


9.4 Si può fare... — idee geniali/paranoiche

Probabilmente questa è la sezione più instabile e bizzarra, ma si spera che alcune di queste idee, volte ad aumentare la sicurezza, possano essere realizzate — nonostante possano sembrare, a seconda dei punti di vista, geniali, paranoiche, pazzesche o... profetiche.


9.4.1 Costruirsi una honeypot ("trappola al miele")

FIXME: Serve maggiore materiale specifico per Debian

Una honeypot ("trappola al miele") è un sistema progettato per insegnare agli amministratori come i cracker sondano e sfruttano il sistema; è un modo di impostare un sistema con l'aspettativa e l'obiettivo che sia sondato, attaccato e potenzialmente, sfruttato. Conoscendo gli strumenti e le metodiche dei cracker, un amministratore di sistema impara a proteggere meglio i sistemi e le reti di cui si occupa.

Un sistema Debian GNU/Linux può essere agevolmente configurato come "trappola al miele", dedicando un po' di tempo ad implementare e controllare: basta impostare il falso server con un firewall e un qualsiasi rilevatore di intrusioni nella rete, collegarlo a Internet e aspettare. In caso di sfruttamento del sistema, occorre essere ben certi di essere avvisati per tempo (vedete L'importanza di log e avvisi, Sezione 4.12), sì da poter assumere le opportune contromisure e terminare il danneggiamento quando se ne conosca abbastanza. Questo è un elenco di pacchetti e di aspetti da valutare durante l'impostazione di una honeypot:

Maggiori informazioni sulla costruzione di honeypot si possono trovare nell'eccellente articolo di Lanze Spitzner To Build a Honeypot, (costruire una honeypot), - della serie "conosci i tuoi nemici" o in Building your own honeypot (costruirsi la propria honeypot), di David Raikow. Inoltre, l'Honeynet Project offre informazioni preziose sul modo di costruire queste trappole e controllare gli attacchi rivolti contro di esse.


[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ successivo ]

Securing Debian Manual

Version: 2.97, Mon, 16 May 2005 21:28:06 +0200

Javier Fernández-Sanguino Peña jfs@debian.org
Autore, Sezione 1.1
Per la traduzione si veda l'Appendice I