Gentoo Logo

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

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

1.  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 1.1: /usr/local/sbin/mail_pwd_failures.sh per postfix

#! /bin/sh
echo "$3" | mail -s "Warning (program : $2)" root

Per netqmail:

Codice 1.1: /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 1.1: /etc/metalog/metalog.conf

command  = "/usr/local/sbin/mail_pwd_failures.sh"

1.  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 1.1: /etc/syslog-ng/syslog-ng.conf

options {
        chain_hostnames(no);

        # The default action of syslog-ng is to log a STATS line
        # to the file every 10 minutes.  That's pretty ugly after a while.
        # Change it to every 12 hours so you get a nice daily update of
        # how many messages syslog-ng missed (0).
        stats_freq(43200);
};



source src {

    unix-stream("/dev/log" max-connections(256));

    internal();

};

source kernsrc { file("/proc/kmsg"); };

#define destinations
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"); };

# By default messages are logged to tty12...
destination console_all { file("/dev/tty12"); };

# ...if you intend to use /dev/console for programs like xconsole
# you can comment out the destination line above that references /dev/tty12
# and uncomment the line below.
#destination console_all { file("/dev/console"); };

#create filters
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"); };

#connect filter and destination
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); };

#default log
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!

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

Aggiornato il 2 aprile 2010

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.