Attachment 52023 Details for Bug 83148 – gentoo-security.xml

gentoo-security.xml

gentoo-security.xml (text/xml), 126.12 KB, created by Andrea Torelli on 2005-02-24 00:18:27 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Andrea Torelli

Created: 2005-02-24 00:18:27 UTC

Size: 126.12 KB

patch

obsolete

><?xml version='1.0' encoding='UTF-8'?>
>
>
><!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
><guide link = "/doc/it/gentoo-security.xml" lang="it">
><title>Gentoo Linux Security Guide</title>
><author title="Autore Originale">
>	<mail link="kn@insecurity.dk">Kim Nielsen</mail>
></author>
><author title="Aggiornamento">
>	John P. Davis
></author>
><author title="Aggiornamento">
>	<mail link="stocke2@gentoo.org">Eric R. Stockbridge</mail>
></author>
><author title="Aggiornamento">
>	<mail link="carl@gentoo.org">Carl Anderson</mail>
></author>
><author title="Aggiornamento">
>	<mail link="peesh@gentoo.org">Jorge Paulo</mail>
></author>
><author title="Redazione">
>	<mail link="swift@gentoo.org">Sven Vermeulen</mail>
></author>
><author title="Redazione">
>	<mail link="bennyc@gentoo.org">Benny Chuang</mail>
></author>
><author title="Redazione">
>	<mail link="jaervosz@itu.dk">Sune Jeppesen</mail>
></author>
><author title="Redazione">
>	<mail link="blubber@gentoo.org">Tiemo Kieft</mail>
></author>
><author title="Redazione">
>	<mail link="klasikahl@gentoo.org">Zack Gilburd</mail>
></author>
><author title="Editor">
>	<mail link="krispykringle@gentoo.org">Dan Margolis</mail>
></author>
><author title="Traduzione">
>	<mail link="gentoo@virgilio.it">Shev</mail>
></author>
><author title="Traduzione">
>	<mail link="toro2k@quipo.it">Andrea Torelli</mail>
></author>
>
>
><abstract>
>Questa Ã¨ una guida passo-passo per rafforzare la sicurezza (ndt, quello che in gergo si chiama "hardening") di un sistema Gentoo Linux.
></abstract>
>
><license/>
>
><version>0.4.44</version>
><date>14 Febbraio 2005</date>
>
>
><chapter>
><title>Introduzione</title>
><section>
><body>
>
><p>
>Questa guida Ã¨ stata scritta per coloro che stanno utilizzando Gentoo Linux in un ambiente server e/o che sentono il bisogno di aumentarne la sicurezza.
></p>
>
><note>
>Se siete interessati a rendere ancor piÃ¹ sicura la vostra Gentoo, dopo aver letto questa guida allora date un'occhiata allo <uri link="http://www.gentoo.org/proj/en/hardened/">Hardened Gentoo Project</uri>
></note>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Concetti Pre-Installazione</title>
><section>
><title>Sicurezza Fisica</title>
><body>
>
><p>
>Non importa quante misure di sicurezza implementiate, possono facilmente essere aggirate qualora l'attaccante guadagni l'accesso fisico alla vostra macchina. Dovete essere sicuri che il vostro hardware non sia facilmente accessibile. Per esempio, potreste mettere la vostra macchina in una stanza chiusa a chiave. Anche sigillare il case Ã¨ una buona idea. Per un livello di sicurezza ancora maggiore potreste configurare il BIOS per limitare il boot al solo disco rigido. E disabilitare il boot da floppy o cdrom. Per i paranoici, Ã¨ una buona idea abilitare la password per accedere alle impostazioni del BIOS. Quest'ultima puÃ² essere una scelta saggia anche per gli utenti che usano portatili. E' anche importante impostare una password per LILO o GRUB per evitare che un utente malintenzionato possa avviare il sistema in modalitÃ¡ monoutente, ottenendone il completo controllo. Questo argomento Ã© spiegato piÃº in dettaglio nel Capitolo 3 nei paragrafi <uri link="#passwording_GRUB">Password di GRUB</uri> e <uri link="#passwording_LILO">Password di LILO</uri>.
></p>
>
></body>
></section>
>
><section>
><title>Pianificare Demoni/Servizi</title>
><body>
>
><p>
>Documentatevi su quali servizi debbano girare sulla macchina o che supponete debbano girarvi. Questo vi aiuterÃ  a studiare un buono schema per le partizioni da creare sul sistema e a pianificare meglio le misure di sicurezza da adottare. Naturalmente se possedete soltanto una macchina, o comunque poche, o siete i soli a servirvene non sarÃ  necessario preoccuparsi di ciÃ². Es.: se il computer Ã¨ destinato a fungere da firewall non dovrÃ  girare su di esso <e>nessun</e> servizio ad eccezione di sshd.
></p>
>
><p>
>Prendete nota dei numeri di versione di tutti i demoni che girano sulla vostra macchina. Questo permette di mantenere il sistema aggiornato nel caso vengano scoperti bug sfruttabili in remoto in uno dei vostri demoni.</p>
>
></body>
></section>
>
><section>
><title>Schema delle Partizioni</title>
><body>
>
><p>
>Regole di partizionamento:
></p>
>
><ul>
>
><li>
>Ogni albero di directory sul quale un utente puÃ² scrivere ( Es. <path>/home</path>, <path>/tmp</path> e <path>/var</path>), dovrebbe risiedere in una partizione separata e fare uso di quote disco. Questo accorgimento riduce il rischio che un utente possa riempire l'intero file system. Portage usa <path>/var/tmp</path> per compilare i file, quindi la partizione dovrebbe essere abbastanza grande. 
></li>
>
><li>
>Ogni albero di directory in cui si prevede di installare software opzionale dovrebbe risiedere in una partizione separata. In accordo con il <uri link="http://www.pathname.com/fhs/">File Hierarchy Standard</uri>, questa dovrebbe essere <path>/opt</path> o <path>/usr/local</path>. Se queste sono partizioni separate, non verranno cancellate in caso di reinstallazione del sistema.
></li>
>
><li>
>Provate a spostare i dati statici nelle loro partizioni e montarle in modalitÃ  di sola lettura. Se siete realmente 
>paranoici potreste provare a memorizzare i dati statici su supporti di sola lettura come i cdrom.
></li>
>
></ul>
></body>
></section>
>
><section>
><title>L'utente root</title>
><body>
><p>
>L'utente 'root' Ã¨ l'utente piÃ¹ importante del sistema e non dovrebbe essere usato se non per pura necessitÃ . Se un attaccante dovesse ottenere l'accesso come root, il sistema sarebbe da considerarsi permanentemente compromesso, e l'unico modo per ottenere un sistema nuovamente sicuro sarebbe la reinstallazione.
></p>
>
><p>
>Regole d'oro riguardanti 'root'
></p>
>
><ul>
>
><li>
>Create sempre un utente per uso quotidiano e se questi necessitasse di avere l'accesso con privilegi di root, aggiungetelo al gruppo <c>wheel</c>. Questo rende possibile ad un utente normale ottenere i previlegi di root tramite il comando <c>su</c>.
></li>
>
><li>
>Non eseguite mai X o qualsiasi altra applicazione utente come root. L'utente root non va utilizzato 
>se non strettamente necessario. Qualora un'applicazione che gira con previlegi di utente contenesse una qualche vulnerabilitÃ¡, un eventuale attaccante potrebbe ottenere i previlegi dell'utente che sta facendo girare l'applicazione. Se invece l'applicazione fosse stata avviata da root l'attaccante otterrebbe i previlegi di root.
></li>
>
><li>
>Usate sempre percorsi assoluti quando accedete come root, oppure utilizzate il comando<c>su -</c> che fa in modo che le variabili d'ambiente dell'utente vengano sostituite con quelle di root, questo fa si che root utilizzi una variabile <c>PATH</c> che contenga solo directory sicure quali per esempio <path>/bin</path> o <path>/sbin</path>. E' possibile ingannare root facendogli eseguire applicazioni diverse da quelle che vorrebbe, usando solo percorsi assoluti o usando una variabile <c>PATH</c> sicura questo non puÃ² succedere.
></li>
>
><li>
>Se un utente ha bisogno solo di pochi comandi anzichÃ¨ di tutti quelli che root ha normalmente a disposizione, prendete in considerazione l'uso di <c>sudo</c>, ma con la dovuta cautela!
></li>
>
><li>
>Non lasciate mai il terminale quando siete loggati come root.
></li>
>
></ul>
>
><p>
>Gentoo possiede una protezione generale contro il cambio da utente normale a root <c>su</c>. 
>La configurazione di default di PAM prevede infatti che un normale utente debba far parte del gruppo <c>wheel</c> per poter diventare root.
></p>
>
></body>
></section>
>
><section id = "security_policies">
><title>Politiche di sicurezza</title>
><body>
>
><p>
>Vi sono diversi motivi per cui le politiche di sicurezza sono necessarie.
></p> 
>
><ul>
>
><li>
>Una buona politica di sicurezza consente di definire con precisione e coerenza quali misure di sicurezze valga la pena prendere e quali invece no. Per esempio, in mancanza di una politica, un amministratore potrebbe decidere di eliminare il servizio telnet da un sistema, in quanto trasmette password non cifrate, e invece mantenere l'accesso tramite FTP, che ha lo stesso difetto.
></li>
>
><li>
>E' quasi impossibile scoprire un potenziale attaccante, risolvere problemi di rete o condurre prove di audit senza spiare il traffico di rete o dare un'occhiata a directory home private, e spiare senza il consenso dell'utente Ã¨ illegale in molti paesi. Inoltre poichÃ¨ circa il 60% degli attacchi proviene dall'interno delle organizzazioni, Ã¨ importante tenere sempre gli occhi aperti.
></li>
>
><li>
>Una delle principali minacce per la sicurezza Ã© rappresentata da account con password compromesse. Se non si spiega agli utenti qual'Ã© l'importanza della sicurezza e come mantenerla (per esempio non scrivendo password e lasciandole sulla propria scrivania), ci sono poche probabilitÃ¡ di avere degli ccount sicuri.
></li>
>
><li>
>Una buona documentazione rigurdante la rete e il sistema Ã© di grande aiuto nel caso si debbanno tracciare intrusioni o individuare debolezze dopo aver subito un attacco, sia per se stessi, sia eventualmente per le forze dell'ordine. Esporre un avviso sopra al prompt di login (ndt, issue banner), dove si evidenzia che non Ã© concesso l'accesso senza autorizzazione, dovrebbe rendere piÃº facile perseguire un eventuale intruso qualora venisse identificato.
></li>
>
></ul>
>
><p>
>Questo dovrebbe chiarire perchÃ© Ã¨ importante creare politiche sui sistemi che hanno piÃ¹ di un utente e perchÃ¨ Ã¨ importante educare gli utenti stessi.
></p>
>
><p>
>Una politica Ã¨ un documento, o piÃ¹ documenti, che descrive le caratteristiche della rete e del sistema (Es. i servizi offerti), cosa Ã© permesso e cosa non Ã© permesso fare, come deve essere mantunata la sicurezza e cose simili. E' importante che vi prendiate del tempo per aiutare gli utenti a capire la politica, capire perchÃ© Ã¨ necessario firmarla o cosa accadrebbe se agissero direttamente contro di essa (la politica dovrebbe prevedere anche questo). Tutto questo dovrebbe essere ripetuto almeno una volta all'anno, dato che la politica puÃ² essere soggetta a modifiche, ma anche perchÃ¨ Ã¨ sempre meglio ricordare certe cose.
></p>
>
><note>
>Create politiche che siano facili da leggere e veramente chiare/specifiche su ciascun argomento trattato.
></note>
>
><p>
>Una politica di sicurezza dovrebbe contenere almeno i seguenti argomenti:
></p>
>
><p>Utilizzo consentito.</p>
><ul>
>  <li>Screen savers.</li>
>  <li>Password.</li>
>  <li>Download di software e sua installazione.</li>
>  <li>Informazioni relative al caso in cui l'utente venga monitorato.</li>
>  <li>Software anti-virus.</li>
></ul>
>
><p>Gestione di informazioni sensibili (in qualsiasi forma scritta, sia cartacea 
>che digitale).
></p>
><ul>
>  <li>Pulire la scrivania e chiudere a chiave le informazioni classificate.</li>
>  <li>Spegnere il computer prima di lasciare il lavoro.</li>
>  <li>Usare la crittografia.</li>
>  <li>Come gestire le chiavi di collaboratori fidati.</li>
>  <li>Come gestire materiale riservato in viaggio.</li>
></ul>
>
><p>Gestione del materiale informatico in viaggio.</p>
><ul>
>    <li>Come gestire portatili durante viaggi e permanenze in hotel.</li>
></ul>
>
><p>
>Differenti tipologie di utenti potebbero richiedere differenti livelli di accesso al sistema, la politica deve tenere conto anche di questa eventualitÃ¡.
></p>
>
><p>
>La politica di sicurezza puÃ² diventare enorme e di conseguenza informazioni vitali potrebbero venire facilmente dimenticate. La politica dello staff IT dovrebbe contenere informazioni che sono ritenute classificate per gli utenti ordinari, quindi potrebbe essere saggio suddividerla in politiche piÃ¹ piccole; p.e. Politica di ciÃ² che Ã¨ concesso usare, Politica delle Password, Politica delle email, Politica per l'accesso remoto.
></p>
>
><p>
>Si possono trovare esempi di policies su <uri link="http://www.sans.org/resources/policies/">The 
>SANS Security Policy Project</uri>. Se avete una piccola rete e pensate che queste politiche siano eccessive per voi date un'occhiata al <uri link="http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2196.html">Site Security Handbook</uri>.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Rinforzare la sicurezza durante e dopo l'installazione</title>
><section>
><title>Flags USE</title>
><body>
>
><p>
>Il file <path>make.conf</path> contiene le flags USE definite dall'utente e <path>/etc/make.profile/make.defaults</path> contiene le flags USE di default per Gentoo Linux. Per gli scopi che si prefigge questa guida risultano importanti le flags <c>pam</c> (Pluggable Authentication Modules), <c>tcpd</c> (TCP wrappers) e <c>ssl</c> (Secure Socket Layer). Questa flags sono tutte comprese nelle USE di default.
></p>
>
></body>
></section>
>
><section id = "passwording_GRUB">
><title>Password di GRUB</title>
><body>
>
><p>
>Grub supporta due differenti modi di aggiungere password per restringere l'accesso ai suoi file di configurazione (<path>/boot/grub/grub.conf</path>). Il primo metodo prevede l'uso di password testuali in chiaro e il secondo crittografate con md5+salt.
></p>
>
><pre caption="/boot/grub/grub.conf">
>timeout 5
>password changeme
></pre>
>
><p>
>Questo aggiungerÃ  la password <c>changeme</c>, se non viene inserita alcuna password verrÃ  semplicemente usata la configurazione di default.
></p>
>
><p>
>Per aggiungere una password md5, dovrete convertire la password in un formato cifrato, che ha lo stesso formato del file <path>/etc/shadow</path>. Per maggiori informazioni leggete <c>man crypt</c>. La password <e>changeme</e> cifrata dovrebbe apparire simile a $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
></p>
>
><p>
>O altrimenti potete convertirla direttamente nella shell di grub:
></p>
>  	 
><pre caption="md5crypt nella shell di grub">
>#<i>/sbin/grub</i>
> 	 
>GRUB  version 0.92  (640K lower / 3072K upper memory)
>  	 
>  [ Minimal BASH-like line editing is supported.  For the first word, TAB
>  lists possible command completions.  Anywhere else TAB lists the possible
>  completions of a device/filename. ]
>  	 
>grub> <i>md5crypt</i>
>  	 
>Password: <i>********</i>
><codenote>Digitate changeme</codenote>
>Encrypted: $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
>  	 
>grub> <i>quit</i>
></pre>
>  	 
><p>
>Quindi copiate e incollate la vostra password in <path>/boot/grub/grub.grub</path>.
></p>
>
><pre caption="/boot/grub/grub.conf">
>timeout 5
>password --md5 $1$T7/dgdIJ$dJM.n2wZ8RG.oEiIOwJUs.
></pre>
>
><note>N.d.T: la password cifrata si riferisce a <e>changeme</e>, se usate il tool <c>grub-md5-crypt</c> dovrete sostituirla con l'output del comando.
></note>
>
>
><p>
>Un timeout di 5 secondi risulta molto comodo se il sistema Ã¨ remoto e deve potersi riavviare senza alcuna interazione con la tastiera. Maggiori informazioni sulle password in Grub possono essere trovate eseguendo <c>info grub</c>.
></p>
>
></body>
></section>
>
><section id = "passwording_LILO">
><title>Password di GRUB</title>
><body>
>
><p>
>Anche LILO supporta due modalitÃ  di utilizzo delle password: globale e per immagine, entrambe con testo in chiaro.
></p>
>
><p>
>Nella modalitÃ  globale la password deve essere impostata all'inizio del file di configurazione e viene applicata a tutte le immagini.
></p>
>
><pre caption="/etc/lilo.conf">
>password=changeme
>restricted
>delay=3
></pre>
>
><p>
>In alternativa Ã¨ possibile aggiungerla solamente ad un'immagine.
></p>
>
><pre caption="/etc/lilo.conf">
>image=/boot/bzImage
>      read-only
>      password=changeme
>      restricted
></pre>
>
><p>
>Se l'opzione <c>restricted</c> Ã¨ omessa, verrÃ  richiesto l'inserimento della password ad ogni riavvio.
></p>
>
><p>
>Per rendere effettive le nuove impostazioni in <path>lilo.conf</path> dovrete eseguire il comando 
><c>/sbin/lilo</c>.
></p>
>
></body>
></section>
>
><section>
><title>Limitare l'uso della Console</title>
><body>
><p>
>Il file <path>/etc/securetty</path> vi permette di specificare su quali device <c>TTY</c> (terminali) Ã¨ permesso il login di root.
></p>
>
><p>
>Suggeriamo di commentare tutte le linee eccetto <c>vc/1</c>. Questo assicurerÃ  che root possa effettuare il login solo su questo terminale.
></p>
>
><note>
>Gli utenti nel gruppo wheel possono dare <c>su -</c> per diventare root nelle altre TTY.
></note>
>
><pre caption="/etc/securetty">
>vc/1
></pre>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Log (Registrazioni) piÃ¹ completi</title>
><section>
><body>
>
><p>
>Per scoprire errori o warnings che potrebbero riferirsi ad un attacco in corso o ad una compromissione giÃ  avvenuta, dovrebbero essere aggiunti log piÃ¹ approfonditi. Gli attaccanti spesso eseguono una scansione o sondano le reti prima di attaccarle.
></p>
>
><p>
>E' inoltre vitale che i file di log siano facilmente leggibili e manutenibili. Gentoo Linux, durante la fase di installazione, vi permette di scegliere tra 3 differenti sistemi di log.
></p>
></body>
></section>
>
><section>
><title>Syslogd</title>
><body>
>
><p>
>Syslogd Ã¨ il piÃ¹ comune sistema di log per Linux e Unix in generale. Non provvede alla rotazione dei log. Tale funzione viene gestita eseguendo <path>/usr/sbin/logrotate</path> in un job di cron e configurandolo in <path>/etc/logrotate.conf</path>. Quanto spesso debba essere fatta la rotazione dipende dal carico di lavoro del sistema.
></p>
>
><p>
>Quello che segue Ã¨ il file <path>syslog.conf</path> standard con alcune funzionalitÃ  aggiuntive. Abbiamo decommentato le linee <c>cron</c> e <c>tty</c> e aggiunto un server per il loggin remoto. Per aumentare ulteriormente la sicurezza potreste aggiungere il log su due posti diversi.
></p>
>
><pre caption="/etc/syslog.conf">
>#  /etc/syslog.conf     Configuration file for syslogd.
>#
>#                       For more information see syslog.conf(5)
>#                       manpage.
>#                       This is from Debian, we are using it for now
>#                       Daniel Robbins, 5/15/99
>
>#
># First some standard logfiles.  Log by facility.
>#
> 	 
>auth,authpriv.*                 /var/log/auth.log
>*.*;auth,authpriv.none          -/var/log/syslog
>cron.*                     			/var/log/cron.log
>daemon.*                        -/var/log/daemon.log
>kern.*                          -/var/log/kern.log
>lpr.*                           -/var/log/lpr.log
>mail.*                     			/var/log/mail.log
>user.*                          -/var/log/user.log
>uucp.*                          -/var/log/uucp.log
>local6.debug                    /var/log/imapd.log
>
>#
># Logging for the mail system. Split it up so that
># it is easy to write scripts to parse these files.
>#
>mail.info                       -/var/log/mail.info
>mail.warn                       -/var/log/mail.warn
>mail.err                        /var/log/mail.err
>
># Logging for INN news system
>#
>news.crit                       /var/log/news/news.crit
>news.err                        /var/log/news/news.err
>news.notice                     -/var/log/news/news.notice
>  	 
>#
># Some `catch-all' logfiles.
>#
>*.=debug;\
>        auth,authpriv.none;\
>        news.none;mail.none     -/var/log/debug
>*.=info;*.=notice;*.=warn;\
>        auth,authpriv.none;\
>        cron,daemon.none;\
>        mail,news.none          -/var/log/messages
>  	 
>#
># Emergencies and alerts are sent to everybody logged in.
>#
>*.emerg                         *
>*.=alert                        *
>  	 
>#
># I like to have messages displayed on the console, but only on a virtual
># console I usually leave idle.
>#
>daemon,mail.*;\
>       news.=crit;news.=err;news.=notice;\
>       *.=debug;*.=info;\
>       *.=notice;*.=warn       /dev/tty8
>
>#Setup a remote logging server
>*.*                        @logserver
>
># The named pipe /dev/xconsole is for the `xconsole' utility.  To use it,
># you must invoke `xconsole' with the `-file' option:
>#
>#    $ xconsole -file /dev/xconsole [...]
>#
># NOTE: adjust the list below, or you'll go crazy if you have a reasonably
>#      busy site..
>#
>#daemon.*,mail.*;\
>#       news.crit;news.err;news.notice;\
>#       *.=debug;*.=info;\
>#       *.=notice;*.=warn       |/dev/xconsole
>  	 
>local2.*                --/var/log/ppp.log
></pre>
>
><p>
>Un attaccante molto probabilmente proverÃ  a cancellare ogni sua traccia modificando o cancellando i file di log. Potete rendergli la vita difficile loggandolo in uno o piÃ¹ logging server su macchine differenti. Per maggiori informazioni su syslogd eseguite <c>man syslog</c>.
></p>
>
></body>
></section>
>
><section>
><title>Metalog</title>
><body>
>
><p>
><uri link="http://metalog.sourceforge.net">Metalog</uri> di Frank Dennis non puÃ² inviare i log a server remoti,ma mostra tutti suoi pregi quando si bada alla flessibilitÃ  e alla velocitÃ  di logging.
>PuÃ² fare il logging a seconda del nome del programma, urgenza, facility (come syslogd) e inoltre supporta l'interpretazione di espressioni regolari e l'esecuzione di script esterni quando rileva determinati pattern. Davvero comodo per intraprendere determinate azioni quando necessario. 
></p> 
>
><p>
>La configurazione standard Ã¨ fondamentalmente sufficente. Se volete essere avvertiti via email ogni volta che avviene un errato inserimento di una password usate uno dei seguenti scripts.
></p>
>
><p>
>Per postfix:
></p>
>
><pre caption = "/usr/local/sbin/mail_pwd_failures.sh per postfix">
>#! /bin/sh
>echo "$3" | mail -s "Warning (program : $2)" root
></pre>
>
><p>
>Per qmail:
></p>
>
><pre caption = "/usr/local/sbin/mail_pwd_failures.sh per qmail">
>#!/bin/sh
>echo "To: root
>Subject:Failure (Warning: $2) 
>$3
>" | /var/qmail/bin/qmail-inject -f root
></pre>
>
><p>
>Ricordatevi di rendere lo script eseguibile dando <c>/bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh</c>	
></p>
>
><p>
>Quindi decommentate la linea di comando sotto "Password failures" in <path>/etc/metalog/metalog.conf</path> cosÃ¬:
></p>	 
>
><pre caption="/etc/metalog/metalog.conf">
>command  = "/usr/local/sbin/mail_pwd_failures.sh"
></pre>
>
></body>
></section>
><section>
>
><title>Syslog-ng</title>
><body>
>
><p>
>Syslog-ng fornisce parte delle caratteristiche di syslogd e di metalog, con alcune piccole differenze. PuÃ² filtrare i messaggi basandosi su livello e contenuto (come metalog), fornisce la possibilitÃ  di logging remoto come syslog, puÃ² gestire log provenienti da syslogd (come flussi di log provenienti da Solaris), scrivere su una TTY, eseguire programmi e agire da logging server. Fondalmente unisce il meglio di entrambi i programmi di log precedenti fondendolo con un'avanzata 
>configurazione.
></p>
>
><p>
>Un file di configurazione classico con alcune modifiche.
></p>
>
><pre caption="/etc/syslog-ng/syslog-ng.conf">
>options { long_hostnames(off); sync(0); };
>
># Sorgenti da cui leggere i log
>source src { unix-stream("/dev/log"); internal(); };
>source kernsrc { file("/proc/kmsg"); };
>
># Definisce le destinazioni
>destination authlog { file("/var/log/auth.log"); };
>destination syslog { file("/var/log/syslog"); };
>destination cron { file("/var/log/cron.log"); };
>destination daemon { file("/var/log/daemon.log"); };
>destination kern { file("/var/log/kern.log"); };
>destination lpr { file("/var/log/lpr.log"); };
>destination user { file("/var/log/user.log"); };
>destination mail { file("/var/log/mail.log"); };
>
>destination mailinfo { file("/var/log/mail.info"); };
>destination mailwarn { file("/var/log/mail.warn"); };
>destination mailerr { file("/var/log/mail.err"); };
>
>destination newscrit { file("/var/log/news/news.crit"); };
>destination newserr { file("/var/log/news/news.err"); };
>destination newsnotice { file("/var/log/news/news.notice"); };
>
>destination debug { file("/var/log/debug"); };
>destination messages { file("/var/log/messages"); };
>destination console { usertty("root"); };
>destination console_all { file("/dev/tty12"); };
>destination xconsole { pipe("/dev/xconsole"); };
>
># Crea filtri
>filter f_auth { facility(auth); };
>filter f_authpriv { facility(auth, authpriv); };
>filter f_syslog { not facility(authpriv, mail); };
>filter f_cron { facility(cron); };
>filter f_daemon { facility(daemon); };
>filter f_kern { facility(kern); };
>filter f_lpr { facility(lpr); };
>filter f_mail { facility(mail); };
>filter f_user { facility(user); };
>filter f_debug { not facility(auth, authpriv, news, mail); };
>filter f_messages { level(info..warn) 
>	and not facility(auth, authpriv, mail, news); };
>filter f_emergency { level(emerg); };
>
>filter f_info { level(info); };
>filter f_notice { level(notice); };
>filter f_warn { level(warn); };
>filter f_crit { level(crit); };
>filter f_err { level(err); };
>filter f_failed { match("failed"); };
>filter f_denied { match("denied"); };
>
># Collega filtri e destinazioni
>log { source(src); filter(f_authpriv); destination(authlog); };
>log { source(src); filter(f_syslog); destination(syslog); };
>log { source(src); filter(f_cron); destination(cron); };
>log { source(src); filter(f_daemon); destination(daemon); };
>log { source(kernsrc); filter(f_kern); destination(kern); };
>log { source(src); filter(f_lpr); destination(lpr); };
>log { source(src); filter(f_mail); destination(mail); };
>log { source(src); filter(f_user); destination(user); };
>log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
>log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
>log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };
>
>log { source(src); filter(f_debug); destination(debug); };
>log { source(src); filter(f_messages); destination(messages); };
>log { source(src); filter(f_emergency); destination(console); };
>
># Log di default
>log { source(src); destination(console_all); };
></pre>
>
><p>
>E' veramente facile da configurare ma Ã¨ altrettanto facile dimenticare qualcosa nel file di configurazione, viste le non indifferenti dimensioni di quest'ultimo. L'autore promette per il futuro alcune caratteristiche aggiuntive come crittografia, autenticazione, compressione e MAC (Mandatory Access Control). Con queste opzioni sarÃ  perfetto per il logging di rete, dato che un attaccante non potrÃ  spiare i log.
></p>
>
><p>
>E syslog-ng ha anche un altro vantaggio. Non deve essere eseguito come root!
></p>
>
></body>
></section>
>	 
><section>
><title>Analisi dei file di log con Logcheck</title>
><body>
>  	 
><p>
>Un'aaplicazione com Logcheck consente di effettuare un'analisi periodica dei file di log. Logcheck Ã© uno script, accompagnato dall'esguibile binario <c>logtail</c>, che controlla che nei file di log non ci siano tracce di attivitÃ¡ sospette, e alla fine dell'analisi invia i risultati alla casella di posta dell'amministratore.
></p>
>
><p>
>Logcheck e logtail fanno parte del pacchetto <c>app-admin/logsentry</c>.
></p>
>
><p>
>Logcheck usa quattro file per filtrare le informazioni piÃº significative dai file di log. Questi file sono <path>logcheck.hacking</path>, che contiene informazioni su tentativi di intrusione nel sistema, <path>logcheck.violations</path>, che contiene i pattern che indicano tentativi di violazione del sistema, <path>logcheck.violations.ignore</path>, che contiene pattern che potrebbero venire considerati come tentativi di intrusione ma in realtÃ¡ possono essere ignorati, e <path>logcheck.ignore</path>, che contiene i pattern che devono essere ignorati.
></p>
>  	 
><warn>
>Non lasciare il file <path>logcheck.violations.ignore</path> vuoto. Logcheck usa <c>grep</c> per la ricerca dei pattern nei file di log, alcune versioni di <c>grep</c> interpretano un file vuoto come una wildcard, cosicchÃ© ogni violazione verrebbe ignorata.
></warn>
>  	 
></body>
></section>
></chapter>
>
><chapter>
><title>Montare le partizioni</title>
><section>
>
><body>
>
><p>
>Quando montate una partizione <c>ext2</c>, <c>ext3</c> o <c>reiserfs</c>, avete diverse opzioni che potete utilizzare in <path>/etc/fstab</path>. Queste sono:
></p>
>
><ul>
>
><li>
><c>nosuid</c> - Ignora il bit SUID considerando tutti i file come ordinari.
></li>
>
><li>
><c>noexec</c> - Impedisce l'esecuzione di programmi in questa partizione.
></li>
>
><li>
><c>nodev</c> - Ignora i dispositivi (devices). 
></li>
></ul>
>
><p>
>Sfortunatamente questi parametri possono essere facilmente aggirati dall'esecuzione in path "non-diretti". Comunque settando <path>/tmp</path> come noexec verrÃ  fermatÃ² il 99% degli script kiddies, poichÃ¨ i loro exploits sono pensati per essere eseguiti direttamente da <path>/tmp</path>.
></p>
>
><pre caption="/etc/fstab">
>/dev/sda1 /boot ext2 noauto,noatime 1 1
>/dev/sda2 none swap sw 0 0
>/dev/sda3 / reiserfs notail,noatime 0 0
>/dev/sda4 /tmp reiserfs notail,noatime,nodev,nosuid,noexec 0 0
>/dev/sda5 /var reiserfs notail,noatime,nodev 0 0
>/dev/sda6 /home reiserfs notail,noatime,nodev,nosuid 0 0
>/dev/sda7 /usr reiserfs notail,noatime,nodev,ro 0 0
>/dev/cdroms /cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
>proc /proc proc defaults 0 0
></pre>
>
><warn>
>Impostando <path>/tmp</path> in modalitÃ  <c>noexec</c> Ã¨ possibile impedire la corretta esecuzione di certi script legittimi.
></warn>
>
><note>Le quote-disco vengono descritte in un altro capitolo.</note>
>
><note>
>Non ho impostato <path>/var</path> in modalitÃ  <c>noexec</c> o <c>nosuid</c> anche se normalmente qui non verrÃ  mai eseguito alcun file. La ragione di questa scelta Ã¨ che qmail viene installato in 
><path>/var/qmail</path> e deve avere il permesso di esecuzione e accesso per un file SUID.
>Ho configurato <path>/usr</path> in modalitÃ  read-only (sola lettura) dato che non scrivo mai nulla qui a meno che non voglia aggiornare Gentoo. In questo caso rimonto il file system in modalitÃ  read-write (lettura-scrittura), aggiorno il sistema e lo rimonto nuovamente con i permessi originali.
></note>
>
><note>
>Anche se non usate qmail, Gentoo necessita comunque di avere il bit di esecuzione in <path>/var/tmp</path> dato che gli ebuild vengono costruiti qui. Se siete decisi ad avere <path>/var</path> in modalitÃ  <c>noexec</c>, potreste pensare ad una directory alternativa per la compilazione degli ebuild.
></note>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Limitazioni User/group</title>
>
><section  id = "limits_conf">
><title>/etc/security/limits.conf</title>
><body>
>
><p>
>Avere il controllo dei limiti delle risorse puÃ² veramente aiutare nella prevenzione di Denial of Service locali o nella gestione del numero massimo di utenti o gruppi cui Ã¨ permesso collegarsi.
></p>
>
><pre caption="/etc/security/limits.conf">
>*    soft core      0
>*    hard core      0
>*    hard nproc     15
>*    hard rss       10000
>*    -    maxlogins 2
>@dev hard core      100000
>@dev soft nproc     20
>@dev hard nproc     35
>@dev -    maxlogins 10
></pre>
>
><p>
>Se vi trovaste a voler impostare <c>nproc</c> o <c>maxlogins</c> a 0, probabilmente fareste meglio ad eliminare questo utente. L'esempio qui sopra imposta le opzioni del gruppo <c>dev</c> per quanto riguarda processi, file core e <c>maxlogins</c>. Il resto viene mantenuto ai valori di default.
></p>
>
><note>
><path>/etc/security/limits.conf</path> fa parte del pacchetto PAM e sarÃ  applicabile solamente ai pacchetti che fanno uso di PAM.
></note>
>
>
></body>
></section>
>
><section>
><title>/etc/limits</title>
><body>
>
><p>
><path>/etc/limits</path> Ã¨ molto simile al file <path>/etc/security/limits.conf</path>. La sola differenza risiede nel formato e nel fatto che lavora solo su utenti e caratteri jolly (non sui gruppi). Questa Ã¨ una discreta configurazione:
></p>
>
><pre caption="/etc/limits">
>*   L2 C0 U15 R10000
>kn L10 C100000 U35
></pre>
>
><p>
>Qui abbiamo impostato i settaggi di default ed un'impostazione specifica per l'utente kn. Limits Ã¨ parte del pacchetto sys-apps/shadow. Non Ã¨ necessario impostare ogni limitazione in questo file se avete disabilitato <c>pam</c> in <path>make.conf</path> o non avete correttamente configurato PAM.
></p>
>
></body>
></section>
><section>
>
><title>Quote</title>
><body>
>
><warn>
>Assicuratevi che il filesystem con cui state lavorando supporti le quote. Per utilizzare le quote disco con il filesystem ReiserFS Ã© necessario applicare la patch prodotta da <uri link = "ftp://ftp.namesys.com/pub/reiserfs-for-2.4/testing/quota-2.4.20">Namesys</uri>. I tools per gestire le quote su ReiserFS sono disponibili sul sito del <uri link = "http://www.sf.net/projects/linuxquota/">Linux DiskQuota project</uri>. Utilizzare le quote disco con ReiserFS potrebbe comportare diversi problemi!
></warn>
>
><p>
>L'uso delle quote in un file system previene la saturazione del disco da parte degli utenti. Le quote vanno abilitate nel kernel ed aggiunte al mount point. Le opzioni del kernel da abilitare si trovano sotto <c>File systems->Quota support</c>. Abilitate le opzioni disponibili, ricompilate il kerne e riavviate il sistema utilizzando il nuovo kernel.
></p>
>
><p>
>Cominciate ad installare le quote con <c>emerge quota</c>. Quindi modificate il vostro <path>/etc/fstab</path>e aggiungete <c>usrquota</c> e <c>grpquota</c> alle partizioni per le quali volete sia ristretto l'utilizzo di spazio-disco come nell'esempio che segue.
></p>
>
><pre caption="/etc/fstab">
>/dev/sda1 /boot ext2 noauto,noatime 1 1
>/dev/sda2 none swap sw 0 0
>/dev/sda3 / reiserfs notail,noatime 0 0
>/dev/sda4 /tmp ext3 noatime,nodev,nosuid,noexec,usrquota,grpquota 0 0
>/dev/sda5 /var ext3 noatime,nodev,usrquota,grpquota 0 0
>/dev/sda6 /home ext3 noatime,nodev,nosuid,usrquota,grpquota 0 0
>/dev/sda7 /usr reiserfs noatime,nodev,ro	0 0
>/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
>proc /proc proc defaults 0 0
></pre>
>
><p>
>In ogni partizione per la quale avete abilitato le quote, create i file quota (<path>aquota.user</path> e <path>aquota.group</path>) posizionandoli nella radice (root) della partizione.
></p>
>
><pre caption="Creazione dei file quota">
># <i>touch /tmp/aquota.user</i>
># <i>touch /tmp/aquota.group</i>
># <i>chmod 600 /tmp/aquota.user</i>
># <i>chmod 600 /tmp/aquota.group</i>
></pre>
>
><p>
>Questo passo andrÃ  ripetuto per ogni partizione in cui avrete abilitato le quote. Dopo aver aggiunto e configurato i file quota, avremo bisogno di aggiungere lo script <c>quota</c> al runlevel di boot.
></p>
>
><pre caption="Aggiungere quota al runlevel di boot">
># <i>rc-update add quota boot</i>
></pre>
>
><p>
>Ora configureremo il sistema affinchÃ¨ controlli le quote ogni settimana aggiungendo la seguente riga al <path>/etc/crontab</path>.
></p>
>
><pre caption="Aggiungere un controllo delle quote al crontab">
>	0 3 * * 0 /usr/sbin/quotacheck -avug.
></pre>
>
><p>
>Dopo il riavvio della macchina, Ã¨ il momento di assegnare le quote per gli utenti e i gruppi. 
><c>edquota -u kn</c> aprirÃ  l'editor definito in $EDITOR (nano di default) e vi permetterÃ  di editare le quote per l'utente kn. Con <c>edquota -g</c> potrete fare la stessa cosa per i gruppi.
></p>
>
><pre caption="Assegnare una quota all'utente kn">
>Quotas for user kn: 
>/dev/sda4: blocks in use: 2594, limits (soft = 5000, hard = 6500) 
>         inodes in use: 356, limits (soft = 1000, hard = 1500)
></pre>
>
><p>
>Per maggiori dettagli leggete <c>man edquota</c> o il <uri link="http://www.tldp.org/HOWTO/mini/Quota.html">Quota mini howto</uri>
></p>
>
></body>
></section>
>
><section>
><title>/etc/login.defs</title>
><body>
>	    
><p>
>Se la politica scelta prevede che ogni utente debba cambiare la propria password ogni settimana, 
>cambiate il valore di <c>PASS_MAX_DAYS</c> a 14 e <c>PASS_WARN_AGE</c> a 7. 
>Si raccomanda di applicare tale politica poichÃ¨ utilizzando password vecchie le si rende facilmente soggette ad attacchi di forza bruta in grado di violare qualsiasi password: Ã¨ solo questione di tempo. Siete anche invitati a settare <c>LOG_OK_LOGINS</c> a yes.
></p>
>
></body>
></section>
>
><section>
><title>/etc/login.access</title>
><body>
><p>
>Il file <path>login.access</path> Ã¨ anch'esso parte del pacchetto sys-apps/shadow e fornisce una tabella di controllo per l'accesso di login. La tabella Ã¨ usata per controllare chi puÃ² o non puÃ² eseguire il login basandosi su user name, group name o host name. Di default, tutti gli utenti di un sistema possono eseguire il login, cosÃ¬ il file Ã¨ pieno solo di commenti ed esempi. Se perÃ² state cercando di rendere piÃ¹ sicuro il vostro server o la vostra workstation, vi raccomandiamo di configurare questo file in modo tale da evitare che nessun altro oltre a voi (l'amministratore) abbia accesso alla console.
></p>
>
><note>Queste impostazioni non si applicano a root.</note>
>
><pre caption="/etc/login.access">
>-:ALL EXCEPT wheel sync:console
>-:wheel:ALL EXCEPT LOCAL .gentoo.org
></pre>
>
><warn>
>Fate attenzione quando configurate queste opzioni, un errore potrebbe impedirvi l'accesso alla macchina se non avete accesso di root.
></warn>
>
><note>
>Queste impostazioni non si applicano a SSH dato che SSH non esegue <c>/bin/login</c> di default. Questo puÃ² essere abilitato usando <c>UseLogin yes</c> in <path>/etc/ssh/sshd_config</path>. Tale opzione forzerÃ  SSH ad usare login e dunque rendere attive le impostazioni precedenti.
></note>
>
><p>
>Questa configurazione permetterÃ  l'accesso alla console solo ai membri del gruppo wheel localmente o dal dominio gentoo.org. Potrebbe sembrare paranoico, ma prevenire Ã¨ meglio che curare.
></p>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Permessi sui File</title>
><section>
>
><title>World readable (Permessi di lettura per tutti)</title>
><body>
>
><p>
>Gli utenti normali non dovrebbero avere accesso a file di configurazione o password. Un attaccante puÃ² rubare le passwords da un database o da un sito web e modificare, o peggio, cancellare i dati. Ecco perchÃ¨ Ã¨ importante che i permessi siano corretti. Se siete sicuri che un file Ã¨ usato solo da root, assegnategli i permessi <c>0600</c> e il giusto proprietario con <c>chown</c>.
></p>
>
></body>
></section>
>
><section>
><title>World/Group writable (Permessi di scrittura per tutti o per il gruppo)</title>
><body>
>
><pre caption="Trovare file e directory con permessi di scrittura per tutti">
># <i>/usr/bin/find / -type f $ -perm -2 -o -perm -20 $ \ 
>   -exec ls -lg {} \; 2>/dev/null >writable.txt</i>
># <i>/usr/bin/find / -type d $ -perm -2 -o -perm -20 $ \ 
>   -exec ls -ldg {} \; 2>/dev/null >>writable.txt</i>
></pre>
>
><p>
>Questi comandi creeranno un grosso file con la lista di tutti i file e le directory che hanno il permesso di scrittura impostato per un gruppo o per chiunque. Controllateli ed eliminate il permesso di scrittura per tutti eseguendo <c>/bin/chmod o-w</c> sui file.
></p>
>
></body>
></section>
>
><section>
><title>File SUID/SGID</title>
><body>
>
><p>
>I files con il bit SUID o SGID attivo permettono ai files di essere eseguiti con i privilegi dell'utente o del gruppo <e>proprietario</e> e non con quelli dell'utente che esegue il file.Normalmente questi bit vengono impostati per quei file che necessitano di fare qualcosa con i privilegi di root. Questi file possono portare alla compromissione locale di root (se contengono buchi di sicurezza) poichÃ¨ il file Ã¨ eseguito con permessi di root. Questi file sono pericolosi e dovrebbero essere evitati ad ogni costo. Se non usate questi file, usate <c>chmod 0</c> su di loro o eliminate il pacchetto che li contiene con <c>emerge -C pacchetto</c> (trovate il pacchetto con <c>equery</c>). Se non lo avete ancora installato, digitate semplicemente <c>emerge gentoolkit</c>. Oppure disabilitate soltanto il bit suid con <c>chmod -s nomefile</c>.
></p>
>
><pre caption="Trovare file setuid">
># <i>/usr/bin/find / -type f $ -perm -004000 -o -perm -002000 $ \ 
>  -exec ls -lg {} \; 2>/dev/null >suidfiles.txt</i>
></pre>
>
><p>
>Questo comando creerÃ  un file contenente una lista di tutti i file SUID/SGID.
></p>
>
><pre caption="Lista di binari setuid">
>/bin/su
>/bin/ping
>/bin/mount
>/bin/umount
>/var/qmail/bin/qmail-queue
>/usr/bin/chfn
>/usr/bin/chsh
>/usr/bin/crontab
>/usr/bin/chage
>/usr/bin/expiry
>/usr/bin/sperl5.6.1
>/usr/bin/newgrp
>/usr/bin/passwd
>/usr/bin/gpasswd
>/usr/bin/procmail
>/usr/bin/suidperl
>/usr/lib/misc/pt_chown
>/usr/sbin/unix_chkpwd
>/usr/sbin/traceroute
>/usr/sbin/pwdb_chkpwd
></pre>
>
><p>
>Di default Gentoo Linux non ha molti file SUID (dipende da cosa avete installato), ma potreste comunque avere una lista come quella precedente. La maggior parte dei comandi non dovrebbe essere usata da normali utenti, ma solo da root. Disattivate il bit suid da <c>ping</c>, <c>mount</c>, <c>umount</c>, <c>chfn</c>, <c>chsh</c>, <c>newgrp</c>, <c>suidperl</c>, <c>pt_chown</c> e <c>traceroute</c> eseguendo <c>chmod -s</c> su ogni file. Non eliminate il bit da <c>su</c>, <c>qmail-queue</c> o <c>unix_chkpwd</c>, altrimenti rischiate di non essere piÃ¹ in grado di fare switch user (su) o di ricevere mail. Eliminando questo bit prevenite la possibilitÃ  che un normale utente (o un attaccante) possa guadagnare i privilegi di root attraverso uno di questi file.
></p>
>
><p>
>I soli file SUID che ho sul mio sistema sono <c>su</c>, <c>passwd</c>, <c>gpasswd</c>, <c>qmail-queue</c>, <c>unix_chkpwd</c> e <c>pwdb_chkpwd</c>. Ma se state usando X, probabilmente ne avrete degli altri visto che X necessita di tale accesso.
></p>
>
></body>
></section>
>
><section>
><title>Eseguibili SUID/SGID e hardlinks</title>
><body>
>
><p>
>Un file si puÃ² considerare cancellato solo quando non ci sono piÃº links che puntano a esso. Potrebbe sembrare strano, ma bisogna tener presente che il nome di un file come <path>/usr/bin/perl</path> in realtÃ¡ rappresenta un link all'inode dove sono registrati i dati. A questo file si possono riferire un numero qualsiasi di link, e fino a che non vengono rimossi tutti il file continuerÃ¡ a esistere.
></p>
>
><p>
>Se gli utenti del proprio sistema hanno accesso a partizioni che non vengono montate con le opzioni <c>nosuid</c> o <c>noexec</c> (per esempio nel caso in cui <path>/tmp</path>, <path>/home</path> o <path>/var/tmp</path> non sia partizioni separate) bisogna assicurarsi che gli utenti non creino hardlink a degli eseguibili SUID o SGUID, altrimenti dopo un aggiornamento del software tramite Portage sarebbero comunque in grado di eseguire le vecchie versioni del software.
></p>
>
><warn>
>Se si sono ricevuti degli avvisi da Portage riguardano hardlink rimasti sul sistema e gli utenti possono scrivere su partizioni che consentono l'esecuzione di file SUID/SGID, si dovrebbe leggere questa sezione della guida con molta attenzione. Uno degli utenti potrebbe aver cercato di aggirare l'aggiornamento mantenendo una versione vecchia di un programma. Se gli utenti del sistema non hanno possobilitÃ¡ di creare file SUID o possono eseguire programmi solo attraverso il dynamic loader (partizioni montate con l'opzione <c>noexec</c>), non ci dovrebbe essere nulla di cui preoccuparsi. 
></warn>
>
><note>
>Un utente non ha bisogno di avere il permesso di lettura su un file per creare un link a esso, Ã© sufficiente che abbia il permesso di lettura sulla directory che contiene il file.
></note>
>
><p>
>Per verificare quanti link si riferiscono a un file si utilizza il comando <c>stat</c>.
></p>
>
><pre caption="Comando stat">
>$ stat /bin/su    
>  File: `/bin/su'
>  Size: 29350           Blocks: 64         IO Block: 131072 regular file
>Device: 900h/2304d      Inode: 2057419     Links: 1
>Access: (4711/-rws--x--x)  Uid: (    0/    root)   Gid: (    0/    root)
>Access: 2005-02-07 01:59:35.000000000 +0000
>Modify: 2004-11-04 01:46:17.000000000 +0000
>Change: 2004-11-04 01:46:17.000000000 +0000
></pre>
>
><p>
>Per trovare file SUID o SGID a cui si riferisca piÃº di un link si usa il comando <c>find</c>.
></p>
>
><pre caption="Trovare eseguibili SUID/SGID con link multipli">
>$ find / -type f $ -perm -004000 -o -perm -002000 $ -links +1 -ls
></pre>
>
></body>
></section>
>
></chapter>
>
><chapter>
><title>PAM (Pluggable Authentication Modules)</title>
><section>
><body>
>
><p>
>PAM Ã¨ una suite di librerie condivise che forniscono una modalitÃ  di autenticazione alternativa a un programma. La flag USE <c>pam</c> Ã¨ attiva di default. Sebbene le configurazioni di PAM su Gentoo Linux siano piÃ¹ che ragionevoli, c'Ã¨ sempre modo di migliorare. Prima di tutto installiamo le cracklib
></p>
>
><pre caption="Installare le cracklib">
># <i>emerge cracklib</i>
></pre>
>
><pre caption="/etc/pam.d/passwd">
>auth	 required pam_unix.so shadow nullok
>account	 required pam_unix.so
>password required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=2 ocredit=2 
>password required pam_unix.so md5 use_authtok
>session	 required pam_unix.so
></pre>
>
><p>
>Questo aggiungerÃ  le cracklib, che vi assicureranno che gli utenti usino una password di almeno 8 caratteri
>e contenente almeno 2 cifre, 2 simboli e che ci siano almeno 3 caratteri differenti dalla password precedente.
>Questo forza l'utente a scegliere un buona password (politica delle password). Guardate la documentazione delle
><uri link="http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/pam-6.html#ss6.3">PAM</uri> per maggiori dettagli.
></p>
>
><pre caption="/etc/pam.d/sshd">
>auth      required pam_unix.so nullok 
>auth      required pam_shells.so
>auth	    required pam_nologin.so
>auth	    required pam_env.so
>account	  required pam_unix.so
>password  required pam_cracklib.so difok=3 retry=3 minlen=8 dcredit=2 ocredit=2 use_authtok
>password  required pam_unix.so shadow md5
>session	  required pam_unix.so
>session	  required pam_limits.so
></pre>
>
><p>
>Tutti i servizi che non sono configurati con un file PAM in <path>/etc/pam.d</path> useranno le regole contenute nel file  <path>/etc/pam.d/other</path>. Le impostazioni di default sono impostate a <c>deny</c> com'Ã¨ giusto che sia. Ma mi piace avere molti log, ecco perchÃ© ho aggiunto <c>pam_warn.so</c>. L'ultima configurazione Ã¨ <c>pam_limits</c> che Ã¨ controllata da <path>/etc/security/limits.conf</path>. Date un'occhiata alla <uri link="#doc_chap6_sect1">sezione su /etc/security/limits.conf</uri> per maggiori informazioni.
></p>
>
><pre caption="/etc/pam.d/other">
>auth     required pam_deny.so 
>auth     required pam_warn.so 
>account  required pam_deny.so 
>account  required pam_warn.so 
>password required pam_deny.so 
>password required pam_warn.so 
>session  required pam_deny.so 
>session  required pam_warn.so
></pre>
>
></body>
></section>
></chapter>
>
><chapter>
><title>TCP Wrappers</title>
><section>
><body>
>
><p>
>E' un modo di controllare l'accesso ai servizi eseguiti normalmente da inetd (che Gentoo non ha)
>ma che puÃ² anche essere usato da xinetd e altri servizi.
></p>
>
><note>
>I vari servizi dovrebbero eseguire tcpd nel relativo argomento server (in xinetd). Guardate il 
>capitolo su xinetd per maggiori informazioni.
></note>
>
><pre caption="/etc/hosts.deny">
>ALL:PARANOID
></pre>
>
><pre caption="/etc/hosts.allow">
>ALL: LOCAL @wheel
>time: LOCAL, .gentoo.org
></pre>
>
><p>
>Come potete vedere il formato Ã¨ molto simile a quello di <path>/etc/login.access</path>. Tcpd supporta uno specifico servizio ma non lavora nella medesima zona di sicurezza. Queste impostazioni si applicano soltanto ai servizi che usano tcp wrappers.
></p>
>
><p>
>E' possibile eseguire comandi anche quando un servizio Ã¨ in uso (per esempio quando Ã¨ attivato il relaying di un modem per gli utenti) ma non Ã¨ una scelta raccomandata, poichÃ¨ spesso le persone tendono a creare piÃ¹ problemi di quanti ne cerchino di risolvere. Un esempio potrebbe essere quello di configurare uno script che invii una mail ogni volta che qualcuno accede ad un servizio negato, ma un attaccante potrebbe lanciare un DoS contro di voi sfruttando le regole di negazione. Questo genererebbe un notevole I/O e le mail non verrebbero piÃ¹ inviate! Leggete <c>man 5 host_access</c> per maggiori informazioni.
></p>
>
></body>
></section>
>
></chapter>
>
><chapter>
><title>Sicurezza del Kernel</title>
>
><section>
><title>Rimuovere funzionalitÃ </title>
><body>
>
><p>
>La regola di base per la configurazione del kernel Ã¨ di rimuovere tutto ciÃ² che non Ã¨ necessario. Questo creerÃ  un kernel compatto ma soprattutto eliminerÃ  le vulnerabilitÃ  che potrebbero essere insite in un driver o in altre funzionalitÃ .
></p>
>
><p>
>Considerate inoltre di rimuovere il supporto per i moduli. Nonostante sia possibile aggiungere moduli (root kit) anche senza tale supporto,  renderete comunque piÃ¹ difficile per un normale attaccante installare root kit attraverso i moduli del kernel.
></p>
>
></body>
></section>
>
><section>
><title>Il filesystem /proc</title>
><body>
>
><p>
>Molti parametri del kernel possono essere alterati attraverso il file system <path>/proc</path> o usando <c>sysctl</c>.
></p>
>
><p>
>Per cambiare dinamicamente "al volo" i parametri e le variabili del kernel, Ã¨ necessario che nel vostro kernel sia definita <c>CONFIG_SYSCTL</c>. Questa Ã¨ attivata di default in un kernel 2.4 standard.
></p>
>
><pre caption="Disattivare l'IP forwarding">
># <i>/bin/echo "0" > /proc/sys/net/ipv4/ip_forward</i>
></pre>
>
><p>
>Assicuratevi che l'IP forwarding non sia attivo, a meno che non stiate configurando un sistema con piÃ¹ interfacce di rete.
></p>
>
><pre caption="Ignorare i pacchetti ping">
># <i>/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all</i>
></pre>
>
><p>
>Questo comando farÃ  si che il kernel semplicemente ignori del tutto i messaggi ping, conosciuti anche come messaggi ICMP di tipo 0. La ragione di questa scelta Ã¨ che il pacchetto IP che trasporta il messaggio icmp puÃ² contenere nel proprio payload piÃ¹ informazioni di quanto pensiate. Gli amministratori usano ping come un tool per la diagnostica e quindi spesso si rammaricano di non poterlo utilizzare. Non v'Ã¨ invece motivo per permettere ad un estraneo di "pingarci". A volte puÃ² essere utile agli utenti interni potersi servire di ping. La soluzione a tutto ciÃ² puÃ² essere di disabilitare gli icmp di tipo 0 nel firewall.
></p>
>
><pre caption="Ignorare ping broadcast ping">
># <i>/bin/echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts</i>
></pre>
>
><p>
>Questo comando disabilita la risposta a ICMP broadcast e previene gli attacchi Smurf. L'attacco smurf avviene inviando un messaggio ICMP di tipo 0 (ping) all'indirizzo broadcast di una rete. Tipicamente l'attaccante userÃ  un indirizzo sorgente spoofed. Tutti i computer nella rete risponderanno al messaggio ping e quindi inonderanno (flooding) di messaggi l'host spoofed.
></p> 
>
><pre caption="Disabilitare i pacchetti source routed">
># <i>/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route</i>
></pre>
>
><p>
>Non accetta i pacchetti source routed (pacchetti instradati dalla sorgente). Un attaccante puÃ² usare il source routing per generare traffico che sembra avere origine dalla vostra rete, ma in realtÃ  Ã¨ instradato all'indietro lungo il percorso dal quale Ã¨ venuto, cosÃ¬ che un attaccante puÃ² compromettere la vostra rete. Il source routing Ã¨ usato raramente per motivi legittimi quindi disabilitatelo.
></p>
>
><pre caption="Disabilitare l'accettazione di pacchetti redirezionati">
># <i>/bin/echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects</i>
># <i>/bin/echo "0" > /proc/sys/net/ipv4/conf/all/secure_redirects</i>
></pre>
>
><p>
>Disabilita l'accettazione di ICMP redirezionati. Gli ICMP redirezionati possono essere utilizzati per modificare le vostre tabelle di routing, possibilmente verso cattive destinazioni.
></p>
>
><pre caption="Protezione contro i falsi messaggi d'errore">
># <i>/bin/echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses</i>
></pre>
>
><p>
>Abilita la protezione contro le risposte a falsi massaggi d'errore.
></p>
>
><pre caption="Abilitare il reverse path filtering">
># <i>for i in /proc/sys/net/ipv4/conf/*; do
>        /bin/echo "1" &gt; $i/rp_filter
>done</i>
></pre>
>
><note>
>Se abilitate l'ip forwarding, otterrete anche questo risultato.
></note>
>
><p>
>Abilitate il "reverse path filtering" (filtraggio del cammino inverso). CiÃ² permette di verificare che i pacchetti utilizzino un indirizzo sorgente legittimo, rifiutando automaticamente i pacchetti ricevuti qualora la voce relativa a tale sorgente nella tabella di routing non risulti correttamente abbinata alla rispettiva interfaccia di rete dalla quale il pacchetto stesso Ã¨ stato ricevuto. CiÃ² presenta vantaggi di sicurezza poichÃ¨ previene lo spoofing IP.
></p>
>
><warn>
>Tuttavia attivare il reverse path filtering puÃ² costituire un problema se utilizzate il routing asimmetrico (i pacchetti che voi inviate ad un host intraprendono un percorso diverso da quello diretto dall'host a voi) o se operate un "non-routing" con un host che possiede piÃ¹ indirizzi IP su diverse interfacce.
></warn>
>
><pre caption="Loggare tutti i pacchetti spoofed, source routed e redirezionati">
># <i>/bin/echo "1" > /proc/sys/net/ipv4/conf/all/log_martians</i>
></pre>
>
><p>
>Loggate tutti i pacchetti spoofed, i pacchetti source routed e quelli redirezionati.
></p>
>
><p>
>Tutte queste impostazioni andranno perdute quando la macchina verrÃ  riavviata. Per questo vi suggerisco di aggiungerle a <path>/etc/sysctl.conf</path> affinchÃ¨ vengano lette automaticamente dallo script init <path>/etc/init.d/bootmisc</path>
></p>
>
><p>
>La sintassi di <path>/etc/sysctl.conf</path> Ã¨ abbastanza intuitiva. Eliminate dai path precedentemente menzionati <path>/proc/sys/</path> e sostituite ogni <path>/</path> con <path>.</path>:
></p>
>
><pre caption="Passare a sysctl.conf">
><comment>(Manualmente usando echo):</comment>
>/bin/echo "0" &gt; /proc/sys/net/ipv4/ip_forward
>
><comment>(Automaticamente in sysctl.conf:)</comment>
>net.ipv4.ip_forward = 0
></pre>
>
></body>
></section>
>
><section>
><title>Grsecurity</title>
><body>
>
><p>
>La patch <uri link="http://grsecurity.net">Grsecurity</uri> Ã¨ applicata ormai come standard nei sorgenti del kernel Gentoo ma per default Ã¨ disabilitata. Configurate il vostro kernel come fate normalmente, quindi configurate l'opzione Grsecurity. Una spiegazione accurata sulle opzioni Grsecurity disponibili (versione 1.9) Ã¨ disponibile sulla pagina del progetto <uri link="/proj/en/hardened">Gentoo Hardened</uri>.
></p>
>
><p>
>I recenti <c>grsec-sources</c> forniscono la versione 2.* di Grsecurity. Per maggiori informazioni sui miglioramenti introdotti da questo nuovo insieme di patch, consultate la documentazione disponibile sulla <uri link="http://www.grsecurity.net/">homepage di Grsecurity</uri>.
></p>
>
></body>
></section>
>
><section>
><title>Kerneli</title>
><body>
>
><p>
><uri link="http://www.Kerneli.org">Kerneli</uri> Ã¨ una patch che aggiunge la crittografia al kernel esistente. Patchando il vostro kernel otterrete delle nuove opzioni quali: Cryptographic ciphers, algoritmi di digest e filtri "cryptographic loop".
></p>
>
><warn>
>La patch kerneli per l'ultimo kernel non Ã¨ ancora in versione stabile, quindi prestate attenzione qualora sceglieste di usarla.</warn>
>
></body>
></section>
>
><section>
><title>Altre patches per il kernel</title>
><body>
>
><ul>
>  <li><uri link="http://www.openwall.com">The OpenWall Project</uri></li>
>  <li><uri link="http://www.lids.org">Linux Intrusion Detection System</uri></li>
>  <li><uri link="http://www.rsbac.org">Rule Set Based Access Control</uri></li>
>  <li><uri link="http://www.nsa.gov/selinux">NSA's security enhanced kernel</uri></li>
>  <li><uri link="http://sourceforge.net/projects/wolk/">Wolk</uri></li>
></ul>
>
><p>
>Probabilmente ne esistono anche altre. 
></p>
>
></body>
></section>
>
></chapter>
>
><chapter>
><title>Rendere piÃ¹ sicuri i servizi</title>
>
><section>
><title>Apache</title>
><body>
>
><p>Apache (1.3.26) possiede una buona configurazione di default, ma non abbastanza. Dobbiamo migliorare alcune cose, come legarlo ad un indirizzo e impedirgli di rivelare troppe informazioni. Queste sono le opzioni che dovreste sistemare nel file di configurazione.
></p>
>
><p>Se non avete disabilitato <c>ssl</c> nel vostro <path>/etc/make.conf</path> prima di installare apache, dovreste avere accesso ad un server con ssl abilitato. Aggiungete soltanto la seguente riga per attivarlo.
></p>
>
><pre caption="/etc/conf.d/apache">
>HTTPD_OPTS="-D SSL"
></pre>
>
><pre caption="/etc/apache/conf/apache.conf">
># Lo mette in ascolto sul vostro ip
>Listen 127.0.0.1
>BindAddress 127.0.0.1
>
># Non Ã¨ una buona idea usare nobody o nogroup - 
># per ogni servizio che non gira come root
># (semplicemente aggiungete l'utente apache con il gruppo apache)
>User apache
>Group apache
>
># Impedisce ad apache di comunicare la propria versione
>ServerSignature Off
>ServerTokens Prod
></pre>
>
><p>Apache Ã¨ compilato normalmente con le opzioni <c>--enable-shared=max</c> e <c>--enable-module=all</c>. Queste abiliteranno di default ogni modulo, per escluderli dovrete quindi commentare ogni modulo di cui non avrete bisogno nella sezione <c>LoadModule</c> (<c>LoadModule</c> e <c>AddModule</c>). Riavviate il servizio eseguendo <c>/etc/init.d/apache restart</c>.
></p>
>
><p>
>Si puÃ² trovare la documentazione su <uri>http://www.apache.org</uri>
></p>
>
></body>
></section>
>
><section>
><title>Bind</title>
><body>
>
><p>
>Si puÃ² trovare la documentazione presso <uri link="http://www.isc.org/products/BIND/bind9.html">Internet Software Consortium</uri>, il "BIND 9 Administrator Reference Manual" Ã¨ anche in <path>doc/arm</path>.
></p>
>
>
><p>
>I piÃ¹ recenti ebuild di BIND supportano nativamente il chrooting. Prima di emergere <c>bind</c>
>seguite questi semplici passi:
></p>
>
><pre caption="Chrooting BIND">
>ebuild /var/db/pkg/net-dns/bind-9.2.2-r2/bind-9.2.2-r2.ebuild config\`"
><codenote> 
>Prima di eseguire il precednte comando, potreste voler cambiare la directory delchroot
>in /etc/conf.d/named. Altrimenti verrÃ  usata /chroot/dns
></codenote>
><codenote>
>Potreste inoltre aver bisogno di sostituire il numero di versione con quello corrente
></codenote>
></pre>
>
></body>
></section>
>
><section>
><title>Djbdns</title>
><body>
>
><p>Djbdns Ã¨ un'implementazione DNS sulla quale l'autore Ã¨ disposto a scommettere <uri link="http://cr.yp.to/djbdns/guarantee.html">soldi</uri> tanto la ritiene sicura. Il suo modo di operare Ã¨ molto diverso da quello di Bind9, ma Ã¨ da provare. Maggiori informazioni possono essere trovate su <uri>http://www.djbdns.org/</uri>
></p>
>
></body>
></section>
>
><section>
><title>FTP</title>
>
><body>
><p>
>Generalmente, usare l'FTP (File Transfer Protocol) Ã¨ una pessima idea. Scambia dati non cifrati, Ã¨ in ascolto su due porte (normalmente le porte 20 e 21), supporta gli utenti anonimi ed Ã¨ ciÃ² che molti attaccanti cercano (per commerciare "warez"). PoichÃ¨ il protocollo FTP contiene parecchi problemi di sicurezza, sarebbe meglio usare <c>sftpd</c> o HTTP al suo posto. In caso contrario, assicuratevi che i vostri servizi siano quanto migliori possibile e state in guardia. 
></p>
>
></body>
></section>
>
><section>
><title>Mysql</title>
><body>
>
><p>
>Se avete bisogno che soltanto le applicazioni locali abbiano accesso al database <c>mysql</c> decommentate la seguente linea in <path>/etc/mysql/my.cnf</path>.
></p>
>
><pre caption="Disabilitare l'accesso dalla rete">
>skip-networking
></pre>
>
><p>
>Disabilitate il comando <c>LOAD DATA LOCAL INFILE</c> nel medesimo file.
></p>
>
><pre caption="Disabilitare LOAD DATA LOCAL INFILE nella sezione [mysqld]">
>set-variable=local-infile=0
></pre>
>
><p>
>Ora, andiamo a rimuovere il database d'esempio (test) e tutti gli account eccetto quello locale di <c>root</c>.
></p>
>
><pre caption="Rimuovere il database d'esempio e tutti gli utenti non necessari">
>mysql> <i>drop database test;</i>
>mysql> <i>use mysql;</i>
>mysql> <i>delete from db;</i>
>mysql> <i>delete from user where not (host="localhost" and user="root");</i>
>mysql> <i>flush privileges;</i>
></pre>
>
><warn>
>Fate attenzione con i precedenti comandi nel caso abbiate giÃ  configurato account utente. 
></warn>
>
><note>
>Se avete cambiato una password dal prompt di MySQL dovreste svuotare i file <path>~/.mysql_history</path> e <path>/var/log/mysql/mysql.log</path>, in questi file si trovano tutti i comandi SQL eseguiti, tra cui ovviamente anche quelli per il cambiamento della password, che sarÃ¡ scritta in chiaro.
></note>
>
></body>
></section>
>
><section>
><title>Proftpd</title>
><body>
>
><p>Proftpd ha avuto in passato diversi problemi di sicurezza, ma la maggior parte di essi pare essere stata risolta. Potete applicare questi ulteriori miglioramenti:
></p>
>
><pre caption="/etc/proftpd/proftpd.conf">
>ServerName "My ftp daemon"
># Non mostra l'identitÃ  del server
>ServerIdent on "Go away"
>
># Rende piÃ¹ facile creare utenti virtuali
>RequireValidShell off
>
># Utilizza file passwd e group alternativi (passwd usa un formato cifrato)
>AuthUserFile "/etc/proftpd/passwd"
>AuthGroupFile "/etc/proftpd/group"
>
># Permessi
>Umask 077
>
># Timeouts e limiti
>MaxInstances 30
>MaxClients 10 "Only 10 connections allowed"
>MaxClientsPerHost 1 "You have already logged on once"
>MaxClientsPerUser 1 "You have already logged on once"
>TimeoutStalled 10
>TimeoutNoTransfer 20
>TimeoutLogin 20
>
># Tutto in chroot
>DefaultRoot ~
>
># Non gira come root
>User  nobody
>Group nogroup
>
># Registra ogni trasferimento
>TransferLog /var/log/transferlog
>
># Problemi con il globbing
>DenyFilter \*.*/
></pre>
>
><p>
>Si puÃ² trovare la documentazione su <uri>http://www.proftpd.org</uri>.
></p>
>
></body>
></section>
>
><section>
><title>Pure-ftpd</title>
><body>
>
><p> Pure-ftpd Ã¨ un ramo (ndt, deriva dai sorgenti) dell'orginale trollftpd. E' stato modificato per motivi di sicurezza e funzionalitÃ  da Frank Dennis.
></p>
>
><p>Utilizza utenti virtuali (mai accounts di sistema) abilitando l'opzione <c>AUTH</c>. Impostatela a <c>-lpuredb:/etc/pureftpd.pdb</c> e create i vostri utenti utilizzando <c>/usr/bin/pure-pw</c>. 
></p>
>
><pre caption="/etc/conf.d/pure-ftpd">
>AUTH="-lpuredb:/etc/pureftpd.pdb"
>
>## Varie ed eventuali ##
>MISC_OTHER="-A -E -X -U 177:077 -d -4 -L100:5 -I 15"
></pre>
>
><p>Configurate la vostra variabile <c>MISC_OTHER</c> affinchÃ¨ non permetta accessi anonimi (<c>-E</c>), metta tutto in chroot (<c>-A</c>), gli utenti non possano leggere o scrivere file che iniziano con un . (punto) (<c>-X</c>), imposti un idle time massimo (<c>-I</c>), limiti la ricorsione (<c>-L</c>) a una umask ragionevole.
></p>
>
><warn>
><e>NON</e> dovete usare le opzioni <c>-w</c> o <c>-W</c>! Se volete avere un sito warez, smettete di leggere questa guida!
></warn>
>
><p>
>Si puÃ² trovare la documentazione su <uri>http://www.pureftpd.org</uri>
></p>
>
></body>
></section>
>  	 
><section>
><title>Vsftpd</title>
><body>
>
><p>
>Vsftpd (abbreviazione di "very secure ftp") Ã¨ un piccolo demone ftp che funziona con una ragionevole configurazione di default. E' molto semplice e non possiede altrettante caratteristiche di pureftp e proftp. 
></p>
>
><pre caption="/etc/vsftpd">
>anonymous_enable=NO
>local_enable=YES
>
># sola lettura
>write_enable=NO
>
># abilita la registrazione dei trasferimenti
>xferlog_std_format=YES
>
>idle_session_timeout=20
>data_connection_timeout=20
>nopriv_user=nobody
>
>chroot_list_enable=YES
>chroot_list_file=/etc/vsftpd/chrootlist
>
>ls_recurse_enable=NO
></pre>
>
><p>
>Come vedete non c'Ã¨ modo con questo demone di avere permessi individuali. Quando si passa perÃ² alle impostazioni relative agli accessi anonimi Ã¨ davvero valido. A volte puÃ² essere utile avere un server ftp anonimo (per condividere codice sorgente libero) e vsftpd fa veramente un ottimo lavoro in questa situazione.
></p>
>
></body>
></section>
>		 
><section>
><title>Qmail</title>
><body>
>
><p>
>Qmail Ã¨ considerato come il mail server piÃ¹ sicuro. E' stato scritto con la sicurezza (e la paranoia) in testa. Non permette il relaying di default e non presenta buchi di sicurezza dal 1996. Date semplicemente <c>emerge qmail</c> e procedete con la configurazione!
></p>
>
></body>
></section>
>
><section>
><title>Samba</title>
><body>
>
><p>
>Samba Ã¨ un protocollo per condividere file con reti Microsoft/Novell e <e>non</e> dovrebbe essere usato su Internet. Tuttavia deve essere comunque reso piÃ¹ sicuro.
></p>
>
><pre caption="/etc/samba/smb.conf">
>[global]
>  # Lega ad un'interfaccia
>  interfaces = eth0 10.0.0.1/32
>
>  # Si assicura di usare password cifrate
>  encrypt passwords = yes
>  directory security mask = 0700
>
>  # Abilita il traffico da 10.0.0.*
>  hosts allow = 10.0.0.
>
>  # Abilita l'autenticazione degli utenti 
>  #(non usa lo share mode)
>  security = user
>  
>  # Disabilita gli account privilegiati
>  invalid users = root @wheel
>
>  # QuantitÃ  massima che smb mostra per una condivisione (non Ã¨ un limite)
>  max disk size = 102400
>
>  # Specifica la politica delle password
>  min password length = 8
>  null passwords = no
>
>  # Utilizza PAM (se supportato)
>  obey pam restrictions = yes
>  pam password change = yes
></pre>
>
><p>
>Assicuratevi che i permessi siano impostati correttamente in ogni condivisione e ricordatevi di leggere la <uri link="http://www.samba.org">documentazione</uri>.
></p>
>
><p>
>Ora riavviate il server e aggiungete gli utenti che volete abbiano accesso a tale servizio. CiÃ² Ã¨ possibile usando <path>/usr/bin/smbpasswd</path> con il parametro <c>-a</c>.
></p>
>
></body>
></section>
>
><section>
><title>ssh</title>
><body>
>
><p>
>L'unico provvedimento di sicurezza che OpenSSH richiede Ã¨ di abilitare un'autenticazione piÃ¹ forte basata sulla crittografia a chiave pubblica. Molti siti (come <uri>http://www.sourceforge.net</uri>, <uri>http://www.php.net</uri> e <uri>http://www.apache.org</uri>) hanno sofferto di intrusioni non autorizzate nei loro sistemi dovute alla perdita o alla cattiva scelta di password. 
></p>
>
><pre caption="/etc/ssh/sshd_config">
># Abilita solamente la versione 2
>Protocol 2
>
># Non permette l'accesso diretto di root
>PermitRootLogin no
>
># Abilita l'autenticazione della chiave pubblica
>PubkeyAuthentication yes
>AuthorizedKeysFile      .ssh/authorized_keys
>
># Disabilita il file .rhost e le normali password d'autenticazione
>RhostsAuthentication no
>PasswordAuthentication no
>PermitEmptyPasswords no
>
># Solo gli utenti nel gruppo wheel o admin possono avere accesso
>AllowGroups wheel admin
>
># Di tutti gli utenti in questi gruppi, solo solo kn e bs hanno realmente accesso
># La notazione @&lt;dominio&gt; e' opzionale ma sostituisce la vecchia direttiva
># AllowHosts
>AllowUsers kn@gentoo.org bs@gentoo.org
>
># Aggiunge un livello di logging
>SyslogFacility AUTH
>LogLevel INFO
>
># bind
>ListenAddress 127.0.0.1
></pre>
>
><p>
>Bisogna anche verificare che nel file di configurazione non sia presente la direttiva <c>UsePAM</c>, in quanto si sovrapporrebbe al meccanismo di autenticazione tramite chiave pubblica.
></p>
>
><p>
>Ora quello che tutti i vostri utenti devono fare Ã¨ generare una chiave (sulla macchina dalla quale desiderano collegarsi) con il seguente comando.
></p>
>
><pre caption="Creare una coppia di chiavi RSA">
># <i>/usr/bin/ssh-keygen -t dsa</i>
></pre>
>
><p>
>Digitare una passphrase.
></p>
>
><pre caption="Output di ssh-keygen">
>Generating public/private dsa key pair.
>Enter file in which to save the key (/home/kn/.ssh/id_dsa):<i>[Premere invio]</i>
>Created directory '/home/kn/.ssh'.
>Enter passphrase (empty for no passphrase): <i>[Inserire la passphrase]</i>
>Enter same passphrase again: <i>[Inserire nuovamente la passphrase]</i>
>Your identification has been saved in /home/kn/.ssh/id_dsa.
>Your public key has been saved in /home/kn/.ssh/id_dsa.pub.
>The key fingerprint is:
>07:24:a9:12:7f:83:7e:af:b8:1f:89:a3:48:29:e2:a4 kn@knielsen
></pre>
>
><p>
>Questo aggiungerÃ  due file nella vostra directory <path>~/.ssh/</path> chiamati <path>id_dsa</path> e <path>id_dsa.pub</path>. Il file denominato <path>id_dsa</path> Ã¨ la vostra chiave privata e dovrebbe essere conservata soltanto da voi e nessun altro. L'altro file <path>id_dsa.pub</path> va distribuito ad ogni server a cui dovete avere accesso. Aggiungete la chiave nella directory home dell'utente in <path>~/.ssh/authorized_keys</path> e cosÃ¬ all'utente dovrebbe essere permesso l'accesso.
></p>
>
><p>
>Ora, i vostri utenti dovrebbero custodire bene questa chiave. Andrebbe messa su un media da portare sempre appresso o mantenuta sulla propria workstation (aggiungetelo alla vostra politica delle <uri link="#doc_chap2_sect5">password</uri>).
></p>
>
><p>
>Per maggiori informazioni andate sul sito web di <uri link="http://www.openssh.org">OpenSSH</uri>.
></p>
>
></body>
></section>
>
><section>
><title>Usare xinetd</title>
><body>
><p>
>xinetd Ã¨ un sostituto di inetd (non incluso in gentoo), il demone dei servizi internet. Esso supporta il controllo degli accessi basato su indirizzo dell'host remoto e ora d'accesso. Fornisce inoltre ampie possibilitÃ  di logging, quali l'orario d'avvio del server, l'indirizzo dell'host remoto, lo user name remoto, il run time del server e le azioni richieste.
></p>
>
><p>
>Come per ogni altro servizio Ã¨ importante avere una buona configurazione di default. Ma poichÃ¨ <c>xinetd</c> Ã¨ usato da root e supporta protocolli di cui potreste ignorare il funzionamento suggeriamo di non usarlo. Se comunque desiderate utilizzarlo ecco qui come aggiungergli un certo grado di sicurezza.
></p>
>
><pre caption="Installare xinetd">
># <i>emerge xinetd tcp-wrappers</i>
></pre>
>
><p>
>Modificate il file di configurazione:
></p>
>
><pre caption="/etc/xinetd.conf">
>defaults
>{
> only_from      = localhost
> instances      = 10
> log_type       = SYSLOG authpriv info
> log_on_success = HOST PID
> log_on_failure = HOST
> cps            = 25 30
>}
>
># Questo imposterÃ  il pserver (cvs) via xinetd con le seguenti impostazioni: 
># max 10 istanze (10 connessioni per volta)
># limita il pserver ad usare solo il tcp
># utilizza questo servizio per il cvs degli utenti 
># lega le interfacce a soltanto un ip
># permette l'accesso da 10.0.0.*
># limita il tempo in cui gli sviluppatori possono usare il cvs dalle 8am alle 5pm
># utilizza i tpcd wrappers (controllo degli accessi verificato in 
># <i>/etc/hosts.allow</i> e <i>/etc/hosts.deny</i>)
># max_load della macchina impostato a 1.0
># La flag 'disable' Ã¨ per default impostata a 'no' ma preferisco averla
># nel caso essa sia disabilitata
>service cvspserver
>{
> socket_type    = stream
> protocol       = tcp
> instances      = 10
> protocol       = tcp
> wait           = no
> user           = cvs
> bind           = 10.0.0.2
> only_from      = 10.0.0.0
> access_times   = 8:00-17:00
> server         = /usr/sbin/tcpd
> server_args    = /usr/bin/cvs --allow-root=/mnt/cvsdisk/cvsroot pserver
> max_load       = 1.0
> log_on_failure += RECORD
> disable        = no
>}
></pre>
>
><p>
>Per maggiori informazioni leggete la pagina di manuale <c>man 5 xinetd.conf</c>.
></p>
>
></body>
></section>
>
><section>
><title>X</title>
><body>
>
><p>
>Per default Xorg Ã¨ configurato per fungere da Xserver. CiÃ² puÃ² essere pericoloso poichÃ¨ X utilizza connessioni tcp non cifrate e resta in ascolto dei clients X.
></p>
>
><impo>Se non avete bisogno di questo servizio disabilitatelo!</impo>
>
><p>
>Se invece per utilizzare la vostra workstation dipendete da un Xserver utilizzate il comando 
><c>/usr/X11R6/bin/xhost</c> con cautela. Questo comando permette a clients provenienti da altri hosts di collegarsi e usare il vostro display. CiÃ² puÃ² risultare comodo se avete bisogno di un'applicazione che risiede su un'altra macchina e l'unico modo per servirsene Ã¨ la rete. La sintassi Ã¨ <c>/usr/X11R6/bin/xhost +hostname</c>
></p>
>
><warn>
>Non utilizzate mai l'ozpione <c>xhost +</c>! CiÃ² permetterÃ  a qualunque client di connettersi e prendere il controllo del vostro X. Se un attaccante ottenesse l'accesso al vostro X, potrebbe registrare ciÃ² che digitate e controllare il vostro desktop. Se proprio dovete usare tale opzione almeno ricordatevi di specificare un host.
></warn>
>
><p>
>Una soluzione maggiormente sicura Ã¨ di disabilitare completamente tale opzione avviando il vostro X con <c>startx -- -nolisten tcp</c> o disabilitandola permanentemente nel file di configurazione.
></p>
>
><pre caption="/usr/X11R6/bin/startx">
>defaultserverargs="-nolisten tcp"
></pre>
>
><p>
>Per essere sicuri che <path>startx</path> non venga sovrascritto quando emergerete una versione piÃ¹ recente di Xorg dovrete proteggerlo. Aggiungete le seguenti linee a <path>/etc/make.conf</path>:
></p>
>  	 
><pre caption = "/etc/make.conf">
>CONFIG_PROTECT_MASK="/usr/X11R6/bin/startx"
></pre>
>  	 
><p>
>Se utilizzate un login manager grafico avete bisogno d'un differente approccio.
></p>
>
><p>
>Per <c>gdm</c> (Gnome Display Manager).
></p>
>
><pre caption="/etc/X11/gdm/gdm.conf">
>[server-Standard]
>command=/usr/X11R6/bin/X -nolisten tcp
></pre>
>
><p>
>Per <c>xdm</c> (X Display Manager) e <c>kdm</c> (Kde Display Manager)
></p>
>
><pre caption="/etc/X11/xdm/Xservers">
>:0 local /usr/bin/X11/X -nolisten tcp 
></pre>
>
></body>
></section>
></chapter>
>
><chapter>
><title>Chroot o server virtuali</title>
>
><section>
><title>Chrooting</title>
><body>
>
><p>
>Mettere in chroot un servizio Ã¨ un modo di limitare l'ambiente d'esecuzione di un servizio (o utente) a ciÃ² che gli Ã¨ permesso fare non concedendo nessun accesso (o informazione) che potrebbe servire per acquisire privilegi di <c>root</c>. Facendo girare i servizi come utenti diversi da root (<c>nobody</c>, <c>apache</c>, <c>named</c>) un attaccante puÃ² soltanto accedere ai file con i permessi di tali utenti. CiÃ² significa che un attaccante non puÃ² acquisire privilegi di <c>root</c> anche se i servizi presentano vulnerabilitÃ  di sicurezza.
></p>
>
><p>
>Alcuni servizi come <c>pure-ftpd</c> e <c>bind</c> possiedono caratteristiche per il chrooting, altri no. Se i servizi lo supportano, usatelo, in caso contrario dovrete arrangiarvi e crearvelo da soli. Per comprenderne meglio il funzionamento di base, vedremo ora come creare un chroot provandolo sulla <c>bash</c> (poichÃ¨ facile da capire).
></p>
>
><p>
>Create la directory <path>/chroot</path> con il comando <c>mkdir chroot</c>. Cercate con quali librerie dinamiche la <c>bash</c> Ã¨ stata compilata (se Ã¨ stata compilata con <c>-static</c> questo passo non Ã¨ necessario):
></p>
>
><p>
>I seguenti comandi creeranno una lista di librerie usate dalla <c>bash</c>.
></p>
>
><pre caption="Ottenere una lista delle librerie usate">
># <i>ldd /bin/bash</i>
>  libncurses.so.5 => /lib/libncurses.so.5 (0x4001b000)
>  libdl.so.2 => /lib/libdl.so.2 (0x40060000)
>  libc.so.6 => /lib/libc.so.6 (0x40063000)
>  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
></pre>
>
><p>
>Ora bisogna creare un ambiente per la <c>bash</c>.
></p>
>
><pre caption="Creare l'ambiente chroot per la bash">
># <i>mkdir /chroot/bash</i>
># <i>mkdir /chroot/bash/bin</i>
># <i>mkdir /chroot/bash/lib</i>
></pre>
>
><p>
>A questo punto copiate i file usati dalla <c>bash</c> (<path>/lib</path>) nella <path>lib</path> chrooted e copiate i comandi bash nella directory <path>bin</path> chrooted. CiÃ² creerÃ  lo stesso ambiente che si Ã¨ soliti usare, solo con meno funzionalitÃ . Dopo la copiatura provate a dare: <c>chroot /chroot/bash /bin/bash</c>. Se ottenete un prompt tipo <path>/</path> funziona! Altrimenti correttamente vi dirÃ  quali file mancano. Alcune librerie condivise dipendono a vicenda da altre.
></p>
>
><p>
>Noterete che all'interno del chroot non funziona nulla se non <c>echo</c>. Questo Ã¨ dato dal fatto che non ci sono altri comandi nel vostro ambiente chroot se non bash e <c>echo</c>, che Ã¨ una funzionalitÃ  integrata della bash.
></p>
>
><p>
>Questo Ã¨ fondamentalmente lo stesso procedimento per creare un servizio chrooted. La sola differenza Ã¨ che i servizi a volte contano sui dispositivi e i file di configurazione in <path>/etc</path>. Semplicemente copiateli (i dispositivi possono essere copiati con <c>cp -a</c>) nell'ambiente chrooted, modificate lo script init affinchÃ¨ usi il chroot prima di avviarsi. PuÃ² essere difficoltoso trovare quali dispositivi e file di configurazione sono richiesti da un servizio. Per ovviare a ciÃ² diventa utile il comando <c>strace</c>. Avviate il servizio con <c>/usr/bin/strace</c> e cercate le funzioni open, read, stat e forse anche connect. Questo vi darÃ  qualche indizio su quali file copiare. Nella maggior parte dei casi basta copiare il file passwd (modificate la copia rimuovendo gli utenti che non hanno nulla a che fare con tale servizio), <path>/dev/zero</path>, <path>/dev/log</path> e <path>/dev/random</path>.
></p>
>
></body>
></section>
>
><section>
><title>Server virtuali</title>
><body>
>
><p>
>Un altro modo per creare un ambiente piÃ¹ sicuro Ã¨ utilizzare un ambiente "virtual server". Questa soluzione crea una copia dell'esistente Linux e la carica in modalitÃ  virtuale. CiÃ² significa che se un server venisse compromesso sarebbe soltanto il server virtuale ad essere compromesso e non la reale installazione.
></p>
>
><p>
>Esempio di servers virtuali:
></p>
>
>
></body>
></section>
>
></chapter>
>
><chapter>
><title>Firewalls</title>
>
><section>
><title>Un firewall</title>
><body>
>
><p>
>La gente spesso pensa che un firewall sia il sistema di sicurezza definitivo, ma si sbaglia. Nella maggior parte dei casi un firewall mal configurato presenta piÃ¹ problemi di sicurezza che non averlo affatto. Un firewall inoltre non Ã¨ che un software e dovrebbe essere trattato nello stesso modo di un qualsiasi altro software, semplicemente perchÃ¨ Ã¨ possibile che presenti dei bugs (buchi di sicurezza).
></p>
>
><p>
>Quindi pensateci bene prima di implementarne uno! Ne avete realmente bisogno? Se pensate di averne bisogno scrivete una politica su come dovrebbe funzionare, sul tipo di firewall e su chi dovrebbe gestirlo. Ma prima leggete questa guida.
></p>
>
><p>
>I Firewalls vengono utilizzati con due possibili intenti:
></p>
>
><ul>
><li>Impedire agli utenti (worms/attaccanti) di entrare</li>
><li>Impedire agli utenti (impiegati/bambini) di uscire</li>
></ul>
>
><p>
>Fondamentalmente esistono tre tipi di firewalls:
></p>
>
><ul>
><li>Packet filtering (filtro di pacchetti)</li>
><li>Circuit relay (relay di circuito)</li>
><li>Application gateway (gateway d'applicazioni)</li>
></ul>
>
><p>
>Un firewall dovrebbe essere una macchina dedicata sulla quale non gira alcun servizio (o soltanto <c>sshd</c>) e resa sicura con i metodi raccomandati in questa guida.
></p>
>
></body>
></section>
>
><section>
><title>Packet filtering (Filtro di pacchetti)</title>
><body>
>
><p>
>Tutto il traffico di rete Ã¨ sotto forma di pacchetti. Gran parte del traffico Ã¨ inoltre suddiviso in pacchetti piÃ¹ piccoli e facilmente gestibili, quindi ricostruito quando giunge a destinazione. Nel proprio header (ndt, Intestazione) ogni pacchetto contiene le informazioni su come e dove dovrebbe essere trasportato. E queste informazioni sono esattamente quelle che utilizza un firewall "packet filter" (filtro di pacchetti). 
>Il filtraggio Ã¨ basato su:
></p>
>
><ul>
>
><li>Autorizzare o bloccare i pacchetti basandosi sull'indirizzo IP sorgente/destinazione.</li>
><li>Autorizzare o bloccare i pacchetti basandosi sulla porta sorgente/destinazione.</li>
><li>Autorizzare o bloccare i pacchetti basandosi sul protocollo.</li>
><li>Autorizzare o bloccare i pacchetti basandosi sulle flags impostate in uno specifico protocollo.</li>
>
></ul>
>
><p>
>Fondamentalmente il filtraggio Ã¨ basato sui dati contenuti nell'intestazione di un pacchetto e 
>non sul contenuto (ndt, controlla gli header di un pacchetto e non il suo payload).
></p>
>
><p>
>Debolezze:
></p>
>
><ul>
><li>L'indirizzo di un pacchetto potrebbe essere stato appositamente forgiato o come si dice in gergo <e>"spoofed"</e> da chi l'ha spedito</li>
><li>I dati e le richieste contenuti nei pacchetti lasciati passare potrebbero contenere dati indesiderati che un attaccante potrebbe sfruttare su bug noti dei servizi che si trovano su o dietro il firewall</li>
><li>Fallimenti sul singolo pacchetto abbastanza comuni</li>
></ul>
>
><p>
>Vantaggi:
></p>
>
><ul>
><li>Semplice e facile da implementare</li>
><li>PuÃ² avvertire di un possibile attacco prima che questo avvenga (p.e. identificando i portscans)</li>
><li>Ottimo per bloccare gli attachi SYN</li>
></ul>
>
><p>
>Esempi di "packet filter" liberi per Linux:
></p>
>
><ul>
><li><uri link="http://www.iptables.org">Iptables</uri></li>
><li><uri link="http://www.linuxdocs.org/HOWTOs/IPCHAINS-HOWTO.html">Ipchains</uri></li>
><li><uri link="http://www.smoothwall.org">SmoothWall</uri></li>
></ul>
>
><note>
>Si raccomanda di usare iptables in quanto ipchains ormai Ã© diventato obsoleto.
></note>
>
></body>
></section>
>
><section>
><title>Circuit relay (relay di circuito)</title>
><body>
>
><p>
>Noto anche come gateway a livello di circuito, Ã¨ un tipo di firewall che controlla la validitÃ  delle connessioni prima di permettere che i dati vengano scambiati. CiÃ² significa semplicemente che non autorizza o blocca i pacchetti basandosi sull'intestazione dei pacchetti stessi, ma determina se il collegamento fra le due parti sia valido secondo delle regole configurabili prima di aprire una sessione e autorizzare lo scambio di dati. Il filtraggio Ã¨ basato su:
></p>
>
><ul>
><li>Indirizzo sorgente/destinazione</li>
><li>Porta sorgente/destinazione</li>
><li>Un certo intervallo di tempo</li>
><li>Protocollo</li>
><li>Utente</li>
><li>Password</li>
></ul>
>
><p>
>Tutto il traffico Ã¨ validato, monitorato e se si tratta di traffico non desiderato puÃ² essere scartato.
></p>
>
><p>
>Debolezze:
></p>
>
><ul>
><li>
>Opera a livello di trasporto e puÃ² richiedere notevoli modifiche al tipo di programmazione che normalmente fornisce
>le funzioni di trasporto.
></li>
></ul>
>
></body>
></section>
>
><section>
><title>Application gateway (gateway d'applicazioni)</title>
><body>
>
><p>
>Il gateway a livello applicativo Ã¨ un proxy per applicazioni, che scambia quindi dati con un sistema remoto al posto dei suoi clienti. E' solitamente mantenuto per pubblica sicurezza dietro ad una DMZ (Zona DeMilitarizzata: parte di una rete privata che Ã¨ visibile attraverso il firewall) o un firewall senza alcuna connessione dall'esterno. Il filtraggio Ã¨ basato su:
></p>
>
><ul>
><li>Autorizzare o bloccare i pacchetti basandosi sull'indirizzo IP sorgente/destinazione</li>
><li>Autorizzare o bloccare i pacchetti basandosi sul contenuto dei pacchetti stessi</li>
><li>Limitare l'accesso ai file basandosi sul loro tipo o estensione</li>
></ul>
>
><p>
>Vantaggi:
></p>
>
><ul>
><li>PuÃ² mantenere i files nella sua memoria cache, aumentando le prestazioni della rete</li>
><li>PuÃ² registrare dettagliatamente ogni connessione</li>
><li>Scala perfettamente (alcuni proxy server possono "condividere" i dati nelle loro cache)</li>
><li>Nessun accesso diretto dall'esterno</li>
><li>PuÃ² modificare al volo il contenuto dei pacchetti</li>
></ul>
>
><p>
>Debolezze:
></p>
>
><ul>
><li>La configurazione Ã¨ complessa</li>
></ul>
>
><p>
>Gli application gateway sono considerati come le soluzioni piÃ¹ sicure poichÃ¨ non devono girare come root e gli host dietro di essi non sono raggiungibili pubblicamente da internet.
></p>
>
><p>
>Esempi di application gateway liberi:
></p>
>
><ul>
><li><uri link="http://www.squid-cache.org/">Squid</uri></li>
></ul>
>
></body>
></section>
>
><section>
><title>Iptables</title>
><body>
>
><p>
>Per far funzionare correttamente iptables, esso va abilitato nel kernel. Io l'ho aggiunto in forma di moduli (il comando <c>iptables</c> li caricherÃ  quando ne avrÃ  bisogno) ed ho ricompilato il mio kernel. Per maggiori informazioni su come configurare il vostro kernel per iptables fate riferimento a <uri link="http://iptables-tutorial.frozentux.net/chunkyhtml/kernelsetup.html">Iptables Tutorial Chapter 2: Preparations</uri>. Dopo averlo ricompilato (o mentre lo state ricompilando) dovete aggiungere il comando <c>iptables</c>. Basta dare <c>emerge iptables</c> ed esso dovrebbe funzionare.
></p>
>
><p>
>Ora proviamo se funziona lanciando <c>iptables -L</c>. Se dovesse fallire significa che manca qualcosa e dovrete quindi controllare nuovamente la vostra configurazione.
></p>
>
><p>
>Iptables Ã¨ il nuovo e notevolmente migliorato packet filter del kernel Linux 2.4.x. Esso Ã¨ il successore di ipchains, il precedente packet filter del kernel Linux 2.2.x. Uno dei maggiori miglioramenti Ã¨ che iptables Ã¨ in grado di compiere il filtraggio dei pacchetti in modo stateful. Con il filtraggio dei pacchetti stateful Ã¨ possibile mantenere una traccia per ogni connessione TCP stabilita.
></p>
>
><p>
>Una connessione TCP consiste in una serie di pacchetti contenenti informazioni circa l'indirizzo IP sorgente, l'indirizzo IP di destinazione, un numero di sequenza cosÃ¬ che i pacchetti possano essere riassemblati e non vadano persi i dati. TCP Ã¨ un protocollo connection-oriented (ndt, orientato alla connessione) al contrario di UDP che Ã¨ connectionless (ndt, senza connessione)
></p>
>
><p>
>Esaminando l'header di un pacchetto TCP un packet filter di tipo stateful puÃ² determinare se il pacchetto TCP ricevuto Ã¨ parte di una connessione giÃ  stabilita o meno e decidere quindi se accettare o scartare il pacchetto.
></p>
>
><p>
>Con un packet filter stateless Ã¨ possibile ingannare il packet filter affinchÃ¨ accetti pacchetti che dovrebbero essere scartati manipolando gli headers dei pacchetti TCP. CiÃ² puÃ² essere fatto manipolando la flag SYN o altre flags nell'header TCP. Con il filtraggio dei pacchetti di tipo stateful Ã¨ possibile scartare questi pacchetti poichÃ¨ non fanno parte di una connessione giÃ  stabilita. CiÃ² permette inoltre di bloccare la possibilitÃ  di "stealth scans" visto che tali pacchetti non fanno parte di una connessione giÃ  stabilita.
></p>
>
><p>
>Iptables fornisce molte altre funzionalitÃ  come il NAT (Network Address Translation) e la limitazione della frequenza (del "rate"). Quest'ultima possibilitÃ  Ã¨ estremamente utile quando ci si trova a dover prevenire certi attacchi DoS (Denial of Service, Negazione di Servizio) come gli attacchi di SYN floods.
></p>
>
><p>
>Una connessione TCP Ã¨ stabilita attraverso un meccanismo chiamato three-way handshake (ndt, letteralmente "stretta di mano a tre vie", indica la negoziazione della connessione che appunto avviene in tre passaggi). Per stabilire una connessione TCP dal lato client viene inviato un pacchetto al lato server con la flag SYN impostata. Quando il lato server riceve il pacchetto SYN risponde inviando a sua volta un pacchetto SYN+ACK al lato client. A questo punto, quando il SYN+ACK viene ricevuto il lato client risponde con un terzo pacchetto ACK con il quale riconosce il collegamento.
></p>
>
><p>
>Un attacco SYN flood Ã¨ effettuato inviando solamente pacchetti SYN senza rispondere al pacchetto SYN+ACK successivo. Dal lato client si puÃ² forgiare un pacchetto con un indirizzo IP sorgente fasullo (ndt, detto anche "fake") poichÃ¨ non necessita di alcuna risposta. Sul lato server il sistema aggiungerÃ  una voce alla coda delle connessioni aperte a metÃ  quando riceverÃ  un pacchetto SYN e aspetterÃ  quindi il pacchetto ACK finale prima di eliminare la relativa voce dalla coda. La coda ha un numero limitato di slots e se tutti gli slots sono occupati non Ã¨ possibile aprire qualsiasi altra connessione. Se il pacchetto ACK non Ã¨ ricevuto entro un certo intervallo prima del timeout stabilito, la voce relativa ad esso verrÃ  automaticamente cancellata dalla coda. Il valore del timeout Ã¨ variabile ma tipicamente Ã¨ compreso tra i 30-60 secondi o giÃ¹ di lÃ¬. Dal lato client si inizia l'attacco forgiando un certo numero di pacchetti SYN con differenti indirizzi IP sorgente e quindi li si spedisce all'indirizzo IP dell'obiettivo tanto piÃ¹ velocemente possibile in modo da saturare la coda delle connessioni aperte a metÃ  lato server, impedendo cosÃ¬ che gli altri client possano stabilire connessioni legittime con il server.
></p>
>
><p>
>E' a questo punto che la limitazione della frequenza diviene interessante. E' possibile limitare il numero di pacchetti SYN accettati utilizzando <c>-m limit --limit 1/s</c>. Questo limiterÃ  a uno per secondo i pacchetti SYN accettati riducendo dunque la possibilitÃ  di SYN flood sulle nostre risorse.
></p>
>	 
><note>
>Un'alternativa per prevenire i SYN flood sono i <uri link = "http://cr.yp.to/syncookies.html">SYN cookies</uri>, che consentono al sistema di rispondere ai pacchetti SYN senza occupare spazio nella code delle connessioni. I SYN cookies possono venire abilitati nella configurazione del kernel, ma attualmente sono considerati software sperimentale.
></note>
>
><p>
>Vediamo finalmente qualcosa di pratico!
></p>
>
><p>
>Quando iptables Ã¨ caricato nel kernel, ci sono cinque sezioni in cui potete piazzare le vostre regole. Queste sono chiamate <c>INPUT</c>, <c>OUTPUT</c>, <c>FORWARD</c>, <c>PREROUTING</c> e <c>POSTROUTING</c>. Ciascuna di esse Ã¨ chiamata catena (chain) e consiste in una lista di regole. Ogni regola controlla che l'header di ciascun pacchetto non corrisponda al proprio contenuto, quindi decide cosa fare del pacchetto stesso. Se la regola non corrisponde al pacchetto viene consultata la regola successiva nella catena.
></p>
>
><p>
>Potete aggiungere le vostre regole direttamente alle 5 catene principali o crearne di vostre aggiungendole a quelle esistenti. Iptables supporta le seguenti opzioni:
></p>
>
><table>
>  <tr>
>    <th>Opzione:</th><th>Descrizione:</th>
>  </tr>
>  <tr>
>    <ti>-A</ti><ti>Append (Aggiungi)</ti>
>  </tr>
>  <tr>
>    <ti>-D</ti><ti>Delete (Cancella</ti>
>  </tr>
>  <tr>
>    <ti>-I</ti><ti>Insert (Inserisci)</ti>
>  </tr>
>  <tr>
>    <ti>-R</ti><ti>Replace (Rimpiazza)</ti>
>  </tr>
>  <tr>
>    <ti>-L</ti><ti>List (Elenca)</ti>
>  </tr>
>  <tr>
>    <ti>-F</ti><ti>Cancella tutte le regole nella catena o in tutte le catene</ti>
>  </tr>
>  <tr>
>    <ti>-Z</ti><ti>Azzera i contatori in una catena o in tutte le catene</ti>
>  </tr>
>  <tr>
>    <ti>-C</ti><ti>Controlla questo pacchetto nella catena</ti>
>  </tr>
>  <tr>
>    <ti>-N</ti><ti>Crea una nuova catena definita dall'utente</ti>
>  </tr>
>  <tr>
>    <ti>-X</ti><ti>Cancella una catena definita dall'utente</ti>
>  </tr>
>  <tr>
>    <ti>-P</ti><ti>Imposta la politica di una catena su un obiettivo</ti>
>  </tr>
>  <tr>
>    <ti>-E</ti><ti>Cambia il nome di una catena</ti>
>  </tr>
>  <tr>
>    <ti>-p</ti><ti>Protocollo</ti>
>  </tr>
>  <tr>
>    <ti>-s</ti><ti>Indirizzo sorgente/maschera</ti>
>  </tr>
>  <tr>
>    <ti>-d</ti><ti>Indirizzo di destinazione/maschera</ti>
>  </tr>
>  <tr>
>    <ti>-i</ti><ti>Nome dell'Input (nome dell'interfaccia ethernet)</ti>
>  </tr>
>  <tr>
>    <ti>-o</ti><ti>Nome dell'Output (nome dell'interfaccia ethernet)</ti>
>  </tr>
>  <tr>
>    <ti>-j</ti><ti>Jump (obiettivo della regola)</ti>
>  </tr>
>  <tr>
>    <ti>-m</ti><ti>Corrispondenza estesa (potrebbe usare un'estensione)</ti>
>  </tr>
>  <tr>
>    <ti>-n</ti><ti>Output numerico di indirizzi e porte</ti>
>  </tr>
>  <tr>
>    <ti>-t</ti><ti>Tabella da manipolare</ti>
>  </tr>
>  <tr>
>    <ti>-v</ti><ti>ModalitÃ  verbosa (maggiori dettagli in output)</ti>
>  </tr>
>  <tr>
>    <ti>-x</ti><ti>Espandi i numeri (mostra i valori esatti)</ti>
>  </tr>
>  <tr>
>    <ti>-f</ti><ti>Considera il secondo frammento o quelli successivi</ti>
>  </tr>
>  <tr>
>    <ti>-V</ti><ti>Versione del pacchetto</ti>
>  </tr>
>  <tr>
>    <ti>--line-numbers</ti><ti>Stampa il numero della riga</ti>
>  </tr>
></table>
>
><p>
>Proveremo inizialmente a bloccare tutti i pacchetti ICMP sulla nostra macchina, giusto per familiarizzare con iptables.
></p>
>
><pre caption="Bloccare tutti i pacchetti ICMP">
># <i>iptables -A INPUT -p icmp -j DROP</i>
></pre>
>
><p>
>Per prima cosa specifichiamo la catena alla quale dovrÃ  appartenere la regola, successivamente indichiamo il protocollo e quindi l'obiettivo. L'obiettivo puÃ² essere il nome di una catena specificata dall'utente o uno degli obiettivi speciali <c>ACCEPT</c>, <c>DROP</c>, <c>REJECT</c>, <c>LOG</c>, <c>QUEUE</c>, <c>MASQUERADE</c>. In questo esempio, abbiamo utilizzato <c>DROP</c> che scarta i pacchetti senza rispondere al client.
></p>
>
><note>
>L'obiettivo <c>LOG</c> Ã© quello che si dice un obiettivo "non terminante" (ndt, non-terminating target). Se un pacchetto soddisfa una regola con obiettivo <c>LOG</c> invece di interromepere la valutazione delle regole, il pacchetto continua a essere confrontato con le regole successive. Questo consente di registrare un pacchetto mentro lo stesso continua a essere processato.
></note>
>
><p>
>Provate ora a fare <c>ping localhost</c>. Non dovreste ottenere nessuna risposta poichÃ¨ iptables scarta ogni messaggio ICMP in arrivo. Non sarÃ  possibile pingare neppure altre macchine poichÃ¨ i pacchetti ICMP di ritorno verranno scartati. Svuotiamo ora la catena riabilitando i pacchetti ICMP:
></p>
>
><pre caption="Eliminare tutte le regole">
># <i>iptables -F</i>
></pre>
>
><p>
>Osserviamo adesso la parte stateful del filtraggio dei pacchetti di iptables. Se volete fare 
>un'ispezione stateful dei pacchetti entranti in eth0 dovete abilitarla come segue:
></p>
>
><pre caption="Accettare i pacchetti originati da una qualsiasi connessione in corso">
># <i>iptables -A INPUT -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT</i>
></pre>
>
><p>
>Questo accetterÃ  ogni pacchetto facente parte di una connessione giÃ  stabilita o in relazione con essa nella catena di INPUT. Potete scartare tutti i pacchetti che non appartengono a uno stato valido nella tabella dando <c>iptables -A INPUT -i eth0 -m state --state INVALID -j DROP</c> come prima. CiÃ² attiverÃ  la parte stateful di iptables caricando l'estensione "state". Se volete che una macchina dall'esterno possa connettersi alla vostra dovrete usare <c>--state NEW</c>. Ipatables contiene molti moduli per differenti scopi. Alcuni di questi sono:
></p>
>
><table>
>  <tr>
>    <th>Modulo/Corrispondenza</th><th>Descrizione</th><th>Opzioni estese</th>
>  </tr>
>  <tr>
>    <ti>mac</ti><ti>Verifica la corrispondenza del mac address con l'estensione per i pacchetti in ingresso.</ti>
>    <ti>--mac-source</ti>
>  </tr>
>  <tr>
>    <ti>state</ti><ti>Abilita l'ispezione stateful</ti><ti>--state (gli stati sono ESTABLISHED,RELATED, INVALID, NEW)</ti>
>  </tr>
>  <tr>
>    <ti>limit</ti><ti>Definisce un limite di frequenza</ti><ti>--limit, --limit-burst</ti>
>  </tr>
>  <tr>
>    <ti>owner</ti><ti>Cerca di controllare diverse caratteristiche del creatore di un pacchetto</ti><ti>--uid-owner userid
>    --gid-owner groupid --pid-owner processid --sid-owner sessionid</ti>
>  </tr>
>  <tr>
>    <ti>unclean</ti><ti>Vari controlli casuali sulla validitÃ  di un pacchetto</ti><ti/>
>  </tr>
></table>
>
><p>
>Proviamo a creare una catena personalizzata a applicarla alle catene esistenti:
></p>
>
><pre caption="Creare una catena definita dall'utente">
><codenote>Creiamo una nuova catena con una regola</codenote>
># <i>iptables -X mychain</i>
># <i>iptables -N mychain</i>
># <i>iptables -A mychain -i eth0 -m state --state ESTABLISHED,RELATED -j ACCEPT</i>
><codenote>La politica di default Ã¨ che tutto il traffico in uscita Ã¨ autorizzato. Quello in ingresso bloccato.</codenote>
># <i>iptables -P OUTPUT ACCEPT</i>
># <i>iptables -P INPUT DROP</i>
><codenote>Aggiungiamola alla catena di INPUT</codenote>
># <i>iptables -A INPUT -j mychain</i>
></pre>
>
><p>
>Applicando questa regola alla catena di INPUT otteniamo questa politica: tutti i pacchetti in uscita sono autorizzati mentre tutti i pacchetti in ingresso vengono bloccati.
></p>
>
><p>
>Si puÃ² trovare la documentazione su <uri link="http://www.iptables.org/documentation/index.html#HOWTO">Documentazione di Netfilter/iptables</uri>.
></p>
>
><p>
>Studiamo ora un esempio completo. In questo caso le mie politiche per il firewall/gateway sono:
></p>
>
><ul>
>  <li>Sono permesse solo le connessioni al firewall tramite SSH (porta 22)</li>
>  <li>La rete locale deve avere accesso a HTTP, HTTPS e SSH (il DNS deve essere ugualmente autorizzato)</li>
>  <li>Il traffico ICMP puÃ² contenere dati quindi non deve essere permesso. Naturalmente ne autorizzeremo solo una parte.</li>
>  <li>I Port scan devono essere individuati e registrati</li>
>  <li>Gli attacchi SYN devono essere evitati</li>
>  <li>Tutto il traffico rimanente deve essere bloccato e registrato</li>
></ul>
>
><pre caption="/etc/init.d/firewall">
>#!/sbin/runscript
>IPTABLES=/sbin/iptables
>IPTABLESSAVE=/sbin/iptables-save
>IPTABLESRESTORE=/sbin/iptables-restore
>FIREWALL=/etc/firewall.rules
>DNS1=212.242.40.3
>DNS2=212.242.40.51
># interno
>IIP=10.0.0.2
>IINTERFACE=eth0
>LOCAL_NETWORK=10.0.0.0/24
># esterno
>OIP=217.157.156.144
>OINTERFACE=eth1
>
>opts="${opts} showstatus panic save restore showoptions rules"
>
>depend() {
>  need net
>}
>
>rules() {
>  stop
>  ebegin "Setting internal rules"
>
>  einfo "Setting default rule to drop"
>  $IPTABLES -P FORWARD DROP
>  $IPTABLES -P INPUT   DROP
>  $IPTABLES -P OUTPUT  DROP
>
>  # regole di default
>  einfo "Creating states chain"
>  $IPTABLES -N allowed-connection
>  $IPTABLES -F allowed-connection
>  $IPTABLES -A allowed-connection -m state --state ESTABLISHED,RELATED -j ACCEPT
>  $IPTABLES -A allowed-connection -i $IINTERFACE -m limit -j LOG --log-prefix \ 
>      "Bad packet from ${IINTERFACE}:"
>  $IPTABLES -A allowed-connection -j DROP
>
>  # traffico ICMP
>  einfo "Creating icmp chain"
>  $IPTABLES -N icmp_allowed
>  $IPTABLES -F icmp_allowed
>  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \ 
>      time-exceeded -j ACCEPT
>  $IPTABLES -A icmp_allowed -m state --state NEW -p icmp --icmp-type \ 
>      destination-unreachable -j ACCEPT
>  $IPTABLES -A icmp_allowed -p icmp -j LOG --log-prefix "Bad ICMP traffic:"
>  $IPTABLES -A icmp_allowed -p icmp -j DROP
>
>  # traffico in ingresso
>  einfo "Creating incoming ssh traffic chain"
>  $IPTABLES -N allow-ssh-traffic-in
>  $IPTABLES -F allow-ssh-traffic-in
>  # protezione dai flood
>  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
>      ALL RST --dport ssh -j ACCEPT
>  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
>      ALL FIN --dport ssh -j ACCEPT
>  $IPTABLES -A allow-ssh-traffic-in -m limit --limit 1/second -p tcp --tcp-flags \ 
>      ALL SYN --dport ssh -j ACCEPT
>  $IPTABLES -A allow-ssh-traffic-in -m state --state RELATED,ESTABLISHED -p tcp --dport ssh -j ACCEPT
>
>  # traffico in uscita
>  einfo "Creating outgoing ssh traffic chain"
>  $IPTABLES -N allow-ssh-traffic-out
>  $IPTABLES -F allow-ssh-traffic-out
>  $IPTABLES -A allow-ssh-traffic-out -p tcp --dport ssh -j ACCEPT
>
>  einfo "Creating outgoing dns traffic chain"
>  $IPTABLES -N allow-dns-traffic-out
>  $IPTABLES -F allow-dns-traffic-out
>  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS1 --dport domain \ 
>      -j ACCEPT
>  $IPTABLES -A allow-dns-traffic-out -p udp -d $DNS2 --dport domain \ 
>     -j ACCEPT
>
>  einfo "Creating outgoing http/https traffic chain"
>  $IPTABLES -N allow-www-traffic-out
>  $IPTABLES -F allow-www-traffic-out
>  $IPTABLES -A allow-www-traffic-out -p tcp --dport www -j ACCEPT
>  $IPTABLES -A allow-www-traffic-out -p tcp --dport https -j ACCEPT
>
>  # individuare i portscanners
>  einfo "Creating portscan detection chain"
>  $IPTABLES -N check-flags
>  $IPTABLES -F check-flags
>  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -m limit \ 
>      --limit 5/minute -j LOG --log-level alert --log-prefix "NMAP-XMAS:" 
>  $IPTABLES -A check-flags -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
>  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -m limit --limit \ 
>      5/minute -j LOG --log-level 1 --log-prefix "XMAS:"
>  $IPTABLES -A check-flags -p tcp --tcp-flags ALL ALL -j DROP
>  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG \ 
>      -m limit --limit 5/minute -j LOG --log-level 1 --log-prefix "XMAS-PSH:"
>  $IPTABLES -A check-flags -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
>  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -m limit \ 
>      --limit 5/minute -j LOG --log-level 1 --log-prefix "NULL_SCAN:"
>  $IPTABLES -A check-flags -p tcp --tcp-flags ALL NONE -j DROP
>  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -m limit \ 
>      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/RST:"
>  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
>  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -m limit \ 
>      --limit 5/minute -j LOG --log-level 5 --log-prefix "SYN/FIN:"
>  $IPTABLES -A check-flags -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP
>
>  # applicare e aggiungere gli stati non validi alle catene
>  einfo "Applying chains to INPUT"
>  $IPTABLES -A INPUT -m state --state INVALID -j DROP
>  $IPTABLES -A INPUT -j icmp_allowed 
>  $IPTABLES -A INPUT -j check-flags
>  $IPTABLES -A INPUT -i lo -j ACCEPT
>  $IPTABLES -A INPUT -j allow-ssh-traffic-in
>  $IPTABLES -A INPUT -j allowed-connection
>
>  einfo "Applying chains to FORWARD"
>  $IPTABLES -A FORWARD -m state --state INVALID -j DROP
>  $IPTABLES -A FORWARD -j icmp_allowed 
>  $IPTABLES -A FORWARD -j check-flags
>  $IPTABLES -A FORWARD -o lo -j ACCEPT
>  $IPTABLES -A FORWARD -j allow-ssh-traffic-in
>  $IPTABLES -A FORWARD -j allow-www-traffic-out
>  $IPTABLES -A FORWARD -j allowed-connection
>
>  einfo "Applying chains to OUTPUT"
>  $IPTABLES -A OUTPUT -m state --state INVALID -j DROP
>  $IPTABLES -A OUTPUT -j icmp_allowed
>  $IPTABLES -A OUTPUT -j check-flags
>  $IPTABLES -A OUTPUT -o lo -j ACCEPT
>  $IPTABLES -A OUTPUT -j allow-ssh-traffic-out
>  $IPTABLES -A OUTPUT -j allow-dns-traffic-out
>  $IPTABLES -A OUTPUT -j allow-www-traffic-out
>  $IPTABLES -A OUTPUT -j allowed-connection
>
>  # abilitare l'instradamento dei client tramite NAT (Network Address Translation)
>  $IPTABLES -t nat -A POSTROUTING -o $IINTERFACE -j MASQUERADE 
>  eend $?
>}
>
>start() {
>  ebegin "Starting firewall"
>  if [ -e "${FIREWALL}" ]; then
>    restore
>  else
>    einfo "${FIREWALL} does not exists. Using default rules."
>    rules
>  fi
>  eend $?
>}
>
>stop() {
>  ebegin "Stopping firewall"
>  $IPTABLES -F
>  $IPTABLES -t nat -F
>  $IPTABLES -X
>  $IPTABLES -P FORWARD ACCEPT
>  $IPTABLES -P INPUT   ACCEPT
>  $IPTABLES -P OUTPUT  ACCEPT
>  eend $?
>}
>
>showstatus() {
>  ebegin "Status"
>  $IPTABLES -L -n -v --line-numbers
>  einfo "NAT status"
>  $IPTABLES -L -n -v --line-numbers -t nat
>  eend $?
>}
>
>panic() {
>  ebegin "Setting panic rules"
>  $IPTABLES -F
>  $IPTABLES -X
>  $IPTABLES -t nat -F
>  $IPTABLES -P FORWARD DROP
>  $IPTABLES -P INPUT   DROP
>  $IPTABLES -P OUTPUT  DROP
>  $IPTABLES -A INPUT -i lo -j ACCEPT
>  $IPTABLES -A OUTPUT -o lo -j ACCEPT
>  eend $?
>}
>
>save() {
>  ebegin "Saving Firewall rules"
>  $IPTABLESSAVE &gt; $FIREWALL
>  eend $?
>}
>
>restore() {
>  ebegin "Restoring Firewall rules"
>  $IPTABLESRESTORE &lt; $FIREWALL
>  eend $?
>}
>
>restart() {
>  svc_stop; svc_start
>}
>
>showoptions() {
>  echo "Usage: $0 {start|save|restore|panic|stop|restart|showstatus}"
>  echo "start)      will restore setting if exists else force rules"
>  echo "stop)       delete all rules and set all to accept"
>  echo "rules)      force settings of new rules"
>  echo "save)       will store settings in ${FIREWALL}"
>  echo "restore)    will restore settings from ${FIREWALL}"
>  echo "showstatus) Shows the status" 
>}
></pre>
>
><p>
>Qualche consiglio per creare un firewall:
></p>
>
><ol>
>  <li>Create la vostra politica per il firewall prima di implemetarlo</li>
>  <li>Fate cose semplici</li>
>  <li>Imparate come funzionano i protocolli (leggete le <uri link="http://www.ietf.org/">RFC</uri> (Request For Comments))
>  </li>
>  <li>Tenete bene a mente che un firewall non Ã¨ che un altro software che gira come root</li>
>  <li>Provate e testate il vostro firewall</li>
></ol>
>
><p>
>Se pensate che iptables sia troppo difficile da padroneggiare o che vi possa rubare troppo tempo per 
>impostare decentemente il firewall, potete utilizzare <uri link="http://www.shorewall.net">Shorewall</uri>. 
>Fondamentalmente usa iptables per generare le regole del firewall, ma si concentra sulle regole e non 
>sullo specifico protocollo.
></p>
>
></body>
></section>
>
><section>
><title>Squid</title>
><body>
>
><p>
>Squid Ã¨ un server proxy veramente potente e puÃ² filtrare il traffico basandosi su: tempo,
>espressioni regolari su percorsi/uri, indirizzo (IP) sorgente e destinazione, dominio, browser, 
>autenticazione del nome utente, tipo MIME e numero di porta (protocollo). Probabilmente avrÃ² dimenticato 
>qualche funzionalitÃ , ma Ã¨ veramente difficile ricordarsi l'intera lista.
></p> 
>
><p>
>Nell'esempio seguente ho aggiunto un filtro per i banner piuttosto che un filtro basato su siti pornografici. 
>La ragione di questa scelta Ã¨ che Gentoo.org <e>non</e> dovrebbe essere classificato come un sito a carattere
>pornografico. E non voglio perdere il mio tempo cercando di trovare dei buoni indirizzi per voi.
></p>
>
><p>
>In questo esempio, la mia politica Ã¨ la seguente:
></p>
>
><ul>
>  <li>La navigazione (HTTP/HTTPS) Ã¨ permessa nelle ore lavorative (lun-ven 8-17 e sab 8-13) poichÃ¨ se qualcuno resta 
>  fino a tardi, dovrebbe lavorare e non navigare</li>
>  <li>Il download non Ã¨ permesso (.exe, .com, .arj, .zip, .asf, .avi, .mpg, .mpeg etc.)</li>
>  <li>Non amiamo i banners quindi li filtriamo e sostituiamo con gif trasparenti (Ã¨ qui che potete dimostrarvi creativi!)
>  </li>
></ul>
>
><p>
>Tutto questo Ã¨ implememntato in 4 <e>facili</e> passi:
></p>
>
><pre caption="/etc/squid/squid.conf">
># Collega a un ip e una porta
>http_port 10.0.2.1:3128
>
># Configurazione standard
>hierarchy_stoplist cgi-bin ?
>acl QUERY urlpath_regex cgi-bin \?
>no_cache deny QUERY
>
># Aggiunge una basilare lista di controllo degli accessi
>acl all src 0.0.0.0/0.0.0.0
>acl manager proto cache_object
>acl localhost src 127.0.0.1/255.255.255.255
>
># Aggiunge chi puÃ² accedere a questo server proxy
>acl localnet src 10.0.0.0/255.255.0.0
>
># e le porte
>acl SSL_ports port 443
>acl Safe_ports port 80
>acl Safe_ports port 443
>acl purge method PURGE
>
># Aggiunge una lista di controllo degli accessi basata su
># espressioni regolari con urls
>acl archives urlpath_regex "/etc/squid/files.acl"
>acl url_ads url_regex "/etc/squid/banner-ads.acl"
>
># e una lista di controllo degli accessi basata sull'ora e il giorno
>acl restricted_weekdays time MTWHF 8:00-17:00
>acl restricted_weekends time A 8:00-13:00
>
>acl CONNECT method CONNECT
>
># Abilita l'accesso manager da locale
>http_access allow manager localhost
>http_access deny manager
>
># Permette la richiesta di svuotamento della cache solo da locale
>http_access allow purge localhost
>http_access deny purge
>
># Nega le richieste di connessione a porte sconosciute
>http_access deny !Safe_ports
>
># Nega le connessioni a porte che non siano quella SSL
>http_access deny CONNECT !SSL_ports
>
># Regole personali
>
># Aggiunge una pagina da visualizzare quando
># un banner Ã¨ rimosso
>deny_info NOTE_ADS_FILTERED url_ads
>
># dopo un rifiuto
>http_access deny url_ads
>
># Blocca tutti gli archivi
>http_access deny archives
>
># Restringe l'accesso alle ore lavorative
>http_access allow localnet restricted_weekdays
>http_access allow localnet restricted_weekends
>
># Blocca il resto
>http_access deny all
></pre>
>
><p>
>Elencate adesso i file che non volete sia permesso scaricare ai vostri utenti. Io ho aggiunto i file zip, viv, exe, mp3,
>rar, ace, avi, mov, mpg, mpeg, au, ra, arj, tar, gz e z.
></p>
>
><pre caption="/etc/squid/files.acl">
>\.[Zz][Ii][pP]$
>\.[Vv][Ii][Vv].*
>\.[Ee][Xx][Ee]$
>\.[Mm][Pp]3$
>\.[Rr][Aa][Rr]$
>\.[Aa][Cc][Ee]$
>\.[Aa][Ss][Ff]$
>\.[Aa][Vv][Ii]$
>\.[Mm][Oo][Vv]$
>\.[Mm][Pp][Gg]$
>\.[Mm][Pp][Ee][Gg]$
>\.[Aa][Uu]$
>\.[Rr][Aa]$
>\.[Aa][Rr][Jj]$
>\.[Tt][Aa][Rr]$
>\.[Gg][Zz]$
>\.[Zz]$
></pre>
>
><note>
>Si notino le [] contenenti maiuscole e minuscole per ogni carattere. CiÃ² assicura che non sia possibile scaricare file che
>invece di avere estensione avi, per esempio, abbiano qualcosa come Avi, AVi e cosÃ¬ via.
></note>
>
><p>
>Ora aggiungiamo le espressioni regolari per identificare i banners. Sarete sicuramente molto piÃ¹ creativi di me:
></p>
>
><pre caption="/etc/squid/banner-ads.acl">
>/adv/.*\.gif$
>/[Aa]ds/.*\.gif$
>/[Aa]d[Pp]ix/
>/[Aa]d[Ss]erver
>/[Aa][Dd]/.*\.[GgJj][IiPp][FfGg]$
>/[Bb]annerads/
>/adbanner.*\.[GgJj][IiPp][FfGg]$
>/images/ad/
>/reklame/
>/RealMedia/ads/.*
>^http://www\.submit-it.*
>^http://www\.eads.*
>^http://ads\.
>^http://ad\.
>^http://ads02\.
>^http://adaver.*\.
>^http://adforce\.
>adbot\.com
>/ads/.*\.gif.*
>_ad\..*cgi
>/Banners/
>/SmartBanner/
>/Ads/Media/Images/
>^http://static\.wired\.com/advertising/
>^http://*\.dejanews\.com/ads/
>^http://adfu\.blockstackers\.com/
>^http://ads2\.zdnet\.com/adverts
>^http://www2\.burstnet\.com/gifs/
>^http://www.\.valueclick\.com/cgi-bin/cycle
>^http://www\.altavista\.com/av/gifs/ie_horiz\.gif
></pre>
>
><p>
>Eccoci alle ultime battute. Vogliamo sia visualizzato questo file quando rimuoviamo un banner. Si tratta di 
>un file html a metÃ  con una immagine gif trasparente 4x4.
></p>
>
><pre caption="/etc/squid/errors/NOTE_ADS_FILTERED">
>&lt;HTML&gt;
>&lt;HEAD&gt;
>&lt;META HTTP-EQUIV="REFRESH" CONTENT="0; URL=http://localhost/images/4x4.gif"&gt;
>&lt;TITLE>ERROR: The requested URL could not be retrieved&lt;/TITLE&gt;
>&lt;/HEAD&gt;
>&lt;BODY&gt;
>&lt;H1&gt;Add filtered!&lt;/H1&gt;
></pre>
>
><note>
>Non chiudete le tag &lt;HTML&gt; &lt;BODY&gt;. Se ne occuperÃ  squid.
></note>
>
><p>
>Come potete notare squid presenta molte possibilitÃ  di utilizzo ed Ã¨ veramente efficace nel filtraggio di contenuti nonchÃ¨
>come proxy. E' inoltre possibile usare diversi proxies squid per scalare agevolmente in reti molto grandi. La configurazione
>che ho mostrato si adatta ad una rete di piccole dimensioni con 1-20 utenti.
></p>
>
><p>
>Ma la soluzione migliore Ã¨ probabilmente combinare un firewall packet filter (iptables) e un gateway 
>applicativo (squid), anche se squid Ã¨ situato in un posto sicuro e non accessibile dall'esterno. Ricordatevi 
>sempre che un attacco puÃ² venire sferrato anche dall'interno.
></p>
>
><p>
>Ora dovrete impostare i vostri browser affinchÃ¨ utilizzino il server proxy. CosÃ¬ il gateway non permetterÃ  a nessun utente di avere contatti con l'esterno se non attraverso di lui.
></p>
>
><note>
>In Mozilla puÃ² essere impostato nel menu Edit->Preferences->Advanced->Proxies.
></note>
>
><p>
>E' possibile inoltre fare tutto questo in modo trasparente usando iptables per reindirizzare tutto il traffico in uscita verso il proxy squid. Questo puÃ² essere fatto aggiungendo un paio di regole di 
>forwarding/prerouting sul gateway:
></p>
>
><pre caption="Abilitare il portforwarding verso il server proxy">
># <i>iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to proxyhost:3128</i>
># <i>iptables -t nat -A PREROUTING -p tcp --dport 443 -j DNAT --to proxyhost:3128</i>
></pre>
>
><note>
>Se il server proxy gira sulla stessa macchina che esegue il filtraggio dei pacchetti (non Ã© raccomandabile adottare una soluzione del genere, ma in alcune circostanze, ad esempio se non si hanno macchine a sufficienza, potrebbe essere necessario farlo) si puÃ² usare l'obiettivo <c>REDIRECT</c> invece di <c>DNAT</c> (<c>REDIRECT</c> dirige i pacchetti all'host locale).
></note>
>
></body>
></section>
>
><section>
><title>Cosa abbiamo imparato?</title>
>
><body>
>
><p>
>Abbiamo imparato che:
></p>
>
><ol>
>  <li>Un firewall puÃ² essere un rischio. Una cattiva configurazione Ã¨ spesso piÃ¹ pericolosa che non avere un firewall.</li>
>  <li>Come configurare un gateway e un proxy trasparente</li>
>  <li>La chiave di un buon firewall Ã¨ conoscere i protocolli che vogliamo autorizzare</li>
>  <li>Che il traffico IP non sempre contiene dati legittimi. Per esempio i pacchetti ICMP con un payload</li>
>  <li>Come prevenire un attacco SYN</li>
>  <li>Filtrare il traffico HTTP rimuovendo le immagini offensive e il download di virus.</li>
>  <li>Combinare un packet filter e un gateway applicativo permette di avere un maggiore controllo</li>
></ol>
>
><p>
>Ora, se ne avete <e>realmente</e> bisogno, potete creare un firewall che risponda ai vostri bisogni.
></p>
>
></body>
></section>
>
></chapter>
>
><chapter>
><title>Rilevazione delle intrusioni</title>
>
><section>
><title>AIDE (Advanced Intrusion Detection Environment)</title>
><body>
>
><p>
>AIDE Ã¨ un sistema di rilevazione delle intrusioni pensato per gli host (ndt, Host-Based Intrusion Detection System, HIDS ), un'alternativa libera a Tripwire. Gli HIDS vengono usati per individuare cambiamenti nei file di configurazione e negli eseguibili, generalmente calcolando un hash unico per ogni file. Regolarmente vengono controllati gli hash dei file presenti sul sistema e vengono confrontati con gli hash dei file originali. Gli HIDS sono un ottimo strumento per individuare cambiamenti indesiderati sul sistema, ma richiedono un po' di lavoro per essere implementati correttamente e per farne un buon uso.
></p>
>
><p>
>Il file di configurazione Ã¨ basato su espressioni regolari, macro e regole per file e directory. Abbiamo a disposizione le seguenti macro:
></p>
>
><table>
>  <tr>
>    <th>Macro</th><th>Descrizione</th><th>Sintassi</th>
>  </tr>
>  <tr>
>    <ti>ifdef</ti><ti>Se definito</ti><ti>@@ifdef "nome"</ti>
>  </tr>
>  <tr>
>    <ti>ifndef</ti><ti>Se non definito</ti><ti>@@ifndef "nome"</ti>
>  </tr>
>  <tr>
>    <ti>define</ti><ti>Definisce una variabile </ti><ti>@@define "nome" "valore"</ti>
>  </tr>
>  <tr>
>    <ti>undef</ti><ti>Rilascia una variabile</ti><ti>@@undef "nome"</ti>
>  </tr>
>  <tr>
>    <ti>ifhost</ti><ti>Se "hostname"</ti><ti>@@ifhost "hostname"</ti>
>  </tr>
>  <tr>
>    <ti>ifnhost</ti><ti>Se non "hostname"</ti><ti>@@ifnhost "hostname"</ti>
>  </tr>
>  <tr>
>    <ti>endif</ti><ti>Endif va utilizzato dopo una qualsiasi delle precednti macro ad eccezione di define e undef</ti>
>    <ti>@@endif</ti>
>  </tr>
></table>
>
><p>
>Queste macro risultano veramente pratiche se avete piÃ¹ di una Gentoo box e volete servirvi di AIDE su ciascuna di esse.
>Infatti non tutte le macchine forniscono gli stessi servizi o hanno i medesimi utenti.
></p>
>
><p>
>Dobbiamo successivamente impostare le flags che verificheranno file o directory. Queste flags rappresentano una combinazione
>di permessi, proprietÃ  dei file e hashes crittografici/checksums.
></p>
>
><table>
>  <tr>
>    <th>Flag</th><th>Descrizione</th>
>  </tr>
>  <tr>
>    <ti>p</ti><ti>permessi</ti>
>  </tr>
>  <tr>
>    <ti>i</ti><ti>inode</ti>
>  </tr>
>  <tr>
>    <ti>n</ti><ti>numero di links</ti>
>  </tr>
>  <tr>
>    <ti>u</ti><ti>utente</ti>
>  </tr>
>  <tr>
>    <ti>g</ti><ti>gruppo</ti>
>  </tr>
>  <tr>
>    <ti>s</ti><ti>dimensione (size)</ti>
>  </tr>
>  <tr>
>    <ti>b</ti><ti>contatore di blocchi (block count)</ti>
>  </tr>
>  <tr>
>    <ti>m</ti><ti>mtime</ti>
>  </tr>
>  <tr>
>    <ti>a</ti><ti>atime</ti>
>  </tr>
>  <tr>
>    <ti>c</ti><ti>ctime</ti>
>  </tr>
>  <tr>
>    <ti>S</ti><ti>controllo sull'aumento delle dimensioni</ti>
>  </tr>
>  <tr>
>    <ti>md5</ti><ti>md5 checksum</ti>
>  </tr>
>  <tr>
>    <ti>sha1</ti><ti>sha1 checksum</ti>
>  </tr>
>  <tr>
>    <ti>rmd160</ti><ti>rmd160 checksum</ti>
>  </tr>
>  <tr>
>    <ti>tiger</ti><ti>tiger checksum</ti>
>  </tr>
>  <tr>
>    <ti>R</ti><ti>p+i+n+u+g+s+m+c+md5</ti>
>  </tr>
>  <tr>
>    <ti>L</ti><ti>p+i+n+u+g</ti>
>  </tr>
>  <tr>
>    <ti>E</ti><ti>gruppo vuoto</ti>
>  </tr>
>  <tr>
>    <ti>&gt;</ti><ti>file di log crescente p+u+g+i+n+S</ti>
>  </tr>
></table>
>
><p>
>Se AIDE Ã¨ compilato con il supporto mhash avremo a disposizione altre funzionalitÃ :
></p>
>
><table>
>  <tr>
>    <th>Flag</th><th>Descrizione</th>
>  </tr>
>  <tr>
>    <ti>haval</ti><ti>haval checksum</ti>
>  </tr>
>  <tr>
>    <ti>gost</ti><ti>gost checksum</ti>
>  </tr>
>  <tr>
>    <ti>crc32</ti><ti>crc32 checksum</ti>
>  </tr>
></table>
>
><p>
>Ora potete creare le vostre regole personali basandovi sulle flags precedenti, combinandole cosÃ¬:
></p>
>
><pre caption="Creare aun insieme di regole per AIDE">
>All=R+a+sha1+rmd160
>Norm=s+n+b+md5+sha1+rmd160
></pre>
>
><p>
>L'ultima cosa che avremo bisogno di fare per creare un file di configurazione personale Ã¨ di guardare come aggiungere regole
>a file e directory. Fondamentalmente avrete bisogno soltanto del nome del file o della directory seguiti da una regola.
>AIDE aggiungerÃ  tutti i file ricorsivamente, a meno che specifichiate un diverso comportamento.
></p>
>
><table>
>  <tr>
>    <th>Flag</th><th>Descrizione</th>
>  </tr>
>  <tr>
>    <ti>!</ti><ti>Non aggiungere questo file o directory.</ti>
>  </tr>
>  <tr>
>    <ti>=</ti><ti>Aggiungi questa directory, ma non ricorsivamente.</ti>
>  </tr>
></table>
>
><p>
>Guardiamo dunque un esempio completo
></p>
>
><pre caption="/etc/aide/aide.conf">
>@@ifndef TOP DIR 
>@@define TOPDIR /
>@@endif
>
>@@ifndef AIDEDIR 
>@@define AIDEDIR /etc/aide
>@@endif
>
>@@ifhost smbserv
>@@define smbactive
>@@endif
>
># La locazione da cui leggere il database.
>database=file:@@{AIDEDIR}/aide.db
>
># La locazione in cui scrivere il database.
>database_out=file:aide.db.new
>
>verbose=20
>report_url=stdout
>
># Definizione delle regole
>All=R+a+sha1+rmd160
>Norm=s+n+b+md5+sha1+rmd160
>
>@@{TOPDIR} Norm
>!@@{TOPDIR}etc/aide
>!@@{TOPDIR}dev
>!@@{TOPDIR}proc
>!@@{TOPDIR}root
>!@@{TOPDIR}tmp
>!@@{TOPDIR}var/log
>!@@{TOPDIR}var/run
>!@@{TOPDIR}usr/portage
>@@ifdef smbactive
>!@@{TOPDIR}etc/smb/private/secrets.tdb
>@@endif
>=@@{TOPDIR}home Norm
></pre>
>
><p>
>Nell'esempio precedente abbiamo usato alcune macro per indicare la directory iniziale e la posizione della directory di AIDE.
>AIDE controlla il file <path>/etc/aide/aide.db</path> quando deve verificare l'integritÃ  dei file. Ma quando
>aggiorna o crea un nuovo file mette le informazioni ottenute in <path>/etc/aide/aide.db.new</path>. Questo Ã¨ fatto per
>evitare che si sovrascriva automaticamente il precedente file contenente il database. L'opzione 
><c>report_URL</c> Ã¨ ancora in fase di implementazione, dunque non ha ancora una reale utilitÃ . Gli autori comunque hanno intenzione di servirsene per inviare una mail o per eseguire uno script.
></p>
>
><p>
>Dopo aver modificato la configurazione dovrete creare il vostro file db eseguendo <c>aide -i</c> e copiando il file
><path>/etc/aide/aide.db.new</path> in <path>/etc/aide/aide.db</path>, quindi dovrete aggiungere il controllo a crontab
>eseguendo <c>crontab -e</c> come root.
></p>
>
><note>Questa operazione puÃ² richiedere diverso tempo, a seconda della vostra cpu, la velocitÃ  d'accesso del vostro disco e quali flags avete impostato nel vostro file.</note>
>
><pre caption="Programmare l'esecuzione di aide in un cronjob">
>0 3   * * * /usr/bin/aide -u
></pre>
><note>Ricordatevi di impostare correttamente la ricezione della posta di root. In caso contrario potreste non ricevere
>nulla di ciÃ² che Aide vi riferisce.</note>
>
><p>
>In questo esempio verrÃ  avviato automaticamente alle 3 del mattino. CiÃ² per assicurarsi che non sia di disturbo
>agli utenti mentre lavorano. Notate che ho usato l'opzione <c>-u</c> (Update, Aggiorna) al posto di <c>-C</c> 
>(Check, Controlla). Questo perchÃ¨ <c>-u</c> controlla ugualmente i file ma non sovrascrive il db originale; lo
>salva per un certo periodo di tempo, cosÃ¬ ciÃ² che vi resta da fare Ã¨ copiare il file quando Ã¨ stato individuato
>qualche cambiamento. Prima di copiare le modifiche assicuratevi soltanto che siano state fatte da voi stessi e
>non da qualche attaccante!
></p>
>
><p>
>C'Ã¨ perÃ² un problema con l'archiviazione in locale del file del db poichÃ¨ un attaccante (se sa che aide Ã¨ installato)
>cercherÃ  sicuramente di alterare il file del db, aggiornarlo o modificare <path>/usr/bin/aide</path>. 
>Quindi create una copia del file .db e dei binari di Aide su un CD o altro mezzo rimovibile.
></p>
>
><p>
>Si puÃ² trovare la documentazione sulla pagine web del progetto <uri link="http://www.cs.tut.fi/~rammer/aide.html">Aide</uri>.
></p>
>
></body>
></section>
>
><section>
><title>Snort</title>
><body>
>
><p>
>Snort Ã¨ un Network Intrusion Detection System (NIDS). Per installarlo e configurarlo servitevi del seguente 
>esempio.
></p>
>
><pre caption="Aggiungere un utente snort al sistema">
># user add snort -d /var/log/snort -s /dev/null
># chown -R snort /var/log/snort
></pre>
>
><pre caption="/etc/conf.d/snort">
>PID FILE=/var/run/snort_eth0.pid
>MODE="full"
>NETWORK="10.0.0.0/24"
>LOG DIR="/var/log/snort"
>CO NF=/etc/snort/snort.conf
>SNORT_OPTS="-D -s -u snort -dev -l $LOGDIR -h $NETWORK -c $CONF"
></pre>
>
><pre caption="/etc/snort/snort.conf">
><codenote>Passo 1</codenote>
>var HOME_NET 10.0.0.0/24
>var EXTERNAL_NET any
>var SMTP $HOME_NET
>var HTTP_SERVERS $HOME_NET
>var SQL_SERVERS $HOME_NET
>var DNS_SERVERS [10.0.0.2/32,212.242.40.51/32]
>var RULE_PATH ./
>
><codenote>Passo 2</codenote>
>preprocessor frag2
>preprocessor stream4: detect_scans detect_state_problems detect_scans disable_evasion_alerts
>preprocessor stream4_reassemble: ports all
>preprocessor http_decode: 80 8080 unicode iis_alt_unicode double_encode iis_flip_slash full_whitespace
>preprocessor rpc_decode: 111 32771
>preprocessor bo: -nobrute
>preprocessor telnet_decode
>
><codenote>Passo 3</codenote>
>include classification.config
>
><codenote>Passo 4</codenote>
>include $RULE_PATH/bad-traffic.rules
>include $RULE_PATH/exploit.rules
>include $RULE_PATH/scan.rules
>include $RULE_PATH/finger.rules
>include $RULE_PATH/ftp.rules
>include $RULE_PATH/telnet.rules
>include $RULE_PATH/smtp.rules
>include $RULE_PATH/rpc.rules
>include $RULE_PATH/rservices.rules
>include $RULE_PATH/dos.rules
>include $RULE_PATH/ddos.rules
>include $RULE_PATH/dns.rules
>include $RULE_PATH/tftp.rules
>include $RULE_PATH/web-cgi.rules
>include $RULE_PATH/web-coldfusion.rules
>include $RULE_PATH/web-iis.rules
>include $RULE_PATH/web-frontpage.rules
>include $RULE_PATH/web-misc.rules
>include $RULE_PATH/web-attacks.rules
>include $RULE_PATH/sql.rules
>include $RULE_PATH/x11.rules
>include $RULE_PATH/icmp.rules
>include $RULE_PATH/netbios.rules
>include $RULE_PATH/misc.rules
>include $RULE_PATH/attack-responses.rules
>include $RULE_PATH/backdoor.rules
>include $RULE_PATH/shellcode.rules
>include $RULE_PATH/policy.rules
>include $RULE_PATH/porn.rules
>include $RULE_PATH/info.rules
>include $RULE_PATH/icmp-info.rules
>include $RULE_PATH/virus.rules
># include $RULE_PATH/experimental.rules
>include $RULE_PATH/local.rules
></pre>
>
><pre caption="/etc/snort/classification.config">
>config classification: not-suspicious,Not Suspicious Traffic,3
>config classification: unknown,Unknown Traffic,3
>config classification: bad-unknown,Potentially Bad Traffic, 2
>config classification: attempted-recon,Attempted Information Leak,2
>config classification: successful-recon-limited,Information Leak,2
>config classification: successful-recon-largescale,Large Scale Information Leak,2
>config classification: attempted-dos,Attempted Denial of Service,2
>config classification: successful-dos,Denial of Service,2
>config classification: attempted-user,Attempted User Privilege Gain,1
>config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
>config classification: successful-user,Successful User Privilege Gain,1
>config classification: attempted-admin,Attempted Administrator Privilege Gain,1
>config classification: successful-admin,Successful Administrator Privilege Gain,1
>
># NEW CLASSIFICATIONS
>config classification: rpc-portmap-decode,Decode of an RPC Query,2
>config classification: shellcode-detect,Executable code was detected,1
>config classification: string-detect,A suspicious string was detected,3
>config classification: suspicious-filename-detect,A suspicious filename was detected,2
>config classification: suspicious-login,An attempted login using a suspicious username was detected,2
>config classification: system-call-detect,A system call was detected,2
>config classification: tcp-connection,A TCP connection was detected,4
>config classification: trojan-activity,A Network Trojan was detected, 1
>config classification: unusual-client-port-connection,A client was using an unusual port,2
>config classification: network-scan,Detection of a Network Scan,3
>config classification: denial-of-service,Detection of a Denial of Service Attack,2
>config classification: non-standard-protocol,Detection of a non-standard protocol or event,2
>config classification: protocol-command-decode,Generic Protocol Command Decode,3
>config classification: web-application-activity,access to a potentially vulnerable web application,2
>config classification: web-application-attack,Web Application Attack,1
>config classification: misc-activity,Misc activity,3
>config classification: misc-attack,Misc Attack,2
>config classification: icmp-event,Generic ICMP event,3
>config classification: kickass-porn,SCORE! Get the lotion!,1
></pre>
>
><p>
>Maggiori informazioni possono essere trovate sul sito web di <uri link="http://www.snort.org">Snort</uri>.
></p>
>
></body>
></section>
>
><section>
><title>Individuazione di malware con chkrootkit</title>
>  	 
><body>
>  	 
><p>
>Gli HIDS come AIDE sono un modo eccellente per individuare cambiamenti sul sistema, ma non Ã© una cattiva idea adottare anche altri accorgimenti. <c>chkrootkit</c> Ã© un'utility che controlla che nei file di sistema non siano presenti rootkit (software usati per nascondere le tracce di un intruso e consentirgli di ricollegarsi al sistema in qualsiasi momento), verifica che su sistema non siano installati dei keylogger o altro codice malevolo (ndt, malware). Nonostanre <c>chkrootkit</c> (e altri software simili come <c>rkhunter</c>) siano strumenti molto utili sia per la manutenzione sia per tracciare un intruso dopo che il sistema Ã© stato attaccato, non possono garantire la sicurezza del sistema.
></p>  	 
>  	 
><p>
>Il modo migliore per utilizzare <c>chkrootkit</c> per verificare che non ci siano state intrusioni Ã© quello di farlo avviare periodicamente da <c>cron</c>. Per cominciare Ã© necessario installare <path>app-admin/chkrootkit</path>. <c>chkrootkit</c> puÃ² essere avviato sia da linea di comando tramite l'omonimo file eseguibile, o da <c>cron</c> usando una configurazione del genere:
></p>
>  	 
><pre caption="Schedule chkrootkit as a cronjob">
>0 3 * * * /usr/sbin/chkrootkit
></pre>
>  	 
></body> 	 
></section>
>
></chapter>
>
><chapter>
><title>Mantenersi aggiornati</title>
><section>
><body>
>
><p>
>Una volta che avete installato con successo il vostro sistema e assicurato un buon livello di sicurezza non dovete 
>considerarvi a posto. La sicurezza Ã¨ un processo continuo e dovete quindi mantenere aggiornato il vostro sistema con le
>piÃ¹ recenti patches di sicurezza.
></p>
>  	 
><p>
>Se avete installato una versione recente di <c>portage</c> potete prima sincronizzare il vostro portage tree con il comando <c>emerge --sync</c> e quindi proseguire con il comando <c>glsa-check --list</c> per controllare se il vostro sistema Ã¨ aggiornato in quanto a sicurezza.
></p>
>  	 
><pre caption="Esempio di output di glsa-check -l">
># <i>glsa-check -l</i>
>WARNING: This tool is completely new and not very tested, so it should not be
>used on production systems. It's mainly a test tool for the new GLSA release
>and distribution system, it's functionality will later be merged into emerge
>and equery.
>Please read http://www.gentoo.org/proj/en/portage/glsa-integration.xml
>before using this tool AND before reporting a bug.
>  	 
>[A] means this GLSA was already applied,
>[U] means the system is not affected and
>[N] indicates that the system might be affected.
>  	 
>200406-03 [N] sitecopy: Multiple vulnerabilities in included libneon ( net-misc/sitecopy )
>200406-04 [U] Mailman: Member password disclosure vulnerability ( net-mail/mailman )
>.......
></pre>
>  	 
><warn>
><c>glsa-check</c> Ã¨ ancora in fase sperimentale quindi se la sicurezza Ã¨ davvero la vostra massima prioritÃ  sarebbe saggio
>verificare la lista anche con altre fonti.
></warn>
>  	 
><p>
>Tutte le linee con una <c>[A]</c> e una <c>[U]</c> possono essere quasi sicuramente ignorate poichÃ¨ il sistema non Ã¨
>afflitto da queste GLSA.
></p>
>  	 
><p>
>Alcuni preferiscono usare ancora <c>emerge packagename</c> al posto di <c>glsa-check -f</c> cosÃ¬ che tutte le GLSA
>sono elencate come <c>[N]</c>.
></p>
>  	 
><p>
>Se volete una email ogni volta che viene redatta una GLSA iscrivetevi alla mailing list <c>gentoo-announce</c>.
>Le istruzioni per iscriversi a questa e a diverse altre interessanti mailing list possono essere trovate qui: <uri
>link="/main/en/lists.xml">Descrizione delle Mailing List di Gentoo Linux</uri>.
></p>
>  	 
><p>
>Un'altra buona risorsa sulla sicurezza Ã¨ la <uri link="http://www.securityfocus.com/archive/1">mailing list Bugtraq</uri>.
></p>
>  	 
></body>
></section>
>
></chapter>
></guide>

Actions: View

Attachments on bug 83148: 52023