[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico] [volume] [parte]
All'interno di una rete, il firewall è un componente che serve a proteggerne una parte rispetto al resto. Di solito, si tratta di qualcosa che si interpone tra una rete interna e una rete esterna, come Internet, per evitare un accesso indiscriminato alla rete interna da parte di nodi collocati all'esterno di questa.
Il firewall, a parte il significato letterale del nome, è una sorta di filtro (passivo o attivo) che si interpone al traffico di rete. Come tale, deve essere regolato opportunamente, in base agli obiettivi che si intendono raggiungere.
|
Figura 176.1. Il firewall è un filtro che si interpone tra una rete interna e una rete esterna.
|
Generalmente, i compiti del firewall vengono svolti da un elaboratore configurato opportunamente, munito di almeno due interfacce di rete: una per l'accesso alla rete esterna e una per la rete interna.
Il NAT (Network address translation) è un procedimento attraverso cui si modificano gli indirizzi IP, generalmente allo scopo di consentire a una rete privata di accedere all'esterno. Spesso, questa funzionalità si integra con quella di firewall.
Il firewall elementare è un elaboratore con due interfacce di rete, per le quali sono stati definiti gli instradamenti nel modo consueto, ma dove è stato impedito il transito del traffico tra un'interfaccia e l'altra.
L'utilità di un filtro del genere è minima. Probabilmente si potrebbe utilizzare come servente SMTP e come punto di arrivo per i messaggi di posta elettronica, che gli utenti della rete interna potrebbero scaricare attraverso un protocollo come POP3, o IMAP. Inoltre, gli utenti che desiderano accedere alla rete esterna, potrebbero utilizzare il protocollo TELNET per collegarsi al firewall per poi avviare da lì il programma cliente adatto all'operazione che vogliono compiere.
Evidentemente, questa non deve essere intesa come una scelta ottimale, anzi, di sicuro si tratta di un approccio sbagliato dal punto di vista della sicurezza, ma serve a rendere l'idea del significato che può avere un firewall.
Volendo, l'inserimento di una cache proxy all'interno del firewall potrebbe permettere agli utenti della rete interna, disponendo di software adatto, di accedere alle risorse della rete esterna (di solito solo con i protocolli HTTP e FTP).
All'estremo opposto, un router è un firewall che consente il transito di tutto il traffico, senza porre alcun limite, né alcun controllo.
Si distinguono due tipi fondamentali di firewall: filtri di pacchetto IP e serventi proxy. In particolare, il kernel Linux aggiunge alle funzionalità di filtro di pacchetto anche la trasformazione degli indirizzi e delle porte (NAT/PAT).
I filtri di pacchetto IP permettono di bloccare o abilitare selettivamente il traffico che attraversa il firewall, definendo i protocolli (o meglio, il tipo di pacchetto), gli indirizzi IP e le porte utilizzate. Questo tipo di sistema permette al massimo di controllare i tipi di servizio che possono essere utilizzati in una direzione e nell'altra, da e verso indirizzi IP determinati, ma senza la possibilità di annotare in un registro i collegamenti che sono stati effettuati (salvo eccezioni), né di poter identificare gli utenti che li utilizzano. In un certo senso, questo tipo di firewall è come un router su cui si può soltanto filtrare il tipo dei pacchetti che si vogliono lasciare transitare.
I serventi proxy rappresentano una sorta di intermediario che si occupa di intrattenere le connessioni per conto di qualcun altro nella rete interna. Per tornare all'esempio del firewall elementare, è come se un utente aprisse una connessione TELNET verso il proxy, utilizzando da lì un programma cliente adatto per il tipo di collegamento che intende realizzare al di fuori della sua rete interna. Dal momento che il proxy ha un ruolo attivo nelle connessioni, può tenere un registro delle azioni compiute; eventualmente può anche tentare di identificare l'utente che lo utilizza.
Per completare il discorso, una cache proxy è qualcosa di simile al servente proxy a cui si sta facendo riferimento. La differenza sta essenzialmente nella specializzazione che nel primo caso è puntata alla gestione di una memoria cache, mentre nel secondo è rivolta alla protezione della rete interna.
Il filtro di pacchetto può intervenire al terzo o al massimo al quarto livello del modello ISO-OSI. In altri termini, è in grado di identificare e filtrare i pacchetti in base agli indirizzi IP, alle porte utilizzate e a poche altre informazioni, come elencato nella tabella 176.1 a titolo di esempio.
|
Figura 176.2. Un firewall che funziona come filtro di pacchetto IP, può interviene al terzo e quarto livello del modello ISO-OSI.
|
Tabella 176.1. Caratteristiche tipiche dei pacchetti che possono essere prese in considerazione per il filtro.
Si tratta di una limitazione significativa, che rappresenta in pratica il problema maggiore nella configurazione corretta di un filtro del genere in base ai fini che si tendono ottenere. Volendo esprimere la cosa attraverso un esempio molto semplice, un filtro di questo tipo non può intervenire esattamente ed esclusivamente sul «protocollo HTTP»; al massimo si può intercettare il transito dei pacchetti TCP in arrivo verso la porta 80, se si vuole impedire l'instaurarsi di connessioni a un servizio HTTP locale, oppure in uscita se si vuole impedire di raggiungere servizi esterni. Ma questo non vuol dire che si blocca il protocollo HTTP, è solo un intervento fatto in modo tale da arrivare allo stesso risultato.
Tabella 176.2. Messaggi ICMP.
| Tipo | Codice | Nome del tipo | Nome del codice | Chi lo utilizza |
| 0 | echo-reply | risposta a un ping (pong) | ||
| 1 | ||||
| 2 | ||||
| 3 | destination-unreachable | traffico TCP/UDP | ||
| 3 | 0 | network-unreachable | ||
| 3 | 1 | host-unreachable | ||
| 3 | 2 | protocol-unreachable | ||
| 3 | 3 | port-unreachable | ||
| 3 | 4 | fragmentation-needed | ||
| 3 | 5 | source-route-failed | ||
| 3 | 6 | network-unknown | ||
| 3 | 7 | host-unknown | ||
| 3 | 8 | |||
| 3 | 9 | network-prohibited | ||
| 3 | 10 | host-prohibited | ||
| 3 | 11 | TOS-network-unreachable | ||
| 3 | 12 | TOS-host-unreachable | ||
| 3 | 13 | communication-prohibited | ||
| 3 | 14 | host-precedence-violation | ||
| 3 | 15 | precedence-cutoff | ||
| 4 | source-quench | |||
| 5 | redirect | instradamento dei pacchetti | ||
| 5 | 0 | network-redirect | ||
| 5 | 1 | host-redirect | ||
| 5 | 2 | TOS-network-redirect | ||
| 5 | 3 | TOS-host-redirect | ||
| 6 | ||||
| 7 | ||||
| 8 | echo-request | ping | ||
| 9 | router-advertisement | |||
| 10 | router-solicitation | |||
| 11 | time-exceeded (ttl-exceeded) | traceroute | ||
| 11 | 0 | ttl-zero-during-transit | ||
| 11 | 1 | ttl-zero-during-reassembly | ||
| 12 | parameter-problem | |||
| 12 | 0 | ip-header-bad | ||
| 12 | 1 | required-option-missing | ||
| 13 | timestamp-request | |||
| 14 | timestamp-reply | |||
| 15 | information-request | |||
| 16 | information-reply | |||
| 17 | address-mask-request | |||
| 18 | address-mask-reply |
Un'altra cosa fondamentale da considerare è il fatto che i pacchetti frammentati a livello di protocollo IP, possono essere identificati come frammenti, mentre diventa impossibile conoscere le altre caratteristiche (TCP o UDP).
Teoricamente, ammesso che l'applicazione utilizzata come filtro (assieme al kernel) sia abbastanza sofisticata da permetterlo, si può intervenire in tre punti differenti: nel transito dei pacchetti da un'interfaccia a un'altra, nei pacchetti in arrivo attraverso una data interfaccia e nei pacchetti in uscita. La distinzione è importante perché i risultati pratici che si ottengono possono essere molto diversi a seconda del punto in cui si inserisce il filtro.
|
Figura 176.3. Punti di inserzione di un filtro di pacchetto.
|
Anche senza fare un riferimento preciso alle interfacce di rete coinvolte, si pensi al caso in cui si intercettano in uscita i pacchetti ICMP di tipo 8, echo-request, allo scopo di bloccarne il transito. In tal caso, ci si impedisce di usare il Ping verso l'esterno; al contrario, intercettando lo stesso tipo di pacchetto, ma in ingresso, il suo blocco impedisce ai nodi esterni di usare il Ping verso il proprio elaboratore. Se invece l'intercettazione avvenisse nella fase di transito, questo potrebbe servire solo a impedire il Ping che riguarda altri nodi, oppure solo l'interfaccia del lato opposto.
I pacchetti intercettati possono essere trattati in modi differenti:
possono essere lasciati passare;
possono essere bloccati;
possono essere bloccati, inviando all'origine un messaggio di rifiuto attraverso un pacchetto ICMP;
possono essere semplicemente tenuti sotto controllo (contabilizzati).
Eventualmente, la contabilizzazione del traffico può essere implicita in ogni tipo di intercettazione.
In generale, un nodo di rete che svolge funzioni di firewall dovrebbe trovarsi in un «passaggio obbligato» della rete, per evitare che i pacchetti possano utilizzare percorsi alternativi. In questo senso, è opportuno che tale nodo possa ricomporre i pacchetti frammentati a livello IP, in modo da riunire assieme tutte le informazioni necessarie a identificare i pacchetti, proprio per poter attuare effettivamente il controllo che il firewall deve fare.
In mancanza della possibilità di ricomporre i pacchetti frammentati, il firewall può individuare nei frammenti solo gli indirizzi IP, del mittente e del destinatario, oltre al riconoscere che si tratta di frammenti. Diventa impossibile l'identificazione delle porte, TCP o UDP, oppure i messaggi ICMP.
È il caso di raccogliere qualche esempio schematico del modo in cui si potrebbe configurare un firewall che utilizza la tecnica del filtro di pacchetto. Le impostazioni vengono indicate in forma di record, secondo lo schema seguente:
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 |
I campi del record hanno il significato descritto nell'elenco che segue, tenendo conto che i valori mancanti vengono considerati indifferenti:
azione del filtro: blocco, rifiuto o altro;
posizione del filtro: in ingresso, in uscita, in transito o altro;
protocollo: TCP, UDP, ICMP;
indirizzi IP di origine;
porte TCP o UDP di origine;
indirizzi IP di destinazione;
porte TCP o UDP di destinazione;
messaggio ICMP, indicando il tipo e il codice eventuale (tipo[/codice]);
interfaccia di rete coinvolta;
altre caratteristiche.
Si osservi in particolare che gli indirizzi IP si indicano nella forma indirizzo/maschera, dove la maschera si esprime attraverso un intero che rappresenta una quantità iniziale di bit da impostare a uno. Inoltre, gli indirizzi e le porte possono essere prefissati da un punto esclamativo che indica la negazione logica, ovvero tutti gli altri indirizzi o tutte le altre porte.
Si impedisce l'ingresso a ogni pacchetto proveniente dagli indirizzi 192.168.*.*:
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| blocco | ingresso | 192.168.0.0/16 | 0/0 |
Si impedisce l'ingresso ai pacchetti ICMP provenienti dagli indirizzi 192.168.*.*:
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| blocco | ingresso | ICMP | 192.168.0.0/16 | 0/0 |
Si impedisce l'ingresso dei pacchetti provenienti dall'interfaccia x, contenenti come mittente indirizzi tipici delle reti private. In pratica, si presume che sia impossibile ricevere pacchetti di questo tipo da tale interfaccia, perché la rete privata è connessa su un'altra interfaccia; pertanto, pacchetti del genere possono essere solo contraffatti.
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| blocco | ingresso | 10.0.0.0/8 | 0/0 | x | |||||
| blocco | ingresso | 172.16.0.0/12 | 0/0 | x | |||||
| blocco | ingresso | 192.168.0.0/16 | 0/0 | x |
Si impedisce l'attraversamento di pacchetti della classe D e E:
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| blocco | transito | 224.0.0.0/3 | 0/0 |
Consente l'attraversamento ai pacchetti TCP per raggiungere presumibilmente un servizio TELNET:
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| blocco | transito | TCP | 0/0 | 0/0 | 23 |
Blocca il transito delle comunicazioni riferite alla gestione remota di applicazioni X. Si presume si possano gestire un massimo di 10 serventi grafici simultaneamente.
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| blocco | transito | TCP | 0/0 | 6000-6009 | 0/0 | ||||
| blocco | transito | TCP | 0/0 | 0/0 | 6000-6009 |
Blocca l'ingresso e l'uscita delle comunicazioni riferite alla gestione remota di applicazioni X. In questo caso, si protegge il nodo che funge da firewall.
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| blocco | ingresso | TCP | 0/0 | 6000-6009 | 0/0 | ||||
| blocco | uscita | TCP | 0/0 | 0/0 | 6000-6009 |
Vanno tenute a mente alcune cose quando si configura un firewall attraverso il filtro di pacchetto, per evitare di compromettere le funzionalità che invece si vogliono mantenere.
È già stato accennato il fatto che non si deve bloccare il transito dei pacchetti del protocollo ICMP. Il messaggio di tipo 3, destination-unreachable, è indispensabile nei protocolli TCP e UDP per sapere che un certo indirizzo non è raggiungibile; bloccandolo, si attende senza sapere il perché.
Il protocollo ICMP viene usato anche nella determinazione automatica della dimensione massima dei pacchetti (MTU discovery). Mancando la possibilità di ricevere questi pacchetti ICMP, il funzionamento delle comunicazioni potrebbe essere compromesso seriamente.
I protocolli che si basano su UDP sono usati frequentemente nell'ambito di servizi locali, come NIS e NFS. Tra le altre cose, questi servizi tendono a fare viaggiare informazioni particolarmente delicate che non dovrebbero essere accessibili dall'esterno. Per questa ragione, è normale che venga impedito il transito dei pacchetti UDP. Tuttavia, capita che proprio il servizio DNS (per la risoluzione dei nomi), possa averne bisogno.
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| blocco | transito | UDP | 0/0 | 0/0 |
Per la precisione, il servizio DNS può usare pacchetti UDP o connessioni TCP, a seconda della dimensione di questi. Così, il blocco eventuale di tale servizio si avvertirebbe solo in modo intermittente, complicando l'individuazione del problema.
Generalmente, un servizio DNS collocato in una posizione tale per cui non possa inviare o ricevere pacchetti UDP dall'esterno, si deve avvalere necessariamente di un altro collocato al di fuori di tale blocco. Infatti, in questo modo userebbe solo il protocollo TCP.
Eventualmente, il firewall potrebbe essere configurato espressamente per consentire il transito di questi pacchetti legati al servizio DNS. Nell'esempio seguente si suppone che il servizio DNS in questione sia collocato nel nodo 196.1.2.3:
| Azione | Pos. | Prot. | IP srg | IP dst | ICMP | Int. | |||
| accetta | transito | UDP | 0/0 | 53 | 196.1.2.3 | ||||
| accetta | transito | TCP | 0/0 | 53 | 196.1.2.3 | ||||
| accetta | transito | UDP | 196.1.2.3 | 0/0 | 53 | ||||
| accetta | transito | TCP | 196.1.2.3 | 0/0 | 53 |
Il NAT, o Network address translation, è una tecnica descritta nell'RFC 1631, con la quale un nodo di rete speciale acquista funzionalità simili a quelle di un router, intervenendo però sui pacchetti, allo scopo di sostituire gli indirizzi IP reali con altri indirizzi più convenienti.
Il problema a cui fa riferimento l'RFC 1631 riguarda la possibilità di riutilizzare dinamicamente gli indirizzi IP riservati alle reti private, permettendo ugualmente a tali reti di accedere all'esterno, pur non essendo questi univoci a livello globale. Si osservi l'esempio della figura 176.4.
|
Figura 176.4. Esempio di router NAT: l'indirizzo IP 196.1.2.3 è un esempio che sta a rappresentare un indirizzo univoco riconosciuto nella rete esterna.
|
In condizioni normali, gli indirizzi IP 192.168.1.* non hanno la possibilità di essere riconosciuti univocamente all'interno della rete globale, pertanto i nodi relativi non hanno la possibilità di accedere all'esterno. Attraverso il meccanismo NAT e le sue varianti, si può ottenere questo risultato anche se poi è necessario accettare qualche compromesso.
Nella sua impostazione più semplice, un router NAT può gestire un numero ristretto di indirizzi IP univoci, da abbinare dinamicamente a degli indirizzi IP locali privati.
|
Figura 176.5. Utilizzo dinamico di un gruppo ristretto di indirizzi IP univoci.
|
Osservando la figura 176.5 si può vedere che il nodo che ha il ruolo di router NAT dispone di un accesso all'esterno con quattro diversi indirizzi IP univoci. In questo modo, in base alle richieste provenienti dalla rete interna, può abbinare temporaneamente un indirizzo univoco a un indirizzo privato interno. Per esempio, in un dato momento, i pacchetti provenienti o destinati all'indirizzo 192.168.1.1 potrebbero essere modificati in modo da rimpiazzare tale indirizzo con quello univoco 196.1.2.3.
|
Figura 176.6. Una connessione TCP rielaborata da un router NAT.
|
In questo caso, il router NAT si limita a sostituire ai pacchetti gli indirizzi IP di origine o di destinazione, in base all'attribuzione dinamica stabilita.
La conversione degli indirizzi può anche essere dinamica solo in parte, in cui alcuni indirizzi univoci sono abbinati stabilmente ad altrettanti indirizzi della rete privata. Questo permette a tali nodi di essere raggiungibili anche da un accesso esterno, senza che debbano essere loro per primi a instaurare una connessione.
Oltre alla sostituzione degli indirizzi, un router NAT più evoluto può gestire anche la sostituzione delle porte TCP e UDP; in tal caso si parla anche di PAT, ovvero di Port address translation. Spesso, la realtà è tale per cui diventa indispensabile questo approccio, disponendo di un solo indirizzo IP univoco.
|
Figura 176.7. Due connessioni TCP indipendenti, rielaborate attraverso un procedimento NAT/PAT.
|
La figura 176.7 mostra il caso in cui i nodi 192.168.1.1 e 192.168.1.2 instaurano due connessioni TELNET indipendenti attraverso un router NAT/PAT. In questo caso, il NAT/PAT non si limita a sostituire ai pacchetti gli indirizzi IP di origine o di destinazione, intervenendo anche sui numeri di porta TCP.
Utilizzando il meccanismo NAT/PAT in questo modo, considerando che gli accessi iniziano sempre dalla parte della rete interna, per raggiungere indirizzi esterni, è normale che le porte di origine siano sempre non privilegiate, cioè siano maggiori o uguali a 1 024. Il router NAT/PAT potrebbe anche essere utilizzato per dirigere le connessioni originate dall'esterno e dirette a porte determinate (probabilmente nel gruppo di porte privilegiato) a nodi ben precisi nella rete locale, solitamente per raggiungere dei servizi realizzati lì. Per fare questo occorre quindi che il router NAT/PAT annoti delle ridirezioni statiche riferite alla richiesta di porte particolari. Per esempio, la figura 176.8 mostra un router NAT/PAT che ridirige sistematicamente le connessioni provenienti dall'esterno, dirette alla porta 80, verso il nodo locale 192.168.1.1 alla stessa porta 80, dal momento che questo offre un servizio HTTP.
|
Figura 176.8. Ridirezione del traffico diretto a un servente HTTP interno.
|
Il meccanismo NAT/PAT, come qualunque altra forma di rimaneggiamento dei pacchetti allo scopo di sostituire gli indirizzi IP o le porte TCP/UDP, funziona bene solo quando i protocolli utilizzati a livello di sessione, ovvero il quinto del modello ISO-OSI, non prendono iniziative autonome allo scopo di gestire gli indirizzi e le porte. In altri termini, tutto funziona bene se non si inseriscono informazioni sugli indirizzi e sulle porte al di sopra del livello del TCP o di UDP.
Il classico esempio problematico è dato dall'FTP che negozia con la controparte l'instaurazione di una connessione TCP aggiuntiva, attraverso informazioni contenute nell'area «dati» dei pacchetti. In questo modo, un router NAT/PAT ingenuo riuscirebbe a trasferire solo la prima connessione TCP.
Evidentemente, un router NAT/PAT evoluto dovrebbe essere consapevole, non solo dei protocolli IP, TCP e UDP, ma anche di tutti i protocolli che si inseriscono al di sopra di questi, in modo da intervenire opportunamente.
Un'ultima cosa da considerare riguarda anche il problema dei pacchetti frammentati, che devono essere ricomposti quando si utilizza il meccanismo NAT/PAT.
K. Egevang, P. Francis, RFC 1631, The IP Network Address Translator (NAT), 1994
<http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1631.html>
<http://www.cis.ohio-state.edu/cs/Services/rfc/rfc-text/rfc1631.txt>
Cisco IOS Network Address Translation (NAT)
<http://www.cisco.com/warp/public/cc/pd/iosw/ioft/ionetn/prodlit/1195_pp.htm>
daniele @ swlibero.orgDovrebbe essere possibile fare riferimento a questa pagina anche con il nome introduzione_ai_concetti_di_firewall_e_di_nat_pat.html
[successivo] [precedente] [inizio] [fine] [indice generale] [violazione GPL] [translators] [docinfo] [indice analitico]