KBTAG: kben1000022
URL: http://www.securityportal.com/lskb/10000000/kben10000022.html
Date created: 13/04/2000
Date modified:
Date removed:
Authors(s): Kurt Seifried seifried@securityportal.com
Topic: Logging with Syslog
Keywords: Logging
Syslog is the de facto standard for logging events in Linux and UNIX in general.
In a nutshell klogd handles kernel messages, depending on your setup this can range from almost none to a great deal if for example you turn on process accounting. It then passes most messages to syslogd for actual handling (that is it places the data in a physical file). The man pages for sysklogd, klogd and syslog.conf are pretty good with clear examples. One exceedingly powerful and often overlooked ability of syslog is to log messages to a remote host running syslog. Since you can define multiple locations for syslog messages (i.e. send all kern messages to the /var/log/messages file, and to console, and to a remote host or multiple remote hosts) this allows you to centralize logging to a single host and easily check log files for security violations and other strangeness. There are several problems with syslogd and klogd however, the primary ones being the ease of which once an attacker has gained root access to deleting/modifying log files, there is no authentication built into the standard logging facilities.
The standard log files that are usually defined in syslog.conf are:
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler
The first one (messages) gets the majority of information typically; user logins, TCP_WRAPPERS dumps information here, IP firewall packet logging typically dumps information here and so on. The second typically records entries for events like users changing their UID/GID (via su, sudo, etc.), failed attempts when passwords are required and so on. The maillog file typically holds entries for every pop/imap connection (user login and logout), and the header of each piece of email that goes in or out of the system (from whom, to where, msgid, status, and so on). The spooler file is not often used anymore as the number of people running usenet or uucp has plummeted, uucp has been basically replaced with ftp and email, and most usenet servers are typically extremely powerful machines to handle a full, or even partial newsfeed, meaning there aren't many of them (typically one per ISP or more depending on size). Most home users and small/medium sized business will not (and should not in my opinion) run a usenet server, the amount of bandwidth and machine power required is phenomenal, let alone the security risks.
You can also define additional log files, for example you could add:
kern.* /var/log/kernel-log
And you can selectively log to a separate log host:
*.emerg @syslog-host mail.* @mail-log-host
Which would result in all kernel messages being logged to /var/log/kernel-log, this is useful on headless servers since by default kernel messages go to /dev/console (i.e. someone logged in at the machines). In the second case all emergency messages would be logged to the host syslog-host, and all the mail log files would be sent to the mail-log-host server, allowing you to easily maintain centralized log files of various services. The default syslogd that ships with most Linux distributions is horribly insecure, log files are easily tampered with (or outright destroyed), and logging across the network is completely insecure as well as dangerous for the servers involved. I do not advise using syslog if you actually have a need for reliable logging (i.e. the ability to later view log files in the event of a break-in).
The default file permissions on the log files are usually read / write for root, and nothing for anyone else. In addition to this you can (and should) set the files append only (remember to take logrotate into account though, it needs to zero the files). This will prevent any deletion / modifications to the log files unless root unsets the append only attribute first.