Linux Event Collection Reference

Logster monitors Linux endpoints with two collectors that run on the endpoint itself, alongside each other:

auditd — the Linux Audit daemon, driven by the ruleset Logster ships. It provides broad, rule-driven coverage of security-relevant syscalls and watched paths.
The Logster eBPF sensor — a lightweight agent that observes process, file, and network activity directly in the kernel and writes it to three log files on the endpoint.

This page is a reference for what each one monitors. Together they give the detection model a complete view of process execution, file access, network activity, and privileged operations on the host.

Configuration files

Both collectors are driven by a configuration file, and both baselines are published so you can review coverage before deploying:

Collector	Configuration	On the endpoint
auditd	`audit.rules`	`/etc/audit/rules.d/logster.rules`
eBPF sensor	`filter.json`	`/etc/logster/ebpf-sensor/filter.json`

Both auditd and eBPF required config files are available in the logster-endpoint-configs repository, alongside the shipper configuration and the Windows baseline. The sensor release package ships both as well, so a standard deployment does not need to download anything.

The two are applied differently. filter.json is installed and active as soon as the sensor package is installed. The auditd ruleset is staged for you to review and apply as a deliberate step, because audit rules are site policy and may overlap with a baseline you already run.

Configure auditd

Install the Logster ruleset as a drop-in under /etc/audit/rules.d/. augenrules compiles everything in that directory into the active ruleset, so the Logster rules coexist with any baseline you already run.

Apply the copy staged on the endpoint by the sensor package:

sudo cp /usr/share/logster-ebpf-sensor/audit.rules /etc/audit/rules.d/logster.rules
sudo augenrules --load

Or pull the current baseline straight from the repository:

sudo curl -fsSL -o /etc/audit/rules.d/logster.rules \
  https://raw.githubusercontent.com/eunomatix/logster-endpoint-configs/main/linux/auditd/audit.rules
sudo augenrules --load

Verify the rules loaded — the count should be in the hundreds, and the status line reports the backlog and any lost events:

sudo auditctl -l | wc -l
sudo auditctl -s

Generate a known-good event and confirm it was recorded:

whoami                          # matches the 'recon' rule
sudo ausearch -k recon -ts recent

Debian and Ubuntu only

rsyslog runs as user syslog there and cannot read /var/log/audit/audit.log with the default permissions, so no auditd events reach Logster. Set log_group = syslog in /etc/audit/auditd.conf, then restart the daemon:

sudo systemctl restart auditd

Configure the eBPF sensor

The sensor reads /etc/logster/ebpf-sensor/filter.json at startup. The release package installs the baseline there already, so this step is only needed to pull an updated baseline or to apply your own tuning.

sudo curl -fsSL -o /etc/logster/ebpf-sensor/filter.json \
  https://raw.githubusercontent.com/eunomatix/logster-endpoint-configs/main/linux/ebpf-sensor/filter.json
sudo systemctl restart logster-ebpf-sensor

The sensor re-reads the file only on start, so every change needs a restart. If it was not enabled yet:

sudo systemctl enable --now logster-ebpf-sensor

Verify the service is running and events are being written:

systemctl status logster-ebpf-sensor
sudo tail -f /var/log/ebpf_security/process_monitoring.log

Running any command in a second shell produces an [EXEC] line. To confirm the security tagging works end to end, trigger a flagged event — this writes an [EXEC!] line, because /tmp is a staging directory:

cp /bin/true /tmp/logster-test && /tmp/logster-test && rm /tmp/logster-test

If the service fails to start, the preflight check reports why (kernel version, BTF availability, lockdown mode, rsyslog omkafka):

sudo logster-sensor-preflight
journalctl -u logster-ebpf-sensor -n 50

Tuning

Both files are safe to tune for your fleet: add a watched path, exclude a noisy in-house process, widen or narrow coverage. Keep local changes in your own configuration management so they survive package upgrades. filter.json is marked as an operator-editable config file and is never overwritten on upgrade. Re-run the matching command above to apply a change — augenrules --load for auditd, a service restart for the sensor.

What auditd monitors

Logster ships an auditd ruleset based on Florian Roth's widely-used Linux Audit Daemon — Best Practice Configuration, with Logster-specific tuning applied on top. It contains 328 active rules:

219 path watches — in two shapes: write/attribute change on configuration files, and execution of a binary.
84 syscall rules — matching on syscall, architecture, and outcome.
18 suppression rules and 3 exclusions — noise control.

By intent, the biggest clusters (shown with the rule keys they are tagged with, which appear in the audit records themselves):

Area	Keys / coverage
Recon & attacker tooling exec	`susp_activity` (36: wget, curl, nc, ncat, socat, nmap, ss, netstat, ssh/scp/sftp, tcpdump, tshark, rdesktop/xfreerdp, tftp), `recon` (whoami, id, hostname, uname), `sbin_susp` (iptables/nft/ifconfig/tcpdump/traceroute/ufw)
Shells / interpreters	`susp_shell` (21: ash, csh, fish, tcsh, tclsh, xonsh, rbash, wish, yash, tmux, clush), `shell_profiles` (/etc/profile, bashrc, csh., zsh/)
Credentials & accounts	`etcpasswd`, `etcgroup`, `opasswd`, `passwd_modification`, `user_modification`, `group_modification`, `login`, `session` (wtmp/btmp/lastlog), `rootkey` (/root/.ssh), `sshd`
Privilege escalation	`priv_esc` (su, sudo), `pkexec`, `actions` (sudoers), `rootcmd` (`execve` with euid=0 & auid>=1000)
Persistence	`cron` (9), `systemd` + `systemd_generator` (9), `init`, `libpath`, `systemwide_preloads` (ld.so.preload), `pam`
Kernel / evasion	`modules` (init_module/finit_module/delete_module + insmod/modprobe/rmmod), `KEXEC`, `mac_policy` (selinux), `auditlog`/`auditconfig`/`audittools`
Injection	`code_injection`/`data_injection`/`register_injection`/`tracing` (`ptrace` with a0=0x4/0x5/0x6/0x10)
Fileless	`anon_file_create` (`memfd_create`)
Reverse shell	`remote_shell` (successful `connect` from /bin/bash or /usr/bin/bash)
Failed access	`file_access`, `file_creation`, `file_modification` (EACCES/EPERM on open/creat/mkdir/link/rename/chmod/setxattr…)
System state	`mount`, `swap`, `time`, `network_modifications`, `sysctl`, `specialfiles` (mknod), `perm_mod` (xattrs)
Software/infra inventory	`software_mgmt`, `third_party_software_mgmt` (pip/npm/gem/cpan), `docker`, `kubelet`, qemu/virtualbox, `falcon_*`, `filebeat`, chef/salt/puppet
Misc	`32bit_abi` (execve/socket/connect on b32), `detect_execve_www` (execve as euid 33)

The ruleset also carries deliberate suppressions to keep known false-positive sources out of the pipeline. Worth knowing, because they explain events you may expect to see but won't:

openat returning EACCES for find, getcap, and ps — a permission-denied flood from routine filesystem scans.
execve as root by a logged-in user for date, awk, mawk, gawk, and nawk.
The crond_t subject, vmtoolsd, /dev/shm, and /var/lock/lvm.
The CWD, PATH, and CRYPTO_KEY_USER record types.

What the eBPF sensor monitors

The sensor attaches to 14 kernel tracepoints covering process execution, file access, file destruction, and network activity. That fixed set defines everything the sensor is able to see. Surviving events are written as text lines to three log files under /var/log/ebpf_security/.

Tracepoint(s)	Emits
`sys_enter_execve`, `sys_enter_execveat`	`[EXEC]` / `[EXEC!]` → process_monitoring.log
`sys_enter_openat`, `sys_enter_openat2`	`[FILE]` / `[FILE!]` → file_monitoring.log
`sys_enter_unlink/unlinkat/rename/renameat/renameat2/truncate`	`[FILE!]` with `flags=UNLINK`, `RENAME`, or `TRUNCATE` → file_monitoring.log
`sys_enter_connect`	`[CONNECT]` / `[CONNECT!]` → network_monitoring.log
`sys_enter_bind`	`[BIND]` / `[BIND!]` → network_monitoring.log
`sys_enter_accept4` + `sys_exit_accept4`	`[ACCEPT]` → network_monitoring.log
`sys_enter_socket`	`[SOCKET]` → network_monitoring.log

A trailing ! on the tag — [EXEC!], [FILE!], [CONNECT!], [BIND!] — marks an event the sensor flagged as security-relevant: an execution from a staging directory, access to a credential or persistence path, a listener or connection on a known attacker port. Flagged events are prioritized downstream.

Note

The sensor filters events on the endpoint, in the kernel, before anything is written to disk. This keeps volume low on busy hosts: routine library loads, loopback traffic, and repeated identical operations never leave the kernel. Which events survive is governed by filter.json — contact Logster Support if your environment needs coverage beyond the shipped baseline.