Claudio Telmon - Internet -1 © Claudio Telmon - 2000-2002 I firewall.

Presentazione sul tema: "Claudio Telmon - Internet -1 © Claudio Telmon - 2000-2002 I firewall."— Transcript della presentazione:

1 Claudio Telmon - Internet -1 © Claudio Telmon - 2000-2002 I firewall

2 Claudio Telmon - Internet -2 © Claudio Telmon - 2000-2002 Cos’è un firewall  Un firewall è un sistema, nel senso più ampio del termine, che ha lo scopo di controllare il traffico fra due o più reti:  permettendo solo quello autorizzato dalla politica di sicurezza  rilevando e segnalando eventuali tentativi di violazione della politica di sicurezza  svolgendo eventualmente funzioni aggiuntive di auditing e accounting

3 Claudio Telmon - Internet -3 © Claudio Telmon - 2000-2002 Perché installare un firewall  Per implementare una politica di sicurezza:  per permettere l’accesso ai sistemi o servizi di una rete protetta:  agli utenti autorizzati  ai sistemi autorizzati  per permettere agli utenti e sistemi di una rete protetta di accedere ai sistemi e servizi di una rete non protetta:  solo se il rischio è accettabile  registrando le attività

4 Claudio Telmon - Internet -4 © Claudio Telmon - 2000-2002 EsempioEsempio Firewall Servizi pubblici (Web, FTP…) Rete privata (rete interna, intranet) Extranet (server di progetto) Internet (rete esterna)

5 Claudio Telmon - Internet -5 © Claudio Telmon - 2000-2002 A quale livello può operare un firewall?  Livello IP  Livello TCP/UDP….  Protocollo applicativo/stateful filtering  Content inspection

6 Claudio Telmon - Internet -6 © Claudio Telmon - 2000-2002 VantaggiVantaggi  Centralizzazione della politica di sicurezza  Single point of failure (può essere uno svantaggio)  Gestione con personale competente  Sistema specializzato

7 Claudio Telmon - Internet -7 © Claudio Telmon - 2000-2002 SvantaggiSvantaggi  Difficoltà con protocolli non banali  Banda disponibile  firewall come pipeline  la percezione dell’utente  Gestione complessa  configurazione  verifica  analisi dei log  Senso di fiducia e insicurezza interna  Costi

8 Claudio Telmon - Internet -8 © Claudio Telmon - 2000-2002 Cosa un firewall non può fare “You can’t solve social problems with software” “You’re either part of the problem, or part of the solution” - M. J. Ranum

9 Claudio Telmon - Internet -9 © Claudio Telmon - 2000-2002 NATNAT  Non è un meccanismo di sicurezza (anche se c’è qualche vantaggio)  NAT statico: 1 IP interno 1IP esterno  NAT dinamico: pool di indirizzi esterni  Masquerade: 1 indirizzo esterno  Non c’è controllo del traffico sui singoli indirizzi  Senza specifiche ACL si accede comunque agli indirizzi interni

10 Claudio Telmon - Internet -10 © Claudio Telmon - 2000-2002 Un caso particolare: il masquerade  È il NAT in cui è disponibile un unico indirizzo pubblico  Richiede la rimappatura delle porte  comporta l’utilizzo di moduli specifici per i singoli protocolli, quando possbile  Con un opportuno filtraggio le macchine interne sono raggiungibili solo se aprono connessioni verso l’esterno  Non è utilizzabile per i server

11 Claudio Telmon - Internet -11 © Claudio Telmon - 2000-2002 Packet filtering

12 Claudio Telmon - Internet -12 © Claudio Telmon - 2000-2002 RouterRouter  È già presente e divide la rete da Internet  Meccanismo principale di protezione: ACL statiche (IOS 12.0: alcuni meccanismi dinamici)  Logging remoto  Accesso da console?  Protezioni non ridondanti

13 Claudio Telmon - Internet -13 © Claudio Telmon - 2000-2002 Router: vantaggi  Buone prestazioni  Trasparenza  Basso costo (ev. nullo)

14 Claudio Telmon - Internet -14 © Claudio Telmon - 2000-2002 Router: svantaggi  Nessuna autenticazione (Cisco IOS 12.0: alcuni meccanismi)  utente  indirizzo  ACL complesse  Alcuni protocolli non sono gestibili  Nessun controllo sui dati

15 Claudio Telmon - Internet -15 © Claudio Telmon - 2000-2002 Bastion Host Rete protetta Internet Bastion Host

16 Claudio Telmon - Internet -16 © Claudio Telmon - 2000-2002 Packet Filter  Meccanismi analoghi al router  Prestazioni peggiori  Peggiore controllo sul traffico (ev. ipfilter)  Maggiore pericolo di vulnerabilità per altri servizi  Comunque non gestisce alcuni servizi

17 Claudio Telmon - Internet -17 © Claudio Telmon - 2000-2002 Parametri di filtraggio  Header IP  mittente  destinatario  protocollo  flag, opzioni (source routing, frammentazione…)  Header TCP/UDP  porta mittente  porta destinataria  flag TCP (SYN, ACK)

18 Claudio Telmon - Internet -18 © Claudio Telmon - 2000-2002 Azioni possibili  Accettare il pacchetto  Scartare il pacchetto (non avvisa il mittente)  Rifiutare il pacchetto (avvisa il mittente, es. ICMP port unreachable)  NAT  Log (remoto?)  Filtri dinamici (controllati da IDS)  Default deny/default permit

19 Claudio Telmon - Internet -19 © Claudio Telmon - 2000-2002 Dove effettuare il filtraggio Firewall Rete interna 1 Internet (rete esterna) Rete interna 3 Rete interna 2 In ingresso so da quale interfaccia arriva il pacchetto proteggo il sistema locale In uscita gestisco anche il traffico generato localmente

20 Claudio Telmon - Internet -20 © Claudio Telmon - 2000-2002 Protezione dall’IP spoofing  Vogliamo evitare che:  possano essere “inseriti” pacchetti falsificati nella nostra rete  la nostra rete possa essere usata per inviare pacchetti falsificati  Antispoofing: si associano reti a interfacce  si scartano tutti i pacchetti con indirizzo locale non  si scartano tutti i pacchetti provenienti dall’interfaccia interna con indirizzo non locale  gestire anche il loopback

21 Claudio Telmon - Internet -21 © Claudio Telmon - 2000-2002 Direzione delle connessioni TCP  Volgiamo permettere che sia possibile connettersi  da (IP A.A.A.A, porta a) a (IP B.B.B.B,porta b)  Ma non  da (IP B.B.B.B,porta b) a (IP A.A.A.A, porta a)  Problema: e i pacchetti di risposta?  Soluzione: si scartano i pacchetti:  da (IP B.B.B.B,porta b) a (IP A.A.A.A, porta a)  con il solo flag SYN settato (senza il flag ACK)

22 Claudio Telmon - Internet -22 © Claudio Telmon - 2000-2002 IP fragmentation attack (1)  I router non conservano uno stato relativo ai frammenti/pacchetti che hanno gestito  Un pacchetto TCP su un pacchetto IP frammentato può avere le informazioni usate per il filtraggio nel primo frammento e il resto del pacchetto nel secondo  Il secondo frammento viene fatto passare

23 Claudio Telmon - Internet -23 © Claudio Telmon - 2000-2002 IP fragmentation attack(2)  Cosa succede se i due frammenti si sovrappongono?  Gli standard dicono che deve essere considerato il secondo frammento  Questo permette di sovrascrivere parte del pacchetto, ad esempio il flag SYN  Soluzioni:  mantenere uno stato  riassemblare i pacchetti  scartare i frammenti con offset piccolo

24 Claudio Telmon - Internet -24 © Claudio Telmon - 2000-2002 Gestione dei pacchetti ICMP  Il traffico ICMP non è necessario…  tranne per il PATH MTU discovery  è comunque utile per evitare rallentamenti  È opportuno scartare tutti i pacchetti ICMP non necessari?  Si eliminano alcuni possibili attacchi  Si rallenta la scoperta dei problemi, si rallentano le attività degli utenti  Comunque alcuni pacchetti devono passare  È opportuno scartare i pacchetti che forniscono informazioni

25 Claudio Telmon - Internet -25 © Claudio Telmon - 2000-2002 Un caso particolare: il servizio Auth/ident  Servizio di derivazione Unix, si basa sull’affidabilità di root su tutti i sistemi  Utilizzato dai server per “verificare” i client  Può fornire informazioni eccessive  È inutile ed è opportuno disabilitarlo  Scartare i pacchetti causa rallentamenti, quindi i pacchetti vanno rifiutati  Alcuni server non “capiscono” il pacchetto ICMP port unreachable al posto del RST

26 Claudio Telmon - Internet -26 © Claudio Telmon - 2000-2002 Regole di filtraggio (ipchains) pkts bytes target prot ifname source destination ports 271 56476 ACCEPT all lo 127.0.0.1 127.0.0.1 n/a 0 0 DENY all * 127.0.0.0/8 0.0.0.0/0 n/a 0 0 DENY all * 0.0.0.0/0 127.0.0.0/8 n/a 0 0 ACCEPT tcp eth0 0.0.0.0/0 192.168.1.2 * -> 21 0 0 ACCEPT tcp eth0 0.0.0.0/0 192.168.1.2 * -> 1024:65535 0 0 ACCEPT udp eth1 192.168.2.10 192.168.1.2 53 -> * 0 0 DENY tcp * 0.0.0.0/0 0.0.0.0/0 * -> 137:139 0 0 DENY udp * 0.0.0.0/0 0.0.0.0/0 * -> 137:139 0 0 REJECT tcp * 0.0.0.0/0 192.168.1.2 * -> 113

27 Claudio Telmon - Internet -27 © Claudio Telmon - 2000-2002 ChecklistChecklist  Antispoofing  Frammentazione  Loopback  Multicast  ICMP  Broadcast  Servizi

28 Claudio Telmon - Internet -28 © Claudio Telmon - 2000-2002 Proxy/Stateful filtering

29 Claudio Telmon - Internet -29 © Claudio Telmon - 2000-2002 I proxy ClientProxyServer Connesioneclient/proxyConnesioneproxy/server

30 Claudio Telmon - Internet -30 © Claudio Telmon - 2000-2002 I proxy  Ricevono la connessione dal client  Aprono una nuova connessione verso il server  Il traffico TCP/IP non passa direttamente da client a server

31 Claudio Telmon - Internet -31 © Claudio Telmon - 2000-2002 Vantaggi dei proxy  Il traffico non passa direttamente fra client e server  non sono possibili attacchi basati su TCP/IP  È immediato realizzare meccanismi per ispezionare i dati (meno banale capire cosa cercare)  Permettono di aggiungere meccanismi di autenticazione migliori/centralizzati  purché compatibili con il protocollo  oppure preventivamente per un indirizzo IP

32 Claudio Telmon - Internet -32 © Claudio Telmon - 2000-2002 Svantaggi dei proxy  Interferiscono maggiormente con il traffico  Difficoltà nella gestione dei livelli bassi dello stack:  keepalive  ping, traceroute…  Possono modificare l’indirizzo mittente delle connessioni  Richiedono un proxy per ogni protocollo…  È uno svantaggio?  Prestazioni

33 Claudio Telmon - Internet -33 © Claudio Telmon - 2000-2002 Proxy generici (Circuit Level Gateways)  Si limitano a passare da un lato all’altro del proxy i dati TCP/UDP  Permettono di gestire i protocolli che non fanno contrattazione dinamica di porte  Si limitano a evitare gli attacchi dei livelli bassi dello stack

34 Claudio Telmon - Internet -34 © Claudio Telmon - 2000-2002 Proxy specifici (Application Level Gateways)  Sono realizzati per la gestione di uno specifico protocollo, che quindi comprendono:  Possono gestire meccanismi di contrattazione di porte  Possono esaminare i dati trasmessi alla ricerca di attacchi o traffico non autorizzato (content inspection)  in pratica la maggior parte si limita alla correttezza del protocollo  Permettono un’autenticazione compatibile con il protocollo

35 Claudio Telmon - Internet -35 © Claudio Telmon - 2000-2002 Esempi di proxy specifici  Http:  filtraggio delle URL (client/server)  eliminazione del contenuto attivo (server/client)  meccanismi antivirus?  FTP:  riconoscimento del protocollo  limitazione dei comandi supportati  meccanismi antivirus?  Posta elettronica  filtraggio degli header interni  meccanismi antivirus?

36 Claudio Telmon - Internet -36 © Claudio Telmon - 2000-2002 Proxy trasparenti  L’uso di proxy richiede che la connessione avvenga tra client e proxy  Non tutti i protocolli supportano l’uso di proxy  Come comunicare l’informazione su indirizzo e porta del server?  Soluzione: il client crede di comunicare con il server, e la comunicazione viene intercettata dal proxy

37 Claudio Telmon - Internet -37 © Claudio Telmon - 2000-2002 Proxy trasparenti ClientServer TCP/IP Proxy

38 Claudio Telmon - Internet -38 © Claudio Telmon - 2000-2002 Proxy trasparenti  Richiedono la modifica nello stack TCP/IP  Le informazioni sul server sono prese direttamente dai pacchetti IP  Sono invisibili al client  possono essere usati con client generici  il client non può comunicare informazioni al proxy (porte su cui ascolta)  Hanno prestazioni analoghe a quelle dei proxy  Richiedono la risoluzione DNS da parte dei client

39 Claudio Telmon - Internet -39 © Claudio Telmon - 2000-2002 SocksSocks  È un protocollo che permette la comunicazione fra client e proxy di informazioni sulla connessione:  indirizzo e porta del server  autenticazione  porte su cui il client si mette in ascolto?  È un meccanismo molto versatile…  … purché il client supporti il protocollo  Non entra nel merito dei dati trasmessi  Si fida del client?

40 Claudio Telmon - Internet -40 © Claudio Telmon - 2000-2002 Stafeful packet filtering  Problemi del packet filtering:  i pacchetti sono selezionati in base a regole statiche  i pacchetti sono esaminati solo fino all’header TCP  Soluzione:  tenere uno stato sul packet filter  esaminare il contenuto dei pacchetti  Stateful packet filtering  gestione dei pacchetti associati a connessioni aperte  gestione della contrattazione di porte  content filtering

41 Claudio Telmon - Internet -41 © Claudio Telmon - 2000-2002 Stato delle connessioni  Cisco IOS 12.0 Reflexive ACL  Traffico TCP:  inizialmente le regole bloccano il traffico tranne alcuni pacchetti in uscita  quando passa un pacchetto TCP SYN viene dinamicamente attivata una regola che permette il traffico corrispondente in entrata  la regola viene eliminata dopo i FIN  Traffico UDP  dopo un pacchetto UDP in uscita viene attivata una regola che permette pacchetti entranti con le stesse porte  la regola viene tolta dopo un timeout

42 Claudio Telmon - Internet -42 © Claudio Telmon - 2000-2002 Stato delle connessioni  Altri protocolli?  ICMP  traffico non TCP/UDP  Content inspection?  nessun controllo (simile a proxy generici)  Es. attacco al server DNS:  mi connetto a un servizio autorizzato, o invio un pacchetto non autorizzato  i meccanismi di log si connettono al mio server  invio query o genero traffico a piacere  Gestisce FTP in modalità passive

43 Claudio Telmon - Internet -43 © Claudio Telmon - 2000-2002 Riconoscimento dei protocolli  Richiede l’esame del payload  Spesso può essere effettuato su singoli pacchetti  i comandi vengono inviati come singolo pacchetto…  … a meno di attacchi, o di casi particolari; che fare in questi casi? Assemblare più pacchetti…  Richiede la comprensione del protocollo  Richiede notevoli modifiche allo stack TCP/IP  Esempi: Checkpoint Firewall-1, Cisco IOS 12.0, Cisco PIX, iptables?

44 Claudio Telmon - Internet -44 © Claudio Telmon - 2000-2002 ACL su stateful packet filter  Basate su  utenti  sistemi  servizi  orari  Simili alle ACL dei packet filter  vale l’ordine delle regole  le azioni fondamentali sono accept, drop, reject  Funzionalità aggiuntive  autenticazione utente  analisi del contenuto (per alcuni protocolli)

45 Claudio Telmon - Internet -45 © Claudio Telmon - 2000-2002 EsempiEsempi

46 Claudio Telmon - Internet -46 © Claudio Telmon - 2000-2002 SPF e content inspection  L’esame dei dati di una sessione richiede l’esame di dati contenuti in più pacchetti  L’esame è complesso  Che fare dei pacchetti nel frattempo? (Se l’ACK non arriva, dopo un po’la trasmissione di nuovi pacchetti si interrompe)  In pratica, per esami complessi i dati sono passati ad applicazioni

47 Claudio Telmon - Internet -47 © Claudio Telmon - 2000-2002 Esempio: Checkpoint Firewall-1 Driver delle schede di rete Modulo di Inspection Stack TCP/IP del S.O. Security server Serveresterni Spazio utente Kernel FWD gestione

48 Claudio Telmon - Internet -48 © Claudio Telmon - 2000-2002  Per la content inspection di fatto i dati sono passati a un’applicazione:  i vantaggi in termini di prestazioni scompaiono, anche di fronte al costo dell’ispezione; rimane un’ottimizzazione nella gestione dei pacchetti  Lo stack TCP/IP modificato è ottimizzato ma meno testato  Server esterni:  autenticazione  server CVP Esempio: Checkpoint Firewall-1

49 Claudio Telmon - Internet -49 © Claudio Telmon - 2000-2002 Firewall-1 e il content filtering  L’esame della sessione e i protocolli con contrattazione di porte richiedono di ricostruire la sessione tramite una virtual machine  I dati vengono passati ai security server, applicazioni per il content filtering e l’autenticazione  auhtentication server  CVP server (interfaccia per antivirus)  server per traffico http, smtp, ftp

50 Claudio Telmon - Internet -50 © Claudio Telmon - 2000-2002 Altre funzionalità  Protezione dai SYN flood  es. invio di un RESET dopo un timeout  protezione dai fragmentation attack/scan (più corretta dei router)  antispoofing  Network Address Translation (NAT)  Gestione centralizzata di più firewall/politiche

51 Claudio Telmon - Internet -51 © Claudio Telmon - 2000-2002 Content Vectoring Protocol  Problema: passare i dati da ispezionare a server esterni (tipicamente antivirus)  Soluzione: fornire un’interfaccia standard fra firewall e server esterno  Quanto è efficace un antivirus nell’esaminare il traffico in rete?  Architetture diverse  Diversi meccanismi di compressione  Prestazioni di un controllo centralizzato vs. distribuito  Serve comunque proteggersi dai floppy…

52 Claudio Telmon - Internet -52 © Claudio Telmon - 2000-2002 Content Inspection: esiste davvero?  Di fatto è realizzata solo per i protocolli più comuni, se non in termini di corrispondenza al protocollo  Sempre più applicazioni usano http come protocollo, “tanto passa dai firewall”  Che possibilità c’è di capire cosa sta passando?  Cosa capire di un applet o uno script?

53 Claudio Telmon - Internet -53 © Claudio Telmon - 2000-2002 Complessità del proxy: un rischio  Più il proxy (o il modulo per SPF) capisce il protocollo, più assomiglia a un client e a un server  Oltre un certo limite, la complessità lo rende vulnerabile quanto un client o un server  La conoscenza dell’ambiente è comunque limitata (es. interazione con l’ambiente di Microsoft IIS)

54 Claudio Telmon - Internet -54 © Claudio Telmon - 2000-2002 Gestione del DNS  Gli host interni devono poter vedere gli host esterni  Si può decidere di nascondere la rete interna  In tal caso il DNS richiede una configurazione particolare  Sarà necessario riscrivere, ad esempio, gli header della posta, e istruire gli utenti

55 Claudio Telmon - Internet -55 © Claudio Telmon - 2000-2002 Semplicità vs. Corettezza  Posizione 1: il firewall deve essere essenzialmente semplice: si elimina il più possibile e si irrobustisce il sistema op.  Posizione 2: un sistema operativo debole, per di più modificato, è soggetto agli errori suoi e delle applicazioni. Serve un sistema operativo intrinsecamente più sicuro

56 Claudio Telmon - Internet -56 © Claudio Telmon - 2000-2002 Realizzarlo o acquistarlo?  Per realizzare il proprio firewall bisogna conoscere bene:  Internet, e le reti in generale  Il sistema che si vuole utilizzare  Le problematiche di sicurezza  Per acquistarlo bisogna:  fidarsi molto di chi lo produce e installa  In tutti i casi sono importanti la gestione e la manutenzione

57 Claudio Telmon - Internet -57 © Claudio Telmon - 2000-2002 Personal firewall  Nati soprattutto per linee xDSL  Controllano:  quali applicazioni possono accedere alla rete  pacchetti in arrivo dalla rete  Generano molti falsi positivi  ogni pacchetto non previsto è segnalato: su linee dial-up segnalano anche traffico normale  l’utenza non sa interpretare i messaggi  Es. alcuni provider considerano “a bassa priorità” le segnalazioni dovute a questi strumenti

58 Claudio Telmon - Internet -58 © Claudio Telmon - 2000-2002 ArchitettureArchitetture

59 Claudio Telmon - Internet -59 © Claudio Telmon - 2000-2002 Principî guida  Ridondanza delle protezioni  nessun meccanismo è prefetto  Separazione fra servizi, sistemi e reti con diversi requisiti di sicurezza  Flessibilità  Semplicità  Uso della nostra rete per attacchi su Internet? (es. proxy “aperti”)  Verifica: se un meccanismo cede, cosa succede?

60 Claudio Telmon - Internet -60 © Claudio Telmon - 2000-2002 Singolo “dual homed bastion host” BastionHost Internet Reteprotetta

61 Claudio Telmon - Internet -61 © Claudio Telmon - 2000-2002 Screening router: rete protetta? BastionHost Router Internet Rete“protetta” ServerPubblici Sistemiinterni

62 Claudio Telmon - Internet -62 © Claudio Telmon - 2000-2002 Screened subnet: protezioni ridondanti? Routerinterno Routeresterno Internet Reteprotetta Bastionhost

63 Claudio Telmon - Internet -63 © Claudio Telmon - 2000-2002 BastionHost Router Internet Reteprotetta ServerPubblici Configurazione base con DMZ DMZ

64 Claudio Telmon - Internet -64 © Claudio Telmon - 2000-2002 Controllo del traffico da parte del bastion host BastionHost Router Internet ServerPubblici Reteprotetta

65 Claudio Telmon - Internet -65 © Claudio Telmon - 2000-2002 BastionHost Router Internet ServerPubblici Reteprotetta DMZ Protetta

66 Claudio Telmon - Internet -66 © Claudio Telmon - 2000-2002 Firewall Router Internet ServerWeb Reteprotetta Accesso a sistemi interni Serverinterno

67 Claudio Telmon - Internet -67 © Claudio Telmon - 2000-2002 Firewall Router Internet ServerWeb Reteprotetta Accesso a sistemi interni: “belt and suspenders” Serverinterno chokeRouter

68 Claudio Telmon - Internet -68 © Claudio Telmon - 2000-2002 Sistemi più complessi Firewall Router Internet Server Extranet Rete locale Router/firewall Rete aziendale Firewall

69 Claudio Telmon - Internet -69 © Claudio Telmon - 2000-2002 Separazione del traffico Firewall Router Internet Rete locale a bassa criticità Serverpubblici RouterServer Web dedicato Firewall Serverinterno Rete locale ad alta criticità/ mainframe

70 Claudio Telmon - Internet -70 © Claudio Telmon - 2000-2002 BibliografiaBibliografia

71 Claudio Telmon - Internet -71 © Claudio Telmon - 2000-2002 I Sistemi di Intrusion Detection

72 Claudio Telmon - Internet -72 © Claudio Telmon - 2000-2002 IDS: Intrusion detection systems  Tentano di rilevare:  attività di analisi della rete  tentativi di intrusione  intrusioni avvenute  comportamenti pericolosi degli utenti  traffico anomalo

73 Claudio Telmon - Internet -73 © Claudio Telmon - 2000-2002 Tecniche per IDS  I sistemi di Intrusion Detection possono utilizzare diverse tecniche per rilevare un’intrusione:  verificare la presenza di schemi corrispondenti ad attacchi (pattern matching)  verificare la presenza di traffico “irregolare”:  imparando qual è il traffico corretto e rilevando quello anomalo  in base a politiche che definiscono il traffico corretto/anomalo

74 Claudio Telmon - Internet -74 © Claudio Telmon - 2000-2002 Tipologie di IDS  NIDS: analizzano il traffico in rete (i sensori sono sniffer senza indirizzo IP)  HIDS: analizzano le attività su un sistema  Sistemi misti/ibridi (es. NIDS per singoli sistemi, architetture con HIDS/NIDS con un’unica console)

75 Claudio Telmon - Internet -75 © Claudio Telmon - 2000-2002 Network IDS (NIDS)  Esaminano il traffico su un segmento di rete  Vedono traffico che un HIDS potrebbe non vedere  Non dipendono (molto) dagli OS dei sistemi  Non hanno una visione del contesto in cui i dati saranno interpretati (OS, applicazione, ambiente…)  Possono essere sovraccaricati con una certa facilità

76 Claudio Telmon - Internet -76 © Claudio Telmon - 2000-2002 HIDS: IDS per singoli sistemi  Verificano tentativi di attacco al singolo sistema  Possono:  esaminare i log del sistema e delle applicazioni  verificare lo stato dei file  controllare le attività dei processi (es. chiamate di sistema)  controllare il traffico di rete (sistemi ibridi, che possono anche bloccare il traffico come i personal firewall, a volte specializzati per applicazioni come http)

77 Claudio Telmon - Internet -77 © Claudio Telmon - 2000-2002 HIDS vs. NIDS  Sono meno pesanti per il sistema: possono essere installati su server e sistemi critici  Se il sistema è compromesso, possono essere manomessi  Hanno un’idea più chiara dell’ambiente in cui sono trattati i dati  Sono sensibili ai DoS quanto il sistema su cui sono

78 Claudio Telmon - Internet -78 © Claudio Telmon - 2000-2002 Metodologie di analisi  Tipo di analisi:  In base a database di attacchi noti  Euristiche  Quando analizzare i dati?  Tempo reale?  Analisi successiva  Entrambe

79 Claudio Telmon - Internet -79 © Claudio Telmon - 2000-2002 IDS aggiornabili o programmabili?  ISS RealSecure: aggiornato con tecniche stile antivirus; non permette personalizzazioni  NFR Network Flight Recorder: completamente personalizzabile, ma è necessario ottenere i plug-in per i diversi attacchi

80 Claudio Telmon - Internet -80 © Claudio Telmon - 2000-2002 Uso dei sistemi di intrusion detection  Non sostituiscono i firewall  Interferiscono meno con il traffico di rete (è un vantaggio?)  Possono essere utilizzati anche per monitorare il traffico interno  Reactive IDS: abbattono le connessioni (o peggio?)

81 Claudio Telmon - Internet -81 © Claudio Telmon - 2000-2002 Gestione degli IDS  Generalmente sono composti da:  agenti, da installare in punti critici della rete o su sistemi a rischio  console per la gestione e l’analisi  Parte dell’elaborazione dei dati è fatta sull’agente  selezione dei dati interessanti  Parte dell’elaborazione è fatta sul database presente sulla console  analisi a posteriori  visione globale

82 Claudio Telmon - Internet -82 © Claudio Telmon - 2000-2002 Dove mettere un IDS? Firewall Router Internet Server Extranet Rete locale Router/firewall Rete aziendale Firewall

83 Claudio Telmon - Internet -83 © Claudio Telmon - 2000-2002 Attacchi agli IDS: input validation  Gli IDS sono programmi eseguiti con privilegi elevati che leggono dei dati (i pacchetti) e li elaborano  Se non sono realizzati con sufficiente cura, inviando pacchetti malformati è possibile avere anche qui dei buffer overflow  Problemi analoghi (pubblici): ethereal, tcpdump…

84 Claudio Telmon - Internet -84 © Claudio Telmon - 2000-2002 Problemi tecnologici degli IDS  Prestazioni (NIDS)  Quanti protocolli e applicazioni devono conoscere?  Falsi positivi?  Falsi negativi (slow scans, traffico frammentato…)  Aggiornamento  Riconoscimento di attacchi inusuali

85 Claudio Telmon - Internet -85 © Claudio Telmon - 2000-2002 Problemi di uso degli IDS  Lasciati a se stessi, gli IDS proteggono solo dagli attacchi banali  Nella maggior parte dei casi, richiedono un’analisi e una decisione  Sono necessari più dati del solo pattern che ha causato l’allarme:  i dati possono essere incrociati con quelli del firewall  può servire il traffico apparentemente legittimo o trascurabile di giorni precedenti  interpretare i dati può essere difficile, specialmente se sembrano contraddittori o non decisivi

86 Claudio Telmon - Internet -86 © Claudio Telmon - 2000-2002 BibliografiaBibliografia

87 Claudio Telmon - Internet -87 © Claudio Telmon - 2000-2002 IPSECIPSEC

88 Claudio Telmon - Internet -88 © Claudio Telmon - 2000-2002 Cifratura del traffico  Livello 2:  apparecchiature dedicate  inadatti all’uso su Internet (passa solo il livello 3)  caso particolare: PPTP  Livello 3:  cifratura dei pacchetti IP:  SKIP, IPSEC  Livello 4:  cifratura della connessione TCP  SSL, SSH

89 Claudio Telmon - Internet -89 © Claudio Telmon - 2000-2002 PPTPPPTP  Permette di incapsulare traffico PPP su IP:  su IP viene utilizzato GRE  su GRE viene incapsulato PPP  su PPP può essere utilizzato IP, IPX, NETBEUI…  Permette l’accesso RAS su domini remoti con la partecipazione dell’AS locale  Non ha avuto un grande successo neppure fra gli utenti Microsoft (è offerto da alcuni provider)

90 Claudio Telmon - Internet -90 © Claudio Telmon - 2000-2002 IPSEC: cifratura dei pacchetti IP  È trasparente alle applicazioni  Richiede una modifica dello stack TCP/IP  Permette l’associazione delle chiavi a sistemi o utenti  Separa la cifratura del traffico dal meccanismo di gestione delle chiavi (IKE)

91 Claudio Telmon - Internet -91 © Claudio Telmon - 2000-2002 Modalità di IPSEC  Prevede:  due header: AH e ESP con alcune funzionalità (es. autenticazione) ridondanti  due tipologie di sistemi: hosts e gateway  due modalità di “incapsulamento”: transport e tunnel  Il dubbio è che la complessità e l’introduzione dei gateway servano:  a “soddisfare” tutti i vendor coinvolti  a permettere la vendita di licenze gateway

92 Claudio Telmon - Internet -92 © Claudio Telmon - 2000-2002 Tunnel IPSEC Tunnel IPSEC

93 Claudio Telmon - Internet -93 © Claudio Telmon - 2000-2002 Utilizzi di IPSEC  Presentare sistemi remoti come se fossero locali:  sedi remote  mobile computing  Proteggere applicazioni che non hanno meccanismi propri  entrambe le parti devono essere d’accordo

94 Claudio Telmon - Internet -94 © Claudio Telmon - 2000-2002 Svantaggi di IPSEC  Il traffico non può essere monitorato neppure dagli IDS  Nonostante lo standard, la compatibilità fra prodotti diversi è tutta da verificare  Cifrando tutto il traffico, l’impatto sulle prestazioni non è trascurabile  numero di SA  dimensioni dei pacchetti

95 Claudio Telmon - Internet -95 © Claudio Telmon - 2000-2002 IPSEC e firewall Internet Router/firewall

96 Claudio Telmon - Internet -96 © Claudio Telmon - 2000-2002 BibliografiaBibliografia