netfilter/iptables FAQ Harald Welte Version $Revision: 1.22 $, $Date: 2001/07/28 18:24:10 $ Questo documento presenta le domande più frequenti (FAQ) incontrate nella mailing list di netfilter. Commenti / aggiunte / chiarimenti sono apprezzati e devono essere inviati al manutentore della FAQ. ______________________________________________________________________ Indice Generale 1. Domande generali 1.1 Dove posso reperire netfilter/iptables ? 1.2 Esiste un porting di netfilter per Linux 2.2 ? 1.3 Esiste un modulo conntrack/NAT di aiuto per ICQ? 1.4 Che cosa a riguardo dei moduli ip_masq_vdolive / ip_masq_quake / ... 1.5 Che cos'è la patch-o-matic e come si utilizza? 1.6 Dove posso reperire ipnatctl e informazioni a riguardo ? 2. Problemi durante il processo di compilazione 2.1 Non riesco a compilare iptables-1.1.1 con i kernel >= 2.4.0-test4 2.2 Non posso compilare iptables 1.1.0 con i kernel recenti (>= 2.3.99-pre8) 2.3 Alcune patch patch-o-matic di iptables-1.2.1a non funzionano con i kernel >= 2.4.4 2.4 Non riesco a compilare ipt_BALANCE / ip_nat_ftp / ip_nat_irc 2.5 Utilizzo la serie di kernel 2.4.x-acXX di Alan Cox e riscontro problemi 3. Problemi durante l'esecuzione 3.1 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb 3.2 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb 3.3 Non riesco ad utilizzare netfilter in combinazione con il codice di bridging di Linux 3.4 Il modulo IRC è incapace di gestire il resume di DCC 3.5 Come opera il SNAT con gli indirizzi multipli? 3.6 ip_conntrack: maximum limit of XXX entries exceeded 3.7 Come posso avere un elenco di tutte le connessioni tracciate / mascherate in modo simile a 'ipchains -L -M' (2.2.x) ? 3.8 Come posso visualizzare tutte le tabelle IP disponibili ? 3.9 segfault di iptables-save / iptables-restore con iptables-1.2 3.10 iptables -L impiega un tempo davvero lungo per visualizzare le regole 3.11 Come posso impedire al target LOG di visualizzare le registrazioni sulla console ? 3.12 Come posso implementare un proxy trasparente utilizzando squid e iptables ? 3.13 Come si utilizza il target LOG / Come utilizzare LOG e DROP ? 4. Domande riguardanti lo sviluppo di netfilter 4.1 Non capisco come utilizzare dallo userspace l'obiettivo QUEUE 4.2 Voglio contribuire con del codice, ma non so come fare 4.3 Ho corretto un bug o realizzato un'estensione. Come posso contribuire ? ______________________________________________________________________ 1. Domande generali Questa sezione copre le domande più frequenti incontrate nella mailing list riguardanti netfilter (e non). 1.1. Dove posso reperire netfilter/iptables ? Netfilter e IPtables sono integrati nel kernel Linux serie 2.4.x. Si prelevi un kernel recente all'indirizzo <> o da uno dei mirror. Il tool userspace 'iptables' è disponibile alla homepage di netfilter o uno dei suoi mirror <> <> oppure <>. 1.2. Esiste un porting di netfilter per Linux 2.2 ? No, al momento non c'è nulla. Ma se qualcuno vuole cominciare non dovrebbe essere troppo complicato, data l'interfaccia "pulita" verso lo stack di rete. Informateci per qualsiasi lavoro riguardante questo argomento. 1.3. Esiste un modulo conntrack/NAT di aiuto per ICQ? Se si è usati, su una box Linux 2.2, a mascherare, allora per utilizzare ICQ client-to-client si farà sicuramente utilizzo del modulo ip_masq_icq. Nessuno ha reimplementato questo modulo per netfilter in quanto il protocollo ICQ è davvero brutto :) Ma ritengo che sia solo una questione di tempo prima che sia reso disponibile. Rusty una volta ha puntualizzato che solo i moduli riguardanti protocolli con almeno un client free e un server free sono destinati ad essere integrati nella distribuzione principale di netfilter. Per quanto riguarda ICQ, ci sono solo client free, quindi non soddisfa questo criterio (free inteso come libero, non come birra gratis, definizione RMS). 1.4. Che cosa a riguardo dei moduli ip_masq_vdolive / ip_masq_quake / ... Alcuni non sono più necessari, altri non sono stati ancora portati in netfilter. Netfilter effettua un tracciamento completo anche del protocollo UDP e adotta una linea che cerca di disturbare il meno possibile i pacchetti, perciò a volte le cose `funzionano'. 1.5. Che cos'è la patch-o-matic e come si utilizza? I kernel 2.4.x sono release stabili quindi non è possibile aggiungere il codice sviluppato direttamente nel kernel. Tutto il codice viene sviluppato e testato prima di tutto utilizzando patch-o-matic. Se si desidera utilizzare una qualsiasi delle funzioni emergenti di netfilter è necessario applicare una o più delle sue patch. patch-o- matic è disponibile nel più recente pacchetto iptables (oppure naturalmente nella CVS) reperibile sulla homepage di netfilter. patch-o-matic ha un'interfaccia utente pulita. Si utilizzi: make patch-o-matic oppure, se il proprio kernel non è in /usr/src/linux si usi: make KERNEL_DIR={your-kernel-dir} patch-o-matic nella directory del pacchetto iptables. patch-o-matic verificherà ciascuna delle patch che eventualmente si vorranno applicare al sorgente del kernel installato. Se una patch può essere applicata comparirà un piccolo prompt che si potrà utilizzare per richiedere ulteriori informazioni sulla patch, applicarla, passare alla successiva, ... 1.6. Dove posso reperire ipnatctl e informazioni a riguardo ? ipnatctl era utilizzato con i kernel 2.3.x durante le prime revisioni di sviluppo di netfilter per impostare le regole NAT attraverso lo userspace. Ora non è più necessario e quindi non più disponibile. Tutte le funzionalità che offriva sono ora fornite direttamente da iptables. Si dia un'occhiata al NAT HOWTO presente nella homepage di Netfilter. 2. Problemi durante il processo di compilazione 2.1. Non riesco a compilare iptables-1.1.1 con i kernel >= 2.4.0-test4 Questo è un problema noto. Il meccanismo che determina quale patch applicare è corrotto. Provare con "make build" al posto di "make". Soluzione migliore: effettuare aggiornamento a iptables-1.1.2 o superiore 2.2. Non posso compilare iptables 1.1.0 con i kernel recenti (>= 2.3.99-pre8) Strutture interne di iptables sono state modificate. Aggiornare iptables >= 1.1.1 2.3. Alcune patch patch-o-matic di iptables-1.2.1a non funzionano con i kernel >= 2.4.4 Si utilizzi iptables-1.2.2 o si usi la CVS di netfilter. 2.4. Non riesco a compilare ipt_BALANCE / ip_nat_ftp / ip_nat_irc Molto probabilmente si sono riscontrati problemi di compilazione con la funzione denominata ip_nat_setup_info. Se si utilizza iptables <= 1.2.2 sarà NECESSARIO applicare le patch 'dropped-table' e 'ftp-fixes'. Se si utilizza iptables > 1.2.2 o una recente CVS non si applichi la 'dropped-table', in quanto incompatibile con BALANCE, NETMAP, irc-nat, SAME e talk-nat. 2.5. Utilizzo la serie di kernel 2.4.x-acXX di Alan Cox e riscontro problemi Il core team di netfilter basa lo sviluppo sul kernel di Linus, quindi utilizzare la serie -ac è a vostro rischio. 3. Problemi durante l'esecuzione 3.1. NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb Questo messaggio viene segnalato dal codice NAT in quanto pacchetti multicast hanno raggiunto la tabella NAT. Il connection tracking al momento non è in grado di gestire questi pacchetti. Nel caso non si abbia idea di cosa sia il multicast o non se ne abbia bisogno si utilizzi: iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8 3.2. NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb Il syslog o la console presentano il messaggio: "NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb" Questo messaggio è segnalato dal codice NAT. I pacchetti sono scartati in quanto per effettuare il NAT sono necessarie informazioni valide sul tracciamento delle connessioni. Questo messaggio viene incluso per tutti i pacchetti per i quali il connection tracking non è in grado di determinare informazioni conntrack. Possibili ragioni sono: · raggiungimento del limite massimo di entry nel database conntrack · impossibilità di determinare le tuple inverse (multicast, broadcast) · fallimento della kmem_cache_alloc (memoria esaurita) · risposta su una connessione non confermata · pacchetti multicast (si veda la domanda successiva) · pacchetto icmp troppo "corto" · icmp frammentato · icmp checksum non corretto Se si desidera un logging dettagliato di questi pacchetti (es. se si sospettano pacchetti di scanning / probe remoto) si utilizzi la seguente regola: iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID E sì, si deve inserire la regola nella tabella mangle, in quanto i pacchetti sono scartati dal codice NAT prima che raggiungano la tabella filter. 3.3. Non riesco ad utilizzare netfilter in combinazione con il codice di bridging di Linux Si vuole realizzare un completo firewall trasparente ? Ottima idea! Sfortunatamente il codice di bridging scavalca il normale stack di rete, incluso netfilter. C'è comunque qualcuno che sta scrivendo un rimpiazzo per il codice di bridging attuale, visitare il sito <>. Si noti che il supporto bridge per il firewall è considerato ancora altamente sperimentale. 3.4. Il modulo IRC è incapace di gestire il resume di DCC Bene, questa è una mezza verità. Solo il modulo NAT non è in grado di gestirla. Se il firewall non utilizza il NAT allora dovrebbe funzionare bene. 3.5. Come opera il SNAT con gli indirizzi multipli? Netfilter cerca di manipolare il meno possibile. Perciò se la macchina è appena stata riavviata, e qualcuno dietro la SNAT box apre una connessione utilizzando la porta locale 1234, la netfilter box cercherà di manipolare solo l'indirizzo IP mentre la porta resterà la stessa. Se per effettuare il SNAT si usa un unico indirizzo IP, appena qualcuno aprirà un'altra connessione utilizzando la stessa porta sorgente, netfilter interverrà manipolando sia l'indirizzo IP sia la porta. Se sono però disponibili più indirizzi allora dovrà continuare a maneggiare ancora ed esclusivamente la parte IP. 3.6. ip_conntrack: maximum limit of XXX entries exceeded Se si nota il seguente messaggio nel syslog allora il database conntrack non ha un numero sufficiente di entry per il proprio "ambiente". Il connection tracking per default gestisce fino ad un certo numero di connessioni simultaneamente. Questo numero dipende dalla quantità massima di memoria disponibile nel proprio sistema (64MB: 4096, 128MB: 8192, ...). Si può incrementare il numero massimo di connessioni da tracciare in modo alquanto semplice, tuttavia si presti attenzione al fatto che ogni connessione tracciata richiede circa 500 byte di memoria kernel non di swap. Per elevare questo limite a 8192 per esempio, si deve impartire: echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max Ovviamente si può utilizzare un qualsiasi numero sempre che possa però essere contenuto, a seconda del proprio hardware, in un 'int' (ciò significa 32 bit nella maggior parte delle piattaforme). Si tenga presente che ogni connessione tracciata ha bisogno di un certo ammontare di memoria del kernel non di swap ( 500 byte per connessione, tanto per indicare un numero). 3.7. Come posso avere un elenco di tutte le connessioni tracciate / mascherate in modo simile a 'ipchains -L -M' (2.2.x) ? Nel filesystem proc è presente un file denominato /proc/net/ip_conntrack. E' possibile visualizzare questo file utilizzando: cat /proc/net/ip_conntrack 3.8. Come posso visualizzare tutte le tabelle IP disponibili ? Si può ottenere un elenco di tutte le tabelle IP disponibili utilizzando cat /proc/net/ip_tables_names 3.9. segfault di iptables-save / iptables-restore con iptables-1.2 Bug noto. Si aggiorni utilizzando la CVS o si utilizzi iptables >= 1.2.1 appena sarà disponibile. 3.10. iptables -L impiega un tempo davvero lungo per visualizzare le regole Ciò è dovuto a iptables il quale deve effettuare una consultazione del DNS per ogni indirizzo IP. Siccome ogni regola consiste di due indirizzi, il caso peggiore prevede due consultazioni del DNS per regola. Il problema, se si utilizzano indirizzi IP privati (tipo 10.x.x.x oppure 192.168.x.x) è causato dall'impossibilità per il DNS di risolvere un hostname e quindi dal time out. La somma di tutti i time out può diventare davvero consistente, a seconda del proprio set di regole. Si utilizzi l'opzione -n (numeric) di iptables per impedire le consultazioni inverse del DNS. 3.11. Come posso impedire al target LOG di visualizzare le regis­ trazioni sulla console ? E' necessario configurare sylogd in modo appropriato: il target LOG deve registrare utilizzando la facility kern con priority warning (4). Si consultino le pagine del manuale di syslogd.conf per ricavare maggiori informazioni su facility e priority. Di default tutti i messaggi del kernel con priorità più rigorose di debug (7) sono inviati alla console. Se lo si imposta a 4, invece di 7, si ottiene che i messaggi non appariranno più sulla console. Si presti attenzione in quanto potrebbero non essere visualizzati sulla console anche altri messaggi importanti (ciò non influenza syslog). 3.12. Come posso implementare un proxy trasparente utilizzando squid e iptables ? Prima di tutto ovviamente è necessario un'opportuna regola NAT o REDIRECT. Si utilizzi REDIRECT solamente se squid è in esecuzione sulla NAT box stessa. Esempio: iptables -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128 Dopo di ché è necessario configurare squid in modo appropriato. E' possibile indicare qui solo brevi note, per ulteriori dettagli si consulti la documentazione di squid. Per Squid 2.3 è necessario che il file squid.conf assomigli a quanto segue: http_port 3128 httpd_accel_host virtual httpd_accel_port 80 httpd_accel_with_proxy on httpd_accel_uses_host_header on Squid 2.4 richiede l'aggiunta di un'ulteriore linea: httpd_accel_single_host off 3.13. Come si utilizza il target LOG / Come utilizzare LOG e DROP ? Il target LOG è ciò che si definisce un "target non terminante", ossia non causa l'interruzione della traversata del pacchetto tra le regole. Se si utilizza il target LOG il pacchetto sarà registrato e la traversata sarà continuata con la regola successiva. Quindi come effettuare il log e il drop nello stesso istante ? Nulla di più semplice è sufficiente creare una catena con le seguenti due regole: iptables -N logdrop iptables -A logdrop -j LOG iptables -A logdrop -j DROP Ora ogni qualvolta si desideri il log e drop di un pacchetto è sufficiente utilizzare "-j logdrop". 4. Domande riguardanti lo sviluppo di netfilter 4.1. Non capisco come utilizzare dallo userspace l'obiettivo QUEUE Per la gestione dei pacchetti nello userspace (spazio utente) è stata prevista una libreria denominata libipq. Ora è finalmente disponibile documentazione a riguardo sotto forma di pagine di manuale. E' necessario compilare e installare i componenti di sviluppo di iptables: make install-devel quindi consultare libipq(3). Si potrebbe essere interessati inoltre all'interfacciamento tra Perl e libipq, si veda Perlipq: . L'interfacciamento è già di per sé un esempio di come possa essere utilizzata la libreria. Altro codice di esempio incluso: · testsuite/tools/intercept.c presente nella CVS di netfilter · ipqmpd (visitare <>) · nfqtest, parte dei tool di netfilter (visitare <>) 4.2. Voglio contribuire con del codice, ma non so come fare Il core team di netfilter mantiene un lista TODO dove vengono elencati tutti i cambiamenti / nuove funzionalità desiderate. Si può ottenere questa lista accedendo alla CVS come anonymous, istruzioni a riguardo si trovano nella homepage di netfilter. In alternativa si può visitare <> e utilizzare CVSweb. 4.3. Ho corretto un bug o realizzato un'estensione. Come posso con­ tribuire ? Se si desidera pubblicare una di queste la si invii alla mailinglist netfilter-devel. Istruzioni riguardanti l'iscrizione sono presenti all'indirizzo . Il modo corretto per inviare una patch prevede che: · l'oggetto cominci con [PATCH] · siano inclusi i diritti nel corpo del messaggio, non MIME. · sia presente una voce cvs-checkin/Changelog esterno al diff. · sia utilizzata la forma `diff -u old new' dall'esterno della directory root (ossia che possa quindi essere applicata con -p1 quando collocata nella directory untar-rata).