Registra todos os comandos executados por administradores em servidores de produção

Question

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

Existe uma maneira de registrar comandos ALL dentro do syslog com algo semelhante à seguinte sintaxe:

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

Um exemplo de entrada seria:

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

Obviamente, não precisa ser exatamente a sintaxe acima, ela só precisa 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 install random-pkg).

Já experimentei snoopy , mas não incluí a variável SUDO_USER .

    

Answer 1

Atualizar : Mais 2 coisas que surgiram nos comentários e em perguntas de acompanhamento:

• Usar auditd dessa maneira aumentará drasticamente seu volume de log, especialmente se o sistema estiver em uso intenso por meio da linha de comando. Ajuste sua política de retenção de log.
• Auditd logs no host onde eles são criados são tão seguros quanto outros arquivos na mesma caixa. Encaminhe seus logs para um servidor de coleta de log remoto, como ELK ou Graylog, para preservar a integridade de seus logs. Além disso, adicionando ao ponto acima, permite excluir de forma mais agressiva os registros 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, para que sua milhagem possa variar em outros sistemas.

• Instale auditd :

  apt-get install auditd

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

  -a exit,always -F arch=b64 -F euid=0 -S execve
  -a exit,always -F arch=b32 -F euid=0 -S execve

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

• Para eliminar as mensagens auid=4294967295 nos logs, adicione audit=1 ao 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 que são relevantes para su ou sudo . Isso permitirá que auditd receba o usuário do chamador uid corretamente ao chamar sudo ou su .

• Reinicie seu sistema agora.

• Vamos fazer login e executar alguns comandos:

    $ id -u
    1000
    $ sudo ls /
    bin  boot  data  dev  etc  home  initrd.img  initrd.img.old  lib  lib32  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  scratch  selinux  srv  sys  tmp  usr  var  vmlinuz  vmlinuz.old
    $ sudo su -
    # ls /etc
    [...]

Isso produzirá algo assim 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 coluna auid contém o usuário chamador uid , que permite filtrar os comandos executados por esse usuário com

 ausearch -ua 1000

Isso até listará os comandos que o usuário executou como root.

Fontes:

• link
• link
• link

Answer 2

Lembre-se que o próprio sudo registra todos os comandos do sudo no syslog, portanto todos os usuários privados devem ser educados para não simplesmente sudo para obter um shell de root, mas para:

sudo command p1 p2 ... pn

O problema com essa ou qualquer outra abordagem em que pensei é que, como o usuário root , é muito difícil impedir que um usuário evite qualquer tipo específico de registro. Assim, qualquer coisa que você tente será < 100%, eu sinto muito em dizer.

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

    

Answer 3

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

Em /root/.bashrc , adicionei a seguinte linha -

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

Assim, todos os usuários que sudos para root terão um arquivo de histórico .bash_history-username.

Outro método -

Adicione o seguinte código a /root/.bashrc e ele adicionará o nome de usuário, sudo-usuário e o comando ao arquivo de log, onde quer que o nível de aviso esteja 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 - link

    

Answer 4

Diversos estabelecimentos realmente proíbem o uso de auditorias porque são intensivas em recursos e podem resultar em uma oportunidade de ataques de negação de serviço.

Uma solução é configurar o shell Korn mais recente (ksh-93, veja link para detalhes) para registrar todos os comandos executados como root em um servidor de syslog remoto e, em seguida, exigir por diretiva que, exceto em situações de emergência, os sysadmins façam logon com contas pessoais e executem o shell Korn aprimorado via sudo. O exame dos logs pode detectar quando um administrador lança outro shell a partir do shell aprovado, a fim de cobrir seus rastros, e o SA pode ser educado conforme necessário.

    

Answer 5

Desde a versão 2.0.0 snoopy é capaz de registrar variáveis ambientais arbitrárias.

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

Divulgação: sou mantenedor do snoopy.

    

Answer 6

O Sudo tem algo chamado sudoreplay quando as sessões ativadas são registradas e podem ser reproduzidas mais tarde funciona como o comando script que faz um datilografado da sessão de terminal que depois pode ser repetido com o comando scriptreplay .

    

Answer 7

Não há nada de errado com nenhuma das outras respostas até agora, mas se você decidir que o log sudo via syslog é satisfatório, posso sugerir um enrugamento: registre-o pela rede em uma auditoria remota host.

Isso contorna o problema de "agora eu me tornei root, posso remover qualquer traço de minha má conduta dos logs". Agora você pode estar root na caixa local, mas não pode chamar esse pacote de log de volta da rede e você (presumivelmente) não tem privilégios de root no host de auditoria remota.

Eu venho fazendo isso com algumas das redes que gerencio há anos e tem 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 juno estava reclamando que o servidor NFS hera não estava respondendo, alguém mais estava reclamando da mesma coisa ao mesmo tempo? Se assim for, hera provavelmente será o problema, vamos ver o que ela registrou; se não, a conexão de rede juno é mais suspeita, vamos ver o que mais juno logou naquele momento. ".

Em segundo lugar, a rotação do log syslog se torna mais fácil: você não mantém cópias de logs em 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 lá por vários dias. anos. Além disso, se, digamos, você quiser gravá-las na mídia WORM para, por exemplo, fins de auditoria forense, você só precisará comprar uma unidade WORM.