1191 lines
60 KiB
XML
1191 lines
60 KiB
XML
<?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>
|