The logcheck package in Debian is divided into the three packages logcheck (the main program), logcheck-database (a database of regular expressions for the program) and logtail (prints loglines that have not yet been read). The Debian default (in /etc/cron.d/logcheck) is that logcheck is run every hour and after reboots.

This tool can be quite useful if properly customized to alert the administrator of unusual system events. Logcheck can be fully customized so that it sends mails based on events found in the logs and worthy of attention. The default installation includes profiles for ignored events and policy violations for three different setups (workstation, server and paranoid). The Debian package includes a configuration file /etc/logcheck/logcheck.conf, sourced by the program, that defines which user the checks are sent to. It also provides a way for packages that provide services to implement new policies in the directories: /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_, and /etc/logcheck/ignore.d.workstation/_packagename_. However, not many packages currently do so. If you have a policy that can be useful for other users, please send it as a bug report for the appropriate package (as a wishlist bug). For more information read /usr/share/doc/logcheck/README.Debian.

The best way to configure logcheck is to edit its main configuration file /etc/logcheck/logcheck.conf after installation. Change the default user (root) to whom reports should be mailed. You should set the reportlevel in there, too. logcheck-database has three report levels of increasing verbosity: workstation, server, paranoid. "server" being the default level, paranoid is only recommended for high-security machines running as few services as possible and workstation for relatively sheltered, non-critical machines. If you wish to add new log files just add them to /etc/logcheck/logcheck.logfiles. It is tuned for default syslog install.

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.

Por exemplo, o envio de mensagens para o console também é uma configuração interessante para muitos sistemas a nível de produção. Mas para muitos do sistemas também é importante adicionar uma nova máquina que servirá de servidor de logs (i.e. ela receberá os logs de todos os outros sistemas).

Root's mail should be considered also, many security controls (like snort) send alerts to root's mailbox. This mailbox usually points to the first user created in the system (check /etc/aliases). Take care to send root's mail to some place where it will be read (either locally or remotely).

Existem outras contas e aliases em seu sistema. Em um sistema pequeno, é provavelmente o método mais simples de ter certeza que todos estes aliases apontam para a senha de root, e aquele e-mail do root é redirecionado para a caixa de mensagens pessoal do administrador do sistema.

FIXME: It would be interesting to tell how a Debian system can send/receive SNMP traps related to security problems (jfs). Check: snmptrapfmt, snmp and 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=""

to

SYSLOGD="-r"

Next, configure the other machines to send data to the loghost. Add an entry like the following to /etc/syslog.conf:

  facility.level            @your_loghost

See the documentation for what to use in place of facility and level (they should not be entered verbatim like this). If you want to log everything remotely, just write:

  *.*                       @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.

Some log file permissions are not perfect after the installation (but of course this really depends on your local security policy). First /var/log/lastlog and /var/log/faillog do not need to be readable by normal users. In the lastlog file you can see who logged in recently, and in the faillog you see a summary of failed logins. The author recommends chmod 660 for both. Take a brief look at your log files and decide very carefully which log files to make readable/writable for a user with a UID other than 0 and a group other than 'adm' or 'root'. You can easily check this in your system with:

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

Para personalizar a forma que os arquivos de log são criados, você provavelmente terá que personalizar o programa que os gera. Se os arquivos de log forem rotacionados, no entanto, você poderá personalizar o comportamento do rotacionamento e da criação.