0

我正在尝试将与我的 CentOS 7 相关的身份验证发送到 Elasticsearch。奇怪的是，我没有收到任何身份验证事件。

当我运行调试命令 auditbeat -c auditbeat.conf -d -e "*"时，我发现如下内容：

 {
      "@timestamp": "2019-01-15T11:54:37.246Z",
      "@metadata": {
        "beat": "auditbeat",
        "type": "doc",
        "version": "6.4.0"
      },
      "error": {
        "message": "failed to set audit PID. An audit process is already running (PID 68504)"
      },
      "beat": {
        "name": "env-cs-westus-devtest-66-csos-logs-es-master-0",
        "hostname": "env-cs-westus-devtest-66-csos-logs-es-master-0",
        "version": "6.4.0"
      },
      "host": {
        "name": "env-cs-westus-devtest-66-csos-logs-es-master-0"
      },
      "event": {
        "module": "auditd"
      }
    }

还有如下错误行：

Failure receiving audit events {"error": "failed to set audit PID. An audit process is already running (PID 68504)"}

机器细节

NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

Audibeat 配置文件

#================================ General ======================================
fields_under_root: False
queue:
  mem:
    events: 4096
    flush:
      min_events: 2048
      timeout: 1s
max_procs: 1
max_start_delay: 10s
#================================= Paths ======================================
path:
  home: "/usr/share/auditbeat"
  config: "/etc/auditbeat"
  data: "/var/lib/auditbeat"
  logs: "/var/log/auditbeat/auditbeat.log"
#============================  Config Reloading ================================
config:
  modules:
    path: ${path.config}/conf.d/*.yml
    reload:
      period: 10s
      enabled: False
#==========================  Modules configuration =============================
auditbeat.modules:
#----------------------------- Auditd module -----------------------------------
- module: auditd
  resolve_ids: True
  failure_mode: silent
  backlog_limit: 8196
  rate_limit: 0
  include_raw_message: True
  include_warnings: True
  audit_rules: |
    -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
    -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 always,exit -F dir=/home -F uid=0 -F auid>=1000 -F auid!=4294967295 -C auid!=obj_uid -F key=power-abuse
    -a always,exit -F arch=b64 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=elevated-privs
    -a always,exit -F arch=b32 -S setuid -F a0=0 -F exe=/usr/bin/su -F key=elevated-privs
    -a always,exit -F arch=b64 -S setresuid -F a0=0 -F exe=/usr/bin/sudo -F key=elevated-privs
    -a always,exit -F arch=b32 -S setresuid -F a0=0 -F exe=/usr/bin/sudo -F key=elevated-privs
    -a always,exit -F arch=b64 -S execve -C uid!=euid -F euid=0 -F key=elevated-privs
    -a always,exit -F arch=b32 -S execve -C uid!=euid -F euid=0 -F key=elevated-privs
#----------------------------- File Integrity module -----------------------------------
- module: file_integrity
  paths:
    - /bin
    - /usr/bin
    - /sbin
    - /usr/sbin
    - /etc
    - /home/jenkins
  exclude_files:
    - (?i)\.sw[nop]$
    - ~$
    - /\.git($|/)
  scan_at_start: True
  scan_rate_per_sec: 50 MiB
  max_file_size: 100 MiB
  hash_types: [sha1]
  recursive: False
#================================ Outputs ======================================
#-------------------------- Elasticsearch output -------------------------------
output.elasticsearch:
  enabled: True
  hosts:
    - x.x.x:9200
  compression_level: 0
  protocol: "http"
  worker: 1
  bulk_max_size: 50
  timeout: 90
#================================ Logging ======================================
logging:
  level: "info"
  selectors: ["*"]
  to_syslog: False
  to_eventlog: False
  metrics:
    enabled: True
    period: 30s
  to_files: True
  files:
    path: /var/log/auditbeat
    name: "auditbeat"
    rotateeverybytes: 10485760
    keepfiles: 7
    permissions: 0600
  json: False

Auditbeat 版本auditbeat 6.4.0 (amd64)、libbeat 6.4.0

有没有人遇到过类似的问题并得到解决方案？

注意： auditbeat 的此配置成功捕获了 Ubuntu 的身份验证事件

4

1 回答 1

0

所以我在 Elastic beats 论坛上发布了同样的内容并得到了解决方案。你可以在这里找到相同的

根据他们的建议，关闭 auditd 服务将允许 Audibeat 捕获 Audit 事件。我尝试了同样的方法，它对我有用。但我不确定关闭 auditd 的含义。所以我可能会切换到基于 Filebeat 的解决方案。

于 2019-01-19T10:13:02.863 回答