How to Send Linux Audit Logs to a Remote Rsyslog Server

Updated: 28 September 2026 · Applies to: audit 3.1 and 4.0 with rsyslog 8.2x on AlmaLinux and Rocky Linux 9 and 10, RHEL 9 and 10, Ubuntu 24.04 and 26.04, Debian 13

The Linux audit system writes its events to /var/log/audit/audit.log on each server. If an attacker gets root, they can edit that file. Sending a copy of every audit event to a central log server keeps the record out of their reach. Older guides read audit.log with rsyslog's file input; the cleaner way today is the audit system's own syslog plugin. We tested the plugin with audit 4.0 on AlmaLinux 10 and checked the rsyslog configuration with rsyslogd -N1.

On the log server

Set up a central rsyslog server that accepts TCP connections, as described in Rsyslog: how to send logs to a remote log server. With that configuration, the audit events from each server land in /var/log/remote/HOSTNAME/audispd.log.

On each server that sends audit events

1. Install the plugin. On AlmaLinux, Rocky Linux and RHEL it is in a separate package; on Ubuntu and Debian it comes with auditd:

   dnf install audispd-plugins    # AlmaLinux, Rocky Linux, RHEL
   apt install auditd             # Ubuntu, Debian

2. Edit /etc/audit/plugins.d/syslog.conf. Turn it on and send the events to the syslog facility local6:

   active = yes
   direction = out
   path = /sbin/audisp-syslog
   type = always
   args = LOG_INFO LOG_LOCAL6
   format = string

3. Give each event the server's name, so you can tell the servers apart on the log server. In /etc/audit/auditd.conf set:

   name_format = HOSTNAME

   (log_format = ENRICHED, the default, already adds user and group names to the events.)
4. Forward only the audit messages to the log server. Create /etc/rsyslog.d/10-audit-forward.conf with your log server's address (the low number makes it run before Ubuntu's 50-default.conf):

   local6.* action(type="omfwd" target="203.0.113.50" port="514" protocol="tcp"
              queue.type="LinkedList" queue.filename="fwd_audit" queue.maxDiskSpace="1g"
              queue.saveOnShutdown="on" action.resumeRetryCount="-1")
   & stop

   The queue keeps events on disk while the log server is unreachable. & stop keeps the audit events out of the local /var/log/messages or /var/log/syslog; they remain in audit.log as before.
5. Check and restart both services:

   rsyslogd -N1
   systemctl restart rsyslog
   service auditd restart

   On AlmaLinux, Rocky Linux and RHEL, auditd refuses systemctl restart; use service auditd restart as shown. On Ubuntu and Debian, systemctl restart auditd works as well.

Test

Create an audit event on the sending server, for example with a failed su login or auditctl -m "audit forwarding test". On the log server, the event appears within seconds:

tail /var/log/remote/web01/audispd.log

A forwarded event looks like this: audispd: node=web01 type=USER_LOGIN msg=audit(...): ... addr=203.0.113.9 terminal=ssh res=failed.

Notes

• A busy server with many audit rules produces a lot of events. Check the volume on the log server and add log rotation, as described in the rsyslog article above.
• Across the internet, encrypt the connection: see remote rsyslog with TLS.
• The audit system also has its own network client (audisp-remote) that sends events to another auditd. Use it when the receiving side is an audit server rather than a general log server.

Official documentation: audisp-syslog manual and rsyslog omfwd module.