L'obbiettivo dell'intrusion detection è identificare se un'intrusione è avvenuta e dove. Questo testo descrive le tecniche per effettuare questa ricerca.

Intrusion Detection

Introduzione: l'obbiettivo dell'intrusion detection è identificare se un'intrusione è avvenuta e dove. Questo testo descrive le tecniche per effettuare questa ricerca.

1. Integrity Verifiers
2. File Log
3. Intrusion detection system

Intrusion Detection

Come il nome stesso dice, l'intrusion detection identifica se e dove un intrusione è avvenuta. Questo perché, noi dobbiamo minimizzare il danno fatto da un intruso e magari identificare l'attacker. L'intrusion detection è un complemento del firewall, aumenta le possibilità dell'amministratore di sistema di effettuare security auditing e monitoraggio, aiuta anche a scoprire gli attacchi e a rimediare per tempo.

L'intrusion detection può essere sia un dispositivo hardware che un software. E' formato da quattro elementi, i sensori che raccolgono i dati delle attività di sistema e della rete, la console utilizzata per monitorare lo stato della rete e dei computer, il motore di analisi che si occupa di analizzare i dati ricevuti con le regole e le firme che identificano tentativi di intrusione, quest'ultime si trovano nel database.

Le intrusioni possono essere effettuate sia dall'esterno dell'azienda sia dall'interno. Il sistema di intrusion detection prende informazioni da vari apparati della rete, analizza le informazioni paragonandole a firme (simili a quelle degli antivirus) di intrusioni o abusi. La ricerca delle vulnerabilità effettua degli esami scrupolosi al sistema per individuare buchi di sicurezza.

Una volta individuato l'attacco l'IDS lo notifica e può anche effettuare azioni contro determinati eventi, tipo bloccare ogni tipo di comunicazione con l'IP sospetto. In caso di sola notifica vengono chiamati IDS passivi, mentre in caso effettuino azioni contro l'attacco sono chiamati IDS attivi.
Gli IDS attivi per bloccare gli attacchi devono avere la capacità di dare comandi al firewall, perché è tramite la modifica delle sue regole che possono bloccare l'indirizzo dell'attacker. Questo comporta che l'IDS deve essere ben configurato altrimenti potrebbe bloccare traffico autorizzato

Integrity Verifiers

Gli Integrity protection system rivelano quando un componente critico subisce un cambiamento, e cerca di capire se questi cambiamenti sono stati effettuati da un attività di intrusione, come l'aggiunta di una backdoor ai file di sistema. Alcuni dei più famosi integrity verifiers sono:

1. COPS è una collezione di programmi, ognuno dei quali tenta di risolvere un problema relativo alla sicurezza UNIX
2. Tripwire controlla i tuoi file di sistema, e poi verifica se un intruso ha fatto delle modifiche. Confronta i vecchi hash per verificare se dei file sono stati modificati. Gli algoritmi di Hash inclusi sono MD4 MD5, Snefru e Haval. Gli Hash devono essere messi su un server remoto in sola lettura. Tripwire è esoso di risorse ma l'alternativa( reinstallare il sistema da capo) è più costosa. Puoi scaricare Tripwire da www.tripwiresecurity.com/
3. Tiger è un set di script che fanno la scansione di un sistema UNIX per cercare problemi di sicurezza. Regolarmente i programmi e gli script controllano se l'utente root è sicuro. Verifica i programmi suid . Tiger è scaricabile da ftp://net.tamu.edu/pub/security/TAMU/

Log Files

Molti file logs vengono generati dal sistema, per registrare le attività effettuate, e questi log contengono le tracce delle intrusioni che possono essere scoperte sulla macchina. Qui sotto ci sono i più comuni di questi log. (Potrebbe essere che a seconda delle varianti UNIX la posizione nelle cartelle cambino)

1. utmp wtmp files sono di solito locati in /etc, /var/log o /var/run. Gli utmp log riguardano gli attuali utenti loggati. I wtmp log registrano tutti i logins, logout, shutdown e reboot. Per maggiori dettagli man utmp e vedere anche la libreria standard <utmp.h>
2. la directory /var/log registra log da molti servizi

Sui sistemi che devono essere sicuri, le directory di log standard come /etc e /var/log/ sono sconsigliate. Si devono anche usare tool per il log supplementari. Es. se si vuole sapere chi è connesso ai servizi del tuo sistema, ci sono molte tools sotto la voce IP loggers disponibili.

E' importante che i log non siano conservati sul sistema che li ha generati. Un Attacker potrebbe editarli. Potrebbero anche aver causato molte attività inoffensive e aver causato così tanti log da riempire il disco prima di tentare l'attacco.

Analisi dei file di log
Alcune volte questi log sono così grandi che diventa un lavoro davvero arduo per una persona analizzarli e gestirli. Ci sono dei programmi, che si possono cercare sui motori di ricerca con la frase "log file analysis", che analizzano sistematicamente i log e ti avvertono se c'è dell'attività sospetta

Sniffer
I Traffic Sniffer sono una spada a doppio taglio. Si possono utilizzare per tenere traccia delle comunicazioni degli intrusi e aver molti dettagli sulle loro attività. Ma possono anche essere usate per rubare password e altre informazioni sensibili. Devi essere molto cauto nell'uso di questo programma, la macchina sulla quale gira deve essere ben protetta.

Intrusion Detection Systems

Gli intrusion detection systems (IDSs) stanno diventando la maggiore area di ricerca e produzione delle aziende di sicurezza informatica. Funzionano sul presupposto che un intruso possa essere rivela da vari parametri come il traffico di rete, l'utilizzo della cpu, l'utilizzo del'I/O , user location, e varie attività sui file. Gli IDSs creati per proteggere la rete di solito monitorizzano l'attività di rete, mentre un IDS creato per proteggere un singolo host tipicamente monitorizza l'attività del sistema operativo. I monitor di sistema e i demoni convertono i parametri osservati in record cronologici dell'attività di sistema. Chiamata "Audit trails", questi record sono analizzati dall'IDS per trovare comportamenti sospetti.

L'approccio dell'Intrusion Detection include:

Signature analysis

Le firme o dei modelli specificano i tentativi d'attacco. Le descrizioni semantiche e le firme degli attacchi conosciuti, sono immagazzinate in un database. Il tipo di analisi "audit trails", confronta le informazioni trovate nell'audit trail, per esempio, un sistema costruisce un audit log o event log, con una firma di attacco. Lo scenario dell'attacco viene tradotto in una serie di audit event, o in un modello di dati che possono essere generati dal sistema operativo di un computer, da un router software, firewall, switch, o applicazione. Altri modelli o sequenze possono essere trovati nel traffico di rete. Quando una sequenza di eventi trovata in un audit trail, o nel traffico di rete, è uguale a un audit event o ad una firma, si può sospettare un tentativo di intrusione.

Lo svantaggio principale della tecnica dell'analisi delle firme -come tutti gli approcci di questo genere-è che ha bisogno di un frequente aggiornamento per poter rivelare nuovi tipi di attacchi, questa situazione è aggravata dal fatto che c'è bisogno delle varianti di tutti i tipi di attacchi nelle firme

Rule-Based Intrusion Detection

Gli intrusion detection basati su regole (RBID) presuppongono che i tentativi di intrusione siano caratterizzati da attività utente che segnalano lo stato compromesso del sistema. I RBID sono caratterizzati dal loro sistema specializzato che attiva le regole quando audit record o le informazioni di sistema indicano delle possibili penetrazioni. Queste regole controllano i cambiamenti di alto livello dello stato dei patterns, osservati nell'audit data, confrontati con gli stati predefiniti degli scenari d'attacco. Gli audit event sono tradotti in facts per portare il loro significato all'expert system, e la funzione di intrusion analysis crea le sue conclusione basandosi sulle sue regole e i facts per rivelare un attacco o degli avvenimenti sospetti. Questo aumenta il livello di astrazione della verifica dei dati. Se un RBID expert system si accorge di un tentativo di penetrazione è in corso o è avvenuto, questo allerta gli amministratori( con una mail o altro) e fornisce una giustificazione per l'alert e un identificativo utente del sospetto dell'intrusione(se c'è). Notate che RBID deve essere continuamente aggiornato per poter riconoscere i nuovi attacchi

Ci sono due approcci principali su cui si basano i RBID:

1. State Base, in questo approccio, le regole base sono codificate usando gli stati che si trovano negli audit trails. I tentativi di intrusione sono definiti in una sequenza di stati di sistema - che sono definiti nelle informazioni degli audit trails - che conducono da un iniziale sistema sicuro a uno stato di sistema compromesso.
2. Model Base, questo approccio, i tentativi di intrusione sono modelli di comportamento di un utente; questi modelli di comportamento generano eventi audit trails. L'IDS determina se un comportamento di un utente identificato possa generare un audit trails. Gli IDS model base possono processare più dati, perché questa tecnologia ti lascia limitare selettivamente il focus dei dati da analizzare, permette una spiegazione più intuitiva dei tentativi di intrusione, e può prevedere la prossima azione dell'attacker.

I sistemi rules base sono il frutto delle esperienze degli esperti di sicurezza riguardo gli attacchi informatici. Questo approccio fa un controllo sistematico degli audit trail in cerca di evidenti tentativi di exploit della vulnerabilità conosciute. Sono anche utilizzati per verificare l'applicazione delle norme di sicurezza di un'azienda.

Le principali limitazioni di questo approccio sono:

1. La difficoltà di estrazione di conoscenze sugli attacchi
2. La velocità del processo

State transition analysis

Questa tecnica descrive un attacco con un set di obbiettivi e transizioni, ma li rappresenta come un diagramma di stati. Questo approccio è concettualmente identico a quello model base.

Statistical-Based Intrusion Detection

Il metodo più usato di Intrusion Detection è quello statistico. I comportamenti degli utenti e del sistema sono campionati nel tempo e immagazzinati in un profilo. Ci sono molti tipi di misuratori nei profili. Questi misuratori includono: misuratori di intensità di attività; il misuratore della distribuzione degli audit record; misuratori di categoria (es. relativi alla frequenza dei login); e misurazioni di rutine (es. l'utilizzo della cpu e delle risorse I/O per uno specifico utente). I comportamenti correnti di ciascun utente sono contenuti in un profilo. Il modello originale mantiene le medie di tutte queste variabili e rivela se le soglie, basate sulla deviazione standard di una variabile, sono oltrepassate. Dei modelli più complessi sono stati sviluppati, che confrontano i profili, sia a lungo termine che a corto, dell'attività dell'utente. I profili sono aggiornati regolarmente mentre i comportamenti degli utenti si evolvono.

SBID parte dal presupposto che un intrusione possa essere rivelata da un'ispezione degli audit trail cercando di rivelare attività insolite, questo perché il comportamento di un intruso sarà molto differente da un utente autorizzato. Prima che l'attività sospetta possa essere rivelata, un sistema SBID necessita di avere un profilo degli utenti e del sistema che possa considerarsi "normale" Questi profili sono tipicamente una sequenza di eventi che si possono trovate negli audit data. Una sequenza di eventi diversa da quella registrata nel profilo, da un significativo numero di azioni è un tentativo di intrusione. Uno dei vantaggi del SBID è che le intrusioni possono essere rivelate senza sapere a priori di una vulnerabilità del sistema.

I sistemi SBID tipicamente impiegano sistemi di rivelamento basate su anomalie statistiche e modelli rule-based. Profili di sistema, profili utente, o entrambi possono essere usati per definire i comportamenti normali di un utente o del sistema. I profili utente, se usati, sono specifici per ciascun utente e sono mantenuti e aggiornati dinamicamente. Se il comportamento di un utente cambia nel corso del tempo, così fa anche il suo profilo. Nessuno di questi profili è usato nei sistemi RBID. Come nel caso dei sistemi RBID, gli scenari di attacco conosciuti possono essere dentro le rules-base del SBID.

Scoprire un attacco DoS che fa uso delle debolezze dell'internet protocol suite può essere incluso negli approcci statistici. Un esempio è il SYN flood attack dove un attacker manda molte richieste di connessione con un IP falso e richiede che il sistema sotto attacco mandi un acknowledge a queste richieste senza mai ricevere una conferma. Visto che l'attacker sembra comportarsi in modo consono alle specifiche del protocollo di comunicazione, l'attacco può essere rivelato solamente dalla quantità di connessioni ricevuto in uno specifico periodo di tempo. La quantità di richieste insieme al numero massimo di connessioni consentite definisce la soglie per questo tipo di attacco.

User anomalous behavior identification

Questa tecnica consiste nell'identificare le azioni e le operazioni che un'utente può effettuare sul sistema, queste azioni sono classificate in modelli di autorizzazione per ciascun utente (patterns). Questi modelli sono confrontati con i dati di audit e gli eventi di log, che sono osservati e registrati sul sistema. Il sistema di analisi confronta i modelli di ciascun utente con le azioni che hanno eseguito. Questi confronti possono essere fatti real time o offline, se un utente ha effettuato un azione che non rientra nelle sue competenze parte l'allarme. Questo metodo è simile all'analisi basata su firma, ma a differenza di essa questa confronta le azioni consentite agli utenti e quando c'è un'azione effettuata che non è consentita scatta l'allarme, mentre con le firme le azioni sono confrontate con quelle non consentite e se una di esse viene effettuata scatta l'allarme.

By Marchrist

http://marcris.altervista.org

questo testo è stato scritto in parte utilizzando le mie conoscenze e in parte tramite documentazione in lingua inglese trovata in rete