linux 审计事件未传递至 go-audit

linux 审计事件未传递至 go-audit

我们正在尝试使用 slack 的 go-audit 工具来捕获/处理 Linux 审计事件。更多信息:https://github.com/slackhq/go-audit

问题是 Linux 审计正确地拾取了事件,但 go-audit 没有拾取这些事件,或者 go-audit 没有正确输出这些事件。

示例 go-audit 配置文件已修改为具有单个规则,用于捕获有关文件 /opt/secret.txt 访问的信息

rules:
- -a exit,always -F path=/opt/secret.txt -F perm=wra -k test_changes

完整的 go-audit 配置文件在这里: https://gist.github.com/tom-chaoscube/fc2f14b448650ea4018620bbbf2c3345

运行go-audit后,我们可以看到这条规则已经成功部署:

# auditctl -l
-w /opt/secret.txt -p rwa -k test_changes

尝试访问该文件,在审计日志文件中可以看到一条审计记录:

$ cat secret.txt
# cat /var/log/audit/audit.log

type=SYSCALL msg=audit(1485357520.702:868): arch=c000003e syscall=2 success=yes exit=3 a0=7ffee46830dc a1=0 a2=1fffffffffff0000 a3=7ffee4681670 items=1 ppid=5199 pid=5469 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts5 ses=7 comm="cat" exe="/usr/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="test_changes"
type=CWD msg=audit(1485357520.702:868):  cwd="/opt"
type=PATH msg=audit(1485357520.702:868): item=0 name="secret.txt" inode=26244598 dev=ca:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=unconfined_u:object_r:usr_t:s0 objtype=NORMAL

但是,当查看 go-audit 的输出时,没有记录任何事件。我们尝试将 go-audit 设置为输出到 stdout 以及文件。

在 go-audit 上运行 strace,看起来它正在打开一个 NETLINK 套接字,我认为这是与auditd 的连接。还可以看到,一些数据是通过套接字接收的,与audit.log 中的定期条目一致,但它并没有似乎就像在auditd写入文件访问审核条目时专门接收任何数据一样。 (不一定能明确地说出这一点)。

socket(PF_NETLINK, SOCK_RAW, 9)         = 4
bind(4, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0
setsockopt(4, SOL_SOCKET, SO_RCVBUF, [16384], 4) = 0
getsockopt(4, SOL_SOCKET, SO_RCVBUF, [32768], [4]) = 0
... ...
... ...
write(1, "Started processing events\n", 26) = 26
recvfrom(4, "L\0\0\0\2\0\0\0\1\0\0\0\261\25\0\0\357\377\377\3778\0\0\0\351\3\5\0\1\0\0\0"..., 8970, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 76
futex(0xa0f1d0, FUTEX_WAIT, 0, NULL)    = 0

任何建议:

  • 为什么 go-audit 没有接收到事件?
  • 可以采取进一步的步骤来调查 go-audit 是否确实通过套接字接收事件信息。 (即确定他们不会在审计方面迷失的步骤)

编辑:此后我在 Ubunutu 16.10(以及原始 Centos 7 机器)上本地尝试过此操作,并得到了相同的结果。

干杯。

答案1

解决。

这个问题的答案是auditd 仍在系统上运行。

只需停止auditd并重新启动go-audit即可接收审计数据:

sudo service auditd stop

相关内容