Hack Like a Pro: Linux Basics for the Aspiring Hacker, Part 23 (Logging)

Welcome back, my amateur hackers!

When you are using and administering Linux, it is important to be conversant in the use of the log files. As you know, log files are the repository for much information about our system, including errors and security alerts.

If we are trying to secure Linux, it is crucial to know how to manage the logging functions to be able to know if your system has been attacked, and to then decipher what actually happened and who did it. If you are the attacker, it is crucial to understand what information can be gathered about you and your methods from these same log files so you can avoid leaving any trace behind.

Generally, Linux uses a daemon (a program that runs in the background) called syslogd that is a unified system for logging events on your computer. Several variations of syslog exist, including rsyslog and syslog-ng. Although they operate very similarly, they do have some minor differences. Since our Kali Linux is built on Debian, it comes with rsyslog by default, so that is what we will be using in this tutorial.

Step 1: Open a Terminal in Kali

Let's begin by opening a terminal in terminal. To find our rsyslog, we can simply type:

kali > locate rsyslog

Step 2: Open the Rsyslog Configuration File (rsyslog.conf)

Like nearly every application in Linux, rsyslog is managed and configured by a plain text configuration file. As you hopefully learned in earlier Linux tutorials, generally, configuration files are located in the /etc directory. In the case of rsyslog, it is located at /etc/rsyslog.conf. Let's open that file with any text editor (here I will use Leafpad).

kali > leafpad /etc/rsyslog.conf

As you can see above, the rsyslog.conf file comes well documented with numerous comments explaining its use.

Step 3: Format of the Rsyslog Configuration File

Let's navigate down a bit to below Line 50. Here begins the "Rules" section. This is where we can set the rules for what Linux logs.

The basic format for these rules is:

facility.priority action

The facility word references the program (such as mail, kernel, lpr, etc.) that generates the message to be logged. The priority keyword references the importance of the log message. Finally, the action keyword references the location that the log is to be sent to. This can be a file, remote computer, etc.

Facilities

The valid codes to put in place of the facility keyword in our configuration file rules include:

• auth
• authpriv
• daemon
• kern
• lpr
• mail
• mark
• news
• security
• syslog
• user
• uucp

An asterisk (*) refers to all facilities. You can select more than one facility by listing them separated by a comma.

Priorities

The valid codes for priority are:

• debug
• info
• notice
• warning
• warn
• error
• err
• crit
• alert
• emerg
• panic

The priority codes are listed from lowest (debug) priority to highest (emerg, panic). The warning is the same as warn, error is the same as err, and emerg is the same as panic. Error, warn, and panic are all deprecated and should not be used.

For instance, if you specify a priority code of alert, the system will log messages that are classified as alert or emerg, but not crit or below.

Actions

The action is usually a file name with its location. For instance, /var/log/messages.

Step 4: Examples of Facility.Priority Action

Let's look at some examples.

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 (kern) events of critical (crit) priority or higher to var/log/kernel.

*.emerg *

This example will log all events (*) of the emergency priority (emerg) to all logged on users.

Step 5: Logrotate

If you don't delete your log files, they will eventually fill your entire hard drive. On the other hand, if you delete your log files too frequently, you will not have them for an investigation at some future point in time. We can use logrotate to determine the balance between these opposing requirements.

We can rotate our log files by creating a cron job that periodically rotates our log files through the logrotate utility. The logroate utility is configured with the /etc/logrotate.conf. Let's open it with a text editor and take a look at it.

In most cases, the default configuration will work for most people, but note on Line 6 that the default setting is to rotate logs every 4 weeks. If you want to keep your logs for a longer or shorter time, this is the setting you should change.

Keep coming back, my amateur hackers, as we explore the use and administration of Linux that will help make you a professional hacker!