[ << ]
[ < ]
[ Home ]
[ > ]
[ >> ]
3. Logging
Indice:
3.a. Introduzione
Si dovrebbe aggiungere un logging extra per catturare avvertimenti o errori
che potrebbero indicare un attacco in corso o concluso con successo. Gli
aggressori infatti spesso fanno dei controlli prima di attaccare.
È inoltre di vitale importanza che i file di log siano facilmente
leggibili e gestibili. Gentoo Linux vi permette di scegliere tra 3 diversi
loggers durante l'installazione.
3.b. Logging: Syslogd
Syslogd è il logger più comune per Linux e Unix in generale. Ha alcune
funzioni di log rotation, ma usare /usr/sbin/logrotate in un
cron job (logrotate è configurato in /etc/logrotate.conf)
potrebbe rivelarsi più utile, visto che logrotate ha molte funzioni.
Quanto spesso la log rotation dovrebbe essere eseguita, dipende dal carico
del sistema.
Sotto si trova il file syslog.conf standard, con alcune funzioni
aggiunte. Sono decommentate le righe cron e tty e si è
aggiunto un logging server remoto. Per migliorare ulteriormente la sicurezza
si può aggiungere il logging in due posti.
Codice 2.1: /etc/syslog.conf |
# /etc/syslog.conf Configuration file for syslogd.
#
# For more information see syslog.conf(5)
# manpage.
# This is from Debian, we are using it for now
# Daniel Robbins, 5/15/99
#
# First some standard logfiles. Log by facility.
#
auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* /var/log/mail.log
user.* -/var/log/user.log
uucp.* -/var/log/uucp.log
local6.debug /var/log/imapd.log
#
# Logging for the mail system. Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info -/var/log/mail.info
mail.warn -/var/log/mail.warn
mail.err /var/log/mail.err
# Logging for INN news system
#
news.crit /var/log/news/news.crit
news.err /var/log/news/news.err
news.notice -/var/log/news/news.notice
#
# Some `catch-all' logfiles.
#
*.=debug;\
auth,authpriv.none;\
news.none;mail.none -/var/log/debug
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
#
# Emergencies and alerts are sent to everybody logged in.
#
*.emerg *
*.=alert *
#
# I like to have messages displayed on the console, but only on a virtual
# console I usually leave idle.
#
daemon,mail.*;\
news.=crit;news.=err;news.=notice;\
*.=debug;*.=info;\
*.=notice;*.=warn /dev/tty8
#Setup a remote logging server
*.* @logserver
# The named pipe /dev/xconsole is for the `xconsole' utility. To use it,
# you must invoke `xconsole' with the `-file' option:
#
# $ xconsole -file /dev/xconsole [...]
#
# NOTE: adjust the list below, or you'll go crazy if you have a reasonably
# busy site..
#
#daemon.*,mail.*;\
# news.crit;news.err;news.notice;\
# *.=debug;*.=info;\
# *.=notice;*.=warn |/dev/xconsole
local2.* --/var/log/ppp.log
|
Gli aggressori probabilmente cercheranno di cancellare le loro tracce
editando o cancellando i file di log. Si può rendere più difficile questa
operazione salvando i log su uno o più server di logging remoti, su altre
macchine. Per maggiori informazioni su syslogd eseguire man syslog.
3.c. Metalog
Metalog di Frank Dennis non
è in grado di salvare i log su un server remoto, ma ha i suoi punti di forza
nelle performance e nella flessibilità di logging. Può ordinare i log per
nome del programma, urgenza e funzione (come syslogd), e utilizza espressioni
regolari con le quali si possono lanciare script esterni quando vengono
trovati specifici modelli. È molto buono per eseguire determinate azioni
quando se ne presenta la necessità.
La configurazione standard di solito è sufficiente. Se si vuole essere
avvertiti via email ogni volta che qualcuno sbaglia a digitare una password,
usare uno dei seguenti script.
Per postfix:
Codice 3.1: /usr/local/sbin/mail_pwd_failures.sh per postfix |
#! /bin/sh
echo "$3" | mail -s "Warning (program : $2)" root
|
Per netqmail:
Codice 3.2: /usr/local/sbin/mail_pwd_failures.sh per netqmail |
#!/bin/sh
echo "To: root
Subject:Failure (Warning: $2)
$3
" | /var/qmail/bin/qmail-inject -f root
|
Ricordarsi di rendere eseguibile lo script eseguendo
/bin/chmod +x /usr/local/sbin/mail_pwd_failures.sh
Poi decommentare la riga sotto "Password failures" in
/etc/metalog/metalog.conf in questo modo:
Codice 3.3: /etc/metalog/metalog.conf |
command = "/usr/local/sbin/mail_pwd_failures.sh"
|
3.d. Syslog-ng
Syslog-ng fornisce alcune delle funzioni di syslog e metalog, ma con una
piccola differenza. Esso può filtrare i messaggi in base al livello e al
contenuto (come metalog), e supporta il remote logging come syslog, gestisce
i log di syslogd (anche i flussi da Solaris), scrive su TTY, esegue
programmi, e può funzionare come logging server. In pratica, è il meglio di
entrambi i logger con in più una configurazione avanzata.
Ecco un file di configurazione classico, leggermente modificato.
Codice 4.1: /etc/syslog-ng/syslog-ng.conf |
options {
chain_hostnames(no);
stats_freq(43200);
};
source src {
unix-stream("/dev/log" max-connections(256));
internal();
};
source kernsrc { file("/proc/kmsg"); };
destination authlog { file("/var/log/auth.log"); };
destination syslog { file("/var/log/syslog"); };
destination cron { file("/var/log/cron.log"); };
destination daemon { file("/var/log/daemon.log"); };
destination kern { file("/var/log/kern.log"); };
destination lpr { file("/var/log/lpr.log"); };
destination user { file("/var/log/user.log"); };
destination mail { file("/var/log/mail.log"); };
destination mailinfo { file("/var/log/mail.info"); };
destination mailwarn { file("/var/log/mail.warn"); };
destination mailerr { file("/var/log/mail.err"); };
destination newscrit { file("/var/log/news/news.crit"); };
destination newserr { file("/var/log/news/news.err"); };
destination newsnotice { file("/var/log/news/news.notice"); };
destination debug { file("/var/log/debug"); };
destination messages { file("/var/log/messages"); };
destination console { usertty("root"); };
destination console_all { file("/dev/tty12"); };
#destination console_all { file("/dev/console"); };
filter f_authpriv { facility(auth, authpriv); };
filter f_syslog { not facility(authpriv, mail); };
filter f_cron { facility(cron); };
filter f_daemon { facility(daemon); };
filter f_kern { facility(kern); };
filter f_lpr { facility(lpr); };
filter f_mail { facility(mail); };
filter f_user { facility(user); };
filter f_debug { not facility(auth, authpriv, news, mail); };
filter f_messages { level(info..warn)
and not facility(auth, authpriv, mail, news); };
filter f_emergency { level(emerg); };
filter f_info { level(info); };
filter f_notice { level(notice); };
filter f_warn { level(warn); };
filter f_crit { level(crit); };
filter f_err { level(err); };
filter f_failed { message("failed"); };
filter f_denied { message("denied"); };
log { source(src); filter(f_authpriv); destination(authlog); };
log { source(src); filter(f_syslog); destination(syslog); };
log { source(src); filter(f_cron); destination(cron); };
log { source(src); filter(f_daemon); destination(daemon); };
log { source(kernsrc); filter(f_kern); destination(kern); };
log { source(src); filter(f_lpr); destination(lpr); };
log { source(src); filter(f_mail); destination(mail); };
log { source(src); filter(f_user); destination(user); };
log { source(src); filter(f_mail); filter(f_info); destination(mailinfo); };
log { source(src); filter(f_mail); filter(f_warn); destination(mailwarn); };
log { source(src); filter(f_mail); filter(f_err); destination(mailerr); };
log { source(src); filter(f_debug); destination(debug); };
log { source(src); filter(f_messages); destination(messages); };
log { source(src); filter(f_emergency); destination(console); };
log { source(src); destination(console_all); };
|
Syslog-ng è molto facile da configurare, ma è anche molto facile dimenticarsi
di qualcosa nel file di configurazione, dato che è molto grande. L'autore
ancora promette alcune funzioni extra, come la criptazione, l'autenticazione,
la compressione e il controllo MAC (Mandatory Access Control). Con queste
opzioni sarà perfetto per il network logging, dato che l'aggressore non potrà
spiare il log.
E syslog-ng ha un altro vantaggio: non ha bisogno di essere eseguito come root!
3.e. Analisi dei log con Logcheck
Certo, il solo tenere dei log non risolve i problemi. Una applicazione come
Logcheck può rendere l'analisi regolare dei log molto più semplice. Logcheck
è uno script, accompagnato da un binario chiamato logtail, che è
eseguito dal demone cron e controlla i log in base a un set di regole, alla
ricerca di attività sospette. Poi invia l'output alla casella di posta
dell'utente root.
Logcheck e logtail fanno parte del pacchetto app-admin/logsentry.
Logcheck utilizza quattro file per filtrare le voci importanti dei log da
quelle non importanti. Questi file sono logcheck.hacking, che
contiene messaggi conosciuti di attacchi di hackers,
logcheck.violations, che contiene modelli indicanti violazioni
della sicurezza, logcheck.violations.ignore, che contiene parole
chiave che dovrebbero ritrovarsi nel file delle violazioni, consentendo alle
voci normali di essere ignorate, e logcheck.ignore, che contiene
le voci da ignorare.
Avvertenza:
Non lasciare vuoto logcheck.violations.ignore. Logcheck utilizza
grep per analizzare i log, e alcune versioni di esso considerano un file
vuoto come una wildcard. Tutte le violazioni sarebbero così ignorate.
|
[ << ]
[ < ]
[ Home ]
[ > ]
[ >> ]
I contenuti di questo documento sono rilasciati sotto la licenza Creative
Commons - Attribution / Share Alike.
|
