Auditbeat: specified rules don't apply

Elastic Stack Beats
1

Hi Everyone,

Not sure what I am doing wrong here but it seems like auditd does not apply the auditd rules I defined.

our Auditbeat uses both available modules, auditd and file_integrity. and it looks like only the file_integrity module sends its data to our Elasticsearch machine (we're not using logstash, straight from Elasticsearch to Kibana).

Our auditd rules list is quite extensive, it's based on this rule file : https://gist.github.com/Neo23x0/9fe88c0c5979e017a389b90fd19ddfee

Here is what my module configuration in /etc/auditbeat/auditbeat.yml (CentOs 7) looks like:

#========================== Modules configuration =============================

auditbeat.modules:

  • module: auditd

    #audit_rule_files: [ '/etc/audit/rules.d/audit.rules' ]

    audit_rules: |

    -w /var/log/audit/ -k auditlog

    -w /etc/audit/ -p wa -k auditconfig

    -w /etc/libaudit.conf -p wa -k auditconfig

    -w /etc/audisp/ -p wa -k audispconfig

    -w /sbin/auditctl -p x -k audittools

    -w /sbin/auditd -p x -k audittools

    -a always,exclude -F msgtype=AVC

    -a always,exclude -F msgtype=CWD

    -a always,exclude -F msgtype=EOE

skipping hundreds of lines

-a always,exit -F arch=b64 -S mkdir,creat,link,symlink,mknod,mknodat,linkat,symlinkat -F exit=-EACCES -k file_creation

-a always,exit -F arch=b32 -S link,mkdir,symlink,mkdirat -F exit=-EPERM -k file_creation

-a always,exit -F arch=b64 -S mkdir,link,symlink,mkdirat -F exit=-EPERM -k file_creation

-a always,exit -F arch=b32 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EACCES -k file_modification

-a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EACCES -k file_modification

-a always,exit -F arch=b32 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EPERM -k file_modification

-a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EPERM -k file_modification

  • module: file_integrity

    paths:

    • /bin

    • /usr/bin

    • /sbin

    • /usr/sbin

    • /etc

I also tried to point auditbeats to the auditd rules file :slight_smile:
audit_rule_files: [ '/etc/audit/rules.d/audit.rules' ]
but that doesn't seem to be working either. The rules are still ignored. If it wasn't ignored, I should see a lot more log entries in Elasticsearch as the rule file generates a lot of auditd logging.

What am I doing wrong ? or maybe I have too many rules nested under the auditd module?

Finally, it seems like auditdbeat is only sending its data to ES when I reload/restart the service...why is that? Is there some sort of "time-to-push" trigger that I need to configure so auditbeat keeps feeding ES with the newest auditbeat logs?

Yes, I run auditbeat with auditd completely stopped.

Thanks very much!

2

Hi Guillaume, can you paste your Auditbeat log (if it doesn't contain any sensitive information)? I wonder if it contains any errors or warnings that could help us. You could also turn on debug logging using the -d "auditd" command line option.

What do you mean when you say that "auditdbeat is only sending its data to ES when I reload/restart the service"? I first thought you meant the rules are ignored and nothing is ever sent, or maybe sometimes it sends something and then it doesn't?

3

Hello Christoph,

Thank you for getting back to me.

So a couple of things before I start; Please ignore when I said auditbeat only works when I restart it.. I was letting the auditd daemon running in the background. I didn't know it had to be stopped. I read it on this forum..maybe that information should be mentioned in some kind of info box in the official documentation?

Here is my auditbeat.yaml file: https://pastebin.com/QZ2SF5Ke

And here are the auditd logs file: https://pastebin.com/AnnR9ub2

I masked all sensitive information in the files.

Thank you very much for your help,

Guillaume

4

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.