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

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

f:id:yomon8:20180822205841p:plain

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

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

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

はじめに

最初に参考情報ですが、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
    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にイベント入ってきました。

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

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.

例えば [Auditbeat Auditd] Executionsダッシュボードなどは、実行したコマンドが入ってきます。

例えば [Auditbeat Auditd] Socketsダッシュボードでは、Socket経由の接続情報が確認できます。

ここに、Elasticsearch得意の検索機能を組み合わせれば、特定のIPへの接続があった時間や接続数などが一目でわかります。

他にも設定ファイルの変更記録できたり、ユーザーや権限操作を後から追えたり、色々便利そうですが、ここまでにしておきます。

事前定義されているダッシュボードがあると、サービスが何を提供したいのかが良くわかって良いと気づきがありました。他のbeatファミリーも同じような手順でstack-dockerをベースにテストできるので、今度ためしてみます。簡単に試せた割には、なかなか面白い検証でした。

参考URL

Elastic社のDockerデモ群

GitHub - elastic/stack-docker: The Elastic Stack, on Docker, right now.

Elastic社のDockerイメージ一覧

Docker @ Elastic