aboutsummaryrefslogtreecommitdiff
path: root/it_IT.ISO8859-15/books/handbook/security/chapter.xml
diff options
context:
space:
mode:
Diffstat (limited to 'it_IT.ISO8859-15/books/handbook/security/chapter.xml')
-rw-r--r--it_IT.ISO8859-15/books/handbook/security/chapter.xml183
1 files changed, 83 insertions, 100 deletions
diff --git a/it_IT.ISO8859-15/books/handbook/security/chapter.xml b/it_IT.ISO8859-15/books/handbook/security/chapter.xml
index 379ee0644e..4a94b0d5f0 100644
--- a/it_IT.ISO8859-15/books/handbook/security/chapter.xml
+++ b/it_IT.ISO8859-15/books/handbook/security/chapter.xml
@@ -5,26 +5,19 @@
$FreeBSD$
Original revision: 1.312
-->
-
-<chapter id="security">
- <chapterinfo>
+<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security">
+ <info><title>Sicurezza</title>
<authorgroup>
- <author>
- <firstname>Matthew</firstname>
-
- <surname>Dillon</surname>
-
- <contrib>La maggior parte di questo capitolo è stata presa
- dalla manual page security(7) di </contrib>
- </author>
+ <author><personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><contrib>La maggior parte di questo capitolo è stata presa
+ dalla manual page security(7) di </contrib></author>
</authorgroup>
- </chapterinfo>
+ </info>
- <title>Sicurezza</title>
+
<indexterm><primary>security</primary></indexterm>
- <sect1 id="security-synopsis">
+ <sect1 xml:id="security-synopsis">
<title>Sinossi</title>
<para>Questo capitolo dà un'introduzione di base sui concetti dei
@@ -113,13 +106,11 @@
</itemizedlist>
<para>Altri argomenti inerenti la sicurezza sono trattati in altre parti di
- questo libro. Ad esempio i meccanismy di MAC sono discussi in <xref
- linkend="mac"/> e la gestione dei firewall in <xref
- linkend="firewalls"/>.</para>
+ questo libro. Ad esempio i meccanismy di MAC sono discussi in <xref linkend="mac"/> e la gestione dei firewall in <xref linkend="firewalls"/>.</para>
</sect1>
- <sect1 id="security-intro">
+ <sect1 xml:id="security-intro">
<title>Introduzione</title>
<para>La sicurezza è una funzione che inizia e finisce con
@@ -154,7 +145,7 @@
<para>La sicurezza di un sistema riguarda anche il gestire varie forme di
attacco, compresi attacchi che tentano di bloccare, o comunque rendere
inusabile, il sistema, anche se non necessariamente cercano di
- compromettere l'account di root <username>root</username> (<quote>rompere
+ compromettere l'account di root <systemitem class="username">root</systemitem> (<quote>rompere
root</quote>). I problemi di sicurezza possono essere suddivisi in
svariate categorie:</para>
@@ -230,10 +221,10 @@
<para>Bisogna sempre dare per scontato che una volta che un attaccante ha
accesso ad un account utente, può rompere anche
- <username>root</username>.
+ <systemitem class="username">root</systemitem>.
In realtà, comunque, in un sistema ben configurato e mantenuto,
questo non è necessariamente vero. La distinzione è
- importante perché senza accesso a <username>root</username>
+ importante perché senza accesso a <systemitem class="username">root</systemitem>
l'attaccante in genere non può nascondere le proprie tracce e
può, alla peggio, rovinare i file dell'utente o mandare la
macchina in crash. La compromissione degli account utente è molto
@@ -246,19 +237,19 @@
</indexterm>
<para>Gli amministratori di sistema devono ricordare che su una macchina ci
- sono potenzialmente molti modi per rompere <username>root</username>.
- L'attaccante potrebbe conoscere la password di <username>root</username>,
+ sono potenzialmente molti modi per rompere <systemitem class="username">root</systemitem>.
+ L'attaccante potrebbe conoscere la password di <systemitem class="username">root</systemitem>,
potrebbe trovare un bug in un programma server in esecuzione con diritti
- di <username>root</username> e sfruttarlo per entrare da remoto, oppure
+ di <systemitem class="username">root</systemitem> e sfruttarlo per entrare da remoto, oppure
una volta ottenuto un account utente potrebbe fare lo stesso con un bug in
- un programma con suid <username>root</username>. Se un attaccante rompe
- <username>root</username> su una macchina, potrebbe non aver bisogno di
+ un programma con suid <systemitem class="username">root</systemitem>. Se un attaccante rompe
+ <systemitem class="username">root</systemitem> su una macchina, potrebbe non aver bisogno di
installare una backdoor. Molti dei buchi per l'accesso come
- <username>root</username> trovati (e chiusi) fino ad oggi richiedono un
+ <systemitem class="username">root</systemitem> trovati (e chiusi) fino ad oggi richiedono un
considerevole lavoro da parte dell'attaccante per pulire le tracce
lasciate, quindi molti attaccanti installano delle backdoor. Una backdoor
dà all'attaccante un modo semplice per riottenere accesso
- <username>root</username> al sistema, ma danno anche un modo semplice per
+ <systemitem class="username">root</systemitem> al sistema, ma danno anche un modo semplice per
individuare l'intrusione, all'amministratore di sistema furbo. Rendere
impossibile installare backdoor all'attaccante potrebbe in realtà
diminuire la sicurezza del sistema, dato che comunque non chiuderà
@@ -270,13 +261,13 @@
<orderedlist>
<listitem>
- <para>Rendere sicuro <username>root</username> e gli account dello
+ <para>Rendere sicuro <systemitem class="username">root</systemitem> e gli account dello
staff.</para>
</listitem>
<listitem>
<para>Rendere sicuri i server e i binari suid/sgid in esecuzione come
- <username>root</username>.</para>
+ <systemitem class="username">root</systemitem>.</para>
</listitem>
<listitem>
@@ -307,7 +298,7 @@
</sect1>
- <sect1 id="securing-freebsd">
+ <sect1 xml:id="securing-freebsd">
<title>Rendere sicuro &os;</title>
<indexterm>
@@ -326,12 +317,11 @@
</note>
<para>Le sezioni seguenti descrivono i metodi per rendere sicuro il vostro
- sistema &os; che sono stati menzionati nella <link
- linkend="security-intro">sezione precedente</link> di questo
+ sistema &os; che sono stati menzionati nella <link linkend="security-intro">sezione precedente</link> di questo
capitolo.</para>
- <sect2 id="securing-root-and-staff">
- <title>Rendere sicuro <username>root</username> e gli account dello
+ <sect2 xml:id="securing-root-and-staff">
+ <title>Rendere sicuro <systemitem class="username">root</systemitem> e gli account dello
staff.</title>
<indexterm>
@@ -339,9 +329,9 @@
</indexterm>
<para>Innanzitutto, non preoccuparti di rendere sicuri gli account di
- staff se non hai reso sicuro l'account <username>root</username>. La
+ staff se non hai reso sicuro l'account <systemitem class="username">root</systemitem>. La
maggior parte dei sistemi hanno una password assegnata per l'account
- <username>root</username>. La prima cosa che devi dare per assunta
+ <systemitem class="username">root</systemitem>. La prima cosa che devi dare per assunta
è che la password è <emphasis>sempre</emphasis>
compromessa. Questo non significa che devi togliere la password; la
password è quasi sempre necessaria per l'accesso dalla console
@@ -350,53 +340,53 @@
possibilmente neanche dal comando &man.su.1;. Per esempio, assicurati
che le tue pty siano specificate come <literal>insecure</literal> nel
file <filename>/etc/ttys</filename> in modo che accessi diretti
- <username>root</username> tramite <command>telnet</command> o
+ <systemitem class="username">root</systemitem> tramite <command>telnet</command> o
<command>rlogin</command> non siano permessi. Se usi altri servizi di
login come ad esempio <application>sshd</application>, fai in modo che
- accessi diretti come <username>root</username> siano vietati anche per
+ accessi diretti come <systemitem class="username">root</systemitem> siano vietati anche per
questi. Puoi farlo modificando il file
<filename>/etc/ssh/sshd_config</filename> e assicurandoti che
<literal>PermitRootLogin</literal> sia impostato a
<literal>NO</literal>. Tieni conto di tutti i modi di accesso &mdash;
servizi come ad esempio FTP vengono spesso trascurati. Login
- <username>root</username> diretti dovrebbero essere permessi solo
+ <systemitem class="username">root</systemitem> diretti dovrebbero essere permessi solo
tramite la console di sistema.</para>
<indexterm>
- <primary><groupname>wheel</groupname></primary>
+ <primary><systemitem class="groupname">wheel</systemitem></primary>
</indexterm>
<para>Ovviamente, come sysadmin (amministratore di sistema) hai bisogno
- di accesso a <username>root</username>, quindi apriremo alcuni passaggi;
+ di accesso a <systemitem class="username">root</systemitem>, quindi apriremo alcuni passaggi;
ci assicureremo però che questi passaggi richiedano ulteriori
verifiche di password per funzionare. Un modo per accedere a
- <username>root</username> è aggiungere gli appropriati account di
- staff al gruppo <groupname>wheel</groupname> (in
+ <systemitem class="username">root</systemitem> è aggiungere gli appropriati account di
+ staff al gruppo <systemitem class="groupname">wheel</systemitem> (in
<filename>/etc/group</filename>). I membri del gruppo
- <groupname>wheel</groupname> possono accedere a
- <username>root</username> tramite <command>su</command>.
+ <systemitem class="groupname">wheel</systemitem> possono accedere a
+ <systemitem class="username">root</systemitem> tramite <command>su</command>.
Non dovresti mai dare ai membri dello staff accesso nativo al gruppo
- <groupname>wheel</groupname> mettendoli in quel gruppo nel file
+ <systemitem class="groupname">wheel</systemitem> mettendoli in quel gruppo nel file
<filename>/etc/passwd</filename>; dovresti metterli nel gruppo
- <groupname>staff</groupname> e quindi aggiungerli al gruppo
- <groupname>wheel</groupname> tramite il file
+ <systemitem class="groupname">staff</systemitem> e quindi aggiungerli al gruppo
+ <systemitem class="groupname">wheel</systemitem> tramite il file
<filename>/etc/group</filename>. Solo i membri dello staff che hanno
- effettivo bisogno di accesso a <username>root</username> dovrebbero
- essere nel gruppo <groupname>wheel</groupname> group. Altra
+ effettivo bisogno di accesso a <systemitem class="username">root</systemitem> dovrebbero
+ essere nel gruppo <systemitem class="groupname">wheel</systemitem> group. Altra
possibilità, quando si utilizzi Kerberos come metodo di
autenticazione, &grave; quella di utilizzare il file
- <filename>.k5login</filename> dell'account <username>root</username> in
- modo da permettere l'accesso a <username>root</username> tramite
+ <filename>.k5login</filename> dell'account <systemitem class="username">root</systemitem> in
+ modo da permettere l'accesso a <systemitem class="username">root</systemitem> tramite
&man.ksu.1; senza bisogno di mettere nessuno nel gruppo
- <groupname>wheel</groupname>. Questa potrebbe essere la soluzione
- migliore dato che il meccanismo <groupname>wheel</groupname> permette
- all'attaccante di diventare <username>root</username> se è
+ <systemitem class="groupname">wheel</systemitem>. Questa potrebbe essere la soluzione
+ migliore dato che il meccanismo <systemitem class="groupname">wheel</systemitem> permette
+ all'attaccante di diventare <systemitem class="username">root</systemitem> se è
riuscito ad ottenere accesso ad un account di staff. Benché il
- meccanismo <groupname>wheel</groupname> sia meglio di niente, non
+ meccanismo <systemitem class="groupname">wheel</systemitem> sia meglio di niente, non
è necessariamente la soluzione più sicura.</para>
<para>Un metodo indiretto per rendere sicuri gli account di staff e quindi
- l'accesso a <username>root</username> è quello di eseguire
+ l'accesso a <systemitem class="username">root</systemitem> è quello di eseguire
l'operazione nota come <quote>starring</quote> delle password cifrate.
password for the staff accounts: utilizzando il comando &man.vipw.8; si
può rimpiazzare ogni password cifrata con un singolo carattere
@@ -498,9 +488,9 @@
più affetti da bug. Per esempio, utilizzare una versione
obsoleta di <application>imapd</application> o
<application>popper</application> è equivalente a dare accesso
- <username>root</username> al mondo intero. Non eseguire mai un server
+ <systemitem class="username">root</systemitem> al mondo intero. Non eseguire mai un server
senza controllarlo accuratamente. Molti server non hanno bisogno di
- essere eseguiti come <username>root</username>. Per esempio i demoni
+ essere eseguiti come <systemitem class="username">root</systemitem>. Per esempio i demoni
<application>ntalk</application>, <application>comsat</application> e
<application>finger</application> possono essere eseguiti in speciali
<firstterm>sandbox</firstterm> utente. Difficilmente una sandbox
@@ -510,7 +500,7 @@
deve ancora riuscire ad evadere da quest'ultima. Più strati
l'attaccante deve superare, minore la sua probabilità di
successo. Storicamente sono state trovate falle di accesso a root in
- virtualmente ogni server mai eseguito come <username>root</username>,
+ virtualmente ogni server mai eseguito come <systemitem class="username">root</systemitem>,
inclusi i server del sistema base. Se hai una macchina alla quale la
gente accede solamente tramite <application>sshd</application> e mai
tramite <application>telnetd</application> o
@@ -540,20 +530,20 @@
ad alcuni di questi ma installarli potrebbe richiedere più lavoro
di quello che si intende dedicargli (il fattore convenienza colpisce
ancora). Potresti dover eseguire questi servizi come
- <username>root</username> ed affidarti ad altri meccanismi per
+ <systemitem class="username">root</systemitem> ed affidarti ad altri meccanismi per
individuare le intrusioni che potrebbero essere fatte attraverso
questi.</para>
<para>L'altra grande potenziale fonte di falle per l'accesso a
- <username>root</username> sono i binari suid-root e sgid installati nel
+ <systemitem class="username">root</systemitem> sono i binari suid-root e sgid installati nel
sistema, come ad esempio <application>rlogin</application>, nelle
directory <filename>/bin</filename>, <filename>/sbin</filename>,
<filename>/usr/bin</filename> o <filename>/usr/sbin</filename>.
Benché niente sia sicuro al 100%, i binari suid e sgid presenti
nel sistema per default possono essere considerati ragionevolmente
- sicuri. In ogni caso, delle falle da <username>root</username> sono
+ sicuri. In ogni caso, delle falle da <systemitem class="username">root</systemitem> sono
occasionalmente trovate anche in questi. Nel 1998 è stata
- trovata una falla da <username>root</username> in
+ trovata una falla da <systemitem class="username">root</systemitem> in
<literal>Xlib</literal> che rendeva vulnerabile
<application>xterm</application> (che tipicamente è suid).
<!--TODO-->
@@ -569,7 +559,7 @@
any passworded account. Alternatively an intruder who breaks
group <literal>kmem</literal> can monitor keystrokes sent through
ptys, including ptys used by users who login through secure
- methods. An intruder that breaks the <groupname>tty</groupname>
+ methods. An intruder that breaks the <systemitem class="groupname">tty</systemitem>
group can write to
almost any user's tty. If a user is running a terminal program or
emulator with a keyboard-simulation feature, the intruder can
@@ -577,7 +567,7 @@
to echo a command, which is then run as that user.</para>
</sect2>
- <sect2 id="secure-users">
+ <sect2 xml:id="secure-users">
<title>Rendere sicuri gli account utente</title>
<para>Gli account utente sono generalmente i più difficili da
@@ -600,14 +590,13 @@
più password possibile e utilizzare ssh o Kerberos per accedere a
quegli account. Anche se il file di password cifrato
(<filename>/etc/spwd.db</filename>) può essere letto solo da
- <username>root</username>, potrebbe essere possibile per un attaccante
+ <systemitem class="username">root</systemitem>, potrebbe essere possibile per un attaccante
ottenere accesso in lettura a quel file anche senza aver ottenuto
accesso in scrittura.</para>
<para>I tuoi script di sicurezza dovrebbero sempre verificare che il file
password non venga modificato e in caso riportarlo ad un amministratore
- (cfr. la sezione <link
- linkend="security-integrity">Verifica dell'integrità dei
+ (cfr. la sezione <link linkend="security-integrity">Verifica dell'integrità dei
file</link> sottostante).</para>
</sect2>
@@ -615,22 +604,22 @@
<title>Rendere sicuri il kernel, i raw device e i file system</title>
<para>Quando un attaccante irrompe nell'account di
- <username>root</username> può fare qualsiasi cosa, ma alcune cose
+ <systemitem class="username">root</systemitem> può fare qualsiasi cosa, ma alcune cose
sono più comode di altre. <!--there are certain conveniences-->
Per esempio, la maggior parte dei kernel moderni comprende un device
per l'ascolto dei pacchetti di rete. In &os; questo device si chiama
- <devicename>bpf</devicename>. Un intrusore generalmente cercherà
+ <filename>bpf</filename>. Un intrusore generalmente cercherà
di ascoltare i pacchetti delle reti a cui la macchina compromessa
è collegata. Non ò obbligatorio dare all'intrusore questa
possibilità e d'altro canto la maggior parte dei sistemi non ha
- bisogno di avere il device <devicename>bpf</devicename>.</para>
+ bisogno di avere il device <filename>bpf</filename>.</para>
<indexterm>
<primary><command>sysctl</command></primary>
</indexterm>
<para>Anche nel caso di aver disattivato il device
- <devicename>bpf</devicename>, bisogna comunque preoccuparsi di
+ <filename>bpf</filename>, bisogna comunque preoccuparsi di
<filename>/dev/mem</filename> e <filename>/dev/kmem</filename>; tra
l'altro l'intrusore ha anche la possibilità di scrivere sui
device disco raw o utilizzare il comando di caricamento moduli del
@@ -659,7 +648,7 @@
intrusion.</para>
</sect2>
- <sect2 id="security-integrity">
+ <sect2 xml:id="security-integrity">
<title>Verifica dell'integrità dei file: binari, file di
configurazione, etc.</title>
@@ -853,7 +842,7 @@
della vostra rete. L'idea è di prevenire gli attacchi a
saturazione provenienti dall'esterno della vostra rete, non tanto di
proteggere i servizi da attacchi di rete atti a compromettere
- <username>root</username>. Utilizza sempre un firewall <!--TODO:
+ <systemitem class="username">root</systemitem>. Utilizza sempre un firewall <!--TODO:
exclusive-->, ovvero <quote>blocca tutto <emphasis>tranne</emphasis> le
porte A, B, C, D e M-Z</quote>; puoi bloccare tutte le porte basse ad
eccezione di specifici servizi quali <application>named</application>
@@ -972,7 +961,7 @@
are usable. The actual keys themselves are not exposed, but
ssh installs a forwarding port for the
duration of your login, and if an attacker has broken
- <username>root</username> on the
+ <systemitem class="username">root</systemitem> on the
insecure machine he can utilize that port to use your keys to gain
access to any other machine that your keys unlock.</para>
@@ -995,20 +984,14 @@
</sect1>
- <sect1 id="crypt">
- <sect1info>
+ <sect1 xml:id="crypt">
+ <info><title>DES, MD5 e Crypt</title>
<authorgroup>
- <author>
- <firstname>Bill</firstname>
-
- <surname>Swingle</surname>
-
- <contrib>Parti riscritte e aggiornate da </contrib>
- </author>
+ <author><personname><firstname>Bill</firstname><surname>Swingle</surname></personname><contrib>Parti riscritte e aggiornate da </contrib></author>
</authorgroup>
- </sect1info>
+ </info>
- <title>DES, MD5 e Crypt</title>
+
<indexterm>
<primary>sicurezza</primary>
@@ -1077,7 +1060,7 @@
</sect2>
</sect1>
- <sect1 id="one-time-passwords">
+ <sect1 xml:id="one-time-passwords">
<title>Password One-time</title>
<indexterm><primary>one-time passwords</primary></indexterm>
@@ -1142,65 +1125,65 @@
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="tcpwrappers">
+ <sect1 xml:id="tcpwrappers">
<title>TCP Wrappers</title>
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="kerberosIV">
+ <sect1 xml:id="kerberosIV">
<title><application>KerberosIV</application></title>
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="kerberos5">
+ <sect1 xml:id="kerberos5">
<title><application>Kerberos5</application></title>
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="openssl">
+ <sect1 xml:id="openssl">
<title>OpenSSL</title>
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="ipsec">
+ <sect1 xml:id="ipsec">
<title>IPsec</title>
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="openssh">
+ <sect1 xml:id="openssh">
<title>OpenSSH</title>
- <sect2 id="security-ssh-tunneling">
+ <sect2 xml:id="security-ssh-tunneling">
<title>SSH Tunneling</title>
<para>Traduzione in corso</para>
</sect2>
</sect1>
- <sect1 id="fs-acl">
+ <sect1 xml:id="fs-acl">
<title>File System Access Control Lists</title>
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="security-portaudit">
+ <sect1 xml:id="security-portaudit">
<title>Monitoring Third Party Security Issues</title>
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="security-advisories">
+ <sect1 xml:id="security-advisories">
<title>&os; Security Advisories</title>
<para>Traduzione in corso</para>
</sect1>
- <sect1 id="security-accounting">
+ <sect1 xml:id="security-accounting">
<title>Process Accounting</title>
<para>Traduzione in corso</para>