Esercizi Processing.pdf - the Netgroup at Politecnico di Torino

Politecnico di Torino
Corso di Tecnologie per Reti di Calcolatori
Esercizi di riepilogo: Processamento di
traffico
Fulvio Risso
October 17, 2009

Contents
I. Esercizi 3
0.1. Definizione dell’architettura di un firewall di livello applicativo . . . . . . 4
0.2. Definizione dell’architettura di un load-balancer di livello applicativo . . . 4
II. Soluzioni 5
0.3. Definizione dell’architettura di un firewall di livello applicativo . . . . . . 6
0.4. Definizione dell’architettura di un load-balancer di livello applicativo . . . 8
2

Part I.
Esercizi
3

0.1. Definizione dell’architettura di un firewall di livello
applicativo
Si progetti l’architettura generale di un firewall a livello applicativo, caratterizzato dalla
capacità di payload inspection e in grado di boccare determinate sessioni in base ad un
database di signature. Si consideri che l’analisi avvenga solamente su base pacchetto,
pertanto non è richiesto un modulo di riassemblaggio dei flussi TCP. Si richiede tuttavia
che il modulo di session tracking (la “session table”) sia implementato attraverso una
memoria CAM, con l’opportuna logica aggiuntiva per la gestione delle sessioni.
Si descrivano inoltre il funzionamento e le interazioni tra i vari blocchi.
0.2. Definizione dell’architettura di un load-balancer di livello
applicativo
Si progetti l’architettura generale di un load-balancer a livello applicativo per un webserver,
che sia in grado di dirottare il traffico ai vari server reali attraverso l’analisi
dell’URL contenuta nel pacchetto di richiesta HTTP.
Si descrivano inoltre il funzionamento e le interazioni tra i vari blocchi.
4

Part II.
Soluzioni
5

0.3. Definizione dell’architettura di un firewall di livello
applicativo
La soluzione può essere schematizzata come segue.
Control plane
Session
cleanup
daemon
Header
parser
Hit Trusted /
Hit NoTrusted /
Nohit
Session Table
SessionID, TS,
SessionStatus
Signature
DB
RegEx
engine
Slow path
Fast path
Dropper
All’arrivo di un pacchetto vengono estratti gli header significativi (la 5-tupla) che
vengono utilizzati come chiave di ingresso per la Session Table. Questa tabella (implementabile
da una CAM) viene utilizzata per memorizzare una informazione ternaria,
ossia vi possono essere tre possibili output a fronte di un match:
• la sessione è presente nella tabella, è già stata controllata ed è risultata ammissibile
[Hit Trusted]
• la sessione è presente nella tabella, è già stata controllata e non è risultata ammissibile
[Hit NoTrusted]
• la sessione non è presente nella tabella [No Hit]
Questo risultato determina il percorso del pacchetto a seguire:
• nel primo caso viene selezionato il “fast path” e il pacchetto viene inviato in uscita
6

• nel secondo caso viene selezionato il blocco “Dropper” e il pacchetto non viene
fatto proseguire
• nel terzo caso viene selezionato lo “slow path” e il pacchetto viene esaminato dal
motore di espressioni regolari.
Nel terzo caso, si possono ulteriormente verificare tre condizioni:
• se il pacchetto soddisfa una delle regular expression che indica un possibile attacco
di sicurezza, quel determinato SessionID viene aggiunto alla Session Table e il
campo SessionStatus viene impostato ad un valore che indica che la sessione è
malevola (in modo che i pacchetti successivi possano essere scartati)
• se il pacchetto non soddisfa alcuna regular expression, il pacchetto appartiene ad
una sessione “benevola”; in questo caso quel determinato SessionID viene aggiunto
alla Session Table con il campo SessionStatus impostato su “Trusted” (in modo
che i pacchetti successivi possano essere inoltrati alla destinazione)
• se il pacchetto non contiene payload (ad esempio è un TCP SYN), non viene
modificata la tabella delle sessioni e il pacchetto viene comunque lasciato proseguire
verso la destinazione.
Infine, è necessario risolvere il problema della gestione delle entry vecchie nella Session
Table.
Questo viene risolto dal seguente algoritmo:
• ogni volta che un pacchetto ottiene un match su una entry della SessionTable, viene
aggiornato un campo TimeStamp associato alla sessione stessa e che mantiene il
valore dell’istante nel quale è stato visto l’ultimo pacchetto di quella sessione
• periodicamente, un processo di background (Session Cleanup Daemon) scandisce
tutte le entries della Session Table e cancella tutte le sessioni che non hanno
prodotto traffico da più di X minuti (es. 5 min).
Questo processo viene eseguito in background e pertanto non ha la necessità di essere
particolarmente preciso come tempistiche. Pertanto, può permettersi di accedere alla
Session Table solamente quando non ci sono pacchetti in ingresso, in modo da non
ostacolare il processamento del traffico di rete (con l’ovvia avvertenza che nel caso in cui
ci sia molto traffico è comunque necessario fermare il sistema per cancellare le entries
vecchie nella Session Table in modo da evitare il riempimento della stessa).
7

0.4. Definizione dell’architettura di un load-balancer di livello
applicativo
La soluzione può essere schematizzata come segue.
Session
cleanup
daemon
Header
parser
Session table
SessionID,
TS, ServerID
Server ID
Hit/
Nohit
DEMUX
Payload
selector
Payload/no
payload
RegEx
engine
Server ID
TCP
termination
TCP handshake
I pacchetti in ingresso vengono processati con l’estrazione della 5-tupla (Session ID),
che viene utilizzata come chiave di ingresso nella Session Table. Questa tabella mantiene
l’elenco delle sessioni già classificate e per le quali è già stato assegnato un particolare
server web nella lista di quelli disponibili.
Nel caso in cui la sessione sia già stata classificata, l’indicazione del ServerID (il particolare
server che dovrà ricevere quel pacchetto) viene utilizzata da un de multiplatore
(DEMUX) per inoltrare il pacchetto al server corretto. Nel caso in cui la sessione non
sia ancora stata classificata, il pacchetto viene fatto proseguire su un percorso interno al
load balancer nel quale viene prima controllato se il pacchetto contiene un payload.
In caso negativo, il pacchetto è probabilmente relativo ad un handshake relativo ad
una nuova sessione e pertanto il pacchetto viene inoltrato verso un modulo apposito in
grado di gestire la terminazione delle sessioni in arrivo rispondendo con gli opportuni
pacchetti TCP ai pacchetti in ingresso. Nel caso in cui il pacchetto contiene un payload,
viene esaminato dal motore di Regular Expression per determinare il server a cui dovrà
8

essere fatto proseguire, e verrà inoltrato verso il Demux che lo farà proseguire verso il
server corretto.
Un blocco di Session Cleanup incaricato del controllo periodico della validità delle
sessioni nella Session Table completa il disegno architetturale proposto.
Questa soluzione di massima lascia tuttavia scoperti alcuni dettagli (non di poco
conto):
• la gestione dell’handshake delle connessioni TCP sui server web (se l’handshake è
fatto inizialmente dal motore TCP Termination, deve essere previsto un meccanismo
appostito per poter inoltrare un pacchetto di una sessione già iniziata ad un
server reale)
• la cancellazione delle sessioni attive e di eventuali zombies che non sono riusciti a
completare la fase di handshake dal blocco TCP Termination
• non vengono gestite sessioni nelle quali la signature è spezzata su più pacchetti
(non è presente un blocco TCP Normalization)
• non vengono gestite sessioni HTTP persistenti, ossia il caso per cui nella stessa
sessione TCP vengano richiesti più oggetti http appartenenti a server diversi.
Lo studente è invitato a proporre delle soluzioni per questi casi.
9