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 | 1191 |
1 files changed, 0 insertions, 1191 deletions
diff --git a/it_IT.ISO8859-15/books/handbook/security/chapter.xml b/it_IT.ISO8859-15/books/handbook/security/chapter.xml deleted file mode 100644 index 4a94b0d5f0..0000000000 --- a/it_IT.ISO8859-15/books/handbook/security/chapter.xml +++ /dev/null @@ -1,1191 +0,0 @@ -<?xml version="1.0" encoding="iso-8859-15"?> -<!-- - The FreeBSD Italian Documentation Project - - $FreeBSD$ - Original revision: 1.312 ---> -<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><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> - </info> - - - - <indexterm><primary>security</primary></indexterm> - - <sect1 xml: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 xml: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 <systemitem class="username">root</systemitem> (<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 - <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 <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 - 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 <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 <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 <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 - <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 - <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à - 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 <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 - <systemitem class="username">root</systemitem>.</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 xml: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 xml:id="securing-root-and-staff"> - <title>Rendere sicuro <systemitem class="username">root</systemitem> 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 <systemitem class="username">root</systemitem>. La - maggior parte dei sistemi hanno una password assegnata per l'account - <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 - 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 - <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 <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 — - servizi come ad esempio FTP vengono spesso trascurati. Login - <systemitem class="username">root</systemitem> diretti dovrebbero essere permessi solo - tramite la console di sistema.</para> - - <indexterm> - <primary><systemitem class="groupname">wheel</systemitem></primary> - </indexterm> - - <para>Ovviamente, come sysadmin (amministratore di sistema) hai bisogno - 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 - <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 - <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 - <systemitem class="groupname">wheel</systemitem> mettendoli in quel gruppo nel file - <filename>/etc/passwd</filename>; dovresti metterli nel gruppo - <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 <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, ` quella di utilizzare il file - <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 - <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 <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 <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 - <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 - <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 <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 - 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 <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 - <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 - <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 - <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 <systemitem class="username">root</systemitem> sono - occasionalmente trovate anche in questi. Nel 1998 è stata - trovata una falla da <systemitem class="username">root</systemitem> 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 <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 - 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 xml: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 - <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 - 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 - <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 - <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 <filename>bpf</filename>.</para> - - <indexterm> - <primary><command>sysctl</command></primary> - </indexterm> - - <para>Anche nel caso di aver disattivato il device - <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 - 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 xml: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 - <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> - (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 - <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> - - <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 xml:id="crypt"> - <info><title>DES, MD5 e Crypt</title> - <authorgroup> - <author><personname><firstname>Bill</firstname><surname>Swingle</surname></personname><contrib>Parti riscritte e aggiornate da </contrib></author> - </authorgroup> - </info> - - - - <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 xml: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 xml:id="tcpwrappers"> - <title>TCP Wrappers</title> - - <para>Traduzione in corso</para> - </sect1> - - <sect1 xml:id="kerberosIV"> - <title><application>KerberosIV</application></title> - - <para>Traduzione in corso</para> - </sect1> - - <sect1 xml:id="kerberos5"> - <title><application>Kerberos5</application></title> - - <para>Traduzione in corso</para> - </sect1> - - <sect1 xml:id="openssl"> - <title>OpenSSL</title> - - <para>Traduzione in corso</para> - </sect1> - - <sect1 xml:id="ipsec"> - <title>IPsec</title> - - <para>Traduzione in corso</para> - </sect1> - - <sect1 xml:id="openssh"> - <title>OpenSSH</title> - - <sect2 xml:id="security-ssh-tunneling"> - <title>SSH Tunneling</title> - - <para>Traduzione in corso</para> - </sect2> - </sect1> - - <sect1 xml:id="fs-acl"> - <title>File System Access Control Lists</title> - - <para>Traduzione in corso</para> - </sect1> - - <sect1 xml:id="security-portaudit"> - <title>Monitoring Third Party Security Issues</title> - - <para>Traduzione in corso</para> - </sect1> - - <sect1 xml:id="security-advisories"> - <title>&os; Security Advisories</title> - - <para>Traduzione in corso</para> - </sect1> - - <sect1 xml:id="security-accounting"> - <title>Process Accounting</title> - - <para>Traduzione in corso</para> - </sect1> -</chapter> |