<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Linux IPCHAINS HOWTO: Miscellanea</TITLE>
<LINK HREF="IPCHAINS-HOWTO-6.html" REL=next>
<LINK HREF="IPCHAINS-HOWTO-4.html" REL=previous>
<LINK HREF="IPCHAINS-HOWTO.html#toc5" REL=contents>
</HEAD>
<BODY>
<A HREF="IPCHAINS-HOWTO-6.html">Avanti</A>
<A HREF="IPCHAINS-HOWTO-4.html">Indietro</A>
<A HREF="IPCHAINS-HOWTO.html#toc5">Indice</A>
<HR>
<H2><A NAME="s5">5. Miscellanea</A></H2>
<P>Questa sezione contiene tutte le informazioni e le FAQ che non sono
riuscito a sistemare nella struttura precedente.
<P>
<H2><A NAME="organisation"></A> <A NAME="ss5.1">5.1 Come organizzare le proprie regole firewall</A>
</H2>
<P>Questa domanda richiede qualche riflessione. Si può provare a
organizzarle per ottimizzare la velocità (minizzare il numero di
verifiche di regole per i pacchetti più comuni) o per incrementare la
gestibilità.
<P>
<P>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 <CODE>ip-up</CODE>:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# 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
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Lo script <CODE>ip-down</CODE> potrebbe essere così:
<P>
<BLOCKQUOTE><CODE>
<PRE>
ipchains -R input 1 -i ppp0 -j DENY
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>
<H2><A NAME="ss5.2">5.2 Cosa non filtrare</A>
</H2>
<P>Ci sono alcune cosette di cui bisogna essere consci prima di
cominciare a filtrare tutto quello che non si vuole.
<P>
<H3><A NAME="ICMP"></A> Pacchetti ICMP</H3>
<P>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.
<P>
<P>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.
<P>
<P>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.
<P>
<H3>Connessioni TCP al DNS (nameserver)</H3>
<P>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.
<P>
<P>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.
<P>
<P>Se le proprie interrogazioni DNS sono sempre dirette alla stessa fonte
esterna (sia direttamente usando una riga <CODE>nameserver</CODE> in
<CODE>/etc/resolv.conf</CODE> oppure usando un caching nameserver in
modalità forward), allora si devono permettere solo le connessioni TCP
alla porta <CODE>domain</CODE> di quel nameserver dalla porta
<CODE>domain</CODE> locale (se si sta usando un caching nameserver) o da
una porta più alta (> 1023) se si sta usando
<CODE>/etc/resolv.conf</CODE>.
<P>
<H3><A NAME="ftp"></A> Incubi da FTP</H3>
<P>FTP presenta un classico problema del filtraggio dei pacchetti. FTP
ha due <B>modalità</B>; quella tradizionale è detta <B>modalità
attiva</B> e quella più recente è detta <B>modalità passiva</B>. I
web browser solitamente usano la modalità passiva, mentre i programmi
per FTP a riga di comando solitamente usano la modalità attiva.
<P>
<P>In modalità attiva, quando il sito remoto vuole inviare un file
(oppure anche il risultato di un comando <CODE>ls</CODE> o <CODE>dir</CODE>)
apre una connessione TCP verso la macchina locale. Ciò significa che
non si possono filtrare queste connessioni TCP senza rompere l'FTP
attivo.
<P>
<P>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).
<P>
<H2><A NAME="ss5.3">5.3 Filtrare i Ping della Morte</A>
</H2>
<P>La macchine Linux sono ora immuni ai famosi <B>Ping della Morte</B>,
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.
<P>
<P>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 a 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.
<P>
<P>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.
<P>
<H2><A NAME="ss5.4">5.4 Filtrare Teardrop e Bonk</A>
</H2>
<P>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.
<P>
<H2><A NAME="ss5.5">5.5 Filtrare i Fragment Bomb</A>
</H2>
<P>Si dice che alcuni stack TCP meno affidabili hanno problemi a gestire
un grande 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).
<P>
<H2><A NAME="ss5.6">5.6 Cambiare le regole firewall</A>
</H2>
<P>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:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# 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
#
</PRE>
</CODE></BLOCKQUOTE>
<P>Ciò scarta tutti i pacchetti per la durata delle modifiche.
<P>
<P>Se le proprie modifiche sono ristrette a 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.
<P>
<H2><A NAME="antispoof"></A> <A NAME="ss5.7">5.7 Come proteggersi dall'IP Spoofing?</A>
</H2>
<P>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).
<P>
<P>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 <CODE>/proc/sys/net/ipv4/conf/all/rp_filter</CODE>. Se esiste,
allora attivare il Source Address Verification a 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:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# Questo è il metodo migliore: attivare il Source Address Verification
# e avere così la protezione dallo spoof 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
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>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 <CODE>lo</CODE>).
<P>
<P>Per esempio, facciamo il caso che ci siano tre interfacce:
<CODE>eth0</CODE>, <CODE>eth1</CODE> e <CODE>ppp0</CODE>. Possiamo usare
<CODE>ifconfig</CODE> per conoscere l'indirizzo e la netmask delle
interfacce. Diciamo che <CODE>eth0</CODE> sia attaccata alla rete
192.168.1.0 con netmask 255.255.255.0, <CODE>eth1</CODE> sia attaccata
alla rete 10.0.0.0 con netmask 255.0.0.0 e che <CODE>ppp0</CODE> connetta
con Internet (dov'è permesso qualsiasi indirizzo tranne quelli
riservati come indirizzi IP privati). Inseriremo allora le seguenti
regole:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# 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
#
</PRE>
</CODE></BLOCKQUOTE>
<P>
<P>Questo approccio non è buono quanto l'approccio con il Source Address
Verification, perché se cambia la propria rete, si devono cambiare le
regole firewall.
<P>
<P>Se si usa un kernel della serie 2.0, si può voler proteggere anche
l'interfacia loopback, usando una regola come questa:
<P>
<BLOCKQUOTE><CODE>
<PRE>
# ipchains -A input -i ! lo -s 127.0.0.0/255.0.0.0 -j DENY
#
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H2><A NAME="ss5.8">5.8 Progetti avanzati</A>
</H2>
<P>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).
<P>
<P>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.
<P>
<P>Usando questa libreria possono essere implementate nello spazio
utente cose come la <B>stateful inspection</B> (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.
<P>
<H3>SPF: Stateful Packet Filtering</H3>
<P>
<A HREF="ftp://ftp.interlinx.bc.ca/pub/spf">ftp://ftp.interlinx.bc.ca/pub/spf</A> è 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.
<P>
<P>Attualmente c'è poca documentazione, ma ecco qui un post nella mailing
list nel quale Brian spiega un po' di cose:
<P>
<BLOCKQUOTE><CODE>
<PRE>
> 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 a una 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.
</PRE>
</CODE></BLOCKQUOTE>
<P>
<H3>L'ftp-data hack di Michael Hasenstein</H3>
<P> 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
<A HREF="http://www.suse.de/~mha/patch.ftp-data-2.gz">http://www.suse.de/~mha/patch.ftp-data-2.gz</A><P>
<H2><A NAME="ss5.9">5.9 Estensioni future</A>
</H2>
<P>Il firewalling e il NAT sono in fase di riprogettazione per il 2.4. I
piani e le discussioni sono disponibili nella lista netfilter (si veda
<A HREF="http://lists.samba.org">http://lists.samba.org</A>).
Queste estensioni dovrebbero chiarire parecchie questioni insolute
sull'usabilità (veramente, il firewalling e il masquerading non
dovrebbero essere <EM>così difficili</EM>), e permetteranno la
crescita di un firewalling maggiormente flessibile.
<P>
<HR>
<A HREF="IPCHAINS-HOWTO-6.html">Avanti</A>
<A HREF="IPCHAINS-HOWTO-4.html">Indietro</A>
<A HREF="IPCHAINS-HOWTO.html#toc5">Indice</A>
</BODY>
</HTML>
