cerca
Log Files e Syslog
modifica cronologia stampa login logout

Wiki

UniCrema


Materie per semestre

Materie per anno

Materie per laurea


Help

Return to Log Files e Syslog  (Edit)

Uni.LogFilesESyslog History

Hide minor edits - Show changes to output

Changed lines 6-7 from:
%titolo%''':: Log Files e Syslog::'''
to:
%titolo%''':: Log Files e Syslog ::'''
Changed line 14 from:
* "[@troubleshooting e diagnosi problemi@]"
to:
* "[@troubleshooting e diagnosi problemi@]", dove per ''troubleshooting'' si intende ricerca e riparazione di un guasto
Changed line 26 from:
Il lavoro del ''computer security log management'' comporta una serie di provvedimenti e pianificazioni a priori, sia per quanto riguarda l'architettura e lo storage dei log, che per la definizione di una serie di policy su ''rotation'' (sovrascrittura delle nuove entry sulle vecchie), ''retention'' (tempo minimo e massimo di conservazione dei log), ''field'', ''payload'', ''access'' e ''chain of custody''. Tutte queste attività dovrebbero essere svolte in fase di preparazione, durante la quale non vanno persi di vista anche altri aspetti:
to:
Il lavoro del ''log management'' comporta una serie di provvedimenti e pianificazioni a priori, sia per quanto riguarda l'architettura e lo storage dei log, che per la definizione di una serie di policy su ''rotation'' (sovrascrittura delle nuove entry sulle vecchie), ''retention'' (tempo minimo e massimo di conservazione dei log), ''field'', ''payload'', ''access'' e ''chain of custody''. Tutte queste attività dovrebbero essere svolte in fase di preparazione, durante la quale non vanno persi di vista anche altri aspetti:
Changed line 60 from:
Va detto infine che la maggior parte dei log dei sistemi operativi [@unix-like@] adottano il protocollo '''Syslog''' (che studieremo più avanti), mentre quelli Microsoft utilizzano un formato proprietario. A questo proposito va detto che l'analisi di log in formati proprietari è possibile solo grazie a viewer messi a disposizione dalle case di produzione, oppure appellandosi direttamente ad essi (incrociando le dita).
to:
Va detto infine che la maggior parte dei log dei sistemi operativi [@Unix-like@] adottano il protocollo '''Syslog''' (che studieremo più avanti), mentre quelli Microsoft utilizzano un formato proprietario. A questo proposito va detto che l'analisi di log in formati proprietari è possibile solo grazie a viewer messi a disposizione dalle case di produzione, oppure appellandosi direttamente ad essi (incrociando le dita).
Changed lines 19-20 from:
Ogni sistema e periferica di rete dovrebbe avere una fonte unica e non duplicata di log, strutturata in modo da essere accessibile a più utenti. In altre parole bisogna fare in modo che più persone possano accedere allo stesso log, ma non che più log tengano traccia dello stesso sistema. Si rende perciò necessario l'introduzione di un sistema rigoroso di gestione dei log, composto da una serie precisa di task e definito nel suo insieme '''log management'''.
to:
Ogni sistema e periferica di rete dovrebbe avere una fonte unica e non duplicata di log, strutturata in modo da essere accessibile a più utenti. In altre parole bisogna fare in modo che più persone possano accedere allo stesso log, ma non che più log tengano traccia della stessa cosa. Si rende perciò necessaria l'introduzione di un sistema rigoroso di gestione dei log, composto da una serie precisa di task e definito nel suo insieme '''log management'''.
Changed line 34 from:
* '''log di sicurezza''', tra i cui compiti vi sono: il monitoraggio della propria infrastruttura di rete e di sicurezza (misurata con metriche opportune), l'identificazione di nuove minacce e il tracciamento delle attività degli utenti/utilizzatori. Tutte queste attività sono da supporto per l'Incident Response
to:
* '''log di sicurezza''', tra i cui compiti vi sono: il monitoraggio della propria infrastruttura di rete e di sicurezza (misurata con metriche opportune), l'identificazione di nuove minacce e il tracciamento delle attività degli utenti/utilizzatori
Changed lines 38-39 from:
E' importante sapere con che tipo di log abbiamo a che fare per poter poi effettuare tutte le ''correlazioni'' ('''correlation''') possibili, ovvero una serie di attività che hanno come obiettivo l'analisi correlata dei risultati dell'esame sulla macchina compromessa ([@post mortem@]) e della log analysis. I punti di correlazione trovati sono da tenere in alta considerazione per rendere più agevole e precisa l'individuazione del responsabile e la ricostruzione dell'accaduto.
to:
E' importante sapere con quale tipo di log abbiamo a che fare per poter poi effettuare tutte le ''correlazioni'' ('''correlation''') possibili, ovvero una serie di attività che hanno come obiettivo l'analisi correlata tra i risultati dell'esame sulla macchina compromessa e la log analysis. I punti di correlazione trovati sono da tenere in alta considerazione per rendere più agevole e precisa l'individuazione del responsabile e la ricostruzione dell'accaduto.
Changed line 51 from:
* '''Remote Access Server''', che non memorizza sui log solo il traffico concesso (a un determinato utente) ma anche quello bloccato, così che si possa monitorare un'intera sessione indipendentemente dai permessi di accesso alla rete
to:
* '''Remote Access Server''', che non memorizza sui log solo il traffico concesso a un determinato utente ma anche quello bloccato, così che si possa monitorare un'intera sessione indipendentemente dai permessi di accesso alla rete
Changed line 63 from:
"Con il termine '''log rotation''' si indica la metodica con la quale un log viene spostato dalla modalità on-line a quella off-line", ovvero su dispositivi di archiviazione secondari. Questo spostamento può avvenire periodicamente, oppure solo quando la dimensione del file di log ha superato un certo valore. Indipendentemente dal motivo, che va comunque motivato, la log rotation prosegue generalmente con i seguenti passaggi:
to:
"Con il termine '''log rotation''' si indica la metodica con la quale un log viene spostato dalla modalità on-line a quella off-line", ovvero su dispositivi di archiviazione secondari. Questo spostamento può avvenire periodicamente, oppure solo quando la dimensione del file di log ha superato un certo valore. Indipendentemente dal motivo, che va comunque documentato, la log rotation avviene generalmente con i seguenti passaggi:
Changed line 74 from:
* "procedere alla produzione e raccolta dei log senza effettuarne l'analisi""
to:
* "procedere alla produzione e raccolta dei log senza effettuarne l'analisi"
Changed line 88 from:
* contattare l'amministrazione di sistema
to:
* contattare l'amministratore di sistema
Changed lines 96-102 from:
# verifichiamo che il nostro antivirus conosca la firma del worm che ha provocato l'incidente, così da capire se garantiva una protezione adeguata contro questa tipologia di malware
# ci assicuriamo che i log siano realmente presenti (si intende proprio la loro posizione fisica)
# effettuiamo la duplicazione
dei log
# controlliamo i punti di correlazione dei log file
# verifichiamo se ci sia stata una violazione delle policy
#
controlliamo il traffico di entrata e uscita della rete, ad esempio utilizzando uno strumento come [@Network Behaviour Analysis Tool@], che analizza il payload dei pacchetti. Il traffico è monitorato non solo per motivi di sicurezza ma anche per costruire il grafo di andamento della rete, che dà un'idea sulle performance della rete stessa
to:
* verifichiamo che il nostro antivirus conosca la firma del worm che ha provocato l'incidente, così da capire se garantiva una protezione adeguata contro questa tipologia di malware
* ci assicuriamo che i log siano fisicamente presenti
* effettuiamo la duplicazione dei log
* controlliamo i punti di correlazione
dei log file
* verifichiamo se ci sia stata una violazione delle policy
*
controlliamo il traffico di entrata e uscita della rete, ad esempio utilizzando uno strumento come [@Network Behaviour Analysis Tool@], che analizza il payload dei pacchetti. Il traffico è monitorato non solo per motivi di sicurezza ma anche per costruire il grafo di andamento della rete, che dà un'idea sulle performance della rete stessa
Changed lines 106-109 from:
# verifichiamo i log di autenticazione
# cerchiamo il flusso della rete che ha come destinazione i siti pirata
# monitoriamo tale flusso così da poter risalire al colpevole
to:
* verifichiamo i log di autenticazione
* cerchiamo il flusso della rete che ha come destinazione i siti pirata
* monitoriamo tale flusso così da poter risalire al colpevole
Changed line 111 from:
Il '''Syslog''' è un protocollo che consente la trasmissione attraverso la rete di messaggi di log da macchine dette ''Syslog Sender'' a dispositivi di raccoglimento chiamati ''Syslog Servers'' o ''Syslog Daemon''. L'RFC di riferimento è la 3164, molto tecnica, che stabilisce tra le altre cose che i messaggi debbano essere trasmessi tramite UDP, in particolare alla porta 514; ciò significa che non si hanno garanzie di consegna, poiché nell'User Datagram Protocol non è previsto l'invio dell'ack da parte del ricevente (per maggiori dettagli consultate le pagine del wiki di [[Sistemi di elaborazione dell'informazione->Sistemi]]). Problemi di affidabilità e di autenticazione tra le parti sono dunque da mettere in conto, così come l'esposizione ad altri pericoli come il dropping o lo spoofing di un messaggio.\\
to:
Il '''Syslog''' è un protocollo che consente la trasmissione attraverso la rete di messaggi di log da macchine dette ''Syslog Sender'' a dispositivi di raccoglimento chiamati ''Syslog Servers'' o ''Syslog Daemon''. L'RFC di riferimento è la 3164, molto tecnica, che stabilisce tra le altre cose che i messaggi devono essere trasmessi tramite UDP, in particolare alla porta 514; ciò significa che non si hanno garanzie di consegna, poiché nell'User Datagram Protocol non è previsto l'invio dell'ack da parte del ricevente (per maggiori dettagli consultate le pagine del wiki di [[Sistemi di elaborazione dell'informazione->Sistemi]]). Problemi di affidabilità e di autenticazione tra le parti sono dunque da mettere in conto, così come l'esposizione ad altri pericoli come il dropping o lo spoofing di un messaggio.\\
Changed lines 119-120 from:
Il mantenimento di un unico syslog deamon è sconsigliato perché rappresenterebbe un ''Single Point Of Failure'', ovvero la sua compromissione comprometterebbe l'intero sistema. E' quindi opportuno distribuire i log su più macchine, così che lo sforzo per danneggiarli diventi maggiore.
to:
Il mantenimento di un unico syslog deamon è sconsigliato perché rappresenterebbe un ''Single Point Of Failure'', ovvero la sua compromissione ne minerebbe irrimediabilmente l'affidabilità. E' quindi opportuno distribuire i log su più macchine, così che lo sforzo per danneggiarli diventi maggiore.
Changed lines 127-129 from:
* '''Sender''': possono essere sia device che relay, ed inviano i messaggi verso relay o collector senza sapere a priori quali dispositivi siano;
* '''Receiver''': possono essere sia collector che relay, ovvero i dispositivi che ricevono messaggi Syslog
to:
* '''Sender''': possono essere sia device che relay, ed inviano i messaggi verso relay o collector senza sapere a priori quali dei due siano;
* '''Receiver''': possono essere sia collector che relay, ovvero dispositivi che ricevono messaggi Syslog
Changed lines 134-135 from:
Concludiamo il discorso sugli attori del protocollo sottolineando l'importanza dei controlli di sicurezza sull'architettura Syslog, che devono garantire l'integrità dei massaggi e tenere sotto controllo i loro tempi di latenza, attività quest'ultima fondamentale per il corretto funzionamento di sistemi in tempo reale e dei gestori delle sincronizzazioni.
to:
Concludiamo il discorso sugli attori del protocollo sottolineando l'importanza dei controlli di sicurezza sull'architettura Syslog, che devono garantire l'integrità dei messaggi e tenere sotto controllo i loro tempi di latenza, attività quest'ultima fondamentale per il corretto funzionamento di sistemi in tempo reale e dei gestori delle sincronizzazioni.
Changed line 147 from:
Più basso sarà il valore ottenuto e più urgente sarà l'evento (e di conseguenza l'intervento) considerato.
to:
Più basso sarà il valore ottenuto e più urgente sarà l'evento e di conseguenza l'intervento necessario.
December 20, 2008, at 09:44 PM by ido wireless abusivo -
Changed line 60 from:
Va detto infine che la maggior parte dei log dei sistemi operativi [@unix-like@] adottano il protocollo '''Syslog''' (che studieremo nel [[suo capitolo->Syslog]]), mentre quelli Microsoft utilizzano un formato proprietario. A questo proposito va detto che l'analisi di log in formati proprietari è possibile solo grazie a viewer messi a disposizione dalle case di produzione, oppure appellandosi direttamente ad essi (incrociando le dita).
to:
Va detto infine che la maggior parte dei log dei sistemi operativi [@unix-like@] adottano il protocollo '''Syslog''' (che studieremo più avanti), mentre quelli Microsoft utilizzano un formato proprietario. A questo proposito va detto che l'analisi di log in formati proprietari è possibile solo grazie a viewer messi a disposizione dalle case di produzione, oppure appellandosi direttamente ad essi (incrociando le dita).
December 20, 2008, at 09:40 PM by ido wireless abusivo -
Added lines 1-168:
(:title Log Files e Syslog:)
[[#su]]
[[Torna alla pagina di Gestione degli incidenti informatici->Gestione degli incidenti informatici]]
----

%titolo%''':: Log Files e Syslog::'''

>>frame<<
Ove non meglio specificato, tutti i testi tra virgolette vanno intesi come citazioni letterali dalle slide del prof [[Dario Forte]], 2008.
>><<

!!Definizione di log
Il file '''log''' è un record che consente di tener traccia di determinati eventi accaduti all'interno di un sistema o di una rete, ed è formato da una serie di ''entry'' che rappresentano le informazioni legate agli eventi stessi. I file log sono una risorsa fondamentale per i response team, che li utilizzano per i seguenti scopi:
* "[@troubleshooting e diagnosi problemi@]"
* "[@ottimizzazione delle prestazioni di sistemi e reti@]"
* "[@tracciare le attività utente@]". Questa attività è particolarmente utile per verificare che certi utenti non abbiano compiuto operazioni per le quali non erano autorizzati
* "[@fornire informazioni utili per l'investigazione@]"

Ogni sistema e periferica di rete dovrebbe avere una fonte unica e non duplicata di log, strutturata in modo da essere accessibile a più utenti. In altre parole bisogna fare in modo che più persone possano accedere allo stesso log, ma non che più log tengano traccia dello stesso sistema. Si rende perciò necessario l'introduzione di un sistema rigoroso di gestione dei log, composto da una serie precisa di task e definito nel suo insieme '''log management'''.

La generazione dei log può essere ''continua'' o ''schedulata'' (batch mode). Nel primo caso la registrazione dell'evento avviene in tempo reale, mentre nel secondo solo al momento della chiusura della sessione monitorata. Da segnalare inoltre l'esistenza del cosiddetto '''log grezzo''' (o ''raw''), ovvero il primo log disponibile dopo la fase di acquisizione.

!!Computer security log management
Da quanto detto finora già si intuisce l'enorme importanza dell'analisi dei log, ma anche la grande quantità di dispositivi che li generano all'interno di un contesto aziendale. Per questo motivo diventa fondamentale adottare un sistema di gestione dei log efficiente, chiamato '''computer security log management''' (o solo ''log management'') e che si occupa di gestirli nelle loro diverse fasi: generazione, trasmissione, memorizzazione, analisi e disposizione finale dei dati elaborati.

Il lavoro del ''computer security log management'' comporta una serie di provvedimenti e pianificazioni a priori, sia per quanto riguarda l'architettura e lo storage dei log, che per la definizione di una serie di policy su ''rotation'' (sovrascrittura delle nuove entry sulle vecchie), ''retention'' (tempo minimo e massimo di conservazione dei log), ''field'', ''payload'', ''access'' e ''chain of custody''. Tutte queste attività dovrebbero essere svolte in fase di preparazione, durante la quale non vanno persi di vista anche altri aspetti:
* garantire che il paradigma [@C.I.A.@] (''confidentiality, integrity, availability'') sia rispettato per i log generati; eventuali eccezioni vanno giustificate
* separare opportunamente i ruoli e le responsabilità, ad esempio tra amministratore di sistema e response team
* preparare adeguatamente gli addetti alla log analysis
* utilizzare software che adottino un modello di [@three tiers architecture@], ovvero divisi in tre moduli: interfaccia utente (ad esempio PTK o Autopsy), gestione dei dati (ad esempio database) e logica funzionale (che fa funzionare il tutto)

!!Tipi di log
I log possono essere suddivisi in tre categorie:
* '''log di sicurezza''', tra i cui compiti vi sono: il monitoraggio della propria infrastruttura di rete e di sicurezza (misurata con metriche opportune), l'identificazione di nuove minacce e il tracciamento delle attività degli utenti/utilizzatori. Tutte queste attività sono da supporto per l'Incident Response
* '''log di sistema operativo''', che tiene traccia di ''tutti'' gli eventi che avvengono in un sistema operativo, compresi quelli relativi alla sicurezza
* '''log di rete''', che non sono soggetti al controllo di sicurezza e sono associati al traffico di rete

E' importante sapere con che tipo di log abbiamo a che fare per poter poi effettuare tutte le ''correlazioni'' ('''correlation''') possibili, ovvero una serie di attività che hanno come obiettivo l'analisi correlata dei risultati dell'esame sulla macchina compromessa ([@post mortem@]) e della log analysis. I punti di correlazione trovati sono da tenere in alta considerazione per rendere più agevole e precisa l'individuazione del responsabile e la ricostruzione dell'accaduto.

Esaminiamo ora nel dettaglio i ''log di sicurezza'' e quelli ''di sistema operativo''.

!!!Log di sicurezza
I ''log di sicurezza'' tengono traccia di tutti gli eventi del sistema relativi alla sicurezza. I ''security software'' sono la fonte primaria di questo tipo di log, e si rivelano particolarmente utili per comprendere le modalità di penetrazione dell'intruder, per agevolare la collaborazione con le forze di polizia e per collezionare il maggior numero possibile di evidence sull'istrusione. Elenchiamone alcuni:

* '''router''' e '''firewall''', ovvero dispositivi che bloccano o consentono il traffico di rete in base a policy prestabilite. In entrambi i casi le informazioni sul traffico bloccato sono memorizzate su log, anche se i firewall in particolare consentono un maggior livello di dettaglio e ispezione
* '''antimalware software''', che registra su log tutti i suoi interventi (rilevazione, rimozione, quarantena, aggiornamenti)
* '''Intrusion Detection System''' (IDS) e ''Intrusion Prevention System'' (IPS). I primi generano log continui, mentre i secondi fanno delle analisi che hanno come obiettivo la prevenzione degli attacchi
* '''Vulnerability Management Software''', responsabile del monitoraggio della cosiddetta "patch installation history" e dello stato delle vulnerabilità della macchina. Agiscono in modalità batch
* "'''Autentication Server''': si occupano di gestire ogni tentativo (riuscito o meno) di autenticazione, inclusa l'origine". Una delle componenti di questo dispositivo è l' ''OTP'', responsabile della generazione delle password che saranno poi registrate nel log
* '''Network Quarantine Server''', che fa a sua volta parte della ''NAC'' (''Network Access Control''). Mantiene i log delle macchine messe in quarantena, ed il loro traffico viene posto in una porzione di rete anch'essa quarantenata. Finché queste macchine non soddisfano determinate policy non potranno rientrare in rete
* '''Remote Access Server''', che non memorizza sui log solo il traffico concesso (a un determinato utente) ma anche quello bloccato, così che si possa monitorare un'intera sessione indipendentemente dai permessi di accesso alla rete
* '''Web Proxy''', utilizzati come mediatori tra client e server per creare un livello aggiuntivo di sicurezza. Consultare i loro log si rivela spesso un'attività molto utile

!!!Log di sistema operativo
I ''log di sistema operativo'' sono quelli che registrano gli eventi dei sistemi operativi di rete, di servizio e di workstation, ma anche di altre applicazioni tra cui quelle viste in precedenza. Possiamo distinguere due tipi principali:

* '''eventi di sistema''', che forniscono informazioni (timestamp compreso) sulle "operazioni eseguite dal sistema operativo e dai suoi componenti", in particolare quelle che non vanno a buon fine o che si risolvono in errore. In alcuni casi è data possibilità all'amministratore di filtrare le categorie di eventi da loggare
* '''audit''', che tiene unicamente traccia degli eventi di sicurezza, ad esempio: autenticazione riuscite/fallite, violazione di policy, accesso ai file e/o risorse, alterazione del sistema, ...

Va detto infine che la maggior parte dei log dei sistemi operativi [@unix-like@] adottano il protocollo '''Syslog''' (che studieremo nel [[suo capitolo->Syslog]]), mentre quelli Microsoft utilizzano un formato proprietario. A questo proposito va detto che l'analisi di log in formati proprietari è possibile solo grazie a viewer messi a disposizione dalle case di produzione, oppure appellandosi direttamente ad essi (incrociando le dita).

!!Log rotation e retention
"Con il termine '''log rotation''' si indica la metodica con la quale un log viene spostato dalla modalità on-line a quella off-line", ovvero su dispositivi di archiviazione secondari. Questo spostamento può avvenire periodicamente, oppure solo quando la dimensione del file di log ha superato un certo valore. Indipendentemente dal motivo, che va comunque motivato, la log rotation prosegue generalmente con i seguenti passaggi:
# estrazione e compressione della porzione di file di log da archiviare
# generazione dell'hash di tale archivio, così da poterne in seguito comprovarne l'integrità
# spostamento in un sistema di raccolta centralizzato, in cui verrà controllato l'hash

Con la '''log retention''' vengono invece stabiliti i tempi minimi e massimi di conservazione dei log in un sistema. Non esiste una regola universale, ma molto dipende dalla tipologia di azienda (finanziaria, industriale, pubblica amministrazione, ...) e dall'architettura di log e di storage.

!!Errori comuni
Di seguito una serie di errori comuni nel processo di log management (dalle slide di Dario Forte, 2008):

* "non abilitare il logging"
* "procedere alla produzione e raccolta dei log senza effettuarne l'analisi""
* "revisionare unicamente i log prodotti dai sistemi perimetrali omettendo i sistemi interni"
* "sviluppare la propria infrastruttura di logging prima di individuare le fonti da cui attingere", quindi "prima di aver deciso cosa raccogliere"
* "memorizzare i log per un periodo troppo breve"
* "prioritizzare le informazioni prima di averle raccolte"
* "ignorare i log applicativi"
* "ricercare solo i pattern riconosciuti pericolosi, omettendo le rimanenti entry dall'analisi"
* "considerare i log raccolti come evidence nonostante non venga pianificato correttamente il processo di generazione e raccolta"
* "sottostimare il volume delle informazioni da raccogliere"
* "ricondurre la disciplina del log management ad un problema di data management"

!!Cosa fare in caso di incidente
Prima di vedere due casi pratici, forniamo alcune regole generali da rispettare in caso di incidente:
* identificare i punti di raccolta dei log
* contattare l'amministrazione di sistema
* contenere il danno
* collezionare i log in locale senza alterarli in alcun modo
* creare un'immagine della macchina compromessa rispettando l'ordine di volatilità delle informazioni

!!!Esempio 1
Un worm ha causato un incidente di sicurezza su una delle tre sottoreti di una rete, cosa facciamo?

# verifichiamo che il nostro antivirus conosca la firma del worm che ha provocato l'incidente, così da capire se garantiva una protezione adeguata contro questa tipologia di malware
# ci assicuriamo che i log siano realmente presenti (si intende proprio la loro posizione fisica)
# effettuiamo la duplicazione dei log
# controlliamo i punti di correlazione dei log file
# verifichiamo se ci sia stata una violazione delle policy
# controlliamo il traffico di entrata e uscita della rete, ad esempio utilizzando uno strumento come [@Network Behaviour Analysis Tool@], che analizza il payload dei pacchetti. Il traffico è monitorato non solo per motivi di sicurezza ma anche per costruire il grafo di andamento della rete, che dà un'idea sulle performance della rete stessa

!!!Esempio 2
Bisogna risalire al personale interno di un'azienda che ha utilizzato siti pirata, cosa facciamo?

# verifichiamo i log di autenticazione
# cerchiamo il flusso della rete che ha come destinazione i siti pirata
# monitoriamo tale flusso così da poter risalire al colpevole

!!Syslog
Il '''Syslog''' è un protocollo che consente la trasmissione attraverso la rete di messaggi di log da macchine dette ''Syslog Sender'' a dispositivi di raccoglimento chiamati ''Syslog Servers'' o ''Syslog Daemon''. L'RFC di riferimento è la 3164, molto tecnica, che stabilisce tra le altre cose che i messaggi debbano essere trasmessi tramite UDP, in particolare alla porta 514; ciò significa che non si hanno garanzie di consegna, poiché nell'User Datagram Protocol non è previsto l'invio dell'ack da parte del ricevente (per maggiori dettagli consultate le pagine del wiki di [[Sistemi di elaborazione dell'informazione->Sistemi]]). Problemi di affidabilità e di autenticazione tra le parti sono dunque da mettere in conto, così come l'esposizione ad altri pericoli come il dropping o lo spoofing di un messaggio.\\
Esiste tuttavia una versione avanzata del Syslog più orientata alla sicurezza: il ''Secsyslog'', che utilizza il TCP e sfrutta i covert channel.

Il syslog non è sempre abilitato di default poiché comporta un impatto rilevante sulle performance della macchina, impatto che aumenta all'aumentare delle informazioni da monitorare. Per questo motivo l'eventualità di una sua attivazione deve essere valutata con attenzione in fase di preparazione.

!!!Syslog Daemon
Il '''Syslog Daemon/Server''' è un'entità passiva che rimane in ascolto dei messaggi syslog a lei diretti. Per ''passiva'' si intende che non è lei a fare richiesta dei log da un determinato device, ma sono questi ultimi che autonomamente le inviano i messaggi quando lo ritengono opportuno. Ne consegue che in un'indagine forense andranno controllati sia deamon che sender.

Il mantenimento di un unico syslog deamon è sconsigliato perché rappresenterebbe un ''Single Point Of Failure'', ovvero la sua compromissione comprometterebbe l'intero sistema. E' quindi opportuno distribuire i log su più macchine, così che lo sforzo per danneggiarli diventi maggiore.

!!!Attori del protocollo
Per evitare ambiguità con la terminologia definiamo con precisione i vari attori del protocollo:

* '''Device''': "macchina in grado di generare messaggi" (ad esempio firewall, router, ...)
* '''Relay''': "macchina in grado di ricevere messaggi e inoltrarli ad un secondo sistema", il cui utilizzo disinnesca il problema del ''singol point of failure'' e consente inoltre una distribuzione del carico di lavoro. Si noti che i relay possono inoltrare i messaggi ad altri relay
* '''Collector''': macchina in grado di ricevere messaggi e memorizzarli senza inoltrarli. La memorizzazione può avvenire su file di testo (tipico dei log grezzi) o su database (tipico dei sistemi avanzati, dato che consente di effettuare query). I collector sono chiamati anche ''syslog server'' o "[@bidoni centrali@]" (sic)
* '''Sender''': possono essere sia device che relay, ed inviano i messaggi verso relay o collector senza sapere a priori quali dispositivi siano;
* '''Receiver''': possono essere sia collector che relay, ovvero i dispositivi che ricevono messaggi Syslog

Nella figura seguente sono visualizzati a titolo di esempio una serie di connessioni possibili tra i dispositivi coinvolti in una comunicazione Syslog.

%center%Attach:syslogComunicazione.gif

Concludiamo il discorso sugli attori del protocollo sottolineando l'importanza dei controlli di sicurezza sull'architettura Syslog, che devono garantire l'integrità dei massaggi e tenere sotto controllo i loro tempi di latenza, attività quest'ultima fondamentale per il corretto funzionamento di sistemi in tempo reale e dei gestori delle sincronizzazioni.

!!!Pacchetti Syslog
I messaggi Syslog viaggiano attraverso le reti incapsulati in '''pacchetti''', ognuno dei quali non deve superare i 1024 byte di grandezza ed è composto da tre parti: ''PRI'', ''Header'' e ''Msg''. Vediamoli nel dettaglio.

!!!!PRI
'''PRI''' sta per ''priority part'', è composto da 8 bit ed indica il livello di priorità del log. Contiene due informazioni:

* la '''facility''', che indica il componente del sistema operativo che genera il messaggio di log. Ad essa sono dedicati 5 bit, quindi ha 32 possibili valori: [@0, 1, 2, ... , 31@]. I primi sedici valori sono standard, e in particolare i primi cinque sono ''security sensitive''; dal 17 in poi sono personalizzabili
* la '''severity''', che rappresenta il livello di criticità dei log. Ad essa sono riservati i rimanenti 3 bit della priority part, quindi ha 8 possibili livelli in ordine decrescente di gravità (lo 0 è il più grave)

In molti casi è più comodo considerare insieme le due componenti e ciò è possibile attraverso il calcolo del '''priority value''', ottenuto moltiplicando la facility per 8 e quindi aggiungendo al risultato il valore della severity. In formula:
[@priority value = (facility * 8) + severity@]
Più basso sarà il valore ottenuto e più urgente sarà l'evento (e di conseguenza l'intervento) considerato.

Concludiamo il paragrafo sul PRI osservando che solo il sender ha la possibilità (e il dovere) di stabilire il valore di facility e severity, mentre il daemon può solo utilizzarli per funzioni di filtraggio dei pacchetti.

!!!!Header
Nell' '''Header''' viene tenuta traccia di:
* ''timestamp'' che indica la data e l'ora in cui il sistema locale ha generato il messaggio. Lo standard per esprimerlo è il seguente: [@mmm dd hh:mm:ss@], dove [@mmm@] è il mese, [@dd@] è il giorno, [@hh@] l'ora, [@mm@] i minuti e [@ss@] i secondi. Notare come non ci sia alcun riferimento all'anno e come la sua veridicità sia legata al corretto funzionamento del clock di sistema
* ''identificativo della macchina che ha generato il messaggio'', che può essere indicata sottoforma di hostname o indirizzo IP

!!!!MSG
La terza ed ultima parte di un pacchetto Syslog è il '''messaggio''' ('''MSG''') vero e proprio, composto da un ''tag'' che indica il nome del programma che l'ha generato ed un ''content'' che è il contenuto del messaggio vero e proprio.

!!!Syslogd
Unix utilizza come demone per il logging dell'intero sistema il '''Syslogd''', che offre diverse opzioni di comportamento e una buona configurabilità. Il suo file di configurazione si trova generalmente in [@/etc/syslog.conf@], percorso da conoscere con precisione in quanto sarà uno dei principali obiettivi degli attacker. \\
Ogni riga del file di configurazione è composta da due campi:
* '''Selettore''', che indica attraverso la specifica di facility e severity su quali eventi o categorie di eventi si intende agire
* '''Azione''', quella da intraprendere sugli eventi indicati dal selettore

La comunicazione con il deamon syslogd può avvenire tramite il programma [@logger@] (che ha una sintassi precisa e dedicata), oppure utilizzando librerie per il C ([@syslog.h@]), o moduli per Perl e Python.

----
[[Torna alla pagina di Gestione degli incidenti informatici->Gestione degli incidenti informatici]]