File di log: importanza e analisi Prima parte Yvette vodka Agostini [email protected] Valerio Hypo...

File di log: importanza e analisi

Prima parte

Yvette ‘vodka’ [email protected]

Valerio ‘Hypo’ [email protected]

File di log: importanza e

analisiCosa sono

Cosa ci dicono

Cosa cercare

Tutto può essere fonte di log:

• l’hw, tramite il kernel

• i demoni (sshd, telnetd, inetd...)

• gli applicativi (mysql, cron, ...)

• gli utenti


Esempi di log generati dall’hardware:

Jun 4 18:09:43 dhcpclient1 kernel: ide0: BM-DMA at 0xf000-0xf007, BIOS settings: hda:pio hdb:pio

Jun 6 14:45:53 dhcpclient1 kernel: eth0 : Setting promiscuous mode

Esempi di log generati dagli utenti:

yagostinipts/0 xxx-223.xxx.xxx Thu Jun 6 15:56 still logged in

trastai pts/0 xxx-21.xx.xxx Thu Jun 6 15:30 - 15:42 (00:12)



Esempi di log generati da demoni:

sendmail

Jun 2 04:02:03 xxxx sendmail[24976]: g52221tb024971: [email protected], ctladdr=<[email protected]> (0/0), delay=00:00:02, xdelay=00:00:01, mailer=esmtp, pri=270564, relay=mail.xxx.it. [xxx.xx.xxx.xx], dsn=2.0.0, stat=Sent ( <[email protected]> Queued mail for delivery)

Apache

xx.xxx.xx.xx - - [19/Dec/2001:16:22:33 +0100] "GET /apache_pb.gif HTTP/1.1" 200 2326

Cron

Jun 2 04:32:00 hostname CROND[29556]: (root) CMD (/usr/local/bin/CheckDefang.sh > /dev/null 2>&1)


Esempi di log generati da applicativi:

Un generico script di backup

Finished backup at Fri Apr 19 00:00:00 CEST 2002

Starting backup at Sat Apr 20 00:00:00 CEST 2002

Squirrelmail (webmail)

xxx.xx.xx.xxx - - [18/Feb/2002:15:07:30 +0100] "GET /squirrelmail/ HTTP/1.0" 302

0 "-" "Lynx/2.8.4rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.6b"


Tracce (fingerprint) di attacchi e probe:Apache:[Tue Jun 11 04:09:11 2002] [error] [client xxx.xx.xxx.x] File does not exist: /www/virtualhosts/www.nomesito.com/MSADC/root.exe (error_log di apache che segnala un attacco NIMDA)

Ssh:Jun 9 09:39:25 sshd[17060]: scanned from xxx.xx.xxx.xx with SSH-1.0-SSH_Version_Mapper. Don't panic.(messages log file, evidenzia la signature di un version scanner per sshd)


Conoscere lo stato a regime del sistema significa poter cogliere i segnali premonitori

• Dimensione anomala dei file di log• Signature di attacchi

Riconoscere tempestivamente un problema consente di avere più chances di prevenire danni (non necessariamente dovuti a intrusioni)


Strumenti per l’automazione della gestione dei log:• Log rotationSi può fare “a mano” scriptando opportunamente, oppure

si può usare logrotate (ben noto a chi usa redhat), che tramite un file di configurazione e cron provvede a ruotare, comprimere, rimuovere e spedire per mail i file di log.

[ftp://ftp.redhat.com/pub/redhat/code/logrotate/]• Swatch


LogwatchE’ sviluppato in perl. Controlla a intervalli regolari,

impostabili da file di configurazione oppure da linea di comando, i file di log ricercando stringhe particolari.

E’ abbastanza semplice da configurare e modificare per venire incontro alle proprie esigenze.

Warning: installare l’ìultima versione perche’ le precedenti sono affette da un bug che consente root in locale.

[http://www.logwatch.org]


swatchE’ sviluppato in perl. Controlla in tempo reale i file di log

impostati da file di configurazione alla ricerca dei particolari “trigger” da noi scelti (esempio: parsa /var/log/maillog alla ricerca della stringa EXPN). Quando incontra un trigger swatch esegue un’azione impostata da noi.

E’ abbastanza semplice da configurare e modificare. [Homepage http://www.oit.ucsb.edu/~eta/swatch/ , ma

spiegazione ottima qui: http://www.enteract.com/~lspitz/swatch.html]

[Download ftp://ftp.stanford.edu/general/security-tools/swatch/swatch-3.0.4.tar.gz]

Considerazioni:

Conoscere il sistema per non dispersi nella mole delle informazioni.

Analizzare in modo incrociato le informazioni dei diversi file di log

In caso di più sistemi considerare l’opportunita’ di installare un log server per centralizzare i log


FORMATO DI UN MESSAGGIO SYSLOGCome è fatto un messaggio per syslog ( RFC 3164 )

<PRI> TIMESTAMP HOSTNAME TAG CONTENT

PRI HEADER MSG

PRI

PRIORITY = FACILITY * 8 + SEVERITY

Ci sono 24 facilities e 8 severities, quindi il valore di PRI può andare da 0 a 191



PRI HEADER MSG

PRI - LE FACILITIES ( 0-23 )

0 kern, 1 user, 2 mail, 3 daemon, 4 auth, 5 syslog, 6 lpr, 7 news, 8 uucp, 9 cron, 10 authpriv, 11 ftp, 16-23 local 0-7

PRI - LE SEVERITIES ( 0-7 )

0 emerg/panic, 1 alert, 2 crit, 3 error/err, 4 warning/warn, 5 notice, 6 info, 7 debug



PRI HEADER MSG

HEADER

Il TIMESTAMP contiene la data locale nel formato Mmm dd hh:mm:ss

L’HOSTNAME contiene il nome dell’host che ha generato il messaggio ( senza il dominio )



PRI HEADER MSG

MSG

Il TAG contiene il nome del programma o processo che ha generato il messaggio

Il campo CONTENT contiene l’effettivo messaggio

SYSLOGDIl deamon di syslogging

syslogd è il demone che consente di loggare in modi diversi tutti i messaggi di sistema, del kernel (tramite klogd) e dei demoni attivi

Le opzioni principali sono :-a Specifica sockets addizionali per ambienti chrooted-d Debug mode-f Specifica un differente file di configurazione-h Attiva l’host forwarding-mIntervallo per il --MARK-- in minuti ( 0 disattiva il mark )-p Socket da usare al posto di /dev/log-r Abilita la ricezione sulla porta 514 UDP

IL FILE DI CONFIGURAZIONE DI SYSLOGD/etc/syslog.conf

Ogni riga è formata da due campi :

un campo selettore un campo di azione

separati da uno o più spazi (o tab) che definiscono rispettivamente COSA loggare e DOVE

FACILITY.SEVERITY<spazio/tab>AZIONE

IL FILE DI CONFIGURAZIONE DI SYSLOGDIl campo selettore

facility.severity

* tutte le facilities o tutte le severitiesnone nessuna severity, multiple facilities e severities; multiple statement con stessa azione= esattamente una severity! negazione severity\ separazione multiline

IL FILE DI CONFIGURAZIONE DI SYSLOGDIl campo azione

E’ possibile specificare diverse azioni

File normali : /

Named Pipe - FIFO : |

Terminali virtuali e console

Macchine remote : @

Lista di utenti : ,

Tutti gli utenti : *

IL FILE DI CONFIGURAZIONE DI SYSLOGDEsempio

*.=info;*.=notice;*.=warning;\auth,authpriv.none;\ cron,daemon.none;\ mail,news.none /var/log/messagesTutti i messaggi con severity info, notice e warning, eccetto quelli

provenienti da facilities auth,authpriv,cron,daemon,mail,news sul file /var/log/messages

*.alert *Tutti i messaggi con severity alert o maggiore a tutti gli utenti

collegatikern.!alert; \*.=debug;*.=info;\*.=notice;*.=warn /dev/tty8 Tutti i messaggi con severity debug, info, notice e warn vengono

visualizzati su /dev/tty8 tranne quelli provenienti da kern con severity uguale o maggiore ad alert

KLOGDIl kernel logger daemon

Il kernel è una preziosa fonte di log

Il kernel utilizza la funzione printk() per inviare messaggi, che se non ‘intercettati’ da nessun daemon, vengono visualizzati in console

Il daemon klogd serve ad intercettare questi messaggi ( da /proc/kmsg ) e mandarli a syslogd

Le opzioni frequenti sono -c ( forza visualizzazione in console ) e -f ( write to file )

NOTE SULLA SICUREZZAChe problemi posso avere con syslog ?

ESAURIMENTO DELLO SPAZIO SU DISCO

NO AUTH

FLOOD RETE - CARICO MACCHINA

COME INVIARE MESSAGGI A SYSLOGRendere i propri script e programmi più ‘loquaci’

SHELL SCRIPT

E’ possibile utilizzare il programma logger, con il quale si può inviare a syslogd un messaggio con una priorità e un tag definibile.

logger -p facility.severity -t tag message

La priorità può essere specificata numericamente o con una coppia facility.severity

Di default logga con priorità user.notice

COME INVIARE MESSAGGI A SYSLOGRendere i propri script e programmi più ‘loquaci’

C

Basta includere la libreria syslog.h e utilizzari semplici funzioni come :

void openlog(char *ident, int option, int facility)void syslog(int priority, char *format)void closelog(void)

PERL

E’ possibile usare il modulo Sys::Syslog

COME RENDERE (PIU’) SICURI I LOGCome evitare ‘cancellazioni accidentali’

Forwardare i log ad un log server

Scrivere i log su un dispositivo write-once come un WORM

Scrivere i messaggi direttamente su stampante

SYSLOG-NGUna (ottima ?) alternativa a syslogd

syslog-ng ( syslog next generation ) è un sostituto del syslogd,

scritto da Balázs Scheidler, sotto licenza GNU.

La versione di sviluppo attuale e’ la 1.5.18, mentre la versione stabile e’ la 1.4.15

Homepage : http://www.balabit.hu/en/downloads/syslog-ng/

Freshmeat :http://freshmeat.net/projects/syslog-ng/

Mailing List :http://lists.balabit.hu/mailman/listinfo/syslog-ng

SYSLOG-NGLe features di syslog-ng

Compatibilità con syslogd

Possibilità di filtrare sul contenuto del messaggio

File di configurazione chiaro e potente

Forwarding log via UDP/TCP, con forwarding chain

Creazione file di log basata su MACRO

Formato dei log customizzabile

Catchall statement

SYSLOG-NGMessage path

Approccio syslogdmessaggi filtrati in base a facility e severityfacilities troppo generiche come daemonpochi programmi consentono di ‘specificare’ la facility

Approccio syslog-ngcontrollo più preciso sul filtering dei messaggimessaggi filtrati in base a message pathUn message path è composto da :

una o più sorgenti di loguna o più regole di filteringuna o più destinazioni dei log

Quindi ci sono delle regole che legano una o più sorgenti, con uno o più filtri, in una o più destinazioni

5 statements : source, filter, destination, log, options

SYSLOG-NGMessage path

Sorgente

Sorgente

Sorgente

Filter

Filter

Filter

Destin.

Destin.

Destin.

SYSLOG-NGSorgenti

Per dichiarare una sorgente si usa questo statement nel file di configurazione :

source <identifier> { source-driver(params); source-driver(params); ... };

internal per i messaggi generati internamenteunix-stream per aprire un socket in modo SOCK_STREAMunix-dgram per aprire un socket in modo SOCK_DGRAMfile per aprire un filepipe, fifo per aprire una named pipeudp per ricevere messaggi via UDPtcp per ricevere messaggi via TCPsun-stream per aprire lo STREAM device su Solaris

SYSLOG-NGTipi di sorgente

internal()messaggi interni di syslog-ng

unix_dgram(owner,group,perm)apre un socket SOCK_DGRAM e si mette in ascolto

unix_stream(owner,group,perm,keep-alive,max-connections)apre un socket SOCK_STREAM e si mette in ascolto

tcp(ip,port,keep-alive,max-connections)riceve messaggi via tcp

SYSLOG-NGTipi di sorgente

udp(ip,port)riceve messaggi via udp

file()messaggi da file speciali come /proc/kmsg

pipe()messaggi provenienti da named pipe (HP-UX)

sun-stream()messaggi provenienti da doors (SOLARIS)

SYSLOG-NGFiltri

COSA LOGGARE ?

Per dichiarare un filtro si usa questo statement nel file di configurazione :

filter <identifier> { expression; };

Ogni filtro ha un identificativo unico

Un espressione può contenere parentesi, operatori booleani AND, OR e NOT e un certo numero di funzioni interne

SYSLOG-NGFunzioni per i filtri

and or not operatori logici

facility controllo sulle facilities specificatelevel controllo sui levels specificatiprogram controllo sul tag via regexphost controllo sull’hostname via regexpmatch controllo sul messaggio via regexpfilter controllo su una diversa filter rule

SYSLOG-NGDestinazioni

COME LOGGARE ?

Per dichiarare una destinazione si usa questo statement nel file di configurazione :destination <identifier> { destination-driver(params); destination-driver(params); ... };

Ogni destinazione ha un identificativo unico, ed è composto da uno o più destination drivers, ognuno dei quali supporta zero o più parametri

SYSLOG-NGTipi di destinazione

Le destinazioni possibili sono :

file scrive i messaggi su filefifo , pipescrive i messaggi su una named pipeunix-stream invia i messaggi su un socket SOCK_STREAMunix-dgram invia i messaggi su un socket SOCK_DGRAMudp invia i messaggi via UDPtcp invia i messaggi via TCPusertty invia i messaggi ad un utente se collegatoprogram forka, lancia un programma e manda il

messaggio allo stdin

SYSLOG-NGTipi di destinazione : file()

Invia i log ad un file, o ad un insieme di files.Il nome del file di destinazione può includere delle macroche vengono espanse nel momento in cui i messaggivengono scritti, così un singolo driver file() può generare più files.

Esempio :

destination hosts {

file("/var/log/HOSTS/$HOST/$YEAR/$MONTH/$DAY/$FACILITY$YEAR$MONTH$DAY" owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes)); };

SYSLOG-NGTipi di destinazione : file() - opzioni

log_fifo_size()numero di msg in codaDefault = Global setting

fsync()forza una fsync() del destination fdDefault = no

sync_freq()numero di linee in buffer prima della scritturaDefault = Global setting

owner()Owner del file creatoDefault = root

group()Gruppo del file creatoDefault = root

encrypt() non implementata

compress() non implementata

perm()permission maskDefault = 0600

dir_perm()dir permission maskDefault = 0600

create_dirs()consente creazione directoriesDefault = no

template()crea un file di log basato su template - usa standard macro

template_escape()abilita l’escape di ‘ e “Default = yes

remove_if_older()rimuove il file se più vecchio di n secondi. Default = 0

SYSLOG-NGLog paths

Una volta definito sorgenti, filtri e destinazioni, occorre in qualche modo legare tra loro queste cose

Per farlo utilizziamo lo statement loglog { source(s1); source(s2); ... filter(f1); filter(f2); ... destination(d1); destination(d2); ... flags(flag1[, flag2...]); };

Ogni messaggio proveniente da una delle sorgenti, che rispetta ogni filtro viene inviato a tutte le destinazioni

Usando il parametro flags() è possibile modificare questo comportamento, ovvero fermarsi ad esempio al primo match

SYSLOG-NGOption

Lo statement option serve a modificare alcune opzioni di syslog-ng options { option1(params); option2(params); ... };

time_reopen() Tempo per la riapertura di una connessione morta

time_reap() Tempo di wait per connessioni idle prima di chiuderle

chain_hostnames() Chaining dei forwarding hostuse_time_recvd() Usa data di ricezioneuse_dns() Abilita risoluzione dns ( blocking op )use fqdn() Utilizza fqdngc_idle_threshold Parametro per garbage collectorgc_busy_threshold Parametro per garbage collectorsync() Numero messaggi da tenere in bufferlog_fifo_size() Grandezza del buffer

SYSLOG-NGMacro

Le MACRO possono essere utilizzate in due circostanze :

filename per un destination file()

template nelle opzioni di un destination file()

SYSLOG-NGMacro

FACILITYfacility di provenienza

PRIORITY o LEVELpriorità del messaggio

TAGnumero esadecimale a due cifre che specifica priority + facility

DATEdata in formato %h %e %H:%M:%SJun 29 16:21:02

FULLDATEdata in formato %Y %h %e %H:%M:%S2002 Jun 29 16:21:02

ISODATEdata in formato%Y-%m-%dT%H:%M:%S%z2002-06-29T16:21:02+0200

YEARMONTH DAYWEEKDAYHOURMINSECFULLHOST

conserva il chain_hostname nella macro template

HOSTPROGRAMMSG o MESSAGEIPSOURCE (non documentata)

ip di provenienza

UNIXTIME (non documentata)data in formato unix

SYSLOG-NGMacro ( osservazioni )

Le MACRO applicate al filename, possono creare moltissimi file (ad esempio se si usa $PROGRAM).

Questo consente la possibilità di un attacco DoS, dove si fa in modo di far aprire molti file a syslog-ng.

I file aperti da syslog-ng, in cui non viene scritto per più di 60 secondi ( definibile ), vengono chiusi.

La macro più pericolosa è appunto $PROGRAM, poiché può assumere moltissimi valori diversi, ed in ambienti untrusted va fortemente evitata.

SYSLOG-NGTuning

E’ possibile effettuare del tuning su syslog-ng specificando delle opzioni globali

gc_idle_threshold() e gc_busy_thresold() sono parametri del garbage-collector interno, che può creare problemi con protocolli di trasporto non connection-oriented come udp() o unix-dgram()

log_fifo_size() specifica la grandezza (in numero di messaggi) della coda di output, utile per previsti burst di messaggi

sync() specifica il numero di messaggi da mantenere nel buffer prima di eseguire una scrittura

DOMANDE ?

Si! Le slides saranno disponibili sul sito di

sikurezza.org

File di log: importanza e analisi Prima parte Yvette vodka Agostini [email protected] Valerio Hypo...

Documents

Transcript of File di log: importanza e analisi Prima parte Yvette vodka Agostini [email protected] Valerio Hypo...