eventos de auditoria do Linux não foram passados para ir à auditoria

Question

Estamos tentando usar a ferramenta de auditoria go da slack para capturar / processar eventos de auditoria do Linux. Mais informações: link

A questão é que a auditoria do Linux está pegando eventos corretamente, mas eles não estão sendo selecionados pela auditoria, ou não são corretamente gerados pela auditoria.

O exemplo de arquivo de configuração go-audit foi modificado para ter uma única regra para capturar informações sobre o acesso a um arquivo /opt/secret.txt

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

O arquivo de configuração completo de auditoria está aqui: link

Após a execução da auditoria, podemos ver que essa regra foi implantada com sucesso:

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

Uma tentativa de acessar o arquivo é feita e um registro de auditoria pode ser visto no arquivo de log de auditoria:

$ 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

No entanto, ao analisar a saída da auditoria, nenhum evento é registrado. Nós tentamos ambos com o go-audit set para a saída para stdout, e também para um arquivo.

Executando um strace em go-audit, parece que está abrindo um soquete NETLINK, que eu suponho ser a conexão com o auditd. Também pode ser visto que alguns dados são recebidos sobre o soquete, de acordo com as entradas periódicas no arquivo audit.log, no entanto, não parece como todos os dados sendo recebidos especificamente quando as entradas de auditoria de acesso a arquivos são escritas por auditd. (Não pode necessariamente dizer isso categoricamente).

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
rules:
- -a exit,always -F path=/opt/secret.txt -F perm=wra -k test_changes
# 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
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%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%1%pre%%pre%77778%pre%%pre%%pre%1%pre%%pre%%pre%%pre%"..., 8970, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 76
futex(0xa0f1d0, FUTEX_WAIT, 0, NULL)    = 0
%pre%%pre%%pre%%pre%%pre%1%pre%%pre%77778%pre%%pre%%pre%1%pre%%pre%%pre%%pre%"..., 8970, 0, {sa_family=AF_NETLINK, pid=0, groups=00000000}, [12]) = 76
futex(0xa0f1d0, FUTEX_WAIT, 0, NULL)    = 0

Sugestões para:

• Por que a auditoria não está captando os eventos?
• Outras etapas que podem ser tomadas para investigar se o go-audit realmente está recebendo as informações do evento no soquete. (Isto é, passos para estabelecer que eles não estão se perdendo do lado da auditoria)

Edit: Eu já tentei isso localmente no Ubunutu 16.10 (assim como a máquina original do Centos 7), e tenho os mesmos resultados.

Felicidades.

    

Answer 1

Resolvido.

A resposta para este problema é que o auditd ainda estava rodando nos sistemas.

Parar simplesmente o auditd e reiniciar o go-audit permitiu que os dados de auditoria fossem recebidos:

sudo service auditd stop