Auditbeat setting unspecified rule

#1

Hi, Running Auditbeat 6.4.2 and the rules in the .yml file are:

  audit_rules: |
    -w /etc/auditbeat/auditbeat.yml -p wa -k auditbeat_issue
    -w /etc/passwd -p wa -k passwd_changes
    -w /PTC/ -p wr -k ptc_code_access

But the rules that are set when doing an auditctl -l are

    -a never,exit -S all -F pid=28948
    -w /etc/auditbeat/auditbeat.yml -p wa -k auditbeat_issue
    -w /etc/passwd -p wa -k passwd_changes
    -w /PTC/ -p wr -k ptc_code_access

Where is the first one coming from. Definitely appears to be from auditbeat as if I stop auditbeat, delete all the rules and restart it, back it comes with a different pid.

Complete yml file below.

# You can find the full configuration reference here:
# https://www.elastic.co/guide/en/beats/auditbeat/index.html

#============================  Config Reloading ================================

# Config reloading allows to dynamically load modules. Each file which is
# monitored must contain one or multiple modules as a list.
auditbeat.config.modules:

  # Glob pattern for configuration reloading
  path: ${path.config}/conf.d/*.yml

  # Period on which files under path should be checked for changes
  reload.period: 10s

  # Set to true to enable config reloading
  reload.enabled: true

# Maximum amount of time to randomly delay the start of a metricset. Use 0 to
# disable startup delay.
auditbeat.max_start_delay: 10s

#==========================  Modules configuration =============================
auditbeat.modules:

# The kernel metricset collects events from the audit framework in the Linux
# kernel. You need to specify audit rules for the events that you want to audit.
- module: auditd
  resolve_ids: true
  failure_mode: log
  backlog_limit: 8196
  rate_limit: 0
  include_raw_message: false
  include_warnings: false
  audit_rules: |
    -w /etc/auditbeat/auditbeat.yml -p wa -k auditbeat_issue
    -w /etc/passwd -p wa -k passwd_changes
    -w /PTC/ -p wr -k ptc_code_access

#================================ General ======================================

# The name of the shipper that publishes the network data. It can be used to group
# all the transactions sent by a single shipper in the web interface.
# If this options is not defined, the hostname is used.
name: ptc-desk-vm    

#================================ Outputs ======================================

# Configure what output to use when sending the data collected by the beat.

#----------------------------- Logstash output ---------------------------------
output.logstash:
  hosts: ["soptct62-02.location.ptc.com:5044"]
  protocol: "https"

# output.console:
#   pretty: true

#================================= Paths ======================================
# The data path for the auditbeat installation. This is the default base path
# for all the files in which auditbeat needs to store its data. If not set by a
# CLI flag or in the configuration file, the default for the data path is a data
# subdirectory inside the home path.
# path.data: /MON/data

# The logs path for a auditbeat installation. This is the default location for
# the Beat's log files. If not set by a CLI flag or in the configuration file,
# the default for the logs path is a logs subdirectory inside the home path.
# path.logs: /MON/logs

#============================== Dashboards =====================================
# I've been advised by the Auditbeat guru that it is better to manually add
# the dashboards. Must be done after the index template has been deployed
# The command is:
#auditbeat setup -e -d "*" \
#  -E output.logstash.enabled=false \
#  -E output.elasticsearch.hosts=['elasticstack:9200'] \
#  -E setup.kibana.host=elasticstack:5601 \
#  -E setup.dashboards.always_kibana=true

#============================== Template =====================================
# I have been advised by the Auditbeat guru that it is better to deploy 
# the template manually. The command to do this is:

#auditbeat setup --template -E output.logstash.enabled=false \
#  -E 'output.elasticsearch.hosts=["soptct62-02.ptc.com:9200"]'
(Andrew Kroh) #2

This is Auditbeat exempting itself from monitoring to mitigate some really nasty issues that can occur if the system get bogged down. It also can prevent feedback loop issues (like if you were to tell auditbeat to monitor something about itself like changes to its log file).

It would be good for Auditbeat to add a -k exempt_auditbeat key to make this clear.

#3

Hi Andrew, I can understand that and it sort of makes sense. Is there any way I can switch this off as without the key, I cannot filter it out and it is generating a fair amount of noise. Things like cron. systemd and so on are coming across to the monitoring system that we are not interesting in.

Is the answer to just filter these out individually? That would be a pain. Cheers, N

(Andrew Kroh) #4

This rule added by Auditbeat does not generate any noise, in fact it does the opposite. It acts as a filter to drop events.

Auditbeat receives all events written to the audit framework. Some tools publish there own events to the framework. There are two ways to filter message. One is in the kernel by adding rules that exclude. The other is to filter later in Auditbeat after it has received the event (most costly since the filtering is later).

To filter in the kernel you add a rule like described in https://serverfault.com/a/613669. If you enable include_raw_message while setting things up this will be helpful because you can see the raw messages that you will be filtering.

To filter in Auditbeat you can add a drop_event processor to your config.

#5

Hi Andrew, that makes sense, but what rule (based on the above rules) are sending the following types of messages across? ptcdeskvm and ptcdeskfs have the same rules and we see them for both.

I understand about filtering the messages out using things like logstash and have for things like TSM back up running against the /PTC directory, but these are not being sent by any of the rules that I can see. So wondering where they are coming from.

@timestamp  		                        November 17th 2018, 09:35:01.200
t @version 		                        1
t _id 		                                1FgGIWcBOPn74kFzBq2n
t _index 		                        auditbeat-6.6.0-2018.11.17
# _score 		                        - 
t _type 		                                doc
t auditd.data.acct 		                root
t auditd.data.op 		                PAM:session_close
t auditd.data.terminal 		                cron
t auditd.result 		                        success
# auditd.sequence 		                1,640,329
t auditd.session 		                1173
t auditd.summary.actor.primary   		root
t auditd.summary.actor.secondary 		root
t auditd.summary.how 		                /usr/sbin/cron
t auditd.summary.object.primary   		cron
t auditd.summary.object.type 		        user-session
t beat.hostname 		                        ptcdeskfs
t beat.name 		                        ptc-desk-fs
t beat.version 		                        6.6.0
t event.action 		                        ended-session
t event.category 		                user-login
t event.module 		                        auditd
t event.type 		                        user_end
t host                          		        {
                                                "name": "ptc-desk-fs"
                                                }
t process.exe 	                    	        /usr/sbin/cron
t process.pid 	                    	        14274
t tags 		                                beats_input_raw_event
t user.auid 		                        0
t user.name_map.auid 		                root
t user.name_map.uid 		                root
t user.uid 	                	        0
#6

Hi, Anyone any thoughts as to why Auditbeat is sending messages not in the rules across?

#7

In the vague hope that there is a reason for Auditbeat sending /usr/sbin/cron across when it is not in the rules. Even simplified the rules further.

audit_rules: |
-w /PTC/ -p r -k ptc_code_access
-w /etc/auditbeat/auditbeat.yml -p rw -k auditbeat_issue

(Andrew Kroh) #8

As I said in an earlier post, your rules are not responsible for those events. They are generated by other things in the system that write audit events (pam, openssh, etc).

One indicator of these events is that event.category is user-login rather than audit-rule.

#9

Apologies Andrew, that did not make sense before. Not sure why. Still learning!

So is there anyway auditbeat can stop them or is it only a case of filtering at the Logstash point?

(Andrew Kroh) #10

Yes, you can filter them in Auditbeat.