diff options
Diffstat (limited to 'it_IT.ISO8859-15/books/handbook/security/chapter.xml')
| -rw-r--r-- | it_IT.ISO8859-15/books/handbook/security/chapter.xml | 1208 |
1 files changed, 1208 insertions, 0 deletions
diff --git a/it_IT.ISO8859-15/books/handbook/security/chapter.xml b/it_IT.ISO8859-15/books/handbook/security/chapter.xml new file mode 100644 index 0000000000..6d983c6e33 --- /dev/null +++ b/it_IT.ISO8859-15/books/handbook/security/chapter.xml @@ -0,0 +1,1208 @@ +<?xml version="1.0" encoding="iso-8859-15" standalone="no"?> +<!-- + The FreeBSD Italian Documentation Project + + $FreeBSD$ + Original revision: 1.312 +--> + +<chapter id="security"> + <chapterinfo> + <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> + </authorgroup> + </chapterinfo> + + <title>Sicurezza</title> + + <indexterm><primary>security</primary></indexterm> + + <sect1 id="security-synopsis"> + <title>Sinossi</title> + + <para>Questo capitolo dà un'introduzione di base sui concetti dei + sistemi di sicurezza, alcune buone regole di comportamento e alcuni + argomenti avanzati per &os;. Molti degli argomenti qua trattati possono + essere applicati anche ai sistemi e alla sicurezza su Internet in + generale. Internet non è più il luogo + <quote>amichevole</quote> dove ognuno vuole essere il tuo gentile vicino. + Mettere in sicurezza il tuo sistema è un imperativo per la + protezione dei tuoi dati, della tua proprietà intelletuale, del tuo + tempo e molto altro dalla mano di hacker e simili.</para> + + <para>&os; dà un insieme di utility e di meccanismi per assicurare + l'integrità e la sicurezza del tuo sistema e della tua rete.</para> + + <para>Dopo la lettura di questo capitolo, conoscerai:</para> + + <itemizedlist> + <listitem> + <para>Concetti di base dei sistemi di sicurezza, rispetto a &os;.</para> + </listitem> + + <listitem> + <para>Vari meccanismi di crittografia disponibili in &os;, + come <acronym>DES</acronym> e <acronym>MD5</acronym>.</para> + </listitem> + + <listitem> + <para>Come configurare l'autenticazione OTP (password a singolo + uso).</para> + </listitem> + + <listitem> + <para>Come configurare i <acronym>TCP</acronym> Wrapper per l'uso con + <command>inetd</command>.</para> + </listitem> + + <listitem> + <para>Come configurare <application>KerberosIV</application> su + &os;.</para> + </listitem> + + <listitem> + <para>Come configurare <application>Kerberos5</application> su &os; 5.0 + o successivi.</para> + </listitem> + + <listitem> + <para>Come configurare IPsec e creare una <acronym>VPN</acronym> tra + macchine &os;/&windows;.</para> + </listitem> + + <listitem> + <para>Come configurare e usare <application>OpenSSH</application>, + l'implementaizone <acronym>SSH</acronym> usata da &os;.</para> + </listitem> + + <listitem> + <para>Cosa sono le <acronym>ACL</acronym> del file system e come + usarle.</para> + </listitem> + + <listitem> + <para>Come usare l'utility <application>Portaudit</application> per + monitorare i pacchetti software di terze parti installati dalla + Ports Collection.</para> + </listitem> + + <listitem> + <para>Come utilizzare le pubblicazioni sugli avvisi di sicurezza di + &os;.</para> + </listitem> + + <listitem> + <para>Avere un'idea di cosa sia il Process Accounting e come abilitarlo + su &os;.</para> + </listitem> + </itemizedlist> + + <para>Prima di leggere questo capitolo dovresti:</para> + + <itemizedlist> + <listitem> + <para>Capire concetti base di &os; e Internet.</para> + </listitem> + </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> + </sect1> + + + <sect1 id="security-intro"> + <title>Introduzione</title> + + <para>La sicurezza è una funzione che inizia e finisce con + l'amministratore di sistema. Nonostante ogni sistema multi-utente &unix; + BSD abbia della sicurezza insita, il lavoro di costruire e mantenere + meccanismi di sicurezza aggiuntivi in modo da mantenere + <quote>onesti</quote> gli utenti è probabilmente uno dei maggiori + lavori di un amministratore di sistema. La macchine sono sicure solo + quanto le si rende e le richieste di sicurezza si scontrano sempre con + l'umana necessità per la comodità. I sistemi &unix;, in + generale, sono capaci di eseguire un gran numero di processi contemporanei + e ognuno di questi processi opera come server — nel senso che + entità esterne possono connettersi e parlarci. Mentre i mini e i + mainframe di ieri diventano i desktop di oggi, mentre i computer diventano + interconnessi e internet-connessi, la sicurezza diventa un problema + sempre maggiore.</para> + + <!--DELETED + <para>Il modo migliore per implementare la sicurezza è con un + approccio <quote>a cipolla</quote>. In pratica, quello che vuoi fare + è creare tanti livelli di sicurezza quanto è conveniente e + poi tenere sotto controllo il sistema per vedere eventuali intrusioni. + Non vuoi esagerare nella sicurezza o interferirai con l'individuazione e + quest'ultima è una delle parti più importanti di ogni + meccanismo di sicurezza. Per esempio, ha poco senso imopstare il flag + <literal>schg</literal> (vedi &man.chflags.1;) su ogni binario di sistema + dato che questo potrà sì proteggere temporaneamente i + binari, ma evita che l'attaccante faccia una modifica facilmente + individuabile e potrebbe far in modo che il tuo meccanismo di sicurezza + non individui l'attaccante del tutto.</para>--> + + <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 + root</quote>). I problemi di sicurezza possono essere suddivisi in + svariate categorie:</para> + + <orderedlist> + <listitem> + <para>Attacchi che limitano la disponibilità dei servizi + (<quote>Denial of service</quote> o, in breve, DoS).</para> + </listitem> + + <listitem> + <para>Compromissione degli account utente.</para> + </listitem> + + <listitem> + <para>Compromissione di root tramite server accessibili.</para> + </listitem> + + <listitem> + <para>Compromissione di root tramite gli account utente.</para> + </listitem> + + <listitem> + <para>Crazione di backdoor (letteralmente <quote>porte sul + retro</quote>, ovvero accessi secondari personalizzati).</para> + </listitem> + </orderedlist> + + <indexterm> + <primary>attacchi DoS</primary> + <see>Denial of Service (DoS)</see> + </indexterm> + <indexterm> + <primary>sicurezza</primary> + <secondary>attacchi DoS</secondary> + <see>Denial of Service (DoS)</see> + </indexterm> + <indexterm><primary>Denial of Service (DoS)</primary></indexterm> + + <para>Un attacco DoS è un'azione che priva la macchina di risorse. + Tipicamente un attacco DoS è un meccanismo a forza-bruta che tenta + di bloccare e comunque rendere inusabile una macchina travolgendo di + richieste i server che rende disponibili o direttamente lo stack di rete. + Alcuni attacchi DoS tentano di trarre vantaggio da bug nello stack di rete + per bloccare la macchina con un singolo pacchetto. Questo genere di + attacchi può evitato solo mettendo a posto il bug direttamente nel + kernel. Gli attacchi sui server possono spesso essere evitati + specificando con attenzione dei limiti sul carico che i server stessi + devono accettare in caso che il sistema lavori in condizioni avverse. + Gli attacchi a forza-bruta generati da un'intera rete di attaccanti sono + più difficili da gestire. Ad esempio un attacco con pacchetti + in spoof (ovvero con il campo mittente falsato) è praticamente + impossibile da fermare, a meno di staccare del tutto il sistema da + Internet. Potrà anche non fermare la tua macchina, ma sicuramente + può saturare la tua connessione Internet.</para> + + <indexterm> + <primary>sicurezza</primary> + <secondary>compromissione degli account</secondary> + </indexterm> + + <para>La compromissione di un account utente è ancora più + comune di un attacco DoS. Molti sysadmin usano ancora i server standard + <application>telnetd</application>, <application>rlogind</application>, + <application>rshd</application> e <application>ftpd</application> sulle + loro macchine. Questi programmi, normalmente, non usano connessioni + crittate. Il risultato è che quando hai una base utenti di medie + dimensioni, uno o più degli utenti connessi al tuo sistema da + remoto (il modo più comune e conveniente per collegarsi a un + sisetma) avrà una password compromessa da un'operaizone di + sniffing. Gli amministratori di sistema attenti controllano i registri + degli accessi remoto cercando indirizzi sospetti anche tra gli accessi + permessi.</para> + + <para>Bisogna sempre dare per scontato che una volta che un attaccante ha + accesso ad un account utente, può rompere anche + <username>root</username>. + In realtà, comunque, in un sistema ben configurato e mantenuto, + questo non è necessariamente vero. La distinzione è + importante perché senza accesso a <username>root</username> + 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 + comune dato che gli utenti tendono a non prendere precauzioni tanto + quanto gli amministratori di sistema.</para> + + <indexterm> + <primary>sicurezza</primary> + <secondary>backdoor</secondary> + </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>, + potrebbe trovare un bug in un programma server in esecuzione con diritti + di <username>root</username> 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 + installare una backdoor. Molti dei buchi per l'accesso come + <username>root</username> 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 + 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à + il buco che l'attaccante ha trovato la prima volta.</para> + + <para>Le soluzioni di sicurezza devono sempre essere implementate con un + approccio multi-strato a <quote>cipolla</quote> e possono essere + categorizzate come segue:</para> + + <orderedlist> + <listitem> + <para>Rendere sicuro <username>root</username> 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> + </listitem> + + <listitem> + <para>Rendere sicuri gli account utente.</para> + </listitem> + + <listitem> + <para>Rendere sicuro il file delle password.</para> + </listitem> + + <listitem> + <para>Rendere sicuro il nucleo del kernel, i device raw e il file + system.</para> + </listitem> + + <listitem> + <para>Individuazione rapida delle modifiche non appropriate fatte al + sistema.</para> + </listitem> + + <listitem> + <para>Paranoia.</para> + </listitem> + </orderedlist> + + <para>La prossima sezione di questo capitolo coprirà questi punti in + maggior dettaglio.</para> + </sect1> + + + <sect1 id="securing-freebsd"> + <title>Rendere sicuro &os;</title> + + <indexterm> + <primary>sicurezza</primary> + <secondary>rendere sicuro &os;</secondary> + </indexterm> + + <note> + <title>Comandi o Protocolli</title> + <para>In questo documento useremo testo + <application>grassetto</application> per riferirci ad applicazioni e + testo <command>a spaziatura fissa</command> per riferirci a specifici + comandi. I protocolli useranno un font normale. Questa distinzione + tipografica è utile per casi come ssh, che è un protocollo + oltre che un comando.</para> + </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 + capitolo.</para> + + <sect2 id="securing-root-and-staff"> + <title>Rendere sicuro <username>root</username> e gli account dello + staff.</title> + + <indexterm> + <primary><command>su</command></primary> + </indexterm> + + <para>Innanzitutto, non preoccuparti di rendere sicuri gli account di + staff se non hai reso sicuro l'account <username>root</username>. La + maggior parte dei sistemi hanno una password assegnata per l'account + <username>root</username>. 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 + della macchina. Quello che questo significa è che non dovresti + render possibile l'uso di questa password tranne che da console e + 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 + <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 + 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 — + servizi come ad esempio FTP vengono spesso trascurati. Login + <username>root</username> diretti dovrebbero essere permessi solo + tramite la console di sistema.</para> + + <indexterm> + <primary><groupname>wheel</groupname></primary> + </indexterm> + + <para>Ovviamente, come sysadmin (amministratore di sistema) hai bisogno + di accesso a <username>root</username>, 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 + <filename>/etc/group</filename>). I membri del gruppo + <groupname>wheel</groupname> possono accedere a + <username>root</username> 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 + <filename>/etc/passwd</filename>; dovresti metterli nel gruppo + <groupname>staff</groupname> e quindi aggiungerli al gruppo + <groupname>wheel</groupname> 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 + possibilità, quando si utilizzi Kerberos come metodo di + autenticazione, ` quella di utilizzare il file + <filename>.k5login</filename> dell'account <username>root</username> in + modo da permettere l'accesso a <username>root</username> 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 è + riuscito ad ottenere accesso ad un account di staff. Benché il + meccanismo <groupname>wheel</groupname> 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'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 + <quote><literal>*</literal></quote> (asterisco, in inglese + <quote>star</quote>). Questo comando aggiorna il file + <filename>/etc/master.passwd</filename> e il database utenti/password + in modo da disabilitare i login autenticati da password.</para> + + <para>Un account di staff come il seguente:</para> + + <!--TODO:aggiustare la password per essere moderna ($1$...)--> + <programlisting>foobar:R9DT/Fa1/LV9U:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting> + + <para>Andrebbe modificato così:</para> + + <programlisting>foobar:*:1000:1000::0:0:Foo Bar:/home/foobar:/usr/local/bin/tcsh</programlisting> + + <para>Questo previene i normali login dato che la password cifrata non + sarà mai <quote><literal>*</literal></quote>. Fatto questo i + membri dello staff dovranno utilizzare un diverso meccanismo di + autenticazione come ad esempio &man.kerberos.1; o &man.ssh.1; + utilizzando una coppia di chiavi pubblica/privata. Utilizzando Kerberos + bisogna generalmente rendere sicure sia le macchine su cui viene + eseguito il server Kerberos che la propria workstation. Utilizzando una + coppia di chiavi bisogna in generale rendere sicura la macchina + <emphasis>da cui</emphasis> ci si sta collegando (in genere la propria + workstation); si può aggiungere un ulteriore strato di protezione + proteggendo la coppia di chiavi con una password all'atto della + creazione con &man.ssh-keygen.1;. Eseguire lo <quote>starring</quote> + degli account dello staff garantisce che questi possano eseguire il + login solo tramite i metodi di accesso sicuri che sono stati + configutati. Quest forze l'intero staff all'uso di connessioni sicure e + cifrate in tutte le loro sessioni, chiudendo un importante falla di + sicurezza utilizzata da molti attaccanti: ascoltare il traffico di rete + da un'altra macchina meno sicura.</para> + + <!--TODO: questo paragrafo è poco leggibile, anche in inglese --> + <para>I meccanismi di sicurezza più indiretti assumono anche che ci + si colleghi da un server più restrittivo a uno che lo è di + meno; per esempio se il tuo server primario ha in esecuzione una grande + varietà di servizi, la tua workstation non dovrebbe averne in + esecuzione nessuno. Per fare in modo che la tua workstation sia + ragionevolmente sicura dovresti eseguire meno servizi possibile, o + perfino nessuno del tutto, e dovresti utilizzare uno screen saver + protetto da password. Ovviamente, avendo accesso fisico alla + workstation un attaccante può rompere qualsiasi protezione che tu + possa aver importato, ma bisogna sempre considerare che la magior parte + degli attacchi avviene remotamente, tramite una rete, da parte di + persone che non hanno accesso fisico alle tue workstation o ai tuoi + server.</para> + + <indexterm><primary>KerberosIV</primary></indexterm> + + <para>L'uso di sistemi come Kerberos permette di disabilitare o cambiare + la pasword ad un account di staff in un solo posto ed avere effeto + immediato su tutte le macchine in cui il membro dello staff ha un + account. Nel caso l'account di un membro dello staff venga compromesso, + la possibilità di poter cambiare la sua password su tutte le + macchine non ` cosa di poco conto. Con password separate, + cambiare una password su molte macchine può essere un bel + problema. Con Kerberos puoi anche imporre restrizioni di cambio + password: non solo un ticket Kerberos può essere fatto per + scadere dopo un tempo predeterminato, ma il sistema Kerberos può + richiedere all'utente di scegliere una nuova passsword dopo un certo + periodo di tempo (per esempio, una volta al mese).</para> + </sect2> + + <sect2> + <title>Rendere sicuri i server Root e i binari SUID/SGID</title> + + <indexterm> + <primary><command>ntalk</command></primary> + </indexterm> + <indexterm> + <primary><command>comsat</command></primary> + </indexterm> + <indexterm> + <primary><command>finger</command></primary> + </indexterm> + <indexterm> + <primary>sandboxes</primary> + </indexterm> + <indexterm> + <primary><application>sshd</application></primary> + </indexterm> + <indexterm> + <primary><application>telnetd</application></primary> + </indexterm> + <indexterm> + <primary><application>rshd</application></primary> + </indexterm> + <indexterm> + <primary><application>rlogind</application></primary> + </indexterm> + + <para>Il sysadmin prudente esegue soltanto i server che gli sono + necessari, n´ di più né di meno. Bisogna tenere + conto del fatto che i server di terze parti sono generalmente i + 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 + senza controllarlo accuratamente. Molti server non hanno bisogno di + essere eseguiti come <username>root</username>. 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 + sarà una soluzione completa del problema, a meno di dedicarci + parecchio tempo, ma resta valido l'approccio a cipolla alla sicurezza: + se qualcuno riesce ad irrompere in un server eseguito in una sandbox, + 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>, + 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 + <application>rshd</application> o <application>rlogind</application>, + allora disattiva questi servizi!</para> + + <para>&os; attualmente esegue per default + <application>ntalkd</application>, <application>comsat</application> e + <application>finger</application> in una sandbox. Un altro programma + candidato ad essere eseguito in una sandbox è &man.named.8;. + <filename>/etc/defaults/rc.conf</filename> comprende le opzioni + necessarie per eseguire <application>named</application> in una sandbox + in forma comentata. A seconda se state installando un nuovo sistema o + aggiornando un sistema esistente, gli speciali account utente utilizzati + da queste sandbox potrebbero non essere presenti. Il sysadmin prudente + dovrebbe cercar di utilizzare delle sandbox per i server ogniqualvolta + possibile.</para> + + <indexterm> + <primary><application>sendmail</application></primary> + </indexterm> + + <para>Esiste un certo numero di altri servizi che generalmente non vengono + eseguiti in una sandbox: <application>sendmail</application>, + <application>popper</application>, <application>imapd</application>, + <application>ftpd</application> e altri. Ci sono software alternativi + 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 + 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 + 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 + occasionalmente trovate anche in questi. Nel 1998 è stata + trovata una falla da <username>root</username> in + <literal>Xlib</literal> che rendeva vulnerabile + <application>xterm</application> (che tipicamente è suid). + <!--TODO--> + It is better to be safe than sorry and the prudent + sysadmin will restrict suid binaries, that only staff should run, + to a special group that only staff can access, and get rid of + (<command>chmod 000</command>) any suid binaries that nobody uses. + A server with no display generally does not need an + <application>xterm</application> binary. Sgid binaries can be + almost as dangerous. If an intruder can break an sgid-kmem binary, + the intruder might be able to read <filename>/dev/kmem</filename> + and thus read the encrypted password file, potentially compromising + 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> + 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 + potentially generate a data stream that causes the user's terminal + to echo a command, which is then run as that user.</para> + </sect2> + + <sect2 id="secure-users"> + <title>Rendere sicuri gli account utente</title> + + <para>Gli account utente sono generalmente i più difficili da + rendere sicuri. Bench*eacute; tu possa imporre restrizioni d'accesso + <!--TODO: draconian --> allo staff ed eseguire lo + <quote>starring</quote> delle loro password, potresti non poter farlo + con l'account di un generico utente. Se hai sufficiente controllo + <!--TODO:potere?--> potesti farcela e rendere gli account utente + sufficientemente sicuri, altrimenti dovrai essere più vigile nel + controllo di questi account. L'uso di ssh e Kerberos per gli account + utente è più problematico, a causa del maggiore supporto + amministrativo e tecnico richiesto, ma è sempre un'ottima + soluzione se confrontata all'uso di un file password cifrato.</para> + </sect2> + + <sect2> + <title>Rendere sicuro il file password</title> + + <para>L'unica strada sicura è quella di eseguire lo starring so + 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 + 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 + file</link> sottostante).</para> + </sect2> + + <sect2> + <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 + 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à + 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> + + <indexterm> + <primary><command>sysctl</command></primary> + </indexterm> + + <para>Anche nel caso di aver disattivato il device + <devicename>bpf</devicename>, 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 + kernel, &man.kldload.8;. Un intrusore intraprendente può + utilizzare un proprio modulo del kernel per l'ascolto dei pacchetti e + caricarlo su un kernel in esecuzione. Per evitare questi problemi + bisogna eseguire il kernel ad un livello di sicurezza più alto, + almeno al livello 1. Il livello di sicurezza può essere + impostato con <command>sysctl</command> modificando la variabile + <varname>kern.securelevel</varname>. Se il livello di sicurezza + è impostato ad 1, l'accesso in scrittura ai device raw + sarà negato e alcuni <command>chflags</command> speciali, + come ad esempio <literal>schg</literal>, verranno verificati. + Devi anche verificare che il flag <literal>schg</literal> sia impostato + sui binari, cartelle e script utilizzati all'avvio prima + dell'impostazione del livello di sicurezza. L'uso di un livello di + sicurezza superiore potrebbe essere una misura eccesiva, dato che rende + l aggiornamento del sistema molto più complesso. + You may compromise and run the + system at a higher secure level but not set the + <literal>schg</literal> flag for every system file and directory + under the sun. Another possibility is to simply mount + <filename>/</filename> and <filename>/usr</filename> read-only. + It should be noted that being too draconian in what you attempt to + protect may prevent the all-important detection of an + intrusion.</para> + </sect2> + + <sect2 id="security-integrity"> + <title>Verifica dell'integrità dei file: binari, file di + configurazione, etc.</title> + + <para>TODO:When it comes right down to it, you can only protect your core + system configuration and control files so much before the + convenience factor rears its ugly head. For example, using + <command>chflags</command> to set the <literal>schg</literal> bit + on most of the files in <filename>/</filename> and + <filename>/usr</filename> is probably counterproductive, because + while it may protect the files, it also closes a detection window. + The last layer of your security onion is perhaps the most + important — detection. The rest of your security is pretty + much useless (or, worse, presents you with a false sense of + security) if you cannot detect potential intrusions. Half the job + of the onion is to slow down the attacker, rather than stop him, in + order to be able to catch him in the act.</para> + + <para>The best way to detect an intrusion is to look for modified, + missing, or unexpected files. The best way to look for modified + files is from another (often centralized) limited-access system. + Writing your security scripts on the extra-secure limited-access + system makes them mostly invisible to potential attackers, and this + is important. In order to take maximum advantage you generally + have to give the limited-access box significant access to the + other machines in the business, usually either by doing a + read-only NFS export of the other machines to the limited-access + box, or by setting up ssh key-pairs to + allow the limited-access box to ssh to + the other machines. Except for its network traffic, NFS is the + least visible method — allowing you to monitor the + file systems on each client box virtually undetected. If your + limited-access server is connected to the client boxes through a + switch, the NFS method is often the better choice. If your + limited-access server is connected to the client boxes through a + hub, or through several layers of routing, the NFS method may be + too insecure (network-wise) and using + ssh may be the better choice even with + the audit-trail tracks that ssh + lays.</para> + + <para>Once you have given a limited-access box at least read access to the + client systems it is supposed to monitor, you must write scripts + to do the actual monitoring. Given an NFS mount, you can write + scripts out of simple system utilities such as &man.find.1; and + &man.md5.1;. It is best to physically md5 the client-box files + at least once a day, and to test control files such as those + found in <filename>/etc</filename> and + <filename>/usr/local/etc</filename> even more often. When + mismatches are found, relative to the base md5 information the + limited-access machine knows is valid, it should scream at a + sysadmin to go check it out. A good security script will also + check for inappropriate suid binaries and for new or deleted files + on system partitions such as <filename>/</filename> and + <filename>/usr</filename>.</para> + + <para>When using ssh rather than NFS, + writing the security script is much more difficult. You + essentially have to <command>scp</command> the scripts to the client + box in order to + run them, making them visible, and for safety you also need to + <command>scp</command> the binaries (such as find) that those + scripts use. The <application>ssh</application> client on the + client box may already be compromised. All in all, using + ssh may be necessary when running over + insecure links, but it is also a lot harder to deal with.</para> + + <para>A good security script will also check for changes to user and + staff members access configuration files: + <filename>.rhosts</filename>, <filename>.shosts</filename>, + <filename>.ssh/authorized_keys</filename> and so forth, + files that might fall outside the purview of the + <literal>MD5</literal> check.</para> + + <para>If you have a huge amount of user disk space, it may take too + long to run through every file on those partitions. In this case, + setting mount flags to disallow suid binaries and devices on those + partitions is a good idea. The <literal>nodev</literal> and + <literal>nosuid</literal> options (see &man.mount.8;) are what you + want to look into. You should probably scan them anyway, at least + once a week, since the object of this layer is to detect a break-in + attempt, whether or not the attempt succeeds.</para> + + <para>Process accounting (see &man.accton.8;) is a relatively + low-overhead feature of the operating system which might help + as a post-break-in evaluation mechanism. It is especially + useful in tracking down how an intruder has actually broken into + a system, assuming the file is still intact after the break-in has + occured.</para> + + <para>Finally, security scripts should process the log files, and the + logs themselves should be generated in as secure a manner as + possible — remote syslog can be very useful. An intruder + will try to cover his tracks, and log files are critical to the + sysadmin trying to track down the time and method of the initial + break-in. One way to keep a permanent record of the log files is + to run the system console to a serial port and collect the + information to a secure machine monitoring the consoles.</para> + </sect2> + + <sect2> + <title>Paranoia</title> + + <para>Un po' di paranoia non fa mai male. Come regola, un sysadmin + può aggiungere qualsiasi feature di sicurezza fintantoché + non impattano la comodità e può aggiungerne altre + <emphasis>che la</emphasis> impattano, ma solo dopo averci pensato bene. + <!--TODO: questa parte di paragrafo è decisamente opinabile--> + Even more importantly, a security administrator should mix it up a + bit — if you use recommendations such as those given by this + document verbatim, you give away your methodologies to the + prospective attacker who also has access to this document.</para> + </sect2> + + <sect2> + <title>Attacchi Denial of Service</title> + + <indexterm><primary>Denial of Service (DoS)</primary></indexterm> + + <para>Questa sezione parla degli attacchi Denial of Service, ovvero quelli + atti ad interrompere i servizi in esecuzione su una macchina. + Tipicamente un attacco DoS è un attacco a pacchetto; + benché non si possa fare molto riguardo ad un attacco moderno + che satura la vostra rete con pacchetti <!--TODO: spoofed-->, si + può cercare di limitare il danno assicurandosi che l'attacco non + blocchi i vostri servizi, utilizzando le seguenti tecniche:</para> + + <orderedlist> + <listitem> + <para>Limitare le fork dei server.</para> + </listitem> + + <listitem> + <para>TODO:Limiting springboard attacks (ICMP response attacks, ping + broadcast, etc.).</para> + </listitem> + + <listitem> + <para>Sovraccaricare la Kernel Route Cache. <!--TODO: anche in inglese + questo punto non ha molto senso assieme agli altri: non è qualcosa + che si fa per evitare il danno--></para> + </listitem> + </orderedlist> + + <para>Un comune scenario è l'attacco di un server che fa fork e + fargli creare così tanti processi figli da esaurire le risorse + della macchina, come ad esempio la memoria, i file descriptor o altri e + costringerlo quindi a fermarsi. <application>inetd</application> + (cfr. &man.inetd.8;) ha molte opzioni per limitare questo tipo di + attacchi. Si deve notare che benché sia possibile evitare che la + macchina si fermi, non è generalmente possibile evitare che i + servizi vengano resi non disponibili dall'attacco. Leggete attentamente + la pagina del manuale di <application>inetd</application>, con + particolare attenzione alle opzioni <option>-c</option>, + <option>-C</option> e <option>-R</option>. Un attacco con IP + <!--TODO: spoofed--> aggira l'opzione <option>-C</option> quindi + è bene utilizzare una combinazione di opzioni. Alcuni server + indipendenti hanno meccanismi interni per la limitazione delle + fork.</para> + + <para><application>Sendmail</application> ha l'opzione + <option>-OMaxDaemonChildren</option> che generalmente funziona molto + meglio che cercare di utilizzare le funzioni di limitazione basate sul + carico della macchina, a causa del ritardo di aggiornamento del valore + di carico. Quando lanci <application>sendmail</application> dovresti + specificare un parametro <literal>MaxDaemonChildren</literal> abbastanza + alto da gestire il carico previsto , ma non così alto da non + essere gestibile dal computer. È anche prudente eseguire + <application>Sendmail</application> in modalità queued + (<option>-ODeliveryMode=queued</option>) ed eseguire il demone + (<command>sendmail -bd</command>) separatamente dalla gestione code + (<command>sendmail -q15m</command>). Se vuoi che i messaggi vengano + consegnati in tempo reale puoi utilizzare un intervallo molto più + breve, come ad esempio <option>-q1m</option>, ma assicurati di + utilizzare un valore <literal>MaxDaemonChildren</literal> adatto per + <emphasis>quel</emphasis> <application>Sendmail</application>, in modo + da prevenire problemi a catena<!--TODO: cascade failures-->.</para> + + <para><application>Syslogd</application> può essere attaccato + direttamente ed è fortemente consigliato l'uso dell'opzione + <option>-s</option> quando possibile, o al limite l'opzione + <option>-a</option>.</para> + + <para>You should also be fairly careful with connect-back services + such as <application>TCP Wrapper</application>'s reverse-identd, + which can be attacked directly. You generally do not want to use + the reverse-ident feature of + <application>TCP Wrapper</application> for this reason.</para> + + <para>È un'ottima idea quella di proteggere i servizi interni + dall'accesso esterno chiudendoli tramite regole del firewall ai bordi + 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: + 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> + (se sei primario per una zona), <application>ntalkd</application>, + <application>sendmail</application> e altri servizi accessibili da + Internet. Se tu cercassi di configurare il firewall in maniera opposta + (inclusivo o permissivo) c'è una buona probabilità che tu + ti scordi di <quote>chiudere</quote> qualche servizio o che tu aggiunga + un nuovo servizio interno e dimentichi di aggiornare il firewall. + Puoi comunque lasciare aperte tutte le porte <!--TODO: high-numbered-->, + permettendo un uso permissivo, senza però compromettere le porte + <!--TODO: low-->. Nota anche che &os; ti permette di controllare + l'intervallo di porte utilizzate per il binding dinamico tramite vari + <command>sysctl</command> <varname>net.inet.ip.portrange</varname> + (<command>sysctl -a | fgrep portrange</command>), che possono + semplificare la complessità di configurazione del tuo firewall. + <!--TODO: For example, you might use a normal + first/last range of 4000 to 5000, and a hiport range of 49152 to + 65535, then block off everything under 4000 in your firewall + (except for certain specific Internet-accessible ports, of + course).--></para> + + <para>Another common DoS attack is called a springboard attack + — to attack a server in a manner that causes the server to + generate responses which overloads the server, the local + network, or some other machine. The most common attack of this + nature is the <emphasis>ICMP ping broadcast attack</emphasis>. + The attacker spoofs ping packets sent to your LAN's broadcast + address with the source IP address set to the actual machine they + wish to attack. If your border routers are not configured to + stomp on ping packets to broadcast addresses, your LAN winds up + generating sufficient responses to the spoofed source address to + saturate the victim, especially when the attacker uses the same + trick on several dozen broadcast addresses over several dozen + different networks at once. Broadcast attacks of over a hundred + and twenty megabits have been measured. A second common + springboard attack is against the ICMP error reporting system. + By constructing packets that generate ICMP error responses, an + attacker can saturate a server's incoming network and cause the + server to saturate its outgoing network with ICMP responses. This + type of attack can also crash the server by running it out of + memory, especially if the server cannot drain the ICMP responses + it generates fast enough. + Use the <application>sysctl</application> + variable <literal>net.inet.icmp.icmplim</literal> to limit these attacks. + The last major class of springboard + attacks is related to certain internal + <application>inetd</application> services such as the + udp echo service. An attacker simply spoofs a UDP packet with the + source address being server A's echo port, and the destination + address being server B's echo port, where server A and B are both + on your LAN. The two servers then bounce this one packet back and + forth between each other. The attacker can overload both servers + and their LANs simply by injecting a few packets in this manner. + Similar problems exist with the internal + <application>chargen</application> port. A + competent sysadmin will turn off all of these inetd-internal test + services.</para> + + <para>Spoofed packet attacks may also be used to overload the kernel + route cache. Refer to the <varname>net.inet.ip.rtexpire</varname>, + <varname>rtminexpire</varname>, and <varname>rtmaxcache</varname> + <command>sysctl</command> parameters. A spoofed packet attack + that uses a random source IP will cause the kernel to generate a + temporary cached route in the route table, viewable with + <command>netstat -rna | fgrep W3</command>. These routes + typically timeout in 1600 seconds or so. If the kernel detects + that the cached route table has gotten too big it will dynamically + reduce the <varname>rtexpire</varname> but will never decrease it + to less than <varname>rtminexpire</varname>. There are two + problems:</para> + + <orderedlist> + <listitem> + <para>The kernel does not react quickly enough when a lightly + loaded server is suddenly attacked.</para> + </listitem> + + <listitem> + <para>The <varname>rtminexpire</varname> is not low enough for + the kernel to survive a sustained attack.</para> + </listitem> + </orderedlist> + + <para>If your servers are connected to the Internet via a T3 or + better, it may be prudent to manually override both + <varname>rtexpire</varname> and <varname>rtminexpire</varname> + via &man.sysctl.8;. Never set either parameter to zero (unless + you want to crash the machine). Setting both + parameters to 2 seconds should be sufficient to protect the route + table from attack.</para> + </sect2> + + <sect2> + <title>Access Issues with Kerberos and SSH</title> + + <indexterm><primary><command>ssh</command></primary></indexterm> + <indexterm><primary>KerberosIV</primary></indexterm> + + <para>There are a few issues with both Kerberos and + ssh that need to be addressed if + you intend to use them. Kerberos 5 is an excellent + authentication protocol, but there are bugs in the kerberized + <application>telnet</application> and + <application>rlogin</application> applications that make them + unsuitable for dealing with binary streams. Also, by default + Kerberos does not encrypt a session unless you use the + <option>-x</option> option. <application>ssh</application> + encrypts everything by default.</para> + + <para>Ssh works quite well in every respect except that it forwards + encryption keys by default. <!--TODO: ma non è vero!??--> What + this means is that if you have a secure workstation holding keys + that give you access to the rest of the system, and you + ssh to an insecure machine, your keys + 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 + insecure machine he can utilize that port to use your keys to gain + access to any other machine that your keys unlock.</para> + + <para>We recommend that you use ssh in + combination with Kerberos whenever possible for staff logins. + <application>Ssh</application> can be compiled with Kerberos + support. This reduces your reliance on potentially exposed + ssh keys while at the same time + protecting passwords via Kerberos. Ssh + keys should only be used for automated tasks from secure machines + (something that Kerberos is unsuited to do). We also recommend that + you either turn off key-forwarding in the + ssh configuration, or that you make use + of the <literal>from=IP/DOMAIN</literal> option that + ssh allows in its + <filename>authorized_keys</filename> file to make the key only + usable to entities logging in from specific machines.</para> + </sect2> + + </sect1> + + + <sect1 id="crypt"> + <sect1info> + <authorgroup> + <author> + <firstname>Bill</firstname> + + <surname>Swingle</surname> + + <contrib>Parti riscritte e aggiornate da </contrib> + </author> + </authorgroup> + </sect1info> + + <title>DES, MD5 e Crypt</title> + + <indexterm> + <primary>sicurezza</primary> + <secondary>crypt</secondary> + </indexterm> + + <indexterm><primary>crypt</primary></indexterm> + <indexterm><primary>DES</primary></indexterm> + <indexterm><primary>MD5</primary></indexterm> + + <para>Ogni utente su un sistema &unix; ha una password associata con il + proprio account. È pvviamente necessario che queste password siano + note solamente all'utente e al sistema operativo vero e proprio. Per + poter mantenere segrete queste password, sono cifrate con quello che si + chiama un <quote><!--TODO-->one-way hash</quote>, ovvero possono essere + facilmente cifrate ma non decifrate. In altre parole, quel che poco fa + abbiamo dato per ovvio non è neanche vero: il sistema operativo in + sé non conosce <emphasis>realmente</emphasis> la password, conosce + soltanto la forma <emphasis>cifrata</emphasis> della password. L'unico + modo per ricavare la password <emphasis>in chiaro</emphasis> è una + brutale ricerca nell'intero spazio delle password possibili.</para> + + <para>Sfortunatamente l'unico modo sicuro di cifrare le password quando + &unix; è nato era di utilizzare DES (Data Encryption Standard). + Questo non era un grosso problema per gli utenti residenti in USA, ma dato + che il codice sorgente riguardante DES non poteva essere esportato al di + fuori degli USA, &os; ha dovuto cercare un modo per poter + contemporaneamente essere in regola con la legge USA e mantenere la + compatibilità con tutte le altre varianti &unix; che ancora + utilizzavano DES.</para> + + <para>La soluzione è stata quella di suddividere le librerie di + cifratura in modo tale che gli utenti USA potessero installare le librerie + DES ed utilizzarlo ma gli utenti internazionali avessero comunque a + disposizioni metodi crittografici che potessero essere esportati + all'estero. Questo è il modo in cui &os; adottò MD5 come + metodo di cifratura di default. MD5 è considerato più + sicuro di DES, quindi installare DES è una possibilità + pensata principalmente per motivi di compatibilià.</para> + + <sect2> + <title>Riconoscere il funzionamento del tuo crypt</title> + + <para>Attualmente la libreria supporta gli algoritmi DES, MD5 e Blowfish. + Per default &os; utilizza MD5 per cifrare le password.</para> + + <para>È piuttosto semplice identificare il tipo di cifratura + utilizzato; ad esempio uno dei metodi è di leggere il file + <filename>/etc/master.passwd</filename>. Le password cifrate con l'hash + MD5 sono più lunghe e iniziano con i caratteri + <literal>$1$</literal>. Le password che iniziano con + <literal>$2a$</literal> sono cifrate con Blowfish. + Le password DES non hanno alcun carattere identificativo particolare, ma + sono più corte e sono codificate in un alfabeto di 64 caratteri + che non include il <literal>$</literal>, quindi una stringa + relativamente corta che non inizia con un simbolo di dollaro è + molto probabilmente una password DES.</para> + + <para>Il formato utilizzato per le nuove password è deciso dal + valore del campo <literal>passwd_format</literal> nel file + <filename>/etc/login.conf</filename>, che può avere i valori di + <literal>des</literal>, <literal>md5</literal> oo + <literal>blf</literal>. Fai riferimento alla pagina del manuale + &man.login.conf.5; per avere ulteriori informazioni sulle configurazioni + di login.</para> + </sect2> + </sect1> + + <sect1 id="one-time-passwords"> + <title>Password One-time</title> + + <indexterm><primary>one-time passwords</primary></indexterm> + <indexterm> + <primary>security</primary> + <secondary>one-time passwords</secondary> + </indexterm> + + <para>Per default &os; include il supporto per OPIE (One-time Passwords + In Everything), configurato per utilizzare l'hash MD5.</para> + + <para>Ci sono tre tipi di diverse password di cui parleremo in seguito. Le + prime sono le normali pasword &unix; o Kerberos, che verranno chiamate + <quote>password &unix;</quote>. Il secondo tipo sono le password one-time + generate dal programma OPIE &man.opiekey.1; e accettate dal programma + &man.opiepasswd.1; e dal prompt di login, che chiameremo + <quote>password one-time</quote>. L'ultimo tipo di password è la + password segreta che darai al programma <command>opiekey</command> (e + qualche volte al programma <command>opiepasswd</command>) e che viene + utilizzata per generare le password one-time, che chiameremo + <quote>password segreta</quote> o più semplicemente + <quote>password</quote>.</para> + + <para>La password segreta non ha niente a che vedere con la password &unix;; + possono essere uguali ma questo è sconsigliato. Le password + segrete di OPIE non sono limitate a 8 caratteri come le vecchie password + &unix;<footnote><para>In &os; le normali password di login possono essere + lunghe fino a 128 caratteri.</para></footnote>, possono essere lunghe + quanto ti pare. Sono abbastana diffuse password composte da frasi di sei + o sette parole. Per la maggior parte, il sistema OPIE funziona in modo + totalmente indipendente dal sistema di password &unix;.</para> + + <para>Oltre alla password, ci sono altre due informazioni utili a OPIE. Una + è nota come <quote>seme</quote> o <quote>chiave</quote> e consiste + di due lettere e cinque numeri. L'altra è nota come + <quote>numero di iterazioni</quote> ed è un valore tra 1 e 100. + OPIE crea la password one-time concatenando il seme e la password segreta + ed applicandovi l'hash MD5 tante volte quanto specificate dal numero di + iterazioni, trasformando poi il risultato in sei corte parole inglesi, che + saranno la tua password one-time. Il sistema di autenticazione + (principalmente PAM) mantiene traccia dell'ultima password one-time usata + e autentica l'utente se l'hash della password fornita dall'utente + è uguale alla password precedente. Dato che viene usato un hash, + ovvero una funzione matematica a senso unico + <!--TODO:non invertibile? "Because a one-way hash is used"--> + è impossibile generare password one-time future se viene catturata + una password durante il suo utilizzo; il numero di iterazioni viene + decrementato dopo un login avvenuto con successo per mantenere l'utente e + il programma di login in sincrono. Quando il numero di iterazioni scende + a 1, OPIE deve essere reinizializzato.</para> + + <para>Nelle seguenti spiegazioni si farà riferimento a vari + programmi: il programma <command>opiekey</command> richiede un numero di + iterazioni, un seme e una password segreta e genera una password one-time + o una lista di password one-time consecutive; il programma + <command>opiepasswd</command> viene utilizzato per inizializzzare OPIE e + per cambiare password, numeri di iterazioni, semi e password one-time; il + programma <command>opieinfo</command> analizza i file di credenziali + (<filename>/etc/opiekeys</filename>) e stampa il numero di iterazioni + e il seme correnti dell'utente che lo richiama.</para> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="tcpwrappers"> + <title>TCP Wrappers</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="kerberosIV"> + <title><application>KerberosIV</application></title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="kerberos5"> + <title><application>Kerberos5</application></title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="openssl"> + <title>OpenSSL</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="ipsec"> + <title>IPsec</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="openssh"> + <title>OpenSSH</title> + + <sect2 id="security-ssh-tunneling"> + <title>SSH Tunneling</title> + + <para>Traduzione in corso</para> + </sect2> + </sect1> + + <sect1 id="fs-acl"> + <title>File System Access Control Lists</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="security-portaudit"> + <title>Monitoring Third Party Security Issues</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="security-advisories"> + <title>&os; Security Advisories</title> + + <para>Traduzione in corso</para> + </sect1> + + <sect1 id="security-accounting"> + <title>Process Accounting</title> + + <para>Traduzione in corso</para> + </sect1> +</chapter> |