Linux Basics for Hackers

The rsyslog Logging Rules

The rsyslog rules determine what kind of information is logged, what programs have their messages logged, and where that log is stored. As a hacker, this allows you to find out what is being logged and where those logs are written so you can delete or obscure them. Scroll to line 50 and you should see something like Listing 11-2.

###############
#### RULES ####
###############
# # First some standard log files. Log by facility.
#
auth,authpriv.* /var/log/auth.log *.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log daemon.* -/var/log/daemon.log kern.* -/var/log/kern.log 1pr.* -/var/log/lpr.log mail.* -/var/log/mail.log user.* -/var/log/user.log
#
# Logging for the mail system. Split it up so that # it is easy to write scripts to parse these files.
#
mail.info -/var/log/mail.info mail.warn -/var/log/mail.warn mail.err /var/log/mail.err

Listing 11-2: Finding the logging rules in rsyslog.conf
Each line is a separate logging rule that says what messages are logged and where they’re logged to. The basic format for these rules is as follows:

facility.priority action

The facility keyword references the program, such as mail, kernel, or lpr, whose messages are being logged. The priority keyword determines what kind of messages to log for that program. The action keyword, on the far right, references the location where the log will be sent. Let’s look at each section more closely, beginning with the facility keyword, which refers to whatever software is generating the log, whether that’s the kernel, the mail system, or the user.
The following is a list of valid codes that can be used in place of the facility keyword in our configuration file rules: auth/authpriv Security/authorization messages cron Clock daemons daemon Other daemons kern Kernel messages lpr Printing system mail Mail system
user Generic user-level messages
An asterisk wildcard (*) in place of a word refers to all facilities. You can select more than one facility by listing them separated by a comma.
The priority tells the system what kinds of messages to log. Codes are listed from lowest priority, starting at debug, to highest priority, ending at panic. If the priority is *, messages of all priorities are logged. When you specify a priority, messages of that priority and higher are logged. For instance, if you specify a priority code of alert, the system will log messages classified as alert and higher priority, but it won’t log messages marked as crit or any priority lower than alert.
Here’s the full list of valid codes for priority:

debug info notice warning warn error err crit alert emerg panic
The codes warning, warn, error, err, emerg, and panic have all been deprecated and should not be used.
The action is usually a filename and location where the logs should be sent. Note that generally, log files are sent to the /var/log directory with a filename that describes the facility that generated them, such as auth. This means, for example, that logs generated by the auth facility would be sent to /var/log.auth.log.
Let’s look at some examples of log rules:

mail.* /var/log/mail

This example will log mail events of all (*) priorities to /var/log/mail.

kern.crit /var/log/kernel

This example will log kernel events of critical (crit) priority or higher to /var/log/kernel.

*.emerg *

This last example will log all events of the emergency (emerg) priority to all logged-on users. With these rules, the hacker can determine where the log files are located, change the priorities, or even disable specific logging rules.