Questa sezione descrive tutto quello che bisogna veramente sapere per costruire un filtro di pacchetti che incontri le proprie esigenze.
Il kernel parte con tre elenchi di regole; questi elenchi sono detti
firewall chains (catene firewall) o semplicemente
chains (catene). Le tre catene predefinite sono chiamate
rispettivamente input (ingresso), output (uscita) e
forward (inoltro). Quando arriva un pacchetto (diciamo,
attraverso la scheda Ethernet) il kernel usa la catena input
per decidere il suo destino. Se sopravvive a quel passo, allora il
kernel decide dove mandare sucessivamente il pacchetto (ciò è detto
routing (instradamento)). Se è destinato ad un'altra
macchina, consulta la catena forward. Alla fine, appena
prima che il pacchetto esca, il kernel consulta la catena
output.
Una catena è una lista di regole. Ogni regola dice ``se l'intestazione del pacchetto è fatta così, allora questo è quello che si deve fare con il pacchetto''. Se il pacchetto non soddisfa (verifica) una regola, allora viene consultata la successiva regola nella catena. Alla fine, se non ci sono altre regole da consultare, il kernel guarda la policy (tattica) della catena per decidere cosa fare. In un sistema conscio delle problematiche di sicurezza, questa tattica dice al kernel se rifiutare o proibire il pacchetto.
Per gli amanti dell'arte ASCII, questa figura mostra il percorso completo di un pacchetto entrante in una macchina.
----------------------------------------------------------------
| ACCEPT/ lo interface |
v REDIRECT _______ |
--> C --> S --> ______ --> D --> ~~~~~~~~ -->|forward|----> _______ -->
h a |input | e {Routing } |Chain | |output |ACCEPT
e n |Chain | m {Decision} |_______| --->|Chain |
c i |______| a ~~~~~~~~ | | ->|_______|
k t | s | | | | |
s y | q | v | | |
u | v e v DENY/ | | v
m | DENY/ r Local Process REJECT | | DENY/
| v REJECT a | | | REJECT
| DENY d --------------------- |
v e -----------------------------
DENY
Di seguito una descrizione di ogni stadio:
Questo è il test per verificare che il pacchetto non sia in qualche modo corrotto. Se lo è, è rifiutato.
In realtà c'è una verifica di integrità del pacchetto prima di ogni catena firewall, ma quello della catena input è il più importante. Alcuni pacchetti malformati possono confondere il codice per il controllo delle regole, e quindi sono qui rifiutati (se ciò avviene è stampato un messaggio nel syslog).
È la prima catena firewall contro la quale viene
testato il pacchetto. Se il verdetto della catena non è DENY
o REJECT, il pacchetto prosegue.
Se il pacchetto è una risposta (reply) ad un
precedente pacchetto "mascherato", è "demascherato" e passa
direttamente alla catena output. Se non si usa L'IP
Masquerading si cancelli questo percorso dal diagramma.
Il codice di instradamento esamina il campo di destinazione per decidere se questo pacchetto deve andare ad un processo locale (si veda Local process qui sotto) o inoltrato ad una macchina remota (si veda forward chain più avanti)
Un processo in esecuzione sulla macchina può ricevere pacchetti dopo il passo di Routing Decision, e può inviare pacchetti (che passano per il passo Routing Decision, e poi attraversano la catena output).
Se i pacchetti provenienti da un processo locale sono destinati ad un processo locale, attraverseranno la catena output con il campo interfaccia impostato a `lo', e poi ritornano attraverso la catena input sempre con interfaccia impostato a `lo'. L'interfaccia lo è solitamente chiamata interfaccia loopback.
Se il pacchetto non era stato creato da un processo locale, allora è esaminata la catena forward, altrimenti il pacchetto va verso la catena output.
Questa catena è attraversata da qualsiasi pacchetto che provi a passare attraverso questa macchina per andare verso un'altra.
Questa catena è attraversata da qualsiasi pacchetto un attimo prima di essere spedito fuori.
Per prima cosa si controlli di avere la versione di ipchains a cui fa riferimento questo documento:
$ ipchains --version
ipchains 1.3.9, 17-Mar-1999
Si noti che io raccomando la 1.3.4 (che non ha le opzioni lunghe, come `--sport'), o la 1.3.8 o superiori; queste sono molto stabili.
ipchains ha una pagina man piuttosto dettagliata (man
ipchains), e se servono ulteriori dettagli o particolari, si può
dare un'occhiata all'interfaccia di programmazione (man 4
ipfw), oppure al file net/ipv4/ip_fw.c nei sorgenti dei
kernel 2.1.x, che sono (ovviamente) le fonti più autorevoli.
Nel pacchetto sorgente c'è pure una eccellente scheda di riferimento rapido di Scott Bronson, in PostScript(TM) sia in formato A4 che US Letter.
Ci sono parecchie cose diverse che si possono fare con
ipchains. Per prima cosa le operazioni per gestire intere
catene. Si parte con tre catene predefinite input,
output e forward che non possono essere cancellate.
Ci sono diversi modi per manipolare le regole in una catena:
Ci sono alcune operazioni per il masquerading, che, in mancanza di un
posto migliore dove metterle, sono in ipchains:
La funzione finale (e forse la più utile) permette di controllare cosa succederebbe ad un dato pacchetto se volesse traversare una data catena.
Questa è la ragione di sussistenza di ipchains: la manipolazione delle regole. Molto probabilmente si useranno i comandi di aggiunta (-A) e cancellazione (-D). Gli altri (-I per l'inserimento e -R per il rimpiazzo) sono semplici estensioni di questi concetti.
Ogni regola specifica un insieme di condizioni che il pacchetto deve soddisfare, e cosa fare se il pacchetto le soddisfa (un "obiettivo"). Per esempio, si possono voler proibire tutti i pacchetti ICMP provenienti dall'indirizzo 127.0.0.1. Quindi in questo caso le nostre condizioni sono che il protocollo deve essere ICMP e che l'indirizzo di provenienza deve essere 127.0.0.1. Il nostro obiettivo è `DENY'.
127.0.0.1 è l'interfaccia `loopback', presente anche se non si possiede una vera connessione di rete. Si può usare il programma `ping' per generare tali pacchetti (semplicemente invia un pacchetto ICMP di tipo 8 (echo request) al quale tutti gli host cooperativi dovrebbero rispondere obbligatoriamente con un pacchetto ICMP di tipo 0 (echo reply)). Ciò lo rende molto utile per i test.
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.2 ms
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 0.2/0.2/0.2 ms
# ipchains -A input -s 127.0.0.1 -p icmp -j DENY
# ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
--- 127.0.0.1 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
#
Si può vedere che il primo ping ha successo (il `-c 1' dice a ping di inviare un solo pacchetto).
Poi si è aggiunta alla catena `input' una regola che specifica che per i pacchetti provenienti da 127.0.0.1 (`-s 127.0.0.1') con protocollo ICMP (`-p ICMP') si dovrà saltare a DENY (`-j DENY').
Poi si è verificata la nostra regola, usando un secondo ping. Ci sarà una pausa prima che il programma si stanchi di aspettare una risposta che non arriverà mai.
Si può cancellare la regola in due modi. Per prima cosa, poiché sappiamo che è la sola regola nella catena input, possiamo usare la cancellazione in base alla posizione, come in
# ipchains -D input 1
#
Il secondo modo è di ricopiare il comando -A precedente, rimpiazzando -A con -D. Ciò è utile quando si ha una complessa catena di regole e non si vuole star lì a contarle per scoprire che quella che si vuole cancellare è la 37-esima. In tal caso useremo:
# ipchains -D input -s 127.0.0.1 -p icmp -j DENY
#
Si è visto l'uso di `-p' per specificare il protocollo e di `-s' per specificare l'indirizzo di provenienza, ma ci sono altre opzioni che si possono usare per specificare le caratteristiche del pacchetto. Quel che segue è un compendio esaustivo.
Gli indirizzi IP di provenienza (-s) e destinazione (-d) possono essere specificati in quattro modi. Il modo più comune è di usare il nome completo, come `localhost' o `www.linuxhq.com'. Il secondo modo è di specificare l'indirizzo IP, come ad esempio `127.0.0.1'.
Il terzo ed il quarto modo permettono di specificare un gruppo di indirizzi IP, come ad esempio `199.95.207.0/24' o `199.95.207.0/255.255.255.0'. Entrambi specificano un qualsiasi indirizzo IP tra 192.95.207.0 e 192.95.207.255 estremi inclusi; le cifre dopo `/' dicono quali parti dell'indirizzo IP sono significative. I valori predefiniti sono `/32' o `/255.255.255.255' (corrispondenti a tutti gli indirizzi IP). Per specificare nessun indirizzo IP può essere usato `/0', come segue:
# ipchains -A input -s 0/0 -j DENY
#
Questa cosa è raramente usata, in quanto il suo effetto è lo stesso che non specificare affatto l'opzione `-s'.
Molte opzioni, tra le quali `-s' e `-d', possono avere gli argomenti preceduti da `!' (pronunciato `not') per effettuare la corrispondenza con indirizzi NON uguali a quelli dati. Per esempio, `-s ! localhost' corrisponde a qualsiasi pacchetto non proveniente da localhost.
Il protocollo può essere specificato con l'opzione `-p'. Il protocollo può essere un numero (se si conoscono i valori numerici dei protocolli IP) o un nome per i casi speciali di `TCP', `UDP' o `ICMP'. Non è importante come è scritto: vanno bene sia `tcp' che `TCP'.
I nomi dei protocolli possono essere preceduti da un `!' per negarli, con ad esempio `-p ! TCP'.
Nei casi particolari nei quali è specificato TCP o UDP come protocollo, ci può essere un argomento aggiuntivo che indica la porta TCP e UDP, oppure un intervallo (inclusivo) di porte (si veda anche Gestire i frammenti nel seguito). Un intervallo è rappresentato usando un carattere `:', come ad esempio `6000:6010', che copre 11 numeri di porte da 6000 a 6010 estremi compresi. Se è omesso il limite inferiore, il valore predefinito è 0. Se è omesso quello superiore, il suo valore predefinito è 65535. Quindi per specificare le connessioni TCP provenienti da porte inferiori alla 1024, la sintassi potrebbe essere `-p TCP -s 0.0.0.0/0 :1023'. I numeri di porta possono essere specificati anche attraverso il nome, eg. `www'.
Si noti che la specificazione può essere preceduta da un `!', che la nega. Quindi per specificare qualsiasi pacchetto TCP TRANNE i pacchetti WWW, si potrebbe specificare
-p TCP -d 0.0.0.0/0 ! www
È importante realizzare che la specifica
-p TCP -d ! 192.168.1.1 www
è molto diversa da
-p TCP -d 192.168.1.1 ! www
La prima specifica qualsiasi pacchetto TCP verso la porta WWW su qualsiasi macchina tranne la 192.168.1.1. La seconda specifica qualsiasi connessione TCP verso qualsiasi porta di 192.168.1.1 tranne la porta WWW.
Per finire, questo caso indica di escludere sia la porta WWW e che 192.168.1.1:
-p TCP -d ! 192.168.1.1 ! www
Anche ICMP permette argomenti opzionali, ma poiché ICMP non ha le porte (ICMP ha un tipo e un codice) hanno un significato diverso.
Possono essere specificati come nomi ICMP (si usi ipchains -h
icmp per la lista di nomi) dopo l'opzione `-s', oppure come tipo
e codice ICMP numerici, dove il tipo segue l'opzione `-s' e il codice
segue l'opzione `-d'.
I nomi ICMP sono piuttosto lunghi: basta usare solamente abbastanza lettere da rendere il nome distinguibile da ogni altro.
Di seguito una piccola tabella dei più comuni pacchetti ICMP:
Numero Nome Richiesto da
0 echo-reply ping
3 destination-unreachable qualsiasi traffico TCP/UDP.
5 redirect per l'instradamento, se non sta girando
il demone di instradamento
8 echo-request ping
11 time-exceeded traceroute
Si noti che i nomi ICMP al momento non possono essere preceduti da `!'.
NON NON NON si blocchino tutti i messaggi ICMP di tipo 3! (si veda Pacchetti ICMP più avanti).
L'opzione `-i' specifica il nome di un'interfaccia.
Un'interfaccia è il dispositivo fisico dal quale entra o esce il
pacchetto. Si può usare il comando ifconfig per avere un
elenco delle interfacce che al momento sono `sù' (ie. che al momento
funzionano).
L'interfaccia per i pacchetti in arrivo (ie. i pacchetti che stanno
attraversando la catena input) è considerata essere
l'interfaccia dalla quale entrano. Logicamente, l'interfaccia per i
pacchetti in partenza (i pacchetti che stanno attraversando la catena
output) è l'interfaccia dalla quale usciranno. Anche
l'interfaccia per i pacchetti che passano per la catena
forward è l'interfaccia dalla quale usciranno; a me sembra
una decisione piuttosto arbitraria.
È perfettamente legale specificare un'interfaccia che al momento non
esiste; la regola non sarà mai soddisfatta finché l'interfaccia non
viene attivata. Ciò è estremamente utile per le connessioni PPP in
dial-up (solitamente l'interfaccia ppp0) e simili.
Come caso speciale, un nome di intefaccia che termina con un `+'
corrisponderà a tutte le interfacce (che esistano o meno) che
iniziano con quella stringa. Per esempio, per specificare una regola
che corrisponda a tutte le interfacce PPP, può essere usata l'opzione
-i ppp+.
Il nome dell'interfaccia può essere preceduto da un `!' per far sì che sia soddisfatta da tutte le interfacce che NON corrispondono all'interfaccia (o alle interfacce) specificata.
Talvolta è utile permettere connessioni TCP in una direzione, ma non nell'altra. Per esempio, si può voler permettere connessioni verso un server WWW esterno ma non le connessioni da quel server.
L'approccio naive sarebbe quello di bloccare i pacchetti TCP provenienti da server. Sfortunantamente, le connessioni TCP richiedono per funzionare che i pacchetti possono andare in entrambe le direzioni.
La soluzione è di bloccare solo i pacchetti usati per richiedere una connessione. Questi pacchetti sono chiamati pacchetti SYN (ok, tecnicamente sono pacchetti con il flag SYN impostato, e i campi FIN e ACK non attivati, ma li chiameremo lo stesso pacchetti SYN). Non permettendo solamente questi pacchetti, si possono fermare i tentativi di connessione.
Per questo viene usata l'opzione `-y': è valida solamente per regole che specificano TCP come loro protocollo. Per esempio, per specificare un tentativo di connessione TCP da 192.168.1.1:
-p TCP -s 192.168.1.1 -y
Ancora una volta, questa opzione può essere negata precedendola con un `!' che significa tutti pacchetti tranni quelli per iniziare la connessione.
Qualche volta un pacchetto è troppo grande per passarci tutto intero nel cavo. Quando questo succede, il pacchetto è diviso in frammenti (fragments), ed inviato come pacchetti multipli. L'altro capo della connessione riassembla i pacchetti per ricostruire il pacchetto intero.
Il problema con i frammenti è che alcune delle specificazioni suddette (in particolare porta d'origine, porta di destinazione, tipo ICMP, codice ICMP o flag SYN TCP) richiedono che il kernel sbirci nella parte iniziale del pacchetto, che è contenuta solo nel primo frammento.
Se le propria macchina è la sola connessione ad una rete esterna,
allora si può dire al kernel di riassemblare tutti i frammenti che gli
passano attraverso, compilando il kernel con l'opzione IP: always
defragment posta a `Y'. Ciò evita il problema in maniera
pulita.
Diversamente, è importante capire come sono trattati i frammenti dalle
regole di filtraggio. Qualsiasi regola di filtraggio che chiede
informazioni che non si hanno non verrà soddisfatta. Ciò
significa che il primo frammento è trattato come qualsiasi altro
pacchetto. Non lo saranno invece il secondo e i successivi
frammenti. Quindi una regola -p TCP -s 192.168.1.1 www
(specificante una porta sorgente `www') non sarà mai soddisfatta da un
frammento (tranne al primo). E neppure la regola opposta -p TCP
-s 192.168.1.1 ! www.
Comunque, si può specificare una regola specifica per il secondo e i successivi frammenti, usando l'opzione `-f'. Ovviamente in questa regola per i frammenti è illegale specificare una porta TCP o UDP, un tipo o un codice ICMP oppure l'opzione per il SYN TCP.
È pure legale specificare che una regola non si applica al secondo e ai successivi frammenti, precendendo il `-f' con `!'.
Solitamente è considerata una cosa sicura lasciar passare il secondo e i successi frammenti, poiché il filtraggio avrà effetto sul primo frammento e quindi preverrà la ricostruzione nell'host di destinazione. Comunque, sono noti alcuni bug che permettono il crash di macchine semplicemente inviandogli frammenti.
Una nota per i capoccioni della rete: i pacchetti malformati (pacchetti TCP, UDP o ICMP troppo corti affinché il codice di firewalling possa leggere le porte o il codice e tipo ICMP) sono trattati come frammenti. Solo i frammenti TCP che iniziano alla posizione 8 sono esplicitamente scartati dal codice di firewall (dovrebbe apparire un messaggio nel syslog se succede questo).
Come esempio, la regola seguente scarterà qualsiasi frammento diretto a 192.168.1.1:
# ipchains -A output -f -d 192.168.1.1 -j DENY
#
OK, quindi ora si conoscono tutti i modi con i quali si può creare una regola che corrisponda ad un pacchetto. Se un pacchetto soddisfa una regola, succedono le seguenti cose:
Per varietà, le esaminerò in ordine di importanza.
Un obiettivo dice al kernel cosa farne di un pacchetto che soddisfa una regola. ipchains usa `-j' (penso `jump-to' - salta a) per la specifica dell'obiettivo. Il nome dell'obiettivo deve essere più corto di 8 caratteri, ed è importante come è scritto: "RETURN" e "return" sono completamente diversi.
Il caso più semplice è quando non è specificato alcun obiettivo. Questo tipo di regola (spesso detta regola di `accounting' - contabilità) è utile con contare semplicemente un certo tipo di pacchetto. Che questa regola sia o meno soddisfatta, semplicemente il kernel esamina la regola successiva nella catena. Per esempio, per contare il numero di pacchetti da 192.168.1.1, si può fare così:
# ipchains -A input -s 192.168.1.1
#
(Usando `ipchains -L -v' si possono vedere i contatori di byte e pacchetti associati con ciascuna regola).
Esistono sei obiettivi speciali. I primi tre, ACCEPT,
REJECT e DENY sono piuttosto semplici.
ACCEPT permette che il pacchetto passi. DENY scarta
il pacchetto come non fosse mai stato ricevuto. REJECT
scarta il pacchetto, ma (se non è un pacchetto ICMP) genera una
risposta ICMP per la sorgente per dirle che la destinazione non è
raggiungibile.
Quella dopo, MASQ dice al kernel di mascherare il pacchetto.
Affinché ciò funzioni, il proprio kernel dev'essere compilato con il
supporto per l'IP Masquerading. Per i dettagli si veda il
Masquerading-HOWTO e l'appendice
Differenze tra ipchains e ipfwadm. Questo obiettivo è valido
solo per pacchetti che attraversano la catena forward.
L'altro obiettivo principale è REDIRECT che dice al kernel
di inviare un pacchetto ad una porta locale invece di dove era
destinato ad andare. Può essere specificato solo per regole che
specificano TCP o UDP come loro protocolli. Opzionalmente, può essere
specificata una porta (nome o numero) dopo di `-j REDIRECT' che farà
sì che quel pacchetto sia dirottato a quella particolare porta anche
se era indirizzato ad un'altra porta. Questo obiettivo è valido solo
per pacchetti che attraversano la catena input.
L'obiettivo finale speciale è RETURN che è identico
all'uscita immediata dalla catena (si veda
Impostare la tattica nel seguito).
Qualsiasi altro obiettivo indica una catena definita dall'utente (come descritto in Operazione con intere catene nel seguito). Il pacchetto inizierà ad attraversare le regole in quella catena. Se quella catena non decide il destino del pacchetto, allora, una volta che è terminata la traversata della catena, si riprende dalla regola successiva nella catena corrente.
È ora di un altro po' arte ASCII. Si considerino due catene
(sciocche): input (la catena predefinita) e Test
(una catena definita dall'utente).
`input' `Test'
------------------------------ ------------------------------
| Regola1: -p ICMP -j REJECT | | Regola1: -s 192.168.1.1 |
|----------------------------| |----------------------------|
| Regola2: -p TCP -j Test | | Regola2: -d 192.168.1.1 |
|----------------------------| ------------------------------
| Regola3: -p UDP -j DENY |
------------------------------
Si consideri un pacchetto TCP proveniente da 192.168.1.1 e destinato a
1.2.3.4. Entra nella catena input e viene controllato
rispetto a Regola1: non la soddisfa. Soddisfa invece Regola2 il
cui obiettivo è Test. Quindi la successiva regola ad essere
esaminata è la prima di Test. Regola1 in Test è
soddisfatta ma non specifica un obiettivo, quindi Regola2 è la
prossima ad essere esaminata. Questa non è soddisfatta e si è così
raggiunta la fine delle catena. Si quindi ritorna alla catena
input, dove si è appena esaminata Regola2 e quindi ora si
esamina Regola3, che non viene soddisfatta.
Quindi il percorso del pacchetto è:
v ___________________________
`input' | / `Test' v
--------------------------|--/ -------------------------|----
| Regola1 | /| | Regola1 | |
|-------------------------|/-| |------------------------|---|
| Regola2 / | | Regola2 | |
|----------------------------| -------------------------v----
| Regola3 /--+___________________________/
--------------------------|---
v
Si veda la sezione Come organizzare le proprie regole di firewall per alcuni metodi per usare efficacemente le catene definite dall'utente.
Questo è un effetto collaterale che può avere una regola che viene soddisfatta: usando l'opzione `-l' si può far sì che il pacchetto che la soddisfa sia registrato. Solitamente questa cosa non la si vuole per i pacchetti di routine, ma è una caratteristica utile se si vogliono cercare eventi eccezionali.
Il kernel registra questa informazione come segue:
Packet log: input DENY eth0 PROTO=17 192.168.2.1:53 192.168.1.1:1025
L=34 S=0x00 I=18 F=0x0000 T=254
Questo messaggio di registrazione è pensato per essere conciso e contiene informazioni tecniche utili solo ai guru del networking, ma può essere utile anche al resto di noi. Si suddivide così:
Nei sistema Linux standard, questo output del kernel è catturato da klogd (il demone di registrazione del kernel) che lo passa poi al syslogd (il demone di registrazione di sistema). Il file `/etc/syslog.conf' controlla il comportamento di syslogd, specificando una destinazione per ogni `facility' (nel nostro caso la facility è "kernel") e `livello' (per ipchains, il livello usato è "info").
Per esempio, il mio /etc/syslog.conf (Debian) contiene due righe corrispondenti a `kern.info':
kern.* -/var/log/kern.log
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
Indica che i messaggi sono duplicati in `/var/log/kern.log' e in `/var/log/messages'. Per maggiori dettagli, si veda `man syslog.conf'.
Nell'intestazione IP ci sono quattro bit raramente usati, detti bit Type of Service (TOS - Tipo Di Servizio). Influenzano il modo in cui sono trattati i pacchetti; i quattro bit sono "Minimum Delay" (Ritardo Minimo), "Maximum Throughput" (Massima Velocità di Trasmissione), "Maximum Reliability" (Massima Affidabilità) e "Minimum Cost" (Minimo Costo). Solo ad uno di questo bit è permesso di essere impostato. Rob van Nieuwkerk, l'autore del codice di "maltrattamento" TOS, ne parla in questi termini:
Per me è importante specialmente il "Minimum Delay". L'ho attivato per i pacchetti "interattivi" nel mio router (Linux) a monte. Io sono dietro una connessione modem a 33k6. Linux prioritizza i pacchetti in 3 code. In questo modo ottengo accettabili prestazioni interattive mentre faccio dei meri download (potrebbe andare ancora meglio se non ci fosse una coda così grande nel driver della seriale, ma ora la latenza è mantenuta sotto gli 1.5 secondi).
Nota: ovviamente, non si ha controllo sui pacchetti in arrivo; si può controllare la priorità solamente dei pacchetti che lasciano la propria macchina. Per negoziare le priorità con l'altro capo della connessione, deve essere usato un protocollo tipo RSVP (non so niente in proposito, quindi non chiedete a me).
L'uso più comune è di impostare le connessioni di controllo di telnet e ftp a "Minimum Delay" e quelle dati FTP a "Maximum Throughput". Ciò può essere fatto come segue:
ipchains -A output -p tcp -d 0.0.0.0/0 telnet -t 0x01 0x10
ipchains -A output -p tcp -d 0.0.0.0/0 ftp -t 0x01 0x10
ipchains -A output -p tcp -s 0.0.0.0/0 ftp-data -t 0x01 0x08
L'opzione `-t' accetta altri due parametri addizionali, entrambi in esadecimale. Questi permettono di far giochetti complessi con i bit TOS: con la prima maschera è fatta l'AND con i TOS correnti del pacchetto, e poi del risultato viene fatta l'XOR con la seconda. Se è troppo confuso, allora si usi semplicemente la tabella seguente:
Nome del TOS Valore Uso Tipico
Minimum Delay 0x01 0x10 ftp, telnet
Maximum Throughput 0x01 0x08 ftp-data
Maximum Reliability 0x01 0x04 snmp
Minimum Cost 0x01 0x02 nntp
Andi Kleen puntualizza quanto segue:
Forse potrebbe essere utile aggiungere riferimenti al paramentro txqueuelen di ifconfig alla discussione dei bit TOS. La lunghezza predefinita della coda del dispositivo, regolata per le schede ethernet, per i modem è troppo lunga e fa sì che lo schedulatore a 3 bande (le cui code sono basate sui TOS) funzioni in maniera subottima. È una buona idea impostarla ad un valore tra 4 e 10 per le connessioni via modem o ISDN a canale b singolo. Questo è un problema dei kernel 2.0 e 2.1, ma mentre nei 2.1 esiste un'opzione di ifconfig (nei nettools recenti), nei 2.0 è necessaria una patch ai sorgenti dei device driver.
Quindi, per vedere i massimi benefici dalla manipolazione dei TOS nella connessioni PPP via modem, si usi `ifconfig $1 txqueuelen' nel proprio script /etc/ppp/ip-up. Il numero da usare dipende dalla velocità del modem e dalla dimesione del buffer nel modem; Andi ci mostra ancora la direzione da seguire:
Il miglior valore per una data configurazione si determina sperimentalmente. Se la coda è troppo corta in un router allora saranno scartati i pacchetti. Naturalmente si traggono benefici anche senza la riscrittura dei TOS, solo che la riscrittura dei TOS aiuta a dare beneficio ai programmi non cooperativi (tutti i programmi standard di Linux sono cooperativi).
Ciò permette una complessa e potente iterazione con la nuova implementazione di `Quality of Service' di Alexey Kuznetsov e con il forwading basato sulla marcatura degli ultimi kernel della serie 2.1. Darò maggiori informazioni non appena ne verrò in possesso. Questa opzione è ignorata nei kernel della serie 2.0.
Una caratteristica molto utile di ipchains è la possibilità di
raggruppare regole collegate dentro catene. Si possono chiamare le
catene come si vuole a meno che il nome non sia in conflitto con le
catene (input, output e forward) o gli
obiettivi (MASQ, REDIRECT, ACCEPT,
DENY, REJECT o RETURN) predefiniti.
Suggerisco di evitare in toto l'uso di etichette in maiuscolo, in quanto
le potrei usare per estensioni future. Il nome della catena può
essere lungo fino a 8 caratteri.
Suvvia creiamo una nuova catena! Poiché sono un tipo con un sacco di
immaginazione, la chiamerò test.
# ipchains -N test
#
Tutto qua. Ora le si possono mettere dentro le regole come spiegato in precedenza.
Anche cancellare una catena è semplice.
# ipchains -X test
#
Perché `-X'? Beh, tutte le altre lettere buone erano già occupate.
Ci sono un paio di restrizioni sulla cancellazione di una catena: deve essere vuota (si veda Svuotare una catena nel seguito) e non deve essre l'obiettivo di nessuna regola. Non è possibile cancellare nessuna delle tre catene predefinite.
C'è un modo semplice per svuotare una catena di tutte le regole, usando il comando `-F' (flush).
# ipchains -F forward
#
Se non si specifica una catena, allora saranno svuotate tutte le catene.
Si possono elencare tutte le regole in una catena usando il comando `-L' (list).
# ipchains -L input
Chain input (refcnt = 1): (policy ACCEPT)
target prot opt source destination ports
ACCEPT icmp ----- anywhere anywhere any
# ipchains -L test
Chain test (refcnt = 0):
target prot opt source destination ports
DENY icmp ----- localnet/24 anywhere any
#
Il valore di `refcmt' mostrato per test è il numero di regole
che hanno test come loro obiettivo. Deve essere zero (e la
catena essere vuota) prima che si possa cancellarla.
Se è omesso il nome della catena, sono elencate tutte le catene, anche quelle vuote.
Ci sono tre opzioni che possono accompagnare `-L'. L'opzione `-n'
(numeric) è molto utile in quanto previene ipchains dal
tentativo di ricercare gli indirizzi IP, che (se si usa un DNS come
fanno molti) causerà parecchio ritardo se il proprio DNS non è
configurato correttamente, o si sono filtrate tutte le richieste DNS.
Inoltre fa sì che le porte siano mostrate come numeri piuttosto che
con i loro nomi.
L'opzione `-v' mostra tutti i dettagli delle regole, come i contatori di pacchetti e byte, le maschere TOS, l'interfaccia e la marcatura dei pacchetti. Diversamente questi valori sono omessi. Per esempio:
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
Si noti che i contatori di pacchetti e byte sono mostrati usando i suffissi `K', `M' o `G' rispettivamente per 1000, 1000000 e 1000000000. Usando l'opzione `-x' (espandi i numeri) verranno mostrati i numeri interi, senza preoccuparsi di quanto grandi siano.
È utile poter azzerare i contatori. Ciò può essere fatto con l'opzione `-Z' (zero counters). Per esempio:
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
# ipchains -Z input
# ipchains -v -L input
Chain input (refcnt = 1): (policy ACCEPT)
pkts bytes target prot opt tosa tosx ifname mark source destination ports
0 0 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
#
Il problema con questo approccio è che talvolta serve sapere il valore dei contatori un attimo prima di azzerarli. Nell'esempio precedente, tra i comandi `-L' e `-Z' potrebbero essere passati degli altri pacchetti. Per questa ragione, si possono usare `-L' and `-Z' assieme, per azzerare i contatori mentri li si legge. Sfortunatamente, se si fa così, non si può operare su una sola catena: si devono mostrare e azzerare tutte le catene in una volta.
# ipchains -L -v -Z
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere any
# ipchains -L -v
Chain input (policy ACCEPT):
pkts bytes target prot opt tosa tosx ifname mark source destination ports
10 840 ACCEPT icmp ----- 0xFF 0x00 lo anywhere anywhere any
Chain forward (refcnt = 1): (policy ACCEPT)
Chain output (refcnt = 1): (policy ACCEPT)
Chain test (refcnt = 0):
0 0 DENY icmp ----- 0xFF 0x00 ppp0 localnet/24 anywhere any
#
Si è visto cosa succede quando un pacchetto raggiunge la fine di una
catena predefinita quando si è discusso come un pacchetto cammina
attraverso una catena in
Specificare un obiettivo. In questo caso, la tattica (policy) di una
catena determina il destino del pacchetto. Solo le catene predefinite
(input, output e forward) hanno delle
tattiche, poiché se un pacchetto cade fuori dalla fine di una catena
definita dall'utente, la traversata riprende nelle catena precedente.
La tattica può essere una qualsiasi dei primi quattro obiettivi
speciali: ACCEPT, DENY, REJECT o
MASQ. MASQ è valida solamente per la catena
`forward'.
Inoltre è importante notare che un obiettivo RETURN in una
regola in una delle catene predefinite è utile per stabilire
esplicitamente la tattica di una catena quando un pacchetto soddisfa
una regola.
Ci sono diversi parametri per l'IP Masquerading con i quali si può
giocare. Sono inglobati in ipchains perché non valeva la
pena scrivere uno strumento separato (anche se questa cosa cambierà).
Il comando per il masquerading IP è `-M', e può essere combinato con `-L' per mostrare l'elenco delle connessioni attualmente mascherate, o con `-S' per impostare i parametri del masquerading.
Il comando `-L' può essere accompagnato da `-n' (mostra i numeri invece dei nomi degli host e delle porte) o `-v' (mostra i delta nelle sequenze di numeri per le connessioni mascherate, nel caso importi qualcosa).
Il comando `-S' dovrebbe essere seguito da tre valori di timeout in secondi: per le sessioni TCP, per le sessioni TCP dopo un pacchetto FYN e per i pacchetti UDP. Se non si vuole cambiare uno di questi tre valori, semplicemente si specifichi `0' come valore.
I valori predefiniti sono elencati in `/usr/src/linux/include/net/ip_masq.h', e rispettivamente sono 15 minuti, 2 minuti e 5 minuti.
Il valore più comune da cambiare è il primo, per FTP (si veda Incubi da FTP più avanti).
Si noti il problema nell'impostazione dei timeout descritto in Non riesco a impostare i timeout del masquerading!.
Talvolta si vuole vedere cosa succede quando un certo pacchetto entra
nella propria macchina, ad esempio per fare il debug delle catene
firewall. ipchains ha il comando `-C' per permetterlo, che
usa le stesse routine che usa il kernel per la diagnosi dei pacchetti
reali.
Si specifica su quale catena verificare il pacchetto facendo seguire
l'argomento di `-C' con il suo nome. Mentre il kernel inizia la
trasversata sempre dalla catena input, output oppure
forward, per gli scopi di test si ha il permesso di
cominciare la traversata da qualsiasi catena.
I dettagli del `pacchetto' sono specificati usando le stessa sintassi usata per specificare le regole firewall. In particolare, sono obbligatori un protocollo (`-p'), un indirizzo di provenienza (`-s'), un indirizzo di destinazione (`-d') e un'interfaccia (`-i'). Se il protocollo è TCP o UDP, allora devono essere specificati un unico indirizzo di provenienza ed un unico indirizzo di destinazione, mentre devono essere specificati un tipo e un codice ICMP per il protocollo ICMP (a meno che non sia specificata l'opzione `-f' per indicare una regola sui frammenti, nel qual caso queste opzioni sono illegali).
Se il protocollo è TCP (e non è specificata l'opzione `-f' ), può essere specificata l'opzione `-y' per indicare che il pacchetto di test avrà il bit SYN impostato.
Ecco qui un esempio di verifica di un pacchetto SYN TCP dalla porta 60000 di 192.168.1.1 alla porta www di 192.168.1.2, in arrivo sull'interfaccia eth0 e che entra nella catena `input' (questa è la classica inizializzazione di una connessione WWW):
# ipchains -C input -p tcp -y -i eth0 -s 192.168.1.1 60000 -d 192.168.1.2 www
packet accepted
#
Talvolta un'unica riga di comando può aver effetto su più regole. Ciò
capita in due situazioni. La prima: se si può specificare un nome di
host che viene risolto (usando il DNS) in diversi indirizzi IP,
ipchains si comporterà come se si fossero digitati più
comandi, uno per ogni combinazione di indirizzi.
Quindi se il nome di host `www.foo.com' viene risolto in tre indirizzi
IP e il nome di host `www.bar.com' viene risolto in due indirizzi IP,
allora il comando `ipchains -A input -j reject -s www.bar.com -d
www.foo.com' aggiungerà sei regole alla catena input.
Un altro modo per far sì che ipchains effettui azioni
multiple è di usare l'opzione `-b' (bidirezionale). Questa opzione fa
sì che ipchains si comporti come se si fosse digitato due
volte il comando, la seconda volta scambiando gli argomenti di `-s' e
`-d'. Quindi per evitare l'inoltro sia da che per 192.168.1.1, si
potrebbe fare quanto segue:
# ipchains -b -A forward -j reject -s 192.168.1.1
#
Personalmente, non gradisco molto l'opzione `-b'; se si vuole qualcosa di più utile si veda Usare ipchains-save più avanti.
L'opzione `-b' può essere usato con i comandi di inserimento (`-I'), cancellazione (`-D') (ma non le varianti che accettano un numero di regola), aggiunta (`-A') e verifica (`-C').
Un'altra opzione utile è `-v' (verboso) che mostra esattamente quel
che ipchains sta facendo con il comando dato. È utile se si
ha a che fare con comandi che possono evere effetto su più regole.
Per esempio, controlliamo il comportamento dei frammenti tra
192.168.1.1 e 192.168.1.2.
# ipchains -v -b -C input -p tcp -f -s 192.168.1.1 -d 192.168.1.2 -i lo
tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.1 -> 192.168.1.2 * -> *
packet accepted
tcp opt ---f- tos 0xFF 0x00 via lo 192.168.1.2 -> 192.168.1.1 * -> *
packet accepted
#
Ho una connessione PPP in dialup (-i ppp0). Mi scarico le
news (-p TCP -s news.virtual.net.au nntp) e la posta (-p
TCP -s mail.virtual.net.au pop-3) ogni volta che mi connetto.
Uso il metodo FTP di Debian per aggiornare regolarmente la mia
macchina (-p TCP -y -s ftp.debian.org.au ftp-data). Navigo
in rete attraverso il proxy del mio ISP mentre tutta la roba
precedente è in funzione (-p TCP -d proxy.virtual.net.au
8080), ma odio le pubblicità da doubleclick.net nel Dilbert
Archive (-p TCP -y -d 199.95.207.0/24 e -p TCP -y -d
199.95.208.0/24).
Non mi preoccupo della gente che prova a fare ftp nella mia macchina
mentre sono online (-p TCP -d $LOCALIP ftp), ma non voglio
che nessuno da fuori pretenda di avere un indirizzo IP della mia rete
interna (-s 192.168.1.0/24). Ciò è comunemente detto IP
spoofing, e c'è un modo migliore per proteggersi nei kernel 2.1 e
superiori: si veda
Come proteggersi dall'IP spoofing?.
Questa configurazione è piuttosto semplice, perché attualmente non ci sono altre macchine nella mia rete interna.
Non voglio che nessun processo locale (ie. Netscape, lynx ecc.) si connetta a doubleclick.net:
# ipchains -A output -d 199.95.207.0/24 -j REJECT
# ipchains -A output -d 199.95.208.0/24 -j REJECT
#
Ora voglio impostare le priorità in diversi pacchetti in uscita (non
ne vedo l'utilità di farlo nei pacchetti in ingresso). Poiché ho
parecchie di questo regole, ha senso metterle tutte in un unica
catena, chiamata ppp-out.
# ipchains -N ppp-out
# ipchains -A output -i ppp0 -j ppp-out
#
Ritardo minimo per il traffico web e per telnet.
# ipchains -A ppp-out -p TCP -d proxy.virtual.net.au 8080 -t 0x01 0x10
# ipchains -A ppp-out -p TCP -d 0.0.0.0 telnet -t 0x01 0x10
#
Minimo costo per i dati ftp, nntp e pop-3:
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 ftp-data -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 nntp -t 0x01 0x02
# ipchains -A ppp-out -p TCP -d 0.0.0.0/0 pop-3 -t 0x01 0x02
#
Ci sono alcune restrizioni sui pacchetti in ingresso dall'interfaccia ppp0: creo una catena chiamata `ppp-in':
# ipchains -N ppp-in
# ipchains -A input -i ppp0 -j ppp-in
#
Ora, nessun pacchetto in ingresso da ppp0 dovrebbe affermare
un indirizzo di provenienza di 192.168.1.*, e quindi li registro e li
proibisco:
# ipchains -A ppp-in -s 192.168.1.0/24 -l -j DENY
#
Permetto l'ingresso solo di pacchetti UDP per il DNS (eseguo un caching nameserver che inoltra tutte le richieste a 203.29.16.1, quindi mi aspetto risposte DNS solo da loro), ftp entrante e ritorno di dati ftp (che dovrebbero andare solo verso una porta sotto la 1023, non verso le porte X11 attorno a 6000).
# ipchains -A ppp-in -p UDP -s 203.29.16.1 -d $LOCALIP dns -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 1024:5999 -j ACCEPT
# ipchains -A ppp-in -p TCP -s 0.0.0.0/0 ftp-data -d $LOCALIP 6010: -j ACCEPT
# ipchains -A ppp-in -p TCP -d $LOCALIP ftp -j ACCEPT
#
Per finire, vanno bene i pacchetti local-to-local:
# ipchains -A input -i lo -j ACCEPT
#
ora, la mia tattica di default per la catena input è
DENY, quindi qualsiasi altra cosa viene scartata:
# ipchains -P input DENY
#
NOTA: non imposterei le mie catene in questo ordine, in quanto i pacchetti potrebbero passare mentre le imposto. La cosa più sicura è di impostare per prima cosa la tattica a DENY, poi inserire le regole. Naturalmente, se le proprie regole necessitano di ricerche DNS per risolvere i nomi di host, potrebbero esserci problemi.
Impostare le catene firewall proprio nel modo in cui le si vuole, e poi provare a ricordarsi i comandi usati in modo da porterlo fare anche la volta successiva è una cosa penosa.
ipchains-save è uno script che legge l'impostazione corrente
delle catene e la salva in un file. Per ora vi lascio in fremente
attesa di scoprire cosa fa ipchains-restore.
ipchains-save può salvare una catena o tutte le catene (se
non è specificato un nome di catena). La sola opzione attualmente
permessa è `-v' che stampa le regole (in stderr) mentre le salva. Per
le catene input, output e forward è salvata
anche la tattica.
# ipchains-save > my_firewall
Saving `input'.
Saving `output'.
Saving `forward'.
Saving `ppp-in'.
Saving `ppp-out'.
#
ipchains-restore ripristina le catene salvate con
ipchains-save. Accetta due opzioni: `-v' che descrive ogni
regola che viene aggiunta, e `-f' che forza lo svuotamento delle catene
definite dall'utente se esistono, come descritto nel seguito.
Se nell'input è trovata una catena definita dall'utente,
ipchains-restore controlla se esiste già. Se esiste,
sarà chiesto se la catena debba essere svuotata (ripulita da tutte le
regole) o se si debba saltare il ripristino di questa catena. Se si
specifica `-f' in riga di comando, non sarà chiesto niente; la catena
sarà ripulita.
Per esempio:
# ipchains-restore < my_firewall
Restoring `input'.
Restoring `output'.
Restoring `forward'.
Restoring `ppp-in'.
Chain `ppp-in' already exists. Skip or flush? [S/f]? s
Skipping `ppp-in'.
Restoring `ppp-out'.
Chain `ppp-out' already exists. Skip or flush? [S/f]? f
Flushing `ppp-out'.
#