# Auditd exclude filters are adding a significant delay

**URL:** <https://discuss.elastic.co/t/auditd-exclude-filters-are-adding-a-significant-delay/279608>\
**Category:** Beats\
**Tags:** auditbeat\
**Created:** [July 26, 2021, 9:55am UTC](https://discuss.elastic.co/t/auditd-exclude-filters-are-adding-a-significant-delay/279608 "2021-07-26T09:55:11Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![vincent509](https://avatars.discourse-cdn.com/v4/letter/v/b9bd4f/32.png) [@vincent509](https://discuss.elastic.co/u/vincent509)\
**Post date:** [July 26, 2021, 9:55am UTC](https://discuss.elastic.co/t/auditd-exclude-filters-are-adding-a-significant-delay/279608/1 "2021-07-26T09:55:11Z")

</div>

I am running AuditBeat with the auditd module, and I have noticed that some filter rules are adding a significant delay between the event being created, and AuditBeat publishing the event.

For example: Consider the following rule which is filtering out events which are not the message\_types PATH, SYSCALL or CWD.

```auto
-a never,exclude -F msgtype!=SYSCALL -F msgtype!=PATH -F msgtype!=CWD

```

From the AuditBeat logs:

```auto
2021-07-22T16:38:11.822+0200 DEBUG [processors] processing/processors.go:203 Publish event: {
  "@timestamp": "2021-07-22T14:38:09.791Z",
  "@metadata": {
    "beat": "auditbeat",
    "type": "_doc",
    "version": "7.11.1"
  },
  . 
  .
  .
  "process": {
    "ppid": 9599,
    "name": "touch",
    "executable": "/usr/bin/touch",
    "pid": 18287
  }
}
2021-07-22T16:38:12.329+0200 DEBUG [kafka] kafka/client.go:371 finished kafka batch

```

As can be seen, there is a 2 second delay before the touch event happened, and the event is published by Auditbeat:

```auto
2021-07-22T14:38:09.791

```

vs

```auto
2021-07-22T16:38:11.822

```

However, exclude filters which "Blacklisting" instead of "Whitelisting" does not seem to introduce the same delay.

Consider the following filters which are defining which message\_types to exclude, instead of which message\_types not to exclude:

```auto
-a always,exclude -F msgtype=user_acct
-a always,exclude -F msgtype=add_group
-a always,exclude -F msgtype=add_user
-a always,exclude -F msgtype=cred_disp
-a always,exclude -F msgtype=cred_acq
-a always,exclude -F msgtype=cred_refr
-a always,exclude -F msgtype=crypto_key_user
-a always,exclude -F msgtype=crypto_login
-a always,exclude -F msgtype=user_auth
-a always,exclude -F msgtype=user_avc
-a always,exclude -F msgtype=user_logout

```

From the Auditbeat logs:

```auto
2021-07-22T16:47:25.227+0200 DEBUG [processors] processing/processors.go:203 Publish event: {
  "@timestamp": "2021-07-22T14:47:25.207Z",
  "@metadata": {
    "beat": "auditbeat",
    "type": "_doc",
    "version": "7.11.1"
  },
  .
  .
  .
  "process": {
    "pid": 18685,
    "ppid": 9599,
    "title": "touch hello",
    "name": "touch",
    "executable": "/usr/bin/touch",
    "working_directory": "/var/entimice"
  }
}
2021-07-22T16:47:25.729+0200 DEBUG [kafka] kafka/client.go:371 finished kafka batch

```

As can be seen from the logs, the time difference is much more reasonable:

```auto
2021-07-22T14:47:25.207

```

vs

```auto
 2021-07-22T16:47:25.227

```

Since there is a lot of different message\_types ([B.2.&nbsp;Audit Record Types Red Hat Enterprise Linux 6 | Red Hat Customer Portal](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sec-audit_record_types)) it is obviously more convenient to use the first rule, instead of a 100-something rules to capture all the message\_types I am not interested in.

I would like to know what is causing this delay, and if it can be circumvented somehow.

---

<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:** [August 23, 2021, 11:56am UTC](https://discuss.elastic.co/t/auditd-exclude-filters-are-adding-a-significant-delay/279608/2 "2021-08-23T11:56:08Z")

</div>

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