Un modello integrato control-flow e data-flow per il rilevamento ...

Recommendations

Info

32 3. Un modello che integra control flow e data flow 1 #include 2 #define CONFIG "/etc/simpleserver.conf" 3 #define BUFSZ 1024 4 5 read_file(char *name, char *buf) { 6 fd = open(name, O_RDONLY); 7 read(fd, buf); 8 close(fd); 9 } 10 11 write_file(char *name, char *buf) { 12 fd = open(name, O_WRONLY); 13 write(fd, buf, len); 14 close(fd); 15 } 16 17 server_loop(struct config *cfg) 18 { 19 while (1) { 20 fd = accept_client(); 21 read_req(fd, req); 22 23 if (req->method == GET) { 24 read_file(req->file, tmpbuf); 25 send(fd, tmpbuf); 26 } 27 else if (req->method == PUT) { 28 recv(fd, tmpbuf); 29 write_file(req->file, tmpbuf); 30 break; 31 } 32 } 33 } 34 35 main(void) 36 { 37 read_file(CONFIG, configbuf); 38 cfg = parse_config(configbuf); 39 if(cfg->admin_wants_chroot) 40 chroot(cfg->chroot_jail); 41 42 server_loop(cfg); 43 } Figura 3.5: Programma per il secondo esempio.
3.1. Debolezze dei modelli esistenti 33 Il mancato apprendimento di informazioni utili relative ai parametri della open è legato alla numerosità dei casi che potrebbero presentarsi: un client infatti potrebbe, del tutto legittimamente, eseguire la PUT di un file che ha un nome non incontra- to durante il training e poi farne la GET. Non è ovviamente possibile segnalare un’intrusione ogni qualvolta si presenti questa situazione. Quello che l’IDS potrebbe però apprendere è dove i file richiesti sono ubicati. Supponendo che la root directory del server sia /srv, verrà appreso che il parametro di open deve essere un file nelle directory /srv oppure /etc. Questa informazione tuttavia non aiuta a capire se è stato tentato il download del file di configurazione. Se osserviamo il sorgente possiamo notare però che l’unico caso in cui è richiesto di aprire un file in /etc è quando il server viene lanciato, tramite la chiamata read file in main. In altre parole, se lo stack è [main.37|read_file.6|open] allora il file che viene passato alla open deve essere /etc/simpleserver.conf, mentre se lo stack è [main.42|server_loop.24|read_file.6|open] allora può essere aperto qualunque file stia in /srv. Se si costruisce il modello usando anche le informazioni sullo stack è molto semplice rilevare che queste condizioni valgano a runtime. 28 12 read open read 21 accept write 13 14 read close open 6 7 20 close 8 accept end Figura 3.6: FSA per il secondo esempio. read In questo caso naturalmente il comportamento illecito è stato consentito non da un errore da parte di chi ha creato il software e dunque da un bug, ma da parte di
Page 1: Università degli Studi di Udine Fa
Page 5 and 6: Ringraziamenti In questo percorso m
Page 7 and 8: Indice 1 Introduzione 1 1.1 Anomaly
Page 9 and 10: Elenco delle figure 1.1 Codice sema
Page 11 and 12: 1 Introduzione Dai tempi della “d
Page 13 and 14: 1.1. Anomaly detection e system cal
Page 15 and 16: 1.2. Obiettivo del lavoro 5 informa
Page 17 and 18: 1.3. Struttura della tesi 7 seconda
Page 19 and 20: 2 Modelli per l’anomaly detection
Page 21 and 22: 2.1. Modelli control flow 11 con un
Page 23 and 24: 2.1. Modelli control flow 13 • Vi
Page 25 and 26: 2.1. Modelli control flow 15 1 int
Page 27 and 28: 2.2. Modelli data flow 17 • se v
Page 29 and 30: 2.2. Modelli data flow 19 suo scopo
Page 31 and 32: 2.3. Discussione dei modelli studia
Page 33 and 34: 2.3. Discussione dei modelli studia
Page 35 and 36: 3 Un modello che integra control fl
Page 37 and 38: 3.1. Debolezze dei modelli esistent
Page 39 and 40: 3.1. Debolezze dei modelli esistent
Page 41: 3.1. Debolezze dei modelli esistent
Page 45 and 46: 3.2. Proposta 35 1 int main(void) 2
Page 47 and 48: 3.3. Costruzione del modello 37 mai
Page 49 and 50: 3.3. Costruzione del modello 39 Un
Page 51 and 52: 3.3. Costruzione del modello 41 Tra
Page 53 and 54: 3.3. Costruzione del modello 43 Par
Page 55 and 56: 3.3. Costruzione del modello 45 Tut
Page 57 and 58: 3.5. L’algoritmo per la verifica
Page 59 and 60: 3.5. L’algoritmo per la verifica
Page 61 and 62: 4 L’implementazione L’implement
Page 63 and 64: 4.2. Introduzione a DTrace 53 un ce
Page 65 and 66: 4.2. Introduzione a DTrace 55 1 sta
Page 67 and 68: 4.3. Implementazione del sistema 57
Page 69 and 70: 4.4. Costo computazionale del model
Page 71 and 72: 4.4. Costo computazionale del model
Page 73 and 74: 5 Conclusioni e sviluppi futuri La
Page 75 and 76: 5.2. Sviluppi futuri 65 5.2.1 L’u
Page 77 and 78: 5.2. Sviluppi futuri 67 sistemi. In
Page 79 and 80: Bibliografia [1] System V Applicati

Un modello integrato control-flow e data-flow per il rilevamento ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?