<chapt><heading>Prima della compromissione</heading>



<sect id="keep-up-to-date"><heading>Aggiornare continuamente il sistema</heading>

<p>
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
<url id="http://www.cs.umd.edu/~waa/vulnerability.html" name="saggio di Bill Arbaugh"> presentato al Simposio sulla
sicurezza e la riservatezza dell'IEEE nel 2001. Gli aggiornamenti sono
descritti in <ref id="security-update">.</p>



<sect1><heading>Controllo manuale degli aggiornamenti di sicurezza disponibili</heading>

<p>
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.</p>

<p>
Se avrete configurato il sistema come mostrato in 
<ref id="security-update">, baster dare il comando:

<example>
# apt-get update
# apt-get upgrade -s
</example></p>

<p>
La prima linea scaricher la lista dei pacchetti disponibili tra quelli 
presenti sul sistema e configurati;
l'opzione <tt>-s</tt> simuler l'esecuzione, cio
<em>non</em> 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:

<example>
# 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)
</example></p>

<p>
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
<em>woody</em>; se si vuole capire perch tali pacchetti siano necessari,
puntate il vostro browser presso <url id="http://security.debian.org">
e controllate i pi recenti Avvisi sulla Sicurezza di Debian relativi a
questo argomento, presso:
<url id="http://www.debian.org/security/2003/dsa-233" name="DSA-233"> 
(per cvs) e
<url id="http://www.debian.org/security/2003/dsa-232" name="DSA-232">
(per cupsys).</p></sect1>


<sect1 id="cron-apt"><heading>Controllo automatico degli aggiornamenti con cron-apt</heading>

<p>
Un altro metodo per l'aggiornamento automatico per la sicurezza  l'uso di
<package>cron-apt</package>, 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.</p>

<p>
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 
<ref id="check-releases">; in mancanza di questo controllo, 
non potrete essere sicuri che i pacchetti provengano da fonte fidata.</p></sect1>


<sect1><heading>Usare Tiger per controllare automaticamente 
       gli aggiornamenti per la sicurezza</heading>

<p>
Se state cercando uno strumento per un controllo veloce e che riporti
le vulnerabilit di sicurezza del sistema, provate il pacchetto
<package>tiger</package>. 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 
<manref name="tiger" section="8"> per pi informazioni.</p>

<p>
Una di queste aggiunte  lo script <tt>deb_checkadvisories</tt>. 
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 <tt>check_signatures</tt> di Tiger, che 
controlla l'MD5sum di pacchetti dalle vulnerabilit note.</p>

<p>
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
<em>controllo-contro-DSA (check-against-DSA)</em>. 
L'approccio del DSA e quello MD5sum soffrono entrambi del problema 
che la firma deve essere aggiornata frequentemente.</p>

<p>
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 <url id="http://security.debian.org">  (il web server, proprio cos) 
dal locale CVS del manutentore.</p>

<p>
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 <package>tiger</package>.</p>

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

<example>
# Check for Debian security measures every day at 1 AM
#
1 * *   deb_checkmd5sums deb_nopackfiles deb_checkadvisories
#
</example></p>

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

<list>

<item><p>Esegue <tt># apt-get update</tt></p></item>
<item><p>Controlla se ci sono nuovi pacchetti disponibili</p></item>

</list></p>

<p>
Se state utilizzando un sistema <em>stable</em> e avete 
aggiunto la sorgente security.debian.org per <prgn>apt</prgn> al vostro
<file>/etc/apt/sources.list</file> (come descritto in
<ref id="security-update">), 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.</p>

<p>
Naturalmente, questo non funzioner se state utilizzando 
<em>testing</em> o <em>sid/unstable</em>, poich attualmente, i 
nuovi pacchetti sono probabilmente pi numerosi di quelli di 
sicurezza.</p>

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

<example>
# Check for Debian security measures every day at 1 am
#
1 * *   deb_checkmd5sums deb_nopackfiles check_patches
#
</example></p></sect1>


<sect1><heading>Altri metodi per effettuare aggiornamenti per la sicurezza</heading>

<p>
Potete anche considerare un programma non ufficiale, scritto da Fruhwirth
Clemens, per aggiornamenti di sicurezza dal sito security.debian.org con firma
controllata: <url id="http://therapy.endorphin.org/secpack/" name="secpack">.</p></sect1>


<sect1><heading>Evitare di usare il ramo instabile</heading>

<p>
A meno che non vogliate dedicare tempo a riparare i pacchetti da soli
quando sorge una vulnerabilit, dovreste  <em>non</em> usare il ramo
instabile di Debian per sistemi di produzione. La principale ragione
per questo  che non ci sono aggiornamenti di sicurezza per
<em>unstable</em> (Vedete <ref id="sec-unstable">).</p>

<p>
Il fatto  che alcuni problemi di sicurezza potrebbero apparire nella
distribuzione <em>unstable</em> e <em>non</em> nella <em>stable</em>. 
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.</p>

<p>
Allo scopo di eseguire aggiornamenti di sicurezza nel ramo
<em>unstable</em>, 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 <em>stable</em>. L'idea primaria  che 
tra gli aggiornamenti non venga aggiunto <em>nuovo codice</em>, ma 
che vengano solamente risolti i problemi importanti.</p></sect1>


<sect1><heading>Evitare di usare la distribuzione testing</heading>

<p>
Se utilizzate la distribuzione <em>testing</em>, ci sono dei problemi che
occorre considerare circa la disponibilit di aggiornamenti di
sicurezza:

<list>

<item>
<p>Quando viene realizzato un aggiornamento di sicurezza
vengono preparati i pacchetti per <em>unstable</em> e le stesse
modifiche vengono reimplementate in <em>stable</em> 
(visto che la versione dei pacchetti di stable hanno una versione
minore). I pacchetti della distribuzione <em>stable</em> 
sono testati pi a fondo di quelli di <em>unstable</em>, dal 
momento che quest'ultima potrebbe disporre direttamente 
dell'ultimo rilascio dei sorgenti originali.</p></item>
<item>
<p>Gli aggiornamenti di sicurezza sono immediatamente disponibili
per entrambe le distribuzioni (ma non per il ramo <em>testing</em>).</p></item>
<item>
<p>Se non vengono scoperti (nuovi) bug nella versione di
<em>unstable</em> del pacchetto, questo viene inserito in 
<em>testing</em> dopo alcuni giorni (di solito pi di una settimana). 
Tuttavia questo dipende dallo stato di rilascio della distribuzione.</p></item>

</list></p></sect1>


<sect1><heading>Aggiornamento automatico in un sistema Debian GNU/Linux</heading>

<p>
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.</p>

<p>Se volete aggiornare automaticamente il vostro sistema occorre:

<list>

<item>
<p>Configurare <prgn>apt</prgn> in modo che i pacchetti che non volete
aggiornare rimangano alla versione corrente o con la funzione
<em>pinning</em> di <prgn>apt</prgn> o marcandoli con 
<em>hold</em> con <prgn>dpkg</prgn> o <prgn>dselect</prgn>.</p>

<p>
Per mettere un pin a una determinata versione sui pacchetti
dovete modificare <file>/etc/apt/preferences</file> (vedete
<manref name="apt_preferences" section="5"> aggiungendo:

<example>
  Package: *
  Pin: release a=stable
  Pin-Priority: 100
</example></p>

<p>FIXME: verificare se questa configurazione  corretta.</p></item>

<item><p>Usate cron-apt, come in <ref id="cron-apt">,
abilitandolo ad installare i pacchetti scaricati,
o aggiungete una riga in <prgn>cron</prgn>,
cosicch l'aggiornamento sia eseguito
quotidianamente; per esempio:

<example>
  apt-get update && apt-get -y upgrade
</example></p>

<p>
L'opzione <tt>-y</tt> far in modo che <prgn>apt</prgn> 
risponda automaticamente "yes" a tutte le domande che 
possono essere poste durante l'aggiornamento. 
In alcuni casi pu essere preferibile usare
l'opzione <tt>--trivial-only</tt> invece di quella 
<tt>--assume-yes</tt> (equivalente a <tt>-y</tt>).

<footnote>
<p>Potreste anche utilizzare l'opzione <tt>--quiet</tt> (<tt>-q</tt>) 
per ridurre l'output di <prgn>apt-get</prgn>, in modo da non 
mostrare alcun output se non vengono installati pacchetti.</p>
</footnote></p></item>

<item>
<p>Configurate <prgn>cron</prgn> in modo che <prgn>debconf</prgn> 
non ponga nessuna domanda durante l'aggiornamento; in questo modo
l'aggiornamento non  interattivo.

<footnote>
<p>Bisogna ricordare che alcuni pacchetti potrebbero <em>non</em> 
utilizzare <prgn>debconf</prgn> e l'aggiornamento potrebbe 
bloccarsi a causa dei pacchetti che richiedono un input da 
parte dell'utente durante la configurazione.</p>
</footnote></p></item>

<item>
<p>Controllare i risultati dell'esecuzione di <prgn>cron</prgn>, 
che saranno spediti al superutente (a meno che <prgn>cron</prgn> 
non sia stato configurato diversamente con la variabile 
<tt>MAILTO</tt> nello script).</p></item>

</list></p>

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

<p>
Per eseguire questi compiti il sistema deve essere propriamente
configurato per scaricare gli aggiornamenti di sicurezza come
visto in <ref id="security-update">.</p>

<p>
Ad ogni modo questo procedimento non  consigliabile per 
<em>unstable</em> 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.
<em>Testing</em>  un po' pi <em>sicura</em> 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 <em>non</em> avere alcun 
aggiornamento di sicurezza disponibile in questo caso).</p>

<p>
Se avete una distribuzione mista, cio una distribuzione 
<em>stable</em> con alcuni pacchetti presi da 
<em>testing</em> o <em>unstable</em>, potete utilizzare i pinning 
o l'opzione <tt>--target-release</tt> di <prgn>apt-get</prgn> per
aggiornare <em>solo</em> quei pacchetti.

<footnote>
<p>Questo  un problema comune visto che molti utenti vogliono
utilizzare un sistema stable e prendere solo alcuni pacchetti da
<em>unstable</em> per disporre di funzionalit pi recenti. 
Questo bisogno nasce dal fatto che alcuni progetti evolvono 
pi rapidamente del tempo che passa tra due release 
<em>stable</em> di Debian.</p>
</footnote></p></sect1></sect>


<sect id="intrusion-detect"><heading>Pianificare la ricerca di intrusi</heading>

<p>
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.</p>

<p>
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.</p>

<p>
Quando viene scoperto un particolare attacco, molti di questi programmi
sono configurati per inviare un log con <prgn>syslogd</prgn> 
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.</p>

<p>
Un'interessante fonte di informazioni  il 
<url id="http://www.cert.org/tech_tips/intruder_detection_checklist.html" name="CERT lista delle intrusioni accertate (CERT's Intrusion Detection 
Checklist)">.</p>



<sect1><heading>Individuazione delle intrusioni sulla rete</heading>

<p>
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.</p>

<p>
<package>Snort</package>  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 <prgn>Snort</prgn> possiede la qualit 
di avvisare l'amministratore in tempo reale.
Potete usare <prgn>Snort</prgn> 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 
<tt>apt-get install snort</tt>,  importante rispondere alle 
domande e guardare il log.</p>

<p>
Il pacchetto <package>snort</package> 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.</p>

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

<p>
Potete testare questi tools usando <package>idswakeup</package> presente 
in Debian, esso  uno script di shell che genera dei falsi allarmi ed 
include molti comuni attacchi.</p></sect1>



<sect1><heading>Sistemi per individuare gli intrusi</heading>

<p>
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.</p>

<p>
<package>Tiger</package>  un vecchio strumento per scoprire
gli intrusi ed  ben integrato in Debian sin da Woody. 
<package>Tiger</package> 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 <prgn>tiger</prgn>  attiva ogni 
giorno e genera un rapporto che viene spedito all'amministratore 
concernente i possibili file compromessi del sistema.</p>

<p>
I programmi di controllo dei log come ad esempio 
<package>logcheck</package> possono essere usati 
per scovare dei tentativi di intrusione. Al riguardo 
potete leggere in <ref id="custom-logcheck">.</p>

<p>
In pi esistono programmi che controllano l'integrita dei file
systems (leggete in <ref id="check-integ">) che sono
abbastanza utili nella ricerca di anomalie in un sistema sicuro.
&Egrave; 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.</p></sect1></sect>


<sect><heading>Evitare i root-kit</heading>

<sect1 id="LKM"><heading>Moduli del kernel caricabili (LKM)</heading>

<p>
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.</p>

<p>
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 <file>procfs</file>, cosicch 
una copia del binario <prgn>ps</prgn>, ritenuta fedele, non fornirebbe, 
invece, informazioni precise sugli attuali processi in atto nel sistema.</p></sect1>



<sect1><heading>Scoprire i root-kit</heading>

<p>
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.</p>


<sect2 id="proactive"><heading>Difesa proattiva</heading>

<p>
Il vantaggio di questo tipo di difesa  che in primo luogo
previene danni al sistema. Una siffatta strategia consiste nel
motto <em>arrivateci per primi</em>, 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 <file>/dev/kmem</file>
(la memoria del kernel) per non essere scoperti.</p>

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

<list>

<item>
<p><package>kernel-patch-2.4-lsm</package> - LSM  il framework Linux 
Security Modules.</p></item>
<item>
<p><package>lcap</package> - una interfaccia user friendly per rimuovere la
<em>possibilit</em> (il controllo degli accessi a livello kernel) nel
kernel, rendendo il sistema pi sicuro. Per esempio, eseguendo 
<tt>lcap CAP_SYS_MODULE</tt>

<footnote>
<p>Ci sono oltre 28 possibilit, incluse:


<tt>CAP_BSET</tt>,
<tt>CAP_CHOWN</tt>,
<tt>CAP_FOWNER</tt>,
<tt>CAP_FSETID</tt>,
<tt>CAP_FS_MASK</tt>,
<tt>CAP_FULL_SET</tt>,
<tt>CAP_INIT_EFF_SET</tt>,
<tt>CAP_INIT_INH_SET</tt>,
<tt>CAP_IPC_LOCK</tt>,
<tt>CAP_IPC_OWNER</tt>,
<tt>CAP_KILL</tt>,
<tt>CAP_LEASE</tt>,
<tt>CAP_LINUX_IMMUTABLE</tt>,
<tt>CAP_MKNOD</tt>,
<tt>CAP_NET_ADMIN</tt>,
<tt>CAP_NET_BIND_SERVICE</tt>,
<tt>CAP_NET_RAW</tt>,
<tt>CAP_SETGID</tt>, 
<tt>CAP_SETPCAP</tt>,
<tt>CAP_SETUID</tt>,
<tt>CAP_SYS_ADMIN</tt>,
<tt>CAP_SYS_BOOT</tt>,
<tt>CAP_SYS_CHROOT</tt>,
<tt>CAP_SYS_MODULE</tt>,
<tt>CAP_SYS_NICE</tt>,
<tt>CAP_SYS_PACCT</tt>,
<tt>CAP_SYS_PTRACE</tt>,
<tt>CAP_SYS_RAWIO</tt>,
<tt>CAP_SYS_RESOURCE</tt>,
<tt>CAP_SYS_TIME</tt> e
<tt>CAP_SYS_TTY_CONFIG</tt>. 

Tutte queste possono essere disattivate per irrobustire il kernel.</p>
</footnote>

si rimuover la possibilit di caricare moduli (anche per l'utente root).

<footnote>
<p>Non si ha bisogno di installare <package>lcap</package> per fare 
questo, ma risulta pi semplice che impostare 
<file>/proc/sys/kernel/cap-bound</file> manualmente.</p>
</footnote>

Per maggiori informazioni sulle varie possibilit potete
controllare una sezione dello sviluppo del kernel di Jon Corbet's
<url id="http://lwn.net/1999/1202/kernel.php3" name="Kernel development">
sezione in LWN (dicembre 1999).</p></item>

</list></p>

<p>
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 <file>.config</file>. 
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.</p></sect2>


<sect2><heading>Difesa reattiva</heading>

<p>
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,
<file>System.map</file>. Ovviamente, una difesa reattiva si limiter ad
avvisare l'amministratore di sistema dopo che il sistema  gi
stato compromesso.</p>

<p>
Il controllo contro alcuni rootkit in Debian pu essere realizzato
con il pacchetto <package>chkrootkit</package>. Il programma 
<url id="http://www.chkrootkit.org" name="Chkrootkit"> ricerca 
le firme di svariati rootkit noti sul sistema ma non  certo un 
test definitivo.</p>

<p>
Un altro tool d'aiuto  
<url id="http://www.s0ftpj.org/en/site.html" name="KSTAT">
(Kernel Security Therapy Anti Trolls) del gruppo S0ftproject.
KSTAT controlla l'area di memoria del kernel (<file>/dev/kmem</file>) alla
ricerca di informazioni che riguardano l'host obiettivo, in modo da
assistere l'amministratore di sistema a trovare e rimuovere LKM
maliziosi.</p></sect2></sect1></sect>


<sect><heading>Si pu fare... &mdash; idee geniali/paranoiche</heading>

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

<list>

<item>
<p>Divertirsi con i Pluggable Authentication Modules (PAM - moduli per
l'autenticazione inseribili): come riportato nell'articolo su PAM, in
Phrack 56, il loro aspetto pi simpatico  che "l'unico limite  ci che 
si riesce a pensare". Ed  vero! S'immagini un'autenticazione di root
possibile solo mediante impronta digitale o scansione oculare o tessera
magnetica cifrata (ma perch usare la congiunzione "O", invece che la "E"?)</p></item>

<item>
<p>Registrazione dei log "fascista" - per contrasto verso tutte le precedenti
discussioni sulla "registrazione di log leggera": se si vuole una
registrazione di log degna di tal nome, basta spedire tutti i log ad una
stampante con carta a modulo continuo. Sembra un espediente buffo, ma 
sicuro e al riparo da manomissioni e cancellazioni.</p></item>

<item>
<p>Distribuzione su CD: idea davvero semplicissima a realizzarsi, d una
sicurezza abbastanza buona; basta creare una distribuzione Debian ben
corazzata, con regole di firewall appropriate, convertirla in immagine ISO
inizializzabile e schiaffarla su un CD-Rom, cos da avere una distribuzione
di sola lettura, con circa 600 MB di spazio per i vari servizi. Per gli
intrusi  impossibile ottenere l'accesso al sistema in lettura e scrittura
e qualsiasi cambiamento essi riescano a operare pu essere annullato con la
reinizializzazione del sistema.</p></item>

<item>
<p>Disabilitare le funzionalit tramite modulo: come gi visto, quando, 
durante la sua compilazione, si impedisce l'uso dei moduli del kernel, 
molte porte segrete basate su di esso non possono essere sfruttate, 
perch, nella maggioranza dei casi, si fondano sull'installazione 
di moduli del kernel modificati.</p></item>

<item>
<p>Registrazione dei log tramite cavo seriale (collaborazione di Gaby
Schilders): finch i server avranno porte seriali, si potr dedicare un
sistema alla registrazione dei log di un certo numero di server. Tale
sistema sar fuori dalla rete, ma connesso ai server per mezzo di una
multipresa per porte seriali (Cyclades o simili). Ora che tutti i server
registreranno verso le loro porte seriali, in sola scrittura, baster
connettere un masterizzatore di CD/DVD, sul quale trasferire i file di
registrazione, appena essi giungano a riempire la capacit del supporto.
Se solo facessero dei masterizzatori con autocommutatori...! Non  un modo
di fare copie "dure" come la registrazione diretta a mezzo stampante, ma
pu gestirne volumi pi consistenti - e stoccare CD-Rom richede meno spazio.</p></item>

<item>
<p>Cambiare gli attributi dei file usando <prgn>chattr</prgn> 
(tratto da Tips-HOWTO, di Jim Dennis): dopo una semplice installazione 
e una configurazione iniziale, potete usare il programma <prgn>chattr</prgn> 
con l'attributo <tt>+i</tt>, per far si che i file non possano essere 
modificati (ossia, cancellati, rinominati, collegati o riscritti). 
&Egrave; bene impostare questo attributo su tutti i file delle
cartelle <file>/bin</file>, <file>/sbin/</file>,
<file>/usr/bin</file>, <file>/usr/sbin</file>, <file>/usr/lib</file>
e sui file del kernel in root. Si possono anche copiare i tutti file 
di <file>/etc/</file>, con <prgn>tar</prgn> o altro programma
simile e classificare l'archivio come immutabile.</p>

<p>
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 <prgn>rm -fr</prgn>; si pu fare comunque ancora 
molto danno ai propri dati &mdash; ma le librerie e i binari 
saranno PIU' SICURI!</p>

<p>
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 
<em>non fornisca comandi arbitrari di shell</em>.</p>

<p>
Un inconveniente di questa strategia sorge in fase di costruzione e
installazione di vari binari di sistema, dal momento che impedisce al
comando <prgn>make install</prgn> la sovrascrittura dei file. 
Quando ci si scorda di leggere il Makefile e di cambiare con 
<prgn>chattr -i</prgn> i file da sovrascrivere (e le cartelle in cui 
si desidera aggiungerli), il comando make fallisce; bisogna lanciare 
<prgn>chattr</prgn> 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.</p>

<p>
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
<prgn>apt-get update</prgn>.</p></item>

</list></p>


<sect1><heading>Costruirsi una honeypot ("trappola al miele")</heading>

<p>FIXME: Serve maggiore materiale specifico per Debian</p>

<p>
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.</p>

<p>
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 <ref id="log-alerts">), 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:

<list>

<item>
<p>La tecnologia di firewall che si impiegher (fornita dal kernel Linux).</p></item>
<item>
<p><package>syslog-ng</package>, utile per mandare log dalla trappola ad
un server remoto di syslog.</p></item>
<item>
<p><package>snort</package>, per impostare la cattura dell'intero traffico 
in entrata nella trappola e rilevare gli attacchi.</p></item>
<item><p><package>osh</package>, 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).</p></item>
<item>
<p>Ovviamente, tutti i demoni che si useranno per il server-trappola
(ricordarsi di <em>non proteggerlo</em>).</p></item>
<item>
<p>Il Deception Toolkit (equipaggiamento per la frode), che usa 
l'inganno per respingere gli attacchi.
Homepage: <url id="http://www.all.net/dtk/" name="Deception Toolkit"></p></item>
<item>
<p>Verificatori di integrit (vedete <ref id="check-integ">) ed 
il Coroner's Toolkit (<package>tct</package> - gli "Strumenti del 
Patologo"), per fare i controlli post-attacco.</p></item>

</list></p>

<p>
Maggiori informazioni sulla costruzione di honeypot si possono
trovare nell'eccellente articolo di Lanze Spitzner 
<url id="http://www.net-security.org/text/articles/spitzner/honeypot.shtml" name="To Build a Honeypot">, (costruire una honeypot), - della serie "conosci i tuoi nemici" o in <url id="http://www.zdnetindia.com/techzone/resources/security/stories/7601.htm" name="Building your own honeypot"> (costruirsi la propria honeypot), 
di David Raikow.
Inoltre, l'<url id="http://project.honeynet.org/" name="Honeynet Project">
offre informazioni preziose sul modo di costruire queste trappole e 
controllare gli attacchi rivolti contro di esse.</p></sect1></sect></chapt>