Iptables per tutti

Iptables per tutti
Analizziamo come utilizzare al massimo il firewall del kernel 2.4 e come munirci dell'indispensabile
per affrontare l'etere telematico in piena sicurezza. Una guida pratica alla portata di tutti per capire
ogni segreto di iptables esplorandone ogni singola caratteristica.
Oramai il kernel 2.4 ha dato dimostrazioni della sua stabilità e si è tuttora imposto nella maggior parte delle
distribuzioni mettendo alla luce tutte le sue caratteristiche e novità rispetto al suo predecessore. Fra le tante
spicca il suo tool di filtraggio pacchetti: Iptables. Anche se il supporto di ipchains (il firewall del kernel 2.2.x) è
stato garantito, iptables si sta prepotentemente guadagnando le attenzioni dell'utenza proprio per alcune
features di indiscutibile qualità: a questo proposito ho deciso di scrivere questa guida, adatta ad ogni tipo di
utenza, per scoprire completamente tutte le potenzialità di questo firewall, e facilitarne il travaglio a chi è
ancora fedele a ipchains e ha difficoltà a apprenderne le differenze.
Quando abbiamo bisogno
di un firewallIl firewall, nei veicoli motorizzati, serve ad isolare le persone nel cabinato dalle fiamme del
motore nell'eventualità che il motore prenda fuoco. Analogamente al compito prettamente fisico del firewall
dei veicoli a motore, la firewall che conosciamo nel campo informatico agisce metaforicamente nella stessa
maniera, isolando un computer in rete da eventuali attacchi esterni. Tempo fa soltanto gli amministratori di
sistema ricorrevano al filtraggio dei pacchetti per prevenire sinistri informatici nelle proprie reti, ma ora, con
l'avvento sopratutto dell'IRC (Internet Relay Chat) e di nuovi servizi telematici, che permettono ad una
miriade di utenti di venire a conoscenza di un ip privato, il fattore sicurezza è sicuramente stato messo a
rischio. Quanti di noi nella propria "vita telematica" si sono imbattuti in fastidiosi nonchè squallidi nukes,
floods e DoS (Denial of Services) di vario genere; e quanti altri hanno avuto difficoltà nel rendere
irragiungibili da internet alcuni servizi di sistema ( ftp, smb, X...). A tutti questi problemi pone fine il firewall, e
nel nostro caso iptables.
Installiamo iptables
Prima di fiondarci sulla costruzione e sulla sintassi di una "catena" di filtraggio pacchetti è bene verificare le
caratteristiche del nostro kernel per appurarne le opzioni necessarie (integrate nel kernel o compilate come
moduli). Come avrete notato, una delle differenze sostanziali che c'è tra il firewall di linux e quella di altri OS
è che quest'ultimo non agisce come un processo di un programma a se stante, bensì è integrato nel kernel
stesso garantendo maggiore stabilità e flessibilità.
Prima di poter proseguire è necessario verificare di avere i sorgenti del
kernel 2.4 (potete utilizzare quelli della vostra distribuzione oppure
scaricarne dei nuovi da http://www.kernel .org), e dirigendoci nella
directory /usr/src/'linuxdir' digitiamo il seguente comando per accedere al
menu delle opzioni:
$ make menuconfig
Dopo aver verificato le opzioni seguenti ricompilate il kernel e i moduli
con la solita prassi (make dep && make clean && make bzImage && make modules && make
modules_install) e nel caso in cui non tutto dovesse andare per il meglio eseguite un make mrproper per
cancellare ogni configurazione precedente e ripetete nuovamente l'operazione.
Ecco come compilare il kernel per non rinunciare a nessuna delle funzionalità di Iptables, vi ricordo che in
base alle vostre esigenze potrete aggiungere altri moduli per espandere le funzionalità del firewall o magari
per sfruttare netfilter su ipv6.
networking options
[*] Network Packet filtering ( replaces ipchains)
[*] Network Packet filtering debugging (opzionale)
IP Netfilter configuration ----> in questa sezione
compilate tutte le voci come moduli (abiliterete
anche il masquerade, supporto ipchains e ipfwadm)
[M] Iptables support
[M] packet filtering
[M] etc.etc.
Se abbiamo caricato iptables con modprobe o lo abbiamo inserito in
/etc/modules.conf, possiamo verificarlo con un semplice comando
eseguito anche come utente semplice (permessi permettendo):
$ /sbin/lsmod
Nel caso voi stiate utilizzando distribuzioni user-friendly come Red Hat o
Mandrake potete saltare questa parte installando il pacchetto rpm di
iptables presente nei cd di installazione o reperibili da internet (qualora
non l'aveste installato di default). Ma secondo me ci perdete tutto il
gusto....
Primo approccio
A differenza di come ci lasciano intendere alcuni How-to reperibili su internet, iptables non filtra "tutti" i
pacchetti tramite le sue tabelle di regole, bensì soltanto il primo o l'ultimo, accettandolo, rifiutandolo,
ignorandolo o applicando predeterminati criteri. Se 2 host non si sincronizzano, i pacchetti vanno in time-out
senza raggiungere la destinazione, Iptables scartando il primo pacchetto (i syn-packets, i pacchetti di
sincronizzazione) fa sì di non dover applicare le stesse regole a tutti i pacchetti, come invece avviene con
conntrack (connection tracking, traccia i pacchetti).
Prima di tentare un approccio pratico è bene decidere di attivare nei
servizi di boot del nostro runlevel (probabilmente il 5) iptables. Nulla di più
facile per chi usa Mandrake o RedHat, basta eseguire come root il
seguente:
$chkconfig --level 5 iptables on
Dove "--level 5" indica su quale runlevel va attivato il supporto iptables. Chi usa Debian (mi auguro che
cresciate di numero con l'imminente Woody release) non dovrà fare altro che andare il /etc/default/ e
modificare il file iptables oppure vedersela con debconf.
Una volta garantito di avere il firewall attivo ad ogni boot possiamo prendere confidenza con il primo
comando:
$ /sbin/iptables -L -n
Come illustrato in Figura 3, l'output di questo comando ci mostra le regole
attive; nel caso in cui durante l'installazione della vostra distribuzione
abbiate selezionato un livello sicurezza (di solito appaiono come "medio,
alto, basso" nelle odierne distro), probabilmente il firewall è stato già
installato nel vostro sistema e configurata con delle regole predefinite.
In questo caso l'output sarà diverso, in quanto vi mostrerà le regole attive,
proprio come se l'aveste inserite voi, vedere in Figura 4 per avere un
esempio.
Catene per fare che ?
Quando ci riferiamo ad una tabella di regole di iptables intendiamo una ‘catena’, un insieme di regole
concatenate fra loro che vanno ad agire sulle intestazioni IP dei pacchetti per verificarne la corrispondenza.
Con il comando "iptables -L -n" siamo venuti a conoscenza delle tre catene di iptables :
INPUT
FORWARD
OUTPUT
In un precedente articolo riguardante il Nat (Ip Masquerade e NAT, maggio 2002), abbiamo visto con il
comando "iptables -t nat -L -n" le catene del NAT o MASQUERADING:
POSTROUTING
PREROUTING
Ma come orientarci nel loro corretto uso?INPUT e OUTPUT sono due catene che agiscono
specificatamente sui pacchetti i quali, destinazione o sorgente, riguardano soltanto il nostro host locale. La
prima comprende quelli in entrata (da un host verso il nostro pc), l'altra quelli in uscita (dal nostro host verso
un altro pc). FORWARD è specificatamente riservata ai pacchetti che passano (in gergo “forwardati”) da
un'interfaccia all'altra (chi è rimasto fedele a ipchains vada a vedere il paragrafo delle "differenze" per un
concetto più ampio).
Pensate invece che le catene POSTROUTING e PREROUTING
agiscano concettualmente agli estremi della firewall una alla fine e l'altra
all'inizio come descritto in Figura 5. Le catene contengono le regole (ogni
regola è un anello della catena), dove per ordine di "altezza" ogni regola
è assegnata ad un numero, come se iptables assegnasse un ordine
gerarchico alle regole, la prima regola ad essere letta è appunto la prima (quella che sta più in alto), e finchè
il pacchetto non è influenzato da nessun'altra regola iptables continua a scendere di "anello in anello"
leggendo tutte le regole fino alla fine della catena (in questo caso il pacchetto passa attraverso la firewall
tranquillamente fino a raggiungere i processi interni dell'OS).
Premesso ciò mi è obbligatorio sottolineare che la prima regola è capace
di annullare tutte le altre, ne vediamo un pratico esempio in Figura 6,
anche se ancora non siamo arrivati all'analisi della sintassi di iptables è
bene che lo teniate a mente.
Le Tabelle dei filtri
Pensavate fosse finita lì?! eh eh eh... Si usa specificare le tabelle (altrimenti si ricorre sempre a quella di
default) con la seguente sintassi:
$/sbin/iptables -t <nometabella> -L
Con la precedente abbiamo specificato di vedere le regole attive di una determinata tabella, ma cosa sono le
tabelle?
Quando ricorriamo ad una tabella è per specificare un target di pacchetti non "incatenabili" da quella di
default. La tabella di default è filter ed è caricata dal modulo iptables_filter (che deve essere a sua volta
presente nel listato di lsmod insieme a ip_tables per formare il "minimo indispensabile") e non è
obbligatoriamente da specificare nella sintassi di iptables. Proprio come gli esempi precedenti il comando
$/sbin/iptables -L -n
non fa altro che visualizzare l'output della tabella filter. Le altre tabelle che troviamo in iptables sono nat e
mangle (caricate entrambi dai rispettivi moduli), la prima è stata già trattata in un articolo precedente e
riguarda le regole di DNAT, SNAT e MASQUERADE, l'altra è utilizzata quando un amministratore di sistema
deve inserire una marcatura su un pacchetto (in pratica è come se facesse una "rifinitura" di una determinata
regola) oppure specificare il TOS (Type Of Service). Per avere specifiche sul TOS vi consiglio di consultare il
paragrafo di riferimento. Prima di abbandonarci ai veri e propri comandi di iptables, è bene che voi sappiate
che ulteriori tabelle possono essere create per soddisfare varie strategie di firewall... ma ora i comandi !
I comandi di Iptables
Per impartire comandi a iptables dobbiamo rispettare una sintassi semplice ed intuitiva, in Figura 7 ne
troviamo un pratico esempio illustrato.
A voi, tutti i comandi di iptables:
•
•
•
•
•
•
•
•
•
•
•
-A = append, appende una regola, seguono a questo comando il
nome della catena, eventuali opzioni ed il target.
• -D = delete, segue a delete il nome della catena e il numero di
una regola (es . iptables -D OUTPUT 4 : la quarta regola a
contare dall'alto della catena OUTPUT). Questo comando
cancella la regola selezionata.
• -C : check, segue il nome della catena e il numero della regola.
Effettua un test.
-I = insert, inserisce una regola nella catena (in pratica la "infila" tra 2 regole, se l'avesse "appesa"
sarebbe apparsa come l'ultima regola della catena, e sarebbe stata influenzata dalle precedenti) è
obbligatorio il nome della catena e il numero con cui vogliamo inserire la regola (se 1 diventa la
prima, se 2 la seconda..etc)
-R = replace, in pratica fonde i comandi Insert e Delete. Sostituisce una regola con un'altra.
-F = flush, se usato senza specificazione cancella tutte le regole di tutte le catene, altrimenti
specificare il nome della catena.
-L = list, abbiamo già analizzato questo comando precedentemente.
-Z = zero, azzera i contatori della catena (se specificata) o di tutte le catene.
-N = new, crea una nuova catena. Segue a questo comando il nome della catena.
-X = cancella una catena che avete creato con -N, va specificato il suo nome.
-P = policy, è la politica del firewall (vedere paragrafi successivi) ed è seguita dal nome della catena
e dal target.
-E = rename, rinomina una catena, da inserire obbligatoriamente il vecchio nome della catena ed il
nuovo.
-h = help, è l'help!
Le opzioni di Iptables
Le opzioni seguono il nome della catena ed alcuni di essi hanno bisogno di moduli specifici; se avete seguito
le indicazioni di questo articolo non riscontrerete nessuna difficoltà nell'applicazione di essi in una regola.
•
•
•
•
•
•
•
•
•
L'opzione "!" non è obbligatoria ma può essere applicata alle opzioni per invertirne il significato.
-p = protocol, segue il nome del protocollo, icmp, udp, tcp o all (per avere specifiche su "all"
consultare /etc/protocols)
-s = source, specifica l'indirizzo sorgente, in pratica l'host/ip da cui arrivano i pacchetti. Può essere
specificata anche una netmask o una porta applicando come seguente: -s 194.168.0.5/24 o -s
194.168.0.5/255.255.255.0 per la netmask, per la porta invece -s 194.168.0.5:21.
-d = destination, è l'ip dove sono diretti i pacchetti. Di solito è il nostro ip, e sono possibili le stesse
specificazioni di -s.
-i = interface, serve a specificare l'interfaccia d'input. Al nome dell'interfaccia, eth0, ppp1 etc.etc.
possiamo applicare la variabile + per specificare un'interfaccia attiva. Es -i ppp+, se l'interfaccia ppp0
è attiva ppp+ assumerà il valore di ppp0.
-o = output/interfaces, è l'interfaccia di uscita usata nelle catene OUTPUT e POSTROUTING,
catene che con l'opzione precedente non hanno applicazioni (se i pacchetti escono che c'entra
l'interfaccia d' entrata?).
-j = è la fine che facciamo fare ai pacchetti. ACCEPT, DROP, RETURN etc.etc.
-n = fornisce un output numerico di porte ed indirizzi ( es. iptables -L -n).
-v = verbose, o " -vv" per avere un listato delle regole attive più dettagliato. Per capirlo a fondo
provate con:
$/sbin/itpables -L -vv
•
•
•
-x = exac, se i contatori dei pacchetti o dei byte sono utilizzati visualizzano un output numerico al
posto di K, M o G (kilobyte, megabyte, gigabyte).
-f = fragment, la regola si riferisce al secondo frammento o ai successivi. E' applicata sui pacchetti
frammentati e può essere preceduto da "!" per controllare solo gli "head fragments" o "unfragment
packets". Frammentati? Durante una connessione in rete spesso capita che un pacchetto venga
frammentato per la sua eccessiva grandezza. Immaginiamo un pacchetto che per le sue dimensioni
viene suddiviso in 2 parti, la prima (head fragment) con l'intestazione, che va a soddisfare o meno le
regole del firewall, la seconda senza. Iptables potrebbe confondersi e scartare uno o più frammenti
di un pacchetto.
--tcp-flags = applicabile solo se specificato il protocollo tcp. Questa opzione verifica i flags dei
pacchetti per trovarne la corrispondenza.
Se vogliamo analizzare i flags SYN, FIN, RST e ACK ma accettare solo i SYN e ACK (pacchetti di risposta di
avvenuta connessione) utilizziamo la seguente sintassi. Come noterete i flags accettati sono divisi dal resto
non con una virgola ma con uno spazio:
-p tcp --tcp-flags SYN,FIN,RST,ACK SYN,ACK
•
•
•
•
--syn = valida solo se applicata al protocollo tcp. Questa regola specifica soltanto i pacchetti di
risposta ad un'avvenuta connessione (è esattamente l'abbreviazione dell'esempio precedente sui
flags).
--icmp-type = valida solo se applicata al protocollo icmp (-p icmp), questa regola specifica a quale
categoria di icmp packets la regola deve trovare applicazione. Per visualizzare tutti i tipi di pacchetti
icmp digitare:
$/sbin/iptables -p icmp -h
--mac-source = valida dopo l'opzione -m mac come il seguente esempio
-m mac --mac-source 00:00:ab:c0:45:a7
questa opzione serve a specificare l'applicazione della regola su un'indirizzo sorgente MAC.
--limit = imposta un limite, una frequenza massima di una regola. La frequenza può essere
specificata in un periodo con /hour, /minute, /second, /day. Ad esempio, se vogliamo che il nostro
server non accetti più di una connessione alla volta per secondo basta usare -m limit con l'opzione p tcp --syn. Il seguente esempio vi mostra la corretta sintassi:
-m limit --limit 1/sec
•
•
•
•
•
•
•
•
•
•
•
•
•
--limit-burst = è complementare a --limit ed è seguito da un numero, quello di default è 5. Ogni volta
che un pacchetto soddisfa l'opzione --limit, --limit-burst fa da massimo burst (raffica) prima che il
limite succitato li respinga. Anche se a prima vista possa sembrare inutile, limit e limit-burst si
possono rivelare come delle ottime soluzioni a vari tipi di flood, come ad esempio i syn-floods:
$iptables -A FORWARD -p tcp --syn -m limit 1/sec -j ACCEPT
--port = questa opzione è valida solo con -m multiport e -p tcp, -p udp, e viene applicata quando sia
la porta sorgente che quella di destinazione sono uguali.
--mark = riguarda i pacchetti con un valore mark. Questo valore va impostato con il target MARK
che verrà trattato successivamente.
--uid-owner = valido solo per la catena OUTPUT ed è seguito da l'id di un utente. Funziona solo per
i pacchetti creati sul pc locale.
--gid-owner = uguale al precedente, unica differenza che comprende i gruppi e non gli utenti.
--pid-owner = a differenza dei precedenti in questa opzione va applicato l'ID di un processo (PID).
--sid-owner = segue questa opzione l'ID di una sessione.
--state = questa opzione identifica lo stato di una connessione TCP con i seguenti valori:
NEW: connessione appena stabilita o in stallo.
ESTABILISHED: connessione stabilita.
RELATED: nuova connessione "relativa" ad una connessione stabilita (come ad esempio dei
messaggi d'errore icmp inerenti ad una connessione ).
INVALID: riguardano i pacchetti di scansione.
-m state "VALORE"
unclean = quest'opzione è adatta per specificare i pacchetti inusuali o creati male, dato che è
ancora in fase sperimentale ne sconsiglio l'uso. La sintassi è -m unclean.
Chi pensa che le opzioni di iptables siano finite si sta illudendo pietosamente, infatti passiamo ora ad
analizzare meglio il già citato "type of service" (tipo di servizio).
•
•
--tos = è un'opzione usata per soddisfare una TOS MASK (vedere tabella di riferimento). Qui
rappresentato uno stralcio di regola:
-m tos--tos 16
TOS specifica i pacchetti relativi a determinati tipi di servizi, e può essere impostato
indipendentemente a netfilter dal target....
…e iniziamo con i targets...
•
TOS = permette l'impostazione del valore del "type of service" ed è valido sono nelle catene di
OUTPUT e PREROUTING. Segue il seguente argomento obbligatorio che "può" contenere uno dei
valori numerici della tabella dedicata, per visualizzare con iptables una lista di "valid TOS names"
digitare da prompt:
$iptables -j TOS -h
la sintassi per impostare il valore è la seguente:
--set-tos "numeroTOS"
Policy e Targets
I Targets, o in parole spicciole, dove vogliamo destinare i pacchetti che soddisfano le caratteristiche di una
regola, sono specificati nelle regole e sono valori che determinano o meno l'entrata, il forwarding, l'uscita, il
logging, il mascheramento etc.etc. di uno o più pacchetti. A differenza dei Targets la Policy è sì, applicata ad
una regola, ma agisce nei confronti di un'intera catena. Per Policy si intende la politica adottata in una
catena, ogni catena ne ha una di default che ha come valore ACCEPT.
Il seguente esempio ci svela la sua applicazione nella catena di FORWARD:
$iptables -P FORWARD -j DROP
Questa regola cambia la FORWARD's policy di default in DROP, se non appendiamo nessuna regola che
permetta una "via di fuga" per i pacchetti, nessun pacchetto verrà forwardato dal nostro pc.
Eccovi esposta un piccolo firewall con policy "paranoica" e con l'aggiunta delle sopraccitate "vie di fuga" per
permettere al pc alcune transizioni indispensabili:
$iptables -A INPUT -s 127.0.0.1/255.0.0.0 -j ACCEPT
$iptables -A INPUT -s 194.168.0.0/255.255.255.0 -j ACCEPT
$iptables -A INPUT -p tcp --dport 22 -j ACCEPT
$iptables -A INPUT -p icmp --icmp-type echo-reply -j ACCEPT
$iptables -P INPUT -J DROP
La precedente è un firewall con policy DROP in INPUT, non accetta nessun genere di pacchetto dall'esterno
se non quelli espressamente specificati nelle regole della catena.
•
•
•
•
La regola n° 1 specifica che tutti i pacchetti provenienti dal nostro pc locale devono essere accettati
(altrimenti iptables rifiuta anche quelli!).
La regola n° 2 specifica che tutti i pacchetti provenienti dalla nostra piccola rete LAN devono essere
accettati.
La regola n° 3 lascia passare dall'esterno soltanto i pacchetti destinati sulla porta 22 di protocollo
tcp (di solito quella porta è abbinanta a ssh).
La regola n° 4, quella che precede la Policy, accetta dall'esterno soltanto le risposte dei ping (detti
pong). Ed infine abbiamo inserito la Policy (se l'avessimo inserita prima delle regole avremmo avuto
difficoltà nell'interagire con il nostro pc... eheheh, è assurdo ma vero, iptables se vuole essere
paranoico ci riesce veramente bene!), per rendere raggiungibile dall'esterno soltanto la porta 22
(almeno in INPUT ).
Abbiamo parlato di Targets e Policy, vediamo le loro caratteristiche fondamentali:
•
•
•
•
•
•
ACCEPT = accetta i pacchetti specificati nella regola.
DROP = rifiuta i pacchetti specificati nella regola.
REJECT = come DROP, unica differenza che restituisce all'host sorgente un messaggio d'errore
che possiamo decidere con la seguente opzione:
--reject-with-type = quest'opzione vi permette di cambiare il messaggio predefinito "icmp-netunreachable" in icmp-host-unreachable, icmp-port-unreachable o in icmp-proto-unreachable.
RETURN = ha lo stesso effetto di quando si arriva alla fine di una catena: se l'ultima regola
appartiene a una catena predefinita, allora viene eseguita la tattica della catena. Altrimenti se
appartiene ad una catena definita dall'utente, si prosegue con la catena precedente, con la regola
successiva a quella che aveva causato il salto nella catena dell'utente.
QUEUE = è un gestore delle code, il suo compito è quello di accodare i pacchetti per elaborazioni
"userspace". Per funzionare ha bisogno del modulo "ip_queue".
Tutti i seguenti target hanno bisogno di un loro specifico modulo:
•
•
•
•
•
LOG = effettua il logging dei pacchetti che soddisfano la regola. E' consigliabile associare a questo
target la precedente opzione -limit. I seguenti argomenti sono facoltativi:
--log-level = permette di specificare il livello di logging.
--log-prefix = permette di aggiungere un massimo di 14 caratteri all'inizio del log per identificarne il
tipo.
--log-tcp-sequence = logga i numeri di sequenza tcp.
--log-tcp-options = logga il campo options dell'instestazione del pacchetto tcp.
•
•
•
•
•
•
•
•
•
--log-ip-options = uguale al precedente soltanto che è valido per i pacchetti ip.
MARK = è valido solo nella tabella mangle ed associa al pacchetto un valore mark.
--set-mark "valorenumerico"
MIRROR = inverte gli indirizzi sorgente/destinazione dei pacchetti. E' valido nelle catene INPUT,
OUTPUT e FORWARD ed è ancora in fase sperimentale.
SNAT = Source NAT, richiede la tabella nat ed è valido nella catena di POSTROUTING. E' stato
trattato in un articolo (maggio 2002) precedente insieme ai seguenti targets.
DNAT = Destination NAT, valido in PREROUTING.
MASQUERADE = valido nella tabella POSTROUTNG.
REDIRECT = valido solo in PREROUTING, OUTPUT o in una catena definita dall'utente, questo
target effettua un redirect sui pacchetti all' host locale.
--to-ports = valido con protocolli tcp e udp questa opzione seguente REDIRECT ci permette di
modificare le regole euristiche di selezione della porta predefinita.
Strategie
Finora ci siamo occupati dell'analisi dei comandi, opzioni e targets di iptables, ora bisogna decidere come
mettere insieme più regole nelle catene per ottenere un firewall sicuro. Tutto dipende dalla strategia che
intendete adottare per il vostro firewall. Potete scegliere di piazzare un bel DROP come Policy sia in INPUT
che in OUTPUT che in FORWARD e poi decidere minuziosamente quale pachetto deve entrare o uscire,
oppure potete lasciare le vostre catene in ACCEPT e appendere soltanto le regole che ritenete necessarie
per la vostra sicurezza.
Il primo passo da fare è conoscere i propri servizi e le proprie esigenze,
chi meglio di netstat è capace di visualizzarle?!
$netstat -tau
con il listato di netstat potete capire che servizi attivi avete, attraverso
quali protocolli stanno comunicando, lo stato in cui sono (leggere
l'opzione -m state) gli indirizzi locali e gli indirizzi remoti, con queste
informazioni bisogna plasmare il proprio firewall.
Una firewall semplice
Costruiamo un firewall minimalista per soddisfare le nostre esigenze casalinghe:
$iptables -F INPUT
$iptables -F OUTPUT
$iptables -F FORWARD
dopo aver ripulito le nostre catene andiamo ad appendere le regole. Ammettiamo di avere un X server,
samba e ssh come servizi attivi:
$iptables -A INPUT -s 127.0.0.1 -j ACCEPT
$iptables -A INPUT -s 194.168.0.0/24 -j ACCEPT
$iptables -A INPUT -p tcp --dport 6000 -j DROP
$iptables -A INPUT -p all --dport 137:139 -j DROP
$iptables -A INPUT -p icmp --icmp-type echo-request
-j DROP
$iptables -A INPUT -p icmp ! --icmp-type echo-reply
-j DROP
$iptables -A INPUT -p udp --dport 33435:33525 -j DROP
$iptables -A FORWARD -p tcp --syn -m limit –limit 3/s
-j ACCEPT
$iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST
RST -m limit –limit 1/s -j ACCEPT
In INPUT le prime due regole le abbiamo già analizzate in precedenza, la tre e la quattro specificano di non
far passare nessun pacchetto diretto al nostro X server o a samba, la cinque rifiuta gli echo-request mentre
la sei risponde solo ai echo-reply inviati dal nostro host. In FORWARD la prima regola ci protegge dai SynFloods, la seconda da scans remoti sospetti. Come avete notato soltanto la nostra rete LAN raggiunge tutti i
servizi del nostro pc, su internet soltanto ssh è stato reso raggiungibile con delle semplici precauzioni, e il
nostro pc non ha nessun problema nel compiere azioni quotidiane su internet, come chattare o prelevare le
e-mails.
Iptables vs Ipchains
http://www.netfilter.org/documentation/HOWTO/it/packet-filtering-HOWTO-10.html . In questa pagina
web leggerete delle differenze (anche a livello sintattico) descritte dagli sviluppatori stessi di netfilter. A ciò
che è stato scritto dagli stessi sviluppatori vorrei aggiungere qualche piccola caratteristica:
•
•
A differenza di Iptables, Ipchains filtrava i pacchetti della catena FORWARD prima attraverso INPUT
e poi attraverso OUTPUT.
le ispezioni stateful di iptables sono state implementate nel kernel come moduli.
Un firewall con ispezioni stateful è in grado di monitorare i protocolli per verificare che la comunicazione
esegue correttamente le regole di tale connessione ed è capace di verificare l'autenticità dell'ip e della porta
sorgente e di destinazione.
Salvare le regole
Una volta settato il firewall è bene salvare le regole correnti (o attive) in modo tale da non dover riscrivere il
tutto al prossimo boot della macchina. Gli utenti di Red hat o Mandrake possono ricorrere al seguente
metodo:
$/sbin/iptables-save –c > /etc/syconfig/iptables
Chi utilizza distribuzioni differenti dovrebbe dare un’occhiata agli script di init.d inerenti iptables. Per Debian
basta indicare a /etc/init.d/*iptables di salvare le regole attive:
/etc/init.d/*iptables save active
Per ogni necessità consultare in /usr/share/doc/*iptables* per avere specifiche sulle metodologie di
salvataggio delle regole.
Security Issue
Anche netfilter ha avuto le sue pecche per quanto concerne l’ambito della sicurezza, ricordiamo il piccolo
bug inerente al Masquerade della rete. Un utente poteva rilevare i computer nattati (mascherati dietro il
firewall) inviando pacchetti TCP con delle specifiche TTL. Il bug è stato risolto, chi desidera risolvere
quest’inconveniente dovrebbe patchare il proprio netfilter (trovate l’indispensabile in www.netfilter.org)
oppure ricorrere ai ripari con la seguente regola in OUTPUT:
iptables -A OUTPUT -m state -p icmp --state INVALID -j DROP
Questa regola evita il rilascio di informazioni “pericolse” tramite il firewall. Anche se è stato un articolo adatto
ad ogni tipo di utenza, spero che ogni esigenza sia stata soddisfatta, e vi ricordo che per qualsiasi
approfondimento il sito di netfilter (www.netfilter.org) mette a disposizione How-to e FAQ in lingua italiana e
vari link ad altri siti dedicati ad iptables. Per chi ha avuto difficoltà con alcuni termini chiave quali, protocollo,
flags, MAC ed altre terminologie presenti in questo articolo consiglio vivamente una "letturina" agli Appunti di
informatica Libera (http://a2.swlibero.org/), che tenuti costantemente aggiornati dall'autore, stanno
diventando una vera e propria bibbia italiana dell'informatica. Per il resto vi ricordo le man ("man iptables"), e
la morale del giorno : "chi fa da se fa per tre".