Linux Audit Framework · Event CONFIG_CHANGE
auditd type=CONFIG_CHANGE: the audit rules themselves changed
Someone changed what the audit system records. Every other audit rule depends on this one staying honest, which makes an unexplained rule change more significant than almost anything those rules were watching for.
Also written as type=CONFIG_CHANGEauditd rule changedaudit_backlog_limit changedauditd rules removed log
- How oftenRare
- Vendor calls itaudit
- Logaudit
What it means for you
For an analyst
The control worth knowing about is immutable mode. Setting '-e 2' as the last line of the rules means the rule set cannot be changed until reboot — auditctl refuses, and the attempt is recorded. That converts silent rule removal into either a visible failure or a reboot, both of which are noticeable. The trade is real: rule changes then require a maintenance window. Also note that a full rule flush produces a single CONFIG_CHANGE rather than one per rule, so the event count badly understates the impact, and audit_backlog_limit changes belong in the same category since shrinking the backlog causes records to be dropped under load without anything looking wrong.
The fields that decide it
Everything else in the log line is context.
- op
- What was done to the configuration.
-
add_ruleA rule was added. Usually legitimate, and worth confirming against a change record. -
remove_ruleA rule was removed. Coverage was reduced and this needs an explanation. -
setA parameter changed, such as the backlog limit or the failure mode. - key
- The rule key involved, when the rule had one. This is how you tell which of your monitored paths just stopped being monitored.
- auid and ses
- Who made the change and in which session. Because these records survive a privilege change, auid attributes the change to a person even when it was made as root.
- audit_enabled or audit_backlog_limit
- The parameter being changed, when op is set. Lowering the backlog limit causes records to be silently dropped under load, which degrades auditing without removing any rule.
- res
- Whether the change succeeded. A failed attempt in immutable mode is a strong signal on its own — someone tried to change the rules and could not.
Common questions
How do I stop someone removing my audit rules?
Put '-e 2' at the end of /etc/audit/rules.d/audit.rules, which locks the configuration until the next reboot. auditctl then refuses any change and the attempt is recorded. The cost is that legitimate rule changes need a reboot, so this is a decision about how much you value tamper resistance against operational convenience — but on a system where the audit log is evidence, it is usually worth it.
Does CONFIG_CHANGE record every rule that was removed?
No, and this catches people out. Flushing the entire rule set with 'auditctl -D' produces one record, not one per rule. The event count therefore tells you nothing about how much coverage was lost. To know that, compare the current output of 'auditctl -l' against your intended rule file rather than counting events.
Why would changing audit_backlog_limit matter?
Because the backlog is the queue of records waiting to be written. Lowering it means records are dropped when the system is busy, and nothing about that looks like tampering — no rule was removed and no error appears in the obvious places. It degrades auditing quietly, which is exactly why the parameter change is recorded here alongside rule modifications.
Are CONFIG_CHANGE records ever routine?
Yes, at boot and during configuration management runs, when the rule set is loaded or reapplied. Those cluster predictably around system start and around your configuration tool's schedule. What is not routine is a remove_rule outside those windows, or any change attributed to an auid belonging to a person rather than to the boot process.
Read next
- Usually comes after auditd type=SYSCALL: the record everything else hangs off The records produced by whatever rules survive the change.
- Usually comes after auditd EXECVE: a command was executed Command execution records, which stop being generated if the rule producing them is removed.
- The equivalent of Event 4719: The audit policy itself was changed The Windows equivalent — the audit policy itself being changed. The same intent in a different operating system.
- The equivalent of Event 1102: The audit log was cleared Clearing a Windows event log, the blunter approach to the same objective.
- Usually comes before su: someone switched to another account successfully Becoming root, which is a prerequisite for changing audit rules.
Mentioned by
Vendor documentation
Last reviewed 6 September 2026