Linux Server - Integration Guide

This guide will show you how to integrate a Linux server into the Secure60 platform.

Overview

This guide will explain how to monitor Linux instances through configuration of Syslog. As always if you have any additional questions, don’t hesitate to contact Secure60 Support.

Install Syslog

  1. (Prerequisite) Install the Secure60 Collector
  2. (Optional) Install rsyslog on Linux Most Linux instances come preconfigured with syslog installed. Adding TLS Support normally requires an additional package. If needed manually install:
#Check if already exists:
systemctl status rsyslog

#Ubuntu
sudo apt install rsyslog
#RHEL / Rocky
sudo dnf install rsyslog

Then if needed add TLS Support

#RHEL / Rocky:
sudo dnf install rsyslog-gnutls
  1. Create a new file at nano /etc/rsyslog.d/10-tls-forward.conf with the following content:

# without ssl, default syslog port using UDP
*.* @<S60_COLLECTOR_IP_ADDRESS>:514 

# TLS settings for self-signed certs
$DefaultNetstreamDriver gtls
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode anon

# Forward all logs via TLS
*.* @@S60_COLLECTOR_IP_ADDRESS:6514

Ensure you replace <S60_COLLECTOR_IP_ADDRESS> with the actual IP address of your Secure60 collector. Also enable TLS validation with signed certificates as needed.

Capture systemd journal messages

We recommend also capturing systemd journal messages so that auditd/audisp output and other journal-based logs are forwarded to Secure60. This requires loading the imjournal module in rsyslog. If you already have a TLS forward block above, you can add just the module(load="imjournal"...) block to the same file and ensure *.* is forwarded; otherwise use the following complete example.

Update /etc/rsyslog.d/10-tls-forward.conf to contain the below (or a separate file in /etc/rsyslog.d/). Replace the example IP and port with your Secure60 collector address and port.

##################################################
# Secure60 journal input (needed for auditd/audisp)
##################################################
module(
  load="imjournal"
)

##################################################
# TLS settings for self-signed certs
##################################################
$DefaultNetstreamDriver gtls
$ActionSendStreamDriverMode 1
$ActionSendStreamDriverAuthMode anon

##################################################
# Forward all logs via TLS to Secure60 collector
##################################################
*.* @@S60_COLLECTOR_IP_ADDRESS:6514

To restart the Syslog service, execute the following commands:

systemctl restart rsyslog

To check the status of Syslog, use the command:

systemctl status rsyslog
journalctl -u rsyslog

Enabling process execution auditing on Linux

To enable visibility into process execution on Linux systems, Secure60 uses the native auditd framework to record all execve() system calls. This captures when new processes are started, along with the executable path, user context, and command-line arguments.

Some OS versions dont includes auditd by default. Install and make sure sending to syslog enabled:

sudo apt install -y auditd audispd-plugins
sudo nano /etc/audit/plugins.d/syslog.conf
#Change active = no to active = yes
sudo systemctl restart auditd

On Rocky Linux, Ubuntu, and other modern Linux distributions, create or update an audit rules file (for example /etc/audit/rules.d/50-secure60.rules) with the following entries:

## Secure60 - baseline audit rules
## Place at: /etc/audit/rules.d/50-secure60.rules

############################
# 1) Process execution
############################
-a always,exit -F arch=b64 -S execve -k s60_exec
-a always,exit -F arch=b32 -S execve -k s60_exec

############################
# 2) Identity & group management (FIM via audit watches)
#    Captures useradd/usermod/groupadd/passwd changes indirectly by file writes.
############################
-w /etc/passwd  -p wa -k s60_identity
-w /etc/shadow  -p wa -k s60_identity
-w /etc/group   -p wa -k s60_identity
-w /etc/gshadow -p wa -k s60_identity

############################
# 3) Privilege configuration changes
############################
-w /etc/sudoers     -p wa -k s60_privcfg
-w /etc/sudoers.d/  -p wa -k s60_privcfg

############################
# 4) SSH / auth control changes (high signal)
############################
-w /etc/ssh/sshd_config -p wa -k s60_authcfg
-w /etc/pam.d/          -p wa -k s60_authcfg

############################
# 5) Persistence mechanisms
# 5a) Cron
############################
-w /etc/crontab   -p wa -k s60_persist
-w /etc/cron.d/   -p wa -k s60_persist
-w /etc/cron.hourly/ -p wa -k s60_persist
-w /etc/cron.daily/  -p wa -k s60_persist
-w /etc/cron.weekly/ -p wa -k s60_persist
-w /etc/cron.monthly/ -p wa -k s60_persist
-w /var/spool/cron/ -p wa -k s60_persist

############################
# 5b) systemd units (service persistence)
# System-wide unit files
############################
-w /etc/systemd/system/      -p wa -k s60_persist
-w /usr/lib/systemd/system/  -p wa -k s60_persist
-w /lib/systemd/system/      -p wa -k s60_persist

# User-level unit files (user persistence) - add per admin/service user as needed

############################
# 6) Shell/profile persistence (common attacker trick)
############################
-w /etc/profile  -p wa -k s60_persist
-w /etc/bashrc   -p wa -k s60_persist
-w /etc/profile.d/ -p wa -k s60_persist

These rules instruct the kernel to audit all process execution events for both 64-bit and 32-bit binaries. Once applied, auditd will emit correlated audit records for each execution event, which are collected and forwarded to Secure60 via the system logging pipeline.

After adding the rules, reload the audit configuration or restart the auditd service to activate the changes:

Process to reload all config files and test they are working (Expect the last line to tell you if file errors - You then need to check the source files because they are all compbined into the one file that is referenced in the output if errors):

sudo augenrules --load

Optional: reducing audit noise

In environments with high process churn (containers, automation, system services), additional audit records such as PATH, CWD, or end-of-event markers can significantly increase log volume without adding meaningful detection value.

To reduce audit noise while still retaining full process execution visibility, these auxiliary record types can be excluded safely. Add the following to the same audit rules file (for example after the execve rules):

# Exclude less useful metadata records to reduce volume
-a always,exclude -F msgtype=PATH
-a always,exclude -F msgtype=CWD
-a always,exclude -F msgtype=EOE

These exclusions do not affect the core execution telemetry. The following records are still generated and collected:

After adding or changing rules, reload the audit configuration or restart the auditd service as above.

Back to top