Elastic StackのAuditbeatで何ができるのかDockerでさくっと確認してみる

別件で調べていたところ掲題のツール見つけました。 Filebeatって色々種類あるんですね。

f:id:yomon8:20180822205841p:plain

特に個人的に心を惹かれた監査データ用のモジュールAuditbeatを試してみました。

監査データのための軽量シッパー | Elastic

Linuxの監査フレームワークデータを収集し、ファイルの整合性を監視します。Auditbeatからリアルタイムで送信されるイベント情報に基づいて、Elastic Stackがさらに分析を進めます。

はじめに
設定・準備
- auditbeat.yml
  - ソース
  - 補足
- start.sh
  - ソース
  - 補足
- docker-compose.yml|
  - ソース
  - 補足
docker-composeでコンテナ起動
Kibanaのダッシュボード
参考URL
- Elastic社のDockerデモ群
- Elastic社のDockerイメージ一覧

はじめに

最初に参考情報ですが、Elastic Stackのデモ環境は以下のリポジトリにまとめられていて、docker-composeで起動して試せます。

github.com

個人的理解力の無さから、全部入りだと設定や動かし方よくわからないので、今回はここから、目的のAuditbeatを抜き出して設定作ります。

設定・準備

以下の3ファイルを準備します。

ファイル名	内容
auditbeat.yml	Auditbeatの設定ファイル
start.sh	ElasticsearchとKibana起動後にAuditbeat起動するためのスクリプト
docker-compose.yml	docker-compose定義ファイル

auditbeat.yml

ソース

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
- module: file_integrity
  paths:
  - /bin
  - /usr/bin
  - /sbin
  - /usr/sbin
  - /etc

setup.dashboards.enabled: true

setup.kibana:
  host: "kibana:5601"

output.elasticsearch:
  hosts: ["elasticsearch:9200"]

補足

Auditbeatにはauditdとfile_integrityというモジュールがありますので、それぞれの設定を定義しています。

auditbeat.modules:
- module: auditd
# 省略....
- module: file_integrity

それぞれ詳細はこちら。

auditd

https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-module-auditd.html

file_integrity

https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-module-file_integrity.html

このパラメータをtrueとすると、auditbeatで事前定義されているダッシュボードがKibanaに登録されます。

setup.dashboards.enabled: true

https://www.elastic.co/guide/en/beats/filebeat/current/configuration-dashboards.html

Kibanaと出力先としてのelasticsearchの宛先を定義します。

setup.kibana:
  host: "kibana:5601"

output.elasticsearch:
  hosts: ["elasticsearch:9200"]

他の設定情報が知りたい場合はこのあたりを確認してみるとわかります。

https://github.com/elastic/beats/blob/v6.3.2/auditbeat/auditbeat.yml

start.sh

Kibanaの起動を待ってからAuditbeatを起動する簡単な処理を作ります。

ソース

#!/bin/bash

set -euo pipefail

until curl -s -k http://kibana:5601; do
  echo "Waiting for kibana..."
  sleep 5
done
sleep 5

exec auditbeat -e --strict.perms=false

補足

dockerでマウントした際に以下のようにユーザ権限チェックにひっかかってしまうので、 strict.perms=false のオプションを付けて、auditbeatを起動します。

error loading config file: config file ("auditbeat.yml") must be owned by the beat user (uid=0) or root

exec auditbeat -e --strict.perms=false

参考情報はこちら。

https://www.elastic.co/guide/en/beats/libbeat/current/config-file-permissions.html#_disabling_strict_permission_checks

docker-compose.yml|

ではelasticsearch・kibana・auditbeatの3つのコンテナを起動するdocker-composeの定義を作ります。

ソース

version: '3.6'

services:

  elasticsearch:
    container_name: elasticsearch
    image: docker.elastic.co/elasticsearch/elasticsearch:6.3.2
    environment:
      discovery.type: single-node

  kibana:
    container_name: kibana
    image: docker.elastic.co/kibana/kibana:6.3.2
    depends_on:
      - elasticsearch
    ports:
      - 5601:5601

  auditbeat:
    container_name: auditbeat
    image: docker.elastic.co/beats/auditbeat:6.3.2
    command: ['/bin/bash', '/usr/local/bin/start.sh' ]
    pid: host
    cap_add: 
      - AUDIT_CONTROL
      - AUDIT_READ
    depends_on:
      - elasticsearch
      - kibana
    volumes: 
      - ./auditbeat.yml:/usr/share/auditbeat/auditbeat.yml
      - ./start.sh:/usr/local/bin/start.sh

補足

あまり普段のdocker-composeの設定で見ないのは以下の2つかと思います。

    pid: host

コンテナ内でホスト側の PID 名前空間を使う設定です。

詳細はこのあたり。

https://docs.docker.com/engine/reference/run/#pid-equivalent

cap_add

    cap_add: 
      - AUDIT_CONTROL
      - AUDIT_READ

許可するLinuxのcapabilitiesを指定しています。詳細はこのあたり。

https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities

docker-composeでコンテナ起動

これで準備できました。

$ ls -1
auditbeat.yml
docker-compose.yml
start.sh

docker-composeをバックグラウンドで起動します。

$ docker-compose up -d
Starting elasticsearch ... done
Starting kibana        ... done
Starting auditbeat     ... done

auditbeatのログ見てエラーが発生してないか確認します。

$ docker-compose logs -f auditbeat

Kibanaのダッシュボード

少ししたらKibanaにアクセスしてみます。

http://localhost:5601/app/kibana

試しにwhoamiを何回も打ってみます。

$ for i in $(seq 1 10);do whoami;done

Discoveryにイベント入ってきました。

今度はテストユーザ作ってみます。

sudo useradd testuser1

これも、Discoveryにイベント入ってきました。

以下の４つのダッシュボードがデフォルトで定義されていました。

Name	Description
[Auditbeat Auditd] Executions	-
[Auditbeat Auditd] Overview	Summary of Linux kernel audit events.
[Auditbeat Auditd] Sockets	Summary of socket related syscall events.
[Auditbeat File Integrity]	OverviewMonitor file integrity events.