Configuring Auditbeat to only report modifications to files I want to monitor

[nnarain (Nate)]

Hey,

I'd like some advice on configuring my Auditbeat instance to report modifications to the files I've specified. I get a lot of other entries into my elastic index that are not relevant to the rules I've specified.

Current my config looks like the following.

    -a exit,always -F path=/etc/hosts                          -F perm=wa
    -a exit,always -F path=/etc/hostname                 -F perm=wa
    -a exit,always -F path=/etc/network/interfaces -F perm=wa

However Auditbeat will report activity for cron, systemd, sshd, etc. Any advice to help me narrow the filter?

Thanks

[adrisr (Adrian Serrano)]

Hi,

Can you share your full Auditbeat config as well as the version you're using?

[nnarain (Nate)]

Auditbeat 6.3.2

Config is pretty much the defaults with the exception of the above.

###################### Auditbeat Configuration Example #########################

# This is an example configuration file highlighting only the most common
# options. The auditbeat.reference.yml file from the same directory contains all
# the supported options with more comments. You can use it as a reference.
#
# You can find the full configuration reference here:
# https://www.elastic.co/guide/en/beats/auditbeat/index.html

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

- module: auditd
  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

    -a exit,always -F path=/etc/hosts                                       -F perm=wa
    -a exit,always -F path=/etc/hostname                                    -F perm=wa
    -a exit,always -F path=/etc/network/interfaces                          -F perm=wa

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



#==================== Elasticsearch template setting ==========================
setup.template.settings:
  index.number_of_shards: 3
  #index.codec: best_compression
  #_source.enabled: false
setup.template.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.
#name:

# The tags of the shipper are included in their own field with each
# transaction published.
#tags: ["service-X", "web-tier"]

# Optional fields that you can specify to add additional information to the
# output.
#fields:
#  env: staging


#============================== Dashboards =====================================
# These settings control loading the sample dashboards to the Kibana index. Loading
# the dashboards is disabled by default and can be enabled either by setting the
# options here, or by using the `-setup` CLI flag or the `setup` command.
#setup.dashboards.enabled: false

# The URL from where to download the dashboards archive. By default this URL
# has a value which is computed based on the Beat name and version. For released
# versions, this URL points to the dashboard archive on the artifacts.elastic.co
# website.
#setup.dashboards.url:

#============================== 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: "localhost:5601"

#============================= Elastic Cloud ==================================

# These settings simplify using beatname with the Elastic Cloud (https://cloud.elastic.co/).

# The cloud.id setting overwrites the `output.elasticsearch.hosts` and
# `setup.kibana.host` options.
# You can find the `cloud.id` in the Elastic Cloud web UI.
#cloud.id:

# The cloud.auth setting overwrites the `output.elasticsearch.username` and
# `output.elasticsearch.password` settings. The format is `<user>:<pass>`.
#cloud.auth:

#================================ 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: ["http://localhost:8888"]
  index: "foo"

  # Optional protocol and basic auth credentials.
  #protocol: "https"
  #username: "elastic"
  #password: "changeme"

#----------------------------- 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"

#================================ 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: ["*"]

#============================== Xpack Monitoring ===============================
# beatname can export internal metrics to a central Elasticsearch monitoring
# cluster.  This requires xpack monitoring to be enabled in Elasticsearch.  The
# reporting is disabled by default.

# Set to true to enable the monitoring reporter.
#xpack.monitoring.enabled: false

# Uncomment to send the metrics to Elasticsearch. Most settings from the
# Elasticsearch output are accepted here as well. Any setting that is not set is
# automatically inherited from the Elasticsearch output configuration, so if you
# have the Elasticsearch output configured, you can simply uncomment the
# following line.
#xpack.monitoring.elasticsearch:

[adrisr (Adrian Serrano)]

Can you share sample documents for that cron/systemd/sshd activity?\

With the config you shared you should only get activity related to those 3 files (attributes changed and writes). But also the file_integrity module is enabled in /etc, which can cause accesses to /etc/ssh and similar to be reported too. Is that what you want?

[nnarain (Nate)]

Ya I removed use of the file_integrity module for now. Still getting cron entries.

Here's an entry generated by cron.

{
  "_index": "foo_auditbeat-000002",
  "_type": "audit",
  "_id": "3e618270ce74f4a81b770742654e84cad2799b5c",
  "_version": 1,
  "_score": null,
  "_source": {
    "event": {
      "category": "user-login",
      "action": "was-authorized",
      "type": "user_acct",
      "module": "auditd"
    },
    "process": {
      "exe": "/usr/sbin/cron",
      "pid": "18890"
    },
    "@timestamp": "2018-10-02T17:39:02+00:00",
    "namespace": null,
    "auditd": {
      "session": "unset",
      "data": {
        "terminal": "cron",
        "acct": "root",
        "op": "PAM:accounting"
      },
      "result": "success",
      "sequence": 932,
      "summary": {
        "how": "/usr/sbin/cron",
        "object": {
          "type": "user-session",
          "primary": "cron"
        },
        "actor": {
          "primary": "unset",
          "secondary": "root"
        }
      }
    },
    "beat": {
      "hostname": "foo-hostname",
      "name": "foo-hostname",
      "version": "6.3.2"
    },
    "host": {
      "name": "foo-hostname"
    },
    "user": {
      "auid": "unset",
      "uid": "0",
      "name_map": {
        "uid": "root"
      }
    },
    "machine-id": "foo-id"
  },
  "fields": {
    "@timestamp": [
      1538501942000
    ]
  },
  "highlight": {
    "beat.hostname": [
      "foo-hostname"
    ]
  },
  "sort": [
    1538501942000
  ]
}

[adrisr (Adrian Serrano)]

Okay, this are audit events generated by other processes (pam, sudo, etc.), and they show up even if Auditbeat itself install no rules for them.

To filter them out, the suggestion is to install a drop processor. Have a look at this answer:

Auditbeat event types

Auditbeat subscribes to all events from the kernel's audit framework. Even if you configure no audit rules there are still events that get generated by other processes that publish audit events (like PAM, su, sudo). You can add a processor to your configuration if you want to drop events. For example if you only wanted to receive events related to audit rules that you configured you could filter use auditbeat.modules: - module: auditd processors: - drop_event.when.not.equals.event.category…

[nnarain (Nate)]

That looks promising I give it a try.