<!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>