Un firewall per amico (VI)

Siamo arrivati, questa settimana, a parlare del tanto citato ipchains, che ci
permetterà di implementare le nostre politiche di firewall oltre a permetterci
il mascheramento degli indirizzi ip della rete locale (Masquerading). Vediamo in
dettaglio il funzionamento del tool.

Ipchains può essere paragonato ad un arbitro di rete che conosce
tutte le connessioni, le identifica classificandole e permette o nega l’accesso
da o verso la rete interna, in modo da filtrare eventuali attacchi o connessioni
non autorizzate.

Per istruire il nostro "arbitro della rete" utilizziamo delle regole (rules)
che identificano le connessioni per interfaccia (eth0, eth1, ppp0 ?), per
indirizzo IP, per porta e per protocollo utilizzato (TCP, UDP). I filtri (chain)
possono essere di input , di output o di forward .

Ogni pacchetto che transita dalla rete esterna a quella interna o viceversa può
essere sottoposto alla verifica di uno di questi filtri (chain). Quando a un
pacchetto di rete corrisponde una regola (rule), le sue sorti sono definite
dalla regola stessa. Nel caso in cui al pacchetto non corrisponde nessuna
specifica regola, viene applicata la policy generale del filtro, cioè la regola
predefinita per il filtro (chain) che si sta utilizzando.

Per non autorizzare il transito di determinate connessioni, come ad esempio
l’utilizzo del servizio telnet da parte di macchine presenti in Internet,
è possibile definire una regola che impedisca l’accesso di tale servizio da
parte di altri host. Più in particolare la regola che definiamo può impedire
il transito del pacchetto ignorandolo (deny) oppure negarne l’accesso ed
inviando alla fonte un messaggio ICMP di errore ( deny ). Se prendiamo ad
esempio il servizio telnet, uno dei più "a rischio" per un server,
nel caso della regola deny il client prova la connessione fino a che
questa non va in time-out, mentre nel caso della regola reject il server
risponderà immediatamente al client con un messaggio "Connection refused":
questa notifica la si riceve anche con macchine che normalmente non supportano
tale servizio, come ad esempio Windows 95/98.

Quali sono le politiche da preferire, deny o reject ? In generale
la migliore politica è il reject in quanto rende più difficoltoso
dall’esterno capire se il servizio richiesto sia filtrato o completamente
disabilitato. Nel caso invece di deny risulta immediato capire se il
servizio sia abilitato o meno dando modo a malintenzionati di tentare di
aggirare i filtri del nostro firewall.

Riprendiamo l’esempio precedente in cui una macchina connessa ad Internet
cerchi di connettersi via telnet a una delle nostre macchine locali protette dal
firewall. Vediamo in dettaglio cosa succede, aiutati anche dal diagramma.

1) La connessione telnet parte dalla macchina remota connessa ad Internet

2) Il pacchetto viene ricevuto dalla porta 23 (servizio telnet) della nostra
macchina attraverso l’interfaccia di rete "esterna"

3) Si cerca la regola da applicare. Se il traffico telnet è permesso ( allow )
la connessione non viene bloccata, altrimenti attraverso una politica di deny
o reject i pacchetti ricevuti vengono bloccati. Tale traffico può
essere, a nostro piacimento, monitorizzato e loggato.

4) Se il pacchetto può transitare viene processato dal demone preposto. A
questo punto i pacchetti di ritorno verranno inviati su una porta alta
(>1024) e non più sulla porta 23. Immaginiamo che i pacchetti vengano
spediti attraverso la porta 3200 del sistema. Tale traffico sarà soggetto di
controllo da parte delle politiche di output del nostro firewall.

5) Se esiste una politica che permetta l’uscita di tali pacchetti allora la
connessione è andata a buon fine altrimenti i pacchetti vengono
"cestinati".

6) Se il computer remoto è locato su una rete differente dalla nostra, i
pacchetti andranno inoltrati ( forward ) verso la corretta rete,
utilizzando il Masquerading.

7) A questo punto effettivamente i pacchetti generati dalla porta alta
lasceranno la nostra macchina per arrivare a destinazione.

E’ importante capire che per permettere il traffico telnet verso la macchina
locale occorre non solo abilitare il transito dei pacchetti verso la porta 23,
ma anche tutto il traffico di output generato dalle porte alte. Se volete che
vengono instradati verso l’esterno, nel giusto modo, solo i pacchetti di
risposta ed eliminati tutti gli altri, basta definire una regola di output in
cui viene controllato il bit SYN del datagramma inviato.

Come per una tabella di instradamento di un router, così l’ipchains
attraverso una tabella di regole filtra il traffico di rete. L’ordine con cui
vengono definite le regole è importantissimo.

La sintassi del comando è la seguente:

ipchains opzione di comando filtro [regola] [obiettivo]

Le opzioni principali sono:

-F: elimina tutte le regole di un filtro

-D: cancella una o più regole

-A: aggiunge una regola in coda a quelle già esistenti

-I: inserisce una regola in una posizione prestabilita

-R: sostituisce una regola del filtro

Oltre a queste esistono altre due opzioni che non modificano le regole:

-L: elenca le regole di un filtro

-P: cambia la politica predefinita del filtro specificato

Come abbiamo già visto i filtri (chain) sono i seguenti:

Input: filtro di ingresso

Output: filtro di uscita

Forward: filtro di inoltro

Infine gli obiettivi sono:

Accept: permette il transito del pacchetto

Deny: impedisce il transito del pacchetto ignorandolo

Reject: impedisce il transito del pacchetto restituendo alla fonte un messaggio
ICMP di errore

Giuseppe Augiero