Un firewall per amico (VI)

Introduciamo finalmente ipchains, un tool che ci permetterà di implementare le nostre politiche di firewall e di mascherare gli indirizzi IP della rete locale (Masquerading)

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.

Diagramma delle regole di filtraggio dei pacchetti applicate al nostro esempio

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.