Intrusion Detection System
• Sistema di gestione della sicurezza che:
– Raccoglie informazioni al fine di individuare possibili
brecce nella sicurezza monitorando
• Configurazioni dei sistemi
• Attività degli utenti
• Riconoscimento di pattern di attacco
– Le informazioni possono essere raccolte:
• dalla rete e rilevano attacchi provenienti per esempio
dall’esterno
• dai sistemi e rilevano attività di applicazioni sospette
1
IDS
• Possono essere:
– Moduli sw che controllano applicazioni specifiche e
individuano pattern di attacco noti (e.g. modulo di
Apache server che analizza le query HTTP)
– Moduli sw che controllano server, per esempio
controllano cambi di configurazione, di file system,
etc..
– Sistemi di controllo della rete (principalmente firewall)
2
Firewall
• Separa la rete trusted dalla rete un-trusted
• Tipi di firewall
– Packet filter: applica delle regole ai singoli pacchetti
che vede transitare; per TCP può bloccare le richieste di
connessioni provenienti dalla rete esterna (tutti i SYN
provenienti dall’esterno vengono scartati), può
applicare delle regole sul numero della porta (e.g.
pacchetti provenienti dall’interno destinati alla porta 80
www sono accettati); per UDP non c’è modo di
controllare le conversazioni attive (non c’è
handshaking) o di applicare regole sull’indirizzo
sorgente (UDP è facilmente “spoofabile”)
– Stateful: mantiene lo stato delle conversazioni e
applica regole anche in funzione di esso; ad esempio,
può decidere di accettare pacchetti dall’esterno solo se
le conversazioni sono iniziate dall’interno
3
Non basta il NAT ?
• Il NAT impedisce l’accesso dall’esterno alla rete
interna
• Non ha intelligenza per capire se ci sono attacchi
• Non consente di controllare il tipo di traffico da
inside verso outside
• Una volta aperta una connessione verso un host
interno se questo host diventa vittima di un attacco
può essere a sua volta utilizzato per attaccare tutti
gli altri host della LAN interna
4
Come gestire server della rete trusted che
devono essere raggiunti dall’esterno ?
• E.g. il server di posta SMTP che deve
ricevere mail da Internet, il sito web,…
• Soluzione: apro un “buco” sul firewall che
fa passare tutto il traffico proveniente
dall’esterno purchè sia destinato al server di
posta,….
• per essere più precisi: apro una porta sul
firewall che inoltra il traffico proveniente
dall’esterno destinato alla porta 25, al server
di posta
5
Cosa può succedere se c’è un “buco”
• E’ vero che il traffico proveniente dall’esterno può
andare solo verso la porta 25 del server SMTP o la
80 del web server ma: i software che girano su
queste macchine possono essere attaccabili
• Sfruttando la “Vulnerability” di un’applicazione
si può prendere il controllo della macchina e a
quel punto può fare quello che vuole sulla
macchina stessa, o attaccare la rete interna (il
firewall non ha modo di accorgersene)
6
Soluzione
• Non usare la stessa LAN per i server interni e quelli che
devono esporre servizi verso l’esterno
• Mettere i server che devono essere raggiunti dall’esterno in
una zona speciale aperta
• Questa zona è chiamata DMZ (DeMilitarised Zone); si
possono avere anche più livelli di DMZ
• Gli utenti esterni possono accedere alla DMZ ma non alla
rete interna
• Ovviamente, bisogna fare attenzione al traffico che facciamo
passare dalla DMZ alla rete interna: se un hacker prende il
controllo del server sulla DMZ non deve poter entrare sulla
rete interna
7
Untrusted
Network
Rete Esterna
www
Firewall
DMZ
SMTP
Rete Interna
8
Attacchi a livello applicativo e a livello rete
•
Vulnerabilità: errori del codice che generano comportamenti inattesi e che
possono causare la perdita di controllo della macchina:
– Buffer overflow (BOF)
• Si può cambiare l’indirizzo di ritorno dello stack cedendo il controllo ad un appropriato
modulo sw
– SQL injection
• Tipicamente uan form HTML che gestisce dati di input invoca una CGI alla pressione del
pulsante “SUBMIT” (e.g. QUERY STRING ?name=“mauro”&cognome=“rossi”)
• All’interno del CGI si accede al DB per estrarre modificare dati tramite SQL
• L’attaccante può inserire nel form dei comandi preceduti dal simbolo ‘ che possono
causare l’estrazione di dati riservati o peggio la modifica di dati
•
•
•
La vulnerabilità nasce dal mancato controllo dei dati di input (e.g. consente
l’uso di caratteri speciali, come ‘ )
Problema di qualità del codice
Firewall in questa situazione non può fare nulla in quanto l’accesso verso il
server avviene in modo lecito
•
Attacchi a livello rete:
– Attacchi di tipo DOS (Denial of Service): attacchi che consumano tutte le risorse
della macchina e che bloccano il servizio erogato dalla vittima impedendole di
rispondere a connessioni legittime (necessario reboot)
– Esempi: SYN flood, ICMP smurf
9
Vulnerabilità di un’applicazione (BOF)
• Struttura dati di un processo
– Codice
– Data: dati globali (inizializzati o no) dimensionata al momento
della compilazione
– Strutture allocate run time
Codice
Data
Stack
• Stack
– Argomenti delle funzioni, indirizzo istruzione di ritorno, variabili locali,
…..
Heap
• Heap
– Variabili dinamiche (viene allocata memoria con una chiamata NEW)
• Utilizzando opportuni parametri è possibile fare in modo
che l’indirizzo dell’istruzione di ritorno dello stack venga
riscritta; è sufficiente che una funzione contenga una
variabile locale e una funzione che scrive in memoria
senza fare check sui limiti
• In questo modo, all’uscita della funzione, può essere
eseguito del codice ” malicious”
10
Esempio SQL injection
• Supponiamo di avere una pagina web con un form in cui viene
chiesto di inserire in un form una user-name e una password e
si ricevono delle informazioni personalizzate
• Tipicamente nello script chiamato dal form potrebbe esserci un
comando del tipo SELECT * from certa_tabella where ID
=‘user-name’ and PASSWORD = ‘password’
• Utilizziamo user-name = pippo e come password pippo’ or
1=1 - -
• Il comando eseguito dallo script sarà:
– SELECT * from certa_tabella where ID =‘pippo’ and PASSWORD =
‘pippo’ or 1=1 - - ‘ (i caratteri che seguono – sono ignorati per cui
l’apostrofo finale non genera errori)
11
TCP 3-way handshaking
client
server
SYN (SEQ = x)
SYN (SEQ = Y , ACK = x+1)
(SEQ = x+1, ACK = Y+1)
12
Macchina a stati finiti del server (vista parziale)
CLOSED
LISTEN
SYN/SYN+ACK
RST/_
SYN RCVD
TIMEOUT
ACK/ESTABLISHED
13
Attacchi di tipo SYN flood
– Consiste nel generare un elevato numero di
SYN verso il server “vittima”
– Il server sotto attacco avrà un elevato numero di
“half-open connection”
– Per ognuna il server alloca risorse per gestire la
connessione:
• TCB (Transmission Control Block)
– Stato
– Window size
– Puntatori ricezione/trasmissione, RTT
– Esaurimento delle risorse sul server vittima
• Non accetta altre connessioni
• Crash del server
14
Sequenza di SYN flood
client
other
server
[Other] SYN
SYN + ACK
RST
[Other] ACK (predice ISN)
15
SYN flood
• Tipicamente SYN flood è abbinato all’IP spooffing con IP di host non
attivi o che non esistono (pertanto nessuno risponde alla SYN/ACK del
server)
• Contromisure possibili:
– Riduzione dello spoofing
• Blocco traffico uscente con source non della rete interna
• Blocco traffico entrante con source della rete interna
• Comunque non è possibile bloccare spoof dall’esterno con altri host esterni o
spoof dall’interno con altri indirizzi interni
• Soluzioni parziali:
– Drop half-open connection più vecchie, allungamento della coda per
gestire un numero maggiore di half-open connection, riduzione timeout
– Controllo provenienza IP per individuare pacchetti “spoofati”; se si riceve
un pacchetto IP da un interfaccia diversa da quella verso cui si invierebbe
un pacchetto destinato allo stesso host (Reverse Path Forwarding) si tratta
di un pacchetto malizioso;
16
Check RPF che fallisce
X
Pacchetto con
IP sorgente 151.10.3.21
S0
S1
Route Table
Network
151.10.0.0/16
198.14.32.0/24
204.1.16.0/24
S2
E0
Interface
S1
S0
E0
Pacchetto arrivato da una interfaccia
sbagliata (verrà scartato)
17
Check RPF che ha successo
Pacchetto con
IP sorgente 151.10.3.21
S0
S1
S2
E0
Route Table
Network
151.10.0.0/16
198.14.32.0/24
204.1.16.0/24
Interface
S1
S0
E0
Il pacchetto arriva dall’interfaccia
corretta e viene inoltrato
all’interfaccia di destinazione
18
SYN flood
• Firewall
– Detect della condizione di attacco con un qualche algoritmo
• limite max di SYN al secondo
• numero di connessioni nella stato SYN_RCVD
• Algoritmi sofisticati…….
– Una volta individuato un attacco si frappone tra rete e server
rispondendo ai SYN senza allocare risorse (e soprattutto senza
inoltrare i SYN al server sulla rete interna)
– Ulteriori prestazioni:
• Generazione di Initial Sequence Number non predicibile (evita ACK
non leggittime)
• SYN cookie (ISN proposta dal server contiene un cookie che è un
hash calcolato come funzione di una secret): consente di accettare
connessioni valide durante attacchi di flooding
19
ICMP smurf
• ICMP è utilizzato per vedere se un host è
presente/raggiungibile oppure no
• Un ping può essere destinato ad un host
specifico oppure all’indirizzo di broadcast
di una rete; in quest’ultimo caso il ping
raggiunge tutti gli host della rete
• Esempio: rete 10.0.0.0/8 ha come indirizzo
di broadcast 10.255.255.255
20
ICMP smurf
• L’host che esegue l’attacco invia un gran numero di ping (ICMP Echo
request) verso un indirizzo broadcast di una rete
• L’indirizzo sorgente di questi pacchetti è spufato con l’indirizzo IP
della vittima
• Il router che è connesso alla rete verso cui sono indirizzati i ping
effettua il broadcast a livello 2 dei ping
• Come risultato sul server vittima arriverà un volume di traffico ( ICMP
echo replay ) amplificato di un fattore pari al numero degli host
presenti sulla rete indirizzata con il ping
• Difesa: disabilitare l’inoltro di ICMP diretti ad indirizzi broadcast su
tutti i router/firewall
• Un server vittima praticamente non ha modo di difendersi da un simile
attacco in quanto il traffico ricevuto in ingresso può saturare
completamente la banda di accesso ad Internet
21
Port scanning (nmap)
• ICMP echo scanning: determina quali host sono attivi (non
le porte aperte); è possibile inviare ping a classi intere di
indirizzi
• (banale) l’host apre sessioni TCP verso una porta del
server vittima; se la sessione viene attivata significa che la
porta è disponibile
• TCP SYN scanning: apre solo half-connection; se riceve
SYN/ACK dall’host la porta è disponibile; se riceve RST
la porta è chiusa. Se si riceve SYN/ACK si risponde con
RST in modo da abbattere subito la connessione e non
essere tracciato. Se il server vittima è dietro un firewall,
possono essere loggate le SYN ricevute sulle varie porte
in modo da rintracciare l’host che fa scanning.
22
Port scanning
• TCP FIN scanning: inviando un FIN, se la porta è chiusa in
teoria si dovrebbe ricevere in risposta un RST, se la porta è
aperta il messaggio dovrebbe essere ignorato (dipende dai
sistemi operativi)
• TCP identity scanning: una volta stabilita la connessione è
possibile risalire al nome dello user owner del processo in
ascolto sul server
• Scanning UDP: più complesso perché non è previsto un
set up di una connessione e quindi dei messaggi di stato;
inoltre non c’è garanzia di consegna dei messaggi,
ritrasmissioni. Per determinare le porte UDP aperte si può
utilizzare una caratteristica di alcuni stack che inviano una
risposta ICMP_PORT_UNREACH quando ricevono
traffico verso una porta UDP chiusa
23
SNAT
10.0.0.0/24
82.160.1.1
.1
A1
SRC_ADDR
10.0.0.120
B
.120
171.69.58.60
Public
network
NAT
B
DST_ADDR
B
10.0.0.120
1
NAT
2
3
4
NAT
82.160.1.1
B
B
82.160.1.1
24
DNAT
10.1.1.0/24
82.160.1.0/24
A
.1
SRC_ADDR
171.6.1.1
Public
network
B
FW
.100
DST_ADDR
A
171.6.1.1.
171.6.1.1
A
1
2
A
NAT
4
NAT
3
10.1.1.100
10.1.1.100
A
25
IPTABLES (vista semplificata)
Riceve un
pacchetto
Processo locale
PREROUTING
(dnat)
routing
filter
routing
OUTPUT
POSTROUTING
filter
filter
INPUT
FORWARD
Processo locale
Pacchetti ricevuti dal fw e
destinati a processi interni
(e.g. ho un web server sulla
stesso server del fw)
POSTROUTING
(snat)
Pacchetti che attraversano il
fw (e.g. dalla rete trusted
alla rete untrusted, dalla
rete untrusted alla DMZ)
(snat)
Pacchetti che sono originati
dal server su cui risiede il fw
(e.g. uso il server del fw
anche come postazione di
lavoro ed effettuo un telnet,
una get http (web) verso la
rete un-trusted (internet)
26
Stati di IPTABLES
• Connessioni (protocollo, IP sorgente, porta sorgente, IP
destinazione, porta destinaziona, time-to-live, pacchetto di
risposta atteso)
• NEW
– Primo pacchetto visto per una data connessione
• ESTABLISHED
– Il firewall ha visto passare un pacchetto in entrambe le direzioni
– Non ha nulla a che vedere con lo stato previsto dal TCP; infatti il
firewall lo associa anche a flussi di dati UDP
• RELATED
– È in relazione ad una connessione già attiva
• INVALID
27
ESTABLISHED (traffico TCP)
Firewall
client
SYN
server
NEW
ESTABLISHED
SYN / ACK
FIN
ACK
FIN
ACK
CLOSED
28
ESTABLISHED (traffico UDP)
Firewall
client
server
Timeout t1 (30s)
UDP packet
NEW
Timeout t2 > t1 (180s)
ESTABLISHED
UDP packet
t2
CLOSED
29
ESTABLISHED (traffico ICMP)
client
Firewall
server
Timeout t (30s) ICMP Echo request
NEW
ICMP Echo replay ESTABLISHED
CLOSED
30
Gestione “bad packets”
• Ricezione di un pacchetto SYN/ACK nello
stato NEW
– REJECT (invio di un TCP reset)
• Ricezione di un pacchetto nello stato new
che non ha il bit SYN = 1
– DROP
31
FTP
• File Transfer Protocol
• Basato su TCP
• Utilizza una connessione di controllo (porta 21) e una
connessione per lo scambio dei dati
• Sulla sessione di controllo vengono scambiati i comandi
tra client e server
• Esistono due modi differenti per gestire la connessione
dati:
– FTP attivo
– FTP passivo
• Tipicamente i server FTP utilizzano la modalità passive
perché non crea problemi a clienti che utilizzano un
firewall
32
Active FTP
Client
Server
Dati
Cmd
Dati
Cmd
1027
1026
20
21
SYN
SYN / ACK
ACK
“FTP port 1027”
“FTP OK”
SYN (se Client è dietro un firewall, è un tentativo di
apertura di sessione dall’esterno!)
SYN / ACK
ACK
33
Configurazione dei firewall (FTP attivo)
• Firewall lato server:
– Accetta connessioni dall’esterno verso la porta 21 da
qualunque IP, porta > 1024
– Accetta connessioni aperte dall’interno dalla porta 20
verso qualunque IP, porta > 1024
• Firewall lato client:
– Deve gestire connessioni originate dall’esterno verso
porte effimere in modo dinamico in funzione dei dati
scambiati sulla sessione di controllo
34
Stato RELATED (caso active FTP)
Client
Dati
Cmd
1027
1026
Server
Firewall
Dati
Cmd
20
21
SYN
RELATED
SYN/ACK
ESTABLISHED
Il firewall lato cliente riconosce come
RELATED la connessione originata dall’esterno
verso la porta 1027 perché ha letto lo scambio di
messaggi sulla connessione di controllo
35
Passive FTP
Client
Server
Dati
Cmd
Dati
Cmd
1027
1026
2024
21
SYN
SYN / ACK
ACK
“PASV”
“PORT 2024”
SYN (se il Server è dietro un firewall, è un tentativo
di apertura di sessione verso porta effimera)
SYN / ACK
ACK
36
Configurazione dei firewall (FTP passivo)
• Firewall lato server:
– Accetta connessioni dall’esterno verso la porta
21 da qualunque IP, porta > 1024
– Accetta connessioni dall’esterno porta >1024
verso porte > 1024 !! ( a meno che non gestisca
lo stato RELATED
• Firewall lato client:
– Apre solo connessioni originate dall’interno
37
Stato RELATED (caso passive FTP)
Client
Server
Dati
Cmd
1027
1026
Firewall
Dati
Cmd
2024
21
SYN
RELATED
SYN/ACK
ESTABLISHED
Il firewall lato server riconosce come
RELAT la connessione originata dall’esterno
verso la porta 2024 perché ha letto lo
scambio di messaggi sulla connessione di
controllo
38
Configuriamo un firewall un passo per volta
• Sintassi utilizzata per aggiungere una regola:
IPTABLES –t TABLE –A CHAIN –[i|o] IFACE –s x.y.z.w –d
a.b.c.d –p PROT –m state --state STATE –j ACTION
TABLE = nat | filter | …
CHAIN = INPUT | OUTUP | FORWARD | PREROUTING|POSTROUTING
IFACE = eth0 | eth1 | ppp0
PROT = tcp | icmp | udp …..
STATE = NEW | ESTABLISHED | RELATED …..
ACTION = DROP | ACCEPT | REJECT | DNAT | SNAT …..
39
Regole di default (policy)
• IPTABLES –P INPUT DROP
• IPTABLES -P OUTPUT DROP
• IPTABLES -P FORWARD DROP
• Quando un pacchetto fa match con una regola e l’azione è
drop|reject viene immediatamente scartato
• se l’azione è accept passa alla catena successiva
•
se non fa match con nessuna regola vengono applicate le
regole di default
40
Blocco tutto il traffico proveniente dall’esterno
• Supponiamo sia eht0 l’interfaccia esterna
IPTABLES -A FORWARD -i eth0 -j DROP
Nota che i pacchetti vengono scartati in modo
silenzioso; non si forniscono messaggi in modo da
proteggersi in caso di attacchi “flooding” e da non
fornire informazioni in caso di attacchi basati su “port
scanning”
41
Accetto il traffico proveniente dall’esterno se è
relativo a connessioni originate dall’interno
• Supponiamo sia eht0 l’interfaccia esterna
IPTABLES -A FORWARD -i eth0 -m state --state
ESTABLISHED -j ACCEPT
Nota che si usa lo stato “ESTABLISHED” per usare il
connection tracking; lo stato ESTABLISHED non va
confuso con lo stato TCP, bensì per iptables è uno stato
in cui sono passati pacchetti tra due host in entrambe le
direzioni
42
Lascio aperto l’SSH quando è originato da un
indirizzo noto
• Supponiamo sia eht0 l’interfaccia esterna
IPTABLES -A INPUT -i eth0 -s 123.123.123.123 -p tcp -dport 22 -j ACCEPT
Nota: l’host 123.123.123.123 è l’unico autorizzato a fare
connessioni SSH dall’esterno; ovviamente a questo
punto la mia sicurezza dipende anche da questo
host: se qualcuno si impossessa dell’host
123.123.123.123 può entrare sulla mia rete interna
43
Configurazione firewall con DMZ
INET_IP
DNS_IP
HTTP_IP
INET_IFACE
Rete Esterna
Firewall
LAN_IP
LAN_IFACE
DMZ
DMZ_IP
DMZ_IFACE
www
DMZ_HTTP_IP
DNS
DMZ_DNS_IP
Rete Interna
44
Configurazione firewall con DMZ (1/3)
•
Filter table
–
Policy
IPTABLES -P INPUT DROP
IPTABLES -P OUTPUT DROP
IPTABLES -P FORWARD DROP
-
Forward
1.
2.
3.
4.
5.
6.
–
IPTABLES -A FORWARD -i $DMZ_IFACE -o $INET_IFACE -j ACCEPT
IPTABLES -A FORWARD -i $INET_IFACE -o $DMZ_IFACE -m state -state ESTABLISHED,RELATED -j IPTABLES -A FORWARD -i
$DMZ_IFACE -o $LAN_IFACE ACCEPT
IPTABLES -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j ACCEPT
-m state --state ESTABLISHED,RELATED -j ACCEPT
IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -j ACCEPT
IPTABLES -A FORWARD -i $INET_IFACE -o $LAN_IFACE -m state -state ESTABLISHED,RELATED -j ACCEPT
Regole generali: la 1, 3,5 permettono tutto il traffico in uscita verso una zona con
protezione più bassa; la 2,4,6 accettano il traffico verso zone con livello di protezione
45
più alto solo se la stream è originato dall’interno
Configurazione firewall con DMZ (2/3)
-
Forward …continua
7.
8.
IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d
$DMZ_HTTP_IP --dport 80 –j ACCEPT
IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d
$DMZ_HTTP_IP -j ACCEPT
9.
IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d
$DMZ_DNS_IP --dport 53 -j ACCEPT
10. IPTABLES -A FORWARD -p UDP -i $INET_IFACE -o $DMZ_IFACE -d
$DMZ_DNS_IP --dport 53 -j ACCEPT
11. IPTABLES -A FORWARD -p ICMP -i $INET_IFACE -o $DMZ_IFACE -d
$DMZ_DNS_IP -j ACCEPT
–
–
Regole specifiche per i server in DMZ: la 7, 8 sono relative al server web della DMZ e
abilitano il traffico proveniente dalla zona untrusted e destinato al web server (porta
tcp:80) o al processo ICMP (ping)
Le regole 9-11 sono relative al server DNS e sono del tutto analoghe
46
Configurazione firewall con DMZ (3/3)
-
PREROUTING
12. IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $HTTP_IP
dport 80 -j DNAT --to-destination $DMZ_HTTP_IP
13. IPTABLES -t nat -A PREROUTING -p TCP -i $INET_IFACE -d $DNS_IP -dport 53 -j DNAT --to-destination $DMZ_DNS_IP
14. IPTABLES -t nat -A PREROUTING -p UDP -i $INET_IFACE -d $DNS_IP -dport 53 -j DNAT --to-destination $DMZ_DNS_IP
–
Queste regole consentono di raggiungere gli host sulla rete DMZ (DNAT tra indirizzo
pubblico e indirizzo privato della DMZ del server web e del server DNS)
-
POSTROUTING
15. IPTABLES -t nat -A POSTROUTING –i LAN_IFACE -o $INET_IFACE -j
SNAT --to-source $INET_IP
–
Questa regola consente di avere uno stream da host con indirizzi privati della LAN
trusted; viene effettuato lo SNAT (N:1) verso l’indirizzo dell’interfaccia pubblica del
firewall
47
Raggiungibilità dall’interno dei servizi pubblicati (1/2)
INET_IP
INET_IFACE
Rete Esterna
Firewall
LAN_IP
LAN_IFACE
X
HTTP_IP
Rete Interna
www
iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT --to-destination
$HTTP_IP
1.
Parte un paccheto da X a INET_IP.
2.
Il firewall effettua DNAT; la sorgente resta X, la destinazione diventa HTTP_IP
3.
Il server HTTP risponde al pacchetto inviando una risposta con sorgente HTTP_IP e destinazione
X; poiché X è sulla stessa rete del server web il pacchetto è inviato direttamente
4.
Il pacchetto raggiunge X che lo scarterà (RST) perché si aspetta una risposta da INET_IP
48
RaggiungibilitàINET_IP
dall’interno dei servizi pubblicati (2/2)
Rete Esterna
INET_IFACE
Firewall
LAN_IP
LAN_IFACE
X
HTTP_IP
www
iptables -t nat -A PREROUTING --dst $INET_IP -p tcp --dport 80 -j DNAT --to-destination
$HTTP_IP
iptables -t nat -A POSTROUTING -p tcp --dst $HTTP_IP --dport 80 -j SNAT --to-source $LAN_IP
1.
Parte un paccheto da X a INET_IP.
2.
Il firewall effettua DNAT e SNAT; la sorgente diventa LAN_IP, la destinazione diventa
HTTP_IP
3.
Il server HTTP risponde inviando un pacchetto con sorgente HTTP_IP e destinazione LAN_IP;
il pacchetto ritorna al firewall
4.
Il firewall effettuerà il de-NAT del pacchetto che sarà spedito con sorgente INET_IP e
destinazione X (X riceverà correttamente il pacchetto)
49
Apriamo solo il traffico SMTP da e verso la nostra rete
locale
Ci poniamo l’obiettivo di:
Rendere accessibile dall’esterno il server SMTP sulla rete trusted
Aprire il traffico dalla rete trusted verso il server SMTP sulla rete
untrusted
#policy
iptables –P INPUT DROP
iptables –P OUTPUT DROP
iptables –P FORWARD DROP
Rete interna
# traffico da/per il server SMTP interno
[A] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 --dport 25 –j ACCEPT
[B] iptables -A FORWARD -o eth0 –p tcp –s 192.168.1.0/24 --dport 1024: –j
ACCEPT
# traffico da/per il server SMTP esterno
[C] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 --dport 1024: –j ACCEPT
[D] iptables -A FORWARD –o eth0 –p tcp –s 192.168.1.0/24 --dport 25 –j ACCEPT
50
Le regole sono sbagliate !
[A] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 --dport 25 –j ACCEPT
[B] iptables -A FORWARD -o eth0 –p tcp –s192.168.1.0/24 --dport 1024: –j ACCEPT
[C] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 --dport 1024: –j ACCEPT
[D] iptables -A FORWARD –o eth0 –p tcp –s 192.168.1.0/24 --dport 25 –j ACCEPT
Ho aperto le connessioni sugli host della rete interna purchè entrambe le porte
(origine e destinazione) siano nel range [1024,65535]; ad esempio:
212.121.13.4:1800 verso 192.168.1.1:1025
• il traffico in ingresso è conforme alla regola C
• il traffico in uscita è conforme alla regola B
Il primo errore commesso è stato non considerare nelle regole solo le porte
sorgente, oltre che quelle destinazione
51
Riscriviamo le regole
# traffico da/per il server SMTP interno
[A] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 --dport 25 --sport 1024: –j
ACCEPT
[B] iptables -A FORWARD -o eth0 –p tcp –s 192.168.1.0/24 --dport 1024: --sport 25 –j
ACCEPT
# traffico da/per il server SMTP esterno
[C] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 --dport 1024: --sport 25 –j
ACCEPT
[D] iptables -A FORWARD –o eth0 –p tcp –s 192.168.1.0/24 --dport 25 --sport 1024: –j
ACCEPT
Questa volta ho considerato le porte sorgente/destinazione ma ancora non basta; sono
possibili connessioni verso porte [1024-65535] degli host della rete interna purchè
l’host esterno usi la porta 25; il “buco” è creato dalle regole C/D,
Il problema di fondo è che la coppia di regole C/D è stata pensata per far uscire una
richiesta TCP verso un server SMTP esterno, SYN (regola D) e ricevere un
SYN+ACK dal server esterno (regola C); in realtà usando le regole nell’ordine
inverso ottengo uno scopo diverso: il motivo di ciò è che le regole non tengono
52 in
alcun conto chi ha originato per primo la connessione
Riscriviamo ancora le regole
La regola C può essere riscritta per impedire sessioni TCP originate (SYN) dall’esterno
[C] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 --dport 1024: --sport 25 –j
ACCEPT
diventa
[C] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 ! –syn --dport 1024: -sport 25 –j ACCEPT
L’esempio completo diventa:
# traffico da/per il server SMTP interno
[A] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 --dport 25 --sport 1024: –j ACCEPT
[B] iptables -A FORWARD -o eth0 –p tcp –s 192.168.1.0/24 --dport 1024: --sport 25 –j ACCEPT
# traffico da/per il server SMTP esterno
[C] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 ! –syn --dport 1024: --sport 25 –j
ACCEPT
[D] iptables -A FORWARD –o eth0 –p tcp –s 192.168.1.0/24 --dport 25 --sport 1024: –j ACCEPT
53
Riscriviamo per l’ultima volta le regole
Questa volta usiamo le proprietà stateful inspection e restringiamo al solo server di
posta la possibilità di ricevere connessioni sulla porta 25 dall’esterno; le regole ora
sono funzione anche dello stato: nell’esempio si usano gli stati NEW (primo
pacchetto che passa) e ESTABLISHED
[1] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.1 --dport 25 –m state --state
NEW,ESTABLISHED –j ACCEPT
[2] iptables -A FORWARD -i eth0 –p tcp –d 192.168.1.0/24 –m state – state
ESTABLISHED –j ACCEPT
[3] iptables -A FORWARD -o eth0 –p tcp --dport 25 –m state –state
NEW,ESTABLISHED –j ACCEPT
[4] iptables -A FORWARD -o eth0 –p tcp –m state –state ESTABLISHED –j ACCEPT
54