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.8.
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.8, 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).
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.
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.8), 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 #
Potete anche considerare un programma non ufficiale, scritto da Fruhwirth
Clemens, per aggiornamenti di sicurezza dal sito security.debian.org con firma
controllata: secpack
.
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.
Se utilizzate la distribuzione testing, ci sono dei problemi che occorre considerare circa la disponibilità di aggiornamenti di sicurezza:
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:
apt
in modo che i pacchetti che non volete aggiornare
rimangano alla versione corrente o con la funzione pinning di
apt
o marcandoli con hold con dpkg
o
dselect
.
Per mettere un pin a una determinata versione sui pacchetti dovete modificare
/etc/apt/preferences
(vedete apt_preferences(5)
aggiungendo:
Package: * Pin: release a=stable Pin-Priority: 100
FIXME: verificare se questa configurazione è corretta.
cron
, cosicché
l'aggiornamento sia eseguito quotidianamente; per esempio:
apt-get update && apt-get -y upgrade
L'opzione -y farà in modo che apt
risponda
automaticamente "yes" a tutte le domande che possono essere poste
durante l'aggiornamento. In alcuni casi può essere preferibile usare l'opzione
--trivial-only invece di quella --assume-yes
(equivalente a -y). [27]
cron
in modo che debconf
non ponga
nessuna domanda durante l'aggiornamento; in questo modo l'aggiornamento non è
interattivo. [28]
cron
, che saranno
spediti al superutente (a meno che cron
non sia stato configurato
diversamente con la variabile MAILTO nello script).
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.8.
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. [29]
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)
.
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.
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.
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.
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.
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:
kernel-patch-2.4-lsm
- LSM è il framework Linux Security Modules.
lcap
- una interfaccia user friendly per rimuovere la
possibilità (il controllo degli accessi a livello kernel) nel kernel,
rendendo il sistema più sicuro. Per esempio, eseguendo lcap
CAP_SYS_MODULE [30] si
rimuoverà la possibilità di caricare moduli (anche per l'utente root). [31] Per maggiori informazioni
sulle varie possibilità potete controllare una sezione dello sviluppo del
kernel di Jon Corbet's Kernel development
sezione in LWN (dicembre 1999).
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.
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.
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.
chattr
(tratto da
Tips-HOWTO, di Jim Dennis): dopo una semplice installazione e una
configurazione iniziale, potete usare il programma chattr
con
l'attributo +i, per far si che i file non possano essere
modificati (ossia, cancellati, rinominati, collegati o riscritti). È
bene impostare questo attributo su tutti i file delle cartelle
/bin
, /sbin/
, /usr/bin
,
/usr/sbin
, /usr/lib
e sui file del kernel in root.
Si possono anche copiare i tutti file di /etc/
, con
tar
o altro programma simile e classificare l'archivio come
immutabile.
Questa strategia aiuta a limitare i danni che si possono fare quando si opera
come root, così da non sovrascrivere file per una erronea redirezione
dell'operatore e non rendere inutilizzabile il sistema per uno spazio di troppo
nel comando rm -fr
; si può fare comunque ancora molto danno ai
propri dati — ma le librerie e i binari saranno PIU' SICURI!
Per di più, essa rende impossibile o, per lo meno, più difficile una serie di attacchi alla sicurezza tramite denial of service (DoS - rifiuto di fornire servizi), miranti a sovrascrivere un file attraverso l'azione di qualche programma di SETUID che non fornisca comandi arbitrari di shell.
Un inconveniente di questa strategia sorge in fase di costruzione e
installazione di vari binari di sistema, dal momento che impedisce al comando
make install
la sovrascrittura dei file. Quando ci si scorda di
leggere il Makefile e di cambiare con chattr -i
i file da
sovrascrivere (e le cartelle in cui si desidera aggiungerli), il comando make
fallisce; bisogna lanciare chattr
e poi farlo ripartire. Si può
anche approfittare dell'occasione per sbarazzarsi di binari e librerie vecchi,
spostandoli in una cartella .old/ o in un archivio tar, per esempio.
Si noti che questa strategia impedisce anche di aggiornare i pacchetti del
proprio sistema, dal momento che i file forniti dai pacchetti dell'ultima
versione non possono essere sovrascritti. A questo proposito, si potrebbe
creare uno script o un altro meccanismo per disabilitare il flag
"immutabile" su tutti i binari giusto prima di fare un apt-get
update
.
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:
syslog-ng
, utile per mandare log dalla trappola ad un server
remoto di syslog.
snort
, per impostare la cattura dell'intero traffico in entrata
nella trappola e rilevare gli attacchi.
osh
, una shell di root, di tipo SETUID, con limitazioni,
migliorata sotto il profilo della sicurezza e con un sistema di registrazione
dei log (vedete, più oltre, l'articolo di Lance Spitzner).
Deception Toolkit
tct
- gli
"Strumenti del Patologo"), per fare i controlli post-attacco.
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.
Securing Debian Manual
2.96 20 septiembre 2003Sabato, 30 Agosto 2003 18:27:45 +0200jfs@computer.org