The System Logger - syslogd


User programs and services that run on Unix systems can either log to their own log files directly, or through a standardised system logging service called syslog.

On System V the syslog binary is called "syslog", on FreeBSD it is called "newsyslog", and on Linux it is called "syslogd".

There are library calls in the standard C library that offer application programmers access to the syslog service. This shows that the use of syslog is an inherent part of Unix application design.

Many other security programs such as ssh and tcpwrappers (See Network Administration) will log to syslogd. It is important that syslogd is always running on your system.

Additional security precautions that you could take are:

  1. Pick one machine as your loghost and secure it as much as possible. If possible work to run syslogd on this machine and nothing else.

    To ensure full resources stop the other system daemons such as inetd and sendmail, you will also need basic networking but nothing else should be running

    You could consider not running ssh on your loghost and then you would have to log in to the loghost console to check the security logs.

  2. Make sure the system clock is always set to the correct time on the loghost.

  3. In order to allow the loghost to receive syslog messages from other machines, you may need to enable it to receive remote logging.

    Do this by adding the -r command line upon syslogd startup.

    Edit /etc/rc.d/init.d/syslog, and find the line:

    daemon syslogd 

    add the -r option to this line as follows:

    daemon syslogd -r
  4. Set syslogd up so that everytime syslogd is started the log information is sent to the loghost as follows:

    To do this, make sure that the client is able to receive calls from loghost, then add an entry into /etc/hosts so that logging is not interrupted if there is a resolving problem and then add the following to the client /etc/syslog.conf file as the last line in the file:


How does syslogd work

Syslogd is started by the normal startup scripts in /etc/rc.d/rc3.d.

Let's review some of what we have learnt form the introduction, the configuration file for syslogd is /etc/syslog.conf. Syslogd is the system daemon or process that does the actual logging.

Time specific messages are recorded into log files as designated by the .conf file.

Why use a log file to record happenings on systems?

If you are being notified of login attempts and failures, system errors and possible security problems then you will find that:

  • A log will keep track of what is happening on your system at all times.

  • It will alert you to problems before they arise, for example; if your partition is becoming full or if there is an impending attack.

  • The problem would be seen prior to your "healthy" backups being cycled out.

Let's look at the .conf file

"In syslog.conf, there are two fields, the selector and the action. The selector field tells what to log and the action field tells where to log it (i.e., to a certain file, or to a certain host on the network).

The selector has the form: facility.level

The action has the form of a path, e.g., /var/log/messages or /var/log/secure, or /dev/console, or a full host name preceeded by an @ sign:

The facility and level have many possible combinations. But for security's sake, it is far easier to just log everything. "

Setting up the loghost

[Note] Note

If you are part of a cluster, make sure the machine logs to another loghost as well as itself.

  • Make sure the time is correct on your system. Otherwise you will have trouble tracing problems and break-ins.

  • System logs are generally kept in the /var partition, mainly /var/log. Make sure that /var is large enough to hold much more than the basic log file. This is to prevent accidental overflows, which could potentially erase important logging info.

  • The default syslog.conf does not do a very good job of logging. Try changing the entry for /var/log/messages to:

    *.info /var/log/messages
  • If you start getting too much of a certain message (say from sendmail), you can always bump that particular facility down by doing:

    *.info;mail.none /var/log/messages