File di log: importanza e analisi Prima parte Yvette ‘vodka’ Agostini vodka@s0ftpj.org Valerio ‘Hypo’ Verde amover@liber

1. File di log: importanza e analisiPrima parteYvette ‘vodka’ Agostinivodka@s0ftpj.orgValerio ‘Hypo’ Verdeamover@libero.it

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

3. 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

4. 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)

5. 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)

6. 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"

7. 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)

8. 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)

9. 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

10. 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]

11. 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]

12. 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

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

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

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

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

17. SYSLOGD 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 deamon di syslogging

18. IL FILE DI CONFIGURAZIONE DI SYSLOGD 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 /etc/syslog.conf

19. IL FILE DI CONFIGURAZIONE DI SYSLOGD 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 campo selettore

20. IL FILE DI CONFIGURAZIONE DI SYSLOGD E’ possibile specificare diverse azioni File normali : / Named Pipe - FIFO : | Terminali virtuali e console Macchine remote : @ Lista di utenti : , Tutti gli utenti : * Il campo azione

21. IL FILE DI CONFIGURAZIONE DI SYSLOGD *.=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 Esempio

22. KLOGD 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 ) Il kernel logger daemon

23. NOTE SULLA SICUREZZA ESAURIMENTO DELLO SPAZIO SU DISCO NO AUTH FLOOD RETE - CARICO MACCHINA Che problemi posso avere con syslog ?

24. COME INVIARE MESSAGGI A SYSLOG SHELL SCRIPTE’ 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.severityDi default logga con priorità user.notice Rendere i propri script e programmi più ‘loquaci’

25. COME INVIARE MESSAGGI A SYSLOG CBasta 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) PERLE’ possibile usare il modulo Sys::Syslog Rendere i propri script e programmi più ‘loquaci’

26. COME RENDERE (PIU’) SICURI I LOG Forwardare i log ad un log server Scrivere i log su un dispositivo write-once come un WORM Scrivere i messaggi direttamente su stampante Come evitare ‘cancellazioni accidentali’

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

28. 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 Le features di syslog-ng

29. SYSLOG-NG Approccio syslogdmessaggi filtrati in base a facility e severityfacilities troppo generiche come daemonpochi programmi consentono di ‘specificare’ la facility Approccio syslog-ng controllo più preciso sul filtering dei messaggimessaggi filtrati in base a message pathUn message path è composto da : una o più sorgenti di log una o più regole di filtering una o più destinazioni dei logQuindi 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 Message path

30. Destin. SYSLOG-NG Sorgente Filter Message path Destin. Sorgente Filter Destin. Sorgente Filter

31. SYSLOG-NG 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 Sorgenti

32. SYSLOG-NG 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 Tipi di sorgente

33. SYSLOG-NG 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) Tipi di sorgente

34. SYSLOG-NG 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 Filtri

35. SYSLOG-NG 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 Funzioni per i filtri

36. SYSLOG-NG 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 Destinazioni

37. SYSLOG-NG 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

38. SYSLOG-NG 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()

39. SYSLOG-NG 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 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 Tipi di destinazione : file() - opzioni

40. SYSLOG-NG 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 Log paths

41. SYSLOG-NG 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 Option

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

43. SYSLOG-NG 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 YEAR MONTH DAY WEEKDAY HOUR MIN SEC FULLHOSTconserva il chain_hostname nella macro template HOST PROGRAM MSG o MESSAGE IPSOURCE (non documentata)ip di provenienza UNIXTIME (non documentata)data in formato unix Macro

44. SYSLOG-NG 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. Macro ( osservazioni )

45. SYSLOG-NG 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 Tuning

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