<chapt>Prima e durante l'installazione

<sect id="bios-passwd">Scegliere una password per il BIOS

<p>
Prima d'installare qualsiasi sistema operativo sul vostro computer, è 
preferibile inserire una password al BIOS.  Dopo l'installazione, non
appena attiverete l'avvio dall'hard disk, è preferibile 
impostare la sequenza d'avvio da BIOS disabilitando l'avvio 
da floppy, da cdrom e dalle altre periferiche che non dovrebbero 
avviare il computer.  Altrimenti ad un cracker basterebbe solo avere
l'accesso fisico al computer ed un disco di boot per accedere 
al sistema.

<p>
Disabilitare l'avvio se non viene inserita una password è ancora meglio.
Questo può essere molto efficace se avete un server, visto che
non viene riavviato frequentemente.
Il  lato negativo di questa precauzione è che il riavvio della macchina 
richiede l'intervento umano e può essere problematico se la 
macchina non è facilmente accessibile.

<p>
Notate: molti BIOS hanno una master password (o password universale), 
che può essere facilmente rinvenuta, senza contare che 
inoltre esistono delle applicazioni che sono in grado di recuperare la 
password del BIOS rapidamente.
Corollario: si deduce facilmente  che non dipende, principalmente, da 
queste precauzioni la sicurezza dell'accesso al sistema.




<sect>Partizionare il sistema



<sect1>Scegliere uno schema di partizionamento intelligente


<p>Scegliere uno schema di partizionamento intelligente dipenderà 
da come verrà usata la macchina.
&Egrave; buona regola creare delle partizioni sufficientemente grandi e 
prestare attenzione ai seguenti fattori:

<list>

<item>
Ad ogni albero di directory sul quale un'utente ordinario 
ha diritti di scrittura come ad esempio <file>/home</file>  
<file>/tmp</file> e <file>/var/tmp</file> andrebbe riservata una 
partizione separata. Questo riduce il rischio che un'attacco DoS 
saturi il mount point "/" rendendo così il sistema inutilizzabile
(Notate: questo non è esattamente  vero in quanto esiste sempre una 
parte di spazio riservato a root che un utente ordinario
non può riempire) ed in più previene attacchi del tipo hardlink
<footnote>
Un buon esempio di questo tipo di attacchi, portati utilizzando
<file>/tmp</file>, è riportato in dettaglio in 
<url id="http://www.hackinglinuxexposed.com/articles/20031111.html"
name="The mysteriously persistently exploitable program (contest)
(Il programma misteriosamente e perennemente bucabile - il concorso)">
e in 
<url id="http://www.hackinglinuxexposed.com/articles/20031214.html"
name="The mysteriously persistently exploitable program explained
(La spiegazione per il programma misteriosamente e perennemente 
bucabile)"> (notate che l'incidente è riferito a Debian). 
Sostanzialmente è un
attacco in cui un utente locale <em>nasconde</em> da qualche parte
un'applicazione setuid vulnerabile facendo un hard link ad essa, di 
fatto evitando qualsiasi operazione di aggiornamento (o rimozione) 
del binario fatta dall'amministratore di sistema. Di recente dpkg 
è stato patchato per impedire questo comportamento (vedete il bug
<url id="http://bugs.debian.org/225692" name="225692">) ma altri 
binari setuid (non controllati dal gestore dei pacchetti) 
potrebbero essere a rischio  se le partizioni non vengono impostate 
correttamente.
</footnote>.

<item>
Ogni directory di dimensione variabile es. <file>/var</file> 
(specialmente <file>/var/log</file>) deve stare su una partizione 
separata. Attenzione, su un sistema Debian, dovreste creare la 
directory  <file>/var</file> leggermente più
grande di altri sistemi, perché i pacchetti scaricati (nella cache di 
apt) vengono conservati in <file>/var/cache/apt/archives</file>.
<item>
Tutte le directory dove volete installare del software che non 
appartiene alla distribuzione devono stare in partizioni separate. 
Secondo File Hierarchy Standard (Gerarchia Standard dei File system) queste
directory sono <file>/opt</file> oppure <file>/usr/local</file>. 
Se queste directory stanno su partizioni separate, non verranno 
cancellate se reinstallaste di nuovo Debian. 
<item>
<p>Dal punto di vista della sicurezza è importante cercare di mettere i 
dati statici in partizioni proprie, montate in sola lettura. Meglio 
ancora se questi dati vengono messi su supporti di sola lettura.
Vedete più avanti in questo capitolo per maggiori dettagli.


</list>

<p>Nel caso in cui gestiate un mail server è importante avere una partizione 
separata per la directory spool delle mail.
Gli utenti  remoti (sia consapevolmente che inconsapevolmente) possono 
riempire la directory mail spool (<file>/var/mail</file> o 
<file>/var/spool/mail</file>). Se 
la directory spool è in una partizione separata, questa eventualità
non bloccherà il sistema . Altrimenti, se la directory spool è sulla 
stessa partizione di <file>/var</file>, il sistema avrà  
gravi problemi quali: non 
potrete creare i file di log, non potrete installare pacchetti 
aggiuntivi e dei programmi (se usano la directory 
<file>/var/run</file>) avranno problemi a partire o verranno rallentati.

<p>Inoltre, per le partizioni per le quali non siete sicuri dello 
spazio che occorre, è preferibile installare Logical 
Volume Manager (<package>lvm-common</package>  
ed i pacchetti binari per il vostro kernel, questi possono essere  
<package>lvm10</package>, <package>lvm6</package>, oppure 
<package>lvm5</package>). Usando <tt>lvm</tt> si possono creare gruppi 
di volumi che possono occupare più volumi fisici multipli.



<sect2>Selezionare il file system appropriato


<p>
Durante il partizionamento del sistema dovete anche decidere
quale file system usare. L'installazione di Debian prevede, come 
file system predefinito per le partizioni Linux l'<tt>ext2</tt>.
Tuttavia, nei seguenti
casi, si raccomanda di passare ad un file system journalling,
come <tt>ext3</tt>, <tt>reiserfs</tt>, <tt>jfs</tt> o <tt>xfs</tt>, 
per ridurre al minimo i problemi derivanti da un crash di sistema
nei seguenti casi:



<list>

<item>
Per i computer portatili, in tutti i file system installati.
In questo modo se le  batterie si esaurissero inaspettatamente o se il
sistema si bloccasse per una questione relativa all'hardware (come nel caso 
della configurazione di X, che è piuttosto comune) la perdita di dati
durante un riavvio hardware sarebbe meno probabile.
<item>
Per i sistemi in produzione che registrano grandi quantità di
dati (come i server di posta, i server ftp, i file system di rete...)
si raccomanda un file system journalling sulle partizioni interessate. 
In questo modo, in caso di
crash del sistema, il server impiegherà meno tempo a riavviarsi
e controllare i file system, inoltre la perdita di dati sarà meno 
probabile.

</list>

<p>
Lasciando da parte le discussioni sulle prestazioni dei file
system journalling (visto che talvolta possono trasformarsi in
guerre di religione), è meglio, generalmente, usare il file system
<tt>ext3</tt>. 
Il motivo è che questo è compatibile all'indietro con <tt>ext2</tt>,
così se si dovessero presentare problemi con il journalling, è
possibile disabilitarlo e avere comunque un file system funzionante.
Inoltre, in caso si debba ripristinare il sistema con un dischetto di
avvio (o CDROM) non serve un kernel modificato. Se il kernel è un 2.4 
il supporto per <tt>ext3</tt> è già  disponibile, se il kernel è un 
2.2, pur perdendo le caratteristiche del journalling sarete in grado 
di avviare il file system. Invece, nel caso stiate usando altri tipi 
di file system journalling potreste non essere in grado di 
ripristinare, a meno che non abbiate un kernel 2.4 o 2.6 con i moduli 
necessari all'avvio già  compilati. Se avete un dischetto di 
salvataggio con un kernel 2.2 potrebbe essere ancora più 
difficile accedere a <tt>reiserfs</tt> o <tt>xfs</tt>.

<p>
In ogni caso, l'integrità dei dati potrebbe essere meglio
garantita da <tt>ext3</tt> visto che esegue un file-data journalling mentre gli
altri eseguono soltanto il meta-data journalling, vedete in
<url id="http://lwn.net/2001/0802/a/ext3-modes.php3">.



<sect>Non collegarsi ad Internet finché non si è pronti


<p>
Il sistema non dovrebbe essere immediatamente connesso ad
internet durante l'installazione. Questo potrebbe suonare sciocco, ma
l'installazione di rete è un metodo comune. Poiché il sistema,
installandosi, attiva immediatamente dei servizi, se è connesso ad
Internet ed i servizi non sono opportunamente configurati, 
sarà esposto a possibili attacchi.

<p>
Inoltre alcuni servizi potrebbero avere problemi di
sicurezza non ancora corretti nei pacchetti usati per l'installazione.
Questo accade di solito quando si esegue l'installazione con media
vecchi (come i CD-ROM). In questo caso, il sistema potrebbe addirittura
essere compromesso prima che si finisca l'installazione!

<p>
Poiché l'installazione e l'aggiornamento di Debian possono essere
effettuati via Internet, si potrebbe pensare che usare questa
caratteristica sia una buona idea. Se il sistema verrà direttamente
connesso a Internet (e non sarà protetto da firewall o NAT), è
preferibile installare senza essere connessi a Internet, usando un
mirror locale dei pacchetti sia per i sorgenti dei pacchetti
Debian sia per gli aggiornamenti di sicurezza. Un mirror dei
pacchetti per fornire gli archivi al sistema può essere preparato
usando un altro sistema connesso ad Internet con strumenti Debian specifici 
(se è un sistema Debian) come <package>apt-move</package> 
o <package>apt-proxy</package>, o
altri comuni strumenti per il mirroring. Se non è possibile fare
questo, potete attivare regole per il firewall che limitino
l'accesso al sistema durante l'aggiornamento
(vedete in <ref id="fw-security-update">).


<sect>Assegnare una password a root


<p>
Assegnare una buona password a root è il primo requisito
fondamentale per avere un sistema sicuro. Vedete  
<manref name="passwd" section="1"> per alcuni
suggerimenti su come creare una buona password. A questo scopo si
può anche usare un programma per la generazione automatica di password
(vedete in <ref id="user-pwgen">).
<p>
Abbondanti informazioni sulla scelta delle password possono essere 
trovate in internet; un paio di quelli che forniscono un riepilogo 
logico e decente sono:
<url name="How to: Pick a Safe Password (Come fare: scegliere una password sicura)."
id="http://wolfram.org/writing/howto/password.html"> e
Walter Belgers' 
<url name="Unix Password Security (Sicurezza nelle Password Unix)"
id="http://www.belgers.com/write/pwseceng.txt">
<!--Also at http://citeseer.ist.psu.edu/8481.html -->


<sect>Attivare shadow password e MD5 password



<p>
Alla fine dell'installazione verrà chiesto se abilitare le shadow 
password. Rispondere di sì alla domanda, le password verranno
conservate in <file>/etc/shadow</file>.
Solo l'utente root e il gruppo shadow possono accedere in lettura 
a questo file, così che nessun altro possa catturarne una copia 
e lanciarvi contro un password cracker. Potete 
decidere di scegliere tra password shadow e password normali in 
qualsiasi momento usando <tt>shadowconfig</tt>.

<p>
Per saperne di più sulle password shadow vedete il documento
<url id="http://www.tldp.org/HOWTO/Shadow-Password-HOWTO.html" name="Shadow Password">
(<file>/usr/share/doc/HOWTO/en-txt/Shadow-Password.txt.gz</file>).

<p>
L'installazione prevede l'utilizzo predefinito delle password
MD5. Di solito è una buona idea perché permette di usare password più lunghe 
di 8 caratteri e ha una migliore cifratura.  
Se usato correttamente, può rendere difficile trovare password 
di sistema con un attacco a forza bruta.
Le password MD5 sono l'opzione predefinita quando si installa il pacchetto 
<package>password</package> più recente. 
Potete riconoscere le password MD5 nel file 
<file>/etc/shadow</file> dal prefisso $1$.

<p>
Di conseguenza, vengono modificati tutti i file in <file>/etc/pam.d</file> 
sostituendo la riga delle password ed includendo MD5:

<example>
      password required pam_unix.so md5 nullok obscure min=6 max=16
</example>

<p>
Se <tt>max</tt> non è impostato oltre 8 la modifica non avrà 
alcuna utilità. Per maggiori informazioni leggete <ref id="auth-pam">.


<p>
Notate: la configurazione predefinita in Debian, anche attivando 
le password MD5, non modifica la precedente impostazione del 
valore <tt>max</tt>.



<sect>Lanciare i servizi strettamente necessari

<p>
I servizi sono programmi come i server ftp e i server web. Poiché restano 
nello stato <em>di attesa (listening)</em> di connessioni in ingresso che 
richiedono il servizio, i computer all'esterno possono collegarvisi. 
A volte i servizi sono vulnerabili (es: possono essere compromessi da un 
determinato attacco) e possono rappresentare un rischio per la sicurezza.

<p>
Non dovreste installare servizi che non sono necessari sulla 
vostra macchina. Ogni servizio installato può introdurre nuovi, 
magari non evidenti (o conosciuti) buchi di sicurezza sul vostro computer.

<p>
Come forse già saprete, quando si installa un determinato servizio, l'opzione 
predefinita è che sia attivo. In un'installazione Debian predefinita, senza 
servizi installati, l'insieme dei servizi attivi è piuttosto basso 
e questo è ancora più vero per quanto riguarda i servizi di rete. 
In una classica installazione di Debian 3.1, alla fine vi troverete
a disposizione come servizi di rete OpenSSH, Exim (a seconda di come
l'avrete configurato) e l'RPC portmapper <footnote>Lo schema, in 
Debian 3.0 e nei rilasci precedenti, non era così chiuso, dal momento 
che qualche servizio <prgn>inetd</prgn> veniva abilitato in modo 
predefinito. Anche le installazioni standard di Debian 2.2 
installavano sia il server NFS che quello telnet.</footnote>.
Se invece non farete un'installazione standard ma opterete per 
eseguire quella expert, potreste trovarvi alla fine senza servizi 
di rete attivi. Dato un sistema, l'RPC portmapper viene installato in 
modo predefinito perché è necessario per offrire molti servizi, come 
per esempio NFS. Comunque, l'RPC portmapper può essere facilmente 
rimosso, vedete per maggiori informazioni <ref id="rpc"> su come 
rendere sicuri o disabilitare i servizi RPC.

<p>
Quando installate un nuovo servizio di rete (demone) in 
Debian GNU/Linux, questo può essere attivato in 2 modi: per mezzo 
del superdemone <prgn>inetd</prgn> (una riga verrà
aggiunta a <file>/etc/inetd.conf</file>) o per mezzo di 
un programma indipendente che si collega all'interfaccia di 
rete. I programmi indipendenti vengono controllati tramite i 
file in <file>/etc/init.d</file>, che a loro volta vengono 
chiamati al momento del boot dal meccanismo SysV (o uno 
alternativo) usando un collegamento simbolico in 
<file>/etc/rc?.d/*</file> 
(per maggiori informazioni su come funzioni leggete
<file>/usr/share/doc/sysvinit/README.runlevels.gz</file>).

<p>
Se volete mantenere alcuni servizi ma usarli raramente, utilizzate i 
comandi di aggiornamento come, per esempio: 
<prgn>update-inetd</prgn> e <prgn>update-rc.d</prgn> per 
rimuoverli dal processo di avvio.
Per ulteriori informazioni su come disabilitare i servizi di rete 
vedete <ref id="disableserv">. Se volete cambiare  il comportamento 
predefinito, che prevede di abilitare l'avvio dei servizi una volta 
che i pacchetti ad essi associati vengano installati
<footnote>Questo potrebbe essere ciò che desiderate nel caso in cui 
stiate configurando un ambiente chroot per motivi di sviluppo, per 
esempio.</footnote>, dovete usare <prgn>policy-rc.d</prgn>, per 
favore, leggete 
<file>/usr/share/doc/sysv-rc/README.policy-rc.d.gz</file> per 
ulteriori chiarimenti.

<p>Il supporto ad <prgn>invoke-rc.d</prgn> è obbligatorio in Debian 
e questo significa che per Debian 4.0 <em>etch</em> e per i rilasci 
successivi è sempre possibile scrivere un file policy-rc.d che vieti 
di avviare nuovi demoni prima che siano stati configurati.  Sebbene 
tali script non siano stati ancora pacchettizzati, sono piuttosto 
semplici da scrivere. Vedete al riguardo 
<package>policyrcd-script-zg2</package>.





<sect1 id="disableserv">Disabilitare i servizi attivi in modalità demone


<p>Disabilitare i demoni relativi ai servizi è piuttosto semplice. 
Si può rimuovere il pacchetto che fornisce il servizio che gira come 
demone oppure si possono cancellare o rinominare gli script di avvio 
presenti in <file>/etc/rc${runlevel}.d/</file>. Nel caso tali script 
vengano rinominati, è importante assicurarsi che il loro nuovo nome 
non cominci per 'S' cosicché non vengano avviati da 
<prgn>/etc/init.d/rc</prgn>. &Egrave; importante non cancellare tutti
i collegamenti presenti o il sistema di gestione dei pacchetti li rigenererà 
in occasione di un aggiornamento degli stessi ed è quindi 
consigliabile lasciare almeno un collegamento (tipicamente un collegamento 'K' 
(NdT: da "Kill"), che ordina l'interruzione del funzionamento di un 
demone). Per maggiori informazioni leggete la sezione del manuale 
<em>La guida Debian</em>
<url id="http://www.debian.org/doc/manuals/reference/ch-system.it.html#s-custombootscripts"
name="Personalizzare i runlevel"> (Capitolo 2 - Nozioni fondamentali di Debian).



<p>
Potete rimuovere i collegamenti da <file>/etc/rc${runlevel}.d/</file> manualmente
o usando <tt>update-rc.d</tt> (vedete <manref name="update-rc.d" section="8">). 
Per esempio potete disabilitare un servizio nei runlevel 
multiutente con:

<example>
  update-rc.d stop XX 2 3 4 5 .
</example>

<p>
Dove <em>XX</em> è un numero che determina il momento in cui verrà 
chiamata l'interruzione del servizio.
Notate che se <em>non</em> state utilizzando 
<package>file-rc</package>, 
<tt>update-rc.d -f <var>service</var> remove</tt> non funzionerà 
correttamente, perché <em>tutti</em> i collegamenti vengono rimossi ma dopo 
una reinstallazione o un upgrade del pacchetto i collegamenti vengono ricreati 
(probabilmente non è quello che desiderate). Chi pensa che questo 
comportamento non sia intuitivo non ha torto (vedete il 
<url id="http://bugs.debian.org/67095" name="Bug 67095">). 
Dalla manpage:

<example>
  Se  esistono già  dei  file in  /etc/rcrunlevel.d/[SK]??nome  allora
  update-rc.d non fa nulla. In questo modo l'amministratore di sistema
  può risistemare i link, sempre  che ne abbiate lasciato almeno uno,
  senza dover sovrascrivere la loro configurazione.
</example>

<p>
Se usate <package>file-rc</package>, tutte le informazioni che 
riguardano l'avvio dei servizi verranno gestite da un file di 
configurazione comune e vengono conservate anche se i pacchetti 
sono disinstallati dal sistema.

<p>
&Egrave; possibile usare la TUI (Text User Interface, cioè interfaccia
utente in modalità testuale) fornita da 
<package>sysv-rc-conf</package> per apportare queste modifiche 
facilmente (<prgn>sysv-rc-conf</prgn> funziona sia con
<package>file-rc</package> che con i normali runlevel del System V).
Si trovano anche interfacce grafiche simili per i sistemi desktop. 
Altrimenti potete anche usare la riga di comando di 
<package>sysv-rc-conf</package>:

<example>
  # sysv-rc-conf foobar off
</example>
 
<p>
Il vantaggio nell'usare questo programma è che i collegamenti in rc.d 
verranno ripristinati a com'erano prima della disattivazione con la 
chiamata 'off' nel caso vengano riabilitati con:

<example>
  # sysv-rc-conf foobar on
</example>


<p>Altri metodi (non raccomandati) per disabilitare servizi sono: 

<list>

<item> rinominare lo script 
(<file>/etc/init.d/<var>service_name</var></file>) in qualcosa
di diverso (ad esempio 
<file>/etc/init.d/OFF.<var>service_name</var></file>) o eliminarlo.
Ad ogni modo, questo lascerebbe dei collegamenti simbolici interrotti 
in <file>/etc/rc${runlevel}.d/</file> che causerebbero la segnalazione 
di messaggi d'errore durante l'avvio.

<item>togliere il permesso di esecuzione al file dello script 
<file>/etc/init.d/<var>service_name</var></file>, ma anche questo 
causerà la segnalazione di messaggi d'errore all'avvio.

<item>modificare lo script del servizio 
<file>/etc/init.d/<var>service_name</var></file> in modo che termini 
immediatamente subito dopo la chiamata di esecuzione (aggiungendo un 
<prgn>exit 0</prgn> all'inizio della riga o commentando la parte 
<tt>start-stop-daemon</tt>). Però, nel caso in cui operiate in questo 
modo, in un secondo momento non sarete in grado di avviare il servizio 
nemmeno manualmente.

</list>

<p>I file nella directory <file>/etc/init.d</file> vengono classificati 
come file di configurazione e potrebbero non essere sovrascritti dal 
processo d'aggiornamento nel caso in cui siano stati modificati 
manualmente.

<p>
Sfortunatamente, al contrario di altri sistemi operativi (UNIX), 
in Debian i servizi non possono essere disabilitati modificando i
file in <file>/etc/default/<var>service_name</var></file>.

<p>
FIXME: Aggiungere informazioni su come gestire i demoni con
<package>file-rc</package>.





<sect1 id="inetd">Disabilitare i servizi gestiti da <prgn>inetd</prgn>

<p>Considerate bene se al giorno d'oggi avete davvero bisogno del 
demone <prgn>inetd</prgn>. Inetd è sempre stato un modo per rimediare 
a deficienze del kernel, che però sono state eliminate nei moderni 
kernel Linux. Contro <prgn>inetd</prgn> si possono effettuare degli 
attacchi di tipo "Denial of Service" (che possono aumentare 
considerevolmente il carico della macchina) e molti preferiscono usare 
demoni autonomi piuttosto che lanciare servizi tramite 
<prgn>inetd</prgn>. Comunque, se volete far girare un qualche tipo di
servizio <prgn>inetd</prgn>, dovreste almeno passare a un demone Inet 
più configurabile, come <prgn>xinetd</prgn>, <prgn>rlinetd</prgn> o 
<prgn>openbsd-inetd</prgn>.

<p>
Sarebbe bene arrestare tutti i servizi non necessari nel proprio
sistema, come <prgn>echo</prgn>, <prgn>chargen</prgn>, 
<prgn>discard</prgn>, <prgn>daytime</prgn>, <prgn>time</prgn>, 
<prgn>talk</prgn>, <prgn>ntalk</prgn> e gli r-services 
(<prgn>rsh</prgn>, <prgn>rlogin</prgn> e <prgn>rcp</prgn>)
che vengono considerati MOLTO insicuri (meglio usare 
<prgn>ssh</prgn> al loro posto). 

<p>
Potete disabilitare dei servizi modificando direttamente
<file>/etc/inetd.conf</file>, ma Debian fornisce un'alternativa 
migliore: <tt>update-inetd</tt> (che commenta i servizi in modo che 
possano essere facilmente riattivati). Potete rimuovere il demone 
<prgn>telnet</prgn> eseguendo il comando seguente, per cambiare il 
file di configurazione e riavviare il demone (in questo caso il 
servizio <prgn>telnet</prgn> viene disabilitato):

<example>
  /usr/sbin/update-inetd --disable telnet
</example>
<!-- # /etc/init.d/inetd restart Not needed since the manpage says update-inetd
sends a SIGHUP, commented out as suggested by Dariusz Puchalak -->

<p>Se davvero desiderate avere servizi in ascolto, ma non volete che stiano
in ascolto su tutti gli indirizzi IP del vostro host, probabilmente
vorrete utilizzare una funzione non documentata di <prgn>inetd</prgn>
(sostituire il nome del servizio con una sintassi del tipo servizio@ip)
o usare un demone <prgn>inetd</prgn> alternativo, come 
<prgn>xinetd</prgn>.
     



<sect>Installare il software strettamente necessario

<p>
Debian include <em>molto software</em>, per esempio Debian 3.0 
<em>woody</em> include 6 o 7 CD-ROM (a seconda dell'architettura)
di software e migliaia di pacchetti, Debian 3.1 
<em>sarge</em> include circa 13 CD-ROM di software.
Con così tanto software, anche se l'installazione del sistema 
base è ridotta 
<footnote>Per esempio, in Debian woody si aggira attorno ai 
4-500Mb, provate questo:
<example>
  $ size=0
  $ for i in `grep -A 1 -B 1 "^Section: base" /var/lib/dpkg/available |
  grep -A 2 "^Priority: required" |grep "^Installed-Size" |cut -d : -f 2
  `; do size=$(($size+$i)); done
  $ echo $size
  47762
</example>
</footnote>
potreste essere tentati di installare più software di 
quello necessario alle vostre esigenze.

<p>Poiché sapete già a cosa servirà il sistema (o no?), dovreste 
installare solo il software che è realmente necessario per farlo 
funzionare. Qualsiasi tool non necessario ma installato potrebbe 
essere usato da un utente che vuole compromettere il sistema o 
da un intruso esterno che ha ottenuto l'accesso ad una shell (o 
l'esecuzione di codice da remoto attraverso un servizio che lo 
consenta).

<p>La presenza, ad esempio, di utility di sviluppo (un compilatore per il 
linguaggio C) o di linguaggi interpretati (come <prgn>perl</prgn> 
- ma vedete sotto -, <prgn>python</prgn>, <prgn>tcl</prgn>...) 
potrebbe rendere le cose più semplici a colui che attacca per 
compromettere il sistema, in particolare: 

<list>

<item>
Permettendogli di acquisire privilegi. &Egrave; più facile, 
ad esempio, mandare in esecuzione exploit locali nel sistema 
se ci sono un debugger ed un compilatore pronti a compilarli ed a 
collaudarli!
<item>
Fornendo strumenti che potrebbero aiutare l'intruso ad usare il sistema 
compromesso come <em>base d'attacco</em> verso altri sistemi
<footnote>
Molte intrusioni vengono fatte giusto per ottenere accesso a risorse
per compiere attività illegali, (attacchi di tipo denial of service, spam, 
imbrogliare server ftp, inquinare dns...) piuttosto 
che per ottenere dati confidenziali dai sistemi compromessi.
</footnote>.
</list>

<p>
Naturalmente un intruso con accesso locale ad una shell può scaricare 
gli strumenti che gli servono ed eseguirli, ma anche la shell stessa 
può essere usata per scrivere programmi complessi. Rimuovere il 
software non necessario non aiuterà a <em>prevenire</em> il problema, 
ma renderà un po' più difficile l'azione dell'intruso (ed alcuni 
potrebbero rinunciare se si trovano in questa situazione, cercando 
un bersaglio più facile). Quindi, lasciando installati detti strumenti 
su un sistema in produzione, che può essere usato per attaccare sistemi 
da remoto (vedete <ref id="vuln-asses">) è lecito aspettarsi che un intruso 
li utilizzi, se disponibili.

<p>Notate che un'installazione predefinita di Debian <em>sarge</em> 
(come in un'installazione in cui non è stato selezionato alcun 
pacchetto) installerà un certo numero di pacchetti di sviluppo, di 
solito inutili. Ciò avviene perché alcuni pacchetti di sviluppo hanno 
priorità <em>Standard</em>. Se non pensate di fare sviluppo, potete 
rimuovere in tutta sicurezza i seguenti pacchetti dal vostro sistema, 
e questo aiuterà anche a liberare un po' di spazio:

<example>
Package                    Size
------------------------+--------
gdb                     2,766,822
gcc-3.3                 1,570,284
dpkg-dev                  166,800
libc6-dev               2,531,564
cpp-3.3                 1,391,346
manpages-dev            1,081,408
flex                      257,678
g++                         1,384 (Nota: pacchetto virtuale)
linux-kernel-headers    1,377,022
bin86                      82,090
cpp                        29,446
gcc                         4,896 (Nota: pacchetto virtuale)
g++-3.3                 1,778,880
bison                     702,830
make                      366,138
libstdc++5-3.3-dev        774,982
</example>

<p>Questo è stato corretto nelle versioni post-sarge, vedete il 
<url id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301273"
name="Bug #301273"> ed il 
<url id="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=301138"
name="Bug #301138">. A causa di un bug nel sistema di 
installazione, questo non è successo nei sistemi installati mediante 
l'installer della versione di Debian 3.0 <em>woody</em>.




<sect1>Rimuovere Perl

<p>
Dovreste tener conto che rimuovere <prgn>perl</prgn> potrebbe non essere troppo
facile (in realtà potrebbe essere anche abbastanza difficile) in un
sistema Debian poiché viene usato da molte utility di sistema. Inoltre,
il pacchetto <package>perl-base</package> è <em>Priority: required</em> 
(il che dice tutto).
La rimozione è ancora fattibile, ma non potrete eseguire nessuna
applicazione <prgn>perl</prgn> presente nel sistema. 
Dovrete inoltre ingannare il
sistema di gestione dei pacchetti per fargli credere che il pacchetto
<package>perl-base</package> sia installato anche se non lo è
<footnote>
<p>&Egrave; possibile creare (su un altro sistema) un finto pacchetto 
con <package>equivs</package>.
</footnote>.

<p>Quali sono le utility che usano <prgn>perl</prgn>? Potete scoprirlo da soli:

<example>
  $ for i in /bin/* /sbin/* /usr/bin/* /usr/sbin/*; do [ -f $i ] && {
  type=`file $i | grep -il perl`; [ -n "$type" ] && echo $i; }; done
</example>

<p>
Incluse le seguenti utility contenute in pacchetti con priorità 
<em>required</em> o <em>important</em>:


<list>
<item>
<p><file>/usr/bin/chkdupexe</file> del pacchetto <package>util-linux</package>.
<item>
<p><file>/usr/bin/replay</file> del pacchetto
<package>bsdutils</package>.
<item>
<p><file>/usr/sbin/cleanup-info</file> del pacchetto
<package>dpkg</package>.
<item>
<p><file>/usr/sbin/dpkg-divert</file> del pacchetto
<package>dpkg</package>.
<item>
<p><file>/usr/sbin/dpkg-statoverride</file> del pacchetto
<package>dpkg</package>.
<item>
<p><file>/usr/sbin/install-info</file> del pacchetto
<package>dpkg</package>.
<item>
<p><file>/usr/sbin/update-alternatives</file> del pacchetto
<package>dpkg</package>.
<item>
<p><file>/usr/sbin/update-rc.d</file> del pacchetto
<package>sysvinit</package>.
<item>
<p><file>/usr/bin/grog</file> del pacchetto
<package>groff-base</package>.
<item>
<p><file>/usr/sbin/adduser</file> del pacchetto
<package>adduser</package>.
<item>
<p><file>/usr/sbin/debconf-show</file> del pacchetto
<package>debconf</package>.
<item>
<p><file>/usr/sbin/deluser</file> del pacchetto
<package>adduser</package>.
<item>
<p><file>/usr/sbin/dpkg-preconfigure</file> del pacchetto
<package>debconf</package>.
<item>
<p><file>/usr/sbin/dpkg-reconfigure</file> del pacchetto
<package>debconf</package>.
<item>
<p><file>/usr/sbin/exigrep</file> del pacchetto
<package>exim</package>.
<item>
<p><file>/usr/sbin/eximconfig</file> del pacchetto
<package>exim</package>.
<item>
<p><file>/usr/sbin/eximstats</file> del pacchetto
<package>exim</package>.
<item>
<p><file>/usr/sbin/exim-upgrade-to-r3</file> del pacchetto
<package>exim</package>.
<item>
<p><file>/usr/sbin/exiqsumm</file> del pacchetto
<package>exim</package>.
<item>
<p><file>/usr/sbin/keytab-lilo</file> del pacchetto
<package>lilo</package>.
<item>
<p><file>/usr/sbin/liloconfig</file> del pacchetto
<package>lilo</package>.
<item>
<p><file>/usr/sbin/lilo_find_mbr</file> del pacchetto
<package>lilo</package>.
<item>
<p><file>/usr/sbin/syslogd-listfiles</file> del pacchetto
<package>sysklogd</package>.
<item>
<p><file>/usr/sbin/syslog-facility</file> del pacchetto
<package>sysklogd</package>.
<item>
<p><file>/usr/sbin/update-inetd</file> del pacchetto
<package>netbase</package>.

</list>

<p>
Quindi, senza Perl e a meno che non riscriviate queste utility come 
script di shell, probabilmente non potrete gestire alcun pacchetto
(quindi neanche aggiornare il sistema, il che <em>non è una buona cosa</em>). 

<p>
Se siete determinati a rimuovere Perl dal sistema base di Debian e 
avete tempo libero, spedite rapporti sui bachi dei pacchetti 
sopracitati includendo (in forma di patch) codice che sostituisca 
le utility con script di shell.

<p>Se desiderate verificare quali pacchetti Debian dipendano da Perl 
potete usare 

<example>
$ grep-available -s Package,Priority -F Depends perl
</example>

<p>o
<example>
$ apt-cache rdepends perl
</example>




<sect>Leggere la mailing list debian security

<p>Non sarebbe sbagliato dare uno sguardo alla mailing-list 
debian-security-announce, dove vengono annunciate migliorie ai 
pacchetti rilasciate da parte del Team Debian per la Sicurezza, o in
<url id="mailto:debian-security@lists.debian.org">, dove potrete 
partecipare alle discussioni sulla sicurezza in Debian.

<p>Per ricevere gli avvisi degli aggiornamenti di sicurezza, inviate 
un'email a <url 
id="mailto:debian-security-announce-request@lists.debian.org" 
 name="debian-security-announce-request@lists.debian.org">, 
scrivendo la parola "subscribe" nella riga dedicata all'oggetto 
dell'email. Potete altresì iscrivervi a questa lista moderata via 
web dalla pagina 
<url id="http://www.debian.org/MailingLists/subscribe" 
 name="http://www.debian.org/MailingLists/subscribe">.

<p>Questa mailing list ha un basso volume di traffico ed iscrivendovi 
verrete immediatamente avvisati sugli aggiornamenti di sicurezza 
che riguardano la distribuzione Debian. Questo permette di scaricare 
tempestivamente i nuovi pacchetti con le soluzioni ai bachi di 
sicurezza ed è veramente importante per mantenere sicuro il 
sistema. Leggete <ref id="security-update"> per trovare dettagli 
su questo argomento.





