Presentiamo, in questa terza puntata sul tema, un altro strumento di firewall configuration che opera come wizard. Pubblicato su NetsTime numero 14 del giugno 2001
Anche se negli articoli precedenti abbiamo utilizzato e descritto gfcc come interfaccia grafica di riferimento, riteniamo opportuno dare una brevissima spiegazione di quello che accade “sotto” la GUI stessa.
Di solito, quando si inizializza ipchains, si effettua un flushing (rimozione) delle regole e si stabilisce un’impostazione di default finalizzata a bloccare tutti i pacchetti.
Stante quanto descritto nel numero 12 di Netstime, partiamo dal presupposto che siano già state impostate le regole fondamentali relative alle tre chains.
In questo caso si da per assunto di aver già creato lo script file alla base di ipchains, nonché l’ammissione del traffico pacchetti a livello di interfaccia di loopback.
Egress filter e indirizzi
di partenza non corretti
Con questo termine si indicano i filtri che operano sul traffico in uscita. Uno degli accorgimenti principali da adottare riguarda il blocco dei pacchetti aventi indirizzo di partenza non corretto. Specie nelle reti di grandi dimensioni, questo può essere sintomatico di un tentativo di attacco o di utilizzo di una macchina interna come testa di ponte. Ricordiamo che: per inserire una regola dopo l’ultima entry dello script, si utilizza il comando ipchains -A; per indicare l’interfaccia ove questa regola deve operare si utilizza il flag -i; per loggare tutto a livello kernel (quindi con syslogd) si deve utilizzare il flag -l. Possiamo quindi identificare la sintassi corretta da adottare per fare in modo che i pacchetti che partono dall’interfaccia interna alla rete locale debbano avere un indirizzo appartenente a quest’ultima e quelli che vanno verso l’esterno via interfaccia interna debbano avere un indirizzo interno, e, negli altri casi, valgano le regole di default per ogni chain.
La giusta sintassi é:
ipchains – A input -i $INTIF -s $INTNET -j ACCEPT
ipchains – A output -i $INTIF -d $INTNET -j ACCEPT
Filtrare gli indirizzi
non di competenza della rete
Il fine primario di queste operazioni è quello di bloccare indirizzi di provenienza spoofed, con i relativi pacchetti.
Generalmente vengono scritte numerose entry di questo tipo, in quanto, alla fine dei conti, ciò non crea dei particolari problemi, specialmente se il firewall gira su macchine sufficientemente potenti e l’ampiezza di banda non è troppa.
L’impostazione delle regole ha una sintassi simile a quella spiegata nel precedente paragrafo.
Per quanto riguarda il blocco dei pacchetti, osserviamo che bisognerà operare in DENY. Questo per alcune ragioni che abbiamo spiegato dettagliatamente nei numeri precedenti di FocusZone security, ma comunque riconducibili al fatto che utilizzare il REJECT per il traffico esterno significa esporsi, tra l’altro, ai Denial of Service. Quest’ultima tipologia di attacco, inoltre, può essere perpetrata anche nei confronti di un terzo target, il cui indirizzo di partenza è stato “spoofato” in una transazione DdoS.
Ecco un esempio pratico della rule base in argomento:
ipchains -A input -i $EXTIF -s $INTNET -j DENY -l
ipchains -A input -i $EXTIF -s $LPDNET -j DENY -l
ipchains -A input -i $EXTIF ! -d $INTNET -j DENY -l
dove EXTIF sta per interfaccia esterna, INTNET sta per rete interna e LPDNET sta per interfaccia di loopback.
Altra particolare attenzione va posta nei confronti del broadcasting. Normalmente i pacchetti broadcast rientrano nella normalità (e non sempre) soltanto quando provengono dal proprio Internet Service Provider e nell’ambito di una transazione DHCP.
Siccome il broadcasting può essere sinonimo di Denial of Service, si consiglia di implementare una regola in questo senso.Un esempio, a questo proposito, potrebbe essere il seguente:
ipchains -A input -i $EXTIF -d $INTBC -j deny -l
dove INTBC sta per internal broadcast address.
In questa maniera, ribadiamo, tutto il traffico broadcast dovrebbe risultare bloccato.
Un altro strumento
di firewall configuration
Se gfcc risulta essere un’ottima interfaccia grafica, esistono delle alternative a questo tool, che operano anche come “wizard” per la configurazione di ipchains nel caso specifico. Uno di questi è PMFirewall.
Attualmente giunto alla versione 1.1.4, è stato disegnato per consentire a un utente non avanzato di effettuare le operazioni minime di implementazione del firewall.
A detta dell’autore il firewall è in grado di lavorare con la maggior parte di Workstation, server e dual NIC router, lavorando altresì con le linee DSL, Cable o LAN. La cosa interessante è l’autodetection degli indirizzi IP e della Netmask di ogni interfaccia. Dal punto di vista operativo, di base questo tool effettua il Blocking di NetBIOS, NetBUS, Back Orifice e Samba attacks.
Inoltre, viene implementata una protezione contro gli attacchi di tipo IP Spoofing, il logging dei pacchatti sottoposti a operazioni di DENY e via dicendo. In pratica le cose di cui abbiamo parlato in questo articolo. Il tool è disponible all’indirizzo internet http://www.pointman.org/pmfirewall/.
Un’ultima precisazione: all’inizio abbiamo parlato dell’evoluzione del firewalling sotto linux. Con l’avvento del Kernel 2.4,infatti, si è avuta la definitiva introduzione di Iptables, che dovrebbe segnare una svolta in questo settore.
Il problema è che, a leggere i post degli operatori sui vari forum e l’effettuazione dei test, il kernel non è definitivamente stabile.
Il prossimo articolo parlerà delle novità generali di questo nuovo tool di protezione perimetrale, mentre abbiamo deciso di aspettare ancora un po’ di tempo per iniziare con la descrizione di basso livello, in quanto abbiamo notato che la sua diffusione in ambiente di produzione è ancora limitata.
