Linux is an attractive solution for enterprises in search of a flexible, powerful operating system. Many different operating systems use the Linux kernel, such as Ubuntu, Debian, and Red Hat Enterprise Linux (RHEL), which itself is an enterprise-ready extension of CentOS.
Open-source Linux distributions have a slightly different security profile than proprietary technologies like Windows. Some enterprise IT leaders choose Linux specifically for its security capabilities and low implementation costs. However, making the most of those security capabilities requires utilizing sophisticated information security technologies like SIEM, UEBA, and SOAR.
Most Linux distributions automatically collect log data on user, application, and kernel activities. Logins, file modifications, and account modifications are stored in a chronological timeline so that security analysts can review them and investigate suspicious activities when necessary.
SIEM, UEBA, and SOAR technologies rely on these logs to categorize and prioritize suspicious activities and automate some of the most time-consuming tasks security analysts must perform. The better and more comprehensive those logs are, the more accurate these technologies’ insights can be.
One of the best ways to access log data in Linux is through the Linux Audit System, better known through its command line name Auditd. It provides comprehensive visibility into system calls, file access, and pre-configured auditable events throughout the Linux environment.
Configuring Linux’s log collection policies will let you send better, more accurate data to your SIEM, UEBA, or SOAR platform. This significantly boosts the quality of its security performance output in turn.
The example we have written is for RHEL but works the same way in Ubuntu. Most Linux-based operating systems will provide for a similar process.
The goal of this configuration is to push comprehensive system logs onto the syslog directory and move them from there to a remote log management solution. This configuration does not remove any existing rules, so you can use it as a starting point for changing the default configuration. However, if you already have a robust, custom configuration, some of these rules may overwrite yours.
This is the directory you’ll be placing the configuration in...
In our example, we’re using syslog to access the logs our policies generate. You may use syslogd or syslog-ng for the same purpose – our team would be happy to provide you with the appropriate configurations.
Instead of using a simple *.* in the master rsyslog.conf file, we prefer creating a custom file in /etc/rsyslog.d. Consider creating a file called auditd.conf and populating it like this:
if $programname contains 'audisp' then
@@SIEM_COLLECTION_IP:514 & stop
Notice that we’re using @@ to send data via TCP and specifying TCP 514 as the port. The default port for syslog is usually 601, but most systems still use UDP and TCP 514 for logs. Feel free to edit this code to fit the needs of your environment and restart rsyslog when you’re ready to effectuate the changes.
That’s it! Now, almost every SIEM, UEBA, and SOAR system on the market can natively parse the logs generated by your Linux distribution. You may now review and analyze accurate log data describing unwanted access, changes, and installations on your Linux systems.
