<chapt>Dopo l'installazione



<p>Dopo aver installato il sistema, bisogna renderlo sicuro; molti esempi
descritti in questo capitolo puntano ad ottenere tale risultato.
Questo dipende dal vostro setup, ma per la prevenzione dagli accessi
fisici siete invitati a leggere i seguenti paragrafi:
<ref id="bios-boot">,<ref id="lilo-passwd">,
<ref id="kernel-root-prompt">, <ref id="restrict-console-login">
e <ref id="restrict-reboots">.

<p>Dopo esservi connessi a qualsiasi rete, specialmente se pubblica,
dovreste effettuare un aggiornamento di sicurezza
(vedete <ref id="security-update">) e magari cogliere l'occasione per
fare un backup del vostro sistema (in merito vedete
<ref id="snapshot">).

<sect id="debian-sec-announce">Iscrizione alla mailing list 
Debian Security Announce



<p>Per ricevere informazioni sugli aggiornamenti di sicurezza disponibili 
dovreste iscrivervi alla mailing list debian-security-announce per
ricevere i Debian Security Advisories (DSA). 
Leggete <ref id="debian-sec-team"> per maggiori informazioni su come 
lavora il Team Debian per la Sicurezza.  Per informazioni su come
iscriversi alle mailing list Debian leggete 
<url id="http://lists.debian.org">.

<p>I DSA sono firmati con la chiave del Team Debian per la Sicurezza che può
essere ottenuta da <url id="http://security.debian.org">.

<p>Sarebbe anche opportuno prendere in considerazione la sottoscrizione
della <url id="http://lists.debian.org/debian-security"
name="mailing list debian-security">, sulla quale vengono discusse
questioni generiche sulla sicurezza del sistema operativo Debian.
Potrete così sentire il parere di altri colleghi amministratori di
sistema, così come sviluppatori di Debian e di strumenti per la
sicurezza, che potranno rispondere alle vostre domande ed offrire
consulenza.

<p>FIXME: aggiungere qui la chiave?


<sect id="security-update">Eseguire un aggiornamento per la sicurezza



<p>
Non appena nuovi bug di sicurezza vengono scoperti nei pacchetti, i
manutentori di Debian e gli autori dei programmi generalmente li
correggono in pochi giorni o addirittura ore. Dopo che il bug è
risolto, viene reso disponibile un nuovo pacchetto su
<url id="http://security.debian.org" name="http://security.debian.org">.

<p>
Se state installando una qualsiasi versione di Debian dovete tenere
a mente che potrebbero essere usciti nel frattempo degli aggiornamenti per la sicurezza
per pacchetti che sono stati scoperti come affetti da vulnerabilità.
Ci potrebbero essere comunque delle versioni secondarie (ce ne sono
state quattro in Debian 3.0 <em>sarge</em>) che includono questi
aggiornamenti dei pacchetti.

<p>
Si deve poi annotare la data in cui i supporti removibili (se li avete
usati) sono stati preparati e controllare il sito di security per
controllare se ci sono stati aggiornamenti. Se ce ne sono e non potete
scaricare i pacchetti dal sito della sicurezza su un altro sistema
(non siete ancora connessi a Internet?  o si?) prima di connettervi
alla rete potreste pensare (se non siete protetti da un firewall per
esempio) di aggiungere regole al firewall per fare in modo che il
sistema si possa connettere solo a security.debian.org e poi eseguire
l'aggiornamento.  Una configurazione di esempio viene mostrata
in <ref id="fw-security-update">.



<p><em>Nota:</em> a partire da Debian woody 3.0, dopo
l'installazione si ha l'opportunità di aggiungere al
sistema gli aggiornamenti di sicurezza.
Rispondendo 'yes' a questa domanda, il sistema d'installazione
provvederà ad aggiungere alla sorgente dei pacchetti gli
aggiornamenti di sicurezza del codice sorgente e, se disponete
di un collegamento a Internet, a scaricare ed installare gli
aggiornamenti realizzati dopo la creazione del CD
d'installazione. Se state aggiornando una precedente versione
di Debian, o avete chiesto al sistema d'installazione di
non farlo, agite come spiegato più avanti.

<p>
Per aggiornare manualmente il sistema, inserite la seguente
riga nel vostro <file>sources.list</file> e avrete
l'aggiornamento dal ramo security updates automaticamente,
ogni volta che aggiornerete il vostro sistema.

<example>
deb http://security.debian.org/ stable/updates main contrib non-free
</example>

<p><em>Notate</em>: se state utilizzando il ramo <em>testing</em>,
utilizzate i sorgenti dei mirror di sicurezza di testing come
descritto in <ref id="security-support-testing">.

<p>Una volta che avete fatto questo, potrete utilizzare più strumenti
per aggiornare il vostro sistema. Se state usando un sistema desktop
avrete un'applicazione chiamata<footnote>In <em>etch</em> e nelle
versioni successive.</footnote> <prgn>update-notifier</prgn> che
renderà semplice il controllo della disponibilità di nuovi
aggiornamenti; selezionandola potrete aggiornare un sistema dal
desktop (utilizzando <prgn>update-manager</prgn>). Per maggiori
informazioni vedete <ref id="update-desktop">. Negli ambienti desktop
potete anche utilizzare <package>synaptic</package> (GNOME),
<package>kpackage</package> o <package>adept</package> (KDE) per
interfacce più avanzate. Se state lavorando su un semplice terminale,
in console, per aggiornare potete utilizzare
<package>aptitude</package>, <package>apt</package> o
<package>dselect</package> (deprecato):

<list>
<item>se volete utilizzare l'interfaccia di testo di
<package>aptitude</package> occorre solamente selezionare <em>u</em>
(aggiorna) seguito da <em>g</em> (esegui aggiornamento). Altrimenti
scrivete i seguenti comandi sulla riga di comando (come root):
<example>
# aptitude update
# aptitude upgrade
</example>

<item>se volete utilizzare <package>apt</package> scrivete solamente
i comandi come con <prgn>aptitude</prgn>, ma sostituite le righe sopra
di <prgn>aptitude</prgn> con <prgn>apt-get</prgn>.

<item>se volete utilizzare <package>dselect</package> allora prima
[U]Aggiornare, poi [I]nstallare ed alla fine, [C]onfigurare i
pacchetti installati/aggiornati.
</list>

<p>Se volete, potete aggiungere anche le righe deb-src a
<file>/etc/apt/sources.list</file>. Vedete
<manref name="apt" section="8"> per ulteriori dettagli.

<p>Notate: <em>non</em> occorre aggiungere la seguente riga:

<example>
  deb http://security.debian.org/debian-non-US stable/non-US main contrib non-free
</example>
<p>perché security.debian.org viene ospitato in una posizione 
non-US e non ha più un archivio non-US separato.



<sect1 id="lib-security-update">Aggiornamento di sicurezza delle librerie

<p>Una volta eseguito un aggiornamento di sicurezza, potrebbe essere
necessario riavviare alcuni servizi di sistema. Se non lo fate, alcuni
servizi potrebbero ancora essere ancora vulnerabili dopo 
l'aggiornamento di sicurezza. Infatti è possibile che i demoni in 
esecuzione prima di un aggiornamento stiano ancora usando le vecchie 
librerie
<footnote>
          Anche se le librerie sono state rimosse dal filesystem gli 
          inode non verranno cancellati finché non ci sarà più alcun 
          programma con descrittori di file aperti che puntano ad essi.
</footnote>.
Per capire quali demoni dovrebbero essere riavviati potete usare il 
programma <prgn>checkrestart</prgn> (disponibile nel pacchetto 
<package>debian-goodies</package>) o dare (come root) il seguente 
comando, su una singola riga<footnote>
          A seconda della vostra versione di lsof, potreste dover usare 
          $8 invece di $9.</footnote>
:

<example>
# lsof | grep &lt;the_upgraded_library&gt; | awk '{print $1, $9}' | uniq | sort -k 1
</example>

<p>Alcuni pacchetti (come <package>libc6</package>) fanno questo 
controllo nella fase di post installazione per un insieme limitato di 
servizi, soprattutto perché un aggiornamento di librerie essenziali 
potrebbe arrecare danni ad alcune applicazioni (fino al loro 
riavvio)<footnote>
          Ciò è accaduto, per esempio, nell'aggiornamento da libc6 
          2.2.x a 2.3.x a causa di problemi con l'autenticazione NSS,
          vedete <url id="http://lists.debian.org/debian-glibc/2003/debian-glibc-200303/msg00276.html">.
</footnote>.
<p>Quindi portare il sistema al runlevel 1 (singolo utente) e poi di
nuovo a runlevel 3 (multiutente) ed assicurare il riavvio della maggior
parte dei servizi di sistema (se non di tutti). Ma questa non è
un'opzione fattibile se state eseguendo l'aggiornamento di sistema da una
connessione remota (come ssh) poiché questa verrà interrotta.

<p>Fate attenzione quando avete a che fare con gli aggiornamenti di
sicurezza nel caso in cui operiate su una connessione remota come ssh.
Una procedura consigliata che implica un riavvio dei servizi è riavviare
il demone SSH e provare ad aprire immediatamente una nuova connessione
senza chiudere la vecchia. Se la connessione dovesse cadere, annullate
l'aggiornamento ed investigate sulla questione.



<sect1 id="kernel-security-update">Aggiornamenti di sicurezza per il kernel

<p>Per prima cosa dovete essere sicuri che il kernel che volete
aggiornare sia supportato dal vostro gestore di pacchetti. Se
avete fatto l'installazione usando il sistema di installazione di
Debian 3.0 o versioni precedenti, il kernel <em>non</em> è integrato
nel sistema di gestione dei pacchetti e potrebbe non essere
aggiornato. Potete trovare conferma di ciò lanciando:

<example>
$ dpkg -S `readlink -f /vmlinuz`
linux-image-2.6.18-4-686: /boot/vmlinuz-2.6.18-4-686
</example>

<p>Se il kernel non viene gestito invece del messaggio qui sopra, che
dice che il file associato al kernel corrente viene fornito da
<package>linux-image-2.6.18-4-686</package>, vedrete un messaggio che
spiega che il gestore dei pacchetti non trova il file associato ad ogni
pacchetto. Perciò, prima, dovrete installare manualmente un pacchetto
immagine del kernel. La corretta immagine del kernel che dovete
installare dipende dall'architettura della vostra macchina e dalla
versione del kernel che preferite. Una volta fatto questo potrete
gestire gli aggiornamenti di sicurezza del kernel come quelli di ogni
altro pacchetto. In ogni caso, tenete conto che gli aggiornamenti
del kernel verranno eseguiti <em>solo</em> per kernel della stessa
serie e versione di quella che state usando, perciò <prgn>apt</prgn>
non aggiornerà automaticamente il kernel dalla versione 2.4 alla 2.6
(oppure dalla versione 2.4.26 alla 2.4.27<footnote>A meno che non
abbiate installato un kernel metapacchetto come
<package>linux-image-2.6-686</package> che garantirà sempre
le ultime revisioni del kernel della medesima serie, per una
data architettura.</footnote>).

<p>Il sistema di installazione delle ultime versioni Debian tratta
i kernel selezionati come parte del sistema di gestione dei pacchetti.
Potete controllare quale kernel avete installato lanciando:

<example>
$ COLUMNS=150 dpkg -l 'linux-image*' | awk '$1 ~ /ii/ { print $0 }'
</example>

<p>Eseguite i seguenti comandi per controllare se il vostro kernel ha
bisogno di essere aggiornato:

<example>
$ kernfile=`readlink -f /vmlinuz`
$ kernel=`dpkg -S $kernfile | awk -F : '{print $1}'`
$ apt-cache policy $kernel
linux-image-2.6.18-4-686:
  Installed: 2.6.18.dfsg.1-12
  Candidate: 2.6.18.dfsg.1-12
  Version table:
 *** 2.6.18.dfsg.1-12 0
        100 /var/lib/dpkg/status
</example>

<p>Nel caso in cui stiate effettuando un aggiornamento di sicurezza 
che coinvolge anche il kernel è <em>necessario</em> riavviare il 
sistema affinché l'aggiornamento di sicurezza sia efficace. Finché il 
sistema non viene riavviato rimane in esecuzione la vecchia (e 
vulnerabile) immagine del kernel.

<!-- FIXME: Do a script to check for the above, maybe using ps -p 1 -o etime | tail -1
and obtain the creation time of `readlink -f /vmlinuz`. -->

<p>Nel caso in cui sia necessario riavviare il sistema per un 
aggiornamento del kernel, dovete assicurarvi che il sistema
si avvii correttamente e che la connettività di rete venga
ripristinata, soprattutto se l'aggiornamento in questione viene
eseguito mediante una connessione remota come con ssh. Nel caso
in cui insorgesse un  malfunzionamento del nuovo kernel all'avvio
del sistema sarà possibile configurare il boot loader affinché avvii
il vecchio kernel (per maggiori dettagli leggete
<url id="http://www.debian-administration.org/?article=70"
name="Remotely rebooting Debian GNU/Linux machines
(Riavviare macchine Debian GNU/Linux da remoto)">.
Infine dovreste introdurre uno script che collaudi la connettività
di rete dopo il riavvio del sistema, che controlli che il kernel
abbia correttamente configurato il sottosistema di rete e che lo
riavvii se dovesse riscontrare malfunzionamenti
<footnote>un semplice script di esempio,
<url id="http://www.debian-administration.org/articles/70/testnet"
name="testnet"> è disponibile nell'articolo
<url id="http://www.debian-administration.org/?article=70"
name="Remotely rebooting Debian GNU/Linux machines
      (Riavviare macchine Debian GNU/Linux da remoto)">.
Uno script più complesso per controllare la connettività di rete
è presente all'interno dell'articolo sul collaudo della rete
<url id="http://www.debian-administration.org/?article=128"
name="Testing network connectivity
      (Collaudare la connettività di rete)">.
</footnote>.
Questo dovrebbe evitare brutte sorprese come aggiornare il kernel e
rendersi conto, al successivo riavvio, che non riconosce o non
configura correttamente l'hardware di rete e si è nella condizione
di dover lavorare a distanza per risistemare il sistema. Ovviamente,
avere la console seriale di sistema
<footnote>
          Configurare una console seriale esula dallo scopo di questa
          documentazione, per ulteriori informazioni leggete il
          <url id="http://www.tldp.org/HOWTO/Serial-HOWTO.html"
          name="Serial HOWTO"> ed il
          <url id="http://www.tldp.org/HOWTO/Remote-Serial-Console-HOWTO/index.html"
          name="Remote Serial Console HOWTO">.
</footnote>
, connessa ad una console o un terminale di servizio dovrebbe anche 
aiutare ad indagare i problemi di riavvio a distanza.




<sect id="bios-boot">Modificare il BIOS (ancora)


<p>
Ricordate il paragrafo <ref id="bios-passwd">? Bene,
fatelo ora, se non avete bisogno che l'avvio della macchina avvenga
da un supporto rimuovibile, modificate il BIOS per renderla avviabile
<em>solamente</em> dall'hard disk. Prestate attenzione a non perdere
la password del BIOS, altrimenti in caso di fallimento dell'avvio
non potrete entrare nel BIOS e cambiare media, ad esempio per avviare
da CD-ROM.

<p>
Un altro piccolo accorgimento potrebbe essere quello di cambiare la 
configurazione del BIOS, permettendo al sistema di partire dall'hard 
disk e se questo fallisse allora provare con un supporto removibile. 
A proposito, molte persone non usano la password per il BIOS ed è 
quindi facile dimenticarsene.






<sect id="lilo-passwd">Impostazione della password in LILO o GRUB

<p>
Chiunque può molto facilmente eseguire il login come root e cambiare 
la vostra password digitando 
<tt>&lt;nome-della-vostra-immagine di avvio&gt; init=/bin/sh</tt>
al prompt di boot. Dopo aver cambiato la password ed aver riavviato 
il sistema, questa persona ha un accesso illimitato come root e può 
impedire l'accesso al sistema. Con questa procedura, non avrete più 
l'accesso al sistema come root, perché non ne conoscete la password.

<p>
Per essere sicuri di evitare di trovarvi in questa situazione dovete
impostare una password per il vostro boot loader. Potete scegliere se 
impostare la password globalmente, oppure per una determinata immagine.

<p>
Per LILO occorre modificare il file <file>/etc/lilo.conf</file>, 
aggiungere una <tt>password</tt> e la riga <tt>restricted</tt> 
come nell'esempio seguente.

<example>
  image=/boot/2.2.14-vmlinuz
     label=Linux
     read-only
     password=hackme
     restricted
</example>

<p>
Successivamente, assicuratevi che il file di configurazione non 
sia leggibile da tutti, in modo da impedire che i normali utenti 
possano leggere la password. Fatto ciò, riavviate lilo. 
Omettere la riga contenente <tt>restricted</tt> fa sì che lilo 
chieda sempre una password, indipendentemente dal fatto che gli 
siano stati passati dei parametri o meno. I permessi predefiniti 
per il file <file>/etc/lilo.conf</file> consentono l'accesso in 
scrittura ed in lettura all'utente root e l'accesso in lettura 
al gruppo utenti cui appartiene il file, root.


<p>
Se al posto di LILO usate GRUB, modificate 
<file>/boot/grub/menu.lst</file> ed aggiungete le seguenti due righe 
all'inizio (naturalmente, sostituite <tt>hackme</tt> con la vostra 
password). Questo previene che si modifichi la configurazione di 
avvio. La direttiva <tt>timeout 3</tt> istruisce <prgn>grub</prgn> 
ad attendere 3 secondi prima di avviare il sistema.

<example>
  timeout 3
  password hackme
</example>

<p>Per conservare l'integrità delle password, si può generare una
password cifrata. Il programma <prgn>grub-md5-crypt</prgn> genera
una password compatibile con l'algoritmo di cifratura per le 
password di GRUB (MD5). Per specificare in <prgn>grub</prgn> che 
si intende usare il sistema di password nel formato MD5, bisogna 
usare la seguente direttiva:

<example>
  timeout 3
  password --md5 $1$bw0ez$tljnxxKLfMzmnDVaQWgjP0
</example>

<p>
Il parametro --md5, istruisce <prgn>grub</prgn> ad usare il processo 
di autenticazione MD5. L'esempio riporta la versione cifrata con 
MD5 della parola hackme. Usare il metodo di cifratura delle password 
MD5 è preferibile che lasciare il testo chiaramente leggibile.
Potete trovare altre informazioni sull'uso delle password con 
<prgn>grub</prgn> nel pacchetto <package>grub-doc</package>.




<sect id="kernel-initramfs-prompt">Disabilitare il prompt di root su initramfs

<p>Notate: questo si riferisce ai kernel predefiniti forniti in
versioni successive a Debian 3.1

<p>I kernel linux della serie 2.6 permettono di accedere ad una shell
durante il processo di boot nel caso in cui vi sia un errore durante
il caricamento dello initramfs. Ciò permette all'amministratore, in
caso di problemi, di accedere ad una shell di emergenza con i
privilegi di root. Questa shell può inoltre essere usata per inserire
manualmente dei moduli del kernel in caso di malfunzionamenti del
meccanismo di rilevazione automatica dell'hardware. Questo è il
comportamento predefinito sugli initramfs che sono stati creati
tramite <prgn>initramfs-tools</prgn>. In caso di problemi durante
il boot, apparirà il seguente messaggio:

<example>
  "ALERT!  /dev/sda1 does not exist.  Dropping to a shell!
</example>

<p>Per evitare ciò bisogna passare al kernel il seguente
parametro:<em>panic=0</em>. Si può aggiungere tale parametro
alla sezione kopt del file <file>/boot/grub/menu.lst</file> e
poi eseguire il comando <prgn>update-grub</prgn> o aggiungerlo
nella sezione 'append' del file <file>/etc/lilo.conf</file>.






<sect id="kernel-root-prompt">Rimuovere il prompt root nel kernel


<p>Notate: questo non si applica ai kernel forniti per Debian 3.1 come
anche il timeout per il ritardo del kernel è stato impostato a 0.

<p>
I kernel Linux della versione 2.4 forniscono la possibilità di accedere
ad una shell da superutente durante il boot di sistema, subito dopo il
caricamento del file system cramfs. Apparirà un messaggio che permetterà
all'amministratore di accedere ad una shell con privilegi di superutente,
questa può essere usata per caricare manualmente i moduli qualora
il riconoscimento automatico fallisca.
Questo è il comportamento predefinito per gli
<prgn>initrd</prgn> e per <file>linuxrc</file>.
Apparirà il seguente messaggio:

<example>
  Press ENTER to obtain a shell (waits 5 seconds)
</example>

<p>
Per rimuovere questo comportamento dovrete modificare
<file>/etc/mkinitrd/mkinitrd.conf</file> ed impostare:

<example>
  # DELAY  The  number  of seconds the linuxrc script should wait to
  # allow the user to interrupt it before the system is brought up
  DELAY=0
</example>

<p>
Quindi dovrete rigenerare l'immagine del ramdisk. Lo potete fare con:

<example>
  # cd /boot
  # mkinitrd -o initrd.img-2.4.18-k7 /lib/modules/2.4.18-k7
</example>

<p>
Oppure (preferito):

<example>
  # dpkg-reconfigure -plow kernel-image-2.4.x-yz
</example>








<sect id="restrict-console-login">Circoscrivere l'accesso alla console



<p>
Alcune politiche di sicurezza potrebbero forzare l'amministratore ad
autenticarsi nel sistema tramite console con le proprie username e password
e successivamente diventare super utente (tramite 
<prgn>su</prgn> o <prgn>sudo</prgn>).
Questa politica viene implementata in Debian modificando il file
<file>/etc/login.defs</file> oppure <file>/etc/securetty</file> 
se viene utilizzato PAM:

<list>

<item>
<p><file>login.defs</file>, modificando la variabile CONSOLE che 
definisce un file o una lista di terminali su cui è consentito 
l'accesso come superutente.

<item><file>securetty</file>,
    <footnote>
    Il file <file>/etc/securetty</file> è un file di configurazione 
    che appartiene al pacchetto <package>login</package>.
    </footnote>
aggiungendo o rimuovendo i terminali su cui l'utente root 
potrà effettuare il login. Se desiderate permettere solo 
l'accesso alle console locali, dovrete scrivervi 
<em>console</em>, <em>ttyX</em> 
    <footnote>
    O <em>ttyvX</em> in GNU/FreeBSD e <em>ttyE0</em> su GNU/KNetBSD.
    </footnote>
e <em>vc/X</em> (se usate dispositivi <em>devfs</em>).  Se state 
usando una console seriale per l'accesso locale al computer, 
dovrete anche aggiungere al file uno o più righe <em>ttySX</em>
    <footnote>
    O <em>comX</em> su GNU/Hurd, <em>cuaaX</em> su GNU/FreeBSD e 
    <em>ttyXX</em> su GNU/KNetBSD.
    </footnote>
(dove X è un numero intero; è possibile infatti abilitare un numero 
di console virtuali arbitrario
    <footnote>
    La configurazione predefinita in <em>woody</em> include 12 
    console locali di tipo tty e vc oltre al file dispositivo 
    <em>console</em>, ma non permette di effettuare il login da 
    remoto. In <em>sarge</em> la configurazione predefinita fornisce
    64 console di tipo tty e vc. Queste console possono essere 
    tranquillamente disabilitate nel caso in cui non vengano usate.
    </footnote>
in <file>/etc/inittab</file>
    <footnote>
    Vedete le chiamate a <em>getty</em>.
    </footnote>
). Per maggiori informazioni sui dispositivi facenti funzione di 
terminale leggete il 
<url id="http://tldp.org/HOWTO/Text-Terminal-HOWTO-6.html" name="Text-Terminal-HOWTO">.

</list>

<p>
Quando viene utilizzato PAM, altre modifiche al processo di
autenticazione, comprese restrizioni a livello utente e gruppo durante
orari prestabiliti, possono essere configurate 
in <file>/etc/pam.d/login</file>.
Un' interessante caratteristica è quella di poter disabilitare
l'autenticazione con password nulle. Questa caratteristica può essere
abilitata rimuovendo <em>nullok</em> dalla riga:

<example>
  auth       required   pam_unix.so nullok
</example>



<sect id="restrict-reboots">Circoscrivere la possibilità di 
riavviare da console



<p>
Se il vostro sistema ha una tastiera, chiunque (sì, <em>chiunque</em>) 
può riavviare il sistema senza neanche autenticarsi. Questo potrebbe o 
non potrebbe essere conforme alla vostra politica di sicurezza. Se 
volete evitarlo, dovete controllare se nel file 
<file>/etc/inittab</file> la riga che include <tt>ctrlaltdel</tt>
chiama <prgn>shutdown</prgn> con lo switch <tt>-a</tt> 
(ricordatevi di lanciare <tt>init q</tt> dopo
aver apportato qualsiasi modifica a questo file). 
In Debian questo switch è preimpostato:

<example>
  ca:12345:ctrlaltdel:/sbin/shutdown -t1 -a -r now
</example>

<p>
Ora, per permettere ad <em>alcuni</em> utenti di spengere 
il sistema, come spiega la
pagina man <manref name="shutdown" section="8">, dovete creare il 
file <file>/etc/shutdown.allow</file> e includere
lì i nomi degli utenti che possono fare un reboot. Quando si fa il <em>saluto
delle tre dita</em> (conosciuto anche come <em>ctrl+alt+del</em>) 
il programma controlla
che sia autenticato almeno uno degli utenti della lista. Se non ce n'è nemmeno
uno, <prgn>shutdown</prgn> <em>non</em> eseguirà il riavvio.



<sect>Montare le partizioni nel modo giusto



<p>
Quando si monta una partizione ext2 ci sono diverse opzioni
aggiuntive che si possono applicare alla chiamata a mount
o all'<file>/etc/fstab</file>. Per esempio, questa è la riga
del mio fstab per la partizione <file>/tmp</file>:

<example>
  /dev/hda7    /tmp    ext2    defaults,nosuid,noexec,nodev    0    2
</example>

<p>
Potete vedere le differenze nella sezione delle opzioni.
L'opzione <tt>nosuid</tt> ignora completamente i bit setuid e setgid,
mentre <tt>noexec</tt> impedisce l'esecuzione di qualsiasi programma
su quel punto di montaggio e <tt>nodev</tt> ignora i file dispositivo.
Sembra grandioso ma:

<list>

<item>
<p>si applica solo ai filesystem ext2
<item>
<p>può essere facilmente aggirato

</list>

<p>L'opzione <tt>noexec</tt> evita l'esecuzione diretta dei file
binari, ma veniva aggirata facilmente nelle versioni precedenti
del kernel:

<example>
  alex@joker:/tmp# mount | grep tmp
  /dev/hda7 on /tmp type ext2 (rw,noexec,nosuid,nodev)
  alex@joker:/tmp# ./date
  bash: ./date: Permission denied
  alex@joker:/tmp# /lib/ld-linux.so.2 ./date
  Sun Dec  3 17:49:23 CET 2000
</example>

<p>Comunque i kernel più recenti gestiscono correttamente l'opzione
<tt>noexec</tt>:

<example>
  angrist:/tmp# mount | grep /tmp
  /dev/hda3 on /tmp type ext3 (rw,noexec,nosuid,nodev)
  angrist:/tmp# ./date
  bash: ./tmp: Permission denied
  angrist:/tmp# /lib/ld-linux.so.2 ./date
  ./date: error while loading shared libraries: ./date: failed to map segment
  from shared object: Operation not permitted
</example>

<p>
Comunque, molti script kiddie hanno exploit che tentano di creare ed 
eseguire file in <file>/tmp</file>. Se non ci riescono, cadranno nel 
trabocchetto. In altri termini, un utente non può essere ingannato 
ed eseguire un binario trojanizzato in <file>/tmp</file>, ad esempio 
aggiungendo <file>/tmp</file> al suo PATH.

<p>
Siete inoltre avvisati, l'esecuzione di alcuni script dipende
dal fatto che <file>/tmp</file> sia eseguibile. In particolare,
questa cosa riguarda (riguardava?) alcuni aspetti di Debconf, per
maggiori informazioni vedete il Bug
<url id="http://bugs.debian.org/116448" name="116448">.

<p>
Il seguente è un altro esempio. Una nota: <file>/var</file> può
essere impostata noexec, ma certo software
<footnote>
<p>Tra questi i programmi Smartlist ed il gestore dei pacchetti
<package>dpkg</package>, visto che gli script di installazione
(post, pre) e di rimozione (post, pre) sono in
<file>/var/lib/dpkg/</file>.
</footnote>
mette i propri eseguibili in <file>/var</file>. Lo stesso
si applica all'opzione nosuid.

<example>
/dev/sda6   /usr          ext3    defaults,ro,nodev       0       2
/dev/sda12  /usr/share    ext3    defaults,ro,nodev,nosuid        0       2
/dev/sda7   /var          ext3    defaults,nodev,usrquota,grpquota 0      2
/dev/sda8   /tmp          ext3    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
/dev/sda9   /var/tmp      ext3    defaults,nodev,nosuid,noexec,usrquota,grpquota    0       2
/dev/sda10  /var/log      ext3    defaults,nodev,nosuid,noexec    0       2
/dev/sda11  /var/account  ext3    defaults,nodev,nosuid,noexec    0       2
/dev/sda13  /home         ext3    rw,nosuid,nodev,exec,auto,nouser,async,usrquota,grpquota                0       2
/dev/fd0    /mnt/fd0      ext3    defaults,users,nodev,nosuid,noexec      0       0
/dev/fd0    /mnt/floppy   vfat    defaults,users,nodev,nosuid,noexec      0       0
/dev/hda    /mnt/cdrom    iso9660 ro,users,nodev,nosuid,noexec            0       0
</example>





<sect1>Impostare <file>/tmp</file> come noexec

<p>
State attenti ad impostare <file>/tmp</file> come noexec quando
volete installare nuovo software,  poiché alcuni programmi 
potrebbero usarla per l'installazione. 
<package>apt</package> è uno di questi programmi (vedete
<url id="http://bugs.debian.org/116448">) se non è configurata correttamente 
<tt>APT::ExtractTemplates::TempDir</tt> 
(vedete <manref name="apt-extracttemplates" section="1">). 
Potete impostare questa variabile in <file>/etc/apt/apt.conf</file> 
in modo che punti ad un'altra directory,
diversa da <file>/tmp</file> e con privilegi di esecuzione.







<sect1>Impostare /usr in sola lettura

<p>
Se impostate <file>/usr</file> in sola lettura non potrete
più installare nuovi pacchetti sul vostro sistema Debian GNU/Linux.
Dovrete prima rimontarla in lettura-scrittura, installare i pacchetti
e poi rimontarla in sola lettura. <package>apt</package> può essere
configurato per eseguire comandi prima e dopo l'installazione dei
pacchetti, per cui potreste volerlo configurare correttamente.

<p>Per farlo, modificate <file>/etc/apt/apt.conf</file> aggiungendo:

<example>
  DPkg
  {
      Pre-Invoke  { "mount /usr -o remount,rw" };
      Post-Invoke { "mount /usr -o remount,ro" };
  };
</example>

<p>
Notate che Post-Invoke può fallire con un messaggio d'errore "/usr
busy". Questo succede frequentemente quando si stanno aggiornando
alcuni file mentre eseguiamo l'aggiornamento.
Potete trovare questi programmi eseguendo:
<example>
# lsof +L1
</example>

<p>Quindi fermate o riavviate questi programmi ed eseguite il
Post-Invoke manualmente.
<em>Attenzione!</em> Questo significa che sarà probabilmente
necessario riavviare la sessione X (se è in esecuzione) ogni
volta che eseguirete un aggiornamento del sistema.  Da prendere
in considerazione se per voi sia adatto avere <file>/usr</file>
in sola lettura. Vedete anche la discussione su <url
id="http://lists.debian.org/debian-devel/2001/11/threads.html#00212"
name="debian-devel circa /usr in sola lettura">.









<sect>Fornire un accesso sicuro per gli utenti

<sect1 id="auth-pam">Autenticazione degli utenti: PAM

<p>
PAM (Pluggable Authentication Modules) permette agli amministratori di
sistema di scegliere come le applicazioni autenticano gli utenti. 
Notate che PAM non funziona se un'applicazione non è stata compilata 
con il supporto per PAM. Molte delle applicazioni fornite con Debian 
hanno questo supporto integrato (inoltre Debian non ha il supporto PAM
per versioni precedenti alla 2.2).  L'attuale configurazione predefinita per un
qualsiasi servizio abilitato PAM è emulare l'autenticazione UNIX
(leggete in
<file>/usr/share/doc/libpam0g/Debian-PAM-MiniPolicy.gz</file> per
ulteriori informazioni su come i servizi PAM <em>dovrebbero</em>
funzionare in Debian).

<p>
Ogni applicazione con supporto PAM ha un file di configurazione
in <file>/etc/pam.d/</file> che può essere usato per modificare
il suo comportamento:

<list>
<item>
<p>quale programma sottostante viene utilizzato per l'autenticazione.
<item>
<p>quale programma sottostante viene utilizzato per le sessioni.
<item>
<p>come si comportano i controlli delle password.

</list>

<p>
La seguente descrizione è lontana dall'essere completa, per ulteriori
informazioni potete leggere <url id="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam.html" name="The Linux-PAM System Administrator's Guide (Guida dell'amministratore di un sistema Linux-PAM)"> (sul
<url id="http://www.kernel.org/pub/linux/libs/pam/" name="sito primario della distribuzione PAM">),
questo documento viene fornito anche dal pacchetto 
<package>libpam-doc</package>.

<p>PAM offre la possibilità di passare attraverso diverse fasi di
autenticazione in una volta sola, senza che l'utente se ne accorga. 
Si potrebbe autenticare con un database Berkeley e con un
normale file <file>passwd</file> e l'utente riuscirebbe a loggarsi se
autenticato correttamente da entrambi.  Si possono effettuare molte
restrizioni con PAM, così come spalancare le porte del sistema. Perciò
siate prudenti. 
Una tipica riga di configurazione ha un campo di controllo come secondo
elemento. Generalmente dovrebbe essere impostata a <tt>requisite</tt>, in modo
che restituisca un messaggio di login fallita se un modulo fallisce
nell'autenticazione.

<!-- Second in mine (old Debian v2.0 though), check this! (FIXME) (era) -->
<!-- Lots of fields in mine are "required", please elaborate? (FIXME) (era) -->

<p>
La prima cosa che mi piace fare è aggiungere alle applicazioni PAM il 
supporto MD5, poiché ciò protegge da "dictionary cracks" (le password
possono essere più lunghe se si usa MD5). Le due righe seguenti dovrebbero
essere aggiunte a tutti i file in <file>/etc/pam.d/</file> che forniscono 
un accesso alla macchina, come <tt>login</tt> e <tt>ssh</tt>.

<example>
  #  Assicuratevi di aver già installato libpam-cracklib
  #+ o non riuscirete ad autenticarvi
  password   required     pam_cracklib.so retry=3 minlen=12 difok=3
  password   required     pam_unix.so use_authtok nullok md5
</example>

<p>Ma cosa fanno queste righe? La prima carica il modulo PAM cracklib,
che fornisce un controllo sulla qualità delle password, chiede una
nuova password con una lunghezza minima di 12 caratteri, con una
differenza di almeno 3 caratteri da quella vecchia e permette un
massimo di 3 tentativi. Cracklib dipende da una serie di pacchetti 
(come <package>wenglish</package>, <package>wspanish</package>, 
<package>wbritish</package>...), accertatevi di avere installato 
quello appropriato per la lingua desiderata (altrimenti potrebbe 
non essere affatto utile)
<footnote>
<p>Questa dipendenza, tuttavia, non è corretta nel pacchetto in 
Debian 3.0. Vedete il <url id="http://bugs.debian.org/112965" 
name="Bug #112965">.
</footnote>.
La seconda riga inserisce il modulo standard
di autenticazione con password MD5 e permette password di lunghezza
nulla. La direttiva <tt>use_authtok</tt> è necessaria per il passaggio
della password dal modulo precedente.  

<p>Per essere sicuri che l'utente root possa solo autenticarsi 
nel sistema da terminali locali, si dovrebbe aggiungere in 
<file>/etc/pam.d/login</file> la seguente riga:

<example>
  auth     requisite  pam_securetty.so
</example>

<p>Poi, in <file>/etc/securetty</file>, potreste modificare l'elenco 
dei terminali sui quali è consentito l'accesso diretto da root.
In alternativa potreste abilitare il modulo <tt>pam_access</tt> e 
modificare <file>/etc/security/access.conf</file>, che permette di 
configurare in modo più generico e preciso il controllo degli 
accessi, ma (sfortunatamente) è carente di decenti messaggi di log 
(il logging all'interno di PAM non è standardizzato ed è un problema 
decisamente poco remunerativo per dedicarvisi). Ritorneremo su  
<file>access.conf</file> più avanti.

<p>Per ultimo, ma non per questo meno importante, per impostare i 
limiti delle risorse per gli utenti, dovrebbe essere presente in 
<file>/etc/pam.d/login</file> la riga seguente:

<example>
  session  required   pam_limits.so
</example>

<p>
Questa riga riduce le risorse di sistema che gli utenti possono usare
(vedete più avanti in <ref id="user-limits">). 
Per esempio, potreste ridurre il numero
di login concorrenti (di un certo gruppo di utenti, o globalmente)
ammessi, il numero di processi, la dimensione della memoria etc. etc.

<p>
Ora aprite  <file>/etc/pam.d/passwd</file> e cambiate la prima riga. Dovreste
aggiungere l'opzione "md5" per usare le password MD5, cambiare la 
lunghezza minima delle password da 4 a 6 (o più) e stabilire una lunghezza
massima, se lo desiderate. La riga che ne risulta dovrebbe essere simile a:

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

<p>Se volete una protezione per il comando su, in modo che solo alcune
persone possano usarlo per diventare root sul sistema, è necessario
aggiungere un nuovo gruppo "wheel" al sistema (questo è il modo più
pulito, poiché nessun file ha permessi relativi a quel gruppo). Aggiungete
root e  gli altri utenti che dovrebbero poter usare il
comando <prgn>su</prgn> a questo gruppo.  Quindi aggiungete la
seguente riga a <file>/etc/pam.d/su</file>:

<example>
  auth        requisite   pam_wheel.so group=wheel debug
</example>

<p>
Questo garantisce che solo le persone del gruppo "wheel" possano usare
<prgn>su</prgn> per diventare root. Gli altri utenti non saranno in grado di 
diventare root. Infatti otterranno un messaggio di errore se cercheranno
di diventarlo.

<p>
Se volete che solo certi utenti siano autenticati da un servizio PAM,
ciò è ottenibile abbastanza facilmente usando file contenenti gli utenti
a cui è permesso autenticarsi. Immaginate di volere che solo l'utente 'ref' 
possa autenticarsi tramite <prgn>ssh</prgn>. Allora dovreste inserirlo in 
<file>/etc/sshusers-allowed</file> e scrivere la riga seguente 
in <file>/etc/pam.d/ssh</file>:

<example>
  auth        required    pam_listfile.so item=user sense=allow file=/etc/sshusers-allowed onerr=fail
</example>


<p>Siccome ci sono state un certo numero di cosiddette vulnerabilità 
provocate da file temporanei insicuri, thttpd ne è un esempio 
(vedete <url id="http://www.debian.org/security/2005/dsa-883" 
name="DSA-883-1">), <package>libpam-tmpdir</package> è un buon 
pacchetto da installare per risolvere la questione. Tutto quello che 
dovrete fare è aggiungere quanto segue a 
<file>/etc/pam.d/common-session</file>:

<example>
 session    optional     pam_tmpdir.so
</example>

C'era anche stata una discussione sull'aggiungerlo come
predefinito in etch. Per maggiori informazioni vedete 
<url id="http://lists.debian.org/debian-devel/2005/11/msg00297.html">.

<p>L'ultimo suggerimento, ma come al solito, non per questo meno 
importante degli altri, è quello di creare il file 
<file>/etc/pam.d/other</file> ed inserirvi le 
seguenti righe:

<example>
  auth     required       pam_securetty.so
  auth     required       pam_unix_auth.so
  auth     required       pam_warn.so
  auth     required       pam_deny.so
  account  required       pam_unix_acct.so
  account  required       pam_warn.so
  account  required       pam_deny.so
  password required       pam_unix_passwd.so
  password required       pam_warn.so
  password required       pam_deny.so
  session  required       pam_unix_session.so
  session  required       pam_warn.so
  session  required       pam_deny.so
</example>

<p>
Queste righe forniranno una buona configurazione di base per
tutte le applicazioni che supportano PAM (l'accesso viene negato
in modo predefinito).








<sect1 id="user-limits">Limitare l'uso delle risorse: il file <file>limits.conf</file>

<p>Questo file è molto importante in quanto permette di definire dei
limiti nell'utilizzo delle risorse per gli utenti del sistema. Nelle 
vecchie versioni di Debian questo file si trovava in 
<file>/etc/limits.conf</file>, ma nelle nuove versioni (che utilizzano 
PAM) questo file è stato spostato in 
<file>/etc/security/limits.conf</file>. 

<p>Se non si pongono dei limiti all'utilizzo delle risorse del 
computer, <em>qualsiasi</em> utente che abbia accesso ad una shell 
sul sistema (o anche un intruso che abbia compromesso il sistema 
tramite un servizio o un demone) può usare tutta la CPU, la RAM, 
lo stack e le altre risorse a disposizione del sistema. Questo 
problema di <em>esaurimento delle risorse</em> può essere corretto 
usando PAM.

<p>Esiste il modo di specificare dei limiti sulle risorse in alcuni 
tipi di shell (per esempio, <prgn>bash</prgn> ha la direttiva 
<prgn>ulimit</prgn>, vedete la pagina di manuale <manref section="1" 
name="bash">), ma poiché in generale ogni shell può impostare, su 
una data risorsa, gli stessi limiti in maniera diversa, o non 
permette di impostarli affatto, e poiché l'utente può cambiare shell 
(vedete la pagina di manuale <manref section="1" name="chsh">) si 
consiglia di impostare tali limiti utilizzando i moduli PAM in quanto 
tali limiti verranno rispettati indipendentemente dalla shell usata 
e verranno applicati anche ai moduli PAM che non hanno alcuna 
relazione con il tipo di shell.

<p>I limiti sull'utilizzo delle risorse vengono fatti rispettare dal 
kernel e si configurano tramite il file <file>limits.conf</file>. 
Inoltre, le configurazioni PAM dei vari servizi hanno la necessità di poter 
accedere alle corrette impostazioni PAM. Potete controllare quali 
servizi siano sotto controllo ed imporre dei limiti eseguendo il 
seguente comando:

<example>
$ find /etc/pam.d/ \! -name "*.dpkg*" | xargs -- grep limits |grep -v ":#"
</example>

<p>Solitamente, <file>login</file>, <file>ssh</file> ed i gestori di 
sessioni grafiche (<file>gdm</file>, <file>kdm</file> o 
<file>xdm</file>) 
dovrebbero occuparsi di far rispettare i limiti sull'utilizzo delle 
risorse, ma questo compito potrebbe anche essere delegato ad altri 
file di configurazione di PAM, magari inseriti in <file>cron</file>, 
per prevenire che i demoni di sistema si approprino di tutte le risorse 
disponibili. 

<p>I particolari limiti imposti all'uso di risorse per il proprio 
sistema dipendono dalle risorse a disposizione del sistema stesso, 
questo è uno dei motivi per cui non vengono creati dei limiti 
nell'installazione predefinita di Debian. 

<p>Per esempio, nelle righe seguenti c'é un estratto di un file di 
configurazione che imposta, per ogni utente, un limite massimo di 
100 processi in esecuzione contemporanea (per evitare che l'utilizzo 
indiscriminato di <em>fork()</em> blocchi il sistema), un limite 
massimo di occupazione di memoria per ogni processo di 10MB ed un 
limite massimo di 10 login contemporanei. Gli utenti nel gruppo 
<tt>adm</tt> hanno dei limiti  più alti e se vogliono possono 
produrre dei file core (c'é solo un limite <em>soft</em> sui file 
core).

<p>
<example>
*              soft    core            0
*              hard    core            0
*              hard    rss             1000
*              hard    memlock         1000
*              hard    nproc           100
*              -       maxlogins       1
*              hard    data            102400
*              hard    fsize           2048
@adm           hard    core            100000
@adm           hard    rss             100000
@adm           soft    nproc           2000
@adm           hard    nproc           3000
@adm           hard    fsize           100000
@adm           -       maxlogins       10
</example>

<p>I limiti che un utente normale (inclusi i demoni di sistema) 
avrebbe sono elencabili dal comando: 

<example>
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 2048
max locked memory     (kbytes, -l) 10000
max memory size       (kbytes, -m) 10000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 100
virtual memory        (kbytes, -v) unlimited
</example>

<p>E questi sono i limiti per un utente con poteri amministrativi:

<example>
$ ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) 102400
file size             (blocks, -f) 100000
max locked memory     (kbytes, -l) 100000
max memory size       (kbytes, -m) 100000
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) 2000
virtual memory        (kbytes, -v) unlimited
</example>


<p>Per ulteriori informazioni leggete:
<list>

<item><url
id="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html"
name="PAM reference guide for available modules (Il manuale di riferimento per PAM sui moduli disponibili)">

<item><url
id="http://www.samag.com/documents/s=1161/sam0009a/0009a.htm"
name="PAM configuration article (Articolo sulla configurazione di PAM )">.

<item> <url
id="http://seifried.org/security/os/linux/20020324-securing-linux-step-by-step.html"
name="Seifried's Securing Linux Step by Step (Rendere sicuro Linux passo dopo passo)"> 
Nella sezione <em>Introduzione ai limiti per gli utenti</em>.

<item><url id="http://seifried.org/lasg/users/" name="LASG"> nella sezione
<em>Limitare e monitorare gli utenti</em>.

</list>




<sect1>Procedura di autenticazione degli utenti: 
modificare <file>/etc/login.defs</file>



<p>Il passo successivo è modificare la configurazione base e le 
azioni da effettuare ogni volta che un utente effettua il login. 
Notate che questo file non è parte dei file di configurazione usati 
da PAM, bensì influenza il comportamento dei programmi <tt>login</tt> 
e <tt>su</tt>, perciò non vi è alcuna necessità di modificarlo nel 
caso in cui questi due programmi non siano coinvolti nelle operazioni 
del sistema (notate che  ad esempio il programma <prgn>getty</prgn>, 
che presiede all'avvio delle console creando il prompt iniziale del 
login, invoca il comando <prgn>login</prgn>).


<example>
  FAIL_DELAY          10
</example>

<p>
Questa variabile è preferibile impostarla con un valore alto in modo da
rendere  difficile  l'uso di  un  terminale  per  autenticarsi con  un
attacco a forza bruta. Se una  password viene digitata in modo errato,
il possibile  attaccante (o l'utente) dovrà attendere  10 secondi per
riavere  un nuovo prompt  di autenticazione e questo è già un tempo 
sufficiente quando viene usato per testare una password. 
Attenzione, questa precauzione  è  inutile  se  si  usano altri 
programmi  al  posto  di <prgn>getty</prgn> come ad esempio 
<prgn>mingetty</prgn>.

<example>
  FAILLOG_ENAB        yes
</example>

Se si abilita questa variabile, la fallita autenticazione verrà riportata 
nei log. Questo è fondamentale per tenere traccia di chiunque provi degli  
attacchi a forza bruta.

<example>
  LOG_UNKFAIL_ENAB    yes
</example>


<p>Nel caso venga impostata tale variabile a 'yes' il programma 
memorizzerà i nomi utenti non presenti sul sistema, nel caso in cui 
la procedura di login fallisca  per tale ragione. &Egrave; comunque 
consigliabile impostare tale opzione a 'no' (ovverosia lasciare il 
valore predefinito) in quanto è possibile che un utente, 
inavvertitamente, scriva la propria password al posto del suo nome 
utente al prompt di login. Se la variabile viene impostata a 'yes', 
la password dell'utente verrà registrata. Nel caso in cui la 
variabile sia impostata al valore 'yes', sarà importante assegnare 
appropriati permessi ai file di log che registrano quel tipo di 
informazioni (per esempio, potreste impostarli a 640 ed assegnarli 
ad un gruppo appropriato quale ad esempio quello degli amministratori).

<example>
  SYSLOG_SU_ENAB      yes
</example>

<p>Questo abiliterà il logging dei tentativi di esecuzione del
comando <prgn>su</prgn> in <file>syslog</file>. Questione  molto
importante su una macchina seria ma attenzione che può creare dei
problemi con la privacy.

<example>
  SYSLOG_SG_ENAB      yes
</example>

<p>
&Egrave; la stessa di <var>SYSLOG_SU_ENAB</var> ma si 
applica al programma <prgn>sg</prgn>.

<example>
  MD5_CRYPT_ENAB      yes
</example>

<p>
Come detto in precedenza, le password di tipo MD5 riducono 
notevolmente il problema di attacchi da dizionario, poiché 
si possono usare password più lunghe. Se state usando slink, 
leggete la documentazione di MD5 prima di abilitare questa
opzione, in alternativa verrà impostata con PAM.

<example>
  PASS_MAX_LEN        50
</example>

<p>
Se sono attive le password di tipo MD5 nella configurazione di 
PAM, allora questa variabile dovrebbe essere impostata con lo 
stesso valore di cui sopra.



<sect1>Restrizioni ftp: modificare il file <file>/etc/ftpusers</file>



<p>
Il file <file>/etc/ftpusers</file> contiene l'elenco degli utenti che
non  sono  autorizzati ad  autenticarsi  all'host  usando il  servizio
ftp. Solo usando  questo metodo potete autorizzare gli  utenti ad 
accedere all'ftp (solitamente questo è  sconsigliato poiché  usa le  
password in chiaro). Se i demoni attivi supportano PAM, si può anche 
usare questo metodo per autorizzare o negare agli utenti l'accesso ai 
servizi.

<p>
FIXME (BUG): questo è un bug di Debian, la configurazione predefinita 
<em>non</em> include negli <file>ftpusers</file> tutti gli utenti 
amministratori (in <package>base-passwd</package>).

<p>
Un sistema utile per aggiungere  al file <file>/etc/ftpusers</file> 
tutti gli account di sistema è eseguire

<example>
$ awk -F : '{if ($3<1000) print $1}' /etc/passwd > /etc/ftpusers <!-- ' -->
</example>


<sect1>Utilizzo di su



<p>
Se veramente gli utenti hanno la necessità di diventare super user
sul vostro sistema, ad esempio per installare dei pacchetti o
aggiungere utenti, potete utilizzare il comando <prgn>su</prgn> per
cambiare la vostra identità. Dovreste tentare di evitare ogni
accesso come utente root ed utilizzare invece <prgn>su</prgn>. 
Al momento, la soluzione migliore è rimuovere <prgn>su</prgn> e 
passare a <prgn>sudo</prgn>, che consente una scelta più ampia di 
soluzioni rispetto a <prgn>su</prgn>. 
Ad ogni modo, <prgn>su</prgn> è più 
comune  visto che viene utilizzato su numerosi altri Unix.



<sect1>Utilizzo di sudo



<p>
<prgn>sudo</prgn> permette agli utenti di eseguire determinati comandi
con l'identità di un altro  utente, perfino come root. Se l'utente 
viene aggiunto a <file>/etc/sudoers</file> e si autentica 
correttamente, é in grado di eseguire comandi che sono stati definiti 
in <file>/etc/sudoers</file>. Violazioni, come una password non 
corretta o il tentativo di eseguire  un programma non permesso, vengono
registrati e notificati via mail a root.



<sect1>Non permettere accessi per amministrazione remota



<p>
Per impedire il login da remoto di account amministrativi dovete 
modificare <file>/etc/security/access.conf</file>. In 
questo modo gli utenti dovranno usare <prgn>su</prgn> (o 
<prgn>sudo</prgn>) e così rimarrà sempre traccia che un utente
locale vuole usare i privilegi di amministratore.

<p>Dovete aggiungere la seguente riga a <file>/etc/security/access.conf</file>, 
il file di configurazione predefinito di Debian ha una riga simile
commentata:

<example>
   -:wheel:ALL EXCEPT LOCAL
</example>

<p>Ricordate di attivare il modulo <tt>pam_access</tt> per ogni 
servizio (o configurazione predefinita) in <file>/etc/pam.d/</file> 
se desiderate che le modifiche al file 
<file>/etc/security/access.conf</file> producano il 
risultato desiderato.





<sect1 id="user-restrict">Restrizioni agli utenti per l'accesso

<p>A volte potreste pensare di avere la necessità di creare utenti
nel vostro sistema locale per fornire un determinato servizio (pop3
mail o ftp). Prima di fare ciò, ricordatevi che 
l'implementazione di PAM in Debian GNU/Linux permette di validare
utenti con un'ampia varietà di servizi di directory esterni (radius,
ldap, ecc.) forniti dai pacchetti libpam.

<p>
Se gli utenti devono essere creati ed è possibile accedere al sistema
da remoto, tenete presente che gli utenti potranno effettuare il
login nel sistema. Potete rimediare a questo assegnando agli utenti una
shell vuota (<file>/dev/null</file>) (dovrebbe essere nell'elenco 
<file>/etc/shells</file>). Se volete permettere agli utenti di
accedere al sistema limitando i loro movimenti, potete utilizzare
<file>/bin/rbash</file>, equivalente ad aggiungere l'opzione
<tt>-r</tt> a <prgn>bash</prgn> (<em>RESTRICTED SHELL</em>, vedete
<manref name="bash" section="1">). Notate che persino con una
shell limitata, un utente che accede ad un programma interattivo (che
potrebbe permettere l'esecuzione di una sub-shell) potrebbe aggirare
i limiti della shell stessa.

<p>
Debian attualmente fornisce nella versione unstable (e dovrebbe essere
incluso nelle prossime versioni stabili) il modulo
<file>pam_chroot</file> (in <package>libpam-chroot</package>). Un'alternativa 
è usare <prgn>chroot</prgn> sul servizio che fornisce il
login remoto (<prgn>ssh</prgn>, <prgn>telnet</prgn>)
<footnote>
<package>libpam-chroot</package> non è ancora stato collaudato in maniera
approfondita, funziona per <prgn>login</prgn> ma potrebbe non essere 
semplice configurare un ambiente per altri programmi.
</footnote>.

<p>
Se desiderate limitare il <em>quando</em> gli utenti possono accedere al
sistema dovrete configurare <file>/etc/security/access.conf</file> per i 
vostri bisogni.

<p>
Per informazioni su come ingabbiare con <prgn>chroot</prgn> gli 
utenti che accedono al sistema mediante il servizio <prgn>ssh</prgn> 
vedete in <ref id="chroot-ssh-env">.






<sect1>Esame delle attività degli utenti

<p>Nel caso in cui siate molto sospettosi, potreste configurare 
l'intero sistema in modo che esami continuamente tutte le attività 
che gli utenti svolgono nel sistema. Questa sezione presenta alcuni 
consigli e introduce alcuni strumenti utili.




<sect2>Controllo di input e output con script

<p>Potete utilizzare il comando <prgn>script</prgn> per controllare 
sia ciò che gli utenti stanno eseguendo, sia i risultati di questi 
comandi. Non potete impostare <prgn>script</prgn> come una shell 
(anche se lo aggiungete a <file>/etc/shells</file>), ma potete far 
sì che il file di inizializzazione della shell esegua i seguenti 
comandi:

<example>
umask 077
exec script -q -a "/var/log/sessions/$USER"
</example>

<p>Di certo, se fate questo globalmente, per tutto il sistema, 
impedirete che la shell legga i file di inizializzazione 
personali (dato che la shell viene sovrascritta da 
<prgn>script</prgn>). Un'alternativa è fare questo nei file di 
inizializzazione dell'utente (ma poi l'utente lo potrà rimuovere, 
vedete i commenti sotto su questo).


<p>Dovrete anche impostare i file nella directory da controllare 
(nell'esempio <file>/var/log/sessions/</file>) così che gli utenti 
possano scrivere in essa ma non possano rimuovere il file. Questo può 
essere fatto, per esempio, creando i file di sessione dell'utente in 
anticipo ed impostandoli con l'opzione <em>append-only</em> 
utilizzando <prgn>chattr</prgn>.

<p>Un'utile alternativa per gli amministratori di sistema, che include
l'informazione della data, sarebbe:

<example>
umask 077
exec script -q -a "/var/log/sessions/$USER-`date +%Y%m%d`"
</example>






<sect2>Uso del file storico dei comandi della shell

<p>Se volete rivedere i comandi che l'utente ha usato sulla shell 
(ma non qual'è stato il risultato di quei comandi), potete impostare 
un <file>/etc/profile</file> a livello di sistema, che configuri 
l'ambiente in modo tale che tutti i comandi vengano registrati in un 
file storico dei comandi.
La configurazione a livello di sistema deve essere fatta in modo tale 
che gli utenti non possano rimuovere le capacità di verifica e 
registrazione della propria shell. Questo è qualcosa di specifico 
della shell, perciò assicuratevi che tutti gli utenti stiano usando 
una shell che supporti questa funzionalità.

<p>Per esempio, per la bash il file di configurazione 
<file>/etc/profile</file> dovrebbe essere impostato come di seguito 
<footnote>
          Impostare HISTSIZE ad un valore molto grande può causare 
          problemi in qualche shell, poiché lo storico dei comandi 
          viene mantenuto in memoria per ogni sessione dell'utente. 
          Potrebbe essere più sicuro impostarlo ad un valore alto 
          quanto basta e fare il backup del file dello storico dei 
          comandi degli utenti (se per qualche ragione se ne avesse 
          bisogno).
</footnote>
:

<example>
  HISTFILE=~/.bash_history
  HISTSIZE=10000
  HISTFILESIZE=999999
  # Don't let the users enter commands that are ignored
  # in the history file
  HISTIGNORE=""
  HISTCONTROL=""
  readonly HISTFILE
  readonly HISTSIZE
  readonly HISTFILESIZE
  readonly HISTIGNORE
  readonly HISTCONTROL
  export HISTFILE HISTSIZE HISTFILESIZE HISTIGNORE HISTCONTROL
</example>

<p>Perché questo funzioni, l'utente deve solo poter aggiungere 
informazioni al file <file>.bash_history</file>. Dovrete perciò 
<em>anche</em> impostare l'opzione <em>append-only</em> per 
tutti gli utenti con il programma <prgn>chattr</prgn> per 
<file>.bash_history</file>
<footnote>
          Senza l'opzione append-only gli utenti potrebbero svuotare 
          il contenuto del file storico dei comandi lanciando 
          <tt> > .bash_history</tt>.
</footnote>.

<p>Tenete conto che potreste introdurre la configurazione di cui 
sopra nel <file>.profile</file> dell'utente. Ma poi dovreste 
configurare i permessi in modo tale che impediscano all'utente di 
modificare questo file. Questo comprende che la cartella home 
dell'utente <em>non</em> appartenga all'utente (poiché potrebbe 
rimuovere il file in altro modo), ma allo stesso tempo abilitare 
l'utente a leggere il file di configurazione <file>.profile</file> 
e scrivere  sul file <file>.bash_history</file>. Se pensate di 
fare in questo modo, sarebbe bene impostare l'opzione 
<em>immutable</em> (usando <prgn>chattr</prgn>) anche per
<file>.profile</file>.




<sect2>Completate il controllo dell'utente con le utility per gli account


<p>L'esempio precedente è un modo semplice per configurare il 
controllo dell'utente ma potrebbe non essere utile per sistemi 
complessi o per quelli nei quali l'utente non usa per niente o 
quasi le shell. Se questo è il vostro caso, potete dare un'occhiata 
alla utility per account <package>acct</package>. Questo programma
registrerà tutti i comandi dati dagli utenti o dai processi nel 
sistema, a scapito dello spazio disco.

<p>All'attivazione dell'accounting tutte le informazioni su processi 
ed utenti verranno mantenute sotto <file>/var/account/</file>, o più 
specificamente nel file <file>pacct</file>. Il pacchetto per l'account 
include alcuni strumenti, come <prgn>sa</prgn>, <prgn>ac</prgn> e 
<prgn>lastcomm</prgn>, che permettono di analizzare questi dati.

<sect2>Altri metodi di controllo dell'utente

<p>Se siete completamente paranoici e volete controllare ogni comando 
dato dall'utente, potete prendere il codice sorgente della 
<prgn>bash</prgn>, modificarlo, e fare in modo che spedisca tutto 
quello che l'utente batte sulla tastiera in un altro file. Oppure avere 
<package>ttysnoop</package> che controlla costantemente ogni nuova 
ttys<footnote>
          Le ttys vengono generate per gli accessi locali e remoti tramite
          ssh e telnet.
</footnote>
e scarica l'output in un file. 

Un altro programma utile è <package>snoopy</package> (vedete anche la
<url id="http://sourceforge.net/projects/snoopylogger/" 
name="pagina del progetto">, un programma trasparente per l'utente 
che si aggancia come fa una funzione di una libreria, fornendo un 
modo per incapsulare una chiamata <var>execve()</var>, così ogni 
comando eseguito viene registrato in <prgn>syslogd</prgn> usando la 
funzione <tt>authpriv</tt> (di solito messa in 
<file>/var/log/auth.log</file>).




<sect1>Uno sguardo ai profili utente

<p>
Se volete <em>vedere</em> cosa fanno solitamente gli utenti quando 
si connettono, potete usare il database <file>wtmp</file> che 
include tutte le informazioni di login. Il file può essere 
processato con diverse utility, tra cui <prgn>sac</prgn> che può 
restituire un profilo per ogni utente che mostra in quale arco di 
tempo si è connesso.

<p>Nel caso in cui abbiate attivato l'accounting, potete anche 
utilizzare gli strumenti da esso forniti per determinare quando 
gli utenti accedono al sistema e che cosa eseguono.





<sect1>Impostare delle umask per gli utenti


<p>In base al vostro codice di condotta riguardo agli utenti, potreste
voler cambiare il modo in cui gli utenti si scambiano informazioni,
ossia quali siano i permessi predefiniti dei nuovi file creati dagli
utenti.

<p>L'impostazione predefinita di Debian per l'<tt>umask</tt> è 
<em>022</em>, questo significa che i file (e le directory) possono 
essere lette e visitate dai membri del gruppo dell'utente e da 
qualsiasi altro utente del sistema. Questa definizione si trova nel 
classico file di configurazione <file>/etc/profile</file>, che viene
utilizzato da tutte le shell.

<p>Se il valore predefinito da Debian è troppo permissivo per il vostro 
sistema potete cambiare l'impostazione dell'umask per tutte le shell. 
Valori più restrittivi per umask sono 027 (non è consentito l'accesso 
ai nuovi file ad <em>altri</em> gruppi, come per esempio agli altri 
utenti del sistema) o 077 (nessun accesso ai nuovi file è consentito ai 
membri del gruppo dell'utente). Debian (come comportamento 
predefinito<footnote>
          Come definito in  <file>/etc/adduser.conf</file> 
          (USERGROUPS=yes). Potete variare questo comportamento 
          modificando il valore da 'yes' a 'no', anche se non è 
          raccomandato.
</footnote>) 
crea un gruppo per ciascun utente, cosi è solamente un solo utente 
ad essere incluso nel suo gruppo. Di conseguenza 027 e 077 sono 
equivalenti, poiché il gruppo dell'utente contiene unicamente se
stesso.

<p>Questo cambiamento viene impostato definendo una buona 
<tt>umask</tt> per tutti gli utenti. Potete modificare questo valore 
inserendo una chiamata ad <prgn>umask</prgn> nel file di 
configurazione della shell: <file>/etc/profile</file> (letto da tutte 
le shell Bourne-compatibili), <file>/etc/csh.cshrc</file>,
<file>/etc/csh.login</file>, <file>/etc/zshrc</file> e probabilmente 
altri (a seconda delle shell che avrete installato nel vostro 
sistema). Potete anche modificare il parametro <var>UMASK</var> in 
<file>/etc/login.defs</file>. Di tutti questi valori, l'ultimo che 
verrà caricato determinerà il valore finale del parametro. 
L'ordine è: il file predefinito è quello di configurazione della 
shell dell'utente (cioè <file>/etc/profile</file> ed altri file 
globali di sistema relativi alla configurazione), successivamente 
la configurazione personale della shell dell'utente (ovvero il suo 
<file>~/.profile</file>, <file>~/.bash_profile</file>, etc...). 
Alcune shell possono essere eseguite con un'opzione 
<em>nologin</em>, che potrebbe evitare di caricare alcuni di questi 
file. Vedete la pagina di manuale della vostra shell per maggiori 
informazioni.

<p>Per connessioni che fanno uso di <prgn>login</prgn> viene usata, 
prima di tutte le altre, la configurazione di UMASK definita in 
<file>/etc/login.defs</file>. Ad ogni modo questo 
valore non viene applicato ai programmi eseguiti dall'utente che 
non usano <prgn>login</prgn>, come ad esempio quelli eseguiti per 
mezzo di <prgn>su</prgn>, <prgn>cron</prgn> o <prgn>ssh</prgn>.

<p>Non dimenticate di rivedere e magari modificare i file che 
iniziano con il punto sotto <file>/etc/skel/</file> dato che 
questi saranno i file predefiniti dei nuovi utenti quando verranno 
creati con il comando <prgn>adduser</prgn>. I file di Debian 
predefiniti che iniziano con il punto non includono alcuna 
chiamata a <prgn>umask</prgn>, ma se ce ne dovessero essere, i nuovi
utenti creati potrebbero avere valori differenti.

<p>Notate comunque che gli utenti possono modificare l'impostazione 
della propria a propria <tt>umask</tt> se lo vogliono, rendendola 
più o meno permissiva modificando i propri file che iniziano con il 
punto.

<p>Il pacchetto <package>libpam-umask</package> regola 
l'<tt>umask</tt> predefinita degli utenti utilizzando PAM. 
Aggiungete la seguente riga a <file>/etc/pam.d/common-session</file>
dopo aver installato il pacchetto:

<example>
session    optional     pam_umask.so umask=077
</example>

<p>Infine, dovreste prendere in considerazione il cambiamento 
dell'umask predefinita 022 di root (come definita in 
<file>/root/.bashrc</file>) con una umask più restrittiva. Questo 
impedirà all'amministratore di sistema di rimuovere inavvertitamente 
file sensibili quando lavora come root in directory leggibili da 
tutti (come <file>/tmp</file>) e averli disponibili per il proprio 
utente medio.




<sect1>Porre limiti a ciò a cui gli utenti possono accedere


<p>FIXME. Dei contenuti sono necessari. Descrivere le conseguenze 
relative al cambiare i permessi ai pacchetti quando si aggiornano 
(ed un admin paranoico dovrebbe mettere in <prgn>chroot</prgn> i 
suoi utenti, comunque), se non utilizzando 
<prgn>dpkg-statoverride</prgn>.  

<p>
Se dovete dare accesso shell
agli utenti, pensateci bene. Un utente, a meno che non sia in un
ambiente pieno di restrizioni (come una gabbia <tt>chroot</tt>), può
carpire molte informazioni sul sistema, tra cui:



<list>

<item>
<p>alcuni file di configurazione in <file>/etc</file>. 
Comunque i permessi predefiniti per file
contenenti informazioni sensibili, in Debian (per esempio file
contenenti password), prevengono l'accesso ad informazioni critiche. 
Per vedere quali file sono accessibili solo da root basta un 
<tt>find /etc -type f -a -perm 600 -a -uid 0</tt> eseguito da superuser.
<item>
<p>i pacchetti installati, sia guardando il database dei pacchetti in
<file>/usr/share/doc</file> che tirando ad indovinare guardando gli 
eseguibili e le librerie installate.
<item>
<p>alcuni file di log in <file>/var/log</file>. Notate inoltre che alcuni file di
log sono accessibili solo da root e dal gruppo <tt>adm</tt> (provate un
<tt>find /var/log -type f -a -perm 640</tt>) e alcuni sono perfino
disponibili solo a root (provate un 
<tt>find /var/log -type f -a -perm 600 -a -uid 0</tt>).

</list>

<p>
Cosa può visualizzare un utente nel vostro sistema? Probabilmente un
sacco di cose, provate questo (fate un respiro profondo):

<example>
  find / -type f -a -perm +006 2>/dev/null  
  find / -type d -a -perm +007 2>/dev/null  
</example>

<p>
L'output è la lista dei file che un utente può <em>vedere</em> e le
directory a cui ha accesso.



<sect2 id="limit-user-perm">Limitare l'accesso alle 
informazioni di altri utenti


<p>
Se permettete l'accesso tramite shell da parte degli utenti potrebbe
essere desiderabile limitare quali informazioni di altri utenti possano
vedere. Gli utenti con accesso alla shell tendono a creare un gran numero
di file nella loro $HOME: caselle di posta, documenti 
personali, configurazioni di applicazioni per X/GNOME/KDE...

<p>In Debian ogni utente viene creato con un gruppo associato e due 
utenti non appartengono mai allo stesso gruppo. Questo è il 
comportamento predefinito: quando l'utente X viene creato, viene 
creato anche un gruppo di nome X e l'utente viene assegnato a quel 
gruppo. Questo evita il concetto di gruppo di <em>utenti</em> che 
renderebbe più difficile per gli utenti stessi nascondere 
informazioni agli altri.

<p>
Tuttavia, le directory <var>$HOME</var> degli utenti vengono create 
con permessi 0755 (leggibili dal gruppo e da tutti gli altri). I 
permessi di gruppo non sono un problema perché solo l'utente 
appartiene a quel gruppo, ma i permessi globali potrebbero (ma anche 
no) essere un problema, in relazione alle vostre politiche locali di 
sicurezza.

<p>
Questo comportamento può essere cambiato in modo che la creazione di
un utente fornisca permessi diversi su <var>$HOME</var>. 
Per cambiare il comportamento
per i <em>nuovi</em> utenti, quando vengono creati, nel file di 
configurazione <file>/etc/adduser.conf</file> cambiate 
<em>DIR_MODE</em> in 0750 (nessun permesso di lettura globale).

<p>
Gli utenti possono ancora condividere informazioni, ma non direttamente
nelle loro directory <var>$HOME</var>, a meno che non cambino i loro permessi.

<p>
Notate che questo impedirà agli utenti di creare la loro 
pagina web personale nella directory <file>~/public_html</file>
poiché, se è installato, il web server non sarà in grado di leggere 
la directory <var>$HOME</var> e di conseguenza neanche la directory 
sottostante <file>public_html</file>.
Se volete permettere agli utenti di pubblicare pagine HTML nella loro 
directory <file>~/public_html</file>, modificate <em>DIR_MODE</em> in
modo che abbia permessi 0751. Questo consentirà al server web di 
accedere a quella directory (che dovrebbe avere permessi 0755) e 
fornire il contenuto pubblicato dagli utenti. 
Naturalmente qui stiamo solamente parlando di una configurazione 
minima, quella predefinita; generalmente gli utenti vengono 
autorizzati a personalizzare i file a loro piacimento, oppure si 
potrebbe voler destinare i contenuti per il web in una posizione 
che non sia una sottodirectory della <var>$HOME</var> di un utente.


<sect1 id="user-pwgen">Generare password per gli utenti



<p>
Ci sono molti casi in cui un amministratore ha la necessità di creare
molti account e di fornire password per ognuno di essi. Ovviamente
l'amministratore potrebbe semplicemente scegliere come password il
nome scelto dall'utente per l'account, ma ciò non sarebbe molto furbo
per quanto riguarda la sicurezza. Un approccio migliore consiste nell'usare
un programma per generare password. Debian offre i 
pacchetti <package>makepasswd</package>,
<package>apg</package> e <package>pwgen</package>, 
che forniscono programmi (con nome uguale a quello del
pacchetto) che possono essere usati per questo scopo. <prgn>makepasswd</prgn>
genererà password totalmente casuali, con enfasi sulla sicurezza piuttosto
che sulla pronunciabilità, mentre <prgn>pwgen</prgn> 
cercherà di creare password senza
senso ma pronunciabili (ovviamente questo dipende dalla lingua madre).
<prgn>Apg</prgn> ha algoritmi per entrambi 
(per questo programma esiste una versione
client/server ma non è inclusa nel pacchetto Debian).

<p>
<prgn>passwd</prgn> non permette assegnamento non interattivo di password
(poiché usa direttamente l'accesso tty). Se volete cambiare password
mentre state creando un gran numero di utenti, potete creare questi ultimi
usando <prgn>adduser</prgn> con l'opzione <tt>--disabled-login</tt> e 
poi usando <prgn>chpasswd</prgn>
<footnote>
<prgn>chpasswd</prgn> non può gestire la generazione 
di password MD5, quindi necessita della password in
forma criptata prima dell'uso, con l'opzione <tt>-e</tt>.
</footnote>
(incluso nel pacchetto <package>passwd</package>,
che è già installato). Se volete
usare un file contenente tutte le informazioni 
per creare gli utenti come un processo batch può 
essere utile usare <prgn>newusers</prgn>.



<sect1>Controllare le password degli utenti



<p>
Le password degli utenti possono talvolta diventare il <em>componente più
debole</em> nella sicurezza di un sistema. Ciò è dovuto alla scelta da parte
degli utenti di password di scarsa qualità per i loro account (e più utenti
hanno accesso più le possibilità che questo accada crescono). Anche se
sono stati impostati controlli con il modulo PAM cracklib e limiti per 
quanto riguarda le password, descritti nella <ref id="auth-pam">, gli utenti 
saranno comunque in grado di usare password deboli. Poiché l'accesso per 
gli utenti potrebbe includerne uno da shell remote (si spera tramite 
<prgn>ssh</prgn>) è importante che la password sia robusta e quindi 
difficile da indovinare, soprattutto se fossero in qualche modo in 
grado di raccogliere importanti informazioni come i nomi degli utenti 
o anche i file <file>passwd</file> e <file>shadow</file> stessi.

<p>
Un amministratore di sistema deve, ipotizzando un gran numero di utenti,
controllare se le password scelte siano coerenti con le politiche di sicurezza
adottate. Come effettuare questo controllo? Provando a forzarle come farebbe
una persona che attacca il sistema se avesse accesso alle password criptate
(il file <file>/etc/shadow</file>).

<p>
Un amministratore di sistema può usare <package>john</package> o
<package>crack</package> (entrambi sono password crackers a forza 
bruta) insieme ad un adeguato elenco di parole per controllare 
le password degli utenti e prendere i provvedimenti del caso 
quando dovesse rilevare una password debole. Potete cercare i 
pacchetti di Debian GNU che contengono elenchi di parole 
eseguendo <prgn>apt-cache search wordlist</prgn>, o visitare 
il classico sito internet 
<url id="ftp://ftp.ox.ac.uk/pub/wordlists"> o
<url id="ftp://ftp.cerias.purdue.edu/pub/dict">.





<sect1 id="idle-logoff">Disconnettere gli utenti inattivi



<p>
Solitamente gli utenti inattivi sono un problema per la sicurezza.
Un utente potrebbe essere inattivo perché è fuori a pranzo o perché
una connessione remota interrotta non è stata ristabilita.
Qualunque sia la ragione, gli utenti inattivi possono essere causa
di problemi:

<list>
<item>
<p>perché la console dell'utente potrebbe non essere bloccata e
un intruso potrebbe accedervi.
<item>
<p>perché un attaccante potrebbe riuscire a riconnettersi ad
una connessione di una rete chiusa ed eseguire comandi sulla
shell remota (questo è abbastanza facile se la shell
remota non è criptata come nel caso di <prgn>telnet</prgn>).

</list>

<p>
Alcuni sistemi remoti sono stati compromessi attraverso un
programma, <prgn>screen</prgn>, inattivo (distaccato). 

<p>
La disconnessione automatica degli utenti inattivi di solito è una
parte della politica di sicurezza che occorre rafforzare. Ci sono
molti modi per realizzarla:

<list>
<item>
<p>se la shell degli utenti è <prgn>bash</prgn>, l'amministratore di sistema
può impostare un valore predefinito per la variabile <tt>TMOUT</tt>
(vedete <manref name="bash" section="1">) che fa sì che la shell disconnetta
automaticamente gli utenti inattivi. Notate che la variabile
va impostata con l'opzione <tt>-o</tt> altrimenti gli utenti saranno
in grado di modificarla o rimuoverla.
<item>
<p>installare <package>timeoutd</package> e configurare 
<file>/etc/timeouts</file> secondo la
propria politica di sicurezza locale. Il demone controllerà
se ci sono utenti inattivi e manderà in time out le loro shell
secondo la configurazione impostata.
<item>
<p>installare <package>autolog</package> e configurarlo per disconnettere gli
utenti inattivi.

</list>

<p>
I demoni <prgn>timeoutd</prgn> e <prgn>autolog</prgn> sono i 
metodi consigliati, dal momento che gli utenti possono 
cambiare la loro shell predefinita o passare ad un'altra 
shell (non controllata) dopo aver avviato la
loro shell predefinita.



<sect id="tcpwrappers">Usare i tcpwrapper



<p>
I TCP wrapper sono stati sviluppati quando ancora non erano
disponibili dei veri filtri di pacchetti ed era necessario
controllare gli accessi. I TCP wrapper permettono di consentire o
negare un servizio ad un host o ad un dominio e di definire 
regole predefinite per consentire o meno l'accesso (tutte eseguite 
a livello applicativo). Se desiderate maggiori informazioni al 
riguardo, date un'occhiata a <manref name="hosts_access" section="5">.

<p>
Molti servizi installati in Debian vengono:

<list>

<item>
<p>lanciati mediante un servizio tcpwrapper (<file>tcpd</file>).
<item>
<p>compilati con il supporto a libwrapper integrato.

</list>

<p>
In un caso, per i servizi configurati mediante
<file>/etc/inetd.conf</file>
(inclusi <prgn>telnet</prgn>, <prgn>ftp</prgn>,
<prgn>netbios</prgn>, <prgn>swat</prgn> e <prgn>finger</prgn>)
il file di configurazione esegue prima <prgn>/usr/sbin/tcpd</prgn>.
Nell'altro, anche se il servizio viene lanciato dal superdemone
<prgn>inetd</prgn>, il supporto per le regole dei tcp wrapper può
essere compilato al suo interno. In Debian, tra i servizi compilati
con il supporto ai tcp wrapper ci sono
<prgn>ssh, portmap, in.talk, rpc.statd, rpc.mountd, gdm, oaf</prgn>
(il demone di attivazione GNOME), <prgn>nessus</prgn> e
molti altri.

<p>
Per vedere quali pacchetti usano i tcpwrapper<footnote>
Sulle vecchie versioni di Debian potreste  voler fare questo:
<example>
  $ apt-cache showpkg libwrap0 | egrep '^[[:space:]]' | sort -u | \
        sed 's/,libwrap0$//;s/^[[:space:]]\+//'
</example>
</footnote>
provate con:

<example>
  $ apt-cache rdepends libwrap0
</example>

<p>
Occorre tenerne conto quando usate <prgn>tcpdchk</prgn>
(molto utile per controllare le regole e la sintassi del
file di configurazione del TCP wrapper).
I servizi compilati col supporto alla libreria wrapper
possono essere aggiunti ai file <file>hosts.deny</file> e
<file>hosts.allow</file> ma <prgn>tcpdchk</prgn> avviserà che
non è in grado di trovare questi servizi, perché li cerca in
<file>/etc/inetd.conf</file> (la pagina man non è molto chiara
su questo punto).

<p>
Di seguito riportiamo un trucchetto; probabilmente il più piccolo
sistema di rivelazione di intrusione possibile. In generale 
dovreste avere una buona politica di firewall come prima linea di difesa ed i
tcp wrapper come seconda linea. Un trucchetto è quello di
impostare un comando <var>SPAWN</var> 

<footnote>
Assicuratevi di usare il maiuscolo altrimenti <em>spawn</em>
non funzionerà.
</footnote>

in <file>/etc/hosts.deny</file> che spedisce
una mail all'utente root ogni volta che un servizio viene negato
attraverso i wrapper:

<example>
  ALL: ALL: SPAWN ( \
    echo -e "\n\
    TCP Wrappers\: Connection refused\n\
    By\: $(uname -n)\n\
    Process\: %d (pid %p)\n\
    User\: %u\n\
    Host\: %c\n\
    Date\: $(date)\n\
  " | /usr/bin/mail -s "Connection to %d blocked" root) &
</example>

<p>
<em>Attenzione</em>: L'esempio sopra è esposto a attacchi di tipo DoS
stabilendo molte connessioni in un breve periodo di tempo. Molte
email causano un elevato I/O di file spedendo solo pochi pacchetti.




<sect id="log-alerts">L'importanza di log e avvisi

<p>
&Egrave; evidente che il modo di trattare log e avvisi è una questione
importante in un sistema sicuro. Supponiamo che un sistema sia
perfettamente configurato e sicuro al 99%. Se viene portato un attacco
al restante 1% e non ci sono misure di sicurezza pronte, innanzitutto a
rilevarlo e poi ad attivare allarmi, il sistema non è per
nulla sicuro.

<p>
Debian GNU/Linux fornisce alcuni strumenti per svolgere l'analisi
dei log, in particolare <package>swatch</package><footnote>

<p>C'è un ottimo articolo in proposito scritto da
<url id="http://www.enteract.com/~lspitz/swatch.html" name="Lance Spitzner">.

</footnote>,
<package>logcheck</package> o <package>log-analysis</package>
(tutti questi programmi avranno bisogno di un po' di personalizzazione per
rimuovere le cose superflue dal rapporto). Potrebbe anche essere
utile, se il sistema si trova nelle vicinanze, avere i log di sistema
stampati su una console virtuale. Questo è utile perché si può (da
lontano) vedere se il sistema sta funzionando correttamente. In
Debian, il file <file>/etc/syslog.conf</file> ha già in partenza una
configurazione predefinita commentata; per abilitarla, togliete i
commenti dalle seguenti righe e riavviate <prgn>syslogd</prgn> 
(<tt>/etc/init.d/syslogd restart</tt>):

<example>
  daemon,mail.*;\
        news.=crit;news.=err;news.=notice;\
        *.=debug;*.=info;\
        *.=notice;*.=warn       /dev/tty8
</example>


<p>Per colorare i log, potete dare un'occhiata a 
<package>colorize</package>, <package>ccze</package> o
<package>glark</package>.
Ci sarebbe molto altro a proposito dell'analisi dei log che non può
ovviamente essere trattato qui, una buona fonte di informazioni è il 
sito <url name="Log Analysis" id="http://www.loganalysis.org/">.
In ogni caso, anche i più avanzati strumenti automatizzati nulla 
possono contro il miglior strumento di analisi: il vostro cervello.





<sect1 id="custom-logcheck">Usare e personalizzare <prgn>logcheck</prgn>


<p>Il pacchetto <prgn>logcheck</prgn> in Debian è diviso in tre parti:
<prgn>logcheck</prgn> (il programma principale),
<package>logcheck-database</package> (un database di espressioni
regolari per il programma) e <package>logtail</package>
(visualizza le righe corrispondenti ai log che non sono stati ancora
visualizzati). In Debian è predefinito (in
<file>/etc/cron.d/logcheck</file>) che <prgn>logcheck</prgn> venga
eseguito giornalmente ogni ora e dopo ogni riavvio del sistema.



<p>Questo strumento, se propriamente configurato, può essere molto 
utile per segnalare all'amministratore eventi inusuali del sistema.
<prgn>logcheck</prgn> può essere completamente personalizzato, in modo
da spedire mail a proposito di eventi registrati nei log che sembrano
degni di attenzione. L'installazione predefinita include profili (per
gli eventi da ignorare e le violazioni delle politiche adottate)
per tre diverse configurazioni (workstation, server e paranoid). Il
pacchetto Debian include un file di configurazione
<file>/etc/logcheck/logcheck.conf</file>, generato dal
programma, che definisce a quale utente vengono spedite le
verifiche. Inoltre fornisce, ai pacchetti che offrono servizi, un modo
per implementare nuove politiche, nelle cartelle:
<file>/etc/logcheck/cracking.d/_packagename_</file>,
<file>/etc/logcheck/violations.d/_packagename_</file>,
<file>/etc/logcheck/violations.ignore.d/_packagename_</file>,
<file>/etc/logcheck/ignore.d.paranoid/_packagename_</file>,
<file>/etc/logcheck/ignore.d.server/_packagename_</file> e
<file>/etc/logcheck/ignore.d.workstation/_packagename_</file>.
Tuttavia, al momento, non molti pacchetti ne fanno uso. Se avete una
politica che può essere utile ad altri utenti, per favore speditela
come rapporto bug per il pacchetto appropriato (come <em>wishlist</em>
bug). Per ulteriori informazioni leggete
<file>/usr/share/doc/logcheck/README.Debian</file>.

<p>Il modo migliore per configurare <prgn>logcheck</prgn> dopo
l'installazione è modificare il suo principale file di configurazione
<file>/etc/logcheck/logcheck.conf</file>. Cambiate l'utente
predefinito (root) a cui verranno spediti i rapporti. Sempre in quel
file di configurazione dovrete anche modificare il livello di
prolissità del rapporto. <package>logcheck-database</package> ha tre
livelli di prolissità, ovvero: workstation, server, paranoid.
"server" è il livello predefinito, "paranoid" è consigliato solo per
le macchine che devono garantire un'alta sicurezza per l'espletamento
di determinati servizi e "workstation" per sistemi relativamente al
riparo, in posizioni non critiche. Se desiderate aggiungere nuovi
file di log dovrete solamente aggiungere righe in
<file>/etc/logcheck/logcheck.logfiles</file>. &Egrave; già
ottimizzato per l'installazione predefinita del demone syslog.

<p>Una volta fatto questo, forse vorrete controllare per i primi
giorni/settimane/mesi le email che vengono spedite. Se vengono spediti
messaggi che non desiderate ricevere, aggiungete le espressioni
regolari (vedete <manref name="regex" section="7"> ed
<manref name="egrep" section="1">) che corrispondono a questi messaggi
in <file>/etc/logcheck/ignore.d.<var>reportlevel</var>/local</file>.
Dovrete cercare di scrivere regole che corrispondano alle righe dei
log. Dettagli su come scrivere regole vengono spiegati in
<file>/usr/share/doc/logcheck-database/README.logcheck-database.gz</file>.
&Egrave; un processo di taratura al quale si deve dedicare il tempo
necessario. Quando i messaggi spediti saranno sempre rilevanti, la messa
a punto potrà considerarsi conclusa. Notate che, anche se
<prgn>logcheck</prgn> è in esecuzione, se  non trova nulla di
rilevante nel sistema non spedirà email (così potrete ricevere un solo
messaggio a settimana, con un po' di fortuna).




<sect1>Configurare il file dove vengono spediti gli avvisi



<p>Debian nasce con una configurazione standard per <tt>syslog</tt>
(in <file>/etc/syslog.conf</file>) che registra i messaggi in file
appropriati a seconda della configurazione del sistema. Dovreste
avere dimestichezza con questo, se così non fosse date un'occhiata
al file <file>syslog.conf</file> ed alla sua documentazione. Se 
intendete mantenere un sistema sicuro dovreste fare attenzione a dove
i messaggi di log vengono spediti, cosicché non passino inosservati.

<p>Per esempio, mandare i messaggi su una console è una 
configurazione utile per sistemi di diversi livelli di produzione. 
Ma per altri sistemi è ugualmente importante aggiungere una nuova 
macchina che faccia da loghost (cioè che riceva i log da tutte le 
altre macchine del sistema).

<p>Dovreste considerare anche la posta di root, molti programmi
per il controllo della sicurezza (come <package>snort</package>)
spediscono gli avvisi a root via posta.
Questa mailbox di solito punta al primo utente creato nel
sistema (controllate <file>/etc/aliases</file>). Preoccupatevi di
mandare la posta di root in qualche posto dove verrà letta
(localmente o remotamente).

<p>
Ci sono altri account di ruolo ed alias nel tuo sistema. In un piccolo
sistema é, probabilmente, più facile far sì che tutti gli alias
puntino a root e che la posta di root venga inoltrata alla casella
di posta personale dell'amministratore di sistema.

<p>
FIXME: sarebbe interessante spiegare come un sistema Debian possa
spedire/ricevere SNMP trap riguardanti problemi di sicurezza (jfs).
Controllare: <package>snmptrapfmt</package>, <package>snmp</package> 
e <package>snmpd</package>.





<sect1>Usare un loghost



<p>
Un loghost è un host che raccoglie i dati di syslog remoti dalla
rete. Se una delle vostre macchine viene compromessa, l'intruso non
é in grado di coprire le sue tracce, a meno che non penetri anche
nella macchina loghost. Perciò, il loghost dovrebbe essere
particolarmente sicuro. Rendere una macchina un loghost è semplice.
&Egrave; sufficiente avviare <prgn>syslogd</prgn> con 
<tt>syslogd -r</tt> ed un nuovo loghost è nato.
Perché questa azione sia permanente, in Debian, modificate
<file>/etc/default/syslogd</file> e cambiate la riga

<!-- FIXME: The following could also be interesting -->
<!-- How to hide the logging server on the network i.e. by not giving -->
<!-- it an IP address and adding a static ARP entry on the hosts using -->
<!-- the remote syslog server (only if on the same hub); if the remote -->
<!-- syslog server would be on a separate network, the default gateway -->
<!-- should be configured accordingly -->

<example>
SYSLOGD=""
</example>
in 
<example>
SYSLOGD="-r"
</example>

Successivamente, configurate le altre macchine perché spediscano i
dati al loghost. Aggiungete una riga simile alla seguente al file 
<file>/etc/syslog.conf</file>:

<example>
  facility.level            @your_loghost
</example>

<p>
Guardate la documentazione per cosa usare al posto di <em>facility</em> e
<em>level</em> (non dovrebbero contenere queste parole). Se volete
registrare ogni cosa remotamente, scrivete:

<example>
  *.*                       @your_loghost
</example>

nel vostro <file>syslog.conf</file>. La registrazione dei log sia remota che
locale è la migliore soluzione (l'attaccante potrebbe pensare di aver
coperto le sue tracce dopo la cancellazione dei log locali). Vedete
la pagine di manuale di <manref name="syslog" section="3">, 
<manref name="syslogd" section="8"> e <manref name="syslog.conf" section="5"> 
per ulteriori informazioni.



<sect1>Permessi dei file di log



<p>
Non è solo importante decidere come vengono usati gli avvisi, ma anche
chi ha accesso in lettura/modifica ai file di log (se non usate un
loghost remoto). Gli avvisi di sicurezza che l'attaccante può cambiare
o disabilitare non sono il peggiore danno di un'intrusione. Infatti,
dovete tenere a mente che questi file di log possono rivelare molte
informazioni riguardo il proprio sistema ad un attaccante che ne
abbia libera lettura.

<!--  It should be explained why after installation this is not
 already done, jfs -->

<p>
Alcuni permessi sui file di log non sono perfetti dopo una
installazione (ma questo ovviamente dipende dalla vostra politica 
di sicurezza locale). Per prima cosa <file>/var/log/lastlog</file> 
e <file>/var/log/faillog</file> non necessitano di essere letti dai 
normali utenti. Nel file <file>lastlog</file> potete vedere chi ha 
effettuato un login recentemente e in <file>faillog</file> potete 
vedere un riassunto dei login falliti. L'autore raccomanda 
<prgn>chmod 660</prgn> per entrambi. Date una rapida occhiata ai 
vostri file di log e decidete molto attentamente quali rendere 
leggibili/scrivibili per utenti con UID diversi da 0 e gruppi che 
non siano 'adm' o 'root'. Si può facilmente controllare se quanto 
descritto è conforme al vostro sistema con:

<example>
  #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
  (vede a quali utenti appartengono i file in /var/log )
  #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
  (vede a quali gruppi appartengono i file in /var/log)
  # find /var/log -perm +004
  (i file leggibili da qualsiasi utente)
  #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
  (file di proprietà di gruppi diversi da root o adm)
</example>

<p>Per personalizzare la creazione dei file di log, probabilmente 
dovreste modificare il programma che li genera. Se i file di log
vengono ruotati (vgs. <prgn>logrotate</prgn>), ad ogni modo, 
è possibile personalizzare il comportamento di creazione e rotazione.


<!-- This is no longer true, check apache's logrotate
<p>
I want to emphasize that the apache log file permissions are really
screwed due to the fact that the apache user owns the apache log
files. If a user gets a shell with a back door in apache, they can
easily remove the log files.
-->




<sect id="kernel-patches">Includere le patch nel kernel
<!-- last edited by Frédéric Schütz <schutz@mathgen.ch> -->



<p>
Debian GNU/Linux fornisce molte patch per il Kernel Linux
al fine di migliorarne la sicurezza. Queste includono:

<list>

<item><url id="http://www.lids.org" name="Linux Intrusion Detection">
viene fornita dal pacchetto <package>kernel-patch-2.4-lids</package>,
Questa modifica del kernel semplifica il processo di protezione di un 
sistema Linux, permettendo la limitazione, l'occultamento e la 
protezione di processi e di determinati file, in modo che nemmeno 
l'utente root possa intervenire su di essi. Inoltre, implementa 
funzionalità con capacità di controllo di accesso (NdT: MAC).

<item><url id="http://trustees.sourceforge.net/" 
name="Linux Trustees"> (nel pacchetto <package>trustees</package>).
Questa modifica del kernel aggiunge un sistema avanzato di 
gestione dei permessi del kernel Linux. Oggetti speciali, chiamati 
trustees (curatori) vengono uniti ad ogni file o cartella e riposti 
nella memoria del kernel, questo permette un rapido controllo di
tutti i permessi. 

<item>
<p>NSA  Enhanced Linux (nel pacchetto <package>selinux</package>).
Port di pacchetti SElinux già funzionanti per la vostra distribuzione
possono essere rinvenuti presso 
<url id="http://selinux.alioth.debian.org/">. Ulteriori informazioni 
sono disponibili presso la pagina 
<url id="http://wiki.debian.org/SELinux" 
name="SElinux del Debian Wiki"> ed i siti web SElinux di 
<url id="http://www.golden-gryphon.com/software/security/selinux.xhtml" 
name="Manoj Srivastava's"> e <url id="http://www.coker.com.au/selinux/"
name="Russell Cookers's">.


<item>La <url id="http://people.redhat.com/mingo/exec-shield/"
name="patch exec-shield"> fornita nel pacchetto 
<package>kernel-patch-exec-shield</package>. Questa patch fornisce
protezione contro alcuni buffer overflow (attacchi stack
smashing).

<item>La <url id="http://www.grsecurity.net/" name="Grsecurity patch">,
fornita dai pacchetti <package>kernel-patch-2.4-grsecurity</package> e
<package>kernel-patch-grsecurity2</package><footnote>
Fate attenzione che questa patch è in conflitto con le patch già incluse 
nei sorgenti del kernel Debian 2.4. Avrete bisogno di un kernel vanilla. 
Questo può essere ottenuto mediante i seguenti passi:
<example>
 # apt-get install kernel-source-2.4.22 kernel-patch-debian-2.4.22
 # tar xjf /usr/src/kernel-source-2.4.22.tar.bz2
 # cd kernel-source-2.4.22
 # /usr/src/kernel-patches/all/2.4.22/unpatch/debian
</example>

Per maggiori informazioni fate riferimento a
<url id="http://bugs.debian.org/194225" name="#194225">, 
<url id="http://bugs.debian.org/199519" name="#199519">, 
<url id="http://bugs.debian.org/206458" name="#206458">, 
<url id="http://bugs.debian.org/203759" name="#203759">, 
<url id="http://bugs.debian.org/204424" name="#204424">, 
<url id="http://bugs.debian.org/210762" name="#210762">, 
<url id="http://bugs.debian.org/211213" name="#211213"> e
<url id="http://lists.debian.org/debian-devel/2003/debian-devel-200309/msg01133.html" 
name="discussione su debian-devel">
</footnote>
implementa MAC tramite RBAC, fornisce la protezione da buffer overflow
mediante PaX, ACL, casualità in rete (per rendere gli OS fingerprinting 
più difficoltosi) e <url id="http://www.grsecurity.net/features.php" 
name="molte altre funzionalità">.

<item>Il pacchetto <package>kernel-patch-adamantix</package> fornisce 
le patch sviluppate per <url id="http://www.adamantix.org/" 
name="Adamantix">, una distribuzione basata su Debian.  Questa patch 
per i kernel versione 2.4.x introduce alcune funzionalità di sicurezza 
come uno stack non eseguibile tramite l'uso di 
<url id="http://pageexec.virtualave.net/" name="PaX"> ed il controllo 
obbligato sugli accessi basato su <url id="http://www.rsbac.org/" 
name="RSBAC" >. Fra le altre funzionalità, la patch 
<url name="Random PID" id="http://www.vanheusden.com/Linux/sp/">, 
dispositivo di loop criptato con AES, supporto per MPPE ed un backport 
di IPSEC v2.6.

<item>
<p><package>cryptoloop-source</package>. 
Questa patch consente di usare funzionalità crypto API del kernel
per creare dei filesystem cifrati usando il dispositivo di loopback.

<item>Supporto ad IPSEC nel kernel (nel pacchetto 
<package>linux-patch-openswan</package>).
Se volete usare il protocollo IPsec con Linux, occorre questa 
patch, con la quale potrete creare delle VPN, anche per macchine 
Windows, in modo molto semplice, dal momento che IPsec è uno 
standard affermato. Le funzionalità IPSec sono state aggiunte al 
kernel di sviluppo 2.5 e queste caratteristiche verranno incluse in 
modo predefinito nel futuro kernel 2.6. 
La pagina web di riferimento: <url id="http://www.openswan.org">.

<em>FIXME</em>: Gli ultimi kernel 2.4 forniti in Debian includono un 
backport del codice IPSEC dal 2.5. Commenti su questo.

</list>

<p>Le seguenti deprecate patch per il kernel, dedicate alla 
sicurezza, sono disponibili solamente per le vecchie versioni 
dei kernel di woody:

<list>
<item><url id="http://acl.bestbits.at/" 
name="POSIX Access Control Lists"> (ACLs) per Linux, fornita dal 
pacchetto <package>kernel-patch-acl</package>. Questa patch per 
il kernel aggiunge elenchi di controllo degli accessi ed un metodo 
avanzato per limitare l'accesso ai file. Consente di controllare 
in modo granulare l'accesso a file e directory.

<item>La patch per il kernel linux 
<url name="Openwall" id="http://www.openwall.com/linux/"> della 
Solar Designer, fornita nel pacchetto 
<package>kernel-patch-2.2.18-openwall</package> contiene un utile
insieme di restrizioni per il kernel, come link limitati, FIFO in
<file>/tmp</file>, un filesystem <file>/proc</file> limitato, la 
gestione di descrittori speciali di file, area di stack utente non
eseguibile ed altre funzionalità. Notate: questo pacchetto si
applica alla versione 2.2, mentre non sono disponibili
pacchetti per le patch alla versione 2.4 fornite da Solar.

<item><package>kernel-patch-int</package>. 
Questa patch estende le funzioni di criptazione del kernel e può 
essere usata dalle versioni Debian fino a Potato. Non funziona con 
Woody e se usate Sarge o una versione successiva dovreste 
semplicemente usare un kernel più recente visto che include già
questa funzionalità.

</list>

<p>Comunque in Debian alcune patch ancora non sono state fornite. 
Se ritenete che alcune di queste dovrebbero essere incluse 
siete pregati di chiedere di loro mediante
il <url name="Work Needing and Prospective Packages"
id="http://www.debian.org/devel/wnpp/">.








<sect>Protezione contro i buffer overflow

<p>
<em>Buffer overflow</em> è il nome di un comune attacco al software<footnote>
Così comune, in effetti, che sono alla base del 20% delle
vulnerabilità di sicurezza riportate tutti gli anni, come stabilito
da <url id="http://icat.nist.gov/icat.cfm?function=statistics"
name="statistics from ICAT's vulnerability database">.</footnote>
che approfitta di un controllo insufficiente (un errore di
programmazione molto comune in C) in seguito all'esecuzione di codice
immesso da un input. Questo tipo di attacco, portato contro i server 
che rimangono in attesa di una connessione remota e contro il 
software che gira localmente, che solitamente assegnar alti privilegi 
agli utenti (grazie ai <tt>setuid</tt> e <tt>setgid</tt> attivi) può 
compromettere ogni sistema.

<p>
Esistono principalmente quattro metodi per proteggersi dai buffer
overflow:

<list>

<item>
<p>Aggiungendo delle patch al kernel così da prevenire
l'esecuzione dello stack.Potete usare: Exec-shield, OpenWall o PaX
(incluso nelle patch Grsecurity ed Adamantix).
<!-- FIXME: add a link to libsafe to the main place -->

<item>Fissando il codice usando strumenti per trovare frammenti del 
sorgente che potrebbero introdurre vulnerabilità.

<item>Ricompilando il codice sorgente per introdurre controlli
appropriati che prevengano gli overflow, usando la patch per GCC
<url id="http://www.research.ibm.com/trl/projects/security/ssp/"
name="Stack Smashing Protector (SSP)"> (che viene usata da
<url id="http://www.adamantix.org" name="Adamantix">).

</list>

<p>Debian GNU/Linux, dalla versione 3.0, fornisce programmi per 
includere tutti questi metodi, fatta salva l'eccezione relativa 
alla protezione al momento in cui si effettui la compilazione 
del codice sorgente (ma questo è stato richiesto mediante il 
<url id="http://bugs.debian.org/213994" name="Bug #213994">).

<p>Notate che se Debian fornisse un compilatore con protezione contro 
stack o buffer overflow tutti i pacchetti dovrebbero essere 
ricompilati per poter introdurre questa funzionalità. Questo è, in 
effetti, quello che fa la distribuzione Adamantix (tra le altre 
caratteristiche). L'effetto di questa nuova funzionalità sul software 
è ancora da stabilire (alcuni programmi o alcune architetture di 
processori potrebbero non funzionare).

<p>
In ogni caso questi consigli non prevengono i buffer overflow
poiché esistono dei modi per aggirare queste precauzioni, metodi
descritti nel 
<url id="http://packetstorm.linuxsecurity.com/mag/phrack/phrack58.tar.gz" 
name="numero 58"> della rivista phrack's o negli avvisi CORE 
<url id="http://online.securityfocus.com/archive/1/269246"
name="Multiple vulnerabilities in stack smashing protection technologies">.

<p>Una volta implementato, se desiderate collaudare il vostro livello 
di protezione da buffer overflow (indipendentemente dal metodo scelto), 
potreste voler installare <package>paxtest</package> ed eseguire il 
test che fornisce.


<sect1>Patch per la protezione del kernel da Kernel contro buffer overflows

<p>Le patch relative al buffer overflow includono la patch Openwall 
che fornisce protezione contro gli overflow nel kernel 2.2. Per il 
kernel 2.4 o per quelli ancor più recenti, è necessario utilizzare 
l'implementazione Exec-shield o altrimenti PaX (fornita sia dalla
patch grsecurity, <package>kernel-patch-2.4-grsecurity</package>, 
che dalla patch Adamantix, <package>kernel-patch-adamantix</package>). 
Per maggiori informazioni sull'uso di queste patch leggete  
<ref id="kernel-patches">.


<sect1>Collaudare i programmi contro gli overflow
  	 
<p>L'uso di strumenti per trovare buffer overflows richiede, in ogni 
caso, un'esperienza da programmatori per sistemare (e ricompilare) 
il codice. Debian, fornisce, per esempio: <package>bfbtester</package> 
(un programma per collaudare la resistenza ai buffer overflow che 
utilizza binari con approccio a forza bruta mediante overflow 
da riga di comando o di ambiente). Altri pacchetti interessanti 
potrebbero essere  anche <package>rats</package>, 
<package>pscan</package>, <package>flawfinder</package> e 
<package>splint</package>.



  	 

<sect>Trasferire file in sicurezza

<p>
Durante la normale amministrazione, solitamente si ha bisogno di 
importare o di esportare dei file dal sistema installato. Si può riuscire a 
copiare i file da un host ad un altro in maniera sicura, usando il pacchetto 
server <package>ssh</package>. Un'altra possibilità è l'impiego di 
<package>ftpd-ssl</package>, un server ftp che adotta il <em>Secure Socket 
Layer</em> per cifrare le trasmissioni.

<p>
Naturalmente, tutti questi metodi necessitano di client speciali e Debian ne 
offre alcuni: per esempio, con <package>ssh</package> fornisce 
<prgn>scp</prgn>, che funziona come <prgn>rcp</prgn>
ma è completamente cifrato, cosicché i <em>cattivi ragazzi</em> 
non possano nemmeno capire 
CHE COSA si stia copiando. C'è anche un pacchetto client
<package>ftp-ssl</package> per
il server corrispondente. Per questi programmi, si trovano client anche di
altri sistemi operativi (non-UNIX); per copiare in
sicurezza, <prgn>putty</prgn> e 
<prgn>winscp</prgn> forniscono un'implementazione adatta a qualsiasi 
versione del sistema operativo della Microsoft.

<p>
Notate che usare <prgn>scp</prgn> consente a tutti gli utenti 
l'accesso all'intero file-system, a meno che non abbiate usato
<prgn>chroot</prgn>, come spiegato in <ref id="ssh-chroot">. 
Si può configurare l'accesso FTP, attraverso <prgn>chroot</prgn>, 
in modo anche più semplice, a seconda del demone scelto, come illustrato 
in <ref id="ftp-secure">. Se temete che gli utenti sfoglino i 
file locali e volete avere una comunicazione cifrata, potete 
utilizzare un demone ftp con supporto SSL, o abbinare un ftp 
che trasmette testo in chiaro e un'impostazione VPN (cfr. <ref id="vpn">).



<sect>Limitazioni e controllo del File System



<sect1>Usare le quote



<p>
Avere un buon criterio di assegnazione delle quote è importante, 
poiché evita che gli utenti riempiano gli hard disk.

<p>
Si possono avere due differenti sistemi di quote: la quota d'utente 
e la quota di gruppo. Come si intuisce, la quota per utente limita 
la quantità di spazio di cui un utente può disporre e la quota di 
gruppo fa la stessa cosa ma con i gruppi. Ricordatevene quando 
decidete la dimensione delle quote.

<p>
Nell'impostare un sistema di quote, bisogna tenere conto di alcuni punti 
importanti:

<list>
<item>
Fare in modo che le quote siano abbastanza piccole, in modo che gli 
utenti non divorino lo spazio del disco fisso.
<item>
Fare in modo che siano abbastanza grandi, in modo che gli utenti non 
abbiano a lagnarsene e che la loro quota-email impedisca loro di 
accettare posta per un lungo periodo.
<item>
Usare il sistema delle quote su tutte le aree scrivibili dagli utenti, su 
<file>/home</file> come su <file>/tmp</file>.

</list>

<p>
Ogni partizione o cartella a cui gli utenti abbiano pieno accesso 
in scrittura dovrebbe essere organizzata in quote. Il calcolo e 
l'assegnazione di una quota su cui si possa lavorare, combina
utilizzabilità e sicurezza.

<p>
Supponiamo che vogliate usare il sistema delle quote: prima di tutto, 
dovrete controllare che il supporto per le quote sia abilitato nel 
kernel, se non lo fosse andrebbe ricompilato; dopo di che, controllate 
che il pacchetto <package>quota</package> sia installato, altrimenti  
dovrete procedere all'installazione del pacchetto.

<!-- FIXME: how to check for quota support? What to tweak when
recompiling? -->

<p>
Abilitare le  quote per i rispettivi file system è semplice, basta 
modificare l'impostazione nel file <file>/etc/fstab</file> da 
<tt>defaults</tt> a <tt>defaults,usrquota</tt>. Se avete bisogno
delle quote di gruppo, sostituite <tt>usrquota</tt> a
<tt>grpquota</tt>. Potete utilizzare entrambe le opzioni. 
Quindi, basta creare due file vuoti quota.user e  quota.group 
nella root del file system dove volete usare le quote (ad 
esempio,  per il file system <file>/home</file>, date
il comando <tt>touch /home/quota.user /home/quota.group</tt>).

<p>
Riavviare <prgn>quota</prgn> lanciando: 
<tt>/etc/init.d/quota stop;/etc/init.d/quota start</tt>. 
A questo punto, le quote dovrebbero funzionare e potete 
così impostare le dimensioni delle quote.

<p>
Per modificare le quote di un particolare utente basta dare il 
comando <tt>edquota -u &lt;utente&gt;</tt>; per quelle di un gruppo, 
invece, <tt>edquota -g &lt;gruppo&gt;</tt>. Infine impostate la
modalità quota fissa o variabile e/o le quote inode, a piacere.

<p>
Per maggiori informazioni sulle quote, leggete le relative pagine 
man ed il quota mini-HOWTO 
(<file>/usr/share/doc/HOWTO/en-html/mini/Quota.html</file> -
mini guida su quota). Potreste anche voler dare un'occhiata a 
<file>pam_limits.so</file>.



<sect1 id="ext2attr">Specifici attributi del filesystem ext2 (chattr/lsattr)
<!-- section last edited by Frédéric Schütz <schutz@mathgen.ch> -->


<p>
Oltre ai soliti permessi di tipo Unix, i filesystem ext2 ed ext3 offrono un
insieme di attributi specifici per dare un maggiore controllo sui file del
sistema. A differenza dei permessi di base, questi non vengono mostrati con il
comando <prgn>ls -l</prgn> o modificati mediante <prgn>chmod</prgn>; per
amministrarli, occorrono altre due utilità: <prgn>lsattr</prgn> e
<prgn>chattr</prgn> (nel pacchetto <package>e2fsprogs</package>). Notate che
ciò significa che tali attributi non verranno salvati con la copia di sicurezza
del sistema; così, qualora se ne modifichi uno qualsiasi, sarebbe meglio
salvare in uno script i successivi comandi <prgn>chattr</prgn>, così da
poterli reimpostare in un secondo momento, all'atto di un eventuale ripristino.

<p>
Fra tutti gli attributi disponibili, i due più importanti, 
nell'aumentare la sicurezza vengono richiamati dalle lettere 'i' ed 'a' 
e possono essere impostati o rimossi dal superutente:

<list>
<item>
<p>L'attributo 'i' ('immutabile'): un file con questo attributo non può
essere modificato, né cancellato, né rinominato e nemmeno il superutente può
creare collegamenti ad esso.
<item>
<p>L'attributo 'a' ('append'): questo attributo ha lo stesso effetto
del precedente, salvo che consente di aprire il file per aggiungervi nuovi
contenuti, pur senza poter modificare quello già esistente (append mode); è
molto utile per i file di log collocati nella cartella <file>/var/log/</file>,
anche se dovreste considerare che, talvolta, questi vengono spostati, per
via degli script di rotazione dei log.

</list>

<p>Si possono impostare questi attributi anche alle cartelle; in tal caso
nessuno può modificarne i contenuti, rinominando o rimuovendo dei file.
Applicato ad una cartella, l'attributo append permette la sola creazione di
file.

<p>
Si vede bene come l'attributo 'a' aumenti la sicurezza, consentendo ai
programmi non eseguiti dal superutente l'aggiunta di dati ad un file, senza
poterne modificare il contenuto preesistente. Invece, l'attributo 'i' sembra
meno interessante: dopotutto, per limitare l'accesso a un file, il superutente
può già usare i permessi di base di Unix, mentre un intruso che riesca ad
assumere la qualità di superutente potrebbe sempre usare il programma
<prgn>chattr</prgn> per rimuovere l'attributo: inizialmente potrebbe
confondersi, vista l'impossibilità di spostare un file, ma non si può pensare
che sia cieco - in fondo, è pur sempre entrato nel sistema! Per aumentare la
sicurezza, alcuni manuali (compresa una precedente versione di questo
documento), suggeriscono semplicemente di rimuovere dal sistema i programmi
<prgn>chattr</prgn> e <prgn>lsattr</prgn>, ma questo tipo di strategia, nota
come "sicurezza mediante oscurità" deve essere evitata in assoluto, in quanto
fornisce un falso senso di sicurezza.

<p>
Un modo sicuro di risolvere questo problema è usare una funzionalità 
del kernel Linux, come mostrato in <ref id="proactive">. La 
funzionalità che ci interessa si chiama <tt>CAP_LINUX_IMMUTABLE</tt>:
se si rimuove la funzionalità di impostare dei limiti (per esempio 
col comando <tt>lcap CAP_LINUX_IMMUTABLE</tt>) non sarà più
possibile, nemmeno al superutente, modificare qualunque attributo 
'a' o 'i'! Una strategia completa potrebbe essere questa:

<enumlist>

  <item> Impostare gli attributi 'a' ed 'i' sui file desiderati.
  <item> Aggiungere il comando <tt>lcap CAP_LINUX_IMMUTABLE</tt> (o anche,
         come in <ref id="proactive">, <tt>lcap CAP_SYS_MODULE</tt>)
         a uno degli script di avvio.

<!-- Is there anything interesting in :
http://lists.debian.org/debian-security/2001/debian-security-200107/msg00024.html -->

  <item> Impostare l'attributo 'i' su tale script e su altri file di avvio, o
         anche sullo stesso binario <prgn>lcap</prgn>.
  <item> Eseguire manualmente detto comando (o riavviare il sistema, per
         assicurarsi che tutto funzioni a dovere).

</enumlist>

<p>Ora che la funzionalità è stata rimossa dal sistema, un intruso non può cambiare
alcun attributo dei file protetti, né, quindi, modificarli o eliminarli. Se
forza il riavvio della macchina (unico modo per ripristinare la serie di
limitazioni alle funzionalità), sarà facilmente scoperto e comunque quella
funzionalità sarà nuovamente rimossa appena il sistema si sarà riavviato. Il
solo sistema di modificare un file protetto sarebbe inizializzare il sistema
nel modo singolo-utente o usando una altro disco di avvio, due operazioni che
richiedono un accesso fisico alla macchina!

<!-- Add a note about the fact that it is not widely used -->


<sect1 id="check-integ">Controllare l'integrità del file system

<p> Siete sicuri che <file>/bin/login</file> sul disco fisso è ancora 
il binario installato qualche mese fa? 
Cosa accadrebbe se fosse una versione modificata, che registra
le password inserite in un file nascosto o le spedisce in 
chiaro per tutta Internet?

<p>Il solo modo per avere qualche forma di protezione è controllare i 
file ogni ora/giorno/mese (preferibile quotidianamente) confrontando 
gli md5sum attuali di un file con quelli vecchi. Due file non possono 
avere lo stesso md5sum (l'MD5 digest è 128 bits, quindi le 
possibilità che due diversi file abbiano lo stesso md5sum sono 
approssimativamente una su 3.4e3803), perciò è il metodo più sicuro, 
a meno che qualcuno non abbia modificato l'algoritmo che crea 
l'md5sum sulla macchina; il che comunque è piuttosto complicato ed 
improbabile. Bisogna considerare la verifica di questi binari molto 
importante, poiché è un modo semplice per riconoscere le modifiche 
ai binari. 

<p>Strumenti comunemente utilizzati a questo scopo sono 
<package>sxid</package>, <package>aide</package> (Advanced Intrusion 
Detection Environment), <package>tripwire</package>, 
<package>integrit</package> e <package>samhain</package>. Installare 
<prgn>debsums</prgn> può aiutare a controllare l'integrità del file 
system, comparando l'md5sum di ogni file con quello usato 
nell'archivio dei pacchetti Debian. Ma attenzione, questi file 
possono facilmente essere modificati da un intruso malintenzionato 
ed inoltre non tutti i pacchetti offrono un elenco md5sum di 
tutti i file che forniscono. Per ulteriori informazioni leggete
<ref id="periodic-integrity"> e <ref id="snapshot">.


<p>Potreste voler usare <prgn>locate</prgn> per indicizzare l'intero 
filesystem, in questo caso, consideratene le implicazioni. Il 
pacchetto Debian <package>findutils</package> contiene il programma
<prgn>locate</prgn> che viene eseguito dall'utente nobody e quindi 
indicizza i file che sono visibili a tutti. Ad ogni modo, se 
apportate una modifica al suo comportamento potreste rendere i 
percorsi di tutti i file visibili a tutti. Se volete indicizzare 
tutto il filesystem (non solo i file che l'utente nobody può vedere) 
potete sostituire <prgn>locate</prgn> con il pacchetto 
<prgn>slocate</prgn>. slocate è etichettato come la versione sicura 
dello GNU locate, ma in realtà fornisce ulteriori funzionalità per 
la localizzazione dei file. Quando usate <prgn>slocate</prgn>, 
l'utente può vedere solo i file a cui ha realmente accesso e si può 
escludere qualunque file o directory del sistema. Il pacchetto 
<prgn>slocate</prgn> esegue il suo processo di aggiornamento con 
privilegi maggiori di locate e indicizza ogni file. Gli utenti sono 
quindi in grado di cercare rapidamente ogni file a cui abbiano 
diritti di accesso. <prgn>slocate</prgn> non permette loro di vedere 
i nuovi file e filtra l'output basandosi sul vostro UID.

<p>Potreste voler usare <package>bsign</package> o 
<package>elfsign</package>. <package>elfsign</package> fornisce 
un'utility che aggiunge una firma elettronica a un binario ELF ed 
una seconda utility per verificare questa firma. L'attuale 
implementazione usa PKI (Public Key Infrastructure) per firmare il 
cheksum del binario. I benefici di questa pratica sono quelli di 
permettere di verificare se un binario è stato modificato e chi 
lo ha creato. <package>bsign</package> usa GPG, 
<package>elfsign</package> usa certificati PKI (X.509) (OpenSSL).





<sect1>Impostare il controllo di setuid

<p>Il pacchetto Debian <package>checksecurity</package> fornisce un 
processo <prgn>cron</prgn> che viene eseguito giornalmente attraverso 
<file>/etc/cron.daily/checksecurity</file><footnote>
          Nelle distribuzioni precedenti, checksecurity era integrato 
          in cron ed il file quindi era 
          <file>/etc/cron.daily/standard</file>.
</footnote>. 
Questo processo <prgn>cron</prgn> farà partire lo script 
<prgn>/usr/sbin/checksecurity</prgn> che memorizzerà le informazioni 
riguardo questi cambiamenti.

<p>Il comportamento predefinito non invia queste informazioni al 
superuser, bensì mantiene giornalmente copie dei cambiamenti in 
<file>/var/log/setuid.changes</file>. Occorre impostare la variabile 
MAILTO (in <file>/etc/checksecurity.conf</file>) su 'root'
perché queste informazioni siano inviate al superuser.
Vedete <manref name="checksecurity" section="8"> per maggiori 
informazioni sulla configurazione.





<sect id="network-secure">Rendere sicuro l'accesso alla rete



<p>
FIXME. Servono più contenuti (specifici per Debian)


<sect1 id="kernel-conf">Configurare le caratteristiche di rete del kernel


<p>
Molte caratteristiche del kernel possono essere cambiate quando 
questo è in esecuzione, effettuando un echo all'interno del filesystem 
<file>/proc</file> o usando <prgn>sysctl</prgn>.
Eseguendo <tt>/sbin/sysctl -A</tt> potete vedere cosa è possibile 
configurare e quali sono le opzioni, è possibile modificarlo eseguendo
<tt>/sbin/sysctl -w variable=value</tt> (vedete 
<manref name="sysctl" section="8">). Solo in rari casi è necessaria questa
modifica ma potete comunque incrementare la sicurezza in questo 
modo. Per esempio:

<!-- FIXME: Should the prefix on all of these be /proc/sys/? era -->

<example>
net/ipv4/icmp_echo_ignore_broadcasts = 1
</example>

<p>
Questo è un <em>emulatore di Windows</em> perché funziona come 
Windows in broadcast ping, se questa opzione viene impostata ad 1. 
In pratica, le richieste ICMP_ECHO spedite all'indirizzo in
broadcast vengono ignorate. Altrimenti, non succede nulla.

<p>Se volete evitare che il sistema risponda alle richieste 
echo ICMP, basta attivare questa opzione di configurazione:

<example>
net/ipv4/icmp_echo_ignore_all = 1
</example>

<p>Per loggare dei pacchetti destinati ad indirizzi inesistenti
(errore dovuto ad instradamenti sbagliati) sulla vostra rete, 
utilizzate:

<example>
/proc/sys/net/ipv4/conf/all/log_martians = 1
</example>

<p>
Per maggiori informazioni su ciò che può essere fatto con
<file>/proc/sys/net/ipv4/*</file> leggete
<file>/usr/src/linux/Documentation/filesystems/proc.txt</file>.
Tutte le opzioni vengono descritte in maniera esauriente in
<file>/usr/src/linux/Documentation/networking/ip-sysctl.txt</file><footnote>
In Debian, il pacchetto 
<package>kernel-source-<var>version</var></package>
copia i sorgenti in 
<file>/usr/src/kernel-source-<var>version</var>.tar.bz2</file>,
basta sostituire <var>version</var> con qualsiasi altra versione 
dei sorgenti del kernel che avete installato.
</footnote>.



<sect1 id="tcp-syncookies">Configurare i Syncookies


<p>
Questa opzione è un'arma a doppio taglio. Da un lato, protegge
il sistema contro il syn packet flooding, dall'altro viola degli 
standard definiti (le RFC).

<!-- What does this mean? (jfs)
This option is quite dumb as it floods the
other side like it floods you, so the other side is also busy. 
-->

<example>
net/ipv4/tcp_syncookies = 1
</example>

<p>
Se desiderate cambiare questa opzione, ogni volta che il kernel è in
esecuzione, allora dovrete modificare <tt>/etc/network/options</tt> 
impostando <tt>syncookies=yes</tt>. 
Questo cambiamento avrà l'effetto di eseguire ogni volta lo script 
contenuto in <tt>/etc/init.d/networking</tt> (come viene fatto 
solitamente al boot), mentre la seguente opzione avrà effetto 
solamente con il kernel in esecuzione.

<example>
echo 1 > /proc/sys/net/ipv4/tcp_syncookies 
</example>

<p>
Questa opzione è disponibile solamente se il kernel è stato 
compilato con l'opzione <tt>CONFIG_SYNCOOKIES</tt>. Tutti i 
kernel Debian vengono compilati con questa opzione all'interno
del kernel, potete verificarlo eseguendo:

<example>
$ sysctl -A |grep syncookies
net/ipv4/tcp_syncookies = 1
</example>

<p>
Per maggiori informazioni sui syncookies TCP leggete
<url id="http://cr.yp.to/syncookies.html">.


<sect1 id="net-harden">Rendere sicura la rete al momento del boot


<p>
Quando impostate le opzioni del kernel relative al networking,
dovete configurarle in maniera tale che siano caricate ogni volta che
il sistema viene riavviato. L'esempio seguente abilita molte delle 
precedenti opzioni che avete visto, insieme ad altre utili opzioni.

<p>Attualmente, ci sono due maniere per configurare la  rete al boot.
Si può  configurare <file>/etc/sysctl.conf</file> (vedete 
<manref section="5" name="sysctl.conf">), oppure utilizzare uno script 
che viene invocato quando viene abilitata l'interfaccia. La prima 
opzione verrà applicata a tutte le interfacce, mentre la seconda 
opzione permetterà una configurazione mirata per ogni interfaccia.

<p>Sotto viene mostrato un esempio di configurazione di 
<file>/etc/sysctl.conf</file> che rende sicure alcune opzioni di rete 
a livello di kernel. Guardate la parte commentata, 
<file>/etc/network/options</file> potrebbe ignorare alcuni valori, se 
in contrasto con quelli in questo file quando viene eseguito 
<file>/etc/init.d/networking</file> 
(che viene dopo <file>procps</file> nella sequenza di boot).

<example>
#
# /etc/sysctl.conf - File di configurazione per impostare variabili di
# sistema. Vedete sysctl.conf (5) per informazioni aggiuntive. Vedete
# anche i file sotto  Documentation/sysctl/,  
# Documentation/filesystems/proc.txt e
# Documentation/networking/ip-sysctl.txt nei sorgenti del kernel
# (/usr/src/kernel-$version se avete i sorgenti installati) per
# ulteriori informazioni sui valori che possono venir qui definiti.

#
# Attenzione: /etc/init.d/procps viene eseguito per impostare le 
# seguenti variabili. Dopodiché, comunque, /etc/init.d/networking 
# imposta alcune opzioni di rete a dei valori predefiniti. Questi 
# valori possono essere sovrascritti mediante /etc/network/options.
#
#kernel.domainname = example.com

# Additional settings - adapted from the script contributed
# by Dariusz Puchala (see below)
# Ignore ICMP broadcasts
net/ipv4/icmp_echo_ignore_broadcasts = 1
#
# Ignore bogus ICMP errors
net/ipv4/icmp_ignore_bogus_error_responses = 1
# 
# Do not accept ICMP redirects (prevent MITM attacks)
net/ipv4/conf/all/accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net/ipv4/conf/all/secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
net/ipv4/conf/all/send_redirects = 0
#
# Do not forward IP packets (we are not a router)
# Note: Make sure that /etc/network/options has 'ip_forward=no'
net/ipv4/conf/all/forwarding = 0
#
# Enable TCP Syn Cookies
# Note: Make sure that /etc/network/options has 'syncookies=yes'
net/ipv4/tcp_syncookies = 1
#
# Log Martian Packets
net/ipv4/conf/all/log_martians = 1
#
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
# Note: Make sure that /etc/network/options has 'spoofprotect=yes'
net/ipv4/conf/all/rp_filter = 1
#
# Do not accept IP source route packets (we are not a router)
net/ipv4/conf/all/accept_source_route = 0
</example>

<p>Per usare lo script dovete prima di tutto crearlo, per esempio, in
<file>/etc/network/interface-secure</file> (il nome è solo un esempio) 
e chiamarlo da <file>/etc/network/interfaces</file> come mostrato qui:

<example>
auto eth0
iface eth0 inet static
        address xxx.xxx.xxx.xxx
        netmask 255.255.255.xxx
        broadcast xxx.xxx.xxx.xxx
        gateway xxx.xxx.xxx.xxx
        pre-up /etc/network/interface-secure
</example>

<p>In questo esempio, prima di abilitare l'interfaccia eth0, lo script 
verrà chiamato per rendere sicure tutte le interfacce di rete come 
mostrato sotto.

<example>
#!/bin/sh -e
# Script-name: /etc/network/interface-secure
#
# Modifica alcuni comportamenti predefiniti per proteggere il 
# sistema da alcuni attacchi spoofing contro il TCP/IP e da altri 
# tipi di attacchi rivolti a tutte le interfacce.
#
# Contributed by Dariusz Puchalak.
#
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
                                           # Broadcast echo protection enabled.
echo 0 > /proc/sys/net/ipv4/conf/all/forwarding
                                           # IP forwarding disabled.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies # TCP syn cookies protection enabled.
echo 1 >/proc/sys/net/ipv4/conf/all/log_martians # Log strange packets.
# (this includes spoofed packets, source routed packets, redirect packets)
# but be careful with this on heavy loaded web servers.
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses 
                                           # Bad error message protection enabled.

# IP spoofing protection.
echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter

# Disable ICMP redirect acceptance.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects

# Disable source routed packets.
echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

exit 0
</example>

<p>&Egrave; opportuno notare che si possono adottare script specifici 
per ogni interfaccia. Questi script abilitano le opzioni di rete 
relative alle diverse interfacce (qualora ne fossero presenti più di una).
&Egrave; sufficiente modificare il comando di pre-up come indicato di 
seguito:

<example>
pre-up /etc/network/interface-secure $IFACE
</example>

<p>Questo comando lancia lo script che applicherà i cambiamenti 
solamente all'interfaccia di rete specificata e non a tutte le 
interfacce eventualmente disponibili. Notate che alcune opzioni 
di rete possono essere applicate solo globalmente. Di seguito 
un modello di script:

<example>
#!/bin/sh -e
# Script-name: /etc/network/interface-secure
#
# Modifica alcuni comportamenti predefiniti per proteggere il 
# sistema da alcuni attacchi spoofing contro il TCP/IP e da altri 
# tipi di attacchi rivolti a tutte le interfacce.
#
# Contributed by Dariusz Puchalak.
#

IFACE=$1
if [ -z "$IFACE" ] ; then
   echo "$0: Must give an interface name as argument!"
   echo "Usage: $0 &lt;interface&gt;"
   exit 1
fi

if [ ! -e /proc/sys/net/ipv4/conf/$IFACE/ ]; then
   echo "$0: Interface $IFACE does not exit (cannot find /proc/sys/net/ipv4/conf/)"
   exit 1
fi

echo 0 > /proc/sys/net/ipv4/conf/$IFACE/forwarding  # IP forwarding disabled.
echo 1 >/proc/sys/net/ipv4/conf/$IFACE/log_martians # Log strange packets.
# (questo include spoofed packets, source routed packets, redirect packets)
# ma fate attenzione, può essere pesante per un server web.

# IP spoofing protection.
echo 1 > /proc/sys/net/ipv4/conf/$IFACE/rp_filter

# Disable ICMP redirect acceptance.
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_redirects
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/send_redirects

# Disable source routed packets.
echo 0 > /proc/sys/net/ipv4/conf/$IFACE/accept_source_route

exit 0
</example>


<p>In alternativa è possibile creare uno script in <tt>init.d</tt> e 
farlo eseguire al boot (usando <prgn>update-rc.d</prgn> per creare 
l'appropriato link in <tt>rc.d</tt>).



<sect1 id="kernel-fw">Configurare le caratteristiche di un firewall


<p>
Per avere un firewall, sia per proteggere il sistema locale o tutto 
quello che si trova <em>dietro</em>, dovete compilare nel kernel le 
funzionalità del firewall. 
Il kernel standard per Debian 2.2 (Linux 2.2) comprende il packet 
filter <prgn>ipchains</prgn> come firewall, in Debian 3.0 è presente 
anche il kernel della serie 2.4 che è invece munito dello
<em>stateful</em> packet filter, <prgn>iptables</prgn> (netfilter)
come firewall.

<p>
In tutti i casi è vantaggioso e facile usare un kernel differente
da quelli che Debian mette a disposizione. Potete cercare dei pacchetti
che contengano un kernel precompilato ed è semplice installarlo in un
sistema Debian. Potete anche scaricare i sorgenti del kernel usando
<package>kernel-source-<var>X</var></package> e poi realizzare un 
pacchetto usando <package>make-kpkg</package> dal pacchetto
<package>kernel-package</package>.

<p>
La configurazione del firewall sarà ampiamente trattata in
<ref id="firewall-setup">.


<sect1 id="limit-bindaddr">Disabilitare la questione weak-end host 


<p>I sistemi con più di un'interfaccia in differenti reti possono
avere configurati servizi come se avessero solamente un indirizzo IP
convenuto. Normalmente questo previene l'accesso ai servizi quando 
vengono richiesti da altri indirizzi.
Tuttavia questo non significa, sebbene sia un normale malinteso, che
il servizio sia vincolato ad un determinato indirizzo 
<em>hardware</em> (scheda ethernet)<footnote>
Per riprodurre questo (esempio fornito da Felix von Leitner
nella mailing list bugtraq):

<example>
   host a (eth0 connected to eth0 of host b):
     ifconfig eth0 10.0.0.1
     ifconfig eth1 23.0.0.1
     tcpserver -RHl localhost 23.0.0.1 8000 echo fnord

   host b:
     ifconfig eth0 10.0.0.2
     route add 23.0.0.1 gw 10.0.0.1
     telnet 23.0.0.1 8000
</example>
<p>
Comunque, non agite con i servizi impostati per l'indirizzo
127.0.0.1, è consigliato effettuare il test usando i socket raw.

</footnote>.

<p>
Questo non è un problema di ARP e altresì non è una violazione RFC
(viene chiamata <em>weak end host</em> dalla
<url id="ftp://ftp.isi.edu/in-notes/rfc1122.txt" name="RFC1122">,
la trovate nel paragrafo 3.3.4.2).
Ricordate, gli indirizzi IP non hanno nulla da spartire con le interfacce
fisiche.

<p>
Nelle versioni 2.2 del kernel ed anche nelle precedenti è possibile
porre rimedio con:

<example>
# echo 1 > /proc/sys/net/ipv4/conf/all/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth0/hidden
# echo 1 > /proc/sys/net/ipv4/conf/eth1/hidden
.....
</example>
<p>
Nei kernel più recenti si può ottenere lo stesso con:

<list>
<item>Regole per iptable.
<item>Protocolli di instradamento debitamente configurati<footnote>
<p>Il fatto che questo comportamento possa essere modificato cambiando
l'instradamento, viene descritto da Matthew G. Marsh nei thread
di bugtraq:

<example>
eth0 = 1.1.1.1/24
eth1 = 2.2.2.2/24

ip rule add from 1.1.1.1/32 dev lo table 1 prio 15000
ip rule add from 2.2.2.2/32 dev lo table 2 prio 16000

ip route add default dev eth0 table 1
ip route add default dev eth1 table 2
</example>

</footnote>.

<item>
<p>L'applicazione di patch al kernel<footnote>
<p>Esistono numerose patch disponibili per ottenere questo comportamento
descritto nei thread di bugtraq, potete trovarle ai seguenti indirizzi:
<url id="http://www.linuxvirtualserver.org/~julian/#hidden">
e <url id="http://www.fefe.de/linux-eth-forwarding.diff">.
</footnote>.

</list>

<p>In questo testo ci saranno molte occasioni nelle quali viene 
mostrato come configurare alcuni servizi (server sshd, apache, 
servizi di stampa...) al fine di averli in ascolto su ogni dato 
indirizzo, il lettore dovrebbe tenere in considerazione che, senza 
le soluzioni qui fornite, la soluzione in oggetto non potrebbe 
prevenire eventuali accessi effettuati dall'interno della stessa 
rete (locale)<footnote>
Un attaccante potrebbe avere molti problemi a guadagnare l'accesso 
mediante l'indirizzo IP se non è sullo stesso dominio broadcast 
(stessa rete) dell'host attaccato. Se l'attacco passa attraverso un 
router, potrebbe essere abbastanza difficile che i pacchetti di 
risposta ritornino da qualche parte.
</footnote>.

<p>
FIXME: i commenti tratti da bugtraq sono metodi specifici per proteggere
un data interfaccia in Linux.

<p>
FIXME: sottoporre un bug nei confronti di netbase in modo che il 
risultato della riparazione della tabella di routing sia il 
comportamento standard per Debian?


<sect1>Proteggersi dagli attacchi di tipo ARP


<p>
Quando non c'è piena fiducia verso le altre postazioni sulla propria LAN
(dovrebbe essere sempre così, è l'atteggiamento più sicuro), ci si dovrebbe
proteggere dai diversi possibili attacchi di tipo ARP.

<p>
Il protocollo ARP viene usato per collegare indirizzi IP a indirizzi 
MAC - per tutti i dettagli vedete la 
<url id="ftp://ftp.isi.edu/in-notes/rfc826.txt" name="RFC826">.
Ogni volta che si spedisce un pacchetto ad un indirizzo IP viene effettuata una
risoluzione ARP per trovare l'indirizzo dell'hardware interessato (in primo
luogo, consultando la cache locale di ARP e poi, se l'IP non è presente nella
cache, con un'interrogazione in broadcast ARP). Tutti gli attacchi ARP mirano a
far credere ad una postazione che il proprio indirizzo IP non sia associato
all'indirizzo MAC di un intruso. Invece poi ogni pacchetto che vorrete spedire 
all'IP associato al box B in realtà verrà spedito proprio al box dell'intruso...

<p>
Quegli attacchi (ARP cache poisonning, ARP spoofing - 
avvelenamento della cache ARP, falsificazioni ARP) permettono 
all'attaccante di intercettare il traffico anche su reti 
commutate, di dirottare facilmente delle connessioni, di disconnettere
un host qualunque dalla rete... gli attacchi ARP sono potenti e semplici da
implementare, essendovi parecchi strumenti utili allo scopo: 
<prgn>arpspoof</prgn> dal pacchetto <package>dsniff</package> o
<url name="arpoison" id="http://arpoison.sourceforge.net/">.

<p>
Tuttavia, una soluzione c'è sempre:

<list>

<item>
<p>Usare una cache ARP statica, nella quale impostare delle voci "statiche":

<example>
arp -s host_name hdwr_addr 
</example> 

<p>Impostando voci statiche per ciascun host importante presente nella 
rete vi assicurerete che nessuno crei/modifichi per detti host la 
voce (la falsifichi) - le voci statiche non hanno scadenza e non 
possono essere modificate - cosicché le repliche ARP falsificate 
verranno ignorate.

<item>
Scoprire un traffico ARP sospetto: si possono usare 
<package>arpwatch</package>, <package>karpski</package>
o un più generico IDS che possa anche svolgere tale compito
(<package>snort</package>, <url name="preludio"
id="http://www.prelude-ids.org">...).
<item>
Implementare un filtraggio del traffico IP in grado di convalidare 
gli indirizzi MAC.

</list>



<sect id="snapshot">Una fotografia del sistema



<p>Prima di mettere il sistema in produzione se ne può fotografare l'attuale
stato: il risultato dell'operazione può tornare utile in caso di
compromissione (vedete <ref id="after-compromise">). Questo procedimento
dovrebbe essere ripetuto ad ogni aggiornamento del sistema, specialmente se
si aggiorna ad una nuova versione di Debian.

<p>A tale scopo si può usare un media scrivibile e rimuovibile che possa
essere impostato in sola lettura, come un floppy disk, se protetto da
scrittura dopo l'uso, o un CD aperto da un'unità CD-ROM - si può 
usare un CD riscrivibile, in modo da poter conservare copie di 
ripristino, magari con firma md5sum, create in date differenti, o un 
disco USB o ancora una card MMC (se il vostro sistema può accedere 
a tali dati e al contempo possono essere protetti in scrittura).

<p>Il seguente script crea una fotografia del sistema:

<example>
#!/bin/bash
/bin/mount /dev/fd0 /mnt/floppy
if [ ! -f /usr/bin/md5sum ] ; then
	echo "Cannot find md5sum. Aborting."
	exit 1
fi
/bin/cp /usr/bin/md5sum /mnt/floppy
echo "Calculating md5 database"
>/mnt/floppy/md5checksums.txt
for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
do
   find $dir -type f | xargs /usr/bin/md5sum >>/mnt/floppy/md5checksums-lib.txt
done
echo "post installation md5 database calculated"
if [ ! -f /usr/bin/sha1sum ] ; then
	echo "Cannot find sha1sum"
else
	/bin/cp /usr/bin/sha1sum /mnt/floppy
	echo "Calculating SHA-1 database"
	>/mnt/floppy/sha1checksums.txt
	for dir in /bin/ /sbin/ /usr/bin/ /usr/sbin/ /lib/ /usr/lib/
	do
	   find $dir -type f | xargs /usr/bin/sha1sum >>/mnt/floppy/sha1checksums-lib.txt
	done
	echo "post installation sha1 database calculated"
fi
/bin/umount /dev/fd0
exit 0
</example>

<p>Tenete conto che il binario di md5sum (e sha1sum se disponibile) 
si trova su floppy, per poter essere usato, in seguito, per 
controllare i binari del sistema (nel caso che abbiate preso dei trojan).
Comunque, se volete essere sicuri che state facendo girare un binario 
legittimo, potreste sia compilare una copia statica del binario di 
md5sum e usare quella (per evitare che una libreria libc con trojan 
interferisca con il binario), oppure usare una istantanea di md5sum 
solamente da un ambiente sano come un CD-ROM di salvataggio o un 
Live-CD (per evitare che un kernel con trojan interferisca).

Questo non verrà mai posto abbastanza in risalto: se siete su un 
sistema compromesso non potete fidarvi del suo output, vedete 
<ref id="after-compromise">.

<p>L'istantanea non comprende i file sotto 
<file>/var/lib/dpkg/info</file> che includono l'hash MD5 dei 
pacchetti installati (nei file che finiscono con 
<file>.md5sums</file>).  Potete anche copiare questa informazione, 
ma dovreste comunque tenere in conto che:

<list>
<item>i file md5sum includono l'md5sum non solo dei binari di 
sistema, ma di tutti i file forniti dai pacchetti Debian. Una 
conseguenza di ciò è che il database è più grande (5 Mb contro 
600 Kb in un sistema  Debian GNU/Linux con sistema grafico e 
circa 2.5 Gb di software installato) e non entrerà in un supporto 
rimovibile di scarsa capienza (tipo un floppy disk, ma 
probabilmente entrerebbe in una memoria rimovibile USB).

<item>non tutti i pacchetti Debian forniscono l'md5sum per i file 
installati fino a che non sarà (attualmente lo è) una pratica 
obbligatoria. Tenete in conto che, in ogni caso, avrete la 
possibilità di generare l'md5sum per tutti i pacchetti usando 
<package>debsums</package> una volta terminata l'installazione del 
sistema:
<example>
# debsums --generate=missing,keep
</example>

</list>

<p>Una volta fatta l'istantanea dovreste assicurarvi di impostare 
in sola lettura il dispositivo. Potrete poi archiviarlo per backup 
o metterlo in un disco ed usare <prgn>cron</prgn> ogni notte per 
confrontare l'md5sum originale con quella dell'istantanea.

<p>Se non volete approntare un controllo manuale potrete sempre 
usare uno dei programmi di controllo dell'integrità del sistema 
disponibili che faranno questo e anche di più, per maggiori 
informazioni leggete <ref id="periodic-integrity">.



<sect>Ulteriori raccomandazioni



<sect1>Non usare software che dipende dalle librerie SVGA (svgalib)


<p>
SVGAlib è molto carina per gli amanti della console come me, ma è
stato provato diverse volte, in passato, che è molto insicura.
Sono stati rilasciati exploit contro <prgn>zgv</prgn> ed era semplice
utilizzarli per diventare root. Sarebbe meglio evitare di usare 
programmi che fanno uso della SVGAlib, quando possibile.

<!-- FIXME: move this to policy section if there ever is one? -->


