Questa sezione contiene tutte le informazioni e le FAQ che non sono riuscito a sistemare nella struttura precedente.
Questa domanda richiede qualche riflessione. Si può provare ad organizzarle per ottimizzare la velocità (minizzare il numero di verifiche di regole per i pacchetti più comuni) o per incrementare la gestibilità.
Se si ha una connessione intermittente, diciamo una connessione PPP,
si può voler impostare la prima regola nella catena input a `-i ppp0
-j DENY' al boot del sistema, e poi mettere qualcosa di simile a
questo nello script ip-up:
# Ricrea la catena `ppp-in'.
ipchains-restore -f < ppp-in.firewall
# Rimpiazza la regola DENY con un salto alla catena di gestione del ppp.
ipchains -R input 1 -i ppp0 -j ppp-in
Lo script ip-down potrebbe essere così:
ipchains -R input 1 -i ppp0 -j DENY
Ci sono alcune cosette di cui bisogna essere consci prima di cominciare a filtrare tutto quello che non si vuole.
I pacchetti ICMP sono usati (tra le altre cose) per indicare fallimenti negli altri protocolli (come TCP o UDP). In particolare i pacchetti `destination-unreachable' (destinazione irraggiungibile). Bloccare questi pacchetti significa che non si riceveranno mai gli errori `Host unreachable' o `No route to host'; qualsiasi connessione semplicemente attenderà una riposta che non arriverà mai. Ciò è irritante, ma raramente fatale.
Un problema peggiore è la regola dei pacchetti ICMP nel MTU discovery. Tutte le buone implementazioni TCP (inclusa quella di Linux) usano MTU discovery per provare a capire quale sia il pacchetto più grosso che può arrivare a destinazione senza essere frammentato (la frammentazione abbassa le prestazioni. specialmente quando vengono occasionalmente persi dei frammenti). MTU discovery lavora inviando pacchetti con il bit "Don't Fragment" impostato, inviando poi pacchetti più piccoli se riceve un pacchetto ICMP che indica "Fragmentation needed but DF set" (`fragmentation-needed'). Questo è un pacchetto tipo `destination-unreachable', e se non viene mai ricevuto l'host locale non riduce l'MTU e le prestazioni saranno abissali o non esistenti.
Si noti che è comune bloccare tutti i messaggi redirect ICMP (tipo 5); possono essere usati per manipolare l'instradamento (sebbene gli stack IP buoni abbiano delle protezioni), e quindi sono spesso visti un come po' rischiosi.
Se si sta provando a bloccare tutte le connessioni TCP in uscita, si ricordi che il DNS non sempre usa UDP; se la risposta dal server supera i 512 byte, il client usa una connessione TCP (ancora diretta alla porta numero 53) per ottenere i dati.
Ciò può essere una trappola perché il DNS `praticamente funzionerà' se si disabilitano tali trasferimenti TCP; comunque se lo si fa possono capitare strani lunghi ritardi e altri occasionali problemi DNS.
Se le proprie interrogazioni DNS sono sempre dirette alla stessa fonte
esterna (sia direttamente usando una riga nameserver in
/etc/resolv.conf oppure usando un caching nameserver in
modalità forward), allora si devono permettere solo le connessioni TCP
alla porta domain di quel nameserver dalla porta
domain locale (se si sta usando un caching nameserver) o da
una porta più alta (> 1023) se si sta usando
/etc/resolv.conf.
FTP presenta un classico problema del filtraggio dei pacchetti. FTP ha due modalità; quella tradizionale è detta modalità attiva e quella più recente è detta modalità passiva. I web browser solitamente usano la modalità passiva, mentre i programmi per FTP a riga di comando solitamente usano la modalità attiva.
In modalità attiva, quando il sito remoto vuole inviare un file
(oppure anche il risultato di un comando ls o dir)
apre una connessione TCP verso la macchina locale. Ciò significa che
non si possono filtrare queste connessioni TCP senza rompere l'FTP
attivo.
Se si ha la possibilità di usare la modalità passiva, allora bene; la modalità passiva crea connessioni dati dal client al server, anche per i dati in ingresso. Altrimenti, è raccomandabile permettere connessioni TCP solamente verso porte superiori alla 1024 ma non tra 6000 e 6010 (la 6000 è usata per X-Windows).
La macchine Linux sono ora immuni ai famosi Ping della Morte, che implicano l'invio di un pacchetto ICMP illegalmente grande che fa andare in overflow i buffer nello stack TCP del ricevente con effetti devastanti.
Se vi vogliono proteggere macchine che potrebbero essere ancora vulnerabili, semplicemente si blocchino i frammenti ICMP. Normalmente i pacchetti ICMP non sono abbastanza grandi da richiedere frammentazione, e quindi non si romperà niente se non i grossi ping. Ho sentito (non confermato) che ad alcuni sistemi basta anche solo l'ultimo frammento di un pacchetto ICMP fuori misura per corromperli, e quindi non è raccomandabile bloccare solo il primo frammento.
Sebbene i programmi exploit che ho visto usano tutti ICMP, non c'è ragione per non usare frammenti TCP o UDP (o di un protocollo sconosciuto) per questi attacchi, e quindi bloccare i frammenti ICMP è solamente una soluzione temporanea.
Teardrop e Bonk sono due attacchi (rivolti principalmente contro macchine Microsoft Windows NT) che si basano sulla sovrapposizione dei frammenti. Le opzioni sono di far sì che il proprio router Linux effettui la deframmentazione oppure disabilitare tutti i frammenti verso le macchine vulnerabili.
Si dice che alcuni stack TCP meno affidabili hanno problemi a gestire un largo numero di frammenti di pacchetti quando non ricevono mai tutti i frammenti. Linux non ha questo problema. Si possono filtrare tutti i frammenti (il che interrompe pure il loro uso legittimo) oppure compilare il kernel attivando `IP: always defragment' (solo se la propria macchina Linux è il solo instradamento possibile per questi pacchetti).
Ci sono alcune questioni temporali coinvolte nella modifica delle regole firewall. Se non si fa attenzione, si possono lasciar passare pacchetti mentre si fanno le modifiche. L'approccio più semplice è il seguente:
# ipchains -I input 1 -j DENY
# ipchains -I output 1 -j DENY
# ipchains -I forward 1 -j DENY
... fare le modifiche ...
# ipchains -D input 1
# ipchains -D output 1
# ipchains -D forward 1
#
Ciò scarta tutti i pacchetti per la durata delle modifiche.
Se le proprie modifiche sono ristrette ad una sola catena, si potrebbe creare una nuova catena con le nuove regole e poi rimpiazzare (`-R') la regola che punta alla vecchia catena con quella che punta a quella nuova: poi si può cancellare la vecchia catena. Questo rimpiazzo sarà atomico.
L'IP spoofing è una tecnica nella quale un host invia pacchetti che affermano provenire da un altro host. Poiché il filtraggio dei pacchetti prende decisioni basandosi su questo indirizzo di provenienza, l'IP spoofing è utile solo con filtri di pacchetti un po' stupidi. È usato anche per nascondere l'identità dell'attaccante usando attacchi SYN, Teardrop, Ping della Morte e simili (non ci si preoccupi se non si sa cosa sono).
Il miglior modo per proteggersi dall'IP spoofing è chiamato Source
Address Verification (Verifica dell'Indirizzo di Provenienza), ed è
fatto dal codice di instradamento e non dal firewall. Si cerchi il
file /proc/sys/net/ipv4/conf/all/rp_filter. Se esiste,
allora attivare il Source Address Verification ad ogni avvio è la
giusta soluzione. Per farlo, si inseriscano le righe seguenti da
qualche parte nei propri script di inizializzazione, prima che sia
inizializzata qualsiasi interfaccia di rete:
# Questo è il metodo migliore: attivare il Source Address Verification
# ed avere così la protezione dallo spoof protection su tutte le
# intefacce correnti e future.
if [ -e /proc/sys/net/ipv4/conf/all/rp_filter ]; then
echo -n "Setting up IP spoofing protection..."
for f in /proc/sys/net/ipv4/conf/*/rp_filter; do
echo 1 > $f
done
echo "done."
else
echo PROBLEMS SETTING UP IP SPOOFING PROTECTION. BE WORRIED.
echo "CONTROL-D will exit from this shell and continue system startup."
echo
# Start a single user shell on the console
/sbin/sulogin $CONSOLE
fi
Se non si può fare così, si possono inserire manualmente delle regole
per proteggere ogni interfaccia. Ciò richiede conoscenza su qualsiasi
interfaccia. I kernel 2.1 automaticamente rifiutano i pacchetti che
affermano provenire dagli indirizzi 127.* (riservati per l'interfaccia
loopbak locale lo).
Per esempio, facciamo il caso che ci siano tre interfacce:
eth0, eth1 e ppp0. Possiamo usare
ifconfig per conoscere l'indirizzo e la netmask delle
interfacce. Diciamo che eth0 sia attaccata alla rete
192.168.1.0 con netmask 255.255.255.0, eth1 sia attaccata
alla rete 10.0.0.0 con netmask 255.0.0.0 e che ppp0 connetta
con Internet (dov'è permesso qualsiasi indirizzo tranne quelli
riservati come indirizzi IP privati). Inseriremo allora le seguenti
regole:
# ipchains -A input -i eth0 -s ! 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i ! eth0 -s 192.168.1.0/255.255.255.0 -j DENY
# ipchains -A input -i eth1 -s ! 10.0.0.0/255.0.0.0 -j DENY
# ipchains -A input -i ! eth1 -s 10.0.0.0/255.0.0.0 -j DENY
#
Questo approccio non è buono quanto l'approccio con il Source Address Verification, perché se cambia la propria rete, si devono cambiare le regole firewall.
Se si usa un kernel della serie 2.0, si può voler proteggere anche l'interfacia loopback, usando una regola come questa:
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#
Ho scritto una libreria (`libfw') che funziona dello spazio utente inclusa nei sorgenti. Usa la possibilità offerta da IP Chains 1.3 e superiori di copiare un pacchetto nello spazio utente (usando l'opzione di configurazione IP_FIREWALL_NETLINK).
Il valore marcato può essere usato per specificare il paramentro Quality of Service per i pacchetti o per specificare come fare l'inoltro di porta dei pacchetti. Non li ho mai usati, ma se si vuole scrivere qualcosa in proposito, mi si contatti.
Usando questa libreria possono essere implementate nello spazio utente cose come la stateful inspection (preferisco il termine dynamic firewalling). Un'altra idea interessante è il controllo dei pacchetti su base utente facendo delle ricerche in un demone nello spazio utente. Questo dovrebbe essere abbastanza facile.
ftp://ftp.interlinx.bc.ca/pub/spf è il sito del progetto SPF di Brian Murrell, che fa il tracking delle connessioni nello spazio utente. Aggiunge sicurezza significativa per siti a bassa banda.
Attualmente c'è poca documentazione, ma ecco qui un post nella mailing list nel quale Brian spiega un po' di cose:
> Credo che faccia esattamente quello che voglio: installare un regola
> temporanea di "arretramento" ("backward" rule) per permettere
> l'ingresso dei pacchetti come fossero una risposta ad un richiesta
> in uscita.
Yup, è esattamente quello che fa. Più protocolli supporta, più la
regola di "arretramento" funziona bene. Attualmente ha il supporto
(vado a memoria, quindi scusate qualsiasi errore o omissione) per FTP
(sia attivo che passivo, in ingresso e in uscita), RealAudio,
traceroute, ICMP e ICQ basilare (ingresso da un server ICQ e
connessioni TCP dirette, ma non c'è ancora il supporto per le
connessioni TCP dirette secondarie per altre cose come il
trasferimento di file, ecc.).
> È un rimpiazzo per ipchains o un supplemento?
È un supplemento. Penso a ipchains come al motore per permettere o
prevenire ai pacchetti di viaggiare attraverso la macchina Linux. SPF
è il pilota che monitorizza costantemente il traffico e dice a
ipchains come cambiare le sue tattiche per rispondere ai cambiamenti
nel traffico.
Michael Hasenstein della SuSE ha scritto una patch per il kernel che aggiunge a ipchains il tracking delle connessioni ftp. Attualmente può essere trovata a http://www.csn.tu-chemnitz.de/~mha/patch.ftp-data-2.gz
Il firewalling ed il NAT sono in fase di riprogettazione per il 2.3. I piani e le discussioni sono disponibili nell'archivio delle liste netdev e ipchains-dev. Queste estensioni dovrebbero chiarire parecchie questioni insolute sull'usabilità (veramente, il firewalling e il masquerading non dovrebbero essere così difficili), e permetteranno la crescita di un firewalling maggiormente flessibile.