Getting started with Auditbeat

Storing and analyzing audit data

Photo by Scott Graham on Unsplash

Auditbeat allows you to monitor user activity and processes and analyze your event data in the Elastic Stack without touching auditd. Audit beat communicates directly with the Linux audit framework, collects the same data as auditd, and sends the events to the Elastic Stack in real time.

It is a lightweight shipper that can help detect changes to critical files, and identify potential security policy violations.

Auditbeat has various modules and I will discuss the three most common modules in this article

1. Auditd
2. File Integrity
3. System

Auditd Module

• auditd module receives audit events from the Linux Audit Framework that is a part of the Linux kernel(Only available for Linux).
• It establishes a subscription to the kernel to receive the events as they occur ( period configuration is unused).
• Might need to stop other services such auditd/journald
• File System rule — file watches, allow the auditing of access to a particular file or a directory.

 w path_to_file -p permissions -k key_name
 
 Permission: rwxa

• System call rule — allow logging of system calls that any specified program makes

-a action,filter -S system_call -F field=value -k key_name
Action: always/never
Filter: task, exit, user, and exclude
system_call specifies the system call by its name
field=value specifies additional options that furthermore modify the rule to match events based on a specified architecture, group ID, process ID, and others.

File integrity module

• file_integrity module sends events when a file is changed (created, updated, or deleted) on a disk. The events contain file metadata and hashes.
• creates a subscription with the OS to receive notifications of changes to the specified files or directories. Upon receiving notification of a change the module will read the file’s metadata and compute a hash of the file’s contents.
• At startup this module will perform an initial scan of the configured files and directories to generate baseline data for the monitored paths and detect changes since the last time it was run. It uses locally persisted data in order to only send events for new or modified files.

System Module

• The system module collects various security-related information about a system. All datasets send both periodic state information (e.g. all currently running processes) and real-time changes (e.g. when a new process starts or stops).
• Each dataset sends two kinds of information: state and events
• State information is sent periodically and (for some datasets) on startup.
• frequency of state updates can be controlled for all datasets using the state.period
• Event information is sent as the events occur (e.g. a process starts or stops).
• All datasets are currently using a poll model to retrieve their data. The frequency of these polls is controlled by the period configuration parameter

Lab Setup

In this article, we’ll need a single-node elastic search cluster(refer to this article for instructions) and two apache webservers. I have used the GCP platform to build my test lab since it offers $300 USD free trial credit but you can do it on your servers or any other public cloud platform as well.

Auditbeat Installation

Note: You’ll need an existing elastic search cluster to store log data and Kibana to visualize this data. We will also need metric beat and filebeat installed on this server.

1. Please read this article to help set up a single-node elastic search instance and Kibana.
2. Please read this article to help set up the metric beat.
3. Please read this article to help set up file beat

We’ll use the APT repository method to install Filebeat.

Installation and configuration of Auditbeat on ELK Server

1. Install Audit beat

apt-get install auditbeat

2. Configure Auditbeat modules

###Auditd module
## Go to identity changes and add following file watches
-w /etc/elasticsearch/elasticsearch.yml -p wa -k elk_changes
-w /etc/kibana/kibana.yml -p wa -k elk_changes
### file_integrity module
/etc/elasticsearch
/etc/kibana
/etc/metricbeat
/etc/metricbeat/modules.d
/etc/filebeat
/etc/filebeat/module.d
/etc/auditbeat
exclude_files:
- '([^\s]+).reference.yml'
### System module
# No change needed

3. Configure Auditbeat general settings

tags: ["elk"]
### Setup dashboards
setup.dashboards.enabled: true
### Kibana
host: "localhost:5601"
### elasticsearch output
hosts: ["localhost:9200"]
protocol: "http"
username: "elastic"
password: "goodwitch"
### logging
logging.to_files: true
logging.files:
path: /var/log/auditbeat
name: auditbeat
keepfiles: 7
permissions: 0644
### setup monitoring through metricbeat
http.enabled: true
http.port: 5068

5. Enable beat-pack if not already enabled

sudo metricbeat modules enable beat-xpack

6. configure beat-expack

sudo nano /etc/metricbeat/modules.d/beat-xpack.yml
hosts: ["http://localhost:5067","http://localhost:5068"]
username: "beats_system"
password: "avatar"

7. Validate metricbeat service is running

systemctl status metricbeat

8. start audit beat

systemctl start auditbeat

10. Stack monitoring

If your audit beat service has been successfully deployed and configured, you should be able to see audit beat come up under stack monitoring-> Beats

11. Dashboards

Finally, you can go to dashboards and check one of the pre-built dashboards for auditbeat

So, here’s how you can configure audit beat to monitor your users and processes.

If you want to do some hands-on practice on Elaticsearch, here is the link to my youtube playlist where I show you how to can set up a lab setup with 2 apache servers feeding data to a single-node Elasticsearch cluster deployed on a google cloud platform or GCP.