Criação de log remota de criação de usuário

Question

Estou tentando centralizar logs de diferentes servidores para um servidor.

Posso centralizar as informações de registro por meio da adição de auth.* @server_ip:port em /etc/rsyslog.conf dos clientes, mas agora não recupero as informações de registro de criação de usuários. No entanto, esses logs estão em /var/log/auth.log .

Exemplo:

Jun  1 09:46:20 host sshd[12867]: Accepted password for adminelk from 10.0.0.2 port 63676 ssh2
Jun  1 09:46:20 host sshd[12867]: pam_unix(sshd:session): session opened for user adminelk by (uid=0)
Jun  1 09:46:26 host su[12879]: Successful su for root by adminelk
Jun  1 09:46:26 host su[12879]: + /dev/pts/0 adminelk:root
Jun  1 09:46:26 host su[12879]: pam_unix(su:session): session opened for user root by adminelk(uid=1000)
Jun  1 10:17:01 host CRON[12951]: pam_unix(cron:session): session opened for user root by (uid=0)
Jun  1 10:17:01 host CRON[12951]: pam_unix(cron:session): session closed for user root
Jun  1 10:17:01 host groupadd[12955]: group added to /etc/group: name=johnny, GID=1002
Jun  1 10:17:01 host groupadd[12955]: group added to /etc/gshadow: name=johnny
Jun  1 10:17:01 host groupadd[12955]: new group: name=johnny, GID=1002
Jun  1 10:17:01 host useradd[12959]: new user: name=johnny, UID=1004, GID=1002, home=/home/johnny, shell=/bin/bash
Jun  1 10:17:05 host passwd[12966]: pam_unix(passwd:chauthtok): password changed for johnny
Jun  1 10:17:08 host chfn[12967]: changed user 'johnny' information

Eu posso recuperar logs do sshd, mas não logs do useradd ...

Como posso recuperar esses registros?

    

Answer 1

TL; DR

Use auth,authpriv.* @server_ip:port

Detalhes

Você está usando a instalação errada resp. nem todas as instalações corretas.

Para analisar o comportamento que eu executo

journalctl -o verbose -t useradd -t groupadd -t passwd -f

em uma janela e fez

adduser foo

em outro (ambos como root ).

journald intercepta mensagens syslog (locais) que podem ser visualizadas com journalctl . O último permite vários formatos de saída, um dos quais é detalhado com todos os campos de mensagens do syslog .

A saída foi algo como:

Wed 2018-06-06 21:05:22.618392 CEST  [...]
    ...
    PRIORITY=6
    SYSLOG_FACILITY=10
    ...
    SYSLOG_IDENTIFIER=groupadd
    ...
    MESSAGE=group added to /etc/group: name=foo, GID=1004
Wed 2018-06-06 21:05:22.630643 CEST [...]
    ...
    PRIORITY=6
    SYSLOG_FACILITY=10
    ...
    SYSLOG_IDENTIFIER=groupadd
    ...
    MESSAGE=group added to /etc/gshadow: name=foo
    ...
Wed 2018-06-06 21:05:22.631667 CEST [...]
    ...
    PRIORITY=6
    SYSLOG_FACILITY=10
    ...
    SYSLOG_IDENTIFIER=groupadd
    ...
    MESSAGE=new group: name=foo, GID=1004
    ...
Wed 2018-06-06 21:05:22.635070 CEST [...]
    ...
    PRIORITY=6
    SYSLOG_FACILITY=10
    ...
    SYSLOG_IDENTIFIER=useradd
    ...
    MESSAGE=new user: name=foo, UID=1002, GID=1004, home=/home/foo, shell=/bin/bash
    ...
Wed 2018-06-06 21:05:22.699151 CEST [...]
    PRIORITY=4
    ...
    SYSLOG_FACILITY=10
    ...
    SYSLOG_IDENTIFIER=passwd
    MESSAGE=pam_ecryptfs: PAM passphrase change module retrieved a NULL passphrase; nothing to do
    ...

Como podemos ver aqui, o SYSLOG_FACILITY é 10 para todas essas mensagens. Isso não é auth mas authpriv .

Na verdade, minha configuração rsyslog contém a linha

auth,authpriv.* /var/log/auth.log

no arquivo /etc/rsyslog.d/50-default.conf .

Então, minha sugestão é usar

auth,authpriv.*     @server_ip:port

para não apenas encaminhar auth mensagens, mas também authpriv mensagens.