Logging is very important in managing a system. However, some of us may not know what it is or why logging can be so helpful in many instances. Today, we will discuss it in this article, specifically the logs in a Debian-based Linux Distributions.
What is log?
Log is a record in the form of messages for various activities or events that occur in a system or software. It is common for the logs to be stored in a file which is then called a log file. But, it is not always the case. Sometimes, logs may be built into software where the logs can be stored in a database so than can be presented live in real time to users.
Why do logging?
There are reasons we do logging.
Troubleshooting
Resolving and identifying problems or issues can be really challenging without logs in hand. By using logs, detailed information regarding the causes of events such as errors or warnings can be mitigated much more easily. In addition, individuals or teams dealing with issues can detect problems much more easily because logs can provide a valuable source of information and give a broader picture of how the actual system works.
Monitoring
Logs can provide information in real time regarding events or activities carried out in a system or application. That way, monitoring logs can be the way to detect behavior that is currently happening in the system. In terms of security, this will be very useful, especially in cases of an incident or security breaches occurrence which can threaten the system as a whole.
Auditing
Logs also provide information to mitigate security risk and detect anomalies. By reviewing logs, abnormal or unexpected events that lead to potential threats or suspicious activity can be detected, thus may help the auditor to prevent this from happening. Additionally, logs can be used to trace the origins of malicious activity.
Why centralized logging?
In most cases, it is highly recommended to have centralized logging. Among the most prominent reasons are security and better management. From a security standpoint, in cases where the target server or host experiences an attack, having centralized logs will be very helpful for tracing the activity of the attacker as well as in analyzing the current conditions on the compromised host, making a network system more resilient. Having centralized logs is also very helpful for handling and maintaining multiple servers at once. This simplifies a great deal of work by using one centralized log.
Linux logs explained
Before going deeper into the Linux log files, it might be helpful to know some commands while analyzing and reviewing logs.
man: check any options available as well as the concise definition regarding some specific command (e.g.man lastlog)tail: continuously track a specific log in case you need to see the logs updating in almost real time. In the event that an incident or crash occurs, this will be very helpful (e.g.tail -f /var/log/syslog)grep: filtering any information we need. Grep can also be used to search for specific patterns we would like to know (e.g.last -aiF | grep “still logged in”).cat: Displaying content of log files (e.g.cat /var/log/auth.log).less: similar to cat, but gives better navigation over large log files (e.g.less /var/log/kern.log).journalctl: viewing systemd journal (e.g.journalctl -n 10).
In most Linux distributions, the log files are located at /var/log/. However, specific files may be stored in different locations depending on the distribution family used. For example, log files on Ubuntu and Fedora are located in /var/log/. To check for login attempts on Ubuntu, you can find them in /var/log/auth.log whilst with Fedora, you may need an utility like lastb as it has no auth.log file.
It would be too much to explain everything, so it will only focus on Debian- Based Distributions like Ubuntu and summarizes logs that are essential to know.
Authentication attempt
Location:
/var/log/auth. log
This log provides information regarding login attempts on the system which is very useful for security reasons. Any login attempts via SSH are noteworthy, since remote access can be made from anywhere with SSH. At some point, the attacker is likely to use this protocol to take over the system. In addition, attempts to access the root account are also very important to monitor because the root account will be the main target for malicious actors to be able to do everything.
/var/logs/wtmp
This file contains a collection of login and logout attempts that require a
special utility to read them called last. On the other hand, if you try to
open this file manually, like using the cat command, you will see text which
is hard to read. Last will do a search on this file and list all logged in
and out users. With the last -aiF command, you can detect user activity and
more specifically identify currently active users. As an example, you can see
who’s still logged in by typing the following command.
last -aiF | grep -e "still logged in"
/var/logs/btmp
This file is specifically focusing on logging the bad login attempts. Just
like wtmp, it requires the particular utility called lastb. Unlike last,
lastb requires a root account to access it. You can use the command with the
same options as last.
sudo lastb -aiF
/var/log/lastlog
Again, this tool needs you to track the most recent login by using an utility
called lastlog. You can use it by simply typing lastlog in the terminal.
APT Packages
**Location: **
/var/log/apt/history.log
Debian-based Linux Distributions have apt as a package management system.
Other distributions have different package management systems, like dnf for
Fedora or pacman for Arch. All activities related to this apt package
manager will be stored in the history log which can be found at the location
mentioned above. The provided information can be anything regarding upgrades,
installations, removals or anything that causes changes to the system.
Kernel Initialization
**Location: **
/var/log/kern.log
**CLI: **
$dmesg
The kern.log file generates logs that come directly from the kernel. This file uses several rotated logs, to contain the information. Essentially, the kernel manages hardware resources, system memory, and running processes. By analyzing this log file, such occurrences like hardware failures, driver problems and system crashes can be tracked.
Cron Jobs
Location:
/var/log/cron. log
/var/logs/messages
/var/log/syslog
Cron is used for scheduling applications or running specific commands. There are times, though, when it does not work as expected and sadly, cron does not come with a separate log file despite the important role it can play. In fact, it does exist, but by default it is disabled. To enable it, go to /etc/rsyslog.d/50-default.conf**** and uncomment or remove the **#** symbol from the line, so it will be like this.
cron.* /var/log/cron.log
Next, you need to restart the rsyslog service using the command below.
sudo systemctl restart rsyslog
Now, you are supposed to be able to see the new file named cron.log in /var/log/. If not, you can wait until a new cron job runs.
System Logs
**Location: **
/var/log/syslog
As the name implies, syslog is used to monitor system events more thoroughly. For example, a crash that occurs on the system can be caused by a system out of memory. The error can be traced by using the syslog. Besides, syslog can also be used to monitor applications, cron jobs, systemd and so on.
Summary
Logging is the process of recording system events and activities in a log file. Logs can be used for troubleshooting technical issues, monitoring system performance, and analyzing user activity. Thus, maintaining an effective logging system in Linux is essential for ensuring system stability and security.