Many system (and kernel) events cause entries to be made in log files. These can be used to audit a system and track cracking attempts.

Manually scanning log files for signs of cracking attempts or other undesirable behaviour is time-consuming and usually happens well after any intrusion attempts are logged --- too late to prevent a successful attack. These problems are compounded by all good systems administrators who are inherently lazy. To resolve these problems utilities have been developed which scan (tail) logs on your behalf and report significant events by email. We discuss logcheck and swatch.

We also discuss logging of events to a remote host. By default, syslogd and klogd log their messages, as configured by syslog.conf in such places as /var/log/... (Linux) and /var/adm/... (Solaris). Since these files are on the localhost then any hacker can "clean them" in an attempt to cover their tracks. If messages are (also) logged to a remote host then such a clean up becomes more difficult, particularly if the remote host is running a different operating system.

6.1. iblm

We're all lazy at heart --- all good sysadmins are. I'm much more likely to check my log files if they are "on a plate" in front of me, displayed and continually updated, different log-files available at the click of a tab/button. So I use iblm which can be downloaded from sourceforge.

6.2. Remote Logging

Below is an account of how I set up cross-logging between my Linux box and my Solaris box. At the time of writing, August 2000, I have one machine running RedHat 6.2 Linux and a second running Solaris 2.8. Details given below, in particular bug/feature notes, may differ for different versions.

6.2.1. Some General Points to Make

• The syslog daemons on Linux and Solaris take different command-line arguments; the configuration files and corresponding message types are different, for example, Linux has a message type authpriv, whilst Solaris apparently does not.
  
  
• Any messages sent from one host to another are logged according to the configuration file on the remote host, hence authpriv messages sent from a Linux box to a Solaris box will not be logged.
  
  
• After altering the syslog.conf file, the daemon will need to be restarted, e.g., using kill -HUP <processid>.
  
  
• The whitespace in syslog.conf consists of tabs.

6.2.2. The Daemons

The first thing to check is that the syslog daemons, syslogd, have been started with the command-line switches set so that messages from remote hosts are accepted.

Linux

Ensure the -r switch is set. My daemon is:

/sbin/syslogd -m 0 -r

Solaris

Ensure the -t switch is not set. My daemon is:

/usr/sbin/syslogd

6.2.3. The Configuration Files

Linux

This is the significant part of /etc/syslog.conf:

authpriv.* /var/log/secure auth.* /var/log/auth auth.* @boiler.csu.umist.ac.uk

N.B. There is no point in sending authpriv messages to the Solaris machine as Solaris does not apparently recognise this class of messages.

Solaris

This is the significant part of /etc/syslog.conf:

mail.warning;mail.info @talby.csu.umist.ac.uk # ...that's right, mail, not auth... auth.notice @talby.csu.umist.ac.uk

N.B. There is a bug in the Solaris 2.8 syslog system. the classes mail.* log, for example, telnet authentication! (Somebody has a table wrong somewhere.) This means that authentication messages from my Solaris box end up with the mail logs on my Linux box...

6.2.4. References

• Linux Journal, 2000 July, "The System Logging Deamons, syslogd and klogd".
• Linux Journal, 2000 June, "Secure Logging Over a Network".