<chapt id="sec-services">Rendere più sicuri i servizi che girano
                         sul vostro sistema


<p>I servizi attivi su un sistema possono essere resi più sicuri
in due modi:

<list>

<item>
Rendendoli accessibili solo dai punti di accesso (interfacce)
per i quali sono  necessari.
<item>
Configurandoli opportunamente cosicché possano essere usati solo
dagli utenti legittimati con un metodo di autorizzazione.
</list>


<p>Vincolare i servizi in maniera tale da renderli accessibili solo da un
luogo definito può essere fatto limitando il loro accesso a
livello di kernel (per es. i firewall), configurandoli in maniera tale
da ascoltare solo da una data interfaccia (alcuni servizi potrebbero
non fornire questa possibilità) o impiegando qualche altro metodo, per
esempio la patch linux vserver (per il 2.4.16) può essere
usata per obbligare i processi ad usare una sola interfaccia.

<p>Riguardo i servizi che vengono avviati da <prgn>inetd</prgn>
(<prgn>telnet</prgn>, <prgn>ftp</prgn>, <prgn>finger</prgn>,
<prgn>pop3</prgn>...) vale la pena far notare che <prgn>inetd</prgn>
può essere configurato in modo che i servizi lanciati rimangano in
ascolto solo su una data interfaccia di rete (usando
<tt>servizio@ip</tt> come sintassi), ma questa è una possibilità non
documentata. Uno dei suoi sostituti, il meta-demone
<prgn>xinetd</prgn> include un'opzione <tt>bind</tt> proprio a questo
proposito. Vedete <manref name="xinetd.conf" section="5">.

<example>
service nntp
{
        socket_type     = stream
        protocol        = tcp
        wait            = no
        user            = news
        group           = news
        server          = /usr/bin/env
        server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
+/usr/sbin/snntpd logger -p news.info
        bind            = 127.0.0.1
}
</example>

<p>Le sezioni seguenti forniscono dettagli su come configurare
opportunamente singoli e specifici servizi in funzione
dell'uso previsto.



<sect>Rendere sicuro ssh



<p>Se state ancora usando telnet invece di ssh, è meglio che passiate
a ssh prima di proseguire con la lettura di questo manuale.
Sarebbe bene utilizzare ssh invece di telnet per tutti i login remoti.
In un'epoca in cui è facile intercettare il traffico su Internet e
ottenere le password
trasmesse in chiaro, bisognerebbe usare solamente protocolli che
utilizzano la crittografia; per questo motivo meglio eseguire
subito <tt>apt-get install ssh</tt> sulla propria macchina.

<p>Incoraggiate tutti gli utenti del vostro sistema ad usare
ssh invece di telnet o, ancora meglio, disinstallare
telnet/telnetd. Oltre a quanto detto bisognerebbe evitare di 
autenticarsi nel sistema come root con ssh e utilizzare invece 
dei metodi alternativi per diventare root, come
<prgn>su</prgn> o <prgn>sudo</prgn>. Infine,
meglio modificare anche il file
<file>sshd_config</file>, in <file>/etc/ssh</file>, per
aumentare la sicurezza:

<list>
<item><tt>ListenAddress 192.168.0.1</tt>

<p>Fa in modo che ssh ascolti solo su una data interfaccia, nel
caso ne abbiate più di una (e non vogliate che ssh sia disponibile
per le altre) o nel caso prevediate di aggiungere schede di rete
in futuro (e non vogliate connessioni a ssh da queste ultime).

<item><tt>PermitRootLogin no</tt>
<p>
Cerca di impedire l'autenticazione come root quando possibile.
Se volete diventare root con ssh, ora sono necessarie due
autenticazioni e la password di root non può essere ottenuta
con un attacco a forza bruta per mezzo di SSH.

<item><tt>Port 666 o ListenAddress 192.168.0.1:666 </tt>
<p>
Cambia la porta di ascolto, così l'intruso non può essere
del tutto certo che ci sia un demone ssh (bisogna tenere
conto che in questo caso si tratta di 
sicurezza mediante riservatezza 
(security by obscurity)).

<item><tt>PermitEmptyPasswords no</tt>
<p>
Utilizzare password vuote significa prendersi gioco della
sicurezza del sistema.

<item><tt>AllowUsers alex ref me@somewhere</tt>
<p>
Permette solo ad alcuni utenti di avere accesso alla macchina
con ssh. <tt>user@host</tt> può anche essere usato per permettere
l'accesso di un dato utente solo da un determinato host.

<item><tt>AllowGroups wheel admin</tt>
<p>
Permette l'accesso alla macchina mediante ssh solo ai membri 
di un determinato gruppo. AllowGroups ed AllowUser hanno
direttive equivalenti per negare l'accesso alla macchina.
Non sorprende che vengano chiamati "DenyUsers" e "DenyGroups".

<item><tt>PasswordAuthentication yes</tt>

<p>
Siete liberi di scegliere come fare. &Egrave; più sicuro permettere
l'accesso alla macchina solo agli utenti le cui chiavi ssh
siano contenute nel file ~/.ssh/authorized_keys. Se questo è il
comportamento desiderato, impostate questa opzione a "no".

<!-- FIXME: what does this mean? Is it "more secure" to set this to
"no"? (era) --> <!-- jfs, IMHO yes since you place the key of the
incoming host in your server and the authentication is done against
the key -->

<item>
Disabilitare ogni forma di autenticazione non necessaria, se
non viene utilizzata; per esempio disabilitando 
<tt>RhostsRSAAuthentication</tt>, <tt>HostbasedAuthentication</tt>, 
<tt>KerberosAuthentication</tt> o <tt>RhostsAuthentication</tt>, 
anche se lo sono in maniera predefinita (vedete la pagina man 
<manref name="sshd_config" section="5">).

<item><tt>Protocol 2</tt>

<p>
Disabilita il protocollo versione 1, visto che ha dei
difetti di progettazione che rendono più facile corrompere (crack passwords)
le password. Per maggiori informazioni leggete 
<url id="http://paris.cs.berkeley.edu/~dawnson/papers/ssh-timing.pdf" name="il documento relativo ai problemi del protocollo ssh">
o le <url id="http://xforce.iss.net/static/6449.php" name="raccomandazioni di Xforce">.

<item><tt>Banner /etc/some_file</tt>
<p>
Aggiunge un avviso (contenuto nel file) agli utenti che si connettono 
ad un server ssh. In alcuni Stati, per avere protezione legale,
occorre inviare un avviso prima di accedere ad certo sistema 
che avvisi quando l'accesso non è autorizzato o che state
controllando gli accessi degli utenti.
</list>


<p>
Potete limitare l'accesso al server ssh anche utilizzando le direttive 
<tt>pam_listfile</tt> o <tt>pam_wheel</tt> nel file di configurazione 
PAM per ssh, in modo da limitare le autenticazioni ssh. Per 
esempio potreste escludere tutti gli utenti non elencati in 
<file>/etc/loginusers</file> aggiungendo questa riga a 
<file>/etc/pam.d/ssh</file>:

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

<p>Come ultima osservazione dovreste considerare che queste direttive
si riferiscono ad un file di configurazione di OpenSSH. Al momento
vengono utilizzati comunemente tre demoni SSH: ssh1, ssh2 e l'OpenSSH
degli sviluppatori di OpenBSD. ssh1 è stato il primo demone ssh
disponibile ed è ancora il più utilizzato (ci sono voci che esista
anche una versione per Windows). ssh2 ha molti vantaggi rispetto a
ssh1 tranne per il fatto di essere rilasciato con una licenza
closed-source. OpenSSH è un demone ssh rilasciato come software
libero che supporta sia ssh1 che ssh2. OpenSSH è la versione che viene
installata in Debian quando selezionate il pacchetto <package>ssh</package>.

<p>
Potete ottenere più informazioni su come impostare SSH con il
supporto PAM negli <url id="http://lists.debian.org/debian-security/2001/debian-security-200111/msg00395.html" name="archivi della mailing list sulla sicurezza">.



<sect1 id="ssh-chroot">Ssh in chroot

<p>Per ora OpenSSH non fornisce un modo per poter ingabbiare
automaticamente, con chroot, gli utenti dopo una connessione (la versione
commerciale invece fornisce questa possibilità). Ad ogni modo esiste
un progetto per dare questa funzionalità anche ad OpenSSH, vedete
<url id="http://chrootssh.sourceforge.net">, al momento credo non sia
disponibile il pacchetto per Debian. Potreste usare al suo
posto il modulo <file>pam_chroot</file> come descritto in
<ref id="user-restrict">.

<p>
In <ref id="chroot-ssh-env"> potete trovare
numerose opzioni per creare un ambiente chroot per SSH.


<sect1>Client SSH

<p>Se usate un client SSH con un server SSH dovreste assicurarvi
che supporti gli stessi protocolli impostati sul server.
Per esempio, se utilizzate il pacchetto <package>mindterm</package>,
questo supporta solo il protocollo con versione 1. Mentre, il server
sshd, in modo predefinito, viene configurato per accettare solo la
versione 2 (per ragioni di sicurezza).


<sect1>Non permettere il trasferimento di file

<p>Se <em>non</em> volete che gli utenti trasferiscano file da e verso
il server ssh dovete limitare l'accesso all'<prgn>sftp-server</prgn>
<em>e</em> l'accesso a <prgn>scp</prgn>.
Potete limitare l'<prgn>sftp-server</prgn> configurando il corretto
<tt>Subsystem</tt> in <file>/etc/ssh/sshd_config</file>.

<p>Potete anche ingabbiare in chroot gli utenti (usando
<package>libpam-chroot</package>) cosicché, nonostante il
trasferimento di file sia permesso, gli utenti siano costretti in un
ambiente limitato che non comprende file di sistema.



<sect1 id="ssh-only-file">Limitare l'accesso al solo
                          trasferimento di file

<p>Potreste desiderare di limitare l'accesso agli utenti al solo 
trasferimento di file e non concedere loro shell interattive. A 
questo scopo potete anche:

<list>

<item>non permettere agli utenti il login per mezzo del server ssh 
(come descritto in precedenza, sia mediante il suo file di 
configurazione che tramite il file di configurazione di PAM).

<item>concedere agli utenti una shell limitata come 
<package>scponly</package> o <package>rssh</package>. Queste shell 
limitano i comandi disponibili agli utenti in modo da non fornire 
alcun privilegio di esecuzione remota.

</list>






<sect>La sicurezza in Squid

<p>
Squid è uno dei più famosi server proxy/cache e ci sono alcuni
problemi di sicurezza che dovreste tenere presenti. Il file di
configurazione predefinito di Squid nega ogni richiesta degli utenti.
Invece il pacchetto Debian permette accessi da 'localhost', dovreste
solamente configurare il vostro browser correttamente. Dovreste
configurare Squid per permettere l'accesso a utenti, host o reti
fidate definendo le Access Control List (Liste di Controllo
d'Accesso [ndT]) in <file>/etc/squid.conf</file>, vedete la 
<url name="Squid User's Guide" id="http://www.deckle.co.za/squid-users-guide/Main_Page">
per ulteriori informazioni riguardo la definizione delle regole per le
ACL. Da notare che Debian fornisce una configurazione minima di
Squid, che preverrà tutto, tranne la connessione al proprio
proxy server (che utilizzerà in modo predefinito la porta 3128) da
<em>localhost</em>. Sarà necessario personalizzare il vostro
<file>/etc/squid.conf</file> a seconda delle necessità.
La configurazione minima consigliata (fornita con il pacchetto)
è mostrata qui di seguito:

<example>
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl SSL_ports port 443 563
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp
acl Safe_ports port 443 563     # https, snews
acl Safe_ports port 70          # gopher
acl Safe_ports port 210         # wais
acl Safe_ports port 1025-65535  # unregistered ports
acl Safe_ports port 280         # http-mgmt
acl Safe_ports port 488         # gss-http
acl Safe_ports port 591         # filemaker
acl Safe_ports port 777         # multiling http
acl Safe_ports port 901         # SWAT
acl purge method PURGE
acl CONNECT method CONNECT
(...)
# Only allow cachemgr access from localhost
http_access allow manager localhost
http_access deny manager
# Only allow purge requests from localhost
http_access allow purge localhost
http_access deny purge
# Deny requests to unknown ports
http_access deny !Safe_ports
# Deny CONNECT to other than SSL ports
http_access deny CONNECT !SSL_ports
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
http_access allow localhost
# And finally deny all other access to this proxy
http_access deny all
#Default:
# icp_access deny all
#
#Allow ICP queries from everyone
icp_access allow all
</example>

<p>Dovreste configurare Squid anche basandovi sulle vostre risorse
di sistema, inclusa la memoria cache (opzione <tt>cache_mem</tt>), la
posizione dei file nella cache e la quantità di spazio che occuperanno
sull'hard disk (opzione <tt>cache_dir</tt>).


<p>
Da notare che, se non correttamente configurato, qualcuno potrebbe
inoltrare un messaggio di posta tramite Squid, poiché i
protocolli HTTP e SMTP sono abbastanza simili. La configurazione predefinita
di Squid nega l'accesso alla porta 25. Se desiderate
permettere connessioni alla porta 25 aggiungetela alla lista delle
Safe_ports. Comunque, questo <em>NON</em> è raccomandato.

<p>
Impostare e configurare correttamente il server proxy/cache è solo
una parte di lavoro per mantenere il vostro sito sicuro. Un altro 
compito necessario è l'analisi dei log di squid per assicurarsi che 
tutto vada come dovrebbe. Ci sono alcuni pacchetti in Debian 
GNU/Linux che potrebbero aiutare un amministratore a farlo. 
I seguenti sono disponibili in Debian 3.0 e Debian 3.1 (sarge):

<list>

<item><package>calamaris</package> - Analizzatore di log per i file dei 
                                     proxy Squid ed Oops.
<item><package>modlogan</package> - Un analizzatore modulare dei file di log.

<item><package>sarg</package> - Genera rapporti sull'analisi di Squid.

<item><package>squidtaild</package> - Un programma per monitorare i log 
                                      di Squid.
</list>


<p>
Quando utilizzate Squid in Accelerator Mode, questo funziona anche
come web server. Utilizzando questa opzione la complessità del codice
aumenta, rendendolo meno leggibile. La configurazione predefinita di 
Squid non prevede il funzionamento come web server, dunque non vi 
dovete preoccupare di ciò. Notate che se desiderate usare questa 
funzione dovete essere certi che sia veramente necessaria. Per 
trovare più informazioni riguardo l'Accelerator Mode in Squid vedete 
la <url name="Squid User's Guide - Accelerator Mode"
id="http://www.deckle.co.za/squid-users-guide/Accelerator_Mode">


<sect id="ftp-secure">Rendere sicuro FTP

<p>Se avete realmente la necessità di usare il servizio FTP (senza
poterlo costringere in un tunnel SSL o SSH o tramite sslwrap),
dovreste usare chroot per ingabbiare FTP nella directory home
dell'utente ftp, cosicché l'utente non sia in grado di vedere niente
altro se non la sua directory. Altrimenti potrebbe attraversare il
filesystem principale come se avesse una shell nel sistema. Potete
aggiungere la seguente riga nel vostro <file>proftpd.conf</file>
nella sezione globale per abilitare la funzione chroot:

<example>
DefaultRoot ~
</example>

<p>
Fate ripartire ProFTPd con <tt>/etc/init.d/proftpd restart</tt> e
controllate se adesso riuscite ad uscire dalla vostra directory home.

<p>
Per prevenire gli attacchi DoS a ProFTPd usando ../../.., aggiungete
la seguente riga in <file>/etc/proftpd.conf</file>:

<example>
DenyFilter \*.*/
</example>

<p>
Ricordate sempre che FTP spedisce login e password di
autenticazione in chiaro (questo non è un problema se state
fornendo un servizio anonimo pubblico) e che ci sono alternative
migliori in Debian per questo. Per esempio, <prgn>sftp</prgn>
(fornito da <package>ssh</package>). Ci sono
anche implementazioni libere di SSH per altri sistemi operativi:
<url id="http://www.chiark.greenend.org.uk/~sgtatham/putty/" name="putty">
e <url id="http://www.cygwin.com" name="cygwin"> per esempio.

<!-- contributed by Jesus Climent -->

<p>Ad ogni modo, se state mantenendo ancora il server FTP mentre
gli utenti accedono via SSH potreste incontrare un tipico
problema. Gli utenti che accedono al server FTP anonimo all'interno
del sistema SSH-sicuro potrebbero tentare di effettuare un login al
<em>server FTP</em>. Mentre l'accesso verrà rifiutato, la password verrà
spedita senza alcun dubbio attraverso la rete, in chiaro. Per
evitare questo, lo sviluppatore di ProFTPd TJ Sanders ha scritto una
patch che previene gli utenti girando al server FTP anonimo un account
SSH valido. Altre informazioni e patch disponibili alla pagina
<url id="http://www.castaglia.org/proftpd/#Patches" name="ProFTPD Patches">.
Questa patch è stata portata in Debian, vedete il
<url id="http://bugs.debian.org/145669" name="Bug #145669">.





<sect>Rendere sicuro l'accesso al sistema X Window

<p>Oggi, i terminali X vengono usati da numerose e svariate compagnie,
con il sistema X Window è necessario un solo server per numerose
postazioni singole.
Questo potrebbe essere pericoloso perché è necessario permettere al
file server di connettersi ai client (X server dal punto di vista di
X. X scambia le solite definizioni di client e server). Se seguirete il
(pessimo) suggerimento di numerosi documenti, digiterete <tt>xhost +</tt>
sulla vostra macchina. Questo permette ad ogni client X di
connettersi al sistema. Per una piccola miglioria di sicurezza, potrete
invece usare il comando <tt>xhost +hostname</tt> per permettere l'accesso da
specifici host.

<p>Una soluzione più sicura, credo, è quella di usare ssh per creare un tunnel
per X e cifrare <!-- FIXME: add "and compress" -->
l'intera sessione. Questo viene fatto automaticamente
quando vi connettete via ssh ad un'altra macchina.
<!-- This has to be enabled in <file>/etc/ssh/ssh_config</file> by -->
<!-- setting <tt>X11Forwarding</tt> to <tt>yes</tt>. -->
Perché questo
funzioni dovete configurare sia il client che il server ssh. Per il
client ssh dovrete abilitare <tt>ForwardX11</tt> con un <tt>yes</tt> in
<file>/etc/ssh/ssh_config</file>. Per il server ssh, invece, dovrete mettere un
<tt>yes</tt> in <file>/etc/ssh/sshd_config</file> a fianco di
<tt>X11Forwarding</tt> e il
package <package>xbase-clients</package> dovrebbe essere installato
perché il server ssh usi <file>/usr/X11R6/bin/xauth</file>
(<file>/usr/bin/xauth</file> su Debian instabile) nel
momento in cui configura uno pseudo display X.
<!-- discovered this when setting up two minimally installed boxes -->
Con SSH, dovreste aggirare completamente il controllo
dell'accesso con xhost.
<!-- FIXME: check. The text said "has to be disabled" [sic] -->

<p>Per una migliore sicurezza, se non avete bisogno di accedere ad X da
altre macchine tagliate il legame alla porta TCP 6000 semplicemente
digitando:

<example>$ startx -- -nolisten tcp</example>

<p>Questo è il comportamento predefinito in Xfree 4.1.0 (il server X
fornito da Debian 3.0). Se state eseguendo Xfree 3.3.6 (cioè se avete 
Debian 2.2 installata) potete modificare
<file>/etc/X11/xinit/xserverrcc</file> per avere qualcosa di simile a:

<example>
#!/bin/sh
exec /usr/bin/X11/X -dpi 100 -nolisten tcp
</example>

<p>Se utilizzate XDM impostate
<file>/etc/X11/xdm/Xservers</file> come segue:
<tt>:0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp</tt>.
Se invece usate GDM assicuratevi che in
<file>/etc/gdm/gdm.conf</file> sia impostata l'opzione
<tt>DisallowTCP=true</tt> (che in Debian viene impostata in modo
predefinito). Questo fondamentalmente aggiunge
<tt>-nolisten tcp</tt> a tutti i comandi inviati 
ad X<footnote>
GDM <em>non</em> aggiungerà <tt>-nolisten tcp</tt> se rileverà
opzioni <tt>-query</tt> o <tt>-indirect</tt> da riga di
comando, visto che le direttive potrebbero non funzionare.
</footnote>.


<p>Potete anche impostare il timeout di sistema predefinito per il
lock dello <prgn>xscreensaver</prgn>. Anche se l'utente può
sovrascriverla, dovreste modificare la configurazione
<file>/etc/X11/app-defaults/XScreenSaver</file> e cambiare la
riga del lock:

<example>
*lock:                  False
</example>

<p>(che è il predefinito di Debian) in:


<example>
*lock:                  True
</example>

<p>FIXME: aggiungere informazioni su come disabilitare gli screensaver
che mostrano il desktop dell'utente (che potrebbe avere informazioni
sensibili).

<p>Leggete di più sulla sicurezza di X Window in
<url id="http://www.tldp.org/HOWTO/XWindow-User-HOWTO.html" name="XWindow-User-HOWTO">
(<file>/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz</file>).

<p>FIXME: Aggiungere informazioni prese da un thread di debian-security su
come fare a cambiare i file di configurazione di XFree 3.3.6.



<sect1>Controllare il display manager

<p>Se avete un display manager installato per uso locale (avete cioè un
piacevole login grafico), assicuratevi che XDMCP (Protocollo di controllo
per il Display Manager di X) sia disabilitato. In XDM questo si può
ottenere agendo sulla riga in <tt>/etc/X11/xdm/xdm-config</tt>:

<example>
DisplayManager.requestPort:     0
</example>

<p>Per GDM ci dovrebbe essere questo nel vostro gdm.conf:

<example>
[xdmcp]
Enable=false
</example>

<p>Di norma, in Debian, tutti i display manager
vengono configurati per non  lanciare servizi XDMCP.




<sect>Rendere sicuri gli accessi alla stampante (specifico per lpd ed lprng)

<p>Immaginate  di arrivare  al lavoro  e trovarvi  una montagna  di carta
uscita dalla stampante perché il demone di stampa ha subito un attacco
DoS. Lo trovereste piacevole?

<!-- Info based on Dale Southard's post to debian-security april 11th 2002-->
<p>
In qualsiasi architettura per la stampa in Unix, ci deve essere un modo
per ottenere dal client i dati per il server di stampa. Tradizionalmente,
<prgn>lpr</prgn> ed <prgn>lp</prgn> sono i client che si occupano di
fornire i comandi per copiare o creare dei link simbolici ai dati 
contenuti nella directory spool (che è il motivo per il quale usualmente
questi programmi sono SUID o SGID).

<p>
Per evitare questi problemi, dovreste mantenere il vostro server di stampa
particolarmente sicuro. Questo significa necessariamente, configurare il
vostro servizio di stampa per far sì che consenta connessioni solamente
dai server fidati. In merito a questo, aggiungete i server a cui volete 
consentire la stampa nel vostro <file>/etc/hosts.lpd</file>.

<p>
In ogni caso, il demone <prgn>lpr</prgn> accetta in ingresso 
connessioni sulla porta 515 da qualsiasi interfaccia. Dovreste considerare
la possibilità di usare un firewall per le connessioni  tra la rete e gli 
host a cui non è consentito stampare (così il demone <prgn>lpr</prgn>
può rimanere in attesa solo da determinati indirizzi IP).

<!-- FIXME
<p>Of course, you could also take the lpr/lprng sources
and change them so that the connect function is only done to "127.0.0.1".
apt-get source lpr
and patch the bind (finet) call
-->

<p>
<prgn>Lprng</prgn> dovrebbe essere preferito a <prgn>lpr</prgn>
visto che può essere configurato per avere il controllo sugli 
accessi IP. Potete anche specificare quale interfaccia proteggere
(sebbene piuttosto bizzarro).

<!-- FIXME: ask Craig Small about his post in debian-private 19th october 2001 
-->

<p>
Se state usando nel vostro sistema una stampante locale, probabilmente 
non desiderate condividere questo servizio sulla rete. Considerate allora
l'opportunità di usare un altro sistema di stampa, come quello fornito
da <package>cups</package> o <url id="http://pdq.sourceforge.net/" name="PDQ">
che si basa sui permessi degli utenti sul dispositivo 
<file>/dev/lp0</file>.

<p>
In <package>cups</package>, la stampa dei dati viene trasferita al server
mediante il protocollo http. Questo significa che il client non ha
bisogno di particolari privilegi, ma richiede che il server sia in
ascolto su qualche porta. 

<p>
Tuttavia, se desiderate usare <prgn>cups</prgn> in locale potete 
configurarlo proteggendo l'interfaccia di loopback, modificando il
file <file>/etc/cups/cupsd.conf</file>:

<example>
Listen 127.0.0.1:631
</example>

<p>
Vi sono molte altre opzioni per la sicurezza simili a quelle 
contenute nel file di configurazione hosts, che permettono di 
consentire o negare l'accesso dalla rete. Tuttavia, se non ne 
avete bisogno, una soluzione migliore potrebbe essere quella di 
limitare o escludere le connessioni sulle porte in attesa.
<prgn>Cups</prgn> utilizza la porta di comunicazione HTTP, se
desiderate non divulgare informazioni potenzialmente utili ad
eventuali attaccanti, aggiungete (e chiudete verso l'esterno le 
porte aperte) anche:

<example>
&lt;Location /&gt;
  Order Deny,Allow
  Deny From All
  Allow From 127.0.0.1
&lt;/Location&gt;
</example>

<p>Questo file di configurazione può essere modificato aggiungendo 
ulteriori funzionalità, inclusi certificati e cifratura SSL/TLS.
Il manuale è disponibile all'indirizzo http://localhost:631/ o in
<url id="cups.org">.

<p>FIXME: Aggiungere ulteriori contenuti (l'articolo su 
<url id="http://www.rootprompt.org" name="Amateur Fortress Building">
fornisce alcuni punti di vista molto interessanti).

<p>FIXME: Controllare se PDG è disponibile in Debian e se lo fosse,
suggerirlo come sistema di stampa preferito.

<p>FIXME: Controllare se Farmer/Wietse ha rimpiazzato il demone di stampa 
e se è disponibile in Debian.


<sect>Rendere sicuro il servizio di posta

<p>Se il vostro server non fornisce servizi di posta, non avete bisogno
di avere un demone di posta in attesa di connessioni.
Potreste aver bisogno solamente di un sistema di trasporto locale, 
che ad esempio riceva la posta per l'utente root e dagli altri
allarmi di sistema.

<p>Se state usando <prgn>exim</prgn> non avete bisogno di configurare
il demone, in quanto, in maniera predefinita, si assume 
<prgn>cron</prgn> il compito di svuotare la coda di posta. Vedete
<ref id="disableserv"> per sapere come questo avviene.



<sect1>Configurare un nullmailer

<p>Potreste voler avere un demone di posta locale che 
possa ritrasmettere verso un altro sistema i messaggi spediti
localmente. Questa è una cosa comune quando dobbiamo amministrare un
certo numero di sistemi e non desideriamo connetterci ad ognuno di essi
per leggere la posta spedita localmente. Proprio come la scrittura dei
log di ogni singolo sistema può essere centralizzata usando un
server syslog centrale, la posta può essere spedita ad un server di
posta centralizzato.

<p>Un tale sistema <em>solo-redirezione (relay-only)</em> 
dovrebbe essere propriamente
configurato per svolgere questo compito.
Il demone potrebbe anche essere configurato per rimanere in ascolto
sul solo indirizzo di loopback.

<p>I seguenti passaggi per la configurazione si rendono necessari 
solo per configurare il pacchetto <package>exim</package> nel 
rilascio di Debian 3.0. Nell'utilizzo di un rilascio successivo 
(come ad esempio per 3.1 che usa <package>exim4</package>) il 
sistema d'installazione è stato migliorato in maniera tale che se 
l'MTA viene configurato per smistare solamente la posta locale, 
automaticamente allora permetterà connessioni solo dalla macchina 
locale e non consentirà connessioni remote.

<p>In un sistema  Debian 3.0 che usa <package>exim</package>, dovrete 
rimuovere da <prgn>inetd</prgn> il demone SMTP.

<example>
$ update-inetd --disable smtp
</example>

<p>e configurare il demone di posta perché rimanga in ascolto sulla sola
interfaccia di loopback. In <prgn>exim</prgn> (l'MTA predefinito) 
lo potete fare modificando il file 
<file>/etc/exim.conf</file> e aggiungendo la linea seguente:

<example>
local_interfaces = "127.0.0.1"
</example>

<p>Riavviare entrambi i demoni (inetd e exim); exim sarà in ascolto
sul solo socket 127.0.0.1:25. Fate attenzione e per prima cosa
disabilitate inetd, altrimenti exim non partirà poiché il demone inetd
sta già gestendo le connessioni in arrivo.

<p>Per <prgn>postfix</prgn> modificate <file>/etc/postfix/main.conf</file>:

<example>
inet_interfaces = localhost
</example>

<p>Se volete solo posta locale, questo approccio è migliore dell'uso del
tcp-wrapping sul demone di posta o dell'aggiunta di regole per il firewall
per limitarne l'accesso. Tuttavia, se avete bisogno che esso
resti in ascolto su altre interfacce, lo potreste lanciare da inetd
ed aggiungere un tcp wrapper in modo che le connessioni in arrivo
vengano controllate tramite i file <file>/etc/hosts.allow</file> e
<file>/etc/hosts.deny</file>. Inoltre, configurando un'appropriata 
scrittura dei
log per qualunque dei metodi sopra descritti, potrete sapere quando si
verifica un tentativo di accesso non autorizzato al demone di posta.

<p>In ogni caso, per respingere i tentativi di ritrasmissione della posta
a livello di SMTP, potete cambiare <file>/etc/exim/exim.conf</file> in 
modo che contenga:

<example>
receiver_verify = true
</example>

<p>Anche se il vostro server di posta non ritrasmetterà il messaggio,
questo tipo di configurazione è necessaria al test di
ritrasmissione che trovate all'indirizzo
<url id="http://www.abuse.net/relay.html"> per determinare che il 
vostro server <em>non</em> sia in grado di ritrasmettere.

<p>Tuttavia, se desiderate una configurazione solo-ritrasmissione,
potreste cambiare il demone della posta con programmi che possono
<em>solo</em> essere configurati per inoltrare la posta ad un server di posta
remoto. Al momento Debian fornisce <package>ssmtp</package> e 
<package>nullmailer</package> a questo scopo. 
In ogni caso, potrete valutare da soli i vari email transport agents

<footnote>
<p>Per ottenere la lista dei demoni di posta disponibili in Debian
provate:

<example>
$ apt-cache search mail-transport-agent
</example>
<p>
La lista non includerà <prgn>qmail</prgn>, che viene distribuito 
solamente in formato sorgente con il pacchetto 
<package>qmail-src</package>.
</footnote>

forniti da Debian e scegliere quello che meglio
si adatta agli scopi del vostro sistema.


<sect1>Fornire un accesso sicuro alle mailbox

<p>Per fornire un accesso remoto alle mailbox ci sono molti demoni
POP3 e IMAP disponibili<footnote>
          Un elenco dei server/demoni che supportano questi 
          protocolli in Debian la potete ottenere con:

<example>
$ apt-cache search pop3-server
$ apt-cache search imap-server
</example>
</footnote>.

Tuttavia, se fornite accesso IMAP, sappiate
che questo è un protocollo di accesso generale ai file e può
diventare l'equivalente di un accesso tramite shell, mediante il
quale si porrebbero gli utenti in condizioni tali da permetterne
l'accesso a qualunque file.

<p>Provate, ad esempio, a configurare <tt>{server.com}/etc/passwd</tt> 
come percorso della vostra inbox. Se ci riuscite questo significa che 
il demone IMAP non è correttamente configurato per impedire questo 
tipo di accesso.

<p>Tra i server IMAP disponibili in Debian il server <prgn>cyrus</prgn> (nel
pacchetto <package>cyrus-imapd</package>) risolve il problema,
facendo in modo che tutti gli accessi siano rivolti verso un database 
che risiede in una parte del file system dove l'accesso è ristretto. 
Inoltre, <prgn>uw-imapd</prgn> (installare <prgn>uw-imapd</prgn> o 
meglio, se il vostro client IMAP lo supporta, <package>uw-imapd-ssl</package>)
può essere configurato per ottenere la cartella della
posta degli utenti in chroot, ma questa funzionalità non è abilitata 
nella configurazione predefinita. La documentazione a corredo del programma
fornisce ulteriori informazioni su come configurarlo.

<p>Inoltre, potreste voler eseguire un server IMAP che non necessiti
di utenti validi creati sul sistema locale (cosa che consentirebbe
anche l'accesso tramite shell); sia <package>courier-imap</package> 
(per IMAP) che
<package>courier-pop</package> <package>teapop</package> (per POP3) e 
<package>cyrus-imapd</package> (per POP3 e IMAP)
forniscono server con metodi di autenticazione non dipendenti dagli
account degli utenti locali. <prgn>Cyrus</prgn> può 
usare qualunque metodo di
autenticazione configurabile per mezzo di PAM, mentre <prgn>teapop</prgn> 
può usare
dei database (come <package>postgresql</package> e <package>mysql</package>) 
per l'autenticazione degli utenti.

<p>FIXME: Controllare: anche <package>uw-imapd</package> potrebbe essere
configurato per l'autenticazione utenti mediante PAM.


<sect1>Ricevere posta in sicurezza

<p>Nella ricezione e lettura della posta viene impiegato il più comune
protocollo con testo in chiaro; usando sia IMAP che POP3, si
invia la propria password in chiaro,  in questo modo, da quel momento in
avanti,  quasi chiunque può leggere la nostra posta; per evitare ciò,
scaricatela usando il protocollo SSL o,  in alternativa, ssh se avete
un'account dotato di shell sulla postazione che funge da server POP o
IMAP. Ecco un essenziale <file>fetchmailrc</file> esemplificativo:

<example>
poll my-imap-mailserver.org via "localhost"
  with proto IMAP port 1236
      user "ref" there with password "hackme" is alex here warnings 3600
    folders
      .Mail/debian
    preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
     my-imap-mailserver.org sleep 15 &lt;/dev/null &gt; /dev/null'
</example>

<p>La linea che inizia con "preconnect" è importante, in quanto dà il via
ad una  sessione ssh e crea il tunnel necessario, che inoltra le
connessioni alla porta 1236 del localhost verso il server di posta IMAP,
in modo automatico, ma  sottoponendole a cifratura. Un'altra
possibilità sarebbe usare fetchmail con la funzionalità SSL.

<p>Se volete fornire servizi di posta cifrata, come POP e IMAP, usate
il comando <tt>apt-get install stunnel</tt> e attivate i demoni in
questo modo:

<example>
stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd
</example>

<p>Questo ultimo comando collega il demone fornito (-l) alla porta (-d) e
utilizza lo specificato modo di certificazione SSL (-p).


<sect id="sec-bind">Rendere sicuro BIND

<p>Ci sono diversi problemi da affrontare per rendere sicuro il 
demone del domain server, questi sono simili a quelli che 
incontrate normalmente quando vengono resi sicuri altri servizi:

<list>

<item>
Configurare il demone stesso in modo che non possa essere possibile
abusarne dall'esterno (vedete <ref id="configure-bind">). Questo 
include limitare la possibilità di richieste da parte dei client: 
trasferimenti di zona e richieste ricorsive.
<item>
Limitare l'accesso del demone al server stesso di modo che, in caso di
accesso indesiderato tramite il demone, i danni al sistema siano limitati.
Questo include far girare il demone come utente non privilegiato 
(vedete <ref id="user-bind">) in un ambiente chrooted
(vedete <ref id="chroot-bind">).
</list>



<sect1 id="configure-bind">Configurazione di Bind per evitare abusi


<p>Dovreste limitare alcune delle informazioni che vengono servite 
tramite DNS ai client esterni, in modo che non possa essere usato per
reperire importanti informazioni, che non volete far conoscere, sulla 
vostra organizzazione. Questo consiste nell'aggiungere le seguenti 
opzioni: <em>allow-transfer</em>, <em>allow-query</em>,
<em>allow-recursive</em> e <em>version</em>.
Potete anche limitarle nella sezione globale (in modo che vengano
applicate in tutte le zone servite) oppure per zona. Questa informazione
viene documentata nel pacchetto <package>bind-doc</package>, potrete 
leggere di più su questo argomento in 
<file>/usr/share/doc/bind/html/index.html</file> una volta che
avrete installato il pacchetto.

<p>Immaginate che il vostro server sia connesso ad Internet ed 
alla vostra rete interna, con vostro IP locale impostato a 
192.168.1.2 (un server base con due connessioni di rete), non 
volete offrire nessun servizio su Internet e volete solamente 
abilitare il la risoluzione DNS per vostri host interni. Potete 
effettuare quest'operazione includendo le seguenti righe in
<file>/etc/bind/named.conf</file>:

<example>
options {
            allow-query { 192.168.1/24; } ;
            allow-transfer { none; } ; 
            allow-recursion { 192.168.1/24; } ;
            listen-on { 192.168.1.2; } ;
            forward { only; } ;
            forwarders { A.B.C.D; } ;
};
</example>

<p>L'opzione <em>listen-on</em> vincola il 
DNS sull'interfaccia che ha l'indirizzo
interno e anche se questa interfaccia è la stessa che si
connette ad Internet (ad esempio se state utilizzando NAT), le richieste
verranno accettate solamente se provengono dai vostri host interni. Se
il sistema ha interfacce multiple e non è presente il parametro 
<em>listen-on</em>,
solo gli utenti interni potranno effettuare richieste, anche se, visto che
la porta sarebbe accessibile agli attacchi dall'esterno, qualcuno
potrebbe cercare di farvi andare in crash (o provando attacchi di tipo
buffer overflow) il server DNS. Potete anche fare in modo che il DNS ascolti
unicamente su 127.0.0.1 se non dovete fornire il servizio ad altri sistemi
tranne che a voi stessi.

<p>Il record version.bind della classe chaos contiene la versione del
processo bind che sta girando correntemente. Questa informazione viene
spesso usata da scanner automatici o individui maliziosi con l'intento
di determinare se bind è vulnerabile o meno ad un dato attacco.
Non fornendo informazioni o fornendole false all'interno del record
version.bind, vengono limitate le probabilità che il server venga attaccato
sulla base della versione pubblicata. Per fornire la vostra versione
utilizzate la direttiva <em>version</em> nella seguente maniera:

<example> options { ... various options here ...
version "Not available."; }; </example>

<p>Cambiare il record version.bind non fornisce protezione a fronte di
eventuali attacchi, ma può essere considerata un'utile salvaguardia.

<p>Un esempio di configurazione del file <file>named.conf</file> 
potrebbe essere la seguente:

<example>
acl internal {
        127.0.0.1/32;           // localhost
        10.0.0.0/8;             // internal
        aa.bb.cc.dd;            // eth0 IP
};

acl friendly {
        ee.ff.gg.hh;            // slave DNS
        aa.bb.cc.dd;            // eth0 IP
        127.0.0.1/32;           // localhost
        10.0.0.0/8;             // internal
};

options {
        directory "/var/cache/bind";
        allow-query { internal; };
        allow-recursive { internal; };
        allow-transfer { none; };
};
// From here to the mysite.bogus zone 
// is basically unmodified from the debian default
logging {
        category lame-servers { null; };
        category cname { null; };   
};

zone "." {
        type hint;
        file "/etc/bind/db.root";
};

zone "localhost" {
        type master;
        file "/etc/bind/db.local";
};

zone "127.in-addr.arpa" {
        type master;
        file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
        type master;
        file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
        type master;
        file "/etc/bind/db.255";
};

// zones I added myself
zone "mysite.bogus" {
        type master;
        file "/etc/bind/named.mysite";
        allow-query { any; };
        allow-transfer { friendly; };
};
</example>

<p>Controllate il Bug Tracking System riguardo a Bind, specificatamente 
il <url id="http://bugs.debian.org/94760" name="Bug #94760 
(concernente le ACL sui trasferimenti di zona)">. Sentitevi liberi di 
riportare informazioni sui bug che riscontrate, se pensate di poter 
aggiungere informazioni utili.



<sect1 id="user-bind">Cambiare l'utente di BIND

<p>Riguardo il come limitare i privilegi di BIND dovete sapere che se 
un utente normale (quindi non superutente) fa partire BIND, 
questo ultimo non potrà riconoscere le nuove interfacce 
automaticamente, ad esempio se inserite una scheda PCMCIA nel vostro 
portatile. Controllate il file README.Debian nella vostra 
documentazione di named 
(<file>/usr/share/doc/bind/README.Debian</file>) per ulteriori 
informazioni su questo problema. Ci sono stati recentemente
diversi problemi di sicurezza riguardo BIND per cui cambiare utente
diviene comodo quando è possibile farlo. Spiegheremo dettagliatamente
i passi da compiere per realizzare questo procedimento, tuttavia, se 
volete farlo in modo automatizzato potreste provare lo script 
inserito in <ref id="bind-chuser">.

<p>Notate che, in ogni caso, ciò si applica solo alla versione 8
di BIND. Nei pacchetti Debian della versione 9 di BIND
(dalla versione 9.2.1-5, disponibile a partire da <em>sarge</em>)
l'utente <em>bind</em> viene creato ed usato impostando la
variabile OPTIONS in <file>/etc/default/bind9</file>. Se state
usando la versione 9 di BIND ed il vostro domain name server
non sta girando come utente <em>bind</em>, verificate le
impostazioni contenute in quel file.

<p>Per fare girare BIND sotto un altro utente, la prima cosa da fare è
creare un utente separato ed un gruppo apposito (<em>non è</em> una
buona idea usare nobody e nogroup per tutti i servizi che non girano
come root). In questo esempio verranno utilizzati l'utente ed il
gruppo <tt>named</tt>. Potete crearli digitando:

<example>
addgroup named
adduser --system --home /home/named --no-create-home --ingroup named \
      --disabled-password --disabled-login named
</example>

<p>Notate che l'utente <tt>named</tt> sarà parecchio limitato. 
Se volete, per una qualsiasi ragione, avere un utente con 
meno limitazioni, utilizzate:

<example>
adduser --system --ingroup named named
</example>

<p>Adesso modificate il file <tt>/etc/init.d/bind</tt>, con il 
vostro editor preferito, la riga che inizia con:

<example>
start-stop-daemon --start
</example>

in<footnote>
Notate che, a seconda della vostra versione di bind, potreste non
avere l'opzione <tt>-g</tt>, in particolare se state usando bind 9
presente in sarge (versione 9.2.4).
</footnote>:

<example>
start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named
</example>

<p>Altrimenti potete cambiare (creare se già non esiste) il file di
configurazione predefinito (<file>/etc/default/bind</file> per la 
versione 8 di BIND) ed inserire le seguenti voci:

<example>
OPTIONS="-u named -g named"
</example>

<p>Cambiate i permessi dei file usati da bind, incluso
<file>/etc/bind/rndc.key</file>:

<example>
-rw-r-----    1 root     named          77 Jan  4 01:02 rndc.key
</example>

ed anche dove bind crea il suo pidfile, usando, ad esempio,
<file>/var/run/named</file> invece di <file>/var/run</file>:

<example>
$ mkdir /var/run/named
$ chown named.named /var/run/named
$ vi /etc/named.conf
[ ... aggiornare il file di configurazione per usare questo nuovo percorso ...]
options { ...
        pid-file "/var/run/named/named.pid";
};
[ ... ]
</example>


<p>Inoltre, per evitare di far girare qualcosa come superutente,
modificate la riga di <tt>reload</tt> nello script init.d da così:

<example>
reload)
       /usr/sbin/ndc reload
</example>

<p>a così:

<example>
reload)
        $0 stop
        sleep 1
        $0 start
</example>

<p>Notate: a seconda della versione di Debian che state usando potreste dover
cambiare anche la riga <tt>restart</tt>. 
Questo problema, in Debian, è stato sistemato nella versione 
<tt>1:8.3.1-2</tt> di bind.

<p>Tutto quello che dovete fare adesso è far ripartire bind con il 
comando <tt>/etc/init.d/bind restart</tt> e controllare il vostro 
syslog nelle due voci:

<example>
Sep  4 15:11:08 nexus named[13439]: group = named
Sep  4 15:11:08 nexus named[13439]: user = named
</example>

<p>Voilá! Il vostro named adesso <em>non</em> gira come superutente. 
Se volete leggere altre informazioni sul perché BIND non gira in 
maniera predefinita come utente non root sui sistemi Debian, 
controllate il Bug Tracking System riguardo Bind, specificatamente il 
<url id="http://bugs.debian.org/50013" name="Bug #50013: bind non dovrebbe girare come root"> e il 
<url id="http://bugs.debian.org/132582" name="Bug #132582: l'installazione predefinita è potenzialmente insicura">,
<url id="http://bugs.debian.org/53550" name="Bug #53550">, 
<url id="http://bugs.debian.org/52745" name="Bug #52745"> ed il
<url name="Bug #128129" id="http://bugs.debian.org/128129">. 
Sentitevi liberi di riportare informazioni sui bug che riscontrate, se 
pensate di poter aggiungere informazioni utili.


<sect1 id="chroot-bind">Eseguire il name server in chroot

<p>Per ottenere la massima sicurezza, dovrete costruire una gabbia chroot
(vedete in <ref id="chroot">) attorno al vostro demone. Esiste un 
modo semplice per ottenere ciò: l'opzione <tt>-t</tt> (vedete la 
pagina man <manref name="named" section="8"> o la pagina 100 della
<url id="http://www.nominum.com/content/documents/bind9arm.pdf"
name="Documentazione di Bind 9 (PDF)">).
Questo farà sì che Bind sia in chroot nella directory data, senza
che ci sia bisogno di impostare una gabbia chroot e senza che vi dobbiate
preoccupare delle librerie dinamiche. Gli unici file che devono
essere presenti nella gabbia chroot sono:

<example>
dev/null
etc/bind/       - deve contenere named.conf e tutte le zone dei server
sbin/named-xfer - se si fa il trasferimento dei nomi 
var/run/named/  - deve mantenere il pid e la cache del name server (se
                  presente) e questa directory deve essere accessibile
                  in scrittura dall'utente named
var/log/named   - se è impostato il logging su file, deve essere
                  accessibile in scrittura dall'utente named
dev/log         - syslogd dovrebbe essere in ascolto qui se named è
                  stato configurato per eseguire il log tramite esso
</example>

<p>Per far sì che il demone Bind funzioni correttamente, necessita dei
permessi giusti sui file named. Questo è un compito semplice, dal 
momento che i file di configurazione sono sempre in 
<tt>/etc/named/</tt>. Tenete presente che necessita solo dell'accesso 
in lettura ai file di zona, a meno che non si tratti di un name 
server secondario o di cache. Se questo è il caso, dovrete concedere 
i permessi di lettura-scrittura alle zone necessarie (in modo che 
i trasferimenti di zona dal server primario funzionino).

<p>Inoltre, potete trovare maggiori informazioni riguardo al 
chrooting di Bind nel 
<url id="http://www.tldp.org/HOWTO/Chroot-BIND-HOWTO.html" 
name="Chroot-BIND-HOWTO"> (concernente Bind 9) e nel <url 
id="http://www.tldp.org/HOWTO/Chroot-BIND8-HOWTO.html" 
name="Chroot-BIND8-HOWTO"> (per Bind 8). 
Questi stessi documenti dovrebbero essere disponibili
attraverso l'installazione di <package>doc-linux-text</package> 
(versione testuale) oppure <package>doc-linux-html</package> 
(versione HTML). Un altro documento utile è 
<url id="http://web.archive.org/web/20011024064030/http://www.psionic.com/papers/dns/dns-linux">.

<p>Nel caso in cui stiate creando una gabbia chroot per
l'esecuzione di Bind in Debian (senza usare l'opzione <tt>-t</tt>),
assicuratevi di aver incluso i seguenti file<footnote>
          Questa configurazione non è ancora stata collaudata
          per il nuovo rilascio di Bind.
</footnote>:

<example>
dev/log - syslogd dovrebbe essere in ascolto qui
dev/null
etc/bind/named.conf
etc/localtime
etc/group - con una singola riga: "named:x:GID:"
etc/ld.so.cache - generata con ldconfig
lib/ld-2.3.6.so
lib/libc-2.3.6.so
lib/ld-linux.so.2 - link simbolico a ld-2.3.6.so
lib/libc.so.6 - link simbolico a libc-2.3.6.so
sbin/ldconfig - può essere cancellato dopo la configurazione del chroot
sbin/named-xfer - se si esegue il trasferimento di nomi
var/run/
</example>

<p>Modificate inoltre <prgn>syslogd</prgn>, in ascolto su
<tt>$CHROOT/dev/log</tt> in modo che il name server possa
scrivere gli eventi nel syslog del sistema locale di log.

<p>Se volete eliminare i problemi con le librerie dinamiche, 
potete compilare bind staticamente. Potete usare <prgn>apt-get</prgn> 
a questo scopo, con l'opzione <tt>source</tt>. Potete anche scaricare il
pacchetto che si compilerà in modo opportuno. Dovrete eseguire
qualcosa di simile a questo:

<example>
$ apt-get source bind
# apt-get build-dep bind
$ cd bind-8.2.5-2
  (modificate src/port/linux/Makefile perché CFLAGS 
   includa l'opzione '-static')
$ dpkg-buildpackage -rfakeroot -uc -us
$ cd ..
# dpkg -i bind-8.2.5-2*deb
</example>

<p>Dopo l'installazione, dovrete spostare i file all'interno della 
gabbia chroot<footnote>
<p>A meno che non utiliziate l'opzione <tt>instdir</tt> quando chiamate
<prgn>dpkg</prgn>, ma in questo caso la gabbia chroot potrebbe
essere leggermente più complessa.
</footnote>.

Potete mantenere gli script <tt>init.d</tt> in
<file>/etc/init.d</file>, così il sistema avvierà
automaticamente il name server. Però dovrete modificarlo per
aggiungere <tt>--chroot /percorso_del_chroot</tt> nella chiamata
a <prgn>start-stop-daemon</prgn> presente in quegli script,
oppure potete usare l'opzione <em>-t</em> di BIND impostando
l'argomento OPTIONS nel file di configurazione
<file>/etc/default/bind</file> (per la  versione 8) o in
<file>/etc/default/bind9</file> (per la versione 9).

<p>Per maggiori informazioni su come configurare gabbie chroot vedete 
<ref id="chroot">.

<p>FIXME, integrare con informazioni da:
<url id="http://people.debian.org/~pzn/howto/chroot-bind.sh.txt">,
<url id="http://www.cryptio.net/~ferlatte/config/"> (specifico per Debian),
<url id="http://web.archive.org/web/20021216104548/http://www.psionic.com/papers/whitep01.html"> e
<url id="http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm">.




<sect>Proteggere Apache

<p>FIXME:Aggiungere contenuto: moduli forniti con la normale installazione di
Apache (in /usr/lib/apache/X.X/mod_*) e moduli che possono essere installati
separatamente dai pacchetti libapache-mod-XXX.

<p>Potete limitare l'accesso al server Apache se volete utilizzarlo solo
internamente, impedendo che vi accedano estranei (per eseguire dei
test, per accedere all'archivio <package>doc-central</package>, ecc.). 
A tale proposito, usate in <file>/etc/apache/http.conf</file> le direttive 
<tt>Listen</tt> o <tt>BindAddress</tt>.

<p>Se usate Listen:

<example>
Listen 127.0.0.1:80
</example>

<p>Se usate BindAddress:

<example>
BindAddress 127.0.0.1
</example>

<p>Quindi, riavviate Apache con <tt>/etc/init.d/apache restart</tt> e 
vedrete che ascolterà solamente sull'interfaccia di loopback.

<p>In ogni caso, se non utilizzate tutte le funzionalità di Apache, 
potreste considerare altri web server forniti da Debian, come 
<package>dhttpd</package>.

<p>La <url id="http://httpd.apache.org/docs/misc/security_tips.html" 
name="Documentazione di Apache"> informa sulle misure di sicurezza che
dovreste adottare per un server di rete Apache (Debian dà questa
stessa informazione con il pacchetto <package>apache-doc</package>). 
	
<p>Maggiori informazioni su come limitare ulteriormente l'accesso ad Apache,
impostando una gabbia di tipo chroot, le trovate in 
<ref id="chroot-apache-env">.


<sect1>Impedire agli utenti la divulgazione di contenuti di rete

<p>L'installazione predefinita di Apache consente agli utenti di pubblicare
contenuti in <file>$HOME/public_html</file>. 
Tali contenuti possono essere raggiunti in
remoto impiegando un'URL come: http://your_apache_server/~user.

<p>Se volete impedirlo, occorre modificare il file di configurazione
<file>/etc/apache/http.conf</file> commentando (in Apache 1.3)  
la riga:

<example>
LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so
</example>

<p>Nel caso usiate Apache 2.0 dovrete cancellare il file
<file>/etc/apache2/mods-enabled/userdir.load</file> o
rendere più restrittiva la configurazione predefinita di Apache
modificando il file
<file>/etc/apache2/mods-enabled/userdir.conf</file>.

<p>Però, se il modulo fosse stato compilato staticamente (cosa che si
può verificare lanciando <tt>apache -l</tt>), dovreste aggiungere la
seguente riga al file di configurazione di Apache:

<example>
Userdir disabled
</example>

<p>Un attaccante, però, può ancora eseguire il conteggio degli utenti, dal
momento che la risposta del server di rete sarà un
<em>403 Permission Denied</em> e non un <em>404 Not available</em>.
Tuttavia questo comportamento può essere evitato utilizzando
il modulo Rewrite.


<sect1>Permessi sui file di log

<p>I file di log di Apache, dalla versione 1.3.22-1, sono proprietà
dell'utente 'root' e del gruppo 'adm', con permessi 640. Questi
permessi vengono cambiati a rotazione. Senza un
ampliamento dei privilegi, un intruso che abbia avuto accesso al sistema
attraverso il server di rete non potrebbe eliminare voci vecchie dei file di
log.

<!-- FIXME: what do you mean with "this permissions are changed after -->
<!-- rotation -->


<sect1>Pubblicare file web

<p>I file di Apache si trovano in <file>/var/www</file>.
Subito dopo l'installazione, il file predefinito fornisce alcune
informazioni sul sistema (principalmente sul fatto che si tratta di
un sistema Debian su cui è attivo Apache). Le pagine web predefinite
vengono impostate per definizione come proprietà dell'utente root e
del gruppo root, mentre il processo Apache viene eseguito come utente
www-data e gruppo www-data.
Questo dovrebbe rendere più  difficile agli attaccanti, che hanno
compromesso il sistema mediante Apache, di defacciare il sito
web. &Egrave; importante sostituire le pagine predefinite mostrate
da Apache con pagine bianche o comunque personalizzate perché
potrebbero fornire informazioni utili agli attaccanti.


<sect>Rendere sicuro finger

<p>Se avete intenzione di fornire il servizio finger, chiedetevi 
prima se serva veramente. In caso affermativo, vi renderete conto 
che Debian fornisce molti demoni finger (questo è l'output di
<prgn>apt-cache search fingerd</prgn>):

<list>

<item>cfingerd - Un demone finger configurabile.
<item>efingerd - Un altro demone finger per unix, consente di 
                 configurare accuratamente il vostro l'output.
<item>ffingerd - Un demone finger sicuro.
<item>fingerd - Server remoto di informazioni sugli utenti.
<item>xfingerd - Demone finger in stile BSD con supporto per qmail.
</list>


<p><package>ffingerd</package> è il servizio finger raccomandato se 
avete intenzione di usarlo come servizio pubblico. In ogni caso 
siete invitati, quando lo configurate tramite inetd, xinetd 
o tcpserver, a: limitare il numero di processi che verranno eseguiti 
contemporaneamente, limitare gli accessi a finger da specifici 
host (usando i tcp wrapper) e configurarlo in modo da 
farlo ascoltare solo sulle interfacce desiderate.

<!--
# This is quite personal, IMHO, since this is due to the fact that 
# root privileges are dropped on startup. I prefer an attacker to erase
# a service's log files than to erase all of my system's logs. Anyhow, this
# can be improved by changing user permissions after rotation.
-->


<sect id="chroot">Paranoie generiche riguardo chroot e suid

<p>
<prgn>chroot</prgn> è una delle più potenti alternative per stabilire 
restrizioni per un demone, un utente o un altro servizio. Immaginate 
una gabbia attorno ad un bersaglio, da cui esso non può uscire (normalmente, 
anche se ci sono comunque molte condizioni che permettono di uscirne). 
Se non vi fidate di un servizio o di un utente, potete creargli un 
ambiente root diverso. Questo ambiente può occupare una buona parte 
di spazio su disco poiché vi dovrete copiare tutti gli eseguibili e le
librerie necessarie. Anche se l'utente fa qualcosa di malizioso, la 
portata del danno è limitata a questa gabbia.

<!-- Consider removing this:
<p>A good example for this case is, if you do not authenticate against
<file>/etc/passwd</file> but use LDAP or MySQL instead. So your
ftp-daemon only needs a binary and perhaps a few libraries. A 
<prgn>chroot</prgn>ed environment would be an excellent security improvement; 
if a new exploit is found for this ftp-daemon, then attackers can only exploit
the UID of the ftp-daemon-user and nothing else. 
-->

<p>
Molti servizi eseguiti come demoni possono beneficiare di questo
genere di soluzione. Tuttavia i demoni installati dalla distribuzione
Debian non sfrutteranno l'ambiente chroot<footnote> 
          Cercate di eseguirli con i <em>minimi privilegi</em>, cioè 
          avviando i demoni con il loro relativo utente, invece di 
          eseguirli come root.
</footnote> 
in modo predefinito.

<p>
Questi includono: server name (come <prgn>bind</prgn>), server web 
(come <prgn>apache</prgn>), server di posta (come <prgn>sendmail</prgn>) 
e server ftp (come <prgn>wu-ftpd</prgn>).
Probabilmente è giusto dire che la complessità di BIND è il motivo per cui
è stato esposto a molti attacchi in questi anni (vedete in
<ref id="sec-bind">).

<p>
Comunque, Debian fornisce del software che può aiutarvi a configurare
ambienti <prgn>chroot</prgn> automaticamente. 
Vedete <ref id="auto-chroot">.

<p>
Ad ogni modo se eseguite un qualsiasi servizio su un sistema, 
dovreste farlo nel modo più sicuro possibile. Questo comporta: 
revocare i privilegi di root, eseguirli in un ambiente sottoposto 
a restrizioni (come una gabbia creata con chroot) o sostituirli 
con servizi equivalenti più sicuri.

<p>Tuttavia tenete conto fin d'ora che un ambiente creato con 
<prgn>chroot</prgn> può non essere sicuro se l'utente al suo interno 
è il superutente, per questo è necessario eseguire il servizio come 
utente non privilegiato. Limitando il suo ambiente limitate i file 
leggibili/eseguibili globalmente a cui il servizio può accedere e con 
questo le possibilità di una scalata ai privilegi sfruttando 
vulnerabilità relative alla sicurezza del sistema locale.
Anche in questa situazione non si può essere completamente sicuri che 
non ci siano modi per una persona capace di uscire da questa gabbia in 
qualche modo. Usare solo programmi server che hanno la reputazione di 
essere sicuri è una buona misura precauzionale aggiuntiva. Anche buchi 
minuscoli come file di gestione aperti, possono esser usati da una 
persona capace per intromettersi nel sistema. Dopotutto 
<prgn>chroot</prgn> non è stato progettato come strumento per la 
sicurezza, ma come strumento di test.


<sect1 id="auto-chroot">Creare ambienti chroot automaticamente

<p>Ci sono diversi programmi per ingabbiare automaticamente server e 
servizi in ambienti chroot. Al momento (accettato nel maggio 2002) 
Debian fornisce <prgn>chrootuid</prgn> di Wietse Venema nel 
pacchetto <prgn>chrootuid</prgn>, così come 
<package>compartment</package> e <package>makejail</package>. 
Potete usare questi programmi per configurare un ambiente con 
restrizioni ed eseguire qualunque programma (<prgn>chrootuid</prgn> 
permette addirittura di eseguirlo come un utente con restrizioni).

<p>Alcuni di questi strumenti possono essere usati per configurare ambienti
chroot in modo semplice. Il programma <prgn>makejail</prgn>, per esempio,
può creare ed aggiornare una gabbia chroot con brevi file di 
configurazione (ne fornisce alcuni di esempio adatti per 
<prgn>bind</prgn>, <prgn>apache</prgn>, <prgn>postgresql</prgn> e 
<prgn>mysql</prgn>). Cerca di indovinare ed installare dentro la 
gabbia, tutti i file richiesti dal servizio, usando <prgn>strace</prgn>, 
<prgn>stat</prgn> e le dipendenze dei pacchetti Debian.
Ulteriori informazioni sono reperibili presso 
<url id="http://www.floc.net/makejail/">. 
<prgn>Jailer</prgn> è un programma simile che può essere scaricato 
da <url id="http://www.balabit.hu/downloads/jailer/"> ed è anche 
disponibile direttamente come pacchetto Debian. 




<sect>In generale, paranoia per le password in chiaro

<p>Siete invitati a non mantenere nessun servizio di rete che spedisca e riceva
le password in chiaro usando FTP/Telnet/NIS/RPC. &Egrave; raccomandato
l'uso di ssh invece di telnet o di ftp.

<p>Tenete a mente che una migrazione da telnet a ssh, che utilizzi
comunque altri protocolli in chiaro NON aumenta la vostra sicurezza
in alcun modo!
La miglior cosa sarebbe quella di eliminare servizi quali ftp, telnet,
pop, imap, http e sostituirli con i rispettivi servizi cifrati.
Prendete in considerazione di migrare a servizi che hanno una versione SSL
quali, ad esempio: ftp-ssl, telnet-ssl, pop-ssl, https ...

<p>La maggior parte degli esempi riportati possono essere applicati a
tutti i sistemi Unix (siete invitati a cercare altri documenti 
relativi a Linux e ad altri Unix).


<sect>Disabilitare NIS

<p>Se vi è possibile, non usate NIS, il servizio di informazioni di 
rete, perché permette la condivisione delle password. Questo
rende il sistema molto insicuro, se non è configurato in modo ottimale.

<p>Se avete bisogno di condividere la password su più macchine, siete 
invitati a considerare altre alternative.
Per esempio, potete configurare un 
server LDAP e configurare PAM nel vostro sistema in modo da fargli 
contattare il server LDAP per l'autenticazione dell'utente. 
Potete trovare una configurazione dettagliata 
nell'<url id="http://www.tldp.org/HOWTO/LDAP-HOWTO.html" 
name="LDAP-HOWTO">
(<file>/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz</file>).

<p>Altre informazioni su NIS potete trovarle nel 
<url id="http://www.tldp.org/HOWTO/NIS-HOWTO.html" name="NIS-HOWTO">
(<file>/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz</file>).

<p>FIXME (jfs): Aggiungere informazioni su come configurarlo in Debian 




<sect id="rpc">Rendere sicuri i servizi RPC

<p>Disabilitate RPC se non ne fate uso.

<p>RPC (Remote Procedure Call) è un protocollo che i programmi
possono utilizzare per richiedere servizi da altri programmi
che si trovano su computer diversi da quello locale.
Il servizio <prgn>portmap</prgn> controlla i servizi RPC mediante
la combinazione della numerazione assegnata ai programmi RPC con
i numeri delle porte assegnate dal protocollo DARPA.
RPC deve essere in esecuzione per eseguire chiamate RPC.

<p>I servizi basati su RPC hanno avuto un pessimo record circa
i buchi di sicurezza, anche se non portmapper stesso (nonostante
fornisca informazioni ad un attaccante remoto).
Notate che alcuni degli attacchi DDoS (Distributed Denial of 
service) utilizzano exploit RPC per accedere al sistema ed agire 
come un cosiddetto agente/gestore.

<p>RPC vi occorre solamente se state utilizzando un servizio basato
su RPC. I servizi più comuni basati su RPC sono NFS (Network 
File System) e NIS (Network Information System). Vedete la
sezione precedente per maggiori informazioni riguardo NIS. Anche 
il FAM (File Alteration Monitor) fornito dal pacchetto 
<package>fam</package> è un servizio RPC, che dipende da 
<package>portmap</package>.

<p>I servizi NFS sono abbastanza importanti in alcune reti. Se
è il vostro caso, allora occorre trovare un bilanciamento tra 
la sicurezza e l'usabilità della vostra rete (potete leggere di
più riguardo la sicurezza di NFS nel <url name="NFS-HOWTO"
id="http://www.tldp.org/HOWTO/NFS-HOWTO.html">
(<file>/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz</file>)).


<sect1>Disabilitare completamente i servizi RPC

<p>Disabilitare portmap è abbastanza semplice, ci sono diversi
metodi. Il più semplice in un sistema Debian 3.0 e successivi
rilasci è quello di disinstallare il pacchetto 
<package>portmap</package>. Se
state eseguendo una versione più vecchia di Debian dovrete 
disabilitare il servizio come avete visto in
<ref id="disableserv">, perché il programma è parte del pacchetto
<package>netbase</package> (che non può essere disinstallato
senza danneggiare il sistema).

<p>Notate che alcuni ambienti desktop, in particolare GNOME, 
utilizzano i servizi RPC ed hanno bisogno di portmap per alcune
delle loro funzionalità di gestione file. Se è il vostro caso, 
potete limitare l'accesso ai servizi RPC come descritto sotto.



<sect1>Limitare l'accesso ai servizi RPC

<p>Sfortunatamente, in alcuni casi rimuovere i servizi RPC dal 
sistema non rappresenta una soluzione. Alcuni servizi locali in 
ambito desktop (come <package>fam</package> di SGI) sono basati 
su RPC e necessitano di un portmapper locale. Questo significa 
che in alcune situazioni, utenti che installano un ambiente 
desktop (ad esempio GNOME) installerano anche portmapper.

<p>Ci sono diversi modi per limitare l'accesso a portmapper ed
ai servizi RPC:

<list>
<item>Bloccare l'accesso alle porte utilizzate da questi servizi 
con un firewall locale (consultate <ref id="firewall-setup">).
<item>Bloccare l'accesso a questi servizi utilizzando dei wrapper
TCP, da quando portmapper (ed alcuni servizi RPC) vengono 
compilati con <file>libwrap</file> (consultate 
<ref id="tcpwrappers">). Questo significa che è possibile bloccare 
l'accesso ai servizi tramite la configurazione dei wrapper tcp 
<file>hosts.allow</file> e <file>hosts.deny</file>.
<item>Dalla versione 5-5, il pacchetto <package>portmap</package>
può essere configurato per rimanere in ascolto solamente 
sull'interfaccia di loopback. Per fare questo, occorre modificare 
<file>/etc/default/portmap</file>, decommentando la riga seguente: 
<tt>#OPTIONS="-i 127.0.0.1"</tt> e fare un restart del portmapper. 
&Egrave; sufficiente questo per permettere ai servizi locali RPC 
di essere in esecuzione ed allo stesso tempo impedire l'accesso 
remoto al sistema (consultate, comunque, <ref id="limit-bindaddr">).
</list>


<sect id="firewall-setup">Aggiungere funzionalità al firewall


<p>Il Sistema Operativo Debian GNU/Linux ha le funzionalità di
firewalling integrate fornite dal kernel Linux. Se installate
una versione recente di Debian (in cui il kernel predefinito è il
2.6) sarà disponibile il tool di firewalling <prgn>iptables</prgn> 
(netfilter)<footnote>
          Disponibile fin dalla versione 2.4 del kernel (che era 
          il kernel predefinito in Debian 3.0). Le versioni 
          precedenti del kernel (2.2, disponibile nelle versioni di 
          Debian più vecchie) utilizzavano <prgn>ipchains</prgn>. La
          differenza maggiore fra <prgn>ipchains</prgn> ed
          <prgn>iptables</prgn> è che questo ultimo è basato sulla
          <em>stateful packet inspection</em> che permette una
          configurazione dei filtri  più sicura e più facile da
          realizzare. Le versioni più vecchie di Debian (ora non 
          più supportate) usavano i kernel della serie 2.0 che 
          necessitavano di apposite patch.
</footnote>.


<sect1>Proteggere il sistema locale con un firewall

<p>Potete usare le regole di un firewall per rendere più sicuro 
l'accesso al sistema ed anche per limitare le comunicazioni 
in uscita. Le regole del firewall possono anche essere 
utilizzate per proteggere i processi che non possono essere 
adeguatamente configurati per <em>non</em> fornire servizi 
ad alcune reti, indirizzi IP, etc..

<p>Comunque, questo passaggio viene presentato per ultimo in questo 
manuale essenzialmente perché è <em>molto</em> meglio non 
dipendere unicamente dalle capacità di un firewall per 
proteggere un determinato sistema. La sicurezza in un sistema
è data da livelli, in cui il firewall è l'ultimo 
da includere, una volta che tutti i processi sono stati adeguatamente
irrobustiti. Potete facilmente immaginare un'installazione 
in cui un sistema è protetto solo dal firewall magari
incorporato e un amministratore che incautamente rimuove 
le regole del firewall per qualche motivo (problemi 
con l'installazione, fastidio, errore umano...), questo 
sistema sarebbe parecchio esposto ad un attacco se non ci 
fosse nessun'altra protezione a garantirlo.

<p>D'altra parte, impostare le regole di un firewall sul sistema 
può anche prevenire il verificarsi di alcuni fatti spiacevoli. 
Anche se i servizi forniti vengono configurati in modo sicuro, 
un firewall può proteggere da errate configurazioni o da 
servizi appena installati che non sono ancora stati configurati. 
Inoltre, una configurazione sicura previene il funzionamento
di trojans <em>che chiamano casa</em>, finché il codice del 
firewall non viene rimosso. Notate che un intruso <em>non</em> 
necessita di un accesso superutente per installare un 
trojan locale che possa essere controllato da remoto 
(dato che il binding sulle porte è consentito se non si 
tratta di porte privilegiate e se queste funzionalità non sono 
state rimosse).

<p>Quindi, il firewall, se impostato correttamente, dovrebbe 
avere una politica di negazione predefinita, secondo cui:

<list>

<item>
Le connessioni in ingresso vengono consentite solo ai servizi 
locali da macchine autorizzate.
<item>
Le connessioni in uscita vengono consentite solo a servizi 
utilizzati dal vostro sistema (DNS, navigazione, pop, 
email...)<footnote>
A dispetto di firewall personali in altri sistemi operativi, 
Debian GNU/Linux non fornisce (ancora) una generazione di 
interfacce per il firewall che permettano di creare regole 
limitatamente a processi o utenti. Comunque, il codice
di iptables può essere configurato per farlo 
(consultate il modulo relativo alla 
pagina di manuale <manref name="iptables" section="8">).
</footnote>.

<item>
La regola di inoltro nega qualsiasi cosa (a meno che non stiate 
proteggendo altri sistemi, vedete più in basso).
<item>
Tutte le altre connessioni in ingresso o in uscita vengono negate.
</list>


<sect1>Utilizzare un firewall per proteggere altri sistemi

<p>Un firewall Debian può anche essere installato per 
proteggere, con regole di filtraggio, accessi a sistemi posti
<em>dietro</em> ad esso, limitando la loro esposizione su
Internet. Il firewall può essere configurato per proteggere 
i sistemi dall'esterno verso la rete locale per l'accesso a 
determinati servizi (porte) che non sono pubblici. Per esempio, su 
un server di posta, solo la porta 25 (che fornisce il servizio di 
posta) ha bisogno di essere accessibile dall'esterno. 
Un firewall può essere configurato, anche se ci sono altri 
servizi di rete oltre a quelli pubblici, per respingere pacchetti 
(questo è conosciuto come <em>filtraggio</em>) diretti verso di sé.

<p>Potete anche configurare un sistema Debian GNU/Linux come bridge firewall, ad
esempio un firewall filtrante privo di indirizzo IP, completamente trasparente
alla rete e che quindi non può essere attaccato direttamente.
A seconda del kernel che avete installato potreste aver bisogno di installare 
la patch per il bridge firewall; andate quindi su 
<em>802.1d Ethernet Bridging</em> durante la configurazione del kernel e 
abilitate la nuova opzione <em>netfilter (firewalling) support</em>.
Leggete <ref id="bridge-fw"> per ulteriori informazioni 
su come meglio sfruttare questa funzionalità sul vostro sistema 
Debian GNU/Linux.



<sect1>Configurare il firewall

<p>L'installazione Debian predefinita, contrariamente ad altre
distribuzioni Linux, non fornisce ancora all'amministratore un 
modo per impostare una configurazione per il firewall durante
l'installazione, ma è possibile installare alcuni pacchetti per
configurare il firewall (vedete <ref id="firewall-pack">).

<p>Naturalmente, la configurazione del firewall dipende sempre dal 
sistema e dalla rete. Un amministratore deve conoscere 
anticipatamente qual'è la struttura di rete e i sistemi che vuole 
proteggere, i servizi che hanno bisogno di fornire accesso e se 
tenere presente o meno altre considerazioni di rete (come NAT o
routing). Prestate attenzione durante la configurazione del 
firewall, come dice Laurenc J. Lane nel pacchetto 
<package>iptables</package>:

<p><em>&Egrave; facile fare un cattivo uso degli strumenti, causando gravi 
danni e bloccando completamente l'accesso di rete ad un sistema. 
Non è così raro per un amministratore di un sistema remoto restarne
bloccato fuori a centinaia o migliaia di chilometri di distanza. 
Può anche succedere di bloccare l'accesso al computer che si ha sotto 
le dita. Quindi, usate la dovuta cautela.</em>

<p>Ricordate: la semplice installazione di <package>iptables</package> 
(o di altri programmi per gestire firewall) non dà nessuna protezione, 
fornisce solamente il software. 
Per poter avere un firewall è necessario <em>configurarlo</em>!

<p>Se non avete idea di come impostare delle regole per un firewall, 
è opportuno che consultiate il <em>Packet Filtering HOWTO</em> ed il 
<em>NAT HOWTO</em>, forniti da <package>iptables</package> per la
lettura non in linea in <file>/usr/share/doc/iptables/html/</file>.

<p>Se non sapete molto riguardo all'argomento firewall sarebbe meglio
iniziare leggendo il 
<url id="http://www.tldp.org/HOWTO/Firewall-HOWTO.html" 
name="Firewalling and Proxy Server HOWTO">, installate il pacchetto
<package>doc-linux-text</package> se volete leggerlo quando 
non siete collegati. In caso di domande o se vi servisse aiuto
nell'impostazione di un firewall potete chiedere alla mailing 
list debian-firewall, vedete 
<url id="http://lists.debian.org/debian-firewall">.
Vedete anche in <ref id="references">, per ulteriori puntatori
(generici) sui firewall. Un altro buon tutorial per iptables è
<url 
id="http://iptables-tutorial.frozentux.net/iptables-tutorial.html">.






<sect2 id="firewall-pack">Uso dei pacchetti firewall

<p>L'impostazione manuale di un firewall può essere complicata per
gli amministratori novizi (e talvolta anche per quelli esperti).
Comunque, la comunità del free software ha creato un buon numero di
strumenti che possono essere usati per configurare facilmente un 
firewall locale. Sappiate però che alcuni di questi strumenti sono
più orientati verso una protezione esclusivamente locale (anche
conosciuta come <em>personal firewall</em>) mentre alcuni
sono molto più versatili e possono essere usati per configurare 
regole complesse per proteggere intere reti.

<p>Alcuni software che possono essere usati per impostare regole 
di firewall in sistemi Debian sono:

<list>
<item>Per sistemi desktop:

<list>
<item><package>firestarter</package>, un'applicazione GNOME 
orientata all'utente finale che include un'utile wizard per 
impostare velocemente le regole del firewall. L'applicazione 
comprende un'interfaccia grafica capace di controllare quando 
una regola del firewall blocca il traffico.
<item><package>guarddog</package>, un pacchetto di 
configurazione basato su KDE e rivolto sia ad utenti principianti
che avanzati.
<item><package>knetfilter</package>, un'interfaccia grafica per KDE
in grado di gestire le regole firewall e NAT di iptables (è
un'alternativa, o concorrente che dir si voglia, del programma
guarddog, anche se tende a soddisfare maggiormente le necessità di
un utente esperto).
<item><package>fireflier</package>, un programma interattivo in grado 
di creare regole per iptables in base al traffico rilevato sul 
sistema e alle applicazioni presenti sul sistema stesso.  &Egrave; 
composto da un server e da un client, che vanno installati entrambi; 
oltre al server (<package>fireflier-server</package>) bisogna quindi 
anche scegliere uno dei vari client disponibili, ve ne sono per vari 
ambienti grafici:
<package>fireflier-client-gtk</package> (basato sulle Gtk+ ),
<package>fireflier-client-kde</package> (per ambiente KDE) e
<package>fireflier-client-qt</package> (basato sulle QT ).
</list>

<item>Per sistemi ad uso server (senza schermo):

<list>
<item><package>fwbuilder</package>, è un interfaccia grafica,
scritta usando la programmazione orientata agli oggetti, che
include dei generatori di regole per vari firewall, tra cui
netfilter per Linux, pf (usato da  OpenBSD, NetBSD, FreeBSD e
MacOS X) ed un generatore di liste di accesso per i router. 
Le sue funzionalità sono paragonabili ai software per la
gestione dei firewall comunemente usati dalle aziende.
Include anche un'interfaccia a riga di comando che permette di
sfruttare tutte le funzionalità del programma.

<item><package>shorewall</package>, un tool di configurazione per 
i firewall che fornisce supporto per IPsec così come un supporto 
limitato per il traffic shaping nonché per le definizioni delle 
regole di un firewall. La configurazione viene effettuata mediante 
un semplice insieme di file che vengono usati per generare le 
regole di iptables.
<item><package>bastille</package>, questa applicazione di 
irrobustimento viene descritta in <ref id="automatic-harden">. Uno 
dei passi di irrobustimento configurabile dall'amministratore è la 
definizione del traffico di rete ammesso e vietato, che viene usato 
per generare un insieme di regole del firewall che il sistema 
eseguirà all'avvio.
</list>

</list>

<p>In Debian vengono forniti diversi frontend a iptables; un elenco
esaustivo che raffronta i differenti pacchetti software presenti
viene mantenuta nella pagina
<url id="http://wiki.debian.org/Firewalls"
name="Firewall"> del wiki di Debian.

<p>Da notare che alcuni dei pacchetti presentati precedentemente,
installeranno degli script di firewalling che verranno eseguiti
all'avvio del sistema. Testate gli script in maniera approfondita
prima di riavviare, altrimenti potreste rimanere chiusi fuori dal
sistema. Di solito, mescolando diversi pacchetti di firewalling, si
possono ottenere effetti indesiderati, tipo che l'ultimo script ad
essere eseguito sarà quello che configura il sistema (comportamento 
che potrebbe non essere quello desiderato). Consultate la 
documentazione del pacchetto e usate solo uno di questi setup.

<p>Come già detto, alcuni programmi, come
<package>firestarter</package>, <package>guarddog</package> e
<package>knetfilter</package> sono interfacce grafiche di
amministrazione che usano GNOME o (le ultime due) KDE.
Queste applicazioni sono rivolte in particolare all'utente
(ossia all'utente comune), a differenza di alcuni degli altri
pacchetti dell'elenco, che invece potrebbero essere pensati più
per gli amministratori. Alcuni dei programmi già menzionati
(come <prgn>bastille</prgn>) sono specializzati nell'impostare
le regole del firewall che protegge l'host su cui girano ma non
necessariamente per impostare regole di firewall per host che
proteggono una rete (come invece fanno <prgn>shorewall</prgn> o
<prgn>fwbuilder</prgn>).

<p>Esiste poi un altro tipo di applicazione per firewall, ossia gli
application proxy. Se cercate di configurare un firewall aziendale 
che faccia packet filtering e fornisca un certo numero di transparent
proxy che analizzino il traffico in modo dettagliato, potete
considerare l'utilizzo di <package>zorp</package>, che fa tutto 
questo in un unico programma. Potete anche impostare manualmente 
questo tipo di host per il firewall usando i proxy disponibili in 
Debian per differenti servizi; per il DNS usando
<package>bind</package> (adeguatamente configurato), 
<package>dnsmasq</package>, <package>pdnsd</package> o
<package>totd</package>, per l'FTP usando 
<package>frox</package> o <package>ftp-proxy</package>, per X11
usando <package>xfwp</package>, per IMAP usando 
<package>imapproxy</package>, per la mail usando 
<package>smtpd</package>, o per il POP3 usando 
<package>p3scan</package>. Per altri protocolli potete usare un 
proxy TCP generico come
<package>simpleproxy</package> o un proxy SOCKS generico come 
<package>dante-server</package>, <package>tsocks</package> o 
<package>socks4-server</package>. Nella maggior parte dei casi,
bisognerà anche usare un sistema di web caching (come 
<package>squid</package>) e di filtraggio web (come 
<package>squidguard</package> o <package>dansguardian</package>).




<sect2>Configurazione manuale di init.d

<p>Un'altra possibilità è quella di configurare manualmente le
regole del firewall attraverso uno script in init.d che lanci
tutti i comandi <prgn>iptables</prgn>.
&Egrave; sufficiente seguire la seguente procedura:

<list>

<item>Revisionare lo script che segue ed adattarlo alle proprie
esigenze.

<item>Collaudare lo script ed esaminare i log di sistema per 
vedere il tipo di traffico che viene eliminato. Se lo state 
collaudando in remoto, vorrete lanciare la snippet shell di 
esempio per rimuovere il firewall (se non digitate nulla per 
20 secondi), oppure potreste voler decommentare le definizioni 
della procedura di <em>default deny</em> (<em>-P INPUT DROP</em> 
e <em>-P OUTPUT DROP</em>) e verificare poi che il sistema 
non elimini alcun traffico legittimo.

<item>Spostare lo script in <file>/etc/init.d/myfirewall</file>.

<item>Configurare il sistema per eseguire lo script prima che 
ogni interfaccia di rete venga configurata:
<example>
#update-rc.d myfirewall start 40 S . stop 89 0 6 .
</example>

</list>

<p>Questo e' un esempio di uno script per un firewall:

<example>
#!/bin/sh
# Esempio di configurazione del firewall.
#
# Avvertenze:
# - Questa configurazione si applica a tutte le interfacce di rete:
#   se voleste restringerla ad una sola interfaccia, usate
#   '-i INTERFACE' nelle regole (chiamate) di iptables
# - L'accesso remoto per i servizi TCP/UDP e` permesso ad ogni macchina;
#   se probabilmente vorrete restringere l'intervallo, usate l'opzione
#   '--source'.
#
# chkconfig: 2345 9 91
# description: Attiva/Disattiva il firewall all'avvio
#
# Si puo` testare questo script prima di renderlo operativo col seguente
# pezzo di script di shell; se non digiterete nulla per 10 secondi, le
# regole del firewall verranno azzerate.
#---------------------------------------------------------------
#  while true; do test=""; read  -t 20 -p "OK? " test ; \
#  [ -z "$test" ] && /etc/init.d/myfirewall clear ; done
#---------------------------------------------------------------

PATH=/bin:/sbin:/usr/bin:/usr/sbin

# Servizi che il sistema offrira` alla rete
TCP_SERVICES="22" # SSH only
UDP_SERVICES=""
# Servizi che il sistema utilizzera` dalla rete
REMOTE_TCP_SERVICES="80" # web browsing
REMOTE_UDP_SERVICES="53" # DNS
# Rete che verra` usata per la manutenzione remota 
# (se lasciate vuote, non verra` caricata nessuna regola)
# NETWORK_MGMT=192.168.0.0/24
# Porta usata per il servizio SSH, definirla se avete configurato 
# una management network ma toglierla da TCP_SERVICES
# SSH_PORT="22"

if ! [ -x /sbin/iptables ]; then  
    exit 0
fi

fw_start () {

  # Traffico in ingresso:
  /sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  # Servizi
  if [ -n "$TCP_SERVICES" ] ; then
  for PORT in $TCP_SERVICES; do
    /sbin/iptables -A INPUT -p tcp --dport ${PORT} -j ACCEPT
  done
  fi
  if [ -n "$UDP_SERVICES" ] ; then
  for PORT in $UDP_SERVICES; do
    /sbin/iptables -A INPUT -p udp --dport ${PORT} -j ACCEPT
  done
  fi
  # Gestione remota
  if [ -n "$NETWORK_MGMT" ] ; then
    /sbin/iptables -A INPUT -p tcp --src ${NETWORK_MGMT} --dport ${SSH_PORT} -j ACCEPT
  else 
    /sbin/iptables -A INPUT -p tcp --dport ${SSH_PORT}  -j ACCEPT
  fi
  # Collaudo remoto
  /sbin/iptables -A INPUT -p icmp -j ACCEPT
  /sbin/iptables -A INPUT -i lo -j ACCEPT
  /sbin/iptables -P INPUT DROP
  /sbin/iptables -A INPUT -j LOG

  # Output:
  /sbin/iptables -A OUTPUT -j ACCEPT -o lo 
  /sbin/iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
  # E` consentito ICMP:
  /sbin/iptables -A OUTPUT -p icmp -j ACCEPT
  # Questo e` per gli aggiornamenti di sicurezza dei pacchetti.
  # Nota: potete scrivere direttamente qui l'indirizzo IP allo 
  # scopo di prevenire il DNS spoofing ed per impostare le regole 
  # persino se il DNS non dovesse funzionare; ma in questo caso 
  # non sareste in grado di "vedere" i cambi di IP per questo
  # servizio:
  /sbin/iptables -A OUTPUT -p tcp -d security.debian.org --dport 80 -j ACCEPT 
  # Questo per i servizi che abbiamo definito:
  if [ -n "$REMOTE_TCP_SERVICES" ] ; then
  for PORT in $REMOTE_TCP_SERVICES; do
    /sbin/iptables -A OUTPUT -p tcp --dport ${PORT} -j ACCEPT
  done
  fi
  if [ -n "$REMOTE_UDP_SERVICES" ] ; then
  for PORT in $REMOTE_UDP_SERVICES; do
    /sbin/iptables -A OUTPUT -p udp --dport ${PORT} -j ACCEPT
  done
  fi
  # Tutte le altre connessioni vengono registrate in  syslog
  /sbin/iptables -A OUTPUT -j LOG
  /sbin/iptables -A OUTPUT -j REJECT 
  /sbin/iptables -P OUTPUT DROP
  # Altre protezioni per la rete 
  # (alcune saranno operative solo con alcune versioni del kernel)
  echo 1 > /proc/sys/net/ipv4/tcp_syncookies
  echo 0 > /proc/sys/net/ipv4/ip_forward 
  echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 
  echo 1 > /proc/sys/net/ipv4/conf/all/log_martians 
  echo 1 > /proc/sys/net/ipv4/ip_always_defrag
  echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
  echo 1 > /proc/sys/net/ipv4/conf/all/rp_filter
  echo 0 > /proc/sys/net/ipv4/conf/all/send_redirects
  echo 0 > /proc/sys/net/ipv4/conf/all/accept_source_route

}

fw_stop () {
  /sbin/iptables -F
  /sbin/iptables -t nat -F
  /sbin/iptables -t mangle -F
  /sbin/iptables -P INPUT DROP
  /sbin/iptables -P FORWARD DROP
  /sbin/iptables -P OUTPUT ACCEPT
}

fw_clear () {
  /sbin/iptables -F
  /sbin/iptables -t nat -F
  /sbin/iptables -t mangle -F
  /sbin/iptables -P INPUT ACCEPT
  /sbin/iptables -P FORWARD ACCEPT
  /sbin/iptables -P OUTPUT ACCEPT
}


case "$1" in
  start|restart)
    echo -n "Avvio del firewall..."
    fw_stop 
    fw_start
    echo "done."
    ;;
  stop)
    echo -n "Arresto del firewall..."
    fw_stop
    echo "done."
    ;;
  clear)
    echo -n "Pulizia delle regole del firewall..."
    fw_clear
    echo "done."
    ;;
  *)
    echo "Uso: $0 {start|stop|restart|clear}"
    exit 1
    ;;
  esac
exit 0
</example>

<p>Invece di includere tutte le regole di iptables negli script in
init.d, potete usare il programma <prgn>iptables-restore</prgn> per
ripristinare le regole salvate usando <prgn>iptables-save</prgn>. 
Per fare questo dovrete definire le vostre regole e salvare il
file delle regole creato in una posizione statica (come ad esempio
in <file>/etc/default/firewall</file>).




<sect2>Configurare le regole del firewall tramite <prgn>ifup</prgn>

<p>Potete utilizzare anche la configurazione di rete in
<file>/etc/network/interfaces</file> per determinare le regole del
firewall. Per fare questo:

<list>
<item>Create il vostro insieme di regole del firewall per quando
l'interfaccia è attiva.

<item>Salvate l'insieme di regole con <prgn>iptables-save</prgn> in 
un file in <file>/etc</file>, ad esempio <file>/etc/iptables.up.rules</file>

<item>Configurate <file>/etc/network/interfaces</file> ed usate 
l'insieme delle regole appena impostate:

<example>
iface eth0 inet static
        address x.x.x.x
        [.. interface configuration ..]
        pre-up iptables-restore < /etc/iptables.up.rules
</example>

</list>

<p>In aggiunta potete anche configurare un insieme di regole da
applicare per quando l'interfaccia di rete è <em>down</em>, mediante
la creazione del suddetto insieme di regole, salvandolo in
<file>/etc/iptables.down.rules</file> e aggiungendo questa direttiva
alla configurazione dell'interfaccia:

<example>
    post-down iptables-restore < /etc/iptables.down.rules
</example>

<p>Per script di configurazione più avanzati che fanno uso di
<package>ifupdown</package>, potete utilizzare gli agganci 
disponibili per ciascuna interfaccia come nelle directory 
<file>*.d/</file> chiamati con <prgn>run-parts</prgn> (consultate
<manref name="run-parts" section="8">).



<sect2>Collaudare la configurazione del firewall

<p>Collaudare la configurazione del firewall è molto facile, e 
pericoloso, infatti basta eseguire lo script del firewall (o 
abilitare la configurazione definita nella propria applicazione per
la configurazione del firewall). Comunque, se non siete abbastanza
cauti e state configurando il vostro firewall da remoto (ad esempio
mediante una connessione SSH), potreste trovarvi tagliati fuori.

<p>Ci sono parecchi modi per impedire che questo avvenga. Uno di 
questi è eseguire uno script in un terminale separato che rimuoverà 
la configurazione del firewall se non viene recepito un input. Un 
esempio di questo è:

<example>
$  while true; do test=""; read  -t 20 -p "OK? " test ; \
  [ -z "$test" ] && /etc/init.d/firewall clear ; done
</example>

<p>Un'altra strada è quella di introdurre una backdoor nel sistema 
mediante un meccanismo alternativo che permetta di disattivare il
firewall o bucarlo nel caso in cui qualcosa andasse storto. Per fare 
questo potete usare <package>knockd</package> e configurarlo in modo
che una determinata connessione ad una porta disattivi il firewall (o
aggiunga una regola temporanea). Anche se i pacchetti verranno
rifiutati dal firewall, finché <package>knockd</package> impegna
l'interfaccia e <em>vede</em>, potrete aggirare il problema.

<p>Collaudare un firewall che sta proteggendo una rete interna è una
questione differente, si può voler conoscere alcuni dei tool usati
nella valutazione delle vulnerabilità remote (vedete in
<ref id="vuln-asses">) per sondare la rete dall'esterno all'interno
(o da qualunque altra direzione) per verificare l'efficacia della
configurazione del firewall.
