Linux auditd can record privilege changes, authentication events, process execution, file access, and policy changes. The records are valuable only if an attacker cannot edit the same local log and the operations team can retrieve it after a host is isolated. Remote forwarding is a practical first step, but it is not a complete chain of custody.
Red Hat's audit documentation describes audit events and daemon behavior, while the remote-logging guidance covers sending auditd records to another server. The architectural decision is where to place that server, how to authenticate the sender, and how long to retain the evidence.
Separate collection from custody
The audited host should not be the only place where its evidence lives. An attacker with root access can stop the audit daemon, modify local policy, or remove a log file unless the platform provides additional protections. Forward records to a destination that has independent access control and a different failure domain. Restrict who can alter the receiver's configuration and stored files.
Encrypt transport and authenticate the source. A plaintext UDP path can be lost, forged, or replayed without leaving an obvious mark. Use a mutually authenticated transport supported by the audit forwarding stack, or send through a well-managed log pipeline that adds a source identity. Preserve the original event fields. Parsing them into a normalized store is useful, but the raw record should remain available for investigation.
Keep host clocks synchronized and record the time source. An event with a correct local timestamp is still hard to place if the host clock was wrong. Use authenticated network time for critical systems where possible, and monitor the offset. When receiving events from many hosts, retain both the event time and the receiver's ingestion time.
Plan for policy changes
Audit rules should be managed as configuration and change controlled. Include rules for changes to audit policy, log forwarding, authentication, privilege escalation, and critical data paths. Alert on attempts to stop or reconfigure the audit daemon, and make those alerts fan out to the central receiver.
Test retention and recovery. Define how long records must remain available, how access is audited, and whether the receiver can restore data after corruption. A remote collector with a seven-day retention period may be useful for detection but insufficient for an incident that is discovered after three weeks. Different retention tiers can preserve the raw record longer than the searchable index.
Review the source of time and identity for each event. A local username is not necessarily a human identity, and a process ID can be reused. Correlate audit events with session records, SSH logs, container metadata, and cloud control-plane logs where applicable. The central record is stronger when it can connect what happened on the host to who initiated the session.
The goal is not to make tampering impossible on every host. The goal is to make tampering visible and to keep a copy outside the host's control. That requires transport security, independent receivers, retention, and a tested response path.