Il pacchetto logcheck in Debian è diviso in tre parti: logcheck (il programma principale), logcheck-database (un database di espressioni regolari per il programma) e logtail (visualizza le righe corrispondenti ai log che non sono stati ancora visualizzati). In Debian è predefinito (in /etc/cron.d/logcheck) che logcheck venga eseguito giornalmente ogni ora e dopo ogni riavvio del sistema.

Questo strumento, se propriamente configurato, può essere molto utile per segnalare all'amministratore eventi inusuali del sistema. logcheck può essere completamente personalizzato, in modo da spedire mail a proposito di eventi registrati nei log che sembrano degni di attenzione. L'installazione predefinita include profili (per gli eventi da ignorare e le violazioni delle politiche adottate) per tre diverse configurazioni (workstation, server e paranoid). Il pacchetto Debian include un file di configurazione /etc/logcheck/logcheck.conf, generato dal programma, che definisce a quale utente vengono spedite le verifiche. Inoltre fornisce, ai pacchetti che offrono servizi, un modo per implementare nuove politiche, nelle cartelle: /etc/logcheck/cracking.d/_packagename_, /etc/logcheck/violations.d/_packagename_, /etc/logcheck/violations.ignore.d/_packagename_, /etc/logcheck/ignore.d.paranoid/_packagename_, /etc/logcheck/ignore.d.server/_packagename_ e /etc/logcheck/ignore.d.workstation/_packagename_. Tuttavia, al momento, non molti pacchetti ne fanno uso. Se avete una politica che può essere utile ad altri utenti, per favore speditela come rapporto bug per il pacchetto appropriato (come wishlist bug). Per ulteriori informazioni leggete /usr/share/doc/logcheck/README.Debian.

Il modo migliore per configurare logcheck dopo l'installazione è modificare il suo principale file di configurazione /etc/logcheck/logcheck.conf. Cambiate l'utente predefinito (root) a cui verranno spediti i rapporti. Sempre in quel file di configurazione dovrete anche modificare il livello di prolissità del rapporto. logcheck-database ha tre livelli di prolissità, ovvero: workstation, server, paranoid. "server" è il livello predefinito, "paranoid" è consigliato solo per le macchine che devono garantire un'alta sicurezza per l'espletamento di determinati servizi e "workstation" per sistemi relativamente al riparo, in posizioni non critiche. Se desiderate aggiungere nuovi file di log dovrete solamente aggiungere righe in /etc/logcheck/logcheck.logfiles. È già ottimizzato per l'installazione predefinita del demone syslog.

Once this is done you might want to check the mails that are sent, for the first few days/weeks/months. If you find you are sent messages you do not wish to receive, just add the regular expressions (see regex(7) and egrep(1)) that correspond to these messages to the /etc/logcheck/ignore.d.reportlevel/local. Try to match the whole logline. Details on howto write rules are explained in /usr/share/doc/logcheck-database/README.logcheck-database.gz. It's an ongoing tuning process; once the messages that are sent are always relevant you can consider the tuning finished. Note that if logcheck does not find anything relevant in your system it will not mail you even if it does run (so you might get a mail only once a week, if you are lucky).

Debian comes with a standard syslog configuration (in /etc/syslog.conf) that logs messages to the appropriate files depending on the system facility. You should be familiar with this; have a look at the syslog.conf file and the documentation if not. If you intend to maintain a secure system you should be aware of where log messages are sent so they do not go unnoticed.

Per esempio, mandare i messaggi su una console è una configurazione utile per sistemi di diversi livelli di produzione. Ma per altri sistemi è ugualmente importante aggiungere una nuova macchina che faccia da loghost (cioè che riceva i log da tutte le altre macchine del sistema).

Dovreste considerare anche la posta di root, molti programmi per il controllo della sicurezza (come snort) spediscono gli avvisi a root via posta. Questa mailbox di solito punta al primo utente creato nel sistema (controllate /etc/aliases). Preoccupatevi di mandare la posta di root in qualche posto dove verrà letta (localmente o remotamente).

Ci sono altri account di ruolo ed alias nel tuo sistema. In un piccolo sistema é, probabilmente, più facile far sì che tutti gli alias puntino a root e che la posta di root venga inoltrata alla casella di posta personale dell'amministratore di sistema.

FIXME: sarebbe interessante spiegare come un sistema Debian possa spedire/ricevere SNMP trap riguardanti problemi di sicurezza (jfs). Controllare: snmptrapfmt, snmp e snmpd.

A loghost is a host which collects syslog data remotely over the network. If one of your machines is cracked, the intruder is not able to cover the tracks, unless hacking the loghost as well. So, the loghost should be especially secure. Making a machine a loghost is simple. Just start the syslogd with

syslogd -r

and a new loghost is born. In order to do this permanently in Debian, edit /etc/default/syslogd and change the line

SYSLOGD=""

in

SYSLOGD="-r"

Successivamente, configurate le altre macchine perché spediscano i dati al loghost. Aggiungete una riga simile alla seguente al file /etc/syslog.conf:

  facility.level            @your_loghost

Guardate la documentazione per cosa usare al posto di facility e level (non dovrebbero contenere queste parole). Se volete registrare ogni cosa remotamente, scrivete:

  *.*                       @your_loghost

into your syslog.conf. Logging remotely as well as locally is the best solution (the attacker might presume to have covered his tracks after deleting the local log files). See the syslog(3), syslogd(8) and syslog.conf(5) manpages for additional information.

It is not only important to decide how alerts are used, but also who has read/modify access to the log files (if not using a remote loghost). Security alerts which the attacker can change or disable are not worth much in the event of an intrusion. Also, you have to take into account that log files might reveal quite a lot of information about your system to an intruder who has access to them.

Alcuni permessi sui file di log non sono perfetti dopo una installazione (ma questo ovviamente dipende dalla vostra politica di sicurezza locale). Per prima cosa /var/log/lastlog e /var/log/faillog non necessitano di essere letti dai normali utenti. Nel file lastlog potete vedere chi ha effettuato un login recentemente e in faillog potete vedere un riassunto dei login falliti. L'autore raccomanda chmod 660 per entrambi. Date una rapida occhiata ai vostri file di log e decidete molto attentamente quali rendere leggibili/scrivibili per utenti con UID diversi da 0 e gruppi che non siano 'adm' o 'root'. Si può facilmente controllare se quanto descritto è conforme al vostro sistema con:

  #  find /var/log -type f -exec ls -l {} \; | cut -c 17-35 |sort -u
  (see to what users do files in /var/log belong)
  #  find /var/log -type f -exec ls -l {} \; | cut -c 26-34 |sort -u
  (see to what groups do files in /var/log belong)
  # find /var/log -perm +004
  (files which are readable by any user)
  #  find /var/log \! -group root \! -group adm -exec ls -ld {} \;
  (files which belong to groups not root or adm)

Per personalizzare la creazione dei file di log, probabilmente dovreste modificare il programma che li genera. Se i file di log vengono ruotati (vgs. logrotate), ad ogni modo, è possibile personalizzare il comportamento di creazione e rotazione.