This content originally appeared on Level Up Coding - Medium and was authored by Andrea R.
When you have more than one server, it might be difficult to keep up with what’s happening. Instead of looking through thousands of lines of logs divided into different files into different machines, why don’t you send everything to a central logging station, where you can analyze everything without losing the big picture?
The purpose of this article is to show you a practical hands-on example of how to set up a centralized logging machine that receives logs from other nodes of the network. To do this, I will use the Linux Auditing System.
Disclaimer: I am not an expert on this technology by any means. I want to share with you my journey in learning and experimenting with this cool technology. I hope that you’ll have fun as much as I did.
What is Linux Auditing System?
For those of you who don’t know anything about it (like me a couple of days ago), the Linux Kernel Auditing System is a feature to the Linux kernel that allows in-depth information collection about any relevant action on a system.
Being implemented at the kernel level, the Linux Auditing System is able to record:
- System calls, with other useful information such as Parent Process ID, Process ID, executable file and if the call was successful or not
- File access, with the kind of operation performed (read, write, execute, change in the file’s attribute)
Even if, in certain aspects, the auditing system is similar to standard Unix/Linux logging functionality, there are a few relevant differences. One of them is that the Linux Auditing System does not record from every application, but only from trusted ones.[1]
Why?
Audit provides you with the tools to track security-relevant information in the system. However, Audit does not provide additional security to your system. It would be very useful to investigate violations of security policies on your system, but it won’t prevent them. The biggest advantage of the Linux Auditing System is that it is versatile. You can monitor (almost) everything you would need with it. Also, Linux Auditing System is completely free, which is another relevant advantage.[2]
Scenario description
For the sake of this tutorial, we will assume that our network consists of three machines:
- Two of them are the data sources (server-one and server-two)
- The third one is our Centralized logging station (station)
I have created three different virtual machines using VirtualBox, and I have installed Ubuntu Live Server 20.04.2 on two of them. The three machines are on the same NAT Network.
Step 1: installing and setting up components
Auditd, which is the auditing userspace daemon, is not installed by default on Ubuntu and we have to install it. Also, we will need audispd-plugins to relay logging events to remote machines.
$ sudo apt install -y auditd audispd-plugins
Now, check if everything is up and running:
$ systemctl status auditd
And you should get a green message like this one:
...
Active: active (running)
...
Now, it’s time to set up the audisp remote logging plugin.
For every remote server (in this example we only have server-one and server-two), we have to tell the plugin where it should send all the events.
Type this command and put these two lines on top:
$ sudo nano /etc/audisp/audisp-remote.conf
remote_server = 10.0.2.6 #replace this with the IP of your central station
port = 60
Step 2: configuring logging station
Now it’s time to work on the logging station.
First thing, install auditd.
$ sudo apt install -y auditd
We won’t deal with firewalls in this example, but if you have one, don’t forget to allow incoming traffic for port 60 because otherwise, the packets coming from the remote servers will be rejected.
Open the audit config file and remove the “##” from the line containing tcp_listen_port:
$ sudo nano /etc/audit/auditd.conf
...
tcp_listen_port = 60
...
Now, restart the daemon.
$ sudo service auditd restart
Note: Auditd is highly customizable, so make sure to look at /etc/audit/auditd.conf. This file contains configuration information specific to the audit daemon. To know more, read the docs here: https://linux.die.net/man/8/auditd.conf
Step 3: Audit rules and watchers
Since we are just experimenting with this amazing tool, let’s do something really basic like monitoring access to a file containing sensitive information.
What if we want to create a file-watch rule for /etc/passwd?
$ sudo nano /etc/audit/rules.d/audit.rules
...
-w /etc/passwd -p wrxa -k identity
We can split this rule in three parts:
- -w /etc/passwd= watch for /etc/passwd
- -p wrxa = log usage of write,read, execute and attribute change permissions
- -k identity = assign the key identity to this rule
Now, enable the changes by restarting auditd:
$ sudo service auditd restart
Step 4: Start logging!
Now that everything has been set, let’s activate the remote logging plugins on our two remote servers (server-one and server-two).
$ sudo nano /etc/audisp/plugins.d/au-remote.conf
...
active = yes
...
As usual, enable the changes by restarting auditd:
$ sudo service auditd restart
If everything went well, when you try to read, write or change attributes of /etc/passwd on one of the remote servers, you will have an event on the central station. You can easily read the logging file like you would do with a normal file but, since we are talking about logs, it may be a huge and messy file. A comfortable solution to this problem is given by Ausearch, which is a utility for searching the audit logs for events.
For example, if we want to search for events coming from server-one with key identity, we would simply have to write:
$ ausearch --node server-one -k identity
Conclusion
Feel free to experiment with this tool like I did! It is easy to configure, easy to use and it opens up a world of new possibilities concerning audit systems.
Thanks ?
References
[1]: Grubb, S. (2011). Native host intrusion detection with RHEL6 and the audit subsystem, PDF document: https://people.redhat.com/sgrubb/audit/audit_ids_2011.pdf
Linux Auditing System: Centralized Logging to Remote Server was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
This content originally appeared on Level Up Coding - Medium and was authored by Andrea R.
Andrea R. | Sciencx (2021-08-31T17:26:31+00:00) Linux Auditing System: Centralized Logging to Remote Server. Retrieved from https://www.scien.cx/2021/08/31/linux-auditing-system-centralized-logging-to-remote-server/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.