High logging rules

[valoq]

The idea of this auditd configuration is to provide a basic configuration that

works out-of-the-box on all major Linux distributions
fits most use cases
produces a reasonable amount of log data
covers security relevant activity
is easy to read (different sections, many comments)

After several years of using the rules in this repository on many different systems, I have to say that I was never able to deploy them in productive environments without significant changes. That is mostly due to rule that create a high amount of logging data.

Since the project is described as above, which includes a reasonable amount of log data and fitting most use cases, perhaps the relevant rules that trigger most often on common systems should be reviewed.

As one example for such a rule, i would list:

### Successful IPv4 Connections
-a always,exit -F arch=b64 -S connect -F a2=16 -F success=1 -F key=network_connect_4
-a always,exit -F arch=b32 -S connect -F a2=16 -F success=1 -F key=network_connect_4

### Successful IPv6 Connections
-a always,exit -F arch=b64 -S connect -F a2=28 -F success=1 -F key=network_connect_6
-a always,exit -F arch=b32 -S connect -F a2=28 -F success=1 -F key=network_connect_6

If this rule is use on any productive host offering network services, it will flood the logs with these alerts. in most environments, network connections are already logged by central firewalls, so the question is if this rule makes sense to include by default.

The same question can be targeted at rules like susp_shell which will trigger at every execution of a shell script. On production servers I have often seen this rule flood the logs as well since there were scripts that triggered every few seconds.

In general I would argue that the default audit rules should log mostly critical system activities like changing user attributes and privileges as well as anything that is highly likely to be suspicious while having a low chance to be triggered by false positives. Normal operations like network connections should probably be commented out by default.

[Neo23x0]

Those rules should be move to the section High Volume Events at the end of the configuration.
And maybe one day I'll adjust the description and explain that there's the "high volume events" section and if people are worried, they should deactivate them right away before deploying the config.

[lpirl]

I have the same issues with deployment for production systems as @valoq .

Has it already been discussed to split the different "log level" to different files for easier scripting? A rules file with all the rules can probably easily be created with a CI task, no?

[Neo23x0]

Is scripting really necessary?
Would people really script a download of multiple auditd files and concatenate them together?
I wouldn't script it. I'd download it and update it every once in a while manually.

[lpirl]

In the age of devops, automation, and continuous everything, yes, this is a possible use case IMHO *. Since there is /etc/audit/rules.d, there is even no need to concatenate.

Additionally, it wouldn't hurt, would it?

[Neo23x0]

Splitting up a rule set into multiple files hurts the main goal of this project: to provide a best practice configuration in form of a single file. You can find split up rule sets and subsets of this set everywhere.
I'm not sure if the benefit justifies the disadvantage.

Would a dev ops engineer write a script to download an ever changing config file and deploy it automatically.

[lpirl]

If we would compile the split files into a single rules file per CI, I fail to see the disadvantage.

I'd argue that automatically updating the rules is as plausible as updating software in general. People maybe trust the project (as we trust a lot of software), maybe subscribe to changes, or maybe consider the effort for manual updates vs. the risk of unwanted rules.

[valoq]

Having a single file for the rules makes it less complicated to get started with.

Having different sections that may be commented or uncommented depending on use case is probably the more simple approach and you can still script it.

[lpirl]

Having a single file for the rules makes it less complicated to get started with.

Not sure I managed to express my idea: We would still have a single file for download, just a different URL.

Having different sections that may be commented or uncommented depending on use case is probably the more simple approach and you can still script it.

Interesting, with which command would one comment out all rules in the section High Volume Events?

[kovacs-andras]

imho the real problem is "security" folks are usually copy-paste force-deploying these rules into prod without any understanding on the linux audit framework neither the infra they should protect... I've seen it a couple of times. So the only thing is missing from the readme is probably an RTFM. Or does it? :)
The ruleset (as it is now) can give a bunch of ideas to craft a suitable one. Making more specific rulesets seems a slippery-slope to me. And even if we would make separate rulesets for the different auditd versions and different Linux distros we still don't know anything about the target systems like:

• user ids and their range
• installed applications (osquery, binaries, configs to watch and their users too)
• any other already existing rules loaded from somewhere else (ie. Azure OMS audit plugin)
• the resources available (because the auditd rules can and usually have performance impact too)
• any other custom configs

I wouldn't blame this repo for any of the mentioned issues.