Neo23x0/auditd Linux Audit Rules and Deployment Checks

Why Neo23x0/auditd Collects Telemetry Instead of Detections

Neo23x0/auditd addresses a specific gap between Linux audit configuration and downstream security analytics. Its `audit.rules` file collects host activity that commonly matters during investigations, while leaving interpretation to Sigma rules, SIEM content, or host-side analytics. The intended users are Linux security engineers, detection authors, and administrators who want a readable audit baseline rather than a collection of hard-coded alerts tied to one SIEM.

The rules cover configuration integrity, authentication and privilege changes, network and firewall settings, startup paths, SSH, systemd, PAM, account databases, scheduled tasks, file access failures, and special kernel primitives. It also collects high-volume events such as `execve`, `execveat`, socket creation, file deletion, and 32-bit ABI use. This breadth is useful for investigations because the same event stream can support several detection goals.

There is a deliberate trade-off in the volume. The README says process creation, socket creation, and file access failure telemetry are retained even when they can be expensive. That makes the baseline less minimal than a narrowly selected incident-detection profile. Operators should expect to measure storage use and query latency after installation. The repository does not provide benchmark results or deployment-specific volume estimates, so it would be misleading to claim a particular performance level.

The project also makes a clear separation of responsibilities. Neo23x0/auditd does not decide whether an event is malicious. A downstream tool must interpret audit records, combine them with other context, and determine an alert or response. That design can fit organizations with existing Sigma, SIEM, or analytics infrastructure, but it means the repository alone is not a complete monitoring solution.

How the audit.rules Baseline Is Structured

The configuration operates through Linux audit rules that ask the kernel audit subsystem to emit records for specific syscall, file, permission, or configuration activity. Based on the repository layout, the principal deployment artifact is `audit.rules`, while `scripts/` contains supporting automation and `.github/` contains repository checks. The README describes sectioning and comments as the main adaptation mechanism rather than a separate detection engine.

Most rules focus on collecting attributable records. Several interactive-user rules use `auid>=1000 -F auid!=unset`, which keeps the login identifier attached while excluding unset sessions. This threshold is an operational assumption, not a Linux-wide constant. A host with a different first ordinary user ID must change `1000` in `audit.rules` after reading its configured `UID_MIN`.

One focused block collects lower-noise parts of the Copy Fail setup around `AF_ALG`. It records `socket(AF_ALG,...)`, `bind()` with the common fixed-size `struct sockaddr_alg`, and `setsockopt(..., SOL_ALG,...)`. The README states that syscall filters cannot match string arguments such as the algorithm name. Detection therefore requires inspecting the `SOCKADDR` record and correlating repeated binds by process, executable, or login user. This split between collection and detection defines the project's architecture.

The repository also includes rules for kernel, module, mount, swap, time, scheduled-task, account-database, PAM, sudo, login, firewall, startup, service, boot-path, library-path, shell-profile, SSH, systemd, and MAC policy changes. Coverage is intentionally broad. That makes the file useful as a starting point, but it also increases the need to review exclusions for paths that do not exist on a particular distribution.

Checking UID_MIN and AF_ALG Readiness Before Adoption

The UID check is a mandatory adaptation point for hosts that do not use `1000` as their first ordinary login ID. The README provides this command:

awk '$1=="UID_MIN" { print $2 }' /etc/login.defs

It prints the configured `UID_MIN`. Compare that value with `1000` in `audit.rules`, then replace the threshold where needed before deployment. Failing to do so can either omit activity from lower-numbered interactive accounts or include records outside the intended range. The README does not provide a packaged template for every distribution's `UID_MIN`.

For Copy Fail telemetry, the repository intentionally does not enable all relevant syscalls by default. The proof of concept relies on repeated `splice()` operations, but the README describes those calls as too noisy on many systems. A commented-out `splice_user` overlay is supplied in `audit.rules`. Enabling it is reasonable only when `splice` or `vmsplice` is uncommon and the resulting records can be correlated with recent `af_alg` activity from the same process or user session.

The downstream checks are similarly specific. Start with records whose key is `af_alg`, inspect `SOCKADDR.saddr` or `SADDR={ saddr_fam=alg ... }`, identify `salg_type=aead`, and examine `salg_name` for `authencesn(`. The README also recommends increasing severity when one `pid`, `exe`, or `auid` produces many such binds in a short window. The rules collect evidence for that logic, but they do not implement the full detection.

This example illustrates the intended division of work. Neo23x0/auditd supplies event collection. A downstream rule or analyst supplies string inspection, correlation, severity, and response. Anyone expecting the rules file to raise a complete alert by itself will find the project incomplete for that purpose.

Portable Loading Versus Strict Rule Validation

The configuration normally includes `-i`, which tells audit rule loading to ignore errors for optional or distribution-specific paths. This supports the project's goal of loading out of the box across major Linux distributions. It also creates the repository's most important limitation: a successful portable load does not prove that every rule was accepted.

That distinction matters when a binary or directory is missing. The permissive setting allows the remaining rules to load rather than terminating validation at the first absent item. For a development workstation or a controlled staging host, that can be convenient. For a production baseline, it can conceal incomplete coverage or host-specific syntax problems.

The strict-copy procedure is the safer check when deployment readiness matters more than one-command portability:

grep -v '^-i$' audit.rules > /tmp/audit.rules.strict
auditctl -R /tmp/audit.rules.strict

The first command removes the permissive loading line from a temporary copy. The second asks `auditctl` to load that strict copy. The README presents this as a pre-deployment validation technique, not as a permanent replacement for `audit.rules`.

The repository also reports GitHub Actions checks that lint the rules and validate both a portable copy and a strict copy on Ubuntu. Those checks support maintainability of the repository's CI path, but Ubuntu validation alone does not establish compatibility with every supported distribution. The README describes the rules as designed for major distributions, not certified for all of them.

A second limitation is that compliance profiles are not bundled wholesale. The README points readers to separate Linux audit rules for PCI DSS and NISPOM. This keeps Neo23x0/auditd from claiming complete framework coverage, but it also means a team with a formal control mapping must compare this baseline with its applicable rules.

Maintenance, Licensing, and the Aurora Linux Alternative

The repository is not archived, and the last push was on 2026-05-04. Releases `v0.1.0` and `v0.2.0` were both published on 2026-04-21. This supports a current maintenance judgement without claiming a release cadence beyond the listed history. Upgrade work appears configuration-oriented: operators must compare changed rules, reassess event volume, and repeat strict validation after copying a new `audit.rules`.

The project uses the Apache-2.0 license. That identifier describes the repository's stated licensing model, but this review does not provide legal advice about how a particular deployment or distribution of the rules must handle notices, modifications, or dependencies.

For downstream analysis, the README names Aurora Linux as an alternative path rather than a replacement for the rules. Neo23x0/auditd provides audit subsystem rules and deliberately does not choose a detection runtime. Aurora Linux is described as a lightweight, customizable Sigma-based agent that combines eBPF telemetry, user-space enrichment, and Sigma rule matching. The practical difference is collection architecture: this repository centers on audit rules, while Aurora Linux centers on agent-side enrichment and rule execution. An organization already standardized on auditd can keep the baseline; an organization seeking an integrated Sigma agent must evaluate the additional agent component.

The maintenance burden is therefore not limited to checking whether the Git repository changed. Administrators must also review changed exclusions, confirm `UID_MIN`, test strict loading, and decide whether high-volume events fit their storage capacity. Those costs are concrete configuration tasks tied to this repository, not general advice about security monitoring.

What Neo23x0/auditd Does Not Replace

The project is not a drop-in replacement for a complete Linux security platform. It does not provide Sigma rules, SIEM connectors, alert routing, case management, or response automation. Those responsibilities are intentionally left downstream according to the README. The file is a telemetry baseline that can feed several analysis systems, but it does not make those systems interchangeable.

It is also not a complete PCI DSS or NISPOM rules package. The README directs readers to separate rulesets maintained by the Linux audit project for those profiles. A compliance-oriented deployment still needs a control mapping and an assessment of which rules are required. Copying this repository without performing that comparison would not establish compliance.

The `-i` behavior creates another boundary for evaluation. Portable loading can hide missing-path errors, so administrators should not use a clean `auditctl` load as their only validation step. The strict-copy procedure is the repository's documented check, and the GitHub Actions workflow provides an Ubuntu validation path. Neither fact proves performance or coverage on every Linux host.

For teams that need lightweight, readable audit collection and already have downstream analytics, the repository is a reasonable baseline candidate. For teams that want one component to collect telemetry, run detections, enrich events, and manage alerts, the project will appear incomplete unless paired with another tool. That boundary is visible in the project design, not an omission hidden by the documentation.

Editorial conclusion

Adopt this repository as a starting ruleset when you want broad, inspectable Linux audit telemetry and plan to tune it for the host. Do not treat it as a complete detection product or assume its `-i` behavior proves every rule loads correctly. Verify `/etc/login.defs`, load `/tmp/audit.rules.strict` with `auditctl -R`, and assess event volume before deploying `audit.rules`.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. Neo23x0/auditd on GitHub
4. README
5. Releases