- Your System
- Checking Out Your System's Content
- Determining User Access
- Reviewing the syslog.conf File
Reviewing the syslog.conf File
Now that we're happy with our inetd.conf file, let's take a quick look at our /etc/syslog.conf file. The standard syslog.conf is rather bland, and that's okay for many systems. But if you have a sensitive server, it just won't do.
Reviewing how a syslog.conf file is set up, let's take a look a some default entries:
daemon.alert /var/log/alert mail.* /var/log/mail news.* /var/log/news.all uucp,news.err /var/log/spooler authpriv.*;auth.* /var/log/secure *.info;news,mail,authpriv,auth.none -/var/log/messages *.emerg *
I've rearranged the order of these lines taken from a default Caldera install after dropping all the comments and blank lines (easily done with grep: grep -v ^# /etc/syslog.conf | grep -v ^$). Let's talk about these entries so that we at least understand what's being logged where and when.
Log Entries
The first thing I want you to notice is that you have two columns separated by whitespace. The left column is the what, and the right column is the where. Most entries will be a write to a log. If you don't care that each log entry is immediately sync'd to disk, you can use a hyphen as the first character (as is done with the sixth entry here).
But "where" can be more than a file. A "where" can be a logged in a user or another system. A file must be full-pathed and so will start with a "/". A special case file would be something like /dev/console, where special handling is done for the console. A system user is shown by name, so it starts with an alphanumeric character. You can put in a comma-separated list of users, and syslog will send to any that are logged in. To send to everyone logged on, as in an emergency, you can use a "*". A remote system starts with an "@". Logging to remote systems is done via UDP. The usual problems accompany this type of logging: If you are under a denial-of-service attack and your network is saturated, the log messages may not make it to their destination. You may also log messages to a named pipe. The pipe that you want to use must exist before syslogd is started so that syslogd can attach to it. Named pipes will be listed in syslog.conf by preceding the full-pathed name with a "|" symbol.
By the way, a good insurance policy is to maintain your logs on a nonroot partition. If someone can force your logs to grow by triggering hundreds of syslog entries, and if your logs are on your root partition, you could wind up with a full root partition and a frozen system.
Priorities
Now let's turn our attention to the left column. This column is comprised of two parts, a facility and a priority. The two are separated with a ".". Looking at the first line in the sample previous syslog.conf file, you see daemon.alert. This means that with the daemon facility (more on facilities follows), all messages of alert or higher precedence are sent to /var/log/alerts.
Priorities are fairly simple. In descending order, they are as follows:
Alternate names for some priorities are shown in parenthesis. The priority names in parenthesis are deprecated and should not be used.
Specifying a particular priority specifies not only that priority, but all priorities above it by default. A comma-separated list of priorities is allowed. If you want only a particular priority but not priorities above it, you need to precede the priority with "=". You can also exclude a priority by prefacing it with "!". If you want to exclude just this priority, you can combine the two symbols, but the exclamation must come before the equal sign. Two priorities that syslog understands that are not listed are * and none, meaning "all" and "nothing," respectively.
The facility can be a comma-separated list of logging facilities. Facilities include these:
For the most part, the facilities are self-explanatory. Those not obvious probably use one of the local facilities. For example, by convention, PPPD and chat use local2.
Looking again at our sample syslog.conf file, you can see that mail and news, regardless of the priority, all go to either /var/log/mail or /var/log/news. The next line shows that all messages of error priority or higher coming from UUCP or news go to /var/log/spool.
The next sample line shows that all priority authpriv and all priority auth messages go to /var/log/secure. So, you can see how to combine different selectors (facility.priority combinations) on the same line. They are separated by semicolons. In this case, because the priorities are both the same, it would be easier to write this as authpriv,auth.*.
The next line shows the power of the syslog selector line. First, we see that every facility, starting with priority info, is to be logged to /var/log/messages (buffered). Syslog expands the * and lists each facility. Following the semicolon, though, we have mail, news, auth, and authpriv listed, with a priority of none. This modifies the all facilities at info by removing mail, news, auth, and authpriv messages (because the priority none means just that—no messages). You can see from this line that what comes later modifies what came earlier.
Finally, any facility with an emergency message is broadcast to all logged in users.
That's it—it's really that easy. Just one final note: If you specify another system to receive messages (a central logging server, for example), that server's syslog daemon must be started with the -r option to bind the syslog UDP port. You'll want to take the precaution of using iptables to block unauthorized systems from sending you syslog messages so that someone can't flood your syslog server as part of an attack on systems on your network.