Archivio per la categoria 'Registrazione'

Combinando Logwatch e OSSEC - Parte 4

18 Febbraio 2010

Nel mio ultimo post abbiamo installato Logwatch così come OSSEC. E 'giunto il momento di ottenere Logwatch e OSSEC giocare insieme nella stessa sandbox. In questo post parlerò come raggiungere Logwatch di riassumere le informazioni che vengono generate da OSSEC.

Opzioni di distribuzione

Abbiamo due strade che possiamo seguire per impostare questa funzione:

  1. Hanno Logwatch analizzare i log OSSEC direttamente.
  2. Hanno OSSEC inviare le proprie segnalazioni a un server Syslog tipo, quindi eseguire Logwatch sul server Syslog.

Il vantaggio per l'opzione # 1 è che abbiamo bisogno di un solo sistema. Logwatch verrà eseguito sul sistema che ospita il server OSSEC. Il problema che stiamo andando a correre in quanto coinvolge il file OSSEC avviso. Voci di registro non vengono normalizzati. Ciò significa che il formato può cambiare da ingresso ingresso, e può anche distribuite su più righe. Sta andando essere un vero incubo per creare uno script Logwatch che filtrerà e sintetizzare le informazioni di allerta.

Se andiamo con opzione # 2, si richiederà un altro box di agire come i nostri server di registrazione centralizzata. Al fine di avere il server OSSEC accettare voci di registro da non-agente, deve ascoltare il UDP/514. Questa è la stessa porta utilizzata da un server di logging centralizzato, e non è possibile avere due applicazioni condividono la stessa porta (tranne che con Windows, ma l'accesso socket è molto disordinato). Sul lato positivo, le voci di allarme avranno normalizzato quando vengono trasmessi al server Syslog per la creazione di uno script di sintesi Logwatch sarà molto più facile. Inoltre, Logwatch sa già sui file Syslog standard, quindi dovremo lavorare di personalizzazione meno da fare.

Infine, ho accennato in un precedente post che OSSEC non è progettato per essere una SIM. Questo è perché non registrare tutto, solo gli eventi che generano un avviso. Quindi siamo probabilmente vorrà un server centralizzato in ogni caso, e ha senso farlo memorizzare le informazioni che vengono generate da OSSEC.

Quindi, se suona come io vi guida verso la scelta # 2, si è assolutamente corretto. Detto questo, io sto in realtà andando a coprire l'opzione # 1 in quanto è una configurazione molto più complesso.

Dealing With Date / Time Stamps

Date un'occhiata al file di log principale OSSEC e si dovrebbe vedere simile al seguente:

[Root @ fubar log] # tail -3 / var / OSSEC / log / ossec.log

2010/02/18 00:32:05 OSSEC-rootcheck: INFO: Fine scansione rootcheck.

2010/02/18 14:27:06 OSSEC-syscheckd: INFO: Starting syscheck scansione.

2010/02/18 14:39:21 OSSEC-syscheckd: INFO: Fine syscheck scansione.

Notare il modo in cui viene formattato la data / ora. Questo è diverso dalla maggior parte delle applicazioni, quindi la prima cosa avremo bisogno di fare è dire Logwatch come trattare con questo formato. Avremo bisogno di creare uno script che possiamo chiamare in caso di necessità, che comprende il formato sopra indicato.

Avviare muovendo nella directory condivisa script:

cd / usr / share / logwatch / scripts / shared

Utilizzando il vostro editor preferito, creare un file denominato "applylongdate":

vi applylongdate

Ecco che cosa avete bisogno all'interno di quel file. Sentitevi liberi di copia / incolla da questa pagina:

uso Logwatch ': date';

my $ debug = $ ENV {'LOGWATCH_DEBUG'} | | 0;

$ SearchDate = TimeFilter ('% Y /% m /% d% H:% M:% S');

if ($ debug> 5) {

print STDERR "DEBUG: ApplyLongDate Dentro ... \ n";

print "DEBUG: In cerca di:" STDERR. $ SearchDate. "\ N";

}

while (defined ($ questa_riga <STDIN> =)) {

if ($ questa_riga = ~ m / ^ $ SearchDate / o) {

print $ questa_riga = ~ s / ^ .... \ / .. \ / .. ..:..:.. / /;

print $ questa_riga;

}

}

# Vi: shiftwidth = 3 = sintassi perl tabstop = 3 et

Una volta salvato il file, ora abbiamo bisogno di impostare le autorizzazioni appropriate:

chmod 755 applylongdate

Configurazione del file di log

Poi abbiamo bisogno di dire Logwatch in cui i file di log OSSEC si trovano. Ogni volta che si aggiungono nuovi file di log o creare nuovi servizi per il monitoraggio in Logwatch, è necessario posizionare le modifiche sotto la directory / etc / logwatch. Abbiamo intenzione di creare due file di configurazione. Il primo si occuperà messaggi OSSEC, e il secondo si occuperà avvisi OSSEC e cambiamenti risposta attiva.

Cominciamo con la creazione del file di configurazione per le principali file di log OSSEC:

cd / etc / logwatch / conf / logfiles

vi ossec.conf

Il contenuto del file deve essere il più seguito:

LogFile = / var / OSSEC / log / ossec.log

* ApplyLongDate =

È ora possibile salvare e uscire dal file. Successivamente, creeremo il file di configurazione dei file di registro rimanenti:

vi OSSEC-alert.conf

Il contenuto di questo file deve essere il più seguito:

LogFile = / var / OSSEC / log / active-responses.log

LogFile = / var / OSSEC / log / avvisi / alerts.log

LogFile = / var / OSSEC / log / firewall / firewall.log

Una volta completata, salvare ed uscire. I permessi di default dovrebbe essere accettabile per la nostra impostazione.

Configurazione dei servizi OSSEC

Successivamente, è necessario per definire i servizi OSSEC e identificare ciò che vogliamo usare come titolo quando i report vengono generati. Ecco come creare il primo file:

cd / etc / logwatch / conf / servizi

vi ossec.conf

Il contenuto di questo file è molto semplice:

Title = "OSSEC Messaggi"

LogFile = OSSEC

Una volta completato è possibile salvare e uscire. Abbiamo bisogno di creare un file di più in questa directory:

vi OSSEC-alert.conf

Il contenuto di questo file deve essere:

Title = "OSSEC avvisi"

LogFile = OSSEC-alert

Al termine, salvare e uscire come al solito.

L'analisi di voci

Quindi, abbiamo bisogno di dire Logwatch come formattare le voci di registro all'interno del report. Avremo bisogno di creare uno script di personalizzazione per ogni insieme di servizi. Stiamo per iniziare utilizzando uno script di test in dotazione Logwatch, solo per fare verificato che tutto funzioni.

Avviare muovendo nella directory appropriata:

cd / etc / logwatch / scripts / servizi

Usa il tuo editor preferito per creare il tuo primo script:

vi OSSEC

Il contenuto dello script deve essere il più seguito:

#! / Bin / bash

# Questo script come è bello che vi mostrerà le linee si

# Essere l'elaborazione e report. Si visualizzerà prima la

# Variabili d'ambiente standard e poi ci vuole STDIN e

# Fare un dump terzino destro fuori su STDOUT.

# Queste sono le variabili d'ambiente standard. È possibile definire

# Più nel file di configurazione di servizio (vedi sopra).

echo "Intervallo date: $ LOGWATCH_DATE_RANGE"

echo "Livello di dettaglio: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Livello di debug: $ LOGWATCH_DEBUG"

# Ora prendete STDIN e discarica a STDOUT

gatto

Ora create il vostro secondo script:

vi OSSEC-alert

e includere il contenuto esattamente lo stesso:

#! / Bin / bash

# Questo script come è bello che vi mostrerà le linee si

# Essere l'elaborazione e report. Si visualizzerà prima la

# Variabili d'ambiente standard e poi ci vuole STDIN e

# Fare un dump terzino destro fuori su STDOUT.

# Queste sono le variabili d'ambiente standard. È possibile definire

# Più nel file di configurazione di servizio (vedi sopra).

echo "Intervallo date: $ LOGWATCH_DATE_RANGE"

echo "Livello di dettaglio: $ LOGWATCH_DETAIL_LEVEL"

echo "Temp Dir: $ LOGWATCH_TEMP_DIR"

echo "Livello di debug: $ LOGWATCH_DEBUG"

# Ora prendete STDIN e discarica a STDOUT

gatto

Infine, abbiamo bisogno di impostare le autorizzazioni appropriate:

chmod 755 OSSEC *

L'installazione di prova

Il modo più semplice per testare la nostra nuova configurazione è di lanciare il comando:

logwatch | less

Se si desidera solo per visualizzare le modifiche, è possibile eseguire una relazione su ogni servizio, uno alla volta:

logwatch servizio OSSEC | less

logwatch-service OSSEC-alert | less

Personalizzazione ulteriormente

Una volta arrivati ​​tutto il lavoro di cui sopra, è possibile concentrarsi su come ottenere Logwatch di filtrare e sintetizzare le voci del registro. Logwatch è abbastanza flessibile, e si può personalizzare l'output nel modo desiderato. Una delle cose belle lo script di test è al di sopra che mostra esattamente quello che hai da lavorare. Così con un po 'di magia espressione regolare è possibile riassumere le voci nel modo che ritiene opportuno. Per alcune idee, controllare il file che si trovano sotto:

/ Usr / share / logwatch / scripts / servizi

Questi sono gli script di default fornito con sintesi Logwatch. In particolare, hanno uno sguardo al file "pam" e "sshd". Essi sono grandi esempi sia di una semplice e una complessa serie di filtri di sintesi.

Durante lo sviluppo script, prestare molta attenzione ai $ "variabile LOGWATCH_DETAIL_LEVEL. Questo vi permetterà di personalizzare il livello di uscita del rapporto a seconda di quanto verbosità l'utente sta cercando. Per esempio, mentre siete ancora nella directory sopra servizi, eseguire il seguente comando:

meno sshd

Quando la prima pagina del contenuto del file viene visualizzato, digitare:

/ Dettaglio <Inserisci key>

Il backslash ci permette di cercare il file una stringa di testo particolare. In questo caso siamo alla ricerca del "dettaglio" parola. Una volta premuto Invio la ricerca permette di saltare attraverso il file fino a che trova la prima istanza della stringa di testo. Sarà anche evidenziare la stringa di ricerca. Nella prima partita si nota che l'autore assegnato alla variabile "$ Detail" per essere lo stesso della variabile $ LOGWATCH_DETAIL_LEVEL ". Questo per risparmiare loro un po 'di digitazione.

Ora premete il tasto backslash ancora seguito dal tasto Invio. Questo saltare attraverso il file nella successiva istanza di "Detail". Si dovrebbe vedere:

if ($ Dettaglio> = 20) {

Gli utenti $ {$ user} {$ host}} {$ Metodo + +;

Else {}

if ($ host! ~ / $ IgnoreHost /) {

Gli utenti $ {$ user} {} {$ host "(tutti )"}++;

Nota l'autore fornisce ulteriori informazioni se il livello di dettaglio è impostato a 20 (a metà strada tra la bassa e media) o superiore. Continuare a saltare attraverso il file e vedrete altri esempi in cui l'autore sfruttato questa tecnica.

Ora pagina fino alla fine del file e dovreste vedere questa dichiarazione:

if (keys% OtherList) {

print "\ n ** ** Le voci senza pari \ n";

print "$ _: $ OtherList {$ _} tempo (s) \ n" foreach keys% OtherList;

}

Questa sezione è estremamente importante, in quanto è un ripostiglio finale. Pensate ad una politica del firewall per un momento. La maggior parte di noi di creare una regolamentazione definitiva che dice: "Se non ho specificamente permesso il traffico attraverso un modello, negarla". In altre parole, se succede qualcosa di inaspettato, è così che voglio che tu gestirlo.

La dichiarazione di cui sopra serve allo stesso scopo durante l'analisi del file di log. Tutte le precedenti "if" tentativo di corrispondere una specifica stringa di testo nella voce di registro al fine di formattarlo correttamente. Questa voce dice: "Se non hai trovato e stampato una voce specifica log ancora, stampare in una sezione intitolata" Voci senza precedenti ** ** ". Questa fase è estremamente importante perché senza di essa non riusciremo mai a vedere le voci inaspettate. E 'l'inaspettato voci che sono probabilmente i più importanti e più interessanti.

Executive Summary

Sia OSSEC e Logwatch sono eccellenti strumenti gratuiti. OSSEC eccelle in allarme quando un modello di attacco conosciuto ha luogo. Logwatch è uno strumento formidabile per riassumere un pezzo il tempo dei tronchi così che gli umani possono realmente dare un senso a ciò che sta accadendo. Combinando i due strumenti è possibile creare una difesa molto più solida in profondità postura. Il tutto diventa più grande della somma delle parti.

Combinando Logwatch e OSSEC - Parte 3

17 febbraio 2010

Nei miei ultimi due post ho discusso Logwatch e OSSEC, e come essi possono essere sfruttare per aumentare la vostra sicurezza. In questa puntata parlerò come installare entrambi di questi strumenti.

Installazione Logwatch

Logwatch è abbastanza facile da installare. In realtà, è installato di default su molte distribuzioni Linux in modo da avere già una copia sul vostro sistema. Per controllare, l'accesso come root e provare ad eseguire Logwatch con la "-v" interruttore. Se si vede:

[Root @ fubar logwatch] # logwatch-v

Logwatch 7.3.6 (rilasciata 05/19/07)

Logwatch è installato e di avere una copia della versione più recente. Se non si dispone dell'ultima versione, è possibile afferrare dalla pagina di download Logwatch .

Ci sono tre tipi di Logwatch che può essere scaricato; binari in formato RPM, sorgente in formato RPM o sorgenti, in una palla di catrame. Se il sistema supporta la gestione dei pacchetti RPM, l'RPM binario è la scelta migliore. E 'semplice da installare e RPM aggiorna automaticamente il software quando sono disponibili nuove versioni.

Installazione Logwatch Da RPM

Per installare la versione binaria del RPM, semplicemente l'accesso come root e passare alla directory dove avete scaricato il file RPM. Ora eseguire il comando:

rpm-U logwatch-7.3.6-1.noarch.rpm

Non dimenticare è possibile utilizzare il tasto TAB per il completamento automatico del nome del file piuttosto che dover digitare l'intera faccenda.

Installazione Logwatch da sorgenti

L'installazione da sorgenti è un po 'più lunghi. Ricordate che per poter installare il codice sorgente è necessario avere già un compilatore (come gcc) installato sul vostro sistema. Di accesso come root e accedere alla directory in cui avete scaricato la palla Tar. Per estrarre l'archivio, eseguire il comando:

tar xvzf logwatch-7.3.6.tar.gz

Vedrete una struttura di directory sotto la posizione corrente vengono creati e un sacco di file da copiare pollici Abbiamo ora bisogno di spostarsi nella directory di livello superiore che è stato creato:

logwatch cd-7.3.6

Al fine di Logwatch a correre, ci sono un sacco di directory che devono essere creati sul sistema. Questi sono documentate nel file README nella directory corrente. Fortunatamente, Logwatch include uno script di installazione che può fare tutto il lavoro per voi. Sfortunatamente, lo script ha i permessi impostati in modo sbagliato non verrà eseguito di default. Questo è abbastanza facile da risolvere ma con il comando chmod:

chmod 500 install_logwatch.sh

Ora siamo in grado di eseguire lo script per impostare il nostro sistema:

. / Install_logwatch.sh

Non dimenticare il punto all'inizio della riga.

Test Logwatch

Per testare la configurazione Logwatch, eseguire il comando:

logwatch | less

Vedrete il vostro schermo del terminale va in bianco, ma questo è normale. Alla fine vedrete un rapporto Logwatch ottenere stampati a schermo che è possibile navigare attraverso l'utilizzo del "Page Up" e "Page Down". Come accedere ci vuole per il rapporto di mostrare sullo schermo dipende dalla quantità di informazioni di log deve avere analizzato. Si potrebbe richiedere alcuni secondi o un paio di minuti. Ad ogni modo, che vi darà la possibilità di familiarizzare con il formato del report.

Installazione OSSEC

Come ho detto nel mio ultimo post, hai due opzioni di installazione con OSSEC, locale o client / server. In questo post ho intenzione di concentrarsi sul client / server di configurazione, in quanto è un po 'più complessa. Se si sta eseguendo un'installazione locale, è sufficiente selezionare l'opzione "locale" durante il processo di installazione e saltare la sezione su come configurare un canale protetto tra l'agente e il server.

Inizia con il Server

OSSEC utilizza la crittografia Blowfish per proteggere la comunicazione tra il client e il server. Blowfish è la chiave simmetrica basata, in modo da entrambe le parti devono sapere quale valore chiave da utilizzare per comunicare. Il server è responsabile della generazione della chiave simmetrica, quindi dobbiamo installare il software del primo server. Durante il client di installazione ci verrà chiesto, per un valore chiave quindi ovviamente avremo bisogno di avere a portata di mano che prima del tempo.

Ecco un suggerimento risparmio di tempo. Il valore della chiave è lungo e quasi impossibile da ricordare. Il modo più semplice per spostare il valore della chiave dal sistema server al sistema agente è quello di utilizzare SSH. Creare una connessione sicura al server OSSEC, ed estrarre la chiave appropriata (indicazioni fornite di seguito). In una finestra di terminale secondo, creare una sessione SSH al sistema in cui si intende installare l'agente. Quando l'installazione client richiede il valore della chiave, si può semplicemente copia / incolla tra i due terminal.

Installazione del server OSSEC

Il software del server è disponibile come una palla di catrame, in modo da poter prendere una copia della versione più recente dalla pagina di download OSSEC . Sarà quindi necessario per estrarre il contenuto della palla Tar:

tar xvzf OSSEC-HIDS-2.3.tar.gz

Quindi, entrare nella struttura di directory appena creata:

OSSEC cd-HIDS-2.3

OSSEC fornisce uno script di installazione per camminare attraverso il processo di installazione del server. Per avviare l', tipo di script:

. / Install.sh

Non dimenticare il punto all'inizio del comando. Ora verrà richiesto attraverso una serie di opzioni di installazione:

  • Lingua - Il valore di default è l'inglese. Cambiare se necessario.
  • Conferma di installazione - Premete Invio dopo aver letto lo schermo.
  • Installare tipo - Digitare "server" senza le virgolette e premere Invio.
  • Installare posizione - Accettare l'impostazione predefinita.
  • E-mail di notifica - di default è sì, selezionare se si vuole avvisi di posta elettronica. Se si seleziona Sì, verrà richiesto un valido indirizzo e-mail e server di posta.
  • Controllo di integrità - di default è sì. Selezionare se si desidera che il sistema locale periodicamente controllati per le intrusioni.
  • Individuazione del root kit - di default è sì. Buona opzione in quanto abbiamo bisogno di mantenere un alto livello di integrità di questo sistema.
  • Risposta attiva - di default è sì. Selezionare questa opzione se si desidera essere in grado di rispondere agli eventi.
  • Goccia Firewall - permette al server OSSEC a difendere è di per sé un attacco diretto se viene rilevato.
  • Lista bianca - Questo vi permetterà di aggiungere gli indirizzi IP da cui possibili attacchi saranno ignorati. Stare attenti con questa opzione. Se non avrà accesso console al server OSSEC, potrebbe essere saggio per identificare un indirizzo IP che può sempre ottenere in, dovrete solo garantire l'IP di origine è un sistema affidabile.
  • Abilita Syslog - di default è sì. Selezionare questa opzione se si desidera raccogliere i log di sistema che non è possibile eseguire un agente OSSEC (come i firewall, switch, router, access point, ecc.)
  • File di log da monitorare - Questa schermata identifica tutti i file di log OSSEC locale controllerà. E 'puramente informazioni, in modo tutto quello che puoi fare è premere Invio per spostare passato. Se notate uno o più file di registro mancanti dalla lista, è possibile aggiungere in seguito al file ossec.conf.

A questo punto OSSEC accederà al compilatore locale e installare tutti i file necessari al sistema. Una volta completata, è possibile avviare il server OSSEC eseguendo il comando:

/ Var / OSSEC / bin / OSSEC controllo avvio

Definizione agenti OSSEC

Non abbiamo ancora finito con il server OSSEC ancora. Quindi, abbiamo bisogno di pre-definire qualsiasi sistema che sarà in esecuzione l'agente OSSEC (client) del software. Questa operazione viene eseguita utilizzando il comando manage_agents. In primo luogo però, abbiamo bisogno di fare un po 'di compiti a casa. Fate una lista di tutti i sistemi che saranno in esecuzione il software OSSEC agente. Per ogni sistema, è necessario un nome descrittivo e indirizzo IP del sistema.

Ora, eseguire il seguente dalla riga di comando:

/ Var / OSSEC / bin / manage_agents

Questo produrrà il menu principale Gestione Agent. Premere il tasto "A" seguito dal tasto Invio per definire il primo sistema. Inserire un nome descrittivo per il primo sistema, seguito dall'indirizzo IP del sistema. Non preoccuparti per il numero ID agente. Basta accettare le impostazioni predefinite e OSSEC si auto-assegna il successivo numero ID disponibili. Dopo aver confermato le informazioni immesse, si torna al menu principale di Agent Manager. Ripetere la procedura per ogni sistema che sarà in esecuzione un agente OSSEC.

Tasti di Generazione

Dopo aver aggiunto in tutti i sistemi, è tempo di generare chiavi di crittografia. Questa operazione viene eseguita anche con l'utilità manage_agents. Se si chiude lo strumento dopo l'ultimo passaggio, è ora il rilancio.

Premere il tasto "E" seguito da Invio per selezionare il tasto "Estrai per un agente" opzione di menu. Ti verrà chiesto il numero di identificazione della chiave che si desidera estrarre. I nomi descrittivi e gli indirizzi IP sono elencati con ogni numero ID, quindi dovrebbe essere banale per identificare quali quello che si desidera. Inizia con il sistema che si intende installare il software dell'agente sul primo.

OSSEC agente di installazione su Linux

Quando si installa il software agente su un client Linux o UNIX, è possibile utilizzare la palla esattamente Tar stesso che abbiamo usato per installare il software server. Eseguire lo stesso script di installazione, ma questa volta quando viene richiesto per il tipo di installazione che si desidera eseguire, il tipo di "agente", seguito dal tasto Invio.

L'installazione cliente ha molte delle stesse richieste come l'installazione del server. Usare le informazioni qui sopra per guidare l'utente attraverso il processo. Il prompt che varieranno tuttavia è che vi sarà chiesto di fornire l'indirizzo IP del server OSSEC. Una volta completata, sarà OSSEC accedere al compilatore locale e installare tutti i file necessari al sistema.

Poi abbiamo bisogno di importare la chiave Blowfish dal server OSSEC. Mentre ancora sul sistema agente, eseguire il comando:

/ Var / OSSEC / bin / manage_agents

Quando il menu Manager Agent, selezionare "I" per importare la chiave Blowfish.

Quando la richiesta successiva, è necessario immettere manualmente la chiave appropriata Blowfish. Anche in questo caso, se si esegue SSH per entrambi i sistemi al tempo stesso, si può semplicemente copia / incolla tra i due terminal. Assicurarsi che la chiave è corretto, premere il tasto Invio, e poi selezionare "y" per confermare che la chiave sembra corretta. Si ritornerà al menu Agent Manager. Selezionare "q" per tornare alla riga di comando.

Ora non ci resta che avviare l'agente OSSEC. Puoi farlo eseguendo il comando seguente:

/ Var / OSSEC / bin / OSSEC controllo avvio

Si dovrebbe vedere tutti i componenti agente OSSEC start up, seguito da un messaggio "Completed".

OSSEC agente di installare su Windows

OSSEC ha un file eseguibile autoestraente che vi permetterà di installare il software agente su un sistema Windows. È sufficiente fare doppio clic sul file eseguibile per avviare il processo di installazione. Ti verrà richiesto di accettare la licenza e quali componenti si desidera installare. Basta seguire le istruzioni fino alla finestra agente OSSEC Manager.

La finestra di agente OSSEC manager vi chiederà l'indirizzo IP del server OSSEC. Sarà anche richiederà il valore della chiave Blowfish da usare, in modo da estrarre la chiave appropriata sul server e inserire il valore in questo campo. Assicurati di cancellare il messaggio in questo campo prima di incollare nella chiave Blowfish. In caso contrario, la comunicazione con il server potrebbe non riuscire.

Avanti, selezionare "Gestione" dal menu OSSEC Manager Agent, seguita da "Start OSSEC". Ora dovreste vedere il "Stato:" cambiare l'indicatore di "Running ...".

Test OSSEC

Una volta che avete il server e il software agente installato, avviato e configurato i tasti appropriati, è giunto il momento di controllare la nostra impostazione. Eseguire il seguente comando sul server OSSEC:

cd / var / OSSEC / logs

Ed estrarre il file ossec.log:

meno ossec.log

Controllare il file di log per eventuali errori. Un errore comune è che i rapporti OSSEC non è possibile inviare e-mail. Assicurarsi che il server di posta sia in esecuzione e che si tratta di accettare connessioni. Una volta soddisfatti con la configurazione del server, è giunto il momento di controllare gli agenti. Spostare verso il basso nella directory "segnalazioni":

cd avvisi

Ed estrarre il file alerts.log:

meno alerts.log

In particolare, siete alla ricerca di voci simile al seguente:

2010 17 febbraio 16:09:16 (desktop) 192.168.1.10-> OSSEC

Regola: 501 (livello 3) -> 'Nuovo agente OSSEC collegati.'

Src IP: (nessuno)

Utente: (nessuno)

OSSEC: Agente iniziare: 'test_system-> 192.168.1.10'.

Si dovrebbe vedere una voce per ogni sistema su cui è installato il software agente.

Più a venire

Caspita! Che è più che sufficiente per un post! Nel mio prossimo post farò entrare sfruttando Logwatch per analizzare tutte le informazioni di allarme generato da OSSEC.

Combinando Logwatch e OSSEC - Parte 2

16 febbraio 2010

Nel mio ultimo messaggio ho descritto come Logwatch potrebbero essere utilizzati per semplificare il processo di revisione del registro. In questo post vedremo OSSEC e quello che porta in tavola.

Che cosa è OSSEC?

OSSEC , abbreviazione di "Sicurezza Open Source", è un host basato su sistema di rilevamento delle intrusioni (HIDS). In altre parole, è progettato per rilevare attacchi o violazioni delle policy, se e quando si verificano. Anche se non ha la capacità di proteggere contro gli attacchi sconosciuti o 0-Day (che sarebbe la prevenzione delle intrusioni basata su host), che include una vasta gamma di strumenti che consentono di identificare una intrusione quando si verifica, così come la misura del danno che è stato causato.

Le piattaforme supportate

Per sfruttare al meglio tutte le caratteristiche OSSEC ha da offrire, è necessario eseguire un agente sul sistema protetto. Agenti OSSEC può essere eseguito su Windows, Mac OS X, Linux, e una vasta gamma di sistemi UNIX. Se siete interessati solo alla parte di analisi dei log però, una gamma ancora più ampia di sistemi possono essere supportati. Ciò include hardware di Cisco e Juniper. Un certo numero di prodotti specifici sono supportati anche come firewall Checkpoint, Symantec Anti-Virus, Snort, Squid, e Arpwatch, solo per citarne alcuni.

Quando si installa OSSEC si hanno due opzioni di configurazione, locale o client / server. Una installazione locale viene utilizzata quando è necessario eseguire tutto su un unico sistema. Il client / server di installazione consente di eseguire un ambiente distribuito proteggendo i sistemi multipli allo stesso tempo. Mentre la maggior parte delle distribuzioni sono client / server basato, se si vuole dare un giro si può facilmente eseguire tutto in un sistema singolo test utilizzando una installazione locale OSSEC.

Analisi log

OSSEC include un log-based Intrusion Detection System (LIDS). Questa ha la capacità di rivedere i file di log in tempo quasi reale, mentre li scrutando per schemi di attacco conosciuti. Quando un registro viene generato su un sistema protetto, l'agente si occupa di trasmettere in modo sicuro l'(cifratura Blowfish tramite una pre-shared secret) accedere nuovamente al server. Il server si occuperà quindi di eseguire l'analisi.

La maggior parte degli strumenti di analisi log processo le loro regole in un formato lineare. Con questo voglio dire se abbiamo 500 regole, la regola si è selezionata, regola due, poi la regola tre, e così via fino a quando un match è trovato o si arriva alla fine del set di regole. OSSEC funziona un po 'diverso in quanto implementa una struttura ieratica alle regole. Le voci del registro vengono prima classificati e poi verificati solo contro qualsiasi normativa è opportuna. Il risultato è che, piuttosto che dover elaborare tutte le 500 regole, maggior parte degli eventi avrà confrontati con 10 regole o meno. Questo riduce drasticamente la quantità di overhead necessario per elaborare il set di regole.

Verifica integrità

OSSEC include uno strumento denominato Syscheck per eseguire il controllo dell'integrità dei file e delle directory. Se si esegue un agente di Windows, è possibile anche includere i tasti specifici all'interno del registro di Windows per essere controllati sia. Modifiche apportate ai file possono essere rilevati utilizzando sia MD-5 e SHA-1 algoritmi hash. Il sistema è estremamente personalizzabile. È possibile includere o escludere singoli file o intere strutture di directory. È anche possibile impostare un flag per rilevare la creazione di nuovi file.

L'agente software è progettato per utilizzare una minima quantità di CPU durante il controllo di integrità. Anche se questo significa il controllo richiederà più tempo, ma aiuta anche a ridurre al minimo il calo di performance del sistema. Informazioni hash viene trasmessa al server. Il server si occuperà quindi di eseguire il confronto hash per vedere se qualcuno dei file critici del sistema sono state modificate. Il server memorizza anche una copia della politica di controllo di integrità, in modo che se cambia la politica sono fatte per l'agente, possono essere rilevate e segnalate pure.

Rilevamento delle anomalie

OSSEC va ben oltre la verifica del log per verificare l'integrità del sistema. Policy di utilizzo possono essere gestiti centralmente dal server, e poi spinto fuori agli agenti appropriati. Per esempio si potrebbe definire una politica che per quanto riguarda le applicazioni Windows sono accettabili (Office, Firefox, ecc) e quali no (client di messaggistica istantanea, Skype, ecc.) È anche possibile definire le opzioni di configurazione accettabile come verificare che gli hash NT vengono utilizzati per la password memorizzata, ma non gli hash LanMan.

OSSEC include una serie di altre cose interessanti al fine di contribuire a verificare l'integrità di un sistema. Per esempio OSSEC ha la capacità di eseguire comandi da agente e monitorare l'uscita che viene generato. Per esempio si potrebbe avere l'agente Linux eseguire il comando "df" a intervalli regolari e generare un allarme se l'utilizzo del disco supera il 90%. Un esempio Windows potrebbe essere quello di avere OSSEC generare un avviso ogni volta che file di informazioni viene scritto flussi di dati alternativi nell'area di NTFS.

Risposta attivo

Infine, OSSEC include la possibilità di rispondere quando viene rilevata un'attività sospetta. Le risposte possono essere generati dal server o l'agente, che mai si specifica. Le risposte possono essere benigni la generazione di una e-mail di avviso, di essere come proattiva come il blocco di un indirizzo IP remoto per un periodo limitato di tempo. Ci sono una serie di script inclusi risposta attiva è possibile disegnare, oppure si può facilmente scrivere il vostro.

Architettura sicuro

Gli autori OSSEC hanno fatto di tutto per proteggere tutti i componenti all'interno del prodotto. Attività quali il controllo dell'integrità vengono eseguite sul server, piuttosto che l'agente, così l'affidabilità del hash non può essere compromessa durante un attacco. I processi sono gestiti con il più basso livello di autorizzazioni possibili e diversi account utilizzati per eseguire ogni componente OSSEC. Ciò significa che un compromesso di una domanda unica ai OSSEC non immediatamente portare a un compromesso del pacchetto completo. Inoltre, la maggior parte dei componenti sono gestiti all'interno di una prigione chroot così il loro accesso al sistema è ulteriormente ristretta.

Le parole finali

Mentre OSSEC è uno strumento potente, è importante ricordare che si tratta di un HIDS e non una soluzione di gestione dei log. OSSEC possibile rivedere le voci del registro alla ricerca di segnali sospetti, ma sarà solo salvare le informazioni allerta. Così, mentre OSSEC non sostituisce il tuo Information Security Management (SIM) soluzione, può certamente aumentare la. È possibile configurare facilmente OSSEC a inoltrare tutte le segnalazioni che genera a un server centrale di registrazione .

Mentre OSSEC è un software open source, Trend Micro è principalmente lo sviluppo. Se hai bisogno di supporto commerciale, è possibile acquistare un contratto di assistenza attraverso di loro ad un costo ragionevole.

Più a venire

Nella mia prossima puntata vedremo l'installazione OSSEC e Logwatch. Dopo di che, ci sposteremo in integrando le due cose insieme.

Combinando Logwatch e OSSEC

15 febbraio 2010

Recentemente ho avuto uno studente mi chiede una domanda riguardo l'integrazione di Logwatch con OSSEC. Mi sentivo come se questa fosse un'idea complessa e ancora abbastanza fresco che è garantita una serie di post per coprire per intero. Quindi nei prossimi giorni vi parlerò di ciascuno di questi strumenti, come integrare insieme, così come quello che la visibilità di sicurezza aggiuntive possono essere acquisite una volta che il processo è completo.

Che cosa è Logwatch?

Logwatch è un ottimo strumento open source per la generazione di report giornalieri umano log leggibile. Le voci del registro tendono a cadere in una delle tre categorie:

  • Cose che conosci è il male
  • Cose che conosci è normale e può essere ignorato
  • Tutto il resto

Si tratta di quella categoria "tutto il resto" dove Logwatch brilla davvero. Per le cose che sappiamo è male, ci sarà l'installazione una qualche forma di sistema di allarme. Per esempio possiamo scrivere una firma allarme che avverte l'analista di sicurezza quando un account viene attacco a forza bruta. Ma per quanto riguarda gli attacchi che non conoscono o non sono sicuro di quello che aspetto hanno? Questo sarebbe un chiaro esempio di quella categoria "tutto il resto". Il traffico non è normale, ma non abbiamo visto prima di avere una firma in attesa di generare un avviso. Dal momento che non saremo in grado di catturare l'attacco in tempo reale, dovremo catturare durante una revisione registro giornaliero.

Naturalmente il problema facendo recensioni registro giornaliero è che si tratta di un'operazione noiosa e lunga. Voglio dire siamo onesti, chi vuole davvero trascorrere la loro giornata rivedere milione più voci di registro? Anche se hai fatto, sei sicuro che sarebbe in realtà catturare il traffico fuori dal normale?

Come funziona

Cosa Logwatch fa molto bene è permesso di riorganizzare i dati in un formato che è più facile per gli esseri umani da seguire. La sua vera forza è che permette di spostare la roba si capisce dal modo (normale o male), in modo che le voci di registro inaspettato risaltare come un pollice irritato. In altre parole, Logwatch consente di riassumere le voci di registro in modo insolito la roba è più facile da individuare.

Quello che mi piace molto di Logwatch è che non si perde nulla. Molti strumenti di revisione log solo indicarti la roba che è stata pre-definito come il male. Il problema che tutti condividiamo è che quando qualcosa di male, ma imprevisto, vola proprio sotto il filo. Perché Logwatch consente di vedere tutto, non è più perdere l'inaspettato.

Logwatch In Azione

Consente di discutere su come Logwatch funziona utilizzando il SSH servizio server come esempio. Gli script a che fare con SSH sono già stati definiti all'interno Logwatch, quindi non c'è bisogno di fare alcun tweaking per ricevere le caratteristiche ci accingiamo a discutere.

Nel rivedere un file di log, la Logwatch prima cosa che fa è riorganizzare le voci di registro in base al tipo di messaggi. Per esempio tutti gli accessi di successo SSH sono raggruppati insieme, così come gli errori di accesso troppi, si è rifiutato connessioni, account bloccati, conti senza un guscio proprio, protocollo mis-match, ecc ecc ecc Una volta che tutti i messaggi SSH sono raggruppati per il loro tipo, i dati vengono poi riassunti per ridurre la quantità di informazioni che vengono segnalati.

Per esempio, il valore predefinito è quello di riassumere i tentativi di accesso non riuscito per account e IP di origine. Così un tipico fallito sezione del report di accesso potrebbe essere simile a questa:

Accessi non riusciti da questi:

bsmith / password da 1.2.3.4: 637 time (s)

jsmith / password da 1.2.3.5: 2 time (s)

Quindi, piuttosto che dover rivedere le voci di registro 639 segnalare un brutto tentativo di accesso, abbiamo tutte le informazioni pertinenti riassunte in tre linee (se si include il titolo). Continuare questo processo per tutti gli altri messaggi SSH, ed abbiamo drasticamente ridotto la quantità di tempo necessario per rivedere i nostri log.

Ma cosa succede se succede qualcosa che Logwatch non è pre-programmato per riconoscere? Quando una voce del registro inaspettato si trova, Logwatch aggiunge una sezione alla fine del rapporto di servizio denominata "Voci senza pari". Quindi, se vediamo questo titolo nella sezione server SSH, sappiamo che un evento si è verificato che è o anomali o imprevisti per il servizio SSH. Questo potrebbe benissimo essere una qualche forma di attacco che non siamo consapevoli sta facendo il giro.

Da mettere a fuoco la sezione voci senza pari, siamo in grado di identificare rapidamente le attività di inaspettato. Come ho detto prima, questo è davvero l'obiettivo principale di fare recensioni registro giornaliero. Per trovare la roba non ci aspettiamo che furtivamente passato il nostro sistema di allarme. Logwatch rende questo processo più rapido e indolore possibile.

Riepilogo delle caratteristiche

Nell'esempio di cui sopra ho parlato di fare recensioni registro giornaliero, ma ad essere onesti Logwatch è altamente personalizzabile. È possibile specificare qualsiasi intervallo che si desidera utilizzare fino a un intervallo di un secondo. Per esempio, diciamo che sto studiando una intrusione, invece di effettuare una rassegna quotidiana di registro. Ho potuto specificare un intervallo come "2010/02/14 17:05:00 per quell'ora" mettere a fuoco in pieno sulle informazioni che mi interessano. Posso anche concentrarsi su un file di log o servizio specifico.

Il livello di dettaglio del report è anche personalizzabile. In genere quando avete a che fare con la sicurezza si ottiene l'abitudine di volere sempre il massimo livello di dettaglio del report. Per essere onesti, con Logwatch un alto livello di dettaglio è probabilmente più che avrete bisogno di mai. Personalmente io di solito bastone con "med" per le medie e che funziona bene. È inoltre possibile specificare il livello di segnalazione come "basso" o "alta" o usare un intervallo numerico di 0-10 per un più alto livello di granularità (basso = 0, med = 5, alta = 10).

Logwatch può essere eseguito automaticamente o come un processo manuale. Tipicamente si vuole impostare in modo da eseguire automaticamente ogni giorno e vale la pena riassumere una giornata di voci di registro. Se hai bisogno di espandere o concentrare il report, è sempre possibile eseguire Logwatch dalla riga di comando, specificando esattamente quello che vuoi vedere. È quindi possibile utilizzare il "risparmio" per specificare un nome di relazione e directory per l'archiviazione.

Più a venire

Quanto sopra dovrebbe darvi una buona idea per le caratteristiche Logwatch può portare al tavolo. Nel prossimo post parlerò OSSEC nello stesso livello di dettaglio. Dopo di che, finisco su come installare ogni strumento e come integrarli tra loro.

Impostazione di un Information Security Management System-Parte 6

20 agosto 2009

Finora in questa serie abbiamo coperto:

  • Definizione di un ambito e punto di riferimento per la SIM
  • Importanza di costruire invece di comprare il vostro primo sistema
  • Architettura e pianificazione della capacità
  • Fasi di implementazione consigliati
  • Selezione di una piattaforma server centralizzato di registrazione
  • Come accettare le voci del registro remoto
  • Impianto, la gravità e la priorità
  • Come ordinare i messaggi di log
  • Configurazione di apparecchi e sistemi operativi di presentare le voci di registro

Fresco. Così abbiamo le voci di registro per un certo numero di sistemi essere raccolte su un server centralizzato. Ora arriva il compito più importante, facendo leva su tali informazioni. Voci di registro verranno raggruppati in due categorie: i messaggi critici che vogliamo sapere subito, e le voci di registro che sarà coinvolto come parte di un processo di revisione regolare.

Lista nera vs. Whitelist

Nel rivedere i messaggi di log, abbiamo due atteggiamenti possibili che possiamo usare. Il primo è denominato lista nera. Con il metodo lista nera si definisce ciò che rende un evento interessante abbastanza da giustificare reporting. Questo è simile a come software antivirus rileva malware o il processo che usiamo per filtrare lo spam.

Come la maggior parte delle cose nella vita, blacklist ha alcuni aspetti buoni e cattivi. Sul lato positivo, di solito è abbastanza facile scrivere una firma se sappiamo ciò che vogliamo cercare. Firme possibile prevedere con precisione per ridurre al minimo il numero di falsi positivi che incontriamo. Il problema con la lista nera è che dobbiamo sapere cosa stiamo cercando. Se un nuovo attacco genera una firma unica che abbiamo mai incontrato in passato, un sistema di liste nere probabilmente perdere l'evento, perché nessuna firma è stata definita.

Con whitelist definiamo gli eventi si capisce, e quindi focalizzare la nostra attenzione sui messaggi di log nuovo e unico che si incontrano. Sul lato positivo ci sono molte più probabilità di catturare il taglio attacchi bordo. Whitelist tende ad essere relativamente rumorosi ma dal momento che siamo tenuti a incontrare messaggi di log uniche che non sono indicativi di un evento di protezione.

Allora che dovremmo usare? Buona difesa in profondità le pratiche ci dicono di usare entrambi. ;)

In tempo reale allarmi

Siamo in grado di sfruttare blacklist per eseguire in tempo reale avvisi di evento vogliamo essere messi a conoscenza della non appena si verificano. Lista nera deve essere utilizzato solo per i tipi a basso rumore di eventi. In altre parole, vogliamo restare con la scrittura di firme per eventi che hanno un'alta probabilità di essere un vero problema di sicurezza. Buoni esempi sono:

  • Nome diverso errori di accesso tutti dallo stesso indirizzo IP in un breve lasso di tempo
  • Molteplici errori HTTP 403 viene generato da un singolo indirizzo IP in un breve lasso di tempo
  • Sistemi interni ricevono molti errori ICMP o reset TCP in un breve lasso di tempo

Per poter eseguire in tempo reale allarme, abbiamo bisogno di un software che controllerà i log in tempo reale. Le voci di registro dovrebbero essere controllati firme definito, che anche indicare cosa fare quando si verifica l'evento.

Swatch

Uno dei più facili strumenti da utilizzare per le voci del registro di monitoraggio è Swatch . Swatch è basato su Perl. Ciò significa che, mentre è stato progettato per i sistemi UNIX e Linux, è possibile farlo funzionare su Windows se avete installato Perl. La semplicità è la più grande forza sia di Swatch e debolezza. Mentre Swatch è relativamente facile da implementare, ma è anche un po 'limitato nelle sue funzionalità. Eppure, se sei un nuovo login, Swatch rende un ottimo strumento primo per avvertire in tempo reale.

Per distribuire Swatch, sarà necessario creare un unico file di configurazione per ogni file di log che si desidera monitorare. Nel file di configurazione diremo Swatch cosa cercare in quel particolare file di log, e cosa fare quando l'evento viene rilevato.

Per esempio, diciamo che stiamo per avere Swatch verificare i log di errore del server web. Ci potrebbe voler creare una voce simile al seguente nel file di configurazione di Swatch per il log di errore:

# Cercate buffer overflow

watchfor / client negato dalla configurazione del server | Nome file troppo lungo /

mail = noc@fubar.org: webmaster@fubar.org, subject = Web server tentativo di overflow

La linea che inizia con un "#" è semplicemente il commento sulla firma. La linea che identifica watchfor stringa di caratteri (s) vogliamo definire come interessanti. In particolare questa regola abbiamo definito due stringhe diverse, "client negato dalla configurazione del server" e "nome file troppo lungo", come interessante. Il carattere pipe tra le corde agisce come una logica "o". Se uno dei due stringa è incontrato, il parametro di posta definisce due differenti indirizzi e-mail dobbiamo contatto. L'oggetto dell'e-mail sarà "server Web tentativo troppo pieno", mentre il corpo dell'e-mail sarà la voce di registro vero e proprio.

Se ci sono altri modelli che vogliamo rilevare, potremmo aggiungere watchfor ulteriori dichiarazioni e mail. Se vogliamo fare di più che inviare una e-mail, il parametro exec può essere utilizzato per eseguire qualsiasi applicazione trova sul sistema locale. Il parametro soglia può essere utilizzato anche per limitare il tasso di segnalazione di eventi.

Evento Coordinatore semplice (SEC)

SEC è uno strumento straordinario di avviso è possibile scaricare dal sito Web principale . Supporta BSD e Linux, e viene fornito con una serie di popolari distribuzioni Linux. SEC supporta pienamente le espressioni regolari e ti permette di creare firme estremamente granulare.

La regola è formato come segue:

tipo = Metodo di rilevazione

PTYPE = tipo di modello (espressione regolare, match stringa)

= Che modello per la ricerca di

desc = Descrizione (può essere una variabile)

action = Cosa fare quando rilevato

C'è un ottimo archivio di pre-scritto le regole è possibile utilizzare tale vale la pena guardare. È possibile abbinare sui modelli multipli, definire soglie multiple, tutte durante l'elaborazione di centinaia di messaggi di log al secondo. Circa l'unico inconveniente della SEC è che hai bisogno di una buona comprensione delle espressioni regolari di utilizzare lo strumento in modo efficace. Ancora, lo strumento può essere molto più potente e flessibile rispetto Swatch.

Dove posso trovare più idee di avviso?

Sono stato coinvolto con la creazione dell'originale SANS Top 5 Report Log . Per il periodo aprile 2009 Vertice Log ho aggiornato la mia presentazione per rompere esempi di report in basso rumore e le categorie di rumore. Nulla sulla lista basso rumore sarebbe un buon candidato per allertare. Qualcosa nella sezione rumore elevato è meglio monitorato attraverso rapporti giornalieri.

Report giornaliero

Così abbiamo sfruttato per generare blacklist nostri avvisi in tempo reale. Noi ora whitelisting leva per aiutare i modelli di traffico evidenziano sconosciuto ma interessante nei nostri rapporti quotidiani.

Quando si tratta di rapporti quotidiani, si tende a gravitare verso i numeri grandi. Quali sono i 5 IP trasferimento dei dati? Quale indirizzo e-mail inviata la maggior parte dei messaggi? Mentre i grandi numeri sono certamente importanti, è stata la mia esperienza che gli eventi di sicurezza è necessario preoccuparsi più generare il minor numero di voci di registro. Gli aggressori intelligente di tutto per rimanere nascosto all'interno del rumore. Quindi l'unico modo per trovarli è quello di ridurre il rapporto segnale-rumore.

Io l'autore del tracciato di sicurezza perimetrale per il SANS. Uno dei laboratori che ho i miei studenti è quello di eseguire il parsing di un file di log di 200.000 linee. L'obiettivo è quello di individuare i modelli interessanti così come formulare il riesame in un processo automatizzato. La maggior parte delle persone trova il port scanner in quanto è piuttosto rumoroso. Alcuni hanno anche posto l'indirizzo IP di eseguire attacchi contro il livello di applicazione Web server. Ciò che molte persone mancano tuttavia, sono le sei linee che sono un indizio abbastanza chiaro che un sistema interno è già compromessa e chiamare a casa per marciare ordini. Come si fa a trovare i 6 linee? Da whitelist tutto ciò che si capisce e concentrandosi su ciò che mai è di sinistra.

Quindi va bene per i nostri rapporti giornalieri a darci belle tabelle con numeri grandi. Uno dei rapporti ha comunque essere in grado di spostare tutti i crud di lato in modo da poter meglio individuare le picchiettii interessante.

Logwatch

Uno dei migliori strumenti per fare una rassegna quotidiana di log è Logwatch . Logwatch riassumerà tutti i modelli di log lo capisce, evidenziando nulla senza una firma predefinita. Il modo migliore per capire questa funzione è quello di guardare ad un esempio.

SSHD ucciso: 2 Time (s)

SSHD iniziate: 1 Time (s)

Connessioni:

Accessi non riusciti da questi:

msmith / password da 1.3.247.11: 6 Tempo (s)

jsmith / password da 1.3.247.11: 5 tempo (s)

Psmith / password da 1.3.247.11: 4 time (s)

Gli utenti che accedono attraverso sshd:

jjones connesso dal tramonto (1.3.247.9) utilizzando publickey: 146 Times (s)

jsmith effettuato l'accesso da dialup5533.wnskvtao.sover.net (216.114.181.200) utilizzando la password: 1 Times (s)

jsmith effettuato l'accesso da dialup984.wnskvtao.sover.net (216.114.163.223) utilizzando la password: 1 Times (s)

bjones effettuato l'accesso da charlie (1.3.247.11) utilizzando publickey: 444 Times (s)

jsmith connesso da 192.168.1.173 password utilizzando: 2 Times (s)

djones effettuato l'accesso da charlie (1.3.247.11), utilizzando la password: 47 volte (s)

** Voci senza precedenti **

Ricevuto disconnettersi da 148.64.147.168: 3: scambio della chiave fallita.

Ricevuto disconnettersi da 216.114.160.132: 11: Tutti i canali aperti chiuso

acquisiti da 146.87.114.150 con SSH-1.0-SSH_Version_Mapper. Niente panico.

acquisiti da 211.184.226.99 con SSH-1.0-SSH_Version_Mapper. Niente panico.

Nel Logwatch Nell'esempio precedente viene utilizzato per riassumere l'attività SSH. Comprende il servizio viene interrotto e avviato, tentativi di accesso così come accessi riusciti. Tutte queste informazioni vengono visualizzate in formato riassunto così è più facile da digerire. Per esempio non sappiamo esattamente quando msmith inserito correttamente la password, ma vediamo è accaduto sei volte, tutte da indirizzi IP 1.3.247.11. Così invece di avere sei linee da digerire, abbiamo solo bisogno di guardare a uno. Se vogliamo vedere ogni voce specifica di registro, possiamo sempre fare riferimento ai registri originali.

Ora guarda al "senza precedenti voci" sezione. Ognuno di questi è un evento che Logwatch non ha una firma. Piuttosto che li ignorano, che accadrebbe con un sistema basato lista nera, sono riassunti qui per noi a rivedere. Abbiamo poi la possibilità di generare una firma per una voce specifica in modo da otterrà categorizzati in modo simile al processo e le sezioni di accesso.

Chiaramente questo ci offre il meglio dei due mondi. La relazione di cui sopra rappresenta un po 'oltre 650 linee di valore di voci di registro, riassunti giù in un facile leggere il rapporto. Ancora più importante, nessuno dei voci di registro doveva essere ignorato in modo da produrre presente relazione di sintesi.

Al di là di reportistica giornaliera

Si può anche essere utile per eseguire analisi a lungo termine di tendenza e di data mining sui dati di log. Questo può aiutare a rivelare modelli che normalmente non vengono rilevati quando i registri per una piccola istantanea nel tempo (come 24 ore) viene rivisto. Probabilmente uno dei migliori strumenti disponibili per affrontare con un sacco di dati è Splunk .

Splunk

Splunk è disponibile come versione gratuita che è limitata a 500 MB di lavorazione al giorno, oppure si può investire nella versione commerciale che supporta un numero illimitato di elaborazione dati. Splunk è estremamente flessibile ai dati di accettare. Può agire come un server di logging centralizzato, oppure è possibile trasferire file attraverso una serie di metodi tra cui FTP e HTTP. Una volta che i dati vengono ricevuti, gli indici Splunk ogni campo in ogni file di log. Questo offre l'ineguagliabile capacità di ordinamento e ricerca.

Le caratteristiche complete sono Splunk sono troppo numerosi per entrare in questo post. Controllare il loro sito per un elenco completo delle funzioni supportate. Che Splunk è estremamente bravo a manipolare e reporting è in un gran numero di voci di registro. E 'in grado di indicizzare, cercare e segnalare miliardi di voci di registro al secondo. Questo lo rende estremamente utile per la generazione di rapporti a lungo termine tendenza o l'esecuzione di ricerche salvate per scopi di data mining.

Executive Summary

Ci siamo arrivati ​​alla fine del percorso. Speriamo che vi sembrerà di avere una migliore gestione su come implementare una soluzione centralizzata di registrazione, e come sfruttare al meglio il vostro ambiente sicuro. Se avete domande, non esitate a goccia un commento. :)

Impostazione di un Information Security Management System-Part5

14 Agosto 2009

Nel mio ultimo post ho parlato di come un server di registrazione utilizza valore di priorità di un messaggio per ordinare i messaggi di log in arrivo. In questa puntata parlerò di connettività di prova, così come come ottenere vari ingranaggi sul filo di presentare le loro voci di registro a un server centralizzato.

Requisiti

Affinché un sistema a presentare le voci di registro, deve avere il supporto per Syslog. Voci di registro deve essere trasmessa in chiaro a porta UDP/514 sul server di log. Se si utilizza rsyslog sul server, TCP/514 è accettabile pure.

Inserito voci lunga dovrebbe includere le seguenti informazioni:

  • Un valore di priorità (in formato <PRI>) all'inizio del payload
  • Il nome della presentazione della domanda la voce di registro
  • L'ID di processo utilizzato dall'applicazione
  • Il corpo dei messaggi di log

Ma ad essere onesti, Syslog non è molto esigente. Si tenterà di registrare qualsiasi cosa inviata alla sua porta di ascolto come una voce lunga. Se un valore di priorità non è presente, si registra l'ingresso a qualsiasi file viene utilizzato per la struttura 1. Tipicamente questo è / var / log / messages.

Verifica della connettività

Durante la distribuzione di una nuova impostazione, mi piace per verificare la connettività tra i client prime e il server di log. Se la registrazione non funziona, si vuole essere in grado di isolare l'area problema. I problemi tipici includono:

  • Cliente configurata in modo errato
  • Firewall nel modo in cui (sul client, il filo, o il server di registrazione)
  • Di server configurati in modo errato

Si vuole monitorare il file di messaggi sul server di registrazione per garantire la voce del registro prova è ricevuto. Sul server di log, eseguire il seguente comando:

tail-f / var / log / messages

La coda si aprirà il file di log di sola lettura e stampa le ultime cinque righe. Come nuove voci di registro sono stati ricevuti, avranno stampato sullo schermo pure.

Per generare una voce di registro di prova, mi piace usare Netcat . Netcat può essere utilizzato da qualsiasi sistema Windows, Linux o UNIX. Dal sistema di prova, eseguire il comando:

echo 'questa è una voce di prova UDP log' | nc-u-w 1 <indirizzo IP del server> registrazione 514

Dovreste vedere la parte eco del comando compaiono nella directory / var / log / messages file sul server di log. In caso contrario, lanciare un packet sniffer e vedere se è possibile determinare quando l'inosservanza si sta verificando. Se si desidera verificare la connettività TCP pure, basta eseguire nuovamente il comando lasciando fuori il Netcat "-u" switch:

echo 'questa è una voce di prova TCP log' | nc-w 1 <indirizzo IP di registrazione server> 514

Se entrambe le voci sono ricevuti, siamo pronti per iniziare i dispositivi di puntamento al nostro server di log.

Hardware di rete

La maggior parte dell'hardware di rete supporta Syslog tramite UDP/514. E 'solo una questione di passare attraverso la documentazione e determinando l'apposito comando di set per l'invio di voci di registro a un server remoto.

Se si sta utilizzando Cisco IOS, eseguire le seguenti modalità di configurazione globale:

<indirizzo disboscamento di server> registrazione

Se si desidera modificare la funzione di registrazione da "uso locale da 7" a qualcos'altro, il comando è:

registrazione <facility <nome impianto breve

Così per cambiare impianto di registrazione a "uso locale 3", il comando sarà:

impianto di registrazione local3

Linux e UNIX

Ci sono una serie di alternative Syslog disponibile per Linux e UNIX. In questa sezione tratteremo come ottenere Syslog e rsyslog di trasmettere i loro messaggi di log su un server remoto.

Syslog

Se il client è in esecuzione Syslog, sarà necessario modificare il file / etc / syslog.conf. Aggiungere la seguente riga alla fine del file:

*.* @ <indirizzo IP del server> registrazione

Quindi, un esempio potrebbe essere:

*.* @ 192.168.1.150

Si noti lo spazio bianco tra il match wild card e l'indirizzo IP remoto deve essere caratteri di tabulazione. Se si utilizzano spazi, Sysylog non sarà in grado di analizzare il file. Salvare e chiudere il file, quindi riavviare Syslog per attivare i cambiamenti.

rsyslog

Con rsyslog abbiamo la possibilità di inoltrare i nostri messaggi di log via UDP o TCP. In entrambi i casi ci sarà bisogno di modificare il file / etc / rsyslog.conf. Per inoltrare le voci lunghe utilizzando UDP, aggiungere la seguente riga alla fine del file:

*.* @ <indirizzo IP di registrazione server>: <porta>

Quindi, un esempio potrebbe essere:

*.* @ 192.168.1.150:514

Se vogliamo utilizzare il protocollo TCP invece, usiamo semplicemente due "@" simboli:

*.* @ @ 192.168.1.150:514

Una volta completato salvare e uscire dal file. Avrete bisogno di riavviare rsyslog per attivare i cambiamenti.

Sistemi Windows

Come accennato in un post precedente, Windows non include il supporto per Syslog. Questo significa che è necessario un software di terze parti per convertire il vostro log in tempo reale e li trasmette ad un server di log. Il sito Web Loganalysis ha una lista di possibili soluzioni.

Ai fini di questo post, tratteremo Snare . E 'gratuito per l'uso, può essere licenza commerciale, e hanno un processo di distribuzione molto semplice.

Una volta scaricato il software, è necessario configurarlo per il sistema. Questo è mostrato nella Figura # 1. Laccio ha bisogno di conoscere la posizione del server di registrazione così come quello che struttura e livello di gravità da usare. Una volta completa, cliccare su "Ultimi eventi" pozione menù per vedere quali specifiche voci di registro del Visualizzatore eventi rullante è l'inoltro al server di registrazione.

snare-config

Executive Summary

In questo post ho parlato di test di connettività a un server di registrazione, così come come configurare i client per centralizzare i propri log. Nel prossimo post vi parlerò di cosa cercare in un strumento di reportistica giornaliera, così come il tempo reale allarme.

Impostazione di un Information Security Management System-Part4

12 Agosto 2009

Nel post precedente ho parlato di come impostare un server di registrazione che accetterà le voci del registro remoto. In questa puntata vi parlerò di come ordinare le voci del registro in file specifici.

Impianto, la gravità e la priorità

Parliamo di come server di registrazione capire quale file per memorizzare una voce di registro quando viene ricevuto. I messaggi di log contengono due parametri descrittivi, struttura e la gravità. Quando questi due parametri vengono combinati, il valore viene indicato come la priorità del messaggio di log.

Facilità

Impianto definisce il tipo di processo che ha generato la voce di registro. Per esempio tutti i server di posta sono tenuti a identificare le loro voci di registro sono parte della struttura "mail". Processi FTP usare la funzione FTP, i processi NTP usare la funzione NTP, e così via. RFC 3164 definisce le strutture di valido, ma ecco la lista:

Fondo numerica

Codice

0 messaggi del kernel (kern)

1 utente a livello di messaggi (utente) - di default se non specificato

2 sistema di posta elettronica (mail)

3 demoni di sistema (demone)

4 sicurezza / autorizzazione (auth)

5 nell'abitazione syslogd (syslog)

6 stampante sottosistema linea (lpr)

7 notizie sottosistema di rete (news)

8 sottosistema UUCP (uucp)

Ore 9 demone

10 di sicurezza / autorizzazione (authpriv)

11 demone FTP (ftp)

12 NTP sottosistema (NTP)

13 registro di controllo

14 Registro degli avvisi

15 clock daemon (cron)

16 0 uso locale (local0)

17 uso locale 1 (local1)

18 uso locale 2 (local2)

19 uso locale 3 (local3)

20 uso locale 4 (LOCAL4)

21 uso locale 5 (local5)

22 uso locali 6 (local6)

23 uso locale 7 (LOCAL7)

L '"uso locale" strutture sono simili a indirizzi privati ​​in tutto il mondo IP. Queste strutture non sono riservati, e sono disponibili per chiunque di utilizzare come meglio credono.

Impianto di problemi

Ci sono un paio di problemi qui. Per iniziare, dove è la struttura del server Web? Questa lista è stata generata nel 1987 prima di server Web (o Gopher è per questo) l'esistenza. Così alcuni dei servizi che usiamo oggi (VoIP, SQL, ecc) sono mancanti. Inoltre, alcuni dei servizi elencati di solito non vengono utilizzati in un ambiente aziendale. UUCP e Network News (NNTP) sono ottimi esempi.

La mancanza dei servizi attuali ha causato molti venditori ad affidarsi pesantemente delle strutture uso locale. Ciò può causare potenziali conflitti quando arriviamo in nostro ordinamento voci di registro. Per esempio Linux usa uso locale da 7 a identificare i suoi tempi di avvio le voci di registro. Apache utilizza anche l'uso locale di 7 per gli errori del server web. Quindi la strada potrebbe essere difficile per noi per ordinare gli errori web e messaggi di boot nei file di registro diverse.

Un altro problema è che non esiste una descrizione dettagliata su ciascuno di questi impianti. Questo può rendere un po 'difficile per un programmatore per identificare quale usare. Per esempio, diciamo che abbiamo scritto un programma che autentica l'utente per l'accesso alla rete. Quale struttura dovremmo usare? Impianto di 4 e 10 sembrano le più probabili, ma le loro descrizioni sono identiche. Come si fa a scegliere? Se il nostro programma viene eseguito come processo in background in realtà dovremmo scegliere impianto di 3 invece?

Si ottiene l'idea. La lista non è così netta come potrebbe essere. Non è raro vedere venditori di utilizzare un impianto diverso da quello che ci si aspetterebbe. Per esempio ho visto fornitori VPN indecisi come le differenze tra le strutture di 4 e 10, quindi è sufficiente inviare una certa percentuale di voci di registro a ciascuno.

Gravità

Gravità definisce l'importanza della voce di registro. Lo stesso RFC 3164 definisce i livelli di gravità come:

Gravità numerica

Codice

0 emergenza: il sistema è inutilizzabile (emerg)

1 Alert: l'azione deve essere presa immediatamente (alert)

2 Critico: condizioni critiche (crit)

3 Errore: condizioni di errore (errore)

4 Attenzione: le condizioni di allarme (WARN)

5 Nota: condizione normale ma significativa (preavviso)

6 informativo: i messaggi informativi (info)

7 Debug: a livello di debug messaggi (debug)

Fortunatamente i livelli di gravità sono molto meno vago rispetto alle descrizioni struttura. Questo significa che sono molto meno confusione con cui lavorare. Più elevati i livelli di gravità numerati tendono ad essere molto prolisso. Questo significa dire che si desidera inviare i messaggi di debug a livello di server di registrazione potrebbe facilmente inondare la rete. Utilizzare più i livelli di gravità numerati con cautela.

Priorità

Quando una voce di registro viene trasmesso a un server di log, il primo valore in esso contenute è la priorità del messaggio. La priorità è la struttura ei valori di gravità combinate per la seguente formula matematica:

(Fondo per x 8) + Gravità = Priorità

Allora supponiamo nostro server di posta deve inviare un messaggio di avviso. Quale sarebbe la priorità sarà? La struttura posta ha un valore di 2, mentre gli avvisi con livello di gravità 4. Così la matematica potrebbe essere:

(2 x 8) + 4 = 20

Se un server di stampa (impianto 6) necessario per inviare una voce del registro dicendo che è attualmente in fiamme (gravità 0), il valore di priorità nel messaggio potrebbe essere:

(6 x 8) + 0 = 48

Quando una voce di registro viene trasmesso, il valore di priorità deve essere incapsulato in meno e maggiore di segni. Quindi il valore di priorità nel messaggio sopra server di posta potrebbe essere "<20>", mentre il server di stampa avrebbe usato "<48>". Di nuovo, questo deve essere il primo pezzo delle informazioni trasmesse nel messaggio di log.

Ordinamento delle voci di log

Il valore di priorità viene utilizzato collegandosi ai server di ordinare i messaggi in arrivo. Per esempio se volessimo tutti i messaggi di posta per passare al file stesso, vorremmo dire ai nostri server di registrazione che tutti i messaggi con priorità 16 (2 × 8 +0) a 23 (2 × 8 +7) dovrebbe andare alla " maillog "file. Maggior parte dei server di registrazione (come rsyslog) vi permetterà di fare questo numericamente o utilizzando i nomi breve descrizione.

esempio rsyslog.conf

Qui ci sono due linee di fuori del file rsyslog.conf fornito con Fedora. Parliamo di quello che stanno realmente facendo:

authpriv .* / var / log / secure

*. Info; mail.none; authpriv.none; cron.none / var / log / messages

Queste linee definiscono due delle regole per determinare quali voci di registro dovrebbe andare a quali file di log. La sintassi per l'ordinamento è:

facility.severity

Così la prima riga dice tutte le voci di registro impianto 10 (authpriv), indipendentemente dalla gravità ("*" è una partita di wild card) deve essere inviata al file / var / log / secure.

La seconda linea è un po 'più complesso in quanto ha più condizioni separati da punto e virgola. Queste condizioni di stato:

  • *. Info = Tutti i servizi, purché il livello di gravità è info
  • mail.none = Nessuna voce funzione di registrazione elettronica, indipendentemente dalla gravità
  • authpriv.none = Nessun authprive voci di registro impianto, indipendentemente dalla gravità
  • cron.none = Nessuna voce impianto di log di cron,, a prescindere dalla gravità

O, per tradurre questo in inglese, la linea dice "Send ogni rigore" info "i messaggi in / var / log / messages, ad eccezione di quelli che contengono una struttura di" mail "," authpriv "o" cron ".

Così, con queste regole si può definire una qualsiasi combinazione di struttura e valori di gravità e file di log che ci piacerebbe dirigerlo. La prima volta che questa impostazione, il bastone con le impostazioni predefinite. Come potete iniziare a raccogliere le voci di registro è possibile modificare le regole come meglio credi.

Piegare la RFC

In un mondo ideale, la RFC sarebbe una misura perfetta per le esigenze di tutti. Purtroppo questo non è sempre così. Un buon esempio è la facile logging. Come già detto che ci manca facilita per i servizi di oggi, al tempo stesso hanno facilita che non userà mai. Una risposta ovvia è quella di riciclare gli impianti obsoleti al fine di supportare i servizi moderni.

Per esempio, UUCP (impianto di 8) non è ancora supportata da moderni sistemi operativi. Con questo in mente, mi piace usarla come la mia struttura di Windows. In questo modo posso ordinare tutte le voci del registro di Windows nel proprio file. Per l'hardware di rete, io uso l'impianto notizie della rete (impianto 7). Se non siete sicuri se un impianto è attualmente in uso, modificare file di configurazione del server di registrazione per inviare tutte le voci di log per tale impianto in un file unico:

ftp .* / var / log / centro-test

Se non arrivano le voci, si è in buona forma. Basta tenere a mente che un servizio legittimo può essere utilizzato in un secondo momento. Per esempio, se tre mesi da oggi qualcuno definisce un server FTP, potremmo avere dei problemi se stiamo già utilizzando la funzione FTP (impianto 11). Se non sei sicuro si può sempre attaccare con le strutture uso locale, come quello è ciò che essi sono destinati. Uso locale 0 e 7 sembrano essere i più utilizzati, in modo da evitare quando possibile.

Altre opzioni di ordinamento

Mentre la sua non fanno parte del RFC, alcuni server di registrazione vi darà la possibilità di ordinare le voci di registro sulla base di modelli all'interno del messaggio. Un buon esempio è syslog-ng . Syslog-ng sorta sulla base di impianto e gravità, ma è anche possibile ordinare in base IP di origine, l'applicazione che ha generato la voce di registro, ecc Questo vi dà opzioni di ordinamento molto più flessibile e può essere una cosa da considerare se struttura / gravità granulare non è sufficiente per le vostre esigenze.

Executive Summary

In questa puntata abbiamo parlato di come struttura e la gravità viene utilizzato per ordinare le voci di registro. Nel mio prossimo post vi parlerò di come ottenere ciascuno dei nostri sistemi per inviare messaggi di log al nostro server centralizzato.

Impostazione di un Information Security Management System-Part3

11 Agosto 2009

Nel post precedente ho coperto alcune delle preoccupazioni architettura con rotolamento un sistema centralizzato di informazioni di sicurezza. In questo post tratteremo la distribuzione di un server di base di registro, e la verifica che è pronto ad accettare voci di registro.

Selezione di un server di registrazione

La prima cosa che dobbiamo fare è selezionare una piattaforma per il nostro server di log. Se siamo semplicemente la creazione di un laboratorio di prova, Windows, UNIX o Linux vi faranno grandi scelte. La scelta di Windows potrebbero essere utili per un amministratore di Windows, in quanto non dovrà tagliare la curva su un nuovo sistema operativo durante il tentativo di provare la registrazione. Anche se Windows non supporta Syslog fuori dalla scatola, ci sono alcuni pacchetti eccellenti come Kiwi Syslog Server e WinSyslog che aggiungerà il supporto Syslog. Entrambi hanno le versioni di valutazione e sono relativamente poco costoso per licenza.

Se stiamo parlando di creazione di un server di produzione però, ci vuole stare lontano da Windows. Windows è noto per avere uno stack IP orribile. Se infatti precedente "patch" hanno paralizzato ancora di più nell'interesse di rallentare la propagazione del worm e aumentando la velocità della GUI. Mentre molti di questi limiti sono stati rimossi nel 2008 Server e Windows 7, le prestazioni IP è ancora inferiore alla media rispetto ad un sistema Linux o UNIX distribuito su hardware identico.

In modo che le foglie Linux e UNIX come scelte per un sistema di produzione. Quale scegliere dipende dalla scelta personale. Alcuni, come la stabilità degli altri, mentre BSD come la flessibilità di Linux. Ai fini del presente documento lavorerò con un Fedora sistema basato su Linux. Installazione e configurazione del sistema operativo è relativamente intuitivo e semplice.

Accettare i log remoto

Al fine di accettare le voci di registro da sistemi remoti, le vecchie versioni di Fedora richiesto di inizializzare il demone syslog (syslogd) con l'opzione "-r" opzione. Ciò è stato fatto con l'aggiunta di "-r" alla linea syslogd_options di / etc / sysconfig / syslog file. Alcune versioni di Linux supportano ancora Syslog legacy, e richiedono di aggiungere "-r" al file di inizializzazione del Syslog RC. Controllare la documentazione per la vostra distribuzione specifica.

Nuovi sistemi di Fedora tuttavia di supporto "Syslog affidabile" o rsyslog. Implementazione è abbastanza simile a quello semplice Syslog vecchio, tranne rsyslog supporta comunicazioni su TCP/514 così come UDP/514. Nel post precedente ho descritto che le voci di registro in esecuzione su TCP in grado di correggere alcune delle ragioni per cui abbiamo sciolto le voci di registro, ma non tutti. Se vuoi giocare con il supporto TCP, andare avanti e aprire entrambe le porte sul server di log.

Per ottenere rsyslog di accettare le voci di registro remoto, dobbiamo modificare il file / etc / rsyslog.conf file. Verso l'inizio del file che si dovrebbe vedere la seguente:

# Fornisce la ricezione syslog UDP

# $ MODLOAD imudp.so

# $ UDPServerRun 514

# Fornisce ricezione TCP syslog

# $ MODLOAD imtcp.so

# $ InputTCPServerRun 514

Il simbolo "#" (cancelletto) simbolo all'inizio della riga indica il sistema a non trasformare il resto della linea. Noi usiamo questa tecnica per il commento e "commentare" i comandi non vogliamo avere elaborato. Commentando la MODLOAD e specifiche linee di porta, ci impediscono rsyslog di aprire un socket in ascolto. L'aiuta a mantenere il sistema in uno stato più sicuro.

Dal momento che stiamo allestendo un server centralizzato di registrazione, abbiamo bisogno di aprire tali prese di accettare le voci di registro remoto. Modificare il file / etc / rsyslog.conf file per eliminare i simboli di cancelletto appropriato. Il file dovrebbe apparire così:

# Fornisce la ricezione syslog UDP

$ MODLOAD imudp.so

UDPServerRun $ 514

# Fornisce ricezione TCP syslog

$ MODLOAD imtcp.so

InputTCPServerRun 514 $

Se sai che non potrà mai utilizzare il protocollo TCP, è possibile lasciare le ultime due righe commentate. Una volta completato salvare le modifiche e uscire dal file.

Ora dobbiamo riavviare la registrazione modo che i nostri cambiamenti sono implementati. Questo viene fatto su Fedora eseguendo il comando seguente:

rsyslog riavvio del servizio

Quando si esegue il comando, si dovrebbe vedere interrompere rsyslog e iniziare con uno stato di "OK". Se l'arresto non è perché rsyslog non viene inizializzato al momento dell'avvio. Dalla riga di comando, eseguire il "setup" e selezionare il comando "servizi di sistema" dal menu principale. Quando il menu dei servizi appare, scorrere l'elenco fino a trovare rsyslog. Spuntare la casella a sinistra e poi selezionare "OK". Chiudere l'utilità di configurazione e rsyslog ora inizializzare ogni volta che il sistema viene avviato.

Verifica la porta di ascolto

Poi abbiamo bisogno di assicurare che il nostro processo di registrazione è accettare voci di registro remoto. Dalla riga di comando, digitare "netstat-an | grep: 514". L'output dovrebbe essere simile al seguente:

[Root @ fubar ~] # netstat-an | grep: 514

tcp 0 0 0.0.0.0:514 0.0.0.0: * LISTEN

tcp 0 0::: 514::: * LISTEN

udp 0 0 0.0.0.0:514 0.0.0.0: *

udp 0 0::: 514::: *

La prima riga ci dice che TCP/514 via IPv4 è in ascolto su tutte le interfacce di rete. Linea due ci dice la porta TCP è anche in ascolto su qualsiasi interfaccia con un indirizzo IPv6. Linee di tre e quattro sono le stesse informazioni, tranne che per UDP. Se una delle voci dello stato "127.0.0.1:514" invece di "0.0.0.0:514", allora la porta è solo legato alla interfaccia di loopback. Solo il sistema locale sarà in grado di raggiungerlo. Questo può accadere con i sistemi legacy Syslog se avete dimenticato di farli funzionare con l'opzione "-r" interruttore.

Ora si dovrebbe avere un server di registrazione che è in grado di ricevere voci di registro in entrata. Nel prossimo post vi parlerò di come queste voci di registro si ordinate in file specifici.

Impostazione di un Information Security Management System-Part2

10 Ago 2009

Nel mio ultimo post abbiamo discusso di definire i tuoi obiettivi per un Information Security Management (SIM) del sistema. In questo post parleremo riguarda l'architettura e pianificazione della capacità.

Rete di comunicazione

L'obiettivo sarà quello di avere uno o più server SIM che raccoglierà le voci di log da altri sistemi. Questo avrà ovviamente un impatto sulle utilizzo della rete. Quanto di un impatto dipenderà dalla quantità e dal tipo di sistemi che raccogliamo le voci di log da.

UDP/514

Quasi tutti i sistemi supportano l'implementazione originale di comunicazione Syslog che va tutta la strada per l'anno 1988. L'ultima descrizione di questo spec apparso in RFC 3164 . Mentre questa RFC è stato reso obsoleto da RFC 5424 , RFC 3164 rappresenta ancora l'attuazione supportato dalla maggior parte dei fornitori. Windows è un notevole eccezione (proprietario, nessun supporto Syslog), ma vi è un software 3rd party per rimediare a questa.

Entrambe le RFC specificare l'uso del protocollo UDP durante la trasmissione le voci di registro. Il noto porta da utilizzare è UDP/514. Dove RFC 3164 e 5424 differiscono è nel formato del messaggio di log. Si analizza queste differenze in un post successivo.

L'amore / odio di utilizzare UDP

Sul lato positivo, UDP è senza connessione. Ciò significa che esso genera meno traffico rispetto a quando abbiamo utilizzato TCP. Inoltre, le trasmissioni log sono un processo a senso unico. Il padrone di generare una voce di registro invia un pacchetto al server di registrazione, ma il server di registrazione non risponde mai. Questo significa che possiamo controllare il flusso del traffico con filtraggio statico, piuttosto che di filtraggio stateful che porrà meno overhead sul dispositivo di controllo del traffico. Inoltre, l'intestazione UDP è di solito 1 / 3 - 1 / 4 della dimensione di un header TCP, il che significa che i pacchetti di trasmissione più piccola, l'overhead di rete quindi meno.

Sul lato negativo, UDP è senza connessione. ;) Questo significa che ha capacità minima segnalazione degli errori. Per esempio, se trasmettiamo una voce di registro e la cornice scompare (ad esempio una collisione o un firewall cadere il pacchetto), UDP non ha la capacità di rilevare che una ritrasmissione è necessaria. Questo significa che il suo possibile per le voci del registro di andare dispersi, se troppo pieno della rete. Inoltre, UDP non ha capacità di controllo del flusso. Se il server riconosce SIM sta raggiungendo la capacità non ha modo di rallentare la trasmissione in entrata delle voci di registro. Opzione solo il server SIM è quello di buttare via i pacchetti senza elaborarli.

Inutile dire che dobbiamo fare in modo che la capacità di specificare correttamente. Se la rete o il server SIM viene sovraccaricato, stiamo andando a perdere le voci di registro. Una corretta pianificazione della capacità inizia con la comprensione dell'impatto di registrazione sulla rete.

Impatto sulla rete di accesso

La dimensione massima di un pacchetto UDP Syslog ha specifiche diverse in diversi RFC. L'obsoleto RFC 3164 definisce la dimensione massima dei messaggi come 1.024 byte. RFC 5426 scende questa dimensione massima di 480 byte. Se il venditore è ancora seguendo le vecchie specifiche, le sue possibili possono ancora che la dimensione in byte 1024 è legittimo. E 'stata la mia esperienza però più che l'ingresso gamma registrare i pacchetti in formato 75-225 byte, in modo che il massimi sono un non-problema.

Sistemi Windows, firewall e sistemi anti-intrusione tendono a generare il maggior messaggi. Hardware di rete tende a generare più piccoli messaggi. Se abbiamo una rete Ethernet 100 Mb, il massimo teorico sarebbe da qualche parte circa 50.000 a 130.000 fotogrammi al secondo. Ciò presuppone lo zero traffico, che è raramente il caso. Ai fini della pianificazione della capacità, si presuppone che sarà limitata a 5.000 voci di registro al secondo. Questo numero potrebbe anche essere inferiore se si dispone di una rete occupata. Prendendo alcune misure di utilizzazione durante il processo di pianificazione è la chiave.

Syslog su TCP

Come accennato in precedenza, UDP introduce il problema che le voci di registro può perdersi senza che noi nemmeno saperlo. Ci sono modi di riconoscimento della capacità che mi occuperò in un secondo post. Alcuni si sentono in esecuzione Syslog via TCP in grado di risolvere questo problema. TCP può essere sfruttato per la sua affidabilità per i nostri insurie voci di registro non vengono consegnati.

Purtroppo il supporto TCP per Syslog non erano vicini standardizzati. Alcuni fornitori di supporto TCP semplicemente in ascolto su TCP/514. RFC 3195 definisce Syslog affidabile come TCP/601 utilizzando la porta, ma la sua adozione è stata estremamente limitata. RFC 5425 definisce l'uso di TLS per proteggere la trasmissione Syslog. Questo RFC specifica l'uso della porta TCP/6514. Questa è una specifica nuova e sono a conoscenza di tutti coloro che lo sostengono ancora.

Quindi, il supporto per TCP è tutto il bordo. Inoltre, TCP non risolvere completamente il problema. Mentre TCP ci darà il controllo del flusso e affidabilità sul filo, non può compensare il fatto che Syslog a livello di applicazione non riconosce il ricevimento delle voci di registro. Questo era di progettazione in quanto riduce in testa. Il problema è che anche utilizzando il protocollo TCP possiamo ancora perdere messaggi all'interno dello stack IP e non si sa mai che sta avvenendo.

Quindi, se volete provare e trasmettere i log via TCP, il suo solo di andare a lavorare tra cliente un fornitore specifico e software per server. Per esempio potrebbe essere necessario eseguire Syslog-NG su entrambe le estremità della connessione di sfruttare sia il supporto per TCP. Questo non è sempre pratico, in quanto non è possibile eseguire il client software su dispositivi come access point, switch, router, ecc

Dove posizionare il server di registrazione

Al momento di decidere dove posizionare il server di registrazione, dobbiamo tenere entrambe le capacità di rete e la sicurezza in mente. Date un'occhiata alla Figura # 1. Questa è una situazione ideale in cui il server di registrazione è stato isolato a una rete dedicata operazioni di rete. Questo lo isola dalle zone di sicurezza di altri e rende molto più facile sfruttare il firewall per limitare l'accesso al server di registrazione.

sim-placement

Il disegno assume abbiamo solo bisogno di un server di registrazione per il nostro intero ambiente. Che cosa succede se abbiamo 100.000 nodi per tenere traccia di? Reti di grandi dimensioni può avere bisogno di guardare aggregando i dati. Per esempio se ho 10 uffici sul campo, posso necessario disporre di un server di registrazione situato a ciascuno di essi raccogliere informazioni locali registro. Ciascuno di questi server la registrazione sarebbe poi trasmettere le informazioni di riepilogo di nuovo alla sede centrale per i rapporti tendenza vasta rete. In questo modo manteniamo un elevato livello di visibilità, riducendo il carico di rete. Tratterò alcune opzioni di aggregazione possibile in un post successivo.

Come molti sistemi possono accedere a un server di registrazione singolo?

Non esiste una risposta univoca a questa domanda dato che ogni rete è diversa. Sta andando a dipendere da come capacità molto è disponibile sulla rete e il numero di voci di registro ciascuno di questi sistemi generano. Per esempio potrei forse 50.000 punti passa ad un singolo server di registrazione, come interruttori tendono a generare messaggi molto pochi. Firewall invece sono estremamente loquace, quindi potrei massimo la rete o il server SIM con solo 20-50 firewall. Quindi, per rispondere alla domanda abbiamo bisogno di guardare a due parametri:

  • Quanto spazio libero c'è sul filo?
  • Quante voci di registro sarà ogni host di generare?

La seconda questione non è così semplice come può sembrare. Per esempio il desktop media può solo generare 4-10 voci di registro al giorno. Se siamo in grado di spingere 1.000 voci di registro al secondo, la matematica dice che dovremmo essere in grado di punto 86 milioni di desktop in un server di registrazione singola. Il problema è che circa l'80% di questi messaggi sono generati in fase di avvio iniziale. Se tutti i poteri tipicamente intorno 9.00, i cambiamenti matematica ad un più realistico 750 desktop (di nuovo, assumendo siamo in grado di spingere 1.000 voci di registro al secondo attraverso la rete).

Quindi non possiamo solo guardare la quantità di voci lunghe. Abbiamo bisogno di prendere tempo del giorno in considerazione pure. Ciò consentirà di individuare il numero effettivo di voci di registro al secondo ci si può aspettare in condizioni di caso peggiore. Peggio caso è il livello di capacità di cui abbiamo bisogno per pianificare.

Distribuzione di registrazione centralizzata in fasi

Se si dispone di decine di migliaia di sistemi da gestire, è facile ottenere sopraffatto con il lavoro in questione con la distribuzione registrazione centralizzata. Condurre la soluzione in fasi rende più facile per avvolgere il tuo cervello l'intero processo.

In primo luogo, iniziare con un server di registrazione singola. Potrebbe non essere in grado di coprire l'intera rete, ma dobbiamo iniziare da qualche parte. Grandi reti dovrebbero prendere in considerazione una distribuzione presso la sede aziendale prima, uscendo agli uffici campo una volta che il sistema aziendale è completamente controllati e funzionale.

Potrai anche voler fase in cui i dispositivi si raccolgono informazioni da. Io di solito andare con il seguente ordine:

  1. Sistemi di rilevamento delle intrusioni nella rete
  2. Firewall
  3. Hardware di rete (router, switch, access point, server di stampa, ecc)
  4. Internet verso i server
  5. Server interni
  6. Desktop interno

Ovviamente è possibile modificare questo elenco per soddisfare le vostre esigenze. Per esempio se non si ha intenzione di raccogliere informazioni dal desktop, è sufficiente lasciare che un passo fuori. Mi piace iniziare con i sistemi di intrusione prima rete come loro voci di registro sono adatti sia per vagliare i rapporti giornalieri e avvisi in tempo reale. Una volta che abbiamo un manico su avviso e reporting, l'aggiunta di dispositivi supplementari diventa molto più facile.

Executive Summary

In questo post ho coperto tutte le cose che dovete considerare quando inizialmente la distribuzione di una soluzione centralizzata di registrazione. Abbiamo coperto il modo di prevedere l'impatto che avrà sul l'utilizzo della rete, come calcolare il numero di host per la registrazione del server, e perché è importante per implementare la soluzione in fasi. Nel prossimo post inizieremo a parlare di configurazione del server centralizzato di registrazione. In particolare, vedremo come andremo per ordinare le voci di registro.

Impostazione di un Information Security Management (SIM) del sistema - Parte 1

8 AGOSTO 2009

Ho un sacco di registrazione domande relative. Tanto che ho deciso di fare una serie su come distribuire la gestione dei log. Ci sono alcune eccellenti risorse di registrazione su Internet, ma sono frammentate in ambito e / o specifiche venditore (solitamente scritto dai fornitori). Ho voluto creare qualcosa fornitore neutrale che tiene la mano attraverso l'intero processo di distribuzione di una soluzione di gestione dei log.

Perché dovrei implementare un sistema informativo di gestione della sicurezza?

Cerchiamo di essere sinceri, la gestione dei log distribuzione è duro e doloroso. Questo è il motivo per cui così tanti amministratori di evitarlo come la peste. E 'difficile da implementare e da un dollaro selvatici per eseguire l'amministrazione a lungo termine. Viaggi settimanali dal dentista probabilmente sarebbe più piacevole.

Con tutto ciò che ha detto, la gestione dei log è probabilmente la singola soluzione di sicurezza più efficaci è possibile distribuire. Non si può cadere e dimenticare come un firewall, ma la gestione dei log in grado di dare visibilità senza rivali nel funzionamento interno della rete. Quando non la sua permettono di approfondire gli eventi di sicurezza che altrimenti non, che sta facendo il doppio dovere aiutare a risolvere problemi di comunicazione e di sistema. Un sistema di registrazione può essere risorse, ma può anche fornire un tasso molto alto di rendimento.

Perché vuoi una SIM?

Prima di iniziare, la prima domanda che dovete porvi è il motivo vuoi una soluzione SIM . Volete migliorare la sicurezza o vi è una specifica di conformità è necessario aderire a? Può sembrare strano a voler distinguere tra i due, ma i requisiti sono drasticamente differenti. Le norme sono molto più facile (e meno costose) per soddisfare le più vera sicurezza.

Standard come PCI-DSS richiedono di registrare l'attività degli utenti, delle applicazioni e della rete. Tuttavia, essi tendono ad essere molto vago in quanto tale informazione viene elaborata. Di solito è possibile farla franca cadere in una scatola nera, generando alcuni rapporti di gestione colorati, ed essere considerato "compatibile". Forse non aiuterà a trovare quel sistema backdoored che sta chiamando a casa, ma che hai incontrato lo standard.

Standard tendono a concentrarsi sul minimo comune denominatore. Hanno bisogno di essere applicabile per una vasta gamma di pubblico, incluse le imprese senza un sacco di risorse. Piuttosto che valutare il rischio di una specifica organizzazione e basando i requisiti su questo, abbiamo fissato la barra bassa ed è quindi raggiungibile da parte di organizzazioni grandi e piccole.

Inoltre, per semplificare il processo, si tende a concentrarsi su liste di controllo. Liste di controllo sono fresche, perché ti dicono esattamente ciò che deve essere fatto per essere reclamo. Se un sindaco può mettere un segno di spunta accanto a tutti gli elementi, si passa il test. Il problema è liste di controllo tendono a concentrarsi sui sintomi, non il problema vero e proprio.

Vi darò un grande esempio. Ho avuto un cliente portare in un Qualified Security Assessor per certificarle per PCI-DSS. Questo è stato uno dei miei client che eseguono la rigorosa attuazione del controllo delle applicazioni, in modo da poter mostrare un anno e mezzo una storia di infezioni da malware zero. Mentre certamente ricevuto malware per tutto questo tempo, potremmo provare che non vi fosse zero casi di infezione reale come ogni attacco malware è stato immediatamente bloccato ed eliminato. Non molte aziende possono richiedere un + anno con zero infezioni malware.

Il revisore li fallito. PCI-DSS requisito # 5 afferma: "software anti-virus deve essere utilizzato su tutti i sistemi comunemente effettuate da malware". Dal momento che correvano controllo delle applicazioni, non anti-virus, sono stati ritenuti non conformi. Se il requisito 5 era stato scritto per identificare una soglia accettabile per il contenimento del malware, che certamente avrebbe incontrato le specifiche. Tuttavia la valutazione del rischio e le metriche non fanno per gli oggetti lista di controllo facile.

Quindi, se si desidera distribuire una SIM per aumentare effettivamente la sicurezza nel proprio ambiente, che sta per prendere più a lungo e richiedono più lavoro di una semplice riunione di una specifica.

Dovrebbe costruire la vostra propria SIM?

Sono fermamente convinto che chiunque voglia una soluzione SIM dovrebbe iniziare con la costruzione di suo proprio. Mentre ci sono alcuni decenti soluzioni commerciali SIM là fuori, ti isolano dalle opere interne del processo di registrazione. Questo può essere una buona cosa, nel senso che consente di risparmiare tempo. Il problema è che non si impara tanto.

Inoltre, la gestione dei log di implementazione è un viaggio. Troverete nel corso di una distribuzione che le vostre esigenze possono cambiare. Le informazioni che inizialmente pensato fosse importante, tutto ad un tratto non lo è. Rapporti che non ha nemmeno pensare, tutto ad un salto improvviso in cima alla lista. Costruendo il proprio sistema si avrà una maggiore flessibilità di apportare modifiche al volo. Se successivamente si decide che si desidera una soluzione commerciale, si è ora meglio informati delle vostre esigenze e può fare un lavoro migliore valutazione di un potenziale acquisto. Questo è importante, come soluzioni log molti sono costosi. Non si vuole far cadere un sacco di soldi su una soluzione che non soddisferà le vostre esigenze a lungo termine.

Vi darò un buon esempio. La maggior parte dei siti con cui ho lavorato inizialmente pensare accessi non riusciti sono importanti e vogliamo vedere i report. Non li vuole molto per capire vedere tutti gli accessi non è una completa perdita di tempo come le dita di grasso tutti la tastiera a volte. Poi si rendono conto che vogliono alcune soglie attorno ai dati. Per esempio, vogliono solo vedere accessi non riusciti, se tre o più guasti si vedono in cinque secondi (che indicano un attacco automatico). O solo mostrare accessi non riusciti, quando i nomi di accesso vengono utilizzate più dalla stessa fonte IP (che indica un attacco di indovinare la password). Quindi, trattando con alcuni sovraccarico di informazioni, diventano più qualificata a definire esattamente ciò che desiderano vedere.

Riassunto

OK, abbiamo trattato la definizione di una messa a fuoco (sicurezza vs. Requisito standard), così come l'importanza di costruire inizialmente proprio sistema. Nella prossima farò entrare in architettura e pianificazione della capacità.