<chapt>Prima della compromissione


<sect id="keep-secure">Mantenere sicuro il proprio sistema

<p>Dovreste sempre sforzarvi di mantenere il vostro sistema sicuro
controllandone l'uso che ne viene fatto e le sue possibili
vulnerabilità; tali vulnerabilità andrebbero poi eliminate
installando gli aggiornamenti di sicurezza non appena sono
disponibili. Anche se siete convinti della robustezza del
vostro sistema appena installato, va ricordato che la sicurezza di
un sistema si degrada nel tempo, poiché potrebbero venire scoperte
nuove vulnerabilità nei servizi offerti dal proprio sistema agli
utenti, anche questi ultimi potrebbero compromettere la sicurezza
del sistema per scarse cognizioni tecniche (ad esempio,
potrebbero accedere al sistema  da remoto usando un
protocollo di comunicazione non cifrato, o usando delle password
banali e dunque facili da indovinare) o perché mirano esplicitamente
a compromettere la sicurezza del sistema (per esempio, installano
dei servizi aggiuntivi sul sistema usando  le risorse del sistema
che sono state loro concesse).


<sect1 id="track-vulns">Mantenersi aggiornati sulle vulnerabilità di sicurezza

<p>Sebbene molti amministratori di sistema vengano a conoscenza di 
una vulnerabilità del sistema solo quando un aggiornamento diventa
disponibile, sarebbe meglio venire a conoscenza delle vulnerabilità
di sicurezza il prima possibile, per prevenire gli attacchi,
introducendo delle contromisure di emergenza. Ciò è particolarmente
utile nel caso in cui stiate amministrando un sistema esposto (ossia
connesso ad Internet) che fornisce un servizio. In tal caso gli
amministratori di sistema dovrebbero controllare regolarmente delle
fonti di informazioni fidate relative alla sicurezza, così da
venire a conoscenza il prima possibile se un servizio critico del
sistema (o che comunque potrebbe avere degli effetti indesiderati
su di esso) è affetto da vulnerabilità.

<p>Tali fonti comprendono, di solito, la mailing list degli annunci,
il sito web del progetto, o i sistemi di tracciamento dei bachi usati
dagli sviluppatori per un dato sottosistema del progetto. Ad esempio,
gli utenti del software Apache dovrebbero controllare regolarmente
l'<url id="http://httpd.apache.org/security_report.html"
name="elenco delle vulnerabilità"> di Apache ed iscriversi alla lista
degli <url id="http://httpd.apache.org/lists.html#http-announce"
name="Annunci dell'Apache Server">.

<p>Al fine di tenere traccia di tutte le vulnerabilità presenti nella
distribuzione Debian, il Team per la Sicurezza di Debian fornisce un
<url id="http://security-tracker.debian.net/" name="archivio"> in cui
vengono elencate tutte le vulnerabilità non ancora corrette presenti
nei pacchetti Debian. Le informazioni presenti in tale archivio
vengono ottenute ed aggiornate mediante ricerche su vari fonti di
pubblico dominio ed includono vulnerabilità note che sono disponibili
nelle banche dati pubbliche sulla sicurezza oppure nel sistema di
gestione dei bachi Debian (<url id="http://www.debian.org/Bugs/"
name="Debian's Bug Tracking system">). Gli amministratori di sistema
possono controllare le vulnerabilità di sicurezza passate e
presenti nella distribuzione
<url id="http://security-tracker.debian.net/tracker/status/release/stable"
name="stable">,
<url id="http://security-tracker.debian.net/tracker/status/release/oldstable"
name="oldstable">,
<url id="http://security-tracker.debian.net/tracker/status/release/testing"
name="testing"> o
<url id="http://security-tracker.debian.net/tracker/status/release/unstable"
name="unstable">.

<p>L'archivio ha un motore di ricerca (si possono effettuare delle
ricerche in base al nome <url id="http://cve.mitre.org/" name="CVE">
ed al nome del pacchetto) ed alcuni strumenti  (come ad esempio
<package>debsecan</package>; vedete al riguardo <ref id="debsecan">)
usano tale banca dati per fornire informazioni sulle vulnerabilità 
ancora aperte (cioè, per le vulnerabilità per cui ancora non esiste 
una soluzione) presenti su un dato sistema.

<p>Un amministratore di sistema scrupoloso dovrebbe usare tali 
informazioni per determinare le falle nella sicurezza del sistema che
sta amministrando, determinare la pericolosità di tali falle ed
applicare (se possibile) delle contromisure temporanee fintantoché 
non venga rilasciato un aggiornamento di sicurezza che risolva il 
problema.

<p>I problemi relativi alla sicurezza, individuati per le versioni di
Debian di cui il Team Debian per la Sicurezza si occupa ancora, 
verranno pubblicati negli avvisi Debian per la sicurezza e i conseguenti
aggiornamenti saranno disponibili per tutti gli utenti (vedete al
riguardo <ref id="keep-up-to-date">). Una volta che gli aggiornamenti
di sicurezza vengono pubblicati, l'avviso corrispondente viene
cancellato dall'archivio, ma è ancora possibile ottenere dettagli
sulla vulnerabilità di sicurezza, identificata col suo nome CVE,
usando la <url id="http://www.debian.org/security/crossreferences"
name="tabella dei riferimenti incrociati"> che collega gli avvisi
Debian ai dati sulle vulnerabilità forniti dal CVE.

<p>Notate, comunque, che il Team per la Sicurezza di Debian Testing
gestisce solo vulnerabilità note al pubblico. In alcune occasione
invece il Team Debian per la Sicurezza (fate attenzione che sono due
entità separate) potrebbe preparare degli Avvisi Debian sulla
Sicurezza (l'acronimo inglese di tali documenti è DSA) in base ad
informazioni riservate (che gli sono state fornite ad esempio da
mailing list private del produttore o da alcuni dei manutentori del
software in via confidenziale). Pertanto alcuni problemi di
sicurezza, sebbene descritti e risolti tramite un DSA, potrebbero
non essere presenti nell'archivio.



<sect1 id="keep-up-to-date">Aggiornare continuamente il sistema

<p>Bisognerebbe eseguire spesso gli aggiornamenti per la sicurezza.
La maggior parte degli exploit deriva da vulnerabilità conosciute
a cui non è 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 su
sicurezza e riservatezza all'IEEE, nel 2001. Gli aggiornamenti
vengono descritti in <ref id="security-update">.



<sect2>Controllo manuale degli aggiornamenti di sicurezza disponibili

<p>Debian ha uno strumento apposito per verificare se un
sistema deve essere aggiornato, ma molti utenti vorranno
semplicemente controllare manualmente se sono disponibili
aggiornamenti di sicurezza per il loro sistema.

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

<example>
# apt-get update
# apt-get upgrade -s
[ ... review packages to be upgraded ... ]
# apt-get upgrade
# checkrestart
[ ... restart services that need to be restarted ... ]
</example>

<p>e riavviare quei servizi le cui librerie sono state aggiornate.
Notate: leggete in <ref id="security-update"> per altre informazioni
sugli aggiornamenti delle librerie (e del kernel).

<p>La prima riga scaricherà l'elenco 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 dovrebbero essere 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>In questo esempio, si vede come il sistema necessiti di un
aggiornamento con i nuovi pacchetti <package>cvs</package> e
<package>cupsys</package> trovati nell'archivio dei pacchetti
del ramo sicurezza di <em>woody</em>; se volete capire perché
tali pacchetti siano necessari, puntate il vostro browser
verso <url id="http://security.debian.org"> e controllate i più
recenti Avvisi sulla Sicurezza di Debian che sono stati pubblicati
in merito a questi pacchetti. In questo caso i relativi DSA sono
<url id="http://www.debian.org/security/2003/dsa-233" name="DSA-233"> (per <package>cvs</package>) e
<url id="http://www.debian.org/security/2003/dsa-232" name="DSA-232"> (per <package>cupsys</package>).

<p>Notate che il sistema dovrà essere riavviato nel caso vi sia
stato un aggiornamento del kernel.





<sect2 id="update-desktop">Controllo degli aggiornamenti dal Desktop

<p>Dalla versione 4.0, <em>lenny</em>, Debian fornisce, in
un'installazione predefinita, il programma
<package>update-notifier</package>. Si tratta di un'applicazione per
GNOME che viene avviata al momento dell'ingresso nel proprio ambiente
Desktop e può essere usata per tenere traccia degli aggiornamenti
disponibili per il proprio sistema ed installarli. A questo scopo usa
<package>update-manager</package>.

<p>In un sistema stabile gli aggiornamenti sono disponibili solo
quando viene rilasciata una patch di sicurezza o al momento dei
nuovi rilasci. Di conseguenza, se il sistema è configurato
per ricevere gli aggiornamenti di sicurezza, come descritto
in <ref id="security-update"> e c'è un'istanza di cron che
aggiorna le informazioni dei pacchetti, verrete informati attraverso
un'icona dell'area di notifica del desktop.

<p>La notifica non è intrusiva e gli utenti non sono obbligati ad
installare gli aggiornamenti. Dall'icona di notifica un utente del
desktop (con la password di amministratore) può accedere ad una
semplice interfaccia grafica per vedere quali sono gli aggiornamenti
disponibili ed installarli.

<p>Questa applicazione funziona controllando il database dei
pacchetti e comparando il sistema con il suo contenuto. Se il
database dei pacchetti viene aggiornato periodicamente attraverso
un'istanza di <prgn>cron</prgn>, allora il contenuto del database
sarà più nuovo dei pacchetti installati nel sistema e quindi una
applicazione lo notificherà.

<p><prgn>Apt</prgn> installa un compito
(<file>/etc/cron.d/apt</file>) che verrà eseguito a seconda della
configurazione di Apt (più nello specifico <em>APT::Periodic</em>).
Nell'ambiente GNOME questo valore di configurazione può essere
modificato in Sistema &gt; Amministrazione &gt; Sorgenti
Software &gt; Aggiornamenti, o eseguendo
<prgn>/usr/bin/software-properties</prgn>.

<p>Se il sistema è configurato per scaricare la lista dei pacchetti
quotidianamente ma non per scaricare i pacchetti stessi, il file
<file>/etc/apt/apt.conf.d/10periodic</file> dovrebbe avere questo
aspetto:

<example>
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
</example>

<p>Potete usare un diverso compito per cron, come quello installato
da <package>cron-apt</package> (vedete in <ref id="cron-apt">). Si
può anche controllare manualmente ed usare sempre questa applicazione.

<p>Gli utenti dell'ambiente desktop KDE probabilmente preferiranno
invece installare <package>adept</package> e
<package>adept-notifier</package>, che offrono un simile servizio ma
non sono parte dell'installazione standard.





<sect2 id="cron-apt">Controllo automatico degli aggiornamenti con
cron-apt

<p>Un altro metodo per l'aggiornamento automatico per la sicurezza
è l'uso di <package>cron-apt</package>. Questo pacchetto fornisce
uno strumento per aggiornare il sistema ad intervalli regolari 
(mediante l'impiego di un job cron) e può anche essere configurato 
per spedire delle mail all'amministratore usando il sistema di 
trasporto locale. 
Nella configurazione base si limiterà ad aggiornare la lista dei
pacchetti e scaricarne di nuovi, ma può essere configurato per
installare automaticamente i nuovi aggiornamenti.

<p>Se volete aggiornare automaticamente il vostro sistema (anche
solo scaricandone i pacchetti), controllate 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 una fonte fidata.

<p>Ulteriori informazioni sono disponibili presso il sito
<url id="http://www.debian-administration.org/articles/162"
name="Debian Administration">.




<sect2 id="debsecan">Individuazione automatica dei problemi di
                     sicurezza con debsecan

<p>Il programma <prgn>debsecan</prgn> dà una valutazione sulla
sicurezza del sistema elencando sia gli aggiornamenti di sicurezza
non effettuati che le falle di sicurezza presenti nel sistema. A
differenza di <package>cron-apt</package>, che fornisce solo
informazioni relative agli aggiornamenti di sicurezza disponibili,
questo strumento riceve le informazioni dalla banca dati sulle
vulnerabilità di sicurezza mantenuta aggiornata dal Team Debian per
la Sicurezza, che include anche informazioni sulle vulnerabilità per
cui non è ancora disponibile un aggiornamento di sicurezza.
Pertanto, è più efficace nell'aiutare gli amministratori di sistema
ad individuare le falle nella sicurezza del proprio sistema (come
descritto precedentemente in <ref id="track-vulns">).

<p>Successivamente all'installazione, il pacchetto
<package>debsecan</package>, qualora l'amministratore di sistema
glielo permetta, assegnerà un compito a cron che eseguirà
regolarmente debsecan ed invierà i risultati della scansione ad un
certo utente, qualora debsecan trovi un pacchetto vulnerabile.
Debsecan scaricherà inoltre informazioni da internet. Il sito su cui
è presente la banca dati delle vulnerabilità di sicurezza viene
scelto in fase di installazione; le risposte fornite alle domande
effettuate durante l'installazione vengono salvate nel file
<file>/etc/default/debsecan</file>. In tale file si può anche
specificare che sistemi non connessi ad internet scarichino da un
mirror sulla rete locale della banca dati di sicurezza; in tal caso,
solo l'host su cui è il mirror accederà alla banca dati su internet.


<p>Notate, comunque, che il Team Debian per la sicurezza esamina molte
vulnerabilità, incluse quelle a basso rischio che potrebbero essere
ignorate e non essere mai risolte tramite un aggiornamento di
sicurezza; alcune vulnerabilità che inizialmente sono state
identificate come riguardanti anche Debian, potrebbero, in futuro,
dopo ulteriori accertamenti, essere invece completamente irrilevanti
per Debian. <prgn>Debsecan</prgn> elenca tutte queste vulnerabilità,
tendendo a fornire dei risultati molto più lunghi da leggere degli
altri strumenti descritti in precedenza.

<p>Ulteriori informazioni sono disponibili sul
<url id="http://www.enyo.de/fw/software/debsecan/"
name="sito dell'autore">.







<sect2>Altri metodi per effettuare aggiornamenti per la sicurezza

<p>Un altro strumento utile è <package>apticron</package>, che, come
<package>cron-apt</package>, controlla se vi sono aggiornamenti ed in
caso positivo invia una email all'amministratore di sistema.  Per
ulteriori informazioni su <package>apticron</package> potete
consultare il sito relativo
<url id="http://www.debian-administration.org/articles/491"
name="all'amministrazione di Debian">.


<p>Potreste anche prendere in considerazione
<url id="http://clemens.endorphin.org/secpack/" name="secpack"> che
è un programma non incluso in Debian per scaricare ed installare
aggiornamenti di sicurezza da security.debian.org; il meccanismo di
controllo delle firme digitali di <package>secpack</package> è stato
scritto da Fruhwirth Clemens.   Un  altro strumento interessante è
il modulo per Nagios
<url id="http://www.unixdaemon.net/nagios_plugins.html#check_debian_packages"
name="check_debian_updates.sh"> creato da  Dean Wilson.





<sect1>Evitare di usare il ramo instabile

<p>A meno che non vogliate dedicare tempo a riparare i pacchetti da
soli quando sorge una vulnerabilità, <em>non</em> dovreste usare il
ramo instabile di Debian per sistemi in produzione. La principale
ragione per questo è che non ci sono aggiornamenti di sicurezza per
<em>unstable</em>.

<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 a nuove applicazioni
che vengono incluse senza aver passato un collaudo approfondito.

<p>Per quanto riguarda l'eseguire aggiornamenti di sicurezza nel ramo
<em>unstable</em>, dovreste aggiornare completamente alle nuove
versioni (che vengono aggiornate più dei pacchetti in questione).
Sebbene ci siano alcune eccezioni, solamente le patch di sicurezza
vengono riportate nel ramo <em>stable</em>. L'idea di fondo
è che tra gli aggiornamenti non venga aggiunto <em>nuovo codice</em>,
ma che vengano solamente risolti i problemi importanti per la
sicurezza.

<p>Notate che, comunque potete ancora usare l'archivio delle
vulnerabilità di sicurezza (come descritto in <ref id="track-vulns">)
per scoprire quali vulnerabilità riguardino la versione di Debian che
state usando.






<sect1 id="security-support-testing">Supporto alla sicurezza per il ramo testing

<p>Se usate il ramo <em>testing</em>, ci sono alcuni aspetti da
tenere in considerazione sulla disponibilità degli aggiornamenti
di sicurezza:

<list>

<item>Quando è pronta una correzione di sicurezza, il Team per la Sicurezza
appronta il backport della patch a <em>stable</em> (in quanto stable
di solito è indietro di qualche versione, minore o maggiore). I
manutentori del pacchetto sono responsabili della preparazione dei
pacchetti per il ramo <em>unstable</em>, di solito basati su una
letteralmente nuova versione. A volte le modifiche avvengono quasi
in contemporanea e altre volte uno dei due rami riceve la correzione
di sicurezza prima dell'altro. I pacchetti per la distribuzione
<em>stable</em> sono soggetti ad un controllo più approfondito di
quelli per <em>unstable</em>, in quanto quest'ultima contiene
perlopiù la versione più recente (che potrebbe includere nuovi bug
ancora sconosciuti).
<item>Gli aggiornamenti di sicurezza sono normalmente disponibili per
il ramo <em>unstable</em> quando il manutentore del pacchetto crea un
nuovo pacchetto e per il branch <em>stable</em> quando il Team per la 
Sicurezza fa un nuovo caricamento e pubblica un DSA. Notate che 
nessuno di questi due cambia il ramo di <em>testing</em>.
<item>Se nessun (nuovo) errore viene scoperto nella versione 
<em>unstable</em> del pacchetto, questo si sposta nel ramo 
<em>testing</em> dopo diversi giorni. Il tempo che occorre per questo 
procedimento di solito è dieci giorni, anche se dipende dalla 
priorità di caricamento del cambiamento e se il pacchetto viene 
bloccato dall'ingresso nel ramo <em>testing</em> dalle sue 
relazioni di dipendenza. Notate che se il pacchetto viene bloccato
dall'entrata in <em>testing</em> la priorità di caricamento non 
modificherà il tempo che gli occorre per entrare.

</list>

<p>Questo comportamento può cambiare in base allo stato di rilascio
della distribuzione. Quando un rilascio è quasi imminente, il Team 
per la Sicurezza o i manutentori del pacchetto possono fornire degli
aggiornamenti direttamente al ramo <em>testing</em>.

<p>Inoltre, il <url id="http://secure-testing-master.debian.net"
name="Team Debian per la Sicurezza"> può emettere avvisi di sicurezza
per Debian <em>testing</em> (Ndt: DTSA, da "Debian Testing Security
Advisories") per i pacchetti nel ramo <em>testing</em> se c'è bisogno
 immediato di correggere un problema di sicurezza e non si può
attendere la procedura standard (o questa è bloccata da qualche altro
pacchetto).

<p>Gli utenti che volessero usufruire di questo supporto devono 
aggiungere le seguenti righe al loro <file>/etc/apt/sources.list</file> 
(invece delle righe descritte in <ref id="security-update">):

<example>
    deb http://security.debian.org testing/updates main contrib non-free
# Questa riga permette di scaricare anche pacchetti in formato sorgente
    deb-src  http://security.debian.org testing/updates main contrib non-free
</example>

<p>Per ulteriori informazioni su questo supporto leggete 
<url id="http://lists.debian.org/debian-devel-announce/2006/05/msg00006.html" 
name="l'annuncio">. Questo supporto è iniziato ufficialmente nel 
<url id="http://lists.debian.org/debian-devel-announce/2005/09/msg00006.html" 
name="settembre 2005"> in un archivio separato ed in seguito è stato 
integrato nell'archivio principale per la sicurezza.





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

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

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

<list>

<item>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>Per decidere il pin ad una determinata versione di 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>FIXME: verificare se questa configurazione è corretta.

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

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

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

<item>Configurare <prgn>debconf</prgn> in modo che non ponga
nessuna domanda durante l'aggiornamento; in questo modo
l'aggiornamento non è interattivo<footnote>
          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.
</footnote>.

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

</list>

<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 verrà
eseguito manualmente se l'esecuzione di <prgn>cron</prgn>
mostrerà che il sistema deve essere aggiornato.

<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>Ad ogni modo questo procedimento non è consigliabile per
<em>unstable</em>, senza prima aver effettuato un'accurata analisi, perché
potrebbe rendere il 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>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 il
sistema del pinning o l'opzione <tt>--target-release</tt> di
<prgn>apt-get</prgn> per aggiornare <em>solo</em> quei
pacchetti che hanno subito variazioni<footnote>
          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 versioni <em>stable</em> di Debian.
</footnote>.



<sect id="periodic-integrity">Effettuate periodicamente dei controlli
sull'integrità del sistema

<p>Basandovi sulle informazioni che avete generato in fase di
installazione come metro di paragone, (ovvero l'istantanea descritta
in <ref id="snapshot">) dovreste essere in grado di controllare
l'integrità del sistema quando volete. Un controllo sull'integrità
del sistema sarà in grado di rilevare le modifiche su disco, effettuate
da un intruso o generate da errori dell'amministratore di
sistema.

<p>I controlli sull'integrità del sistema dovrebbero, se possibile,
essere effettuati con il sistema non in esecuzione<footnote>
          Un modo semplice di realizzare questa operazione è usare un
          Live CD, come ad esempio <url id="http://www.knoppix-std.org/"
          name="Knoppix Std">, che include degli strumenti per
          controllare l'integrità del sistema.
</footnote>,
quindi senza usare il sistema operativo che in quel momento è sotto
esame. Infatti, dei rootkit installati potrebbero aver corrotto
qualsiasi parte del sistema operativo in esame e quindi potreste
trovarvi di fronte a dei falsi negativi. La banca dati in cui viene
immagazzinata la fotografia del sistema dovrebbe inoltre essere 
memorizzata su un dispositivo che non consenta la riscrittura.

<p>Potreste pensare di voler fare dei controlli d'integrità a sistema
avviato (ossia, utilizzando il sistema operativo che state
controllando) usando uno qualsiasi dei sistemi di controllo
dell'integrità del filesystem disponibili, (descritti in
<ref id="check-integ">) se non avete la possibilità di spengere il
sistema. Comunque sia, dovreste assicurarvi che la banca dati usata
nel controllo dell'integrità del filesystem non sia scrivibile e che
gli strumenti di analisi che state usando (incluso il nucleo del
sistema operativo) non siano stati manomessi.

<p>Alcuni degli strumenti sono stati menzionati nella sezione sugli
strumenti per il controllo dell'integrità, ad esempio
<prgn>aide</prgn>, <prgn>integrit</prgn> o <prgn>samhain</prgn> sono
già predisposti per effettuare periodicamente dei controlli (nei
primi due casi si usa il crontab mentre <prgn>samhain</prgn> utilizza
un  demone indipendente) e possono avvisare l'amministratore  in vari
modi (in genere tramite  email, ma <prgn>samhain</prgn> può anche
inviare pagine web, avvisi mediante syslog o notifiche SNMP) qualora il
filesystem sia stato alterato.

<p>Naturalmente, se eseguite un aggiornamento per la sicurezza,
dovrete effettuare una nuova istantanea del sistema che fotografi
anche i cambiamenti legittimi avvenuti in seguito ad un aggiornamento
del sistema per la sicurezza.




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

<p>In Debian GNU/Linux sono presenti molti programmi che servono ad
individuare intrusi nel sistema, 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>Dovete 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>Quando viene scoperto un particolare attacco, molti di questi
programmi vengono configurati per inviare un log con
<prgn>syslogd</prgn> oppure per inviare una email all'amministratore
(le intestazioni delle email sono solitamente configurabili).
Un amministratore può accuratamente configurare questi strumenti
evitando così di ricevere allarmi per falsi positivi.
Inoltre è necessario fare attenzione ai sistemi di allarme dei
tentativi di intrusione, potrebbero rivelarsi inutili se vengono
generati il 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>Un'interessante fonte di informazioni è
l'<url id="http://www.cert.org/tech_tips/intruder_detection_checklist.html"
name="elenco del CERT delle intrusioni accertate (CERT's Intrusion Detection
Checklist)">.



<sect1>Individuazione delle intrusioni sulla rete

<p>Gli strumenti che controllano le intrusioni lo fanno sul traffico
di un segmento di rete e usano le informazioni come una sorgente di
dati. Specificatamente, vengono esaminati i pacchetti in rete e
viene controllato che abbiano un certificato valido.

<p><package>snort</package> è uno sniffer che scova gli attacchi
usando un dizionario di "firme" di precedenti attacchi.
Può rilevare una gran varietà di attacchi e scansioni, come:
buffer overflow, scansioni di porte stealth, 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 controllare alcuni sistemi sulla
vostra rete come pure solamente per controllare il vostro sistema.
<prgn>snort</prgn> dovrebbe essere installato su ogni router
per monitorare costantemente la rete di competenza. Potete installarlo col
comando <tt>apt-get install snort</tt> e dopo aver risposto alle
domande in fase di installazione, ve lo troverete già avviato.
Per uno strumento di sicurezza con più funzioni potreste voler dare
un'occhiata a <url id="http://www.prelude-ids.org" name="Prelude">.

<p>Il pacchetto <package>snort</package> presente in Debian possiede 
molte opzioni di sicurezza attivate in maniera predefinita.
Comunque potete anche personalizzare a vostro piacimento la
configurazione tenendo conto dei servizi attivi sulla 
vostra macchina. Potete altresì ricercare pacchetti addizionali 
specifici per un particolare servizio.

<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>Potete collaudare questi strumenti usando 
<package>idswakeup</package>, presente in Debian, è uno script di 
shell che genera dei falsi allarmi ed include molti comuni attacchi.



<sect1>Sistemi per individuare gli intrusi

<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><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 filesystem,
processi di comunicazione e qualsiasi altro possibile modo per
compromettere root. Sono presenti in questo pacchetto nuove
verifiche di sicurezza specifiche per Debian come: verifica MD5sum
dei file installati, localizzazione dei file che non appartengono
ai pacchetti e analisi dei processi in ascolto. L'installazione
predefinita di <prgn>tiger</prgn> prevede un'esecuzione giornaliera
e la generazione di un rapporto concernente la possibile
compromissione del sistema e la sua trasmissione all'amministratore.

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

<p>Inoltre esistono programmi che controllano l'integrita dei 
filesystem (vedete in <ref id="check-integ">) che sono
abbastanza utili nella ricerca di anomalie in un ambiente sicuro.
&Egrave; molto probabile che un vero intruso modifichi alcuni
file nel filesystem 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 filesystem.



<sect>Evitare i root-kit

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

<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 impiego sta nella
possibilità di aggiungere ulteriori dispositivi, come per
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)) per aprire porte all'insaputa dell'amministratore
(le cosiddette "back door") nei sistemi GNU/Linux.

<p>Le porte segrete aperte tramite LKM sono più sofisticate e meno
rilevabili rispetto ai tradizionali root-kit.
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.



<sect1>Scoprire i root-kit

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


<sect2 id="proactive">Difesa preventiva

<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 atto a
proteggere il sistema da altri LKM malevoli. Una seconda
strategia è quella di rimuovere completamente la possibilità che il
kernel possa caricare dei moduli. Notate, 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>Debian GNU/Linux ha alcuni pacchetti che possono essere utilizzati
per realizzare una difesa preventiva:

<list>

<item><package>lcap</package> - Un'interfaccia amichevole per
rimuovere la <em>capacità</em> (con il controllo degli accessi
a livello kernel) nel kernel, rendendo il sistema più sicuro.
Per esempio, eseguendo 
<tt>lcap CAP_SYS_MODULE</tt><footnote>
        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>.

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

rimuoverete la possibilità di caricare moduli (anche per l'utente 
root)<footnote>
Non avete bisogno di installare <package>lcap</package> per fare
questo, ma risulta più semplice che impostare
<file>/proc/sys/kernel/cap-bound</file> manualmente.
</footnote>.

Potete trovare altre informazioni, per quanto datate,
nell'articolo curato da Jon Corbet's, in
<url id="http://lwn.net/1999/1202/kernel.php3"
name="Kernel development">, sezione di LWN (dicembre 1999).

</list>

<p>Se non avete affatto bisogno di molte delle caratteristiche
del kernel sul vostro sistema GNU/Linux, potete disabilitare il
supporto ai moduli caricabili durante la fase di configurazione
del kernel stesso. Per disabilitare questo supporto, impostate
CONFIG_MODULES=n durante la fase di configurazione per la
compilazione del vostro kernel, oppure nel file
<file>.config</file>.
Questo annullerà i tentativi dei root-kit LKM, ma perderete
questa potente caratteristica del kernel Linux. Inoltre,
disabilitare il supporto per i moduli caricabili a volte potrebbe
appesantire troppo il kernel, rendendo il supporto ai moduli
indispensabile.


<sect2>Difesa reattiva

<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>Il controllo contro alcuni root-kit 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 root-kit noti sul sistema ma non è certo un
test definitivo.




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

<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>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! Immaginate 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"?).

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

<item>Distribuzione su CD: idea davvero semplicissima da 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
in 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
ma qualsiasi cambiamento essi riescano ad operare può essere annullato con la
reinizializzazione del sistema.

<item>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 essi non possono essere sfruttate,
perché, nella maggioranza dei casi, si fondano sull'installazione
di moduli del kernel modificati.

<item>Registrazione dei log tramite cavo seriale (collaborazione di
Gaby Schilders): finché i server avranno porte seriali, si potrà
dedicare un sistema per la 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, fintantoché non 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 richiede meno 
spazio.

<item>Cambiare gli attributi dei file usando <prgn>chattr</prgn> 
(tratto dal Tips-HOWTO, di Jim Dennis): dopo una semplice
installazione ed 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). Da considerare la possibilità di
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. Potreste anche copiare tutti i file
in <file>/etc/</file>, con <prgn>tar</prgn> od un altro programma
simile, e classificare l'archivio come immutabile.

<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>;
potete comunque arrecare ancora molti danni ai vostri dati &mdash;
ma le librerie ed i binari saranno più sicuri.

<p>Inoltre questa strategia rende quasi impossibile, o perlomeno più
difficile, sfruttare attacchi alla sicurezza del tipo denial of
service (DoS - rifiuto di fornire servizi), miranti a sovrascrivere
un file attraverso l'azione di qualche programma con SETUID attivo,
perché <em>fornisca un'arbitraria shell di root</em>.

<p>Un inconveniente di questa strategia sorge in fase di costruzione ed
installazione dei 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 del <prgn>chattr -i</prgn>
passato ai file da sovrascrivere (e le cartelle in cui
si desidera aggiungerli), il comando make fallisce; bisogna lanciare
<prgn>chattr</prgn> e poi farlo ripartire. Potreste anche approfittare
dell'occasione per sbarazzarvi di binari e librerie vecchie,
spostandole in una cartella <file>.old/</file> o in un archivio tar, 
per esempio.

<p>Notate 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, potreste
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>.

<item>Potreste voler alterare un cavo UTP tagliando 2 o 4 fili in
maniera che il traffico di rete possa scorrere in una sola direzione.
Successivamente potreste inviare ad un'altra macchina, tramite dei
pacchetti UDP, i log di sistema.


</list>


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

<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. Apprendendo 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>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<footnote>
          Di solito si usa un bridge firewall in modo tale che il
          firewall stesso non sia rilevabile, vedete in
          <ref id="bridge-fw">.
</footnote>

ed un qualsiasi rilevatore di intrusioni nella rete, collegarlo ad
Internet e aspettare. In caso di sfruttamento del sistema, occorre
essere ben certi di venire avvisati per tempo (vedete in
<ref id="log-alerts">), sì da poter assumere le opportune
contromisure e bloccare la compromissione quando se ne
conosca abbastanza. Questo è un elenco di pacchetti e di aspetti
da valutare durante l'impostazione di una honeypot:

<list>

<item>La tecnologia di firewall che si impiegherà (fornita dal kernel Linux).
<item><package>syslog-ng</package>, utile per spedire log dalla trappola ad
un server remoto di syslog.
<item><package>snort</package>, per impostare la cattura dell'intero traffico
di rete in entrata nella trappola e rilevare gli attacchi.
<item><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).

<item>Naturalmente, tutti i demoni che si useranno per il
server-trappola. Analizzando la situazione, a seconda del tipo di
attaccante, dovrete decidere se irrobustire la vostra trappola, se
mantenere gli aggiornamenti con le patch per la sicurezza o se
<em>non farlo</em>.

<item>Verificatori di integrità (vedete in <ref id="check-integ">) ed
il Coroner's Toolkit (Gli strumenti del patologo) nel pacchetto
<package>tct</package>, per fare i controlli dopo aver subito un
attacco.

<item>Potreste voler usare <package>honeyd</package> e
<package>farpd</package> per mettere in piedi una finta rete che
ascolterà su indirizzi IP non assegnati a nessun sistema sulla
vostra rete e con connessioni in arrivo mediante script che simulano
dei servizi di rete. Potreste anche voler dare un'occhiata a
<package>iisemulator</package>.

<item><package>tinyhoneypot</package> vi permetterà di creare un
semplice server con servizi di rete simulati.


</list>

<p>Se non è possibile utilizzare dei sistemi indipendenti per
costruire la trappola e la rete dei sistemi di protezione,
controllate che non siano disponibili le tecnologie di
virtualizzazione disponibili in <prgn>xen</prgn> o
<prgn>uml</prgn> (User-Mode-Linux). Se avete optato
per questa strada avrete bisogno di patch per il kernel come
<package>kernel-patch-xen</package> o
<package>kernel-patch-uml</package>.


<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". Inoltre, l'<url id="http://project.honeynet.org/"
name="Honeynet Project"> offre informazioni preziose sul modo in cui
progettare queste trappole ed analizzare gli attacchi rivolti contro 
di esse.

</chapt>



