neo23x0 / auditd Goto Github PK

Hi there,

Just observing that some binaries in the Alma base install are in different locations, specifically binaries there were normally in /bin and /sbin are now in /usr/bin and /usr/sbin/

These are the ones I found:

sed -i'' 's/\/opt\/filebeat/\/usr\/bin\/filebeat/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/auditctl/\ \/usr\/sbin\/auditctl/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\=\/sbin\/insmod/\=\/usr\/sbin\/insmod/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\=\/sbin\/modprobe/\=\/usr\/sbin\/modprobe/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\=\/sbin\/rmmod/\=\/usr\/sbin\/rmmod/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/bin\/su/\ \/usr\/bin\/su/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/shutdown/\ \/usr\/sbin\/shutdown/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/poweroff/\ \/usr\/sbin\/poweroff/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/reboot/\ \/usr\/sbin\/reboot/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/halt/\ \/usr\/sbin\/halt/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/bin\/hostname/\ \/usr\/bin\/hostname/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/bin\/uname/\ \/usr\/bin\/uname/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/bin\/nc/\ \/usr\/bin\/nc/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/iptables/\ \/usr\/sbin\/iptables/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/ip6tables/\ \/usr\/sbin\/ip6tables/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/ifconfig/\ \/usr\/sbin\/ifconfig/g' /etc/auditbeat/audit.rules.d/audit.rules
sed -i'' 's/\ \/sbin\/xtables-nft-multi/\ \/usr\/sbin\/xtables-nft-multi/g' /etc/auditbeat/audit.rules.d/audit.rules

Perhaps it's worthwhile to additionally add /usr entries for every binary line, unless of course this doesn't matter for auditd, I admittedly am not an expert on the topic.

Hi,

First of all, thank you for this auditd configuration file.
I use auditbeat running on Ubuntu 16.04 and get some errors when I load this configuration file.

Errors:

• Duplicate rules : this rule is present twice:
  -w /etc/sysconfig/network -p wa -k network_modifications

• Unknown user chrony : the user is _chrony on Ubuntu 16.04

Correction:

• Delete the duplicate rule
• Change chrony by _chrony

I get the error:

augenrules: -F unknown field: uid

I assume this is a typo:
https://github.com/Neo23x0/auditd/blob/master/audit.rules#L464

## Privilege Abuse
### The purpose of this rule is to detect when an admin may be abusing power by looking in user's home dir.
-a always,exit -F dir=/home -F uid=0 -F auid>=1000 -F auid!=-1 -C auid!=obj_uid -k power_abuse

...should be...

## Privilege Abuse
### The purpose of this rule is to detect when an admin may be abusing power by looking in user's home dir.
-a always,exit -F dir=/home -F auid=0 -F auid>=1000 -F auid!=-1 -C auid!=obj_uid -k power_abuse

Hello! I could check that this audit rules are not compatible with the output that is expected by audit2allow to fix selinux issues.
I have to revert the changes, get the default configuration of auditd and after that, I got the expected log type for selinux issues.
Please can you guide me how can I achieve that? I need this format for selinux

messagestype=AVC msg=audit(1571742292.924:439324): avc: denied { open } for pid=7263 comm="psql" path="/var/lib/zabbix/.pgpass" dev="dm-5" ino=2233826 scontext=system_u:system_r:zabbix_agent_t:s0 tcontext=unconfined_u:object_r:var_lib_t:s0 tclass=file permissive=0

Hello,

I was wondering if we could get augenrules to be a little smarter with filtering rules coming in. I found that a blank line with a simple tab or 2 will cause the process to fail. Also a duplicate rule in 2 different rule files will cause it to fail as well. I would like to see these filtered out.

Thanks!

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.

I have an Ubuntu 20.04 and installed auditd on it and I wanna set some rules on audit.rules file but eveyrtime I restart the service the file will rewritten to the default one. How can I keep my modified audit.rules file?

The following lines are yielding a "parameter passed without an option given" error on my CentOS machine.

-w /Library/Application Support/VirtualBox/LaunchDaemons/ -p x -k virt_tool
-w /Library/Application Support/VirtualBox/VBoxDrv.kext/ -p x -k virt_tool
-w /Library/Application Support/VirtualBox/VBoxUSB.kext/ -p x -k virt_tool
-w /Library/Application Support/VirtualBox/VBoxNetFlt.kext/ -p x -k virt_tool
-w /Library/Application Support/VirtualBox/VBoxNetAdp.kext/ -p x -k virt_tool

https://github.com/Neo23x0/auditd/blob/master/audit.rules#L649

As these lines are intended to be for macOS anyway, I will just remove them, so I don't know if escaping the whitespace with \ is the solution or if this is even a bug that affects auditd on macOS.

I was testing a subset of these rules along with what my $dayjob currently has. Something I noticed testing on PopOS/Ubuntu was that with the DAC modifications, they wouldn't catch anything, with at least bash (didn't test any other shells). I'm fairly new to auditd so I'm thinking it just a bash issue, but after I put the path to log some of the DAC modifications then it started logging. Am I missing the purpose of the DAC rule section or is this just a side effect of bash?

Example:

-a always,exit -F arch=b64 -S chown -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b32 -S chown -F auid>=1000 -F auid!=-1 -F key=perm_mod

wouldn't log anything but
-a always,exit -F path=/usr/bin/chown -F perm=x -F auid>=1000 -F auid!=-1 -F key=perm_mod
does.

Dear @Neo23x0,

thanks for starting and maintaining this utterly useful project.

Do you think it would make sense to require contributors to issue a) descriptive commit messages (e.g., "add rules for Inter-Process Communication") and b) atomic commits (e.g., don't trim lines the weren't updated otherwise)? I won't go into detail here since there are millions of pages describing why (e.g., usefulness of the git log) and how (e.g.).

Cheers

Lukas

auditd rhel centos suse debian ubuntu
security, security-tools, security-audit, security-hardening, hardening, cis-benchmark, assessment, compliance, gdpr, hipaa, cis, forensics

I added the in rules.d/audit.rules from this repo but i get
augenrules[30171]: failure 1
augenrules[30171]: pid 30167
augenrules[30171]: rate_limit 0
augenrules[30171]: backlog_limit 8192
augenrules[30171]: lost 0
augenrules[30171]: backlog 0
from systemctl status auditd
Then I checked using augenrules --load and there were some errors like "some directory not found".
I commented out those rules.
Now the error is gone but I still see augenrules[30171]: failure 1 in auditd status.

The following rule is "missing" the -p wa:

-w /var/spool/cron/ -k cron

And of course this implies -p rwxa. Is this intentional?

There are currently a number of key strings that refer to the mitre attack guide, though in most cases there is little relation to the actual logs.

For example:

T1497_Virtualization_Sandbox_Evasion_System_Checks is used as key whenever virtual box applications are executed in /bin/local.

It also triggers for qemu when running on a Debian Bookwork VM, while the comment in the rules indicate it handles "qemu on macOS"

A different example is T1011_Exfiltration_Over_Other_Network_Medium, which is currently triggered every time a network socket file is created. While it may be correct that it could be used for exfiltration, it stands to reason that it will trigger a lot more often during normal operations.

I would suggest to remove the mitre naming convention completely and use more simple key strings, like "socket created" for the second example.

Hi,
I'm trying to run the auditd service with rules based on this Best Practice on Ubuntu 16.04 and i'm having some troubles-
I started with installing the auditd package with the command: "apt-get install auditd audispd-plugins".
Next, I switched the /etc/audit/audit.rules with my audit.rules file
And finally, I restarted the auditd service: "services auditd restart"

The problem:
When I'm running the "service auditd status" command I have this message-
Active: active (running) since ......
Process: 3728 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=1/FALIURE)

Please help me find the right solution.
Thank you,
AgentsOfShield

starting with v5.11.7 kernel goes into oops mode starting auditd service. Sorry I don't have more specific information since I don't know how to debug auditd rules.

Hello
It looks like line 68 is missing an =
-a always,exclude -F msgtypeAVC
should be
-a always,exclude -F msgtype=AVC

Hello, I am afraid that this set of rules is not performing well. I tried the following command on a test VM with it:

time dd if=/dev/zero of=/dev/null bs=512 count=1000000

It took about 1.8s; however, when I inserted the following rule on top of the rule set, it took only about 0.4s:

-a never,exit -F arch=b64 -S read,write

Reason is probably that all system calls that are not handled in the rule set are checked against all syscall rules.
It thus might be useful to insert a rule on top that "ignores" all system calls that are not handled in the original rule set and that are often used.

Hi,
The change made in this merged pull request (issue 125) in January unfortunately broke the power_abuse rule.

The rule does not work anymore because now it requires auid to be both 0 and >=1000 at the same time, which is impossible.

Merged version (since January):

## Privilege Abuse
### The purpose of this rule is to detect when an admin may be abusing power by looking in user's home dir.
-a always,exit -F dir=/home -F auid=0 -F auid>=1000 -F auid!=-1 -C auid!=obj_uid -k power_abuse

Original version (before January):

## Privilege Abuse
### The purpose of this rule is to detect when an admin may be abusing power by looking in user's home dir.
-a always,exit -F dir=/home -F uid=0 -F auid>=1000 -F auid!=-1 -C auid!=obj_uid -k power_abuse

How to fix:
My suggestion would be to revert back to the original version of the rule.

Tests done:
I tested the original and the merged version in an Ubuntu 22.04 VM. As expected, the merged version does not log the behavior, whereas the original version does.
Also, the error message mentioned by the original pull request author did not occur for me.

(Just to track from man auditctl.8.)

The -w form of writing watches is for backwards compatibility and is deprecated due to poor system performance. Convert watches of this form to the syscall based form.

Examples:

To watch a file for changes (2 ways to express):

auditctl -w /etc/shadow -p wa # Note this slows the system
auditctl -a always,exit -F arch=b64 -F path=/etc/shadow -F perm=wa

To recursively watch a directory for changes (2 ways to express):

auditctl -w /etc/ -p wa # Note this slows the system
auditctl -a always,exit -F arch=b64 -F dir=/etc/ -F perm=wa

Why it the order of action and filter in this line "-a exit,always" and not "-a always,exit" like all the other lines have?

This line
https://github.com/Neo23x0/auditd/blob/master/audit.rules#L90
also seems to have a reverse order.

Is this intentional?

Received the following errors on Red Hat 8.6 after reloading the rule file

auditctl -R /etc/audit/rules.d/audit.rules

No rules
enabled 1
failure 1
pid 910
rate_limit 0
backlog_limit 8192
lost 0
backlog 1350
backlog_wait_time 60000
backlog_wait_time_actual 17852
enabled 1
failure 1
pid 910
rate_limit 0
backlog_limit 8192
lost 0
backlog 941
backlog_wait_time 60000
backlog_wait_time_actual 17852
-F missing operation for -k
There was an error in line 66 of /etc/audit/rules.d/audit.rules
-F missing operation for -k
There was an error in line 67 of /etc/audit/rules.d/audit.rules
-F missing operation for -k
There was an error in line 68 of /etc/audit/rules.d/audit.rules
-F missing operation for -k
There was an error in line 69 of /etc/audit/rules.d/audit.rules
-F missing operation for -k
There was an error in line 70 of /etc/audit/rules.d/audit.rules
Unknown user: ntp
There was an error in line 147 of /etc/audit/rules.d/audit.rules
Unknown user: ntp
There was an error in line 148 of /etc/audit/rules.d/audit.rules
Error sending add rule data request (No such file or directory)
There was an error in line 554 of /etc/audit/rules.d/audit.rules
Error sending add rule data request (No such file or directory)
There was an error in line 559 of /etc/audit/rules.d/audit.rules
Error sending add rule data request (No such file or directory)
There was an error in line 562 of /etc/audit/rules.d/audit.rules
Append rule - bad keyword entry,always
There was an error in line 641 of /etc/audit/rules.d/audit.rules
Append rule - bad keyword entry,always
There was an error in line 642 of /etc/audit/rules.d/audit.rules
Append rule - bad keyword entry,always
There was an error in line 653 of /etc/audit/rules.d/audit.rules
Append rule - bad keyword entry,always
There was an error in line 654 of /etc/audit/rules.d/audit.rules
Append rule - bad keyword entry,always
There was an error in line 655 of /etc/audit/rules.d/audit.rules
Append rule - bad keyword entry,always
There was an error in line 656 of /etc/audit/rules.d/audit.rules
Append rule - bad keyword entry,always
There was an error in line 663 of /etc/audit/rules.d/audit.rules
Append rule - bad keyword entry,always
There was an error in line 664 of /etc/audit/rules.d/audit.rules