Il Forum di Orebla.it

Benvenuto nella community di Orebla.it
Oggi è dom 16 feb, 2020 8:14 pm

Tutti gli orari sono UTC + 1 ora




Apri un nuovo argomento Rispondi all’argomento  [ 2 messaggi ] 
Autore Messaggio
 Oggetto del messaggio: AIPreproc, modulo di AI per Snort
Messaggio da leggereInviato: gio 14 ott, 2010 8:14 pm 
Non connesso
super-guru
super-guru
Avatar utente

Iscritto il: mar 28 dic, 2004 6:54 pm
Messaggi: 300
Località: Pisa
La storia.

Giugno 2010, ultimi miei giorni in Danimarca, comincio a guardarmi intorno per la tesi per la mia laurea specialistica in ingegneria informatica. Non trovando disponibilità a Copenhagen mi rivolgo al mio vecchio docente di reti e sicurezza di Modena, con cui cominciamo a parlare dell'idea di integrare all'interno di un IDS (Intrusion Detection System) come Snort algoritmi di AI (intelligenza artificiale), in modo da rendere il rilevamento degli attacchi più intelligente, diminuire il "rumore di fondo" dell'intrusion detection e il tasso di falsi positivi, rendere più agevole e "umana" la lettura di possibili minacce per la sicurezza dai log (ed eventualmente integrare meglio le regole di iptables nel caso in cui si voglia mettere a valle un sistema di sicurezza attivo e quindi trasformare Snort in un Intrusion Prevention Systems), clusterizzare gli alert in macrogruppi in modo da rendere più agevole la lettura (ad esempio invece di 1000 alert del tipo "pacchetto TCP frammentato da parte della macchina della rete X verso una macchina della rete interna" avere un unico alert), e prevedere con buona approssimazione le potenziali mosse future di un attaccante nello scenario di un attacco multi-step, considerato come un grafo molto ramificato dove ogni nodo è un pezzo dell'attacco.

È un progetto estremamente ambizioso, che si rifà un po' al defunto progetto SnortAI, ma anche molto complesso, sia da un punto di vista algoritmico, sia della dimensione e della gestione. È un progetto che finora al mondo non esiste, è altamente sperimentale e mi sto muovendo anch'io per tentativi e idee da concretizzare pian piano.

I sorgenti su cui sto lavorando sono disponibili su GitHub: http://github.com/BlackLight/Snort_AIPreproc e come intuibile, essendo un progetto su cui lavoro quotidianamente e davvero tanto ormai da tempo sono in continuo aggiornamento. Chiunque può esaminarli da lì (consiglio di fare spesso dei clone o dei pull, dato che aggiorno il repository praticamente ogni ora lavorandoci su attivamente), contribuire, fare dei fork, ecc.

Snort_AIPreproc è un modulo per Snort che agisce a livello di preprocessore (quindi prima della trafila di matching di regole e flussi vera e propria). In realtà questo è vero solo in parte, perché pur essendo piazzato a livello di preprocessore in Snort parsa in parallelo anche gli alert log a valle, cercando di integrare quante più informazioni possibile.

Uno schema di massima del software si può trovare qui:
http://i.imgur.com/EXsmJ.png

Quello che fa finora è:

  • Integrazione con Snort. La configurazione del modulo è parsata da snort.conf, e i flussi di pacchetti sniffati da Snort vengono girati al modulo. I singoli pacchetti in arrivo sull'interfaccia di rete vengono ordinati e classificati in una hash table di liste concatenate (dove ogni lista è identificata da una quadrupla IP:porta e rappresenta fondamentalmente una sequenza di traffico). In parallelo il modulo parsa gli alert generati da Snort (da file di testo o da database, il modulo per ora supporta MySQL e PostgreSQL come DBMS), e integra all'interno dei singoli alert le informazioni sui flussi TCP associati, in modo da poter fare un'analisi a valle più dettagliata.
  • Clustering degli alert. L'utente, dalla configurazione di Snort, può fornire certe sottoclassi all'interno dei domini degli attributi degli alert e in funzione di come vuole filtrare il traffico e dell'architettura della propria rete (ad esempio può dire che la sottorete privata si trova a 192.168.1.0/24, che i server in DMZ si trovano a 10.8.0.0/24, che gli interessa raggruppare il traffico verso porte non privilegiate in cluster unici mentre vuole maggiore precisione sul traffico verso porte privilegiate, ecc.). In funzione di queste informazioni (parametri di clustering) il modulo crea diverse gerarchie (finora prevedo gerarchie su indirizzi e porte, ma accetto ogni tipo di suggerimenti, sarebbe interessante ad esempio fare gerarchie di clustering anche di tipo temporale, ad esempio per isolare meglio il traffico che arriva all'inizio o alla fine del mese, durante i giorni lavorativi o nel weekend, nelle ore lavorative o di notte, e così via), che vengono poi usate per creare, attraverso un algoritmo di data mining (proposto da Klaus Julisch nel 2002 nel paper "Clustering intrusion detection alarms to support root cause analysis, ma anche su quest'articolo sto considerando diverse prospettive di miglioramento, ad esempio una funzione che mi permetta di stabilire dinamicamente la dimensione minima dei cluster in funzione delle variabili ambientali della rete invece che prenderla staticamente), diversi "macro-raggruppamenti" per gli alert, più facili da gestire e da interpretare, ad esempio "nel weekend, di notte, durante i backup delle macchine, ricevo da diverse macchine nella sottorete X verso macchine della sottorete Y sulle porte Z diversi pacchetti frammentati, è consigliabile una configurazione migliore della rete". Questo tipo di ragionamento sembra fantascienza, ma se l'utente fornisce parametri di clustering che rispecchiano effettivamente l'ambiente dove l'IDS va a infilarsi ho testato che effettivamente è facile poter estrarre informazioni del genere.
  • Correlazione di alert in contesti di attacchi multi-step. Questo è il core vero e proprio del software. Si tratta di un "modulo dentro al modulo" che prende in ingresso gli alert già clusterizzati e restituisce un grafo di correlazioni (ovvero, è molto probabile che l'attacco A sia stato fatto per "preparare" il terreno all'attacco B). Le correlazioni sono prese da diverse sorgenti:

    • Regole di correlazione statiche. Sono fornite un paio di default nella directory corr_rules, in formato XML, e contengono la descrizione di un alert come "hyper-alert", ovvero come azione con precondizioni (condizioni che devono essere vere affinché l'attacco riesca) e post-condizioni (condizioni che possono essere vere se l'attacco riesce). Incastrando per bene precondizioni di alert con post-condizioni di altri alert e usando una soglia di correlazione statistica è possibile vedere quali attacchi sono correlati, o "preparano", quali attacchi. Un XML che descrive un hyper-alert può essere, ad esempio, il seguente (che descrive pre- e post-condizioni di un port scan), fornito di default in corr_rules:

      Codice:
      <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE hyperalert PUBLIC "-//blacklight//DTD HYPERALERT SNORT MODEL//EN" "http://0x00.ath.cx/hyperalert.dtd">

      <hyperalert>
              <snort-id>122.1.0</snort-id>
              <desc>(portscan) TCP Portscan</desc>

              <pre>HostExists(+DST_ADDR+)</pre>
              <post>HasService(+DST_ADDR+, +ANY_PORT+)</post>
      </hyperalert>


      È semplicissimo creare nuove regole di correlazione semplicemente creando nuovi XML su questo modello, con i propri predicati e le proprie variabile (alcune macro, come quelle comprese fra + e + nel listato di sopra, sono automaticamente sostituite a runtime dal modulo).
    • Auto-apprendimento bayesiano basato sull'history (vedi più avanti)
    • Correlazioni o dis-correlazioni specificate a mano attraverso l'interfaccia web (vedi più avanti)
    • Supporto (futuro) per altre regole di correlazione programmabili dall'utente sotto forma di moduli al di sopra del modulo
  • Output di flussi, cluster, alert e correlazioni su database, su file JSON, su file di testo, e su file DOT, parsabile da librerie come Graphviz per ottenere grafici del genere (in formato PNG e PS):

    Immagine
  • Interfaccia web basata su un web server con supporto CGI scritto da zero all'interno del modulo
  • Possibilità di poter analizzare dall'interfaccia web i singoli cluster, analizzare i singoli alert all'interno dei cluster, e salvare i singoli flussi TCP in formato .pcap (file apribili da tcpdump, Wireshark o lo stesso Snort) per poter essere analizzati con calma nel dettaglio
  • Possibilità di specificare a mano correlazioni o non-correlazioni fra alert attraverso l'interfaccia web

--EDIT--

I lavori vanno avanti. Il modulo ora è stato aggiornato con un bel po' di roba figa fra cui

  • Supporto per correlazione bayesiana "intelligente". Ovvero, tutti gli alert ricevuti vengono serializzati su un file binario di history, parsato a intervalli regolari in una hash table, dal quale si possono ricavare informazioni su quanto due alert sono correlati in funzione del numero di volte in cui capitano insieme. Fondamentalmente gli alert vengono esaminati a coppie e la loro correlazione viene calcolata come

    Immagine

    dove

    Immagine

    con l'insieme di alert correlati definito come sottoinsieme del prodotto cartesiano delle coppie:

    Immagine

    con d definita come distanza temporale massima per considerare 2 alert correlati (1 secondo, 1 minuto, 1 settimana...) ed f è una funzione definita come

    Immagine

    con k che mi definisce quanto deve essere "larga" la gaussiana e configurabile dall'utente, calcolato in particolare come

    Immagine

    e ovviamente la probabilità di B è calcolata come

    Immagine

    Con questo metodo è possibile calcolare quanto due alert sono correlati fra loro in un attacco multi-step in funzione di come e quando vengono "triggerati" dal sistema (ovviamente ci saranno ampie oscillazioni inizialmente, e altrettante correlazioni sballate, ma man mano che il traffico in arrivo al sistema comincia ad assumere una "forma" precisa anche i coefficienti così calcolati si stabilizzano).
  • Supporto per l'output di flussi di traffico associati ad alert, cluster di alert e correlazioni su database (supporto per ora sia per MySQL che PostgreSQL). In questo modo, ad esempio, per vedere le informazioni sui singoli cluster di alert e gli alert in essi contenuti basterà un

    Codice:
    select a.alert_id, c.*
    from ca_clustered_alerts c join ca_alerts a
    on c.cluster_id=a.cluster_id
    group by c.cluster_id

  • Interfaccia web, basata su un web server di base scritto from scratch per l'occasione e runnato come thread parallelo (codice in webserv.c) con supporto CGI. Attraverso l'interfaccia web è possibile esplorare, attraverso un insieme di script AJAX e script esterni CGI in Perl, i cluster di alert ricevuti dal sistema, analizzare gli alert contenuti all'interno di ogni cluster (e salvare i singoli flussi di pacchetti matchati, se disponibili, in formato .pcap attraverso una CGI Perl esterna, pronti per essere analizzati da tcpdump, tcpsmash, Wireshark o snort stesso), visualizzare gli alert correlati (che appariranno come qualcosa del genere)

    Immagine

    personalizzare l'interfaccia semplicemente trascinando a piacere i nodi del grafico come si vuole (grazie a JavaScript + SVG e le librerie Raphael JS e Dracula), e soprattutto modificare eventuali "scazzature" del modulo, avendo la possibilità di correlare a mano degli alert che il modulo non ha correlato o specificare che due alert correlati in realtà non lo sono. Il tutto è fatto a partire da un JSON contenente le inforrmazioni esportato dal modulo in C, parsato da AJAX, visualizzato graficamente attraverso Raphael+Dracula, e le cui informazioni rimbalzano alle CGI Perl responsabili rispettivamente dell'esportazione dei flussi in .pcap e della personalizzazione delle correlazioni (gestite attraverso file XML redirezionati al modulo una volta riempiti).

Come al solito, stesso link su GitHub per avere i sorgenti, e ogni collaborazione è più che accetta.

_________________
Immagine
Immagine


Top
 Profilo  
 
 Oggetto del messaggio: Re: AIPreproc, modulo di AI per Snort
Messaggio da leggereInviato: sab 16 ott, 2010 11:21 pm 
Non connesso
Amministratore
Amministratore
Avatar utente

Iscritto il: lun 27 dic, 2004 10:32 am
Messaggi: 2614
Località: Ferrara
Cavolo Black veramente un'idea geniale. Il suo svolgimento è altrettanto audace. Ma sono convinto che tu riuscirai in questa impresa. E la tua tesi di laurea sarà una bomba.

Ascolta me che un poco ne capisco di persone: tu farai un gran successo nel campo informatico!! :D

_________________
I'm so happy because today
I've found my friends ...
They're in my head

[NIRVANA - LITHIUM]
Il Blog del disperato: http://blog.orebla.it


Top
 Profilo  
 
Visualizza ultimi messaggi:  Ordina per  
Apri un nuovo argomento Rispondi all’argomento  [ 2 messaggi ] 

Tutti gli orari sono UTC + 1 ora


Chi c’è in linea

Visitano il forum: Nessuno e 1 ospite


Non puoi aprire nuovi argomenti
Non puoi rispondere negli argomenti
Non puoi modificare i tuoi messaggi
Non puoi cancellare i tuoi messaggi
Non puoi inviare allegati

Cerca per:
Vai a:  
cron
Powered by phpBB® Forum Software © phpBB Group
Traduzione Italiana phpBBItalia.net basata su phpBB.it 2010
phpBB SEO