Audit security-relevant activity

Synopsis #

FreeBSD security event auditing records selected kernel and application events in Basic Security Module (BSM) trails. It can preserve an authenticated audit user ID across a later privilege transition, making it more suitable than ordinary service logs for questions such as which login identity performed an administrative action.

Auditing is not complete surveillance. Some events are not instrumented, some third-party login paths do not establish audit session state, and a broad selection can generate large trails containing sensitive command arguments and paths. Define the question, event classes, retention, review owner, storage failure behavior, and recovery path before enabling auditd(8). Use a bounded DTrace investigation for transient diagnostic observation rather than treating it as a durable audit trail.

Understand the audit path #

The principal components are:

GENERIC includes kernel audit support on the releases covered here. A custom kernel must retain options AUDIT. Removing it from a custom configuration changes an evidence boundary and should be treated as a security design decision, not a kernel-size optimization.

Define the evidence question #

Begin with a question that has an owner and a review action. Examples include:

• which authenticated identities successfully or unsuccessfully logged in;
• which original login identity executed selected administrative operations;
• whether a protected path was accessed or modified;
• whether an expected application audit event occurred;
• what activity preceded a specific incident time.

Map the question to the smallest relevant event classes in /etc/security/audit_class and /etc/security/audit_event. Selection expressions can distinguish successful and failed events. For example, lo,+ex means both successful and failed login/logout events and successful execution events. It is a syntax illustration, not a universal selection policy.

Avoid selecting all merely to preserve optional future evidence. On a busy host, detailed auditing can generate gigabytes of data and add substantial review noise. A trail that cannot be retained or reviewed does not provide a dependable control.

Know what attribution can and cannot prove #

An attributable record can contain the audit user ID established when the session authenticated, in addition to real and effective user and group IDs. The audit user ID can therefore remain associated with the original login identity after su or another approved privilege transition.

That attribution has limits:

• activity before authentication is non-attributable and follows naflags selection;
• not every system call has complete audit instrumentation;
• some Xorg display managers and third-party daemons do not establish audit login session state correctly;
• a shared account or shared credential still identifies the shared identity, not the individual operator;
• MAC policy labels are not recorded as part of audit records involving MAC decisions;
• audit system calls are not available to jailed processes, although processes carrying host audit session state can still generate records with jail identification.

Validate every real login and privilege path in the intended environment. An SSH test does not establish that a display manager, application gateway, or third-party authentication daemon provides equivalent attribution.

Design storage and failure behavior #

Audit trails default to /var/audit. High-volume auditing should use a dedicated filesystem or dataset so trail growth cannot consume space required by unrelated services. Multiple dir entries in audit_control can provide ordered trail destinations.

The storage controls have different purposes:

FreeBSD documents three materially different storage-exhaustion outcomes:

• cnt permits the system to continue while audit events can be lost;
• neither cnt nor ahlt suspends processes when audit storage is exhausted, a state the current implementation documents as unrecoverable;
• ahlt drains pending records and halts the system.

The audit_control(5) recommendation is cnt without ahlt unless deliberate halt-on-full behavior is required and operationally tested. Select that availability and evidence boundary explicitly for the host’s role. A halt-oriented policy without tested console access, spare storage, and an incident procedure can turn an audit storage fault into an avoidable outage.

Monitor free space independently of audit_warn. Test that warnings reach a staffed destination before relying on them, and account for a failed notification channel in the recovery plan.

Protect privacy and trail integrity #

Audit records reveal identities, paths, network endpoints, process relationships, and possibly command arguments. The argv policy flag records arguments passed to execve(2); commands that place passwords, tokens, or personal data in arguments can therefore place those values in the trail.

Treat the trail as sensitive security data:

• restrict read access to named reviewers;
• keep the audit group empty unless review is deliberately delegated;
• encrypt and authenticate off-host archives according to the backup design;
• document retention and deletion requirements;
• avoid copying unrestricted trail text into tickets or general-purpose log systems;
• record clock synchronization and time-zone assumptions used during incident review.

The host administrator can affect both audit configuration and local trails. Requirements for evidence against host compromise need prompt off-host transfer, restricted destination credentials, and independent integrity controls. Local BSM trails alone cannot provide that property.

Qualify a minimal policy #

Inspect the existing state before editing configuration:

$ sysrc auditd_enable
# service auditd status
# sed -n '1,160p' /etc/security/audit_control
# sed -n '1,160p' /etc/security/audit_user
# df -h /var/audit

Review the current definitions rather than assuming class names from another operating system or an older example:

$ less /etc/security/audit_class
$ less /etc/security/audit_event

On a representative non-production system, configure the smallest selection that answers the evidence question, a bounded filesz and retention rule, a meaningful minfree threshold, and the chosen failure policy. Then enable and start the base-system daemon through the normal rc mechanism:

# sysrc auditd_enable=YES
# service auditd start

Generate one controlled successful event and one controlled failure for each selected class. Confirm that the correct audit user ID, outcome, time, object, and jail identity where applicable appear in the trail. Also exercise an approved privilege transition and every supported login path.

Do not proceed merely because trail files exist. Qualification requires the desired events to appear and excluded high-volume events to remain outside the trail.

Reduce and review trails deliberately #

BSM trail files are binary. Work on a closed trail when developing review filters. List the directory, identify a completed file, and preserve its exact name:

# ls -lt /var/audit
# praudit /var/audit/AUDITFILE

For a focused review, reduce before formatting. This example selects records associated with one audit user from one closed trail:

# auditreduce -u account /var/audit/AUDITFILE | praudit

auditreduce(1) also supports time, event, class, and object filters. Save the exact reduction expression with incident notes so the review can be reproduced. Retain the original BSM file; formatted text is a view, not a substitute for the source trail.

Live review through auditpipe(4) can create a feedback loop when the review session itself generates selected events. Begin with closed trails. Introduce live monitoring only after the event volume and the review transport have been tested.

Rotate through auditd #

Do not rotate active audit trails with newsyslog or by renaming them directly. Ask auditd to close the active trail and switch to a new one:

# audit -n

Use filesz for size-based rotation or a documented scheduled audit -n operation for time-based boundaries. Compress, archive, or transfer only trails that auditd closed cleanly. An abrupt shutdown can leave an unterminated trail that does not receive ordinary close-file handling.

Test expiry and archival together. Local expiry must not remove the only required copy, and archive failure must not silently allow the local filesystem to fill.

Preserve a recovery boundary #

Before production enablement, document how to respond to:

• a full or unavailable audit filesystem;
• repeated rotation or warning-script failures;
• a malformed selection that floods the trail;
• a missing event that invalidates an investigation assumption;
• a daemon that does not establish audit session state;
• an unterminated trail after a crash;
• an archive destination that cannot accept new trails.

Retain console access for policies that may halt or materially constrain the host after audit failure. Restore availability by following the chosen failure policy and preserving the affected evidence, not by deleting active trail files blindly.

Review the design after every new authentication path, major service change, or FreeBSD release upgrade. Link the review owner and audit storage checks into the security baseline .

Primary references #

• FreeBSD Handbook: Security Event Auditing
• audit(4)
• auditd(8)
• audit(8)
• audit_control(5)
• audit_user(5)
• audit_warn(5)
• auditreduce(1)
• praudit(1)
• auditpipe(4)