# Auditd events are not captured for centos

**URL:** <https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215>\
**Category:** Beats\
**Tags:** auditbeat\
**Created:** [September 2, 2020, 11:25am UTC](https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215 "2020-09-02T11:25:21Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![ajesh](https://avatars.discourse-cdn.com/v4/letter/a/ecd19e/32.png) [@ajesh](https://discuss.elastic.co/u/ajesh)\
**Post date:** [September 2, 2020, 11:25am UTC](https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215/1 "2020-09-02T11:25:21Z")

</div>

Hi There,

We are running latest version of elastic stack 7.9. One issues we observed is auditd events are not captured for Centos 7 operating systems. Audit rules are already enabled and we see the events getting captured in /var/log/audit/audit.log.

This is is happening only for Centos , other OS like oracle linux and Amazon Linux 2 etc all giving the auditd events in elasticsearch dashboard.

We have also tested this on an old version of elasticsearch 7.6 and we are getting the same issues , Auditd events are not getting captures for centos alone.

Please help

---

<div class="post-metadata">

**Author:** ![ajesh](https://avatars.discourse-cdn.com/v4/letter/a/ecd19e/32.png) [@ajesh](https://discuss.elastic.co/u/ajesh)\
**Post date:** [September 17, 2020, 9:48am UTC](https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215/2 "2020-09-17T09:48:38Z")

</div>

Hi Team,

Please have a check on this, auditd events are not captured for CentOS by auditbeat.

---

<div class="post-metadata">

**Author:** ![kvch](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/kvch/32/72058_2.png) [@kvch](https://discuss.elastic.co/u/kvch)\
**Post date:** [September 21, 2020, 1:13pm UTC](https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215/3 "2020-09-21T13:13:39Z")

</div>

Could you please share your configuration format it using `</>` and debug logs?

---

<div class="post-metadata">

**Author:** ![ajesh](https://avatars.discourse-cdn.com/v4/letter/a/ecd19e/32.png) [@ajesh](https://discuss.elastic.co/u/ajesh)\
**Post date:** [September 23, 2020, 8:13am UTC](https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215/4 "2020-09-23T08:13:07Z")

</div>

Hello Noemi,

Below is the auditctl -l output from server

```
auditctl -l
-a always,exit -F arch=b64 -S rename,unlink,unlinkat,renameat -F auid>=1000 -F auid!=-1 -F key=delete
-a always,exit -F arch=b32 -S unlink,rename,unlinkat,renameat -F auid>=1000 -F auid!=-1 -F key=delete
-w /var/log/lastlog -p wa -k logins
-w /var/run/faillock -p wa -k logins
-w /var/run/utmp -p wa -k session
-w /var/log/wtmp -p wa -k session
-w /var/log/btmp -p wa -k session
-a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b32 -S chmod,fchmod,fchmodat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S chown,fchown,lchown,fchownat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b32 -S lchown,fchown,chown,fchownat -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b32 -S setxattr,lsetxattr,fsetxattr,removexattr,lremovexattr,fremovexattr -F auid>=1000 -F auid!=-1 -F key=perm_mod
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat -F exit=-EACCES -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b64 -S open,truncate,ftruncate,creat,openat -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=access
-a always,exit -F arch=b32 -S open,creat,truncate,ftruncate,openat -F exit=-EPERM -F auid>=1000 -F auid!=-1 -F key=access
-w /var/log/sudo.log -p wa -k actions
-a always,exit -F arch=b64 -S adjtimex,settimeofday -F key=time-change
-a always,exit -F arch=b32 -S stime,settimeofday,adjtimex -F key=time-change
-a always,exit -F arch=b64 -S clock_settime -F key=time-change
-a always,exit -F arch=b32 -S clock_settime -F key=time-change
-w /etc/localtime -p wa -k time-change
-w /etc/group -p wa -k identity
-w /etc/passwd -p wa -k identity
-w /etc/gshadow -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/security/opasswd -p wa -k identity

```

Auditbeat config

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

- module: auditd
  # Load audit rules from separate files. Same format as audit.rules(7).
  audit_rule_files: ['${path.config}/audit.rules.d/*.conf']
  audit_rules: |
    ## Define audit rules here.
    ## Create file watches (-w) or syscall audits (-a or -A). Uncomment these
    ## examples or add your own rules.

    ## If you are on a 64 bit platform, everything should be running
    ## in 64 bit mode. This rule will detect any use of the 32 bit syscalls
    ## because this might be a sign of someone exploiting a hole in the 32
    ## bit API.
    #-a always,exit -F arch=b32 -S all -F key=32bit-abi

    ## Executions.
    #-a always,exit -F arch=b64 -S execve,execveat -k exec

    ## External access (warning: these can be expensive to audit).
    #-a always,exit -F arch=b64 -S accept,bind,connect -F key=external-access

    ## Identity changes.
    #-w /etc/group -p wa -k identity
    #-w /etc/passwd -p wa -k identity
    #-w /etc/gshadow -p wa -k identity

    ## Unauthorized access attempts.
    #-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EACCES -k access
    #-a always,exit -F arch=b64 -S open,creat,truncate,ftruncate,openat,open_by_handle_at -F exit=-EPERM -k access

- module: file_integrity
  paths:
  - /bin
  - /usr/bin
  - /sbin
  - /usr/sbin
  - /etc

- module: system
  datasets:
    - package # Installed, updated, and removed packages

  period: 10m # The frequency at which the datasets check for changes

- module: system
  datasets:
    - host # General host information, e.g. uptime, IPs
    - login # User logins, logouts, and system boots.
    - user # User information

  period: 1m

#- module: system
# datasets:
# - process # Started and stopped processes
# - socket # Opened and closed sockets

# period: 15s

  # How often datasets send state updates with the
  # current state of the system (e.g. all currently
  # running processes, all open sockets).
  state.period: 12h

  # Enabled by default. Auditbeat will read password fields in
  # /etc/passwd and /etc/shadow and store a hash locally to
  # detect any changes.
  user.detect_password_changes: true

  # File patterns of the login record files.
  login.wtmp_file_pattern: /var/log/wtmp*
  login.btmp_file_pattern: /var/log/btmp*

# ======================= Elasticsearch template setting =======================
setup.template.settings:
  index.number_of_shards: 1
  index.codec: best_compression
  #_source.enabled: false

# ================================== 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.

# output.
fields:
  region: "IT India"

# =================================== Kibana ===================================

# Starting with Beats version 6.0.0, the dashboards are loaded via the Kibana API.
# This requires a Kibana endpoint configuration.
setup.kibana:

  # Kibana Host
  # Scheme and port can be left out and will be set to the default (http and 5601)
  # In case you specify and additional path, the scheme is required: http://localhost:5601/path
  # IPv6 addresses should always be defined as: https://[2001:db8::1]:5601
  host: "hotnode1:5601"

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

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

# ---------------------------- Elasticsearch Output ----------------------------
output.elasticsearch:
  # Array of hosts to connect to.
  hosts: ["hotnode1:9200", "hotnode2:9200"]
  compression_level: 9

  # Protocol - either `http` (default) or `https`.
  protocol: "https"

  # Authentication credentials - either API key or username/password.
  #api_key: "id:api_key"
  username: "elastic"
  password: "ajsfdhgsfdfsd"

  ssl.verification_mode: none

queue.mem:
  events: 32
  flush.min_events: 16

# ------------------------------ Logstash Output -------------------------------
#output.logstash:
  # The Logstash hosts
  #hosts: ["localhost:5044"]

  # Optional SSL. By default is off.
  # List of root certificates for HTTPS server verifications
  #ssl.certificate_authorities: ["/etc/pki/root/ca.pem"]

  # Certificate for SSL client authentication
  #ssl.certificate: "/etc/pki/client/cert.pem"

  # Client Certificate Key
  #ssl.key: "/etc/pki/client/cert.key"

# ================================= Processors =================================

# Configure processors to enhance or manipulate events generated by the beat.

processors:
  - add_host_metadata: ~
# - add_cloud_metadata: ~
# - add_docker_metadata: ~

  - drop_fields:
      fields: ["agent.id", "agent.version", "cloud.availability_zone", "cloud.image.id", "cloud.instance.id", "cloud.machine.type", "cloud.provider", "cloud.region", "ecs.version", "agent.ephemeral_id", "agent.id", "host.architecture", "host.os.platform", "host.os.version", "agent.name", "host.containerized"]
      ignore_missing: true

  - drop_event:
      when:
        equals:
          process.name: "chronyd"

# ================================== Logging ===================================

# Sets log level. The default log level is info.
# Available log levels are: error, warning, info, debug
#logging.level: debug

# At debug level, you can selectively enable logging only for some components.
# To enable all selectors use ["*"]. Examples of other selectors are "beat",
# "publish", "service".
#logging.selectors: ["*"]
logging.metrics.enabled: false

```

Currently all rules are applied at system auditd and not in the auditbeat config. This is working fine for other Linux distributions like Oracle Linux , Red Hat Linux etc. we are seeing problem only for Centos Versions

---

<div class="post-metadata">

**Author:** ![adrisr](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/adrisr/32/25423_2.png) [@adrisr](https://discuss.elastic.co/u/adrisr)\
**Post date:** [September 23, 2020, 3:39pm UTC](https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215/5 "2020-09-23T15:39:45Z")

</div>

If you're using a kernel older than 3.16, it's not possible to use Auditbeat as a passive monitor while the auditd service is running. You need to stop auditd and set the rules from Auditbeat.

It's explained under the `socket_type` configuration setting in [the docs:](https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-module-auditd.html#_configuration_options_13)

> **`socket_type`**
> 
> This optional setting controls the type of socket that Auditbeat uses to receive events from the kernel. The two options are `unicast` and `multicast` .
> 
> `unicast` should be used when Auditbeat is the primary userspace daemon for receiving audit events and managing the rules. Only a single process can receive audit events through the "unicast" connection so any other daemons should be stopped (e.g. stop `auditd` ).
> 
> `multicast` can be used in kernel versions 3.16 and newer. By using `multicast` Auditbeat will receive an audit event broadcast that is not exclusive to a a single process. This is ideal for situations where `auditd` is running and managing the rules. If `multicast` is specified, but the kernel version is less than 3.16 Auditbeat will automatically revert to `unicast` .
> 
> By default Auditbeat will use `multicast` if the kernel version is 3.16 or newer and no rules have been defined. Otherwise `unicast` will be used.

---

<div class="post-metadata">

**Author:** ![ajesh](https://avatars.discourse-cdn.com/v4/letter/a/ecd19e/32.png) [@ajesh](https://discuss.elastic.co/u/ajesh)\
**Post date:** [October 4, 2020, 5:52pm UTC](https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215/6 "2020-10-04T17:52:00Z")

</div>

Hello Adrian,

Sorry for the delayed response. We are using CentOS 7 with latest kernel.

I have tried on multiple VM's which up to date

Can you try this on your lab , you will not be getting the auditd events if you are using audit rules configured with the auditd service. Kindly check this

Thanks,  
Ajesh

---

<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:** [November 1, 2020, 7:52pm UTC](https://discuss.elastic.co/t/auditd-events-are-not-captured-for-centos/247215/7 "2020-11-01T19:52:00Z")

</div>

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