Registrar todos os comandos executados pelos administradores nos servidores de produção

É política da empresa que os administradores façam login nos servidores por meio de um nome de usuário pessoal e depois executem sudo -ipara se tornarem root. Ao executar sudo -i, o sudo criará uma variável ambiental chamada SUDO_USER, que contém o nome de usuário do usuário original.

Existe uma maneira de registrar TODOS os comandos no syslog com algo semelhante à seguinte sintaxe:

${TIME/DATE STAMP}: [${REAL_USER}|${SUDO_USER}]: ${CMD}

Uma entrada de exemplo seria:

Sat Jan 19 22:28:46 CST 2013: [root|ksoviero]: yum install random-pkg

Obviamente, não precisa ser exatamente a sintaxe acima, apenas deve incluir um mínimo do usuário real (por exemplo, root), o usuário sudo (por exemplo: ksoviero) e o comando completo que foi executado (por exemplo, yum instale o random-pkg).

Eu já tentei snoopy, mas não incluiu a SUDO_USERvariável.

Atualização : mais duas coisas que apareceram nos comentários e nas perguntas seguintes:

• O uso auditddessa maneira aumentará drasticamente seu volume de log, especialmente se o sistema estiver em uso intenso via linha de comando. Ajuste sua política de retenção de log.
• Auditdos logs no host em que são criados são tão seguros quanto outros arquivos na mesma caixa. Encaminhe seus logs para um servidor remoto de coleta de logs, como ELK ou Graylog, para preservar a integridade dos logs. Além disso, acrescentando ao ponto acima, ele permite excluir mais agressivamente os logs antigos.

Como foi sugerido por Michael Hampton, auditdé a ferramenta correta para o trabalho aqui.

Eu testei isso em uma instalação do Ubuntu 12.10, então sua milhagem pode variar em outros sistemas.

• Instalar auditd:

  apt-get install auditd

• Adicione estas 2 linhas a /etc/audit/audit.rules:

  -a saída, sempre -F arch = b64 -F euid = 0 -S execve
  -a saída, sempre -F arch = b32 -F euid = 0 -S execve

Eles rastrearão todos os comandos executados por root ( euid=0). Por que duas regras? O execvesyscall deve ser rastreado no código de 32 e 64 bits.

• Para se livrar das auid=4294967295mensagens nos logs, adicione audit=1ao cmdline do kernel (editando /etc/default/grub)

• Coloque a linha

  session required pam_loginuid.so

em todos os arquivos de configuração do PAM relevantes para o login ( /etc/pam.d/{login,kdm,sshd}), mas não nos arquivos relevantes para suou sudo. Isso permitirá auditdobter o usuário que está uidchamando corretamente ao ligar sudoou su.

• Reinicie seu sistema agora.

• Vamos entrar e executar alguns comandos:

    $ id -u
    1000
    $ sudo ls /
    bin boot data dev etc home initrd.img initrd.img.old lib lib32 lib64 perdido + encontrado mídia mnt opt ​​proc root executar sbin scratch selinux srv sys tmp usr var vmlinuz vmlinuz.old
    $ sudo su -
    # ls / etc
    [...]

Isso produzirá algo como isto em /var/log/audit/auditd.log:

----
time->Mon Feb  4 09:57:06 2013
type=PATH msg=audit(1359968226.239:576): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968226.239:576): item=0 name="/bin/ls" inode=2117 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968226.239:576):  cwd="/home/user"
type=EXECVE msg=audit(1359968226.239:576): argc=2 a0="ls" a1="/"
type=SYSCALL msg=audit(1359968226.239:576): arch=c000003e syscall=59 success=yes exit=0 a0=10cfc48 a1=10d07c8 a2=10d5750 a3=7fff2eb2d1f0 items=2 ppid=26569 pid=26570 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" key=(null)
----
time->Mon Feb  4 09:57:06 2013
type=PATH msg=audit(1359968226.231:575): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968226.231:575): item=0 name="/usr/bin/sudo" inode=530900 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968226.231:575):  cwd="/home/user"
type=BPRM_FCAPS msg=audit(1359968226.231:575): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=ffffffffffffffff new_pi=0000000000000000 new_pe=ffffffffffffffff
type=EXECVE msg=audit(1359968226.231:575): argc=3 a0="sudo" a1="ls" a2="/"
type=SYSCALL msg=audit(1359968226.231:575): arch=c000003e syscall=59 success=yes exit=0 a0=7fff327ecab0 a1=7fd330e1b958 a2=17cc8d0 a3=7fff327ec670 items=2 ppid=3933 pid=26569 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.523:578): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.523:578): item=0 name="/bin/su" inode=44 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.523:578):  cwd="/home/user"
type=EXECVE msg=audit(1359968229.523:578): argc=2 a0="su" a1="-"
type=SYSCALL msg=audit(1359968229.523:578): arch=c000003e syscall=59 success=yes exit=0 a0=1ceec48 a1=1cef7c8 a2=1cf4750 a3=7fff083bd920 items=2 ppid=26611 pid=26612 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="su" exe="/bin/su" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.519:577): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.519:577): item=0 name="/usr/bin/sudo" inode=530900 dev=08:01 mode=0104755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.519:577):  cwd="/home/user"
type=BPRM_FCAPS msg=audit(1359968229.519:577): fver=0 fp=0000000000000000 fi=0000000000000000 fe=0 old_pp=0000000000000000 old_pi=0000000000000000 old_pe=0000000000000000 new_pp=ffffffffffffffff new_pi=0000000000000000 new_pe=ffffffffffffffff
type=EXECVE msg=audit(1359968229.519:577): argc=3 a0="sudo" a1="su" a2="-"
type=SYSCALL msg=audit(1359968229.519:577): arch=c000003e syscall=59 success=yes exit=0 a0=7fff327ecab0 a1=7fd330e1b958 a2=17cc8d0 a3=7fff327ec670 items=2 ppid=3933 pid=26611 auid=1000 uid=1000 gid=1000 euid=0 suid=0 fsuid=0 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1 comm="sudo" exe="/usr/bin/sudo" key=(null)
----
time->Mon Feb  4 09:57:09 2013
type=PATH msg=audit(1359968229.543:585): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968229.543:585): item=0 name="/bin/bash" inode=6941 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968229.543:585):  cwd="/root"
type=EXECVE msg=audit(1359968229.543:585): argc=1 a0="-su"
type=SYSCALL msg=audit(1359968229.543:585): arch=c000003e syscall=59 success=yes exit=0 a0=13695a0 a1=7fffce08a3e0 a2=135a030 a3=7fffce08c200 items=2 ppid=26612 pid=26622 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="bash" exe="/bin/bash" key=(null)
----
time->Mon Feb  4 09:57:11 2013
type=PATH msg=audit(1359968231.663:594): item=1 name=(null) inode=668682 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=PATH msg=audit(1359968231.663:594): item=0 name="/bin/ls" inode=2117 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00
type=CWD msg=audit(1359968231.663:594):  cwd="/root"
type=EXECVE msg=audit(1359968231.663:594): argc=3 a0="ls" a1="--color=auto" a2="/etc"
type=SYSCALL msg=audit(1359968231.663:594): arch=c000003e syscall=59 success=yes exit=0 a0=7fff8c709950 a1=7f91a12149d8 a2=1194c50 a3=7fff8c709510 items=2 ppid=26622 pid=26661 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="ls" exe="/bin/ls" key=(null)

A auidcoluna contém o usuário que está chamando uid, o que permite filtrar os comandos executados por esse usuário com

 ausearch -ua 1000

Isso lista os comandos que o usuário executou como root.

Fontes:

• http://www.woitasen.com.ar/2011/11/auditing-user-actions-after-sudo/
• http://linux.die.net/man/8/pam_loginuid
• http://linux.die.net/man/8/auditd

Lembre-se de que o próprio sudo registra todos os comandos sudo no syslog; portanto, todos os usuários privados devem ser instruídos a não apenas sudo para obter um shell raiz, mas para:

sudo command p1 p2 ... pn

O problema com esta ou qualquer outra abordagem em que pensei é que, como rootusuário, é bastante difícil impedir que um usuário evite qualquer tipo específico de log. Portanto, qualquer coisa que você tentar será <100%, lamento dizer.

Educação, documentação, fiscalização e, acima de tudo, confiança é o que é necessário.

Uma vez fui confrontado com o mesmo problema e tive que encontrar uma solução rápida e suja - cada usuário sudo terá seu próprio arquivo de histórico assim que executar o comando sudo -i

Em /root/.bashrceu adicionei a seguinte linha -

 export HISTFILE=/root/.bash_history-$SUDO_USER
 export HISTTIMEFORMAT="%F %T "

Portanto, todo usuário que deseja fazer o root terá um arquivo de histórico .bash_history-username.

Outro método -

Adicione o código a seguir /root/.bashrce ele acrescentará o nome de usuário, sudo-user e o comando ao arquivo de log, sempre que o nível de aviso estiver definido, provavelmente / var / log / messages.

function log2syslog
{
   declare COMMAND
   COMMAND=$(fc -ln -0)
   logger -p local1.notice -t bash -i -- "${USER}:${SUDO_USER}:${COMMAND}"
}
trap log2syslog DEBUG

Crédito para - http://backdrift.org/logging-bash-history-to-syslog-using-traps

Na verdade, vários estabelecimentos proíbem o uso do auditd, pois consome muitos recursos e pode resultar em uma oportunidade para ataques de negação de serviço.

Uma solução é configurar o shell Korn mais recente (ksh-93, consulte http://kornshell.com/ para obter detalhes) para registrar todos os comandos executados como raiz em um servidor syslog remoto e, em seguida, exigir pela política que, exceto em situações de emergência situações, os administradores de sistema efetuam logon com contas pessoais e executam o shell Korn aprimorado via sudo. O exame dos logs pode detectar quando um administrador lança outro shell do shell aprovado para cobrir seus rastros, e a SA pode ser instruída conforme necessário.

O Sudo tem algo chamado sudoreplay quando as sessões ativadas são registradas e podem ser reproduzidas mais tarde, funciona de forma semelhante ao scriptcomando que cria um texto datilografado da sessão do terminal que posteriormente pode ser reproduzido com o scriptreplaycomando.

Não que exista algo errado com qualquer uma das outras respostas até agora, mas se você decidir que sudoo registro via syslogé satisfatório, posso sugerir uma ruga: registre-o pela rede em um host de auditoria remota.

Isso contorna o problema de "agora que me tornei root, posso remover qualquer vestígio de minha violação" dos logs ". Agora você pode ser root na caixa local, mas não pode chamar esse pacote de log da rede e você (presumivelmente) não possui privilégios de root no host de auditoria remota.

Venho fazendo isso com algumas das redes que gerencio há anos, e há outras duas vantagens de sinal:

Em primeiro lugar, há um lugar na rede para verificar todos os syslogs, o que permite uma correlação muito mais fácil de incidentes, assim como um balcão único para investigações como "Quando junoestava reclamando que o servidor NFS heranão estava respondendo, havia mais alguém reclamando sobre a mesma coisa ao mesmo tempo? Se sim, heraé provável que seja o problema, vamos ver o que ela registrou; caso contrário, junoa conexão de rede é mais suspeita, vamos ver o que mais junoregistrou naquele momento. ".

Em segundo lugar, a rotação de logs do syslog se torna mais fácil: você não mantém cópias dos logs nos hosts locais por mais de alguns dias, mas garante que o servidor de auditoria tenha grandes quantidades de espaço em disco e mantenha todos os syslogs por vários anos. Além disso, se, digamos, você desejar gravá-los na mídia WORM para, por exemplo, fins de auditoria forense, você precisará comprar apenas uma unidade WORM.

Desde a versão 2.0.0, o snoopy pode registrar variáveis ​​de ambiente arbitrárias.

No entanto, uma contribuição recente apontou que o proprietário do log do tty é uma resposta bastante eficaz e elegante à pergunta "Quem executou esse comando como root?".

Divulgação: Eu sou mantenedor do Snoopy.