Esercizi di riepilogo: Processamento di traffico

Transcript

1 Politecnico di Torino Corso di Tecnologie per Reti di Calcolatori Esercizi di riepilogo: Processamento di traffico Fulvio Risso October 18, 2010

2 Contents I. Esercizi 3 1. Esercizi Definizione dell architettura di un firewall di livello applicativo Definizione dell architettura di un load-balancer di livello applicativo II. Soluzioni 5 2. Soluzioni Definizione dell architettura di un firewall di livello applicativo Definizione dell architettura di un load-balancer di livello applicativo

3 Part I. Esercizi 3

4 1. Esercizi 1.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 Definizione dell architettura di un load-balancer di livello applicativo Si progetti l architettura generale di un load-balancer a livello applicativo per un web-server, 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

5 Part II. Soluzioni 5

6 2. Soluzioni 2.1. 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] 6

7 Questo risultato determina il percorso del pacchetto a seguire: nel primo caso viene selezionato il fast path e il pacchetto viene inviato in uscita 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 T 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

8 2.2. 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 contienga un payload di livello applicativo, viene esaminato dal motore di Regular Expression per determinare il server a cui dovrà 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): 8

9 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