Linux Log Collection Reference

Background material for endpoints already installed with Connect Linux Endpoints: the configuration files both collectors are driven by, how to tune them, what happens to events while Logster is unreachable, and exactly what each collector monitors.

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/40-logster.rules
eBPF sensor	filter.json	/etc/logster/ebpf-sensor/filter.json

Both 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.

Both are active as soon as the package is installed. filter.json is laid down as-is; the auditd ruleset is installed as a merge-safe drop-in — the -D/-f directives are stripped so rules you already run survive (see Step 3). Audit rules can overlap with a baseline you already maintain, which is why the applied file and its unmodified source are both kept on the endpoint for review.

Buffering during an outage

The rendered shipper config gives every Kafka output its own disk-assisted queue under /var/spool/logster (up to 1 GiB per topic, preserved across an rsyslog restart). When Logster is down or unreachable, events spool to disk instead of stalling the log readers, and drain once the broker comes back; the shipper retries indefinitely rather than discarding.

The readers poll their log files once a second rather than relying on inotify, so a file replaced by rotation — auditd's own rotation included — is picked up on the next interval instead of being missed.

If an outage lasts long enough to fill the queues, the oldest events are the ones lost. du -sh /var/spool/logster shows the current backlog.

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.

To apply an updated filter.json — the sensor reads it only at startup, so every change needs a restart:

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-sensor

For auditd, re-run sudo augenrules --load.

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.