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.
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:
Fa in modo che ssh ascolti solo su una data interfaccia, nel caso ne abbiate più di una (e non vogliate che ssh sia disponibile per le altre) o nel caso prevediate di aggiungere schede di rete in futuro (e non vogliate connessioni a ssh da quest'ultime).
Cerca di impedire l'autenticazione come root quando possibile. Se volete diventare root con ssh, ora sono necessarie due autenticazioni e la password di root non può essere ottenuta con un attacco a forza bruta attraverso SSH.
Cambia la porta di ascolto, così l'intruso non può essere del tutto certo che ci sia un demone ssh (bisogna tenere conto che in questo caso si tratta di sicurezza mediante riservatezza (security by obscurity)).
Utilizzare password vuote significa prendersi gioco della sicurezza del sistema.
Permette solo ad alcuni utenti di avere accesso alla macchina con ssh. user@host può anche essere usato per permettere l'accesso di un dato utente solo da un determinato host.
Permette l'accesso alla macchina con ssh solo ai membri di un determinato gruppo. AllowGroups e AllowUser hanno regole equivalenti per negare l'accesso ad una macchina chiamante senza sorprese, "DenyUsers" e "DenyGroups".
Siete liberi di scegliere come fare. È più sicuro permettere l'accesso alla macchina solo agli utenti le cui chiavi ssh sono contenute nel file ~/.ssh/authorized_keys. Se questo è il comportamento desiderato, impostate questa opzione a "no".
sshd_config(5)
).
Disabilita il protocollo versione 1, visto che ha dei difetti di progettazione
che rendono più facile corrompere (crack passwords) le password. Per maggiori
informazioni leggete il documento
relativo ai problemi del protocollo ssh
o le raccomandazioni di
Xforce
.
Aggiunge un avviso (contenuto nel file) agli utenti che si connettono a un server ssh. In alcuni stati, per avere protezione legale, occorre inviare un avviso prima di accedere a certo sistema che avvisi quando l'accesso non è autorizzato o che state controllando gli accessi degli utenti.
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
.
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.
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).
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:
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):
calamaris
- Analizzatore di log per i file di Squid e Oops.
modlogan
- Un analizzatore modulare dei file di log.
squidtaild
- Un programma per monitorare i log di Squid.
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
.
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
.
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.
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.
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.
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.
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.
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.
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)
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.
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.
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
.
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.
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.
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.
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.
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.
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.
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.
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).
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
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
.
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).
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:
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.
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).
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:
/etc/default/iptables
in modo tale che la variabile
enable_iptables_initd fosse impostata a true.
iptables(8)
) o alcuni strumenti forniti
dal pacchetto Debian firewall (vedete in Utilizzare
il pacchetto Firewall, Sezione 5.14.3.2). Dovete creare un'insieme di
regole per il firewall da utilizzare quando il firewall è attivo e uno
da utilizzare quando il firewall è inattivo (queste possono
semplicemente essere regole vuote).
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.
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:
firestarter
, orientato agli utenti finali, include una semplice
procedura per l'impostazione delle regole del firewall
knetfilter
fwbuilder
, una GUI orientata agli oggetti, che include compilatori
di politiche per varie piattaforme di firewall, che comprendono iptables, così
come le liste di accesso per router.
shorewall
fornisce supporto per IPsec, oltre ad un limitato
supporto per la regolazione del traffico, così come la definizione delle regole
per il firewall.
mason
, che può proporre regole di firewall in base al traffico che
"vede" il vostro sistema.
bastille
(tra le iniziative più efficaci che possono essere
inserite nelle nuove versioni di bastille c'è la possibilità di aggiungere
regole per il firewall da eseguire all'avvio del sistema).
ferm
fwctl
easyfw
firewall-easy
ipac-ng
gfcc
lokkit
o gnome-lokkit
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).
Securing Debian Manual
Version: 2.97, Mon, 16 May 2005 21:28:06 +0200jfs@debian.org