Capiamo ed usiamo Iptables – Parte 2°

Eccoci stasera con la seconda parte della nostra guida su IpTables. Oggi vediamo i parametri più comuni che si utilizzano per definire le regole e come/quali obiettivi si possono passare alle stesse.

Quando si parla di firewall, molto spesso le regole vengono chiamate ACL, che è un acronimo che sta per Access Control List, difatti le regole di un firewall non sono altro che una lista di controlli che il firewall deve fare, ed in base alle quali garantisce o nega l’accesso ad un determinato servizio/protocollo/indirizzo/ecc…

Alcuni parametri delle regole

Su iptables i parametri più comuni nella definizione delle regole sono questi:

-p/–protocol [protocollo]
specifichiamo con quale protocollo
i pacchetti intercettati fanno matchare la regola.
Se anteponiamo un ! prima del nome del protocollo
indichiamo tutti i pacchetti che non usano quel protocollo.
I protocolli specificabili sono ip, icmp, udp e tcp.

-s/–source [sorgente]
con questo parametro specifichiamo l’indirizzo, o la classe
di indirizzi, che se contenuti nel campo sorgente del pacchetto
fanno matchare la regola. Anche qui con un ! prima dell’indirizzo
specifichiamo tutti i pacchetti che non provengono dalla sorgente.
E’ possibile inoltre specificare un nome dns al posto degli ip.

-d/–destination [destinazione]
Uguale a -s ma questa volta per il campo destinazione.

-i/–in-interface [interfaccia]
viene utilizzato per specificare l’interfaccia di entrata
dei pacchetti, una macchina firewall generalmente
ha più interfaccie di rete, quindi questo parametro
è necessario per le catene di forward di input e di prerouting
per indicare l’interfaccia di entrata dei pacchetti.
Anche qui possiamo utilizzare il carattere jolly !,
inoltre possiamo utilizzare un altro carattere, il +;
se ad esempio nel nome dell’interfaccia mettiamo eth+
la regola riguarderà tutte le interfaccie che avranno
il nome che inizia per eth.

-o/–out-interface [interfaccia]
Stessa cosa di -i solo che questa volta coinvolgiamo
l’interfaccia d’uscita e le catene di output, forward
e postrouting.

Obiettivi delle regole

Come abbiamo detto, le regole hanno degli obiettivi, vale a dire istruiamo la regola in modo da dirgli come comportarsi se questa viene innescata da un pacchetto. Il parametro per definire un obiettivo è  -j/–jump; gli obiettivi possibili da assegnare ad una regola possono essere:

1. Uno degli obiettivi standard (ACCEPT, DROP, QUEUE…ecc)
2. Una catena definita dall’utente
3. Nessun obiettivo, in questo caso il pacchetto non verrà modificato e proseguirà il suo corso, ma il contatore della regola verrà aumentato, utile per le statistiche.

Quando come obiettivo la regola ha la concatenazione con un altra catena, il pacchetto viene dato in pasto a quest’ultima e processato, se non farà innescare nessuna delle regole di questa seconda catena, verrà continuato ad essere processato dalla catena chiamante, vale a dire la prima catena. Quando invece la regola usa un obiettivo standard ecco cosa succede:

ACCEPT:
Com’è facile intuire con accept
si indica l’accettazione del pacchetto,
che detto cosi potrebbe non voler dire una s***, ed infatti
ha diverse accezzioni (si scrive cosi?!) in base al contesto:
In una regola di INPUT infatti il pacchetto verrà accettato
e verrà introdotto nel sistema, in una regola di OUTPUT
il pacchetto generato dal sistema verrà accettato
e quindi gli sarà consentito di uscire dal sistema.
In una regola di FORWARD invece il pacchetto verrà accettato
e quindi verrà smistato dal sistema verso
un altra interfaccia, od un altro sistema in base alla regola.

DROP:
Con l’obiettivo drop il pacchetto verrà scartato, e pertanto
scomparirà dal sistema completamente. Questo tipo di obiettivo
è molto sicuro, e difatti è il più utilizzato in policy
che hanno l’obiettivo di negare un determinato tipo di traffico.
Questo perchè con DROP il firewall scarterà il pacchetto,
senza dare la benchè minima evidenza dell’evento, a livello
applicativo, questo significa che il mittente non vedrà altro
che la connessione appesa fino al suo timeout. Molto utile
perchè un potenziale attaccante non saprà se il pacchetto
è stato ricevuto e poi scartato, oppure se non è stato proprio
ricevuto, non riuscirà a determinare nemmeno se il sistema
esista o no.

QUEUE:
Con questo obiettivo facciamo si che il pacchetto interessante
venga messo in una coda, questo perchè venga poi processato
da una applicazione apposita, in iptables infatti esiste
la libreria libipq, che permette ad un applicazione di modificare
i pacchetti impilati in una coda. Se non vi è nessuna applicazione
dedicata al processo dei pacchetti accodati, questo obiettivo
sarà equivalente ad un DROP.

RETURN:
Con questo obiettivo facciamo si che il pacchetto arrivi
direttamente alla fine della catena, viene quindi applicata
la policy di default della catena, ma cosa significa?
Potremmo ad esempio dover gestire un firewall con una catena
di INPUT quasi infinita, tutti i pacchetti che dovranno essere
droppati quindi dovranno prima attraversare tutta la catena, ed
infine venire scartati, questo comporta un dispendio di risorse
soprattutto su sitemi interessati da grosse moli di traffico.
Definendo una politica di return, ed una policy di default
di drop, possiamo far si che tali pacchetti vengano scartati
subito anzichè fargli attraversare tutta la catena.

REJECT: L’obiettivo reject ha lo stesso ruolo del drop,
con la differenza che in questo caso viene mandato un pacchetto
ICMP d’errore per indicare che il pacchetto è stato scartato.
I tipi di pacchetto errore che è possibile mandare sono diversi,
difatti a volte l’obiettivo reject viene accompagnato
dal parametro –reject-with [parametro], e viene fatto seguire
da una di queste voci: icmp-net-unreachable, icmp-host-unreachble,
icmp-port-unreachable, icmp-proto-unreachable, icmp-net-prohibited,
icmp-host-prohibited, icmp-admin-prohibited.

LOG:
Questo obiettivo ha il semplice compito di annotare (o loggare)
l’evento inviando un messaggio sul syslog, utile
per l’amministratore per sapere i pacchetti droppati,
infatti questo obiettivo viene molto usato
nelle regole di input per sapere cosa e quando viene filtrato.

DNAT: Questo obiettivo viene utilizzato nella tabella del nat,
la tabella con cui gestiamo i mascheramenti degli indirizzi
della nostra rete. Con DNAT, utilizzato nella catena PREROUTING
ed OUTPUT, modifichiamo il pacchetto riscrivendo il campo
destination con l’indirizzo da noi scelto.

SNAT:
Anche questo obiettivo è utilizzato nella tabella del nat,
e come è facile intuire comporta la riscrittura del campo source
dell’header dei pacchetti, a differenza di dnat, questo obiettivo
viene utilizzato solo nelle catene di POSTROUTING.

MASQUERADE:
Questa è un altra forma di SNAT, utilizzata per nattare ad esempio,
un intera rete interna con l’ip della macchina che fa da firewall,
utile se ad esempio il firewall fa anche da router.

Iptables è un firewall di tipo stateful….eh?! O.o

Come abbiamo già detto iptables è un firewall stateful, vale a dire che è capace non solo di analizzare i pacchetti, ma anche di capire a quale connessione essi appartengano. Ed infatti una delle funzionalità più utili che iptables ci fornisce è proprio il monitoraggio delle connessioni. Il NAT ad esempio, fa uso di questo tipo di funzione, per sapere quali pacchetti devono essere nattati in un modo piuttosto che in un altro, oppure che non devono essere nattati.

Iptables assegna ai pacchetti i seguenti stati:

1. NEW -> Il pacchetto è il primo di una nuova connessione
2. ESTABLISHED -> Il pacchetto fa parte di uan connessione già instaurata ed attiva.
3. RELATED -> Il pacchetto è in qualche modo legato ad una connessione già attiva.
4. INVALID -> Il pacchetto è invalido, vale a dire che non fa parte di nessuna connessione, non è possibile creare una nuova connessione con esso, ne è possibile ricondurlo ad una connessione già esistente.

Il primo pacchetto di una connessione quindi, sarà sempre classificato come NEW, i seguenti pacchetti di risposta verranno considerati come ESTABLISHED, mentre i messaggi d’errore come RELATED. Un tipo di attacco molto comune è quello di mandare milioni di pacchetti di risposta (SYN-ACK)[fn]syn-ack è uno dei modi con cui vengono classificati i vari pacchetti, una connessione viene instaurata tramite quello che viene definito il "three way handshaking": la macchina che deve fare iniziare la connessione manda un pacchetto alla macchina di destinazione per sapere se è disponibile (syn), la macchina di destinazione, se disponibile, risponde con un altro pacchetto ed attende che anche la macchina mittente sia pronta(syn-ack), se anche la macchina mittente è pronta manda un altro pacchetto di risposta (ack), a questo punto la connessione è stabilita, ed il flusso dei dati viene garantito dai pacchetti veri e propri dei dati stessi (pacchetti push), quando la comunicazione deve terminare, la macchina mittente manda un altro pacchetto (reset) per indicare che ha finito e che la connessione può essere eliminata.[/fn] ad una connessione che non esiste (non vi è stato alcun SYN in precedenza), di modo che se non vi è un controllo sulla macchina questa attivi un socket (un canale per una connessione), e lo lasci li in attesa di un qualcosa che non verrà mai, fino a saturare i socket disponibili e quindi far crashare la macchina; questo è un tipo di attacco DoS[fn]Denail Of Service, attacchi volti a far cessare il servizio erogato da una macchina[/fn], ed il pacchetto syn-ack che abbiamo menzionato prima sarebbe classificato come INVALID.

Il monitoraggio delle connessioni è un arma molto potente per gli amministratori di sistema. Ad esempio è possibile contrassegnare come RELATED due connessioni apparentemente diverse ma che in realtà fanno capo alla stesso tipo di connessione; per esempio una connessione FTP, prevede l’utilizzo di due canali, uno di controllo ed uno di trasmissione dati, il secondo canale normalmente verrebbe visto come NEW, noi invece possiamo renderlo come RELATED al canale di controllo dato che fanno capo sempre alla stessa sessione FTP.

E’ possibile inoltre, lasciar passare dall’interno verso l’esterno le connessioni NEW, e dall’esterno verso l’interno le RELATED e le ESTABLISHED, fornendo un alto grado di sicurezza in quanto dall’esterno non è possibile instaurare connessioni, è possibile farlo solo in senso inverso. Tornando alla connessione FTP di prima, poniamo che una macchina della lan instauri una connessione con l’esterno, questa viene vista come NEW e quindi viene lasciata passare, ma se questa connessione prevede ad un certo punto, l’apertura di una sessione FTP dall’esterno, questa verrebbe vista come NEW e quindi bloccata, noi possiamo renderla come RELATED alla precedente connessione oramai ESTABLISHED, permettendo il flusso FTP di passare.[fn]mi rendo conto che questo ultimo pezzo possa essere di un livello tecnico un pò troppo avanzato per alcuni, eventualmente vi ricordo che ci sono sempre i commenti o il forum se avete dubbi.[/fn]

Per stasera è tutto, la prossima volta inizieremo ad analizzare iptables in se, inteso come interfaccia per netfilter, impareremo ad evocarlo (senza crisi mistiche però) ed a passargli i primi comandi per la creazione di un semplice firewall.

Stay tuned