1

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

2

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)

3

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

4

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

5

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

6

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)

7

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

8

UntrustedNetwork

FirewallFirewall DMZDMZ

Rete InternaRete Interna

Rete Esterna www

SMTP

9

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

10

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

• Stack– Argomenti delle funzioni, indirizzo istruzione di ritorno, variabili locali,

…..• 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”

Stack

Heap

Data

Codice

11

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)

12

TCP 3-way handshakingclient server

SYN (SEQ = x)

(SEQ = x+1, ACK = Y+1)

SYN (SEQ = Y , ACK = x+1)

13

LISTEN

SYN/SYN+ACK

SYN RCVD

ESTABLISHED

ACK/-TIMEOUT

CLOSED

RST/_

Macchina a stati finiti del server (vista parziale)

14

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

15

Sequenza di SYN floodclient server

[Other] SYN

RST

SYN + ACK

other

[Other] ACK (predice ISN)

16

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;

17

Route TableNetwork Interface151.10.0.0/16 S1198.14.32.0/24 S0204.1.16.0/24 E0

Check RPF che fallisce

Pacchetto arrivato da una interfaccia sbagliata (verrà scartato)

E0S1

S0

S2

Pacchetto con IP sorgente 151.10.3.21

X

18

Check RPF che ha successo

Route TableNetwork Interface151.10.0.0/16 S1198.14.32.0/24 S0204.1.16.0/24 E0

E0S1

S0

S2

Il pacchetto arriva dall’interfaccia corretta e viene inoltrato all’interfaccia di destinazione

Pacchetto con IP sorgente 151.10.3.21

19

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

20

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

21

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

22

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.

23

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

24

SNAT

NAT BPublic network

.1 171.69.58.60

A1 .120

10.0.0.120 B

SRC_ADDR DST_ADDR1

NAT 82.160.1.1 B2

B 82.160.1.13

B 10.0.0.1204

10.0.0.0/2482.160.1.1

NAT

25

DNAT

BPublic network

171.6.1.1

A .1

A 171.6.1.1.

SRC_ADDR DST_ADDR1

NAT A 10.1.1.1002

10.1.1.100 A3

171.6.1.1 A4

82.160.1.0/24

NAT

FW

10.1.1.0/24

.100

26

IPTABLES (vista semplificata)Riceve un pacchetto

PREROUTING (dnat)

routing

Processo locale

filter

FORWARD

filter

INPUT

POSTROUTING (snat)

Processo locale

filter

OUTPUT

POSTROUTING

(snat)

Pacchetti ricevuti dal fw e destinati a processi interni (e.g. ho un web server sulla stesso server del fw)

Pacchetti che attraversano il fw (e.g. dalla rete trusted alla rete untrusted, dalla rete untrusted alla DMZ)

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)

routing

27

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

28

ESTABLISHED (traffico TCP)client server

SYN

SYN / ACK

Firewall

NEW

ESTABLISHEDFIN

ACK

ACK

FIN

CLOSED

29

ESTABLISHED (traffico UDP)client server

UDP packet

UDP packet

Firewall

NEW

ESTABLISHED

Timeout t1 (30s)

Timeout t2 > t1 (180s)

t2

CLOSED

30

ESTABLISHED (traffico ICMP)client server

ICMP Echo request

ICMP Echo replay

Firewall

NEW

ESTABLISHED

Timeout t (30s)

CLOSED

31

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

32

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

33

Client Server

SYN

ACK

SYN / ACK

Active FTP

Dati

1027

Cmd

1026

Dati

20

Cmd

21

“FTP port 1027”

“FTP OK”

SYN (se Client è dietro un firewall, è un tentativo di apertura di sessione dall’esterno!)

ACK

SYN / ACK

34

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

35

Stato RELATED (caso active FTP)

SYN

SYN/ACK

Firewall

RELATED

ESTABLISHED

Dati

1027

Cmd

1026

ServerDati

20

Cmd

21

Client

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

36

Client Server

SYN

ACK

SYN / ACK

Passive FTP

Dati

1027

Cmd

1026

Dati

2024

Cmd

21

“PASV”

“PORT 2024”

SYN (se il Server è dietro un firewall, è un tentativo di apertura di sessione verso porta effimera)

ACK

SYN / ACK

37

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

38

Stato RELATED (caso passive FTP)

SYN

SYN/ACK

Firewall

RELATED

ESTABLISHED

Dati

1027

Cmd

1026

ServerDati

2024

Cmd

21

Client

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

39

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 …..

40

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

41

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”

42

• 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

Accetto il traffico proveniente dall’esterno se è relativo a connessioni originate dall’interno

43

• 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

Lascio aperto l’SSH quando è originato da un indirizzo noto

44

Configurazione firewall con DMZ

FirewallFirewall

DMZDMZ

Rete InternaRete Interna

Rete Esterna www

DNS

INET_IP

DNS_IP

HTTP_IP

INET_IFACE

LAN_IP

LAN_IFACE

DMZ_HTTP_IP

DMZ_DNS_IPDMZ_IP

DMZ_IFACE

45

Configurazione firewall con DMZ (1/3)• Filter table

– PolicyIPTABLES -P INPUT DROP IPTABLES -P OUTPUT DROP IPTABLES -P FORWARD DROP

- Forward1. IPTABLES -A FORWARD -i $DMZ_IFACE -o $INET_IFACE -j ACCEPT2. 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

3. IPTABLES -A FORWARD -i $LAN_IFACE -o $DMZ_IFACE -j ACCEPT4. -m state --state ESTABLISHED,RELATED -j ACCEPT5. IPTABLES -A FORWARD -i $LAN_IFACE -o $INET_IFACE -j ACCEPT6. 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 più alto solo se la stream è originato dall’interno

46

Configurazione firewall con DMZ (2/3)- Forward …continua

7. IPTABLES -A FORWARD -p TCP -i $INET_IFACE -o $DMZ_IFACE -d $DMZ_HTTP_IP --dport 80 –j ACCEPT

8. 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

47

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)

- POSTROUTING15. 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

48

Raggiungibilità dall’interno dei servizi pubblicati (1/2)

FirewallFirewall

Rete InternaRete Interna

Rete Esterna

www

INET_IP

INET_IFACE

LAN_IP

LAN_IFACE

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

HTTP_IPX

49

Raggiungibilità dall’interno dei servizi pubblicati (2/2)

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)

FirewallFirewall

Rete EsternaINET_IP

INET_IFACE

LAN_IP

LAN_IFACE

Xwww

HTTP_IP

50

#policyiptables –P INPUT DROPiptables –P OUTPUT DROPiptables –P FORWARD DROP

# 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

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

Rete interna

51

[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

Le regole sono sbagliate !

52

# 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 in alcun conto chi ha originato per primo la connessione

Riscriviamo le regole

53

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

Riscriviamo ancora le regole

54

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

Riscriviamo per l’ultima volta le regole