Monitoring di Attività e Rilevazione Intrusioni
Una volta eliminati tutti i servizi non indispensabili su un sistema e attivato un efficace antivirus, non è possibile affermare di aver eliminato con certezza ogni problema di sicurezza.
Ogni procedura di Hardening e sistema di protezione, per quanto robusti, possono risultare inadeguati nel medio/lungo periodo.
Nel caso in cui una vulnerabilità non nota in precedenza (Zero-Day), venga utilizzata con successo da un attaccante per conseguire un accesso non autorizzato, occorre mostrare una buona reattività e operare le opportune modifiche alle proprie misure difensive per scongiurare il ripetersi dell’incidente.
La probabilità che si verifichi un’intrusione è sempre diversa da zero, anche quando gli strumenti adottati per la protezione dei sistemi rappresentano lo stato dell’arte.
Una politica di sicurezza corretta non può quindi prescindere dall’attivazione di meccanismi in grado di individuare tempestivamente eventuali intrusioni.
Il processo per rilevare un’intrusione in un sistema informatico è analogo al processo per rintracciare il colpevole di un crimine nel mondo reale.
Se il colpevole non lascia alcuna traccia del suo passaggio, è estremamente difficile non solo scoprirne l’identità, ma anche semplicemente rendersi conto dell’avvenuta infrazione.
Per poter rilevare l’intrusione è quindi indispensabile innanzitutto che l’intruso lasci tracce significative.
Ogni sistema operativo è provvisto di meccanismi che registrano le attività illegittime.
A integrazione dei meccanismi esistenti a livello di sistema operativo, possono essere utilizzati software dedicati, generalmente noti come IDS (Intrusion Detection System).
Tali strumenti hanno molti punti in comune con quelli che vengono chiamati IPS o Intrusion Prevention System.
In prima approssimazione un IPS è un IDS che riesce in qualche modo a prevenire l’incidente invece che limitarsi solo a registrarlo.
Gli strumenti di Intrusion Detection si distinguono in due categorie: quelli che svolgono una semplice azione di Accounting e quelli che compiono un’azione di controllo in tempo reale reagendo, se necessario, all’attacco secondo quanto configurato dal responsabile della sicurezza.
I primi effettuano semplicemente il monitoring delle attività globali relative al sistema operativo e/o alle richieste di accesso al singolo servizio, memorizzando il risultato dell’attività di controllo in uno o più file di log.
Nei file di log vengono normalmente registrate le informazioni riguardanti le risorse richieste, l’identità (quando nota) del richiedente e il momento della richiesta.
La creazione e l’aggiornamento di un file di log di solito non appesantisce molto la CPU del sistema su cui le funzioni di Accounting sono abilitate.
Decisamente diverso il carico di lavoro nel caso si adottino strumenti appartenenti al secondo gruppo.
Gli IDS in grado di rilevare tentativi di intrusione in tempo reale, sono agenti decisamente più complessi, che devono riconoscere in maniera automatica la presenza di pattern ostili, a livello di singoli pacchetti, comandi o nei file trasferiti nella comunicazione.
La loro introduzione, attivazione e configurazione sulle piattaforme in esercizio è quindi da ritenersi decisamente più complicata delle altre comuni procedure di logging.
Purtroppo non è sempre possibile accorgersi dell’intrusione mentre questa è ancora in corso. Talvolta non si dispone di personale adeguato per presidiare ventiquattro ore al giorno i sistemi.
In altre circostanze, l’individuazione dell’intrusione richiede un’analisi delle informazioni così approfondita da richiedere un tempo superiore alla durata dell’attacco.
Per questo, anche se l’esame delle informazioni registrate è affidato a sistemi esperti semiautomatici è fondamentale poter rilevare l’intrusione anche in un secondo momento e poter analizzare i dettagli di quanto accaduto, attraverso le registrazioni effettuate.
Indipendentemente dalla natura e complessità degli strumenti utilizzati, i file di log restano pertanto una componente fondamentale di ogni sistema di sicurezza dell’informazione.
Attraverso l’analisi delle informazioni registrate in tali file, è possibile individuare eventuali bug nei sistemi e nei programmi utilizzati, stabilire l’identità degli attaccanti e le risorse danneggiate.
Molto spesso, se l’attacco ha avuto successo, le registrazioni dei file di log rappresentano l’unica possibilità per scoprire la metodologia di attacco utilizzata dall’hacker.
Per evitare che l’attaccante riesca a nascondere il proprio operato i file di log devono essere protetti crittograficamente in modo da poter rilevare ogni possibile alterazione illegittima.
Per individuare un’avvenuta intrusione, è indispensabile riuscire a estrarre, dalle registrazioni disponibili, gli eventi riconducibili ad azioni illecite.
Questa operazione è complicata dal fatto che non tutte le azioni che violano le regole devono essere considerate indice di un’intrusione o di un tentativo di intrusione.
Alcune registrazioni possono appartenere a utenti legittimi, che hanno commesso uno sbaglio o richiesto un servizio, senza rispettare completamente il protocollo (per esempio digitando male la propria password).
Un controllo veramente efficace può essere svolto solo se si è in grado di distinguere le azioni di un attaccante da quelle di un utente inesperto.
Per risolvere questo problema, è possibile utilizzare due approcci:
- stabilire un profilo comportamentale standard per l’utente legittimo e avvisare l’amministratore ogni volta che il comportamento di un utente si discosta da tale modello;
- stabilire una soglia per ogni azione, indice di una potenziale intrusione, e avvisare l’amministratore ogni volta che un utente supera questa soglia.
Il primo approccio necessita l’individuazione di un modello comportamentale di non facile determinazione.
Un modello che deve poter evolvere per riuscire a caratterizzare in modo accurato l’attività degli utenti legittimi nel tempo, e soprattutto deve essere adattato ogni qual volta si assista all’introduzione di un nuovo servizio.
Il secondo approccio richiede invece la determinazione di soglie di allarme, che possono essere stabilite solo grazie all’esperienza diretta dell’organizzazione in fatto di attacchi reali.
Una migliore risposta del sistema richiede la valutazione di più parametri correlati, complicando l’individuazione delle relative soglie.
La qualità del sistema, per rilevare le intrusioni, viene generalmente misurata attraverso il numero di falsi positivi o falsi negativi registrati e attraverso la reattività del meccanismo nel prendere decisioni.
Si ha un falso positivo ogni volta che scatta un allarme senza motivo; si ha un falso negativo quando un’intrusione passa invece inosservata.
La reattività del sistema è un’altra componente fondamentale, in quanto determina le possibili modalità di risposta all’intrusione.
Un sistema che opera in tempo reale, ovvero che riesce a individuare l’intruso mentre l’attacco è ancora in corso, prevede normalmente che le informazioni vengano indirizzate direttamente ad amministratori e/o programmi automatici per una pronta reazione e, solo in un secondo momento, gli eventi rilevanti registrati in appositi file di log per una valutazione a posteriori dell’accaduto.
Molti sistemi operativi prevedono la registrazione di file di log, sotto forma di file ASCII, accessibili a tutti gli utenti locali.
Questa soluzione rappresenta una pericolosa vulnerabilità.
Se infatti la stazione è oggetto di una intrusione, non rilevabile in tempo reale, l’hacker può cancellare ogni traccia del suo passaggio alterando il file di log.
Se la struttura dei file di log permette all’hacker di cancellare in maniera selettiva solo le informazioni riguardanti le proprie azioni, senza alterare le altre, diviene particolarmente difficile non solo stabilire con quali risorse l’intruso ha interagito, ma anche individuare la sua presenza all’interno del sistema.
Un’altra limitazione delle registrazioni contenute nei file di log, è che queste risultano molto spesso carenti di informazioni utili per risalire al dettaglio delle azioni svolte dall’attaccante.
Per risolvere inconvenienti del genere è consigliabile:
- adottare strumenti specifici in grado di registrare gli eventi verificatisi, in maggior dettaglio;
- memorizzare le informazioni in forma cifrata (con opportune tecniche per la codifica di messaggi lunghi);
- conservare copie di backup dei file di log su altri sistemi.
Un hacker particolarmente motivato non si lascia però spaventare facilmente.
Se la stazione prevede la memorizzazione di un file di log codificato, è sufficiente che l’attaccante si procuri la chiave di codifica per recuperare le informazioni originali, tagliare le parti sospette e codificare il tutto di nuovo.
Per evitare questa eventualità, è preferibile adottare algoritmi asimmetrici. Per rendere più veloce l’operazione di cifratura asimmetrica, una soluzione alternativa alla codifica dell’intero file, è quella di calcolare un digest e proteggere crittograficamente solo il digest.
Per la corretta conservazione di una copia di backup dei file di log o dei relativi digest, può essere necessario prevedere la trasmissione delle registrazioni via rete.
Un protocollo di larga diffusione utilizzabile in tal senso è il protocollo SYSLOG (da non confondere con l’omonimo servizio locale).
I dati trasmessi con tale protocollo devono essere preventivamente protetti in quanto il SYSLOG (che si basa su semplici invii UDP, porta riservata 514/udp) non garantisce né un canale affidabile né intrinseca sicurezza alle informazioni trasmesse.
Prima di procedere operativamente alla configurazione delle funzioni di logging sui sistemi esposti è necessario ricordare che, per la memorizzazione delle informazioni, occorre uno spazio di memoria proporzionale al numero di eventi da registrare e al livello di dettaglio associato.
Prima dell’attivazione di un IDS è quindi necessario verificare l’idoneità dei propri sistemi a svolgere attività di logging, assicurandosi di aver lasciato spazio disco sufficiente per memorizzare i file di log che saranno prodotti.
La predisposizione di risorse non adeguate può trasformare il logging in uno strumento dannoso invece che utile; offrendo un ulteriore punto debole attraverso il quale l’attaccante può tentare un attacco DoS (saturazione delle risorse di memoria, in seguito alla creazione di file di log molto lunghi).
