Skip to content

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.

Neither collector runs inside the Logster appliance. Both are installed on every Linux machine you want monitored.

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 and diff a tuned endpoint against the shipped defaults:

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 live in the logster-endpoint-configs repository alongside the shipper configuration and the Windows baseline. The sensor release package ships both, so a standard deployment does not need to download anything — the repository is for review, for tuning, and for pulling an updated baseline onto an existing endpoint.

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 — the endpoint installation guide covers that step.

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.

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.