next   previous   contents

Riuso di meccanismi di intrusion prevention od intrusion detection

 Un'interessante alternativa ad una soluzione standalone basata sulla libreria LibPcap potrebbe essere quella di sfruttare un intrusion detection system preesistente per catturare e processare i pacchetti.
 Gli IDS ( acronimo per Intrusion Detection System ) sono un componente molto importante di molte architetture di sicurezza di rete. Essi offrono infatti un layer di difesa aggiuntivo, rilevando accessi non consentiti o potenziali attacchi per mezzo di informazioni disponibili sul sistema (log) o dalla rete ( traffico di rete ). Ricercando pattern predefiniti un IDS puo' allertare l'amministratore di sistema quando necessario, o anche prendere contromisure atte ad arginare l'attacco ( in questo caso e' piu' corretto parlare di Intrusion Prevention System ).
 Quindi l'IDS nell'accezione piu' pura del termine puo' essere visto come un sistema di monitoraggio e non un mezzo per fermare l'attacco.
 Gli intrusion detection system possono essere classificati in vari modi :

• In base ai meccanismi di analisi : Online ed Offline ( batch ). Nel primo caso gli alert vengono generati in base ad eventi correnti, mentre nel secondo caso gli eventi sono registrati nei log e analizzati periodicamente ( il risultato quindi non e' istantaneo) .
  Considerato che l'analisi dei syslog non e' un buon metodo di rilevamento per le sequenze di knock, un IDS offline non e' sicuramente adatto allo scopo.

• In base al metodo di rilevamento : Misuse ed Anomaly Detection. Nel primo caso l'IDS analizza le informazioni che raccoglie e le confronta con un database contenente le attack signatures. Essenzialmente si cerca un'attacco gia' documentato. Quindi l'affidabilita' e' legata alla qualita' ed all'aggiornamento delle regole del database. Nel secondo caso invece l'amministratore deve definire delle linee guida, come per esempio lo stato del traffico di rete, i protocolli, la dimensione dei pacchetti ecc. Il sistema controlla i segmenti di rete per confrontare il loro stato con le linee guida e scoprire eventuali anomalie.

• In base alle sorgenti di informazioni : Network ed Host based.

Non essendo questo un lavoro sugli intrusion detection system non ci si sofferma sulle differenze tra i vari modelli con i loro pro e contro, limitandosi a spiegare brevemente come riutilizzare un NIDS per riconoscere e gestire le sequenze di knock.
Esistono diversi IDS sia commerciali che liberi. L'attenzione in particolare viene posta su hogwash, utilizzato come base per uno dei due prototipi sviluppati ed in musira minore su snort. Entrambi i software sono distribuiti con licenza GPL.

Snort

 Snort e' un Network Intrusion Detection System, basato sulla libreria LibPcap. Si tratta di un sistema multipiattaforma, in grado di compilare correttamente su tutti i sistemi compatibili con questa libreria.
 Questo software e' composto da un packet sniffer/logger e da un engine avanzato di pattern matching e puo' di conseguenza venire utilizzato sia come uno sniffer avanzato che come intrusion detection system.
 Il sistema di individuazione dei tentativi di intrusione si basa su un set di regole che determinano quali pacchetti di rete registrare e quando inviare degli alert all'amministratore. In particolare Snort e' in grado di generare degli alert in tempo reale attraverso syslog, messaggi SMB (“winpopup”) oppure su un file di alert separato. Questa soluzione risulta particolarmente flessibile, perche' il file potrebbe essere poi analizzato da un software esterno che provveda ad inviare ad esempio avvisi all'amministratore attraverso mezzi differenti da quelli predefiniiti, come via email o sms.
 Il funzionamento di questo sistema di intrusion detection puo' essere suddiviso in quattro componenti, fondamentali per la rilevazione delle intrusioni. ll primo componente si occupa della cattura dei pacchetti. Poiche' Snort non ha un proprio meccanismo di cattura dei pacchetti, questa operazione viene affidata alla libreria esterna LibPcap. L'architettura propria di Snort e' invece costituita da tre sottosistemi principali : il packet decoder, detection engine e il sottosistema di logging e alert.
 L'immagine seguente rappresenta uno schema complessivo, che mostra come le varie componenti del sistema coinvolte, collaborano con Snort nella rilevazione delle intrusioni:

 Il packet decoder ha il compito decodificare i pacchetti catturati per passarli poi al detection engine, il tutto cercando di garantire la massima velocita' possibile.
 Il detecion engine e' il componente fondamentale del sistema vero e proprio, ed utilizza delle liste linkate bidimensionali sulle quali viene applicato un algoritmo di pattern matching. Va inoltre ricordato che Snort ha una struttura modulare e supporta quindi diversi plugin, che possono essere usati per estendere il set di regole e le funzionalita' del detection engine.
 il BSD Packet Filter (BPF), permette la creazione di filtri tra il processo user space ed il kernel. Si ricorda pero' che tale feature su sistemi diversi da quelli della famiglia BSD deve essere emulata, con conseguenze quindi sulle prestazioni.
 L'ultimo sottosistema e' quello deputato al logging ed alla generazione degli alert. Oltre ai vari canali usati per avvisare ( syslog, messaggi SMB, ecc, ) e' possibile scegliere tra i cosiddetti Full alerting e Fast alerting. Nel primo caso vengono registrati sia i messaggi d'allarme che l'header completo dei pacchetti, mentre nel secondo si conservano solamente le informazioni piu' importanti riguardo ai pacchetti sospetti. La seconda soluzione e' quindi piu' indicata per quelle situazioni caratterizzate da un carico particolarmente pesante.
 Al fine di poter sfruttare Snort per il rilevamento delle sequenze di knock, la caratteristica piu' interessante e' la possibilita di utilizzare plugin. Attualmente Snort supporta tre tipi di plugin : output plugin , preprocessori e detection plugin.  Gli output plugins vengono invocati in caso debba essere loggato qualche evento o generato un alert. Un possibile output plugin potrebbe ad esempio memorizzare gli alert in un database anziche' in un file di testo.
 I detection plugin possono essere chiamati anche piu' volte per pacchetto, passandogli argomenti diversi. Di norma un plugin di questo tipo analizza uno o piu' parametri di un pacchetto per determinare se rispettino alcuni criteri stabiliti, come ad esempio i flag dei pacchetti TCP per verificare che corrispondano a delle combinazioni definite in una particolare regola.
 I preprocessori invece possono essere chiamati una sola volta per pacchetto e svolgono funzioni complesse come il riassemblaggio di flussi TCP (TCP stream reassembly), ed il controllo dello stato delle connessioni (stateful inspection). Queste due operazioni ad esempio consistono rispettivamente nella ricostruzione dell'esatta sequenza di trasmissione dei dati partendo dai sequence number dei pacchetti TCP e nel registrare le informazioni riguardanti ogni singola connessione in una apposita tabella (la cosiddetta connection o state table), in modo tale che successivamente, ogni volta che un pacchetto viene analizzato, si verifichi prima di tutto se esso faccia parte di una connessione precedentemente stabilita. Questo tipo di controllo presenta infatti il vantaggio di essere molto piu' veloce di un normale controllo volto ad analizzare ad esempio la presenza di un determinato pattern nel payload del pacchetto.

Hogwash

 Hogwash e' un intrusion detection system/packet scrubber (anche definito come firewall signature based), ovvero un software in grado di riconoscere attacchi sulla rete monitorata, e se specificato filtrarli.
Originariamente nel 1996 il programma (allora chiamato scrub) fu scritto per filtrare gli attacchi diretti verso un webserver impossibile da aggiornare per problemi di compatibilita' del software applicativo installato.
Nel 1999 venne abbandonato il vecchio engine in favore di quello di Snort, ed il programma rinominato SnortScrub. Col passare del tempo il nome del software venne cambiato in hogwash e furono aggiunte nuove caratteristiche come la possibilita' di funzionare senza uno stack IP. Hogwash puo' infatti essere utilizzato anche su macchine Linux che non abbiano il supporto IP incluso nel kernel.
 Man mano venivano aggiunte le nuove features il motore di Snort si rivelava pero' inefficace per situazioni di “packet scrubbing” particolarmente intense. Venne quindi modificato e riutilizzato l'engine originale usato per processare i pacchetti (H2 engine). Hogwash e' un software piuttosto leggero, progettato per girare anche con hardware modesto e su sistemi embedded.
 Il software prevede tre modalita' di funzionamento : IDS , packet scrubber e honeypot control.
Nella prima modalita' di funzionamento, l'unica differenza rispetto ad altri prodotti e' la possibilita' di creare pacchetti in grado di resettare una connessione. Usato come semplice IDS il prodotto non e' pero' ancora in grado di competere con sistemi piu' maturi come Snort ad esempio.
 La seconda modalita' e' forse quella piu' interessante, che permette di utilizzare hogwash anche senza la presenza dello stack TCP/IP, come firewall/router per controllare tutto il traffico in transito. In questa modalita' e' possibile filtrare direttamente i pacchetti senza l'intervento di netfilter (e' per questo motivo che viene definito anche come un firewall signature based), e possibilmente anche modificare il pacchetto in transito, ed il suo instradamento.
 In modalita' Honey Pot Control, hogwash agisce come un router, per inviare vari tipi di attacchi a sistemi honey pot. Si tratta comunque di una funzionalita' ancora sperimentale.
 Un grosso vantaggio e' la struttura modulare di hogwash che permette di creare in maniera estremamente semplice dei moduli per svolgere funzionalita' aggiuntive. Un possibile sistema di portknocking potrebbe quindi essere implementato, sfruttando Hogwash per il riconoscimento dei pacchetti
 I piu' grossi svantaggi di hogwash sono invece rappresentati dalla documentazione abbastanza scarsa (specialmente se paragonata al materiale disponibile riguardante Snort) e dalla lentezza del suo sviluppo. Un'altra pecca e' inoltre l'incompatibilita' con le regole di Snort, da quando il programma ha adottato l'utilizzo dell'engine H2. Snort ormai e' particolarmente diffuso, e sarebbe stato estremamente utile potere riutilizzare tutte le regole gia' scritte e costantemente aggiornate per questo IDS.

next   previous   contents