File di log: importanza e analisi Prima parte Yvette ‘vodka’ Agostini vodka@s0ftpj.org Valerio ‘Hypo’ Verde amover@libero.it Slide introduttiva circa 2 minuti Piccola introduzione sul fatto che i log sono la fonte irrinunciabile per trovare le rispsote ai problemi, siano essi douti a malfunzoinamenti hw o sw o a tentatii di attacco.

File di log: importanza e analisi Cosa sono Cosa ci dicono Cosa cercare

File di log: importanza e analisi Tutto può essere fonte di log: l’hw, tramite il kernel i demoni (sshd, telnetd, inetd...) gli applicativi (mysql, cron, ...) gli utenti Chi genrea i log? Praticamente tutto e dico tutto sia hw che sw puo’ essere fonte di log..... Il kernel (tramite klogd) e cosenguentemente l’hw tramie il kernel Gli applicativi ---mysql, cron, posso dire agli applicativi checreo di scrivere nei log... I demoni---httpd, ftpd, sshd, klogd (che registra le attivita’ del kernel) Eventualmente noi. Se consideriamo il resto del mondo otlre l anostra box...abbiamo: Apparati di rete (router, switch, firewall,nids) In sostanza

File di log: importanza e analisi 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: yagostini pts/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 generato da hardware: Il controller ide 2) Scheda di rete che entra in promiscuous mode Questa e’ una cosa interessante da notare...in

File di log: importanza e analisi Esempi di log generati da demoni: sendmail Jun 2 04:02:03 xxxx sendmail[24976]: g52221tb024971: to=yagostini@xxx.it, ctladdr=<root@xxx.xxx.it> (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 ( <200206020202.g52221OJ024969@mail.xxx.it> 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 demoni Sendmail : vediamo che la mail indirizzata a yagostini e’ messa in coda per la spedizione Apache: vediamo una richiesta effettuata al web server Cron: vediamo che cron ha eseguito il comando /usr/local/bin/CheckDefang.sh

File di log: importanza e analisi 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" Esempi di log generati da applicativi: Uno script che esegue il backup di alcuni dati del sistema logga l’inizio e la fine del suoc ompito 2) Un applicativo per webmail, nel caso squirrelmail, logga gli accessi al servizio

File di log: importanza e analisi 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) Vediamo un estratto da error_log di apache relativamente a un attacco Nimda. Nimda cerca di esploitare una decina di vulnerabilità di IIS, perciò oltre a questa linea di log ne avremo un’altra decina. Sebbene siamo immuni aquesto attacco perche’ siamo apache e non win, cmq ci può arrecare danno floddandoci di errori che finiscono in error_log. Cosa che è accaduta a molti quando nimda ha cminciato la sua diffusione aggressiva in rete. Un estratto da /var/log/messages che mostra attività di probing della versione corrente di sshd alla ricerca di versioni vulnerabili.

File di log: importanza e analisi 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)

File di log: importanza e analisi Strumenti per l’automazione della gestione dei log: Log rotation Si 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

File di log: importanza e analisi Logwatch E’ 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]

File di log: importanza e analisi swatch E’ 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]

File di log: importanza e analisi 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 SYSLOG Come è 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

FORMATO DI UN MESSAGGIO SYSLOG Come è fatto un messaggio per syslog ( RFC 3164 ) <PRI> TIMESTAMP HOSTNAME TAG CONTENT 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

FORMATO DI UN MESSAGGIO SYSLOG Come è fatto un messaggio per syslog ( RFC 3164 ) <PRI> TIMESTAMP HOSTNAME TAG CONTENT 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 )

FORMATO DI UN MESSAGGIO SYSLOG Come è fatto un messaggio per syslog ( RFC 3164 ) <PRI> TIMESTAMP HOSTNAME TAG CONTENT 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

Il deamon di syslogging SYSLOGD Il 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 -m Intervallo 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 SYSLOGD Il campo selettore facility.severity * tutte le facilities o tutte le severities none nessuna severity , multiple facilities e severities ; multiple statement con stessa azione = esattamente una severity ! negazione severity \ separazione multiline

IL FILE DI CONFIGURAZIONE DI SYSLOGD Il 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 SYSLOGD Esempio *.=info;*.=notice;*.=warning;\ auth,authpriv.none;\ cron,daemon.none;\ mail,news.none /var/log/messages Tutti 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 collegati kern.!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

Il kernel logger daemon KLOGD Il 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 SICUREZZA ESAURIMENTO DELLO SPAZIO SU DISCO NO AUTH Che problemi posso avere con syslog ? ESAURIMENTO DELLO SPAZIO SU DISCO NO AUTH FLOOD RETE - CARICO MACCHINA

COME INVIARE MESSAGGI A SYSLOG Rendere 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 SYSLOG Rendere 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 LOG Come 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

Una (ottima ?) alternativa a syslogd SYSLOG-NG Una (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

Le 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-NG Message path Approccio syslogd messaggi filtrati in base a facility e severity facilities troppo generiche come daemon pochi programmi consentono di ‘specificare’ la facility Approccio syslog-ng controllo più preciso sul filtering dei messaggi messaggi filtrati in base a message path Un message path è composto da : una o più sorgenti di log una o più regole di filtering una 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-NG Destin. Sorgente Filter Destin. Sorgente Filter Destin. Message path Filter Destin. Sorgente Filter Destin. Sorgente Filter

SYSLOG-NG Sorgenti 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 internamente unix-stream per aprire un socket in modo SOCK_STREAM unix-dgram per aprire un socket in modo SOCK_DGRAM file per aprire un file pipe, fifo per aprire una named pipe udp per ricevere messaggi via UDP tcp per ricevere messaggi via TCP sun-stream per aprire lo STREAM device su Solaris

SYSLOG-NG internal() messaggi interni di syslog-ng Tipi 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-NG udp(ip,port) riceve messaggi via udp file() Tipi 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-NG COSA LOGGARE ? Filtri 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-NG and or not operatori logici Funzioni per i filtri and or not operatori logici facility controllo sulle facilities specificate level controllo sui levels specificati program controllo sul tag via regexp host controllo sull’hostname via regexp match controllo sul messaggio via regexp filter controllo su una diversa filter rule

SYSLOG-NG COME LOGGARE ? Destinazioni 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-NG Tipi di destinazione Le destinazioni possibili sono : file scrive i messaggi su file fifo , pipe scrive i messaggi su una named pipe unix-stream invia i messaggi su un socket SOCK_STREAM unix-dgram invia i messaggi su un socket SOCK_DGRAM udp invia i messaggi via UDP tcp invia i messaggi via TCP usertty invia i messaggi ad un utente se collegato program forka, lancia un programma e manda il messaggio allo stdin

Tipi di destinazione : file() SYSLOG-NG Tipi di destinazione : file() Invia i log ad un file, o ad un insieme di files. Il nome del file di destinazione può includere delle macro che vengono espanse nel momento in cui i messaggi vengono 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)); };

Tipi di destinazione : file() - opzioni SYSLOG-NG Tipi di destinazione : file() - opzioni log_fifo_size() numero di msg in coda Default = Global setting fsync() forza una fsync() del destination fd Default = no sync_freq() numero di linee in buffer prima della scrittura Default = Global setting owner() Owner del file creato Default = root group() Gruppo del file creato Default = root encrypt() non implementata compress() non implementata perm() permission mask Default = 0600 dir_perm() dir permission mask Default = 0600 create_dirs() consente creazione directories Default = 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-NG Log paths Una volta definito sorgenti, filtri e destinazioni, occorre in qualche modo legare tra loro queste cose Per farlo utilizziamo lo statement log log { 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-NG Option 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 host use_time_recvd() Usa data di ricezione use_dns() Abilita risoluzione dns ( blocking op ) use fqdn() Utilizza fqdn gc_idle_threshold Parametro per garbage collector gc_busy_threshold Parametro per garbage collector sync() Numero messaggi da tenere in buffer log_fifo_size() Grandezza del buffer

SYSLOG-NG filename per un destination file() Macro Le MACRO possono essere utilizzate in due circostanze : filename per un destination file() template nelle opzioni di un destination file()

SYSLOG-NG Macro FACILITY facility di provenienza PRIORITY o LEVEL priorità del messaggio TAG numero esadecimale a due cifre che specifica priority + facility DATE data in formato %h %e %H:%M:%S Jun 29 16:21:02 FULLDATE data in formato %Y %h %e %H:%M:%S 2002 Jun 29 16:21:02 ISODATE data in formato %Y-%m-%dT%H:%M:%S%z 2002-06-29T16:21:02+0200 YEAR MONTH DAY WEEKDAY HOUR MIN SEC FULLHOST conserva il chain_hostname nella macro template HOST PROGRAM MSG o MESSAGE IPSOURCE (non documentata) ip di provenienza UNIXTIME (non documentata) data in formato unix

SYSLOG-NG Macro ( 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-NG Tuning 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

Si! Le slides saranno disponibili sul sito di sikurezza.org DOMANDE ? Si! Le slides saranno disponibili sul sito di sikurezza.org