[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ successivo ]

Securing Debian Manual
Capitolo 5 - Rendere più sicuri i servizi che girano sul vostro sistema


I servizi attivi su un sistema possono essere resi più sicuri in due modi:

Vincolare i servizi in maniera tale da renderli accessibili solo da un luogo definito può essere fatto restringendo il loro accesso a livello di kernel (per es. i firewall), configurandoli in maniera tale da ascoltare solo da una data interfaccia (alcuni servizi potrebbero non fornire questa possibilità) o impiegando qualche altro metodo, per esempio la patch linux vserver (per il 2.4.16) può essere usata per obbligare i processi ad usare una sola interfaccia.

Per quanto riguarda i servizi che vengono eseguiti da inetd (telnet, ftp, finger, pop3...), queste considerazioni non valgono, in quanto i servizi non possono essere configurati in maniera tale da rimanere in ascolto su una data interfaccia. Comunque il suo sostituto, il meta-demone xinetd, include un bind proprio a questo scopo. Leggete xinetd.conf(5).

     service nntp
     {
             socket_type     = stream
             protocol        = tcp
             wait            = no
             user            = news
             group           = news
             server          = /usr/bin/env
             server_args     = POSTING_OK=1 PATH=/usr/sbin/:/usr/bin:/sbin/:/bin
     +/usr/sbin/snntpd logger -p news.info
             bind            = 127.0.0.1
     }

Le sezioni seguenti forniscono i dettagli su come configurare opportunamente specifici servizi individuali in funzione dell'uso previsto.


5.1 Rendere sicuro ssh

Se state ancora usando telnet invece di ssh, è meglio che passiate a ssh prima di proseguire con la lettura di questo manuale. Sarebbe bene utilizzare ssh invece di telnet per tutte le login remote. In un'epoca in cui è facile intercettare il traffico su Internet e ottenere le password trasmesse in chiaro, bisognerebbe usare solamente protocolli che utilizzano la crittografia; per questo motivo meglio eseguire subito apt-get install ssh sulla propria macchina.

Incoraggiate tutti gli utenti del vostro sistema ad usare ssh invece di telnet o, ancora meglio, disinstallare telnet/telnetd. Oltre a quanto detto bisognerebbe evitare di autenticarsi nel sistema come root con ssh e utilizzare invece dei metodi alternativi per diventare root, come su o sudo. Infine meglio modificare anche il file sshd_config, in /etc/ssh, per aumentare la sicurezza:

Potete restringere l'accesso al server ssh anche utilizzando pam_listfile o pam_wheel nel file di controllo PAM per ssh, in modo da limitare le autenticazioni ssh. Per esempio potreste escludere tutti gli utenti non elencati in /etc/loginusers aggiungendo questa linea a /etc/pam.d/ssh:

     auth       required     pam_listfile.so sense=allow onerr=fail item=user file=/etc/loginusers

Come ultima osservazione dovreste considerare che queste direttive si riferiscono ad un file di configurazione di OpenSSH. Al momento vengono utilizzati comunemente tre demoni SSH: ssh1, ssh2 e l'OpenSSH degli sviluppatori di OpenBSD. Ssh1 è stato il primo demone ssh disponibile ed è ancora il più utilizzato (ci sono voci che esista anche una versione per Windows). Ssh2 ha molti vantaggi rispetto a ssh1 tranne per il fatto di essere rilasciato con una licenza closed-source. OpenSSH è un demone ssh rilasciato come software libero che supporta sia ssh1 che ssh2. OpenSSH è la versione che viene installata in Debian quando selezionate il pacchetto ssh.

Potete ottenere più informazioni su come impostare SSH con il supporto PAM negli archivi della mailing list sulla sicurezza.


5.1.1 Chroot di ssh

Per ora OpenSSH non fornisce un modo per poter automaticamente ingabbiare con chroot gli utenti dopo una connessione (la versione commerciale invece fornisce questa possibilità). Ad ogni modo esiste un progetto per dare questa funzionalità anche a OpenSSH, vedete http://chrootssh.sourceforge.net, al momento credo non sia disponibile il pacchetto per Debian. Potreste usare al suo posto il modulo pam_chroot come descritto in Restrizioni agli utenti per l'accesso, Sezione 4.10.8.

In Ambiente Chroot per SSH, Appendice G potete trovare numerose opzioni per creare un ambiente chroot per SSH.


5.1.2 Client ssh

Se state usando un client SSH con un server SSH dovreste assicurarvi che supporti gli stessi protocolli che sono impostati sul server. Per esempio, se utilizzate il package mindterm, supporta solo il protocollo con versione 1. Mentre, il server sshd, in modo predefinito, è configurato per accettare solo la versione 2 (per ragioni di sicurezza).


5.1.3 Non permettere il trasferimento di file

Se non volete che gli utenti trasferiscano file da e verso il server ssh dovete restringere l'accesso all'sftp-server e l'accesso a scp. Potete restringere l'sftp-server configurando il corretto Subsystem in /etc/ssh/sshd_config. Ad ogni modo, per restringere l'accesso via scp, dovete:


5.2 La sicurezza in Squid

Squid è uno dei più famosi server proxy/cache e ci sono alcuni problemi di sicurezza che dovreste tenere presenti. Il file di configurazione predefinito di Squid nega ogni richiesta degli utenti. Invece il package Debian permette accessi da "localhost", dovreste solamente configurare il vostro browser correttamente. Dovreste configurare Squid per permettere l'accesso a utenti, host o reti fidate definendo la Access Control List (Lista di Controllo d'Accesso [ndT]) in /etc/squid.conf, guardate Squid User's Guide per ulteriori informazioni riguardo la definizione delle regole per le ACL. Da notare che Debian fornisce una configurazione minima di Squid, che preverrà tutto, tranne la connessione al proprio proxy server (che utilizzerà la porta di default 3128) da localhost. Sarà necessario personalizzare il vostro /etc/squid.conf a seconda delle necessità. La configurazione minima consigliata (fornita con il pacchetto) è mostrata qui di seguito:

     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
     acl SSL_ports port 443 563
     acl Safe_ports port 80          # http
     acl Safe_ports port 21          # ftp
     acl Safe_ports port 443 563     # https, snews
     acl Safe_ports port 70          # gopher
     acl Safe_ports port 210         # wais
     acl Safe_ports port 1025-65535  # unregistered ports
     acl Safe_ports port 280         # http-mgmt
     acl Safe_ports port 488         # gss-http
     acl Safe_ports port 591         # filemaker
     acl Safe_ports port 777         # multiling http
     acl Safe_ports port 901         # SWAT
     acl purge method PURGE
     acl CONNECT method CONNECT
     (...)
     # Only allow cachemgr access from localhost
     http_access allow manager localhost
     http_access deny manager
     # Only allow purge requests from localhost
     http_access allow purge localhost
     http_access deny purge
     # Deny requests to unknown ports
     http_access deny !Safe_ports
     # Deny CONNECT to other than SSL ports
     http_access deny CONNECT !SSL_ports
     #
     # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
     #
     http_access allow localhost
     # And finally deny all other access to this proxy
     http_access deny all
     #Default:
     # icp_access deny all
     #
     #Allow ICP queries from eveyone
     icp_access allow all

Dovreste configurare Squid anche basandovi sulle vostre risorse di sistema, inclusa la memoria cache (opzione cache_mem), la posizione dei file nella cache e la quantità di spazio che occuperanno sull'hard disk (opzione cache_dir).

Da notare che, se non correttamente configurato, qualcuno potrebbe inoltrare un messaggio di posta tramite Squid, poiché i protocolli HTTP e SMTP sono abbastanza simili. La configurazione predefinita di Squid nega l'accesso alla porta 25. Se desiderate permettere connessioni alla porta 25 aggiungetela alla lista delle Safe_ports. Comunque, questo è NON raccomandato.

Impostare e configurare correttamente il server proxy/cache è solo una parte volta a mantenere il vostro sito sicuro. Un altro compito necessario è l'analisi dei log di squid per assicurarsi che tutto vada come dovrebbe. Ci sono alcuni pacchetti in Debian GNU/Linux che potrebbero aiutare un amministratore a farlo. I seguenti sono disponibili in woody (Debian 3.0):

Quando utilizzate Squid in Accelerator Mode, questo funziona anche come web server. Utilizzando questa opzione la complessità del codice aumenta, rendendolo meno leggibile. Di default Squid non é configurato per funzionare come web server, dunque non vi dovete preoccupare di ciò. Notate che se desiderate usare questa funzione dovete essere certi che sia veramente necessaria. Per trovare più informazioni riguardo l'Accelerator Mode in Squid vedete Squid User's Guide #Chapter9.


5.3 Rendere sicuro FTP

Se avete realmente la necessità di usare il servizio FTP (senza poterlo costringere in un tunnel SSL o SSH o tramite sslwrap), dovreste usare chroot per ingabbiare ftp nella directory home dell'utente ftp, cosicché l'utente non sia in grado di vedere niente altro se non la sua directory. Altrimenti potrebbe attraversare il filesystem principale come se avessero una shell nel sistema. Potete aggiungere la seguente riga nel vostro proftpd.conf nella sezione globale per abilitare la funzione chroot:

     DefaultRoot ~

Fate ripartire proftpd con /etc/init.d/proftpd restart e controllate se adesso riuscite ad uscire dalla vostra directory home.

Per prevenire gli attacchi DoS a Proftp usando ../../.., aggiungete la seguente riga in /etc/proftpd.conf: DenyFilter \*.*/

Ricordate sempre che FTP spedisce login e password di autenticazione in chiaro (questo non è un problema se state fornendo un servizio anonimo pubblico) e ci sono alternative migliori in Debian per questo. Per esempio, sftp (fornito da ssh). Ci sono anche implementazioni libere di SSH per altri sistemi operativi: putty e cygwin per esempio.

Ad ogni modo, se state mantenendo ancora il server FTP mentre gli utenti accedono via SSH potreste incontrare un tipico problema. Gli utenti che accedono al server FTP anonimo all'interno del sistema SSH-sicuro potrebbero tentare di effettuare un login al server FTP. Mentre l'accesso verrà rifiutato, la password verrà spedita senza alcun dubbio attraverso la rete, in chiaro. Per evitare questo, lo sviluppatore di ProFTPd TJ Sanders ha scritto una patch che previene gli utenti girando al server FTP anonimo un account SSH valido. Altre informazioni e patch disponibili alla pagina ProFTPD Patches. Questa patch è stata portata in Debian, vedete il Bug #145669.


5.4 Rendere sicuro l'accesso al sistema X Window

Oggi, i terminali X sono usati da numerose e svariate compagnie così un solo server è necessario per numerose postazioni singole. Questo potrebbe essere pericoloso perché è necessario permettere al file server di connettersi ai client (X server dal punto di vista di X. X scambia le solite definizioni di client e server). Se seguirete il (pessimo) suggerimento di numerosi documenti, digiterete xhost + sulla vostra macchina. Questo permette ad ogni client X di connettersi al sistema. Per una piccola miglioria di sicurezza, potrete invece usare il comando xhost +hostname per permettere l'accesso da specifici host.

Una soluzione più sicura, credo, è di usare ssh per creare un tunnel per X e cifrare l'intera sessione. Questo è fatto automaticamente quando vi connettete via ssh ad un'altra macchina. Perché questo funzioni dovete configurare sia il client che il server ssh. Per il client ssh: bisognerà abilitare ForwardX11 con un yes in /etc/ssh/ssh_config. Per il server ssh, invece, dovrete mettere un yes in /etc/ssh/sshd_config a fianco di X11Forwarding e il package xbase-clients dovrebbe essere installato perché il server ssh usi /usr/X11R6/bin/xauth nel momento in cui configura un pseudo display X. Al tempo di SSH, dovreste aggirare completamente il controllo dell'accesso con xhost.

Per una migliore sicurezza, se non avete bisogno di accedere ad X da altre macchine tagliate il legame alla porta tcp 6000 semplicemente digitando:

     $ startx -- -nolisten tcp

Questo è il comportamento predefinito in Xfree 4.1.0 (il server X fornito da Debian 3.0). Se state eseguendo Xfree 3.3.6 (cioè se si ha Debian 2.2 installata) potete modificare /etc/X11/xinit/xserverrcc per avere qualcosa di simile a:

     #!/bin/sh
     exec /usr/bin/X11/X -dpi 100 -nolisten tcp

Se state usando XDM impostate /etc/X11/xdm/Xservers a :0 local /usr/bin/X11/X vt7 -dpi 100 -nolisten tcp. Se usate Gdm assicuratevi che l'opzione -nolisten tcp sia impostata in /etc/gdm/gdm.conf (che è il default in Debian) così come qui sotto:

     [server-Standard]
     name=Standard Server
     command=/usr/bin/X11/X -nolisten tcp

Potete anche impostare il timeout di sistema di default per il lock dello xscreensaver. Anche se l'utente può sovrascriverla, dovreste modificare la configurazione /etc/X11/app-defaults/XScreenSaver e cambiare la linea di lock:

     *lock:                  False

(che è il default di Debian) in:

     *lock:                  True

FIXME: aggiungere informazioni su come disabilitare gli screensaver che mostrano il desktop dell'utente (che potrebbe avere informazioni sensibili).

Leggete di più sulla sicurezza di X Window in XWindow-User-HOWTO (/usr/share/doc/HOWTO/en-txt/XWindow-User-HOWTO.txt.gz).

FIXME: Aggiungere informazioni prese da un thread di debian-security su come fare a cambiare i file di configurazione di XFree 3.3.6.


5.4.1 Controllare il display manager

Se avete un display manager installato per uso locale (avete cioè un piacevole login grafico), assicuratevi che XDMCP (Protocollo di controllo per il Display Manager di X) sia disabilitato. In XDM questo si può ottenere agendo sulla linea in /etc/X11/xdm/xdm-config:

     DisplayManager.requestPort:     0

Normalmente in Debian, in maniera predefinita, tutti i display manager sono configurati per non lanciare i servizi XDMCP.


5.5 Rendere sicuri gli accessi alla stampante (specifico per lpd ed lprng)

Immaginate di arrivare al lavoro e trovarvi una montagna di carta uscita dalla stampante perché il demone di stampa ha subito un attacco DoS. Lo trovereste piacevole?

In qualsiasi architettura per la stampa in Unix, ci deve essere un modo per ottenere dal client i dati per il server di stampa. Tradizionalmente, lpr ed lp sono i client che si occupano di fornire i comandi per copiare o creare dei link simbolici ai dati contenuti nella directory spool (che è il motivo per il quale usualmente questi programmi sono SUID o SGID).

Per evitare questi problemi, dovreste mantenere il vostro server di stampa particolarmente sicuro. Questo significa necessariamente, configurare il vostro servizio di stampa per far sì che consenta connessioni solamente dai server fidati. In merito a questo, aggiungete i server a cui volete consentire la stampa nel vostro /etc/hosts.lpd.

In ogni caso, il demone lpr accetta in ingresso connessioni sulla porta 515 da qualsiasi interfaccia. Dovreste considerare la possibilità di usare un firewall per le connessioni tra la rete e gli host a cui non è consentito stampare (così il demone lpr può rimanere in attesa solo da determinati indirizzi IP).

Lprng dovrebbe essere preferito a lpr visto che può essere configurato per avere il controllo sugli accessi IP. Potete anche specificare quale interfaccia proteggere (sebbene piuttosto bizzarro).

Se state usando nel vostro sistema una stampante locale, probabilmente non desiderate condividere questo servizio sulla rete. Considerate allora l'opportunità di usare un altro sistema di stampa, come quello fornito da cups o PDQ che si basa sui permessi degli utenti sul dispositivo /dev/lp0.

In cups, la stampa dei dati è trasferita al server mediante il protocollo http. Questo significa che il client non ha bisogno di particolari privilegi, ma richiede che il server sia in ascolto su qualche porta.

Tuttavia, se desiderate usare cups in locale potete configurarlo proteggendo l'interfaccia di loopback, modificando il file /etc/cups/cupsd.conf:

     Listen 127.0.0.1:631

Vi sono molte altre opzioni per la sicurezza simili a quelle contenute nel file di configurazione hosts, che permettono di consentire o negare l'accesso dalla rete. Tuttavia, se non ne avete bisogno, una soluzione migliore potrebbe essere quella di limitare o escludere le connessioni sulle porte in attesa. Cups utilizza la porta di comunicazione HTTP, se desiderate non rendere note informazioni potenzialmente utili ad eventuali attaccanti, aggiungete (e chiudete verso l'esterno le porte aperte) anche:

     <Location />
       Order Deny,Allow
        Deny From All
         Allow From 127.0.0.1
     </Locationi>

Questo file di configurazione può essere modificato aggiungendo ulteriori funzionalità, inclusi certificati e cifratura SSL/TLS. Il manuale è disponibile all'indirizzo http://localhost:631/ o in cups.org.

FIXME: Aggiungere ulteriori contenuti (l'articolo su Amateur Fortress Building fornisce alcuni punti di vista molto interessanti).

FIXME: Controllare se PDG è disponibile in Debian e se lo fosse, suggerirlo come sistema di stampa preferito.

FIXME: Controllare se Farmer/Wietse ha rimpiazzato il demone di stampa e se è disponibile in Debian.


5.6 Rendere sicuro il servizio di posta

Se il vostro server non fornisce servizi di posta, non avete bisogno di avere un demone di posta in attesa di connessioni. Potreste aver bisogno solamente di un sistema di trasporto locale, per esempio, per ricevere la posta dall'utente root e dagli altri allarmi di sistema.

Se state usando exim non avete bisogno di configurare il demone, in quanto, in maniera predefinita, si assume cron il compito di svuotare la coda di posta. Vedete Disabilitare i servizi attivi in modalità demone, Sezione 3.6.1 per sapere come questo avviene.


5.6.1 Configurare un nullmailer

Potreste voler avere un demone di posta locale che possa ritrasmettere verso un altro sistema i messaggi spediti localmente. Questa è una cosa comune quando dobbiamo amministrare un certo numero di sistemi e non desideriamo connetterci ad ognuno di essi per leggere la posta spedita localmente. Proprio come la scrittura dei log di ogni singolo sistema può essere centralizzata usando un server syslog centrale, la posta può essere spedita ad un server di posta centralizzato.

Un tale sistema solo-redirezione (relay-only) dovrebbe essere propriamente configurato per svolgere questo compito. Il demone potrebbe anche essere configurato per rimanere in ascolto sul solo indirizzo di loopback.

Per fare ciò in un sistema Debian, dovrete rimuovere il demone smtp da inetd:

     $ update-inetd --disable smtp

e configurare il demone di posta perché rimanga in ascolto sulla sola interfaccia di loopback. In exim (l'MTA predefinito) lo potete fare modificando il file /etc/exim.conf e aggiungendo la linea seguente:

     local_interfaces = "127.0.0.1"

Riavviare entrambi i demoni (inetd e exim); exim sarà in ascolto sul solo socket 127.0.0.1:25. Fate attenzione e per prima cosa disabilitate inetd, altrimenti exim non partirà poiché il demone inetd sta già gestendo le connessioni in arrivo.

Per postfix modificate /etc/postfix/main.conf:

     inet_interfaces = localhost

Se volete solo posta locale, questo approccio è migliore dell'uso del tcp-wrapping sul demone di posta o dell'aggiunta di regole per il firewall per limitarne l'accesso. Tuttavia, se avete bisogno che esso resti in ascolto su altre interfacce, lo potreste lanciare da inetd ed aggiungere un tcp wrapper in modo che le connessioni in arrivo vengano controllate tramite i file /etc/hosts.allow e /etc/hosts.deny. Inoltre, configurando un'appropriata scrittura dei log per qualunque dei metodi sopra descritti, potrete sapere quando si verifica un tentativo di accesso non autorizzato al demone di posta.

In ogni caso, per respingere i tentativi di ritrasmissione della posta a livello di SMTP, potete cambiare /etc/exim/exim.conf in modo che contenga:

     receiver_verify = true

Anche se il vostro server di posta non ritrasmetterà il messaggio, questo tipo di configurazione è necessaria al test di ritrasmissione che trovate all'indirizzo http://www.abuse.net/relay.html per determinare che il vostro server non sia in grado di ritrasmettere.

Tuttavia, se desiderate una configurazione solo-ritrasmissione, potreste cambiare il demone della posta con programmi che possono solo essere configurati per inoltrare la posta ad un server di posta remoto. Al momento Debian fornisce ssmtp e nullmailer a questo scopo. In ogni caso, potrete valutare da soli i vari email transport agents [21] forniti da Debian e scegliere quello che meglio si adatta agli scopi del sistema.


5.6.2 Fornire un accesso sicuro alle mailbox

Per fornire un accesso remoto alle mailbox ci sono molti demoni POP3 e IMAP disponibili. [22] Tuttavia, se fornite accesso IMAP, sappiate che questo è un protocollo di accesso generale ai file e può diventare l'equivalente di un accesso tramite shell, mediante il quale si porrebbero gli utenti in condizione tale da permetterne l'accesso a qualunque file.

Provate, ad esempio, a configurare {server.com}/etc/passwd come percorso della vostra inbox. Se vi riuscite, il demone IMAP non è correttamente configurato per impedire questo tipo di accesso.

Tra i server IMAP disponibili in Debian il server cyrus (nel pacchetto cyrus-imapd) risolve il problema, facendo in modo che tutti gli accessi siano rivolti verso un database che risiede in una parte del file system dove l'accesso è ristretto. Inoltre, uw-imapd (installare uw-imapd o meglio, se il vostro client IMAP lo supporta, uw-imapd-ssl) può essere configurato per ottenere la cartella della posta degli utenti in chroot, ma questa funzionalità non è abilitata nella configurazione predefinita. La documentazione a corredo del programma fornisce ulteriori informazioni su come configurarlo.

Inoltre, potreste voler eseguire un server IMAP che non necessiti di utenti validi creati sul sistema locale (cosa che consentirebbe anche l'accesso tramite shell); sia courier-imap (per IMAP) che courier-pop teapop (per POP3) e cyrus-imapd (per POP3 e IMAP) forniscono server con metodi di autenticazione non dipendenti dagli account degli utenti locali. Cyrus può usare qualunque metodo di autenticazone configurabile per mezzo di PAM, mentre teapop può usare dei database (come postgresql e mysql) per l'autenticazione degli utenti.

FIXME: Controllare: anche uw-imapd potrebbe essere configurato per l'autenticazione utenti attraverso PAM.


5.6.3 Ricevere posta in sicurezza

Nella ricezione e lettura della posta viene impiegato il più comune protocollo con testo in chiaro; usando sia IMAP che POP3, si invia la propria password in chiaro, in questo modo, da quel momento in avanti, quasi chiunque può leggere la nostra posta; per evitare ciò, scaricatela usando il protocollo SSL o, in alternativa, ssh se avete un'account dotato di shell sulla postazione che funge da server POP o IMAP. Ecco un essenziale fetchmailrc esemplificativo:

     poll my-imap-mailserver.org via "localhost"
       with proto IMAP port 1236
           user "ref" there with password "hackme" is alex here warnings 3600
         folders
           .Mail/debian
         preconnect 'ssh -f -P -C -L 1236:my-imap-mailserver.org:143 -l ref
          my-imap-mailserver.org sleep 15 </dev/null > /dev/null'

La linea che inizia con "preconnect" è importante, in quanto dà il via ad una sessione ssh e crea il tunnel necessario, che inoltra le connessioni al port 1236 del localhost verso il server di posta IMAP, in modo automatico, ma sottoponendole a cifratura. Un'altra possibilità sarebbe usare fetchmail con la funzionalità SSL.

Se volete fornire servizi di posta cifrata, come POP e IMAP, usate il comando apt-get install stunnel e attivate i demoni in questo modo:

     stunnel -p /etc/ssl/certs/stunnel.pem -d pop3s -l /usr/sbin/popd

Quest'ultimo comando collega il demone fornito (-l) alla porta (-d) e utilizza lo specificato modo di certificazione SSL (-p)


5.7 Rendere sicuro BIND

Esistono diversi problemi che devono essere affrontati quando andate a rendere sicuro il demone del domain server, questi sono simili a quelli che incontrate normalmente quando vengono resi sicuri altri servizi:

Dovreste limitare alcune delle informazioni che sono servite tramite DNS ai client esterni, di modo che non possa essere usato per reperire informazioni importanti sulla vostra organizzazione che non volete far sapere. Questo consiste nell'aggiungere le seguenti opzioni: allow-transfer, allow-query, allow-recursive e version. Potete anche limitarli nella sezione globale (in modo che vengano applicati in tutte le zone servite) oppure per zona. Questa informazione è documentata nel pacchetto bind-doc, potete leggere di più su questo argomento in /usr/share/doc/bind/html/index.html una volta che il pacchetto sarà installato.

Immaginate che il vostro server sia connesso ad Internet ed alla vostra rete interna (il vostro IP interno è 192.168.1.2) (un server base con due connessioni di rete), non volete offrire nessun servizio su Internet e volete solamente abilitare il DNS Lookup dai vostri host interni. Potete effettuare quest'operazione includendo le seguenti righe in /etc/bind/named.conf:

     options {
     	    allow-query { 192.168.1/24; } ;
     	    allow-transfer { none; } ; 
     	    allow-recursive { 192.168.1/24; } ;
     	    listen-on { 192.168.1.2; } ;
     	    forward { only; } ;
     	    forwarders { A.B.C.D; } ;
     };

L'opzione listen-on vincola il DNS sull'interfaccia che ha l'indirizzo interno e anche se questa interfaccia è la stessa che si connette ad Internet (ad esempio se state utilizzando NAT), le richieste saranno accettate solamente se provengono dai vostri host interni. Se il sistema ha interfacce multiple e non è presente il parametro listen-on, solo gli utenti interni potranno effettuare richieste, anche se, visto che la porta sarebbe accessibile agli attacchi dall'esterno, qualcuno potrebbe cercare di farvi mandare in crash (o provando attacchi di tipo buffer overflow) il DNS server. Potete anche fare in modo che il DNS ascolti unicamente su 127.0.0.1 se non dovete fornire il servizio ad altri sistemi tranne che a voi stessi.

Il record version.bind nella classe chaos contiene la versione del processo bind che sta girando correntemente. Questa informazione viene spesso usata da scanner automatici o individui maliziosi con l'intento di determinare se il bind è vulnerabile o meno ad un dato attacco. Non fornendo informazioni o fornendole false all'interno del record version.bind, vengono limitate le probabilità che il server venga attaccato sulla base della versione pubblicata. Per stabilire la vostra versione utilizzate la direttiva version nella seguente maniera:

      options { ... various options here ...
     version "Not available."; };

Cambiare il record version.bind non fornisce protezione a fronte di eventuali attacchi, ma può essere considerata un'utile salvaguardia.

Un esempio di configurazione di named.conf potrebbe essere la seguente:

     acl internal {
             127.0.0.1/32;           // localhost
             10.0.0.0/8;             // internal
             aa.bb.cc.dd;            // eth0 IP
     };
     
     acl friendly {
             ee.ff.gg.hh;            // slave DNS
             aa.bb.cc.dd;            // eth0 IP
             127.0.0.1/32;           // localhost
             10.0.0.0/8;             // internal
     };
     
     options {
             directory "/var/cache/bind";
             allow-query { internal; };
             allow-recursive { internal; };
             allow-transfer { none; };
     };
     // From here to the mysite.bogus zone 
     // is basically unmodified from the debian default
     logging {
             category lame-servers { null; };
             category cname { null; };   
     };
     
     zone "." {
             type hint;
             file "/etc/bind/db.root";
     };
     
     zone "localhost" {
             type master;
             file "/etc/bind/db.local";
     };
     
     zone "127.in-addr.arpa" {
             type master;
             file "/etc/bind/db.127";
     };
     
     zone "0.in-addr.arpa" {
             type master;
             file "/etc/bind/db.0";
     };
     
     zone "255.in-addr.arpa" {
             type master;
             file "/etc/bind/db.255";
     };
     
     // zones I added myself
     zone "mysite.bogus" {
             type master;
             file "/etc/bind/named.mysite";
             allow-query { any; };
             allow-transfer { friendly; };
     };

Controllate il Bug Tracking System riguardo a Bind, specificatamente il Bug #94760 (riguardo le ACL sui trasferimenti di zona). Sentitevi liberi di riportare informazioni sui bug se pensate di poter aggiungervi informazioni utili.


5.7.1 Cambiare l'utente di BIND

Riguardo come limitare i privilegi di BIND dovete sapere che se un utente normale (quindi non superutente) fa partire BIND, quest'ultimo non potrà riconoscere le nuove interfacce automaticamente, ad esempio se inserite una scheda PCMCIA nel vostro portatile. Controllate il file README.Debian nella vostra documentazione di named (/usr/share/doc/bind/README.Debian) per ulteriori informazioni su questo problema. Ci sono stati recentemente diversi problemi di sicurezza riguardanti BIND per cui cambiare utente diviene comodo quando è possibile farlo. Spiegheremo dettagliatamente i passi da compiere per realizzare questo procedimento, tuttavia, se volete farlo in modo automatizzato potreste provare lo script inserito in Script di esempio per modificare l'installazione predefinita di Bind., Appendice E.

Per fare girare BIND sotto un altro utente la prima cosa da fare è creare un utente separato ed un gruppo apposito (non è una buona idea usare nobody e nogroup per tutti i servizi che non girano come root). In questo esempio saranno utilizzati l'utente ed il gruppo named. Potete crearli digitando:

     addgroup named
     adduser --system --home /home/named --no-create-home --ingroup named \
           --disabled-password --disabled-login named

Notate che l'utente named sarà parecchio ristretto. Se volete, per una qualsiasi ragione, avere un utente con meno limitazioni, utilizzate:

     adduser --system --ingroup named named

Adesso modificate il file /etc/init.d/bind con il vostro programma preferito la linea che inizia con

     start-stop-daemon --start

in

     start-stop-daemon --start --quiet --exec /usr/sbin/named -- -g named -u named

Inoltre, per evitare di far girare qualcosa come superutente, modificate la linea di reload in:

     reload)
            /usr/sbin/ndc reload

e cambiatela in:

     reload)
             $0 stop
             sleep 1
             $0 start

Nota: A seconda della versione di Debian che state usando potreste dover cambiare anche la linea restart. Questo problema, in Debian, è stato sistemato nella versione 1:8.3.1-2 di bind.

Tutto quello che dovete fare adesso è far ripartire bind con il comando "/etc/init.d/bind restart" e controllare il vostro syslog nelle due voci:

     Sep  4 15:11:08 nexus named[13439]: group = named
     Sep  4 15:11:08 nexus named[13439]: user = named

Voilá! Il vostro named adesso non gira come superutente. Se volete leggere altre informazioni sul perché BIND non gira in maniera predefinita come utente non root sui sistemi Debian, controllate il Bug Tracking System riguardo Bind, specificatamente il Bug #50013: bind non dovrebbe girare come root e il Bug #132582: l'installazione predefinita è potenzialmente insicura, Bug #53550, Bug #52745 ed il Bug #128120. Sentitevi liberi di riportare informazioni sui bug se pensate di poter aggiungervi informazioni utili.


5.7.2 Eseguire il name server in chroot

Per ottenere la massima sicurezza, si costruirà una gabbia chroot (vedete in Paranoie generiche riguardo chroot e suid, Sezione 5.10) attorno al proprio demone. Esiste un modo semplice per ottenere ciò: l'opzione -t (vedete la pagina man named(8)). Questo farà sì che bind sia in chroot nella directory data, senza che ci sia bisogno di impostare una gabbia chroot e senza che vi dobbiate preoccupare delle librerie dinamiche. Gli unici file che devono essere presenti nella gabbia chroot sono:

     dev/null
     etc/bind/       - deve contenere named.conf e tutte le zone dei server
     sbin/named-xfer - se si fa il trasferimento dei nomi 
     var/run/named/  - deve mantenere il pid e la cache del name server (se
                       presente) e questa directory deve essere accessibile
                       in scrittura dall'utente named
     var/log/named   - se è impostato il logging su file, deve essere
                       accessibile in scrittura dall'utente named
     dev/log         - syslogd dovrebbe essere in ascolto qui se named è
                       stato configurato per eseguire il log tramite esso

Per far sì che il demone Bind funzioni correttamente, necessita dei permessi sui file named. Questo è un compito semplice, dal momento che i file di configurazione sono sempre in /etc/named/. Tenete presente che necessita solo dell'accesso in lettura ai file di zona, a meno che non si tratti di un name server secondario o di cache. Se questo è il caso, dovrete concedere i permessi di lettura-scrittura alle zone necessarie (in modo che i trasferimenti di zona dal server primario funzionino).

Inoltre, potete trovare maggiori informazioni riguardo al chrooting Bind nel Chroot-BIND-HOWTO (concernente Bind 9) e nel Chroot-BIND8-HOWTO (concernente Bind 8). Questi stessi documenti dovrebbero essere disponibili attraverso l'installazione di doc-linux-text (versione testuale) oppure doc-linux-html (versione html). Un altro documento utile è http://www.psionic.com/papers/dns/dns-linux.

Se siete interessati a configurare una gabbia chroot completa (per esempio non semplicemente tramite -t) per Bind 8.2.3 in Debian (potato), assicuratevi che i seguenti file vi siano contenuti:

     dev/log - syslogd dovrebbe essere in ascolto qui
     dev/null
     etc/bind/named.conf
     etc/localtime
     etc/group - con una singola linea: "named:x:GID:"
     etc/ld.so.cache - generata con ldconfig
     lib/ld-2.1.3.so
     lib/libc-2.1.3.so
     lib/ld-linux.so.2 - link simbolico a ld-2.1.3.so
     lib/libc.so.6 - link simbolico a libc-2.1.3.so
     sbin/ldconfig - può essere cancellato dopo la configurazione del chroot
     sbin/named-xfer - se si esegue il trasferimento di nomi
     var/run/

Modificate inoltre syslogd, in ascolto su $CHROOT/dev/log in modo che il name server possa scrivere gli eventi nel syslog del sistema locale di log.

Se volete eliminare i problemi con le librerie dinamiche, potete compilare bind staticamente. Potete usare apt-get a questo scopo, con l'opzione source. Potete anche scaricare il pacchetto che si compilerà in modo opportuno. Dovrete eseguire qualcosa di simile a questo:

     $ apt-get --download-only source bind build-dep bind
     $ cd bind-8.2.5-2
     (edit the Makefile.in so CFLAGS includes the '-static' option 
     before the @CFLAGS@ definition substituted by autoconf)
     $ dpkg-buildpackage -rfakeroot
     $ cd ..
     $ dpkg  -i bind-8.2.5-2*deb

Dopo l'installazione, dovrete spostare i file all'interno della gabbia chroot, [23] potete mantenere gli script init.d in /etc/init.d, così il sistema avvierà automaticamente il name server, però dovrete modificarlo per aggiungere --chroot /location_of_chroot nella chiamata a start-stop-daemon in quegli script.

Per maggiori informazioni su come configurare i chroot vedete Paranoie generiche riguardo chroot e suid, Sezione 5.10.

FIXME, integrare con informazioni da: http://people.debian.org/~pzn/howto/chroot-bind.sh.txt, http://people.pdxlinux.org/~karlheg/ (Bind9 su Debian), http://www.cryptio.net/~ferlatte/config/ (Debian-specifico), http://www.psionic.com/papers/whitep01.html, http://csrc.nist.gov/fasp/FASPDocs/NISTSecuringDNS.htm e http://www.acmebw.com/papers/securing.pdf.


5.8 Proteggere Apache

FIXME:Aggiungere contenuto: moduli forniti con la normale installazione di Apache (in /usr/lib/apache/X.X/mod_*) e moduli che possono essere installati separatamente dai pacchetti libapache-mod-XXX.

Potete limitare l'accesso al server Apache se volete utilizzarlo solo internamente, impedendo che vi accedano degli estranei (per eseguire dei test, per accedere all'archivio doc-central, ecc.). A tale proposito, usate in /etc/apache/http.conf le direttive Listen o BindAddress.

Se usate Listen:

     Listen 127.0.0.1:80

Se usate BindAddress:

     BindAddress 127.0.0.1

Quindi, riavviate Apache con /etc/init.d/apache restart e vedrete che ascolterà solamente sull'interfaccia di loopback.

In ogni caso, se non utilizzate tutte le funzionalità di Apache, si possono considerare altri web server forniti da Debian, come dhttpd.

La Documentazione di Apache informa sulle misure di sicurezza da adottarsi per un server di rete Apache (Debian dà questa stessa informazione con il pacchetto apache-doc). Può essere utile anche la lettura di Apache Security Configuration Document (Documento su come proteggere Apache) fornito da InterSect Alliance.

Maggiori informazioni su come limitare ulteriormente l'accesso ad Apache, impostando una gabbia di tipo chroot, le trovate in Ambiente Chroot per Apache, Appendice H.


5.8.1 Impedire agli utenti la divulgazione di contenuti di rete

L'installazione predefinita di Apache consente agli utenti di pubblicare contenuti in $HOME/public_html. Tali contenuti possono essere raggiunti in remoto impiegando un'URL come: http://your_apache_server/~user.

Se volete impedirlo, occorre cambiare la configurazione di /etc/apache/http.conf inserendo il commento (#) davanti alla riga:

     LoadModule userdir_module /usr/lib/apache/1.3/mod_userdir.so

Però, se il modulo fosse stato collegato in modo statico (cosa che si verifica lanciando apache -l), dovreste aggiungere :

     Userdir disabled

Nota: il lemma disabled è disponibile solo a partire da Apache 1.3; se utilizzate versioni precedenti, dovrete cambiare il file di configurazione ed aggiungere:

     <Directory /home/*/public_html>
         AllowOverride None
         Order deny,allow
         Deny from all
     </Directory>

Un attaccante, però, può ancora eseguire il conteggio degli utenti, dal momento che la risposta del server di rete sarà un 403 Permission Denied e non un 404 Not available.


5.8.2 Permessi sui file di log

I file di log di Apache, dalla versione 1.3.22-1, sono proprietà dell'utente "root" e del gruppo "adm", con permesso 640 - cambiato a rotazione. Senza un ampliamento dei privilegi, un intruso che abbia avuto accesso al sistema attraverso il server di rete non potrebbe eliminare voci vecchie dei file di log.


5.8.3 Pubblicare file web

I file di Apache sono situati in /var/www. Subito dopo l'installazione, il file predefinito fornisce alcune informazioni sul sistema (principalmente sul fatto che si tratta di un sistema Debian su cui è attivo Apache). Le pagine web predefinite sono impostate per definizione come proprietà dell'utente root e del gruppo root, mentre il processo Apache è eseguito come utente www-data e gruppo www-data. Questo dovrebbe rendere più difficile la violazione del sito per chi attacca il sistema attraverso il server di rete.


5.9 Rendere sicuro finger

Se avete intenzione di fornire il servizio finger, chiedetevi prima se serva veramente. In caso affermativo, vi renderete conto che Debian fornisce molti demoni finger (questo è l'output di apt-cache search fingerd):

ffingerd è il servizio finger raccomandato se avete intenzione di usarlo come servizio pubblico. In ogni caso siete invitati, quando lo configurate tramite inetd, xinetd o tcpserver, a: limitare il numero di processi che saranno eseguiti contemporaneamente, limitare gli accessi a finger da specifici host (usando tcp wrapper) e configurarlo in modo da farlo ascoltare solo sulle interfacce desiderate.


5.10 Paranoie generiche riguardo chroot e suid

chroot è una delle più potenti alternative per stabilire restrizioni per un demone, un utente o un altro servizio. Immaginate una gabbia attorno al bersaglio, da cui esso non può uscire (normalmente, anche se ci sono comunque molte condizioni che permettono di uscirne). Se non vi fidate di un servizio o di un utente, potete creargli un ambiente root diverso. Questo ambiente può occupare una buona parte di spazio su disco poiché vi dovrete copiare tutti gli eseguibili e le librerie necessarie. Anche se l'utente fa qualcosa di malizioso, la portata del danno è limitata a questa gabbia.

Molti servizi eseguiti come demoni possono beneficiare di questo genere di soluzione. Tuttavia i demoni installati dalla distribuzione Debian non sfrutteranno l'ambiente chroot [24] in modo predefinito.

Questi includono: name server (come bind), server web (come apache), server di posta (come sendmail) e server ftp (come wu-ftpd). Probabilmente è giusto dire che la complessità di BIND è il motivo per cui è stato esposto a molti attacchi in questi anni (vedete in Rendere sicuro BIND, Sezione 5.7).

Debian fornisce del software che può aiutarvi a configurare ambienti chroot automaticamente. Vedete Creare ambienti chroot automaticamente, Sezione 5.10.1.

Ad ogni modo se eseguite un qualsiasi servizio su un sistema, dovreste farlo nel modo più sicuro possibile. Questo comporta: revocare i privilegi di root, eseguirli in un ambiente ristretto (come una gabbia creata con chroot) o sostituirli con servizi equivalenti più sicuri.

Tuttavia tenete conto fin d'ora che un ambiente creato con chroot può non essere sicuro se l'utente all'interno è il superutente. Perciò è necessario eseguire il servizio come utente non privilegiato. Limitando il suo ambiente limitate i file leggibili/eseguibili globalmente a cui il servizio può accedere e con questo le possibilità di una scalata ai privilegi sfruttando vulnerabilità relative alla sicurezza del sistema locale. Anche in questa situazione non si può essere completamente sicuri che non ci siano modi per una persona capace di uscire da questa gabbia in qualche modo. Usare solo programmi server che hanno la reputazione di essere sicuri è una buona misura precauzionale aggiuntiva. Anche buchi minuscoli come file di gestione aperti, possono esser usati da una persona capace per intromettersi nel sistema. Dopotutto chroot non è stato progettato come strumento per la sicurezza, ma come strumento di test.


5.10.1 Creare ambienti chroot automaticamente

Ci sono diversi programmi per ingabbiare automaticamente server e servizi in ambienti chroot. Al momento (accettato nel maggio 2002) Debian fornisce chrootuid di Wietse Venema nel pacchetto chrootuid, così come compartment e makejail. Potete usare questi programmi per configurare un ambiente limitato ed eseguire qualunque programma (chrootuid permette addirittura di eseguirlo come un utente con restrizioni).

Alcuni di questi strumenti possono essere usati per configurare ambienti chroot in modo semplice. Il programma makejail, per esempio, può creare ed aggiornare una gabbia chroot con brevi file di configurazione (ne fornisce alcuni di esempio adatti per bind, apache, postgresql e mysql). Cerca di indovinare ed installare dentro la gabbia, tutti i file richiesti dal servizio, usando strace, stat e le dipendenze dei pacchetti Debian. Ulteriori informazioni presso http://www.floc.net/makejail/. Jailer è un programma simile che può essere scaricato da http://www.balabit.hu/downloads/jailer/.

FIXME: Ci sono pacchetti pronti per jailer, aggiornare questa sezione quando saranno accettati in Debian

Utile per creare ambienti chroot è deb.pl, uno script che analizza le dipendenze di un insieme di file.


5.11 In generale, paranoia per le password in chiaro

Siete invitati a non mantenere nessun servizio di rete che spedisca e riceva le password in chiaro usando FTP/Telnet/NIS/RPC. È raccomandato l'uso di ssh invece di telnet o di ftp.

Ricordate che questa migrazione da telnet a ssh, oppure da qualsiasi altro protocollo che spedisca testo in chiaro non incrina la sicurezza! La miglior cosa sarebbe quella di eliminare servizi quali ftp, telnet, pop, imap, http e sostituirli con i rispettivi servizi cifrati. Prendete in considerazione di migrare a servizi che hanno una versione SSL quali, ad esempio: ftp-ssl, telnet-ssl, pop-ssl, https ...

La maggior parte degli esempi riportati possono essere applicati su tutti i sistemi Unix (siete invitati a cercare altri documenti relativi a Linux e ad altri sistemi Unix).


5.12 Disabilitare NIS

Non usate NIS, il servizio di informazioni di rete, se possibile, perché permette la condivisione delle password. Questo rende il sistema molto insicuro, se non è configurato in modo ottimale.

Se avete bisogno di usare la password su più macchine, siete invitati a considerare altre alternative. Per esempio, potete configurare un server LDAP e configurare PAM nel vostro sistema in modo da fargli contattare il server LDAP per l'autenticazione dell'utente. Potete trovare una configurazione dettagliata nel LDAP-HOWTO (/usr/share/doc/HOWTO/en-txt/LDAP-HOWTO.txt.gz).

Altre informazioni su NIS potete trovarle nel NIS-HOWTO (/usr/share/doc/HOWTO/en-txt/NIS-HOWTO.txt.gz).

FIXME (jfs): Aggiungere informazioni su come configurarlo in Debian


5.13 Disabilitare i servizi RPC

Se non ne avete bisogno si consiglia di disabilitare RPC dove possibile. [25] Molti buchi di sicurezza relativi ai servizi basati su RPC sono conosciuti e possono essere facilmente sfruttati. Occorre ricercare il giusto compromesso tra sicurezza ed usabilità del vostro sistema. Molti degli attacchi DDoS (rifiuto di fornire un servizio distribuito) usano degli exploit per rpc al fine di entrare nel sistema, questo, è agire come uno agent/handler. Altre informazioni sulla sicurezza con NFS possono essere rinvenute nel NFS-HOWTO (/usr/share/doc/HOWTO/en-txt/NFS-HOWTO.txt.gz).

Disabilitare portmap è molto semplice. Esistono vari metodi. Il più semplice dei quali in un sistema Debian 3.0 è disinstallare il pacchetto portmap. Se usate un'altra versione potete disabilitare questo servizio come descritto nella Disabilitare i servizi attivi in modalità demone, Sezione 3.6.1, questo programma è una parte del pacchetto net-base (una volta disabilitato il servizio bisogna far ripartire il sistema).

Questo procedimento rimuove tutti i link a portmap presenti in /etc/rc${runlevel}.d/, il tutto si può eseguire anche manualmente. Un'altra possibilità è quella di cambiare i permessi, chmod 644 /etc/init.d/portmap ma questo comporterà in fase di boot un messaggio di errore. Potete altresì disabilitare lo script di shell start-stop-daemon che si trova in /etc/init.d/portmap.


5.14 Aggiungere funzionalità al firewall

Il sistema operativo Debian GNU/Linux possiede delle funzionalità implementate direttamente nel kernel. Se avete installato un sistema potato (Debian 2.2) (il kernel di default è il 2.2), potete contare su ipchains, sistema di firewall direttamente implementato nel kernel. Se avete invece woody (Debian 3.0) (dispone del kernel 2.4) avrete iptables (netfilter) come sistema di firewall. La maggiore differenza che potete riscontrare tra ipchains e iptables è che l'ultimo è basato sullo stateful packet inspection che provvede a configurazioni del filtraggio più sicure (e facili da realizzare).


5.14.1 Proteggere il sistema locale con un firewall

Potete usare le regole di un firewall per rendere più sicuro l'accesso al sistema e anche per limitare le comunicazioni in uscita. Le regole del firewall possono anche essere utilizzate per proteggere i processi che non possono essere adeguatamente configurati per non fornire servizi ad alcune reti, indirizzi IP, etc..

Comunque, questo passaggio è presentato per ultimo in questo manuale essenzialmente perché è molto meglio non dipendere unicamente dalle capacità di un firewall per proteggere un determinato sistema. La sicurezza in un sistema è data da livelli, in cui il firewall è l'ultimo da includere, una volta che tutti i processi sono stati rinforzati. Potete facilmente immaginare un'installazione in cui un sistema è protetto solo dal firewall in esso incorporato e un amministratore incautamente rimuove le regole del firewall per qualche motivo (problemi con l'installazione, fastidio, errore umano...), questo sistema sarebbe parecchio esposto ad un attacco se non ci fosse nessun altro rinforzo a proteggerlo.

D'altra parte, impostare le regole di un firewall sul sistema può anche prevenire il verificarsi di alcuni fatti spiacevoli. Anche se i servizi forniti sono configurati in modo sicuro, un firewall può proteggere da errate configurazioni o da servizi appena installati che non sono ancora stati configurati. Inoltre, una configurazione sicura previene il funzionamento di trojans che chiamano casa, finché il codice del firewall non viene rimosso. Notate che un intruso non necessita di un accesso superutente per installare un trojan locale che possa essere controllato da remoto (dato che il binding sulle porte è consentito se non si tratta di porte privilegiate e le funzionalità non sono state rimosse).

Quindi, il firewall impostato correttamente dovrebbe essere quello con una politica di negazione predefinita, secondo cui:


5.14.2 Utilizzare un firewall per proteggere altri sistemi

Un firewall Debian può anche essere installato per proteggere, con regole di filtraggio, accessi a sistemi dietro ad esso, limitando la loro esposizione su Internet. Il firewall può essere configurato per proteggere i sistemi all'esterno della rete locale d'accesso a servizi (porte) che non sono pubblici. Per esempio, su un server di posta, solo la porta 25 (che fornisce il servizio di posta) ha bisogno di essere accessibile dall'esterno. Un firewall può essere configurato, anche se ci sono altri servizi oltre a quelli pubblici, per respingere pacchetti (questo è conosciuto come filtraggio) diretti verso di sé.

Potete anche configurare un sistema Debian GNU/Linux come bridge firewall, ad esempio un firewall filtrante privo di indirizzo IP, completamente trasparente alla rete e che quindi non può essere attaccato direttamente. A seconda del kernel che avete installato potreste aver bisogno di installare la patch per il bridge firewall; andate quindi su 802.1d Ethernet Bridging durante la configurazione del kernel e abilitate la nuova opzione netfilter (firewalling) support. Leggete Impostare un bridge firewall, Appendice D per ulteriori informazioni su come meglio sfruttare questa funzionalità sul vostro sistema Debian GNU/Linux.


5.14.3 Configurare il firewall

Naturalmente, la configurazione del firewall dipende sempre dal sistema e dalla rete. Un amministratore deve conoscere anticipatamente qual'è la struttura di rete e i sistemi che vuole proteggere, i servizi che hanno bisogno di fornire accesso e se tenere presente o meno altre considerazioni di rete (come NAT o routing). Prestate attenzione durante la configurazione del firewall, come dice Laurenc J. Lane nel pacchetto iptables:

È facile fare un cattivo uso degli strumenti, causando gravi danni e bloccando completamente l'accesso di rete ad un sistema. Non è così raro per un amministratore di un sistema remoto restarne bloccato fuori a centinaia o migliaia di chilometri di distanza. Può anche succedere di bloccare l'accesso al computer che si ha sotto le dita. Quindi, usate la dovuta cautela.

Ricordate: la semplice installazione di iptables (o di altri programmi per gestire firewall) non dà nessuna protezione, fornisce solamente il software. Per poter avere un firewall è necessario configurarlo!

Se non conoscete abbastanza un firewall, leggete il Firewalling-HOWTO che trovate nel pacchetto doc-linux-text (sono disponibili altri formati del documento). Consultate Conoscere i problemi generali di sicurezza, Sezione 2.2 per indicazioni (generali).


5.14.3.1 Farlo alla Debian

Se state usando la versione 3.0 di Debian, noterete che il pacchetto iptables viene installato. È il supporto per l'implementazione di netfilter per i kernel 2.4.4 e superiori. Dal momento che subito dopo l'installazione il sistema non può conoscere le regole del firewall (le regole per il firewall sono troppo specifiche del sistema), dovete esplicitamente abilitare iptables. Tuttavia, gli script sono stati configurati per consentire all'amministratore di impostare le regole del firewall, in modo che gli script di init possano conoscerle ed usarle sempre come impostazione per il firewall.

A tale scopo dovete:

Una volta fatto ciò, le impostazioni per il vostro firewall sono salvate nella directory /var/lib/iptables/ e saranno eseguite ad ogni avvio del sistema (o quando vengono eseguiti gli script di inizializzazione con gli argomenti start e stop). Si noti che le impostazioni predefinite di Debian avviano il firewall nei runlevel multiutente (da 2 a 5) molto presto (10). Inoltre il firewall viene arrestato quando il sistema va in monoutenza (runlevel 1), cambiate questa impostazione se non è conforme alla vostra politica locale.

Se non avete idea su come impostare le vostre regole di firewall manualmente, consultate il Packet Filtering HOWTO ed il NAT HOWTO, forniti con iptables per la lettura offline in /usr/share/doc/iptables/html/. Anche il file di configurazione /etc/default/iptables fornisce ulteriori informazioni sulle problematiche connesse a questo pacchetto.


5.14.3.2 Utilizzare il pacchetto Firewall

Impostare manualmente un firewall può essere complicato per un amministratore inesperto (e a volte anche per uno esperto). Tuttavia la comunità del software libero ha creato numerosi strumenti da utilizzare per la configurazione di un firewall locale. Siete avvertiti che alcuni strumenti sono molto orientati alla sola protezione locale (altresì nota come firewall personale), mentre altri sono più versatili e possono essere utilizzati per configurare regole complesse in modo da proteggere un'intera rete.

Alcuni software che possono essere utilizzati per impostare le regole di firewall su un sistema Debian sono:

Gli ultimi pacchetti: gfcc, firestarter e knetfilter sono GUI per l'amministrazione che utilizzano GNOME (i primi due) o KDE (l'ultimo), molto più orientate all'uso da parte di utenti (amministratori di sistemi casalinghi), rispetto agli altri pacchetti della lista che possono essere considerati più orientati all'uso da parte di amministratori.

Siete avvisati che alcuni pacchetti descritti precedentemente utilizzeranno script per firewall da eseguire all'avvio del sistema, questo andrà certamente in conflitto con l'impostazione classica (se configurata) producendo effetti non desiderati. Di solito lo script per il firewall che viene eseguito per ultimo sarà quello che configura il sistema (che potrebbe essere quello che non volete). Consultate la documentazione del pacchetto ed utilizzate soltanto una di queste impostazioni. Generalmente, altri programmi che vi aiutano ad impostare regole per il firewall possono modificare leggermente i file di configurazione.

FIXME: Aggiungere informazioni riguardanti questi pacchetti

FIXME: Controllare le informazioni sul firewall di Debian e cosa/come cambia dalle altre distribuzioni

FIXME: Dove dovrebbe essere abilitato il codice per il firewall personalizzato (domanda comune in debian-firewall?)

FIXME: Aggiungere informazioni su Zorp Zorp in Debian (vedete il Bug #88347. I pacchetti Debian sono disponibili ma dipendono da libglib1.3 che non è ancora disponibile nella distribuzione Debian).


[ precedente ] [ Contenuti ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ H ] [ I ] [ successivo ]

Securing Debian Manual

Version: 2.97, Mon, 16 May 2005 21:28:06 +0200

Javier Fernández-Sanguino Peña jfs@debian.org
Autore, Sezione 1.1
Per la traduzione si veda l'Appendice I