# Auditbeat setting unspecified rule

**URL:** <https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045>\
**Category:** Beats\
**Tags:** auditbeat\
**Created:** [November 16, 2018, 11:46am UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045 "2018-11-16T11:46:29Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![nlh](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@nlh](https://discuss.elastic.co/u/nlh)\
**Post date:** [November 16, 2018, 11:46am UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/1 "2018-11-16T11:46:29Z")

</div>

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"]'
```

---

<div class="post-metadata">

**Author:** ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)\
**Post date:** [November 16, 2018, 4:45pm UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/2 "2018-11-16T16:45:00Z")

</div>

This is Auditbeat exempting itself from monitoring to mitigate some really nasty [issues](https://github.com/elastic/beats/issues/7157) 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.

---

<div class="post-metadata">

**Author:** ![nlh](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@nlh](https://discuss.elastic.co/u/nlh)\
**Post date:** [November 16, 2018, 5:00pm UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/3 "2018-11-16T17:00:03Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)\
**Post date:** [November 16, 2018, 5:43pm UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/4 "2018-11-16T17:43:29Z")

</div>

> [@nlh](#):
>
> I cannot filter it out and it is generating a fair amount of noise.

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 [linux - Ignore specific types with auditd - Server Fault](https://serverfault.com/a/613669). If you enable [include\_raw\_message](https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-module-auditd.html#_configuration_options_13) 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.

---

<div class="post-metadata">

**Author:** ![nlh](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@nlh](https://discuss.elastic.co/u/nlh)\
**Post date:** [November 17, 2018, 9:51am UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/5 "2018-11-17T09:51:08Z")

</div>

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
```

---

<div class="post-metadata">

**Author:** ![nlh](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@nlh](https://discuss.elastic.co/u/nlh)\
**Post date:** [November 22, 2018, 5:19pm UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/6 "2018-11-22T17:19:51Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![nlh](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@nlh](https://discuss.elastic.co/u/nlh)\
**Post date:** [November 26, 2018, 3:20pm UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/7 "2018-11-26T15:20:56Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)\
**Post date:** [November 26, 2018, 3:46pm UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/8 "2018-11-26T15:46:26Z")

</div>

> [@andrewkroh](#):
>
> Auditbeat receives all events written to the audit framework. Some tools publish there own events to the framework.

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`.

---

<div class="post-metadata">

**Author:** ![nlh](https://avatars.discourse-cdn.com/v4/letter/n/f9ae1b/32.png) [@nlh](https://discuss.elastic.co/u/nlh)\
**Post date:** [November 26, 2018, 4:32pm UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/9 "2018-11-26T16:32:23Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![andrewkroh](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/andrewkroh/32/3784_2.png) [@andrewkroh](https://discuss.elastic.co/u/andrewkroh)\
**Post date:** [November 28, 2018, 1:24am UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/10 "2018-11-28T01:24:05Z")

</div>

Yes, you can filter them in Auditbeat.

> [@andrewkroh](#):
>
> 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 [linux - Ignore specific types with auditd - Server Fault](https://serverfault.com/a/613669). If you enable [include\_raw\_message](https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-module-auditd.html#_configuration_options_13) 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.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/elastic/original/3X/1/a/1ac57faf039f6b580b3f104ef42a2a89e41014de.png) [@system](https://discuss.elastic.co/u/system)\
**Post date:** [December 19, 2018, 1:25am UTC](https://discuss.elastic.co/t/auditbeat-setting-unspecified-rule/157045/11 "2018-12-19T01:25:33Z")

</div>

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