Universit` a degli studi di Milano
Progetto d’esame per
Sistemi di elaborazione dell’informazione
Firewall con IpTables
Marco Marconi
Anno Accademico 2009/2010
Sommario
Implementare un firewall con iptables e linux per inserirlo in una piccola realt` a aziendale composta da una intranet, una DMZ, e la rete pubblica. Le problematiche incontrate in questo tipo di implementazione riguardano, il MA- SQUERADE tra la rete intranet e la rete internet, il nat per i servizi dalla rete pubblica alla rete DMZ, la gestione delle connessioni in modalit` a state- full tramite i moduli messi a disposizione da iptables. I paramentri del ker- nel per salvaguardare tutto il traffico, come ad esempio, icmp echo ignore all, icmp echo ignore broadcast, icmp ignore bogus error responses, ecc...., non ver- ranno analizzati.
I
ELENCO DELLE FIGURE INDICE
Indice
1 Introduzione 1
1.1 struttura del documento . . . . 1
2 Cenni di IpTables 2 2.1 premessa . . . . 2
2.2 Il connection tracking . . . . 2
2.2.1 Un esempio con ftp . . . . 3
2.3 Le tabelle e le catene . . . . 4
2.4 Azioni . . . . 5
3 Configurazione utilizzata 6 3.1 S.O. e pacchetti installati . . . . 6
3.2 Piano d’indirizzamento . . . . 7
4 requisiti della rete 8 4.1 intranet . . . . 8
4.2 DMZ . . . . 8
4.3 Internet . . . . 9
4.4 Conclusioni sulle regole . . . . 9
5 Implementazione 10 5.1 Impostiamo l’ip forward . . . . 10
5.2 Blocchiamo tutto il traffico . . . . 10
5.3 da Intranet a Pubblic . . . . 10
5.4 da Intranet a DMZ . . . . 11
5.5 da Internet (pubblic) a DMZ . . . . 11
5.6 Salvare le regole . . . . 12
6 Test e verifiche funzionali 13 6.1 ip forward . . . . 13
6.2 Verifica delle politiche di default(DROP) . . . . 13
6.3 Il masquerating . . . . 13
6.4 Il NAT . . . . 14
6.5 test con nmap . . . . 14
7 Conclusioni e sviluppi futuri 14 8 Lo script delle regole 15 Elenco delle figure 1 Funzionamento della tabella flter . . . . 4
2 Diagramma delle reti . . . . 6
ELENCO DELLE TABELLE ELENCO DELLE TABELLE
Elenco delle tabelle
1 Tabelle Server Client . . . . 7
2 Firewall . . . . 7
3 Intranet . . . . 8
4 DMZ . . . . 8
5 Pubblic . . . . 9
6 Regole complessive . . . . 9
7 Confronto tra traffico in ingresso ed uscita . . . . 14
1 INTRODUZIONE
1 Introduzione
Inseriamoci nella realt`a di una piccola azienda che ha la necessit`a di pubblicare i propri servizi su internet e contestualmente dare ai propri dipendenti la possibilit`a di navi- gare sul web e utilizzare i servizi aziendali, che siano o meno pubblicati su internet.
Uno dei primi problemi `e la gestione dei pochi indirizzi ip pubblici che normalmente i provider assegnano alle piccole aziende. Nel momento in cui un’azienda decide di connettersi ad internet, non solo per la navigazione dei propri dipendenti, ma anche per la pubblicazione dei propri servizi, si trova davanti al problema della sicurezza della rete, che potrebbe essere compromessa da un potenziale attaccante posto su internet o anche sulla rete aziendale stessa. ´ E quindi necessario dotare la propria rete dei servizi (DMZ) di una barriera (Firewall) con cui controllare e regolare il tipo di traffico che viene veicolato all’ingresso della rete DMZ. ´ E altrettanto necessario proteggere la rete dei dipendenti da attacchi provenienti dalla rete internet.
Una possibile soluzione `e quella di implementare un firewall con tre interfacce di rete, una per ogni rete logicamente diversa. Il nostro firewall, con una interfaccia sar`a connesso ad internet, e sulle altre due rimaste libere, troveranno posto, la rete DMZ, e la rete dei dipendenti(intranet). Saranno utilizzati degli indirizzi privati, sia sulla DMZ che sulla intranet, e quindi, una ulteriore complessit`a alla configurazione del firewall, `e costituita dall’utilizzo della funzionalit`a di mascheratura
1, che consente a tutti i dipendenti di presentarsi su internet utilizzando tutti lo stesso indirizzo ip pubblico.
In questo documento saranno analizzate ed implementate le tecniche di maschera- tura, MASQUERADE e NAT
2, e la gestione in modalit`a statefull del firewall.
1.1 struttura del documento
Il documento `e diviso in una parte introduttiva e a seguire dei cenni sulle funzionalit`a di IpTables che utilizzeremo sul nostro firewall (vedi sezione 2). Nella sezione 5 andremo ad implementare le nostre regole sul firewall per poi eseguire dei semplici test nella sezione 6.
1MASQUERADE come viene definita in iptables
2il NAT si divide anche per SNAT,DNAT,. . . in questo documento sar`a utilizzata solamente la funzionalit`a di DestinationNAT
2 CENNI DI IPTABLES
2 Cenni di IpTables
2.1 premessa
Descrivere cos’`e e come funziona IpTables, non `e lo scopo di questo progetto, e quindi ci limiteremo a spiegare le sole funzionalit`a che andremo a utilizzare.
2.2 Il connection tracking
Dalla tabella 6 siamo in grado di capire quale traffico deve transitare per una certa interfaccia di rete, ma questo se sufficiente per la comprensione delle regole di un firewall generico, non lo `e per chi deve implementare ogni singola regola su uno specifico firewall. Per fare un esempio banale, se provo a fare un ping da un host A ad un host B ed utilizzo una regola del tipo source:A destination:B protocol:echo rule:accept il ping continuer`a a non funzionare in quanto non `e stata specificata la regola per il ritorno del ping (echo reply). Il problema `e che la risposta al ping, ma come tutte le connessioni di rete in risposta ad un’altra, fanno uso di numeri di porta casuali sopra la 1023.
Aprire tutte le porte dopo la 1023, non `e una buona politica di sicurezza, e per fortuna IpTables ci viene in aiuto con il modulo connection tracking, che fa diventare il firewall da stateless a stateful.
Il connection tracking `e la capacit`a di mantenere in memoria le informazioni sulle connessioni in transito nel firewall. Con questa caratteristica IpTables `e in grado di ricordare lo stato dei flussi e delle connessioni dei protocolli usati. In
/proc/net/ip_conntrack
il kernel mantiene e aggiorna in tempo reale lo stato delle connessioni gestite, fino ad un numero massimo che `e possibile modificare intervenendo su
/proc/sys/net/ipv4/ip_conntrack_max
La gestione del traffico, basata sulle connessioni, si fa utilizzando il modulo di match (-m state con iptables) con state che permettere di suddividere il traffico nei seguenti stati:
• NEW - una nuova richiesta di connessione da parte di un client (SYN TCP o nuovo pacchetto UDP);
• ESTABLISHED - pacchetti relativi a connessioni gi`a stabilite;
• RELATED - pacchetti correlati (RELATED) a connessioni esistenti e ESTABIL- SHED, come ad esempio il traffico ftp;
• INVALID - una connessione che non `e nessuna delle precedenti.
Il connection tracking `e particolarmente comodo per gestire il traffico di risposta per le
connessioni gi`a accettate. Ad esempio, per permettere tutto il traffico in uscita (tipico
caso di un client), e in entrata solo il traffico RELATED a quanto uscito, `e sufficiente
una regola del tipo:
2 CENNI DI IPTABLES 2.2 Il connection tracking
$ iptables -I INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$ iptables -I OUTPUT -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT Per gestire lo stato di connessione di alcuni protocolli, esistono dei moduli speciali adibiti al connection tracking e al natting:
• ip conntrack ftp - ip nat ftp : Conntrack e nat per FTP
• ip conntrack h323 - ip nat h323 : Conntrack e nat per H323
• ip conntrack irc - ip nat irc : Conntrack e nat per IRC
• ip conntrack rtsp - ip nat rtsp : Conntrack e nat per IRC
• ip conntrack tftp - ip nat tftp : Conntrack e nat per TFTP
• ip conntrack rpc tcp : Conntrack per RPC
• ip conntrack rpc udp : Conntrack per RPC I moduli vanno caricati nel kernel con il comando:
$ modprobe
2.2.1 Un esempio con ftp
definiamo un client A ed un server ftp B ed iniziamo la connessione ftp con il comando:
$ftp B
Questo comando aprir`a una NUOVA (NEW) connessione verso il server B client A NEW Server B
---->
Per brevit`a salto tutti i passaggi di autenticazione e passo direttamente al download di un file:
$get file.tgz
Quando il client chiede al server di eseguire il download di un file, per IpTables,
questa `e una connessione di tipo ESTABLISHED. Nel caso di utilizzo di modalit` a
passiva, la porta di connessione del client `e la 20, ma la porta per il trasferimento
del file pu`o essere una qualsiasi dalla 1023 in poi. Essendo la connessione generata da
quella gi`a esistente di ftp, con stessa sorgente IP e stessa destinazione IP, per permettere
l’utilizzo della modalita passiva, dobbiamo usare lo stato RELATED.
2.3 Le tabelle e le catene 2 CENNI DI IPTABLES
2.3 Le tabelle e le catene
IpTables fornisce tre tabelle prestabilite, ognuna delle quali contiene delle catene pre- definite. Inizialmente tutte le catene sono vuote e hanno una politica che consente a tutti i pacchetti di passare liberamente attraverso le interfacce di rete. Le catene vanno poi modificate a seconda delle proprie esigenze. Le tabelle predefinite sono le seguenti:
• tabella filter
– filtra il traffico in ingresso,uscita e in transito – catene: INPUT, OUTPUT, FORWARD (Figura 1)
Per questo host?
Pacchetto in uscita
NO SI
Verso l’applicazione
INPUT
Dall’applicazione
OUTPUT
FORWARD Pacchetto
in ingresso
Figura 1: Funzionamento della tabella flter
• tabella nat: questa tabella `e responsabile dell’impostazione delle regole per la modifica degli indirizzi e porte dei pacchetti. Il primo pacchetto di una connes- sione passa attraverso questa tabella, e il risultato del passaggio del primo pac- chetto determina come tutti gli altri pacchetti della stessa connessione verranno modificati. La tabella nat contiene le seguenti catene predefinite:
– catena PREROUTING: passano attraverso questa catena i pacchetti in en- trata, il passaggio avviene prima che la locale tabella di routing venga consultata per effettuare l’instradamento. Essa `e usata per il NAT sulla destinazione o DNAT.
– catena POSTROUTING: passano attraverso questa catena i pacchetti in uscita dopo che la locale tabella di routing sia stata consultata. Usata per il NAT sulla sorgente o SNAT.
– catena OUTPUT: permette un DNAT limitato sui pacchetti generati local- mente.
• tabella mangle: questa tabella `e responsabile delle modifiche alle opzioni dei
pacchetti, come ad esempio quella che determina la qualit`a del servizio(TOS,
MARK, . . . ). Tutti i pacchetti passano attraverso questa tabella. Essa contiene
tutte le catene predefinite:
2 CENNI DI IPTABLES 2.4 Azioni
– catena PREROUTING: esamina tutti i pacchetti che in qualche modo en- trano nel sistema. Questo processo avviene prima che il routing decida se il pacchetto debba essere inoltrato (catena FORWARD) o se sia destinato al sistema. Viene utilizzata per manipolare l’header del pacchetto (catena INPUT).
– catena INPUT: tutti i pacchetti destinati al sistema passano per questa catena.
– catena FORWARD: tutti i pacchetti che vengono instradati dal sistema ma di cui il sistema non `e ne sorgente iniziale ne destinazione finale, passano per questa catena.
– catena OUTPUT: tutti i pacchetti generati dal sistema passano per questa catena.
– catena POSTROUTING: tutti i pacchetti che lasciano il sistema, sia quelli in OUTPUT sia quelli in FORWARD, passano poi per questa catena.
• tabella raw: utilizzata molto raramente e che viene invocata prima delle altre, ha lo scopo di evitare il connection tracking per quei pacchetti che, per una qualche ragione, non si vogliono filtrare in maniera stateful. Le catene previste per la tabella raw sono solo due:
– catena OUTPUT: in tale catena si andr`a ad operare sui pacchetti generati da processi locali.
– catena PREROUTING: in tale catena si andr`a, invece, ad operare sui pac- chetti provenienti da qualsiasi interfaccia di rete.
2.4 Azioni
Le azioni possibili da intraprendere per una determinata regola, si dividono in:
• ACCEPT ⇒ il pacchetto viene accettato;
• REJECT ⇒ il pacchetto viene rifiutato informando il mittente;
• DROP ⇒ il pacchetto viene completamente ignorato;
• RETURN ⇒ il pacchetto ritorna alla catena originale;
• una qualunque altra catena o funzione particolare come LOG,ULOG,. . . per la catena filter, o DNAT,SNAT,. . . per la catena nat, . . .
nel caso di azioni come LOG, l’azione pu`o non essere terminante
3e quindi continuare con la regola successiva.
3Un’azione `e considerata non terminante quando, un pacchetto che soddisfa una regola con obiet- tivo non terminante, invece di interromepere la valutazione delle regole, continua a essere confrontato con le regole successive.
3 CONFIGURAZIONE UTILIZZATA
3 Configurazione utilizzata
Grazie all’utilizzo di 3 macchine virtuali, `e stato possibile simulare un’architettura composta da 3 diversi reti.
1. Una rete dedicata alla intranet dove trovano posto le postazioni di lavoro;
2. la rete DMZ, che ospita i server con i servizi da fornire ai dipendenti e alla rete internet;
3. la rete pubblica, che simula la rete internet.
Le macchine virtuali sono state predisposte come da Figura 2 per simulare:
• i computer dei dipendenti;
• i server con i servizi (www, mail, ftp, . . . );
• il Firewall con la funzionalit`a NAT.
fw−intranet:eth1 172.16.1.1/24
fw−dmz: eth0 172.16.2.1/24
fw−pubblic: eth2 151.99.103.1/24 client: eth0
172.16.1.10/24
server: eth0 172.16.2.10/24
DMZ intranet
pubblic equinox: eth0:1
151.99.103.2/24
Figura 2: Diagramma delle reti
La macchina fisica ospitante le tre virtuali, far`a le veci degli utenti internet, e sar`a utilizzata per eseguire delle scansioni dei servizi aperti sul firewall e sulle macchine interne.
3.1 S.O. e pacchetti installati
Le tre macchine virtuali sono state installate con Debian. Gli unici pacchetti aggiunti
all’installazione minima standard, sono stati:
3 CONFIGURAZIONE UTILIZZATA 3.2 Piano d’indirizzamento
• tcpdump ⇒ (per l’analisi del traffico sulle interfacce di rete);
• vsftpd ⇒ come server ftp;
• sshd ⇒ come server SSH;
• lynx ⇒ come browser web/ftp testuale;
• nmap ⇒ per eseguire scansioni sulle porte;
• apache ⇒ come server web
3.2 Piano d’indirizzamento
Per la macchina virtuale che simula la rete dei servizi, come quella dei dipendenti, `e stato predisposto un piano di indirizzamento standard con una sola scheda di rete (vedi tabella 1). Per il firewall si `e utilizzata una configurazione con tre schede di rete, una per la rete dei dipendenti, una per la rete dei servizi, ed infine l’ultima a simulare un collegamento con la rete internet (tabella 2). Il firewall utilizza come default gateway la macchina fisica, e conseguentemente, la macchina fisica `e configurata per utilizzare l’indirizzo pubblico del firewall come default gateway.
(a) Server
server eth0 IP 172.16.2.10 netmask 255.255.255.0
gateway 172.16.2.1
(b) Client
client eth0 IP 172.16.1.10 netmask 255.255.255.0
gateway 172.16.1.1 Tabella 1: Tabelle Server Client
Tabella 2: Firewall
firewall eth0 eth1 eth2
IP 172.168.2.1 172.168.1.1 151.99.103.1 netmask 255.255.255.0 255.255.255.0 255.255.255.0
default gw 151.99.103.2
4 REQUISITI DELLA RETE
4 requisiti della rete
Analizzando i bisogni di ogni computer o classi di computer connessi ad una rete, si `e in grado di definire delle regole base per il firewall, in modo da consentire solo il traffico lecito da e verso una certa rete. Per fare questo, dobbiamo analizzare ogni singola rete e capire che tipo di traffico viene generato e la sua destinazione. Le analisi seguenti saranno improntate ad analizzare solo il traffico in uscita dalle singole reti. L’unione di tutte le tabelle ci dar`a modo di capire quale tipo di traffico dovr`a essere permesso, andando poi a negare completamente tutto ci`o che non `e stato esplicitato.
4.1 intranet
Dalla rete intranet (tabella 3) verso la rete DMZ, dovr`a essere possibile raggiungere i siti web intranet ed internet, spedire e ricevere la posta, utilizzare un ftp, e accedere al dns. Dalla rete intranet si deve anche poter arrivare su qualsiasi server www della rete internet
4. Da questa specifica si ricava la tabella 3.
Tabella 3: Intranet
Source Destination Protocoll Rule
eth1 eth0 http allow
eth1 eth0 ftp-data allow
eth1 eth0 ftp allow
eth1 eth0 smtp allow
eth1 eth0 pop3 allow
eth1 eth0 dns allow
eth1 eth2 http allow
4.2 DMZ
La rete DMZ (tabella 4) per una corretta funzionalit`a della posta, dovr`a fare delle connessioni smtp verso server di posta sulla rete internet. Per il corretto funzionamento dei dns, gli stessi dovranno essere abilitati ad instaurare delle connessioni di tipo dns verso server dns della rete internet.
Tabella 4: DMZ
Source Destination Protocoll Rule
eth0 eth2 smtp allow
eth0 eth2 dns allow
4Per questo tipo di funzionalit`a `e necessario prevedere la funzionalit`a di MASQUERADE
4 REQUISITI DELLA RETE 4.3 Internet
4.3 Internet
Dalla rete pubblica (tabella 5) non dovr`a essere possibile raggiungere alcun computer o apparato, localizzato nella rete intranet. Si dovranno solamente raggiungere i server web e ftp, i server di posta e i dns, con gli opportuni protocolli, localizzati nella rete DMZ.
Tabella 5: Pubblic
Source Destination Protocoll Rule
eth2 eth0 http allow
eth2 eth0 smtp allow
eth2 eth0 dns allow
eth2 eth0 ftp allow
eth2 eth0 ftp-data allow
4.4 Conclusioni sulle regole
Dai requisiti delle singole reti si pu`o arrivare a definire una tabella (tabella 6) com- prensiva di tutte le regole del traffico permesso da e verso una certa rete.
Tabella 6: Regole complessive
Source Destination Protocoll Rule
eth1 eth0 http allow
eth1 eth0 ftp-data allow
eth1 eth0 ftp allow
eth1 eth0 smtp allow
eth1 eth0 pop3 allow
eth1 eth0 dns allow
eth1 eth2 http allow
eth0 eth2 smtp allow
eth0 eth2 dns allow
eth2 eth0 http allow
eth2 eth0 smtp allow
eth2 eth0 dns allow
eth2 eth0 ftp allow
eth2 eth0 fftp-data allow
5 IMPLEMENTAZIONE
5 Implementazione
5.1 Impostiamo l’ip forward
Per poter utilizzare la catena FORWARD `e necessario che lo strato software del sistema operativo che gestisce le connessioni, sia abilitato a far transitare i pacchetti da una interfaccia ad un altra. Le impostazioni possono essere effettuate on the fly
5intervenendo sul file:
/proc/sys/net/ipv4/ip_forward
Questo flag `e utilizzato dal sistema operativo come un flag per sapere il comportamento da intraprendere nel caso che un pacchetto in arrivo da un’interfaccia, debba uscire per un’altra. Va impostato a 1 per abilitare il forward ed a 0 per disabilitarlo.
5.2 Blocchiamo tutto il traffico
Sul firewall impostiamo le azioni di default per le catene della tabella filter
6.
$ iptables -t filter P INPUT DROP
$ iptables -t filter P OUTPUT DROP
$ iptables -t filter P FORWARD DROP
5.3 da Intranet a Pubblic
Impostiamo la funzionalit`a di MASQUERADE in uscita sull’interfaccia eth2 (pub- blica) con il comando
$ iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE
Abilitamo la navigazione internet da parte dei client sulla rete intranet. Per questa regola che comprende le porte 80 (hhtp) e 443 (https), possiamo utilizzare l’attributo multiport che permette di specificare in una sola regola pi` u porte. Dobbiamo anche abilitare il traffico di ritorno utilizzando l’attributo state.
$ iptables -A FORWARD -i eth1 -o eth2 -p tcp -m multiport --dports 80,443 -j ACCEPT
$ iptables -A FORWARD -i eth2 -o eth1 -m state --state ESTABLISHED -j ACCEPT
Ogni altro tipo di traffico verso internet verr` a DROPPATO dalla regola di default
5In realt`a questo comando andrebbe dato alla fine della configurazione del firewall, per evitare che il firewall venga utilizzato maliziosamente in corso di configurazione
6Di default, se omessa la tabella nelle regole, viene considerata sempre la tabella filter. In questo caso per una pi`u facile lettura viene sempre indicata la tabella di appartenenza
5 IMPLEMENTAZIONE 5.4 da Intranet a DMZ
5.4 da Intranet a DMZ
Per permettere l’utilizzo di ftp
7, ricordiamoci di caricare sul kernel il modulo che con- sente il funzionamento in modalit`a stateful per il protocollo ftp, ip conntrack ftp, ed abilitare il traffico ESTABLISHED e RELATED dalla DMZ ⇒ intranet. Il protocollo dei DNS prevede anche pacchetti di tipo udp e quindi, in aggiunta alla regola con il multiport, dobbiamo inserire anche una regola che permetta il traffico di tipo domain utilizzando il protocollo udp.
$ modprobe ip_conntrack_ftp
$ iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
$ iptables -A FORWARD -i eth1 -o eth0 -p tcp -m multiport --dports 53,80,443,20,21,25,110 -j ACCEPT
$ iptables -A FORWARD -i eth1 -o eth0 -p udp --dport 53 -j ACCEPT
5.5 da Internet (pubblic) a DMZ
Per questa funzionalit`a non dobbiamo dimenticarci di eseguire il nat tra l’indirizzo pubblico del firewall e l’indirizzo interno delle macchine con i servizi da pubblicare.
Parlando del server web, e quindi delle porte 80 e 443, la regola che andremo ad inse- rire andr`a a sostituire l’indirizzo ip pubblico del destinatario con l’indirizzo ip privato del server web, se e solo se il pacchetto `e diretto all’indirizzo pubblico del firewall e destinato alle porte 80 e 443. La regola andr`a inserita nella catena PREROUTING della tabella nat, e quindi, prima di applicare le tabelle di routing, il pacchetto viene trasformato e poi con il nuovo destinatario, si applicano le politiche di routing. Bi- sogna fare ancora un po’ di attenzione, perch`e in questo modo non stiamo evitando che un pacchetto destinato all’indirizzo privato del server web, transiti dall’interfaccia pubblica del firewall. Nella realt`a `e un po’ difficile che questo succeda
8, in quanto, il router che ci connette ad internet filtra tutti i pacchetti con indirizzi privati, ma, dal momento che la sicurezza aumenta all’aumentare del grado di paranoia del network administrator, aggiungere una regola che scarti tutti i pacchetti provvenienti dall’in- terfaccia pubblica del firewall e diretti verso un ip privato
9, della DMZ, ci far`a sentire pi` u tranquilli.
iptables -A FORWARD -i eth2 -o eth0 -m state --state NEW,ESTABLISHED, RELATED -j ACCEPT
iptables -A FORWARD -i eth0 -o eth2 -m state --state ESTABLISHED, RELATED -j ACCEPT
iptables -t nat -A PREROUTING -p tcp -i eth2 -d 151.99.103.1 --dport 80 -j DNAT --to-destination 172.16.2.10
7Se si volesse far utilizzare l’ftp in modalit`a passiva, avremmo dovuto impostare una regola del tipo: da eth1 a eth0 stato ESTABLISHED,RELATED ACCEPT
8Pu`o succedere che il nostro router venga compromesso e, da quella posizione, da noi considerata sicura, si potrebbero sferrare degli attacchi alle nostre macchine
9in realt`a ci sarebbero anche altre classi d’indirizzi da filtrare che ho omesso volutamente per non appesantire il tutto
5.6 Salvare le regole 5 IMPLEMENTAZIONE
Ora blocchiamo tutto il traffico diretto un qualsiasi indirizzo privato e proveniente dall’interfaccia pubblica del firewall:
iptables -t nat -A PREROUTING -i eth2 -d 10.0.0.0/8 -j DROP iptables -t nat -A PREROUTING -i eth2 -d 172.16.0.0/12 -j DROP iptables -t nat -A PREROUTING -i eth2 -d 192.168.0.0/16 -j DROP
5.6 Salvare le regole
Tutto ci`o che `e stato fatto finora, verr`a perso al successivo riavvio della macchina.
Dobbiamo salvare le regole, per poi ripristinarle ai successivi riavvii della macchina.
Molto importante ai fini della sicurezza, `e attivare le regole prima che l’interfaccia di rete diventi attiva, per evitare qualsiasi tipo di connessioni non autorizzate durante la fase di start-up della macchina. IpTables ci viene in aiuto con i comandi:
$ iptables-save
$ iptables-restore
che ci consentono di utilizzare lo standard-out e lo standard-in per salvare e leggere le regole impostate. Nello specifico, iptables-save stampa a video le regole impostate in un formato comprensibile a iptables-restore, conseguentemente, iptables-restore legge le regole nel formato prodotto da iptables-save. ´ E quindi sufficiente, redirigere lo standard-out verso un file da far poi leggere come standard-in da iptables-restore.
Distribuzioni differenti di Linux, possono prevedere diversi sistemi per salvare e leggere le regole di iptables, ma fattore comune a tutte le distribuzioni, `e l’utilizzo di iptables- save e iptables-restore, fornito dal pacchetto iptables. Imparato l’uso dei comandi forniti da iptables, si `e in grado di salvare e ripristinare le regole in una qualsiasi distribuzione Linux. Salviamo le regole con il comando:
$ iptables-save > rule.txt e ripristiniamo con:
$ iptables-restore < rule.txt
questi comandi andranno inseriti in uno script, che verr`a eseguito prima della configu- razione dell’interfaccia di rete. Rimando ai vari System V
10di ogni distribuzione la ricerca di dove e come inserire i comandi per il save e restore di iptables. Nel paragrafo 8 ho inserito tutte le regole utilizzate fino ad ora, dove non si fa uso di iptables-save e iptables-restore. Questo per`o significa che saremo costretti a modificare lo script ogniqualvolta avessimo bisogno di cambiare le regole. Nello script ho anche inserito il modulo per consentire la modalit`a statefull per il protocollo ftp. Se si opta per l’uso dei comandi iptables-save e iptables-restore, ricordarsi di, utilizzando le giuste modalit`a, far caricare al kernel i moduli necessari al corretto funzionamento di iptables.
10UNIX System V, spesso abbreviato in System V, `e una versione del sistema operativo proprietario Unix
6 TEST E VERIFICHE FUNZIONALI
6 Test e verifiche funzionali
6.1 ip forward
Dalla macchina fisica, lanciare un ping verso l’ip 172.16.1.10. Se l’ip forward `e stato abilitato (sezione 5.1) si dovrebbe poter ricevere gli echo reply. Se cos`ı non fosse, ripetere il test dopo aver dato:
$ echo "1" > /proc/sys/net/ipv4/ip_forward
6.2 Verifica delle politiche di default(DROP)
Con un semplice ping dalla macchina fisica, verso il firewall o verso una delle macchine virtuali poste dietro il firewall, o anche dalla rete intranet verso la rete DMZ, verificare che regole impostate nella sezione 5.2 funzionino correttamente.
6.3 Il masquerating
dopo aver dato il comando per accettare qualsiasi pacchetto
11in forwarding, mettere la macchina fisica in sniffing
12sull’interfaccia pubblica (eth2) del firewall. Dalla macchina virtuale intranet lanciare un ping cos`ı formato:
$ ping 151.99.103.2
Dal tcpdump verificare che il risultato sia del tipo:
13172.16.1.10 > 151.99.103.2: ICMP echo request 151.99.103.2 > 172.16.1.10: ICMP echo reply
Si evince che sull’interfaccia della nostra macchina fisica sta arrivando una richiesta di ping con indirizzo ip sorgente privato. In un caso reale, questo tipo di pacchetto sarebbe stato bloccato dal primo router incontrato per arrivare su internet. Per fortuna non `e il nostro caso, e quindi possiamo verificare il corretto funzionamento dell’istru- zione vista in 5.3. Dopo l’abilitazione del MASQUERADE verificare che l’output sia il seguente:
151.99.103.1 > 151.99.103.2: ICMP echo request 151.99.103.2 > 151.99.103.1: ICMP echo reply
L’indirizzo, prima privato, `e ora nattato con quello pubblico del firewall, e la richiesta pu`o essere tranquillamente inoltrata verso la rete internet.
11un’alternativa pi`u sicura, `e quella di abilitare il solo icmp di tipo echo request con il comando:
iptables -A FORWARD -i eth1 -o eth2 -p icmp –icmp-type echo-request -j ACCEPT
12tcpdump -ni eth2 icmp
13ho omesso gli altri dati come il seq. number,. . .
6.4 Il NAT 7 CONCLUSIONI E SVILUPPI FUTURI
tcpdump -ni eth2 port 80 tcpdump -ni eth0 port 80 151.99.103.2.53910 ⇒ 151.99.103.1.80 151.99.103.2.53910 ⇒ 172.16.2.10.80 151.99.103.1.80 ⇒ 151.99.103.2.53910 172.16.2.10.80 ⇒ 151.99.103.2.53910 151.99.103.2.53910 ⇒ 151.99.103.1.80 151.99.103.2.53910 ⇒ 172.16.2.10.80 151.99.103.2.53910 ⇒ 151.99.103.1.80 151.99.103.2.53910 ⇒ 172.16.2.10.80 151.99.103.1.80 ⇒ 151.99.103.2.53910 172.16.2.10.80 ⇒ 151.99.103.2.53910
.. . .. .
Tabella 7: Confronto tra traffico in ingresso ed uscita
6.4 Il NAT
Per testare la corretta funzionalit`a del NAT, `e sufficiente sniffare
14il traffico sulle 2 interfacce del firewall, quella pubblica (eth2) e quella sulla DMZ (eth0), e verificare che la trasformazione del pacchetto funzioni correttamente. Il risultato atteso, in caso di una connessione http generata dalla macchina fisica e diretta verso l’ip del firewall porta 80 `e come da tabella
157. ´ E facilemente verificabile che sull’interfaccia pubblica (eth2) transitano solo pacchetti validi per quel segmento di rete, mentre nella parte DMZ (privata), il pacchetto `e stato trasformato per poter raggiungere il servizio richiesto sulla porta 80 del server con IP privato. Questo tipo di configurazione ci d`a la possibilit`a di non sprecare indirizzi pubblici, ma di utilizzare un solo IP per poi fare un NAT verso gli ip privati dei servizi che vogliamo mettere a disposizione, purch´e i servizi utilizzino differenti porte. Se ad esempio avessimo 2 server http nella nostra DMZ, tutti e due starebbero in ascolto sulla porta 80 e questo ci impedirebbe di discriminare, attraverso l’uso della porta, su quale dei due server poter indirizzare le richieste.
6.5 test con nmap
Grazie al tool nmap siamo in grado di verificare velocemete quali porte si rendono di- sponibili sulle nostre macchine e per ogni rete. Rimando al manuale di nmap
16l’utilizzo dello stesso. Nel frattempo ci limiteremo solo a verificare che nessuna macchina con ip privato, sia raggiungibile dall’esterno, e che le porte aperte sull’interfaccia pubblica del firewall, siano le sole nattate ai servizi interni.
7 Conclusioni e sviluppi futuri
Il firewall `e sicuramente migliorabile, e non completamente esaustivo sul piano della sicurezza di rete. ´ E per`o una base sufficiente a capire il funzionamento di un tool tanto potente quanto complicato come IpTables. Non sarebbe male, ad esempio, attivare il log su tutte le nuove connessioni di tipo SSH, o bloccare tutti i port scanner di tipo un po’ anomalo come quelli che utilizzano i flag tcp (SYN,ACK,FIN,RST), . . . .
14tcpdump -ni eth2 port 80, tcpdump -ni eth0 port 80
15ometto volutamente tutte le informazioni non neccessarie alla comprensione della regola
16nmap –help
