Rastreando quais comandos foram executados após o sudo para outro usuário

Eu forneci sudoa dez usuários para se tornar outro usuário como nsup.

Quero rastrear qual usuário executa qual comando depois que eles se tornam nsup. Se houver uma maneira de armazenar os arquivos de log em um arquivo comum, isso seria ótimo.

Eu tentei olhar /var/log/secure, mas a partir daí não consigo distinguir qual usuário executou qual comando depois que se tornou nsup. Ele mostra apenas qual usuário executou o comando para se tornar nsup e nada além disso.

sudo monitoring Veneno
fonte

É isso mesmo, se alguém usar o sudo para abrir um novo shell, as ações executadas no shell não serão registradas. Se houver uma maneira de registrá-los, não espero que seja através do sudo. E nunca ouvi falar de nenhuma maneira de fazer esse registro que não seja "voluntário" (ou seja, que o usuário não possa substituir). Para o registro "voluntário", você pode escrever um script que pegue a última linha de / var / log / secure quando um shell iniciar e combine isso com o histórico normal do shell. Ou consulte unix.stackexchange.com/questions/6554/…

dubiousjim

Também pode haver falha. Considere 2 usuários logados no sametime e eles se tornarão usuários do nzsup e começarão a executar algum comando.

Venom

Eu estava imaginando que uma sessão de shell determinaria apenas no início quem era o usuário original. Mas sim, haveria uma condição de corrida se dois usuários usassem um novo shell ao mesmo tempo. O tópico ao qual vinculei discute outra maneira de determinar quem era o usuário original.

dubiousjim

Se seus usuários usam o bash, você pode usar um script /etc/bash.bash_logout para salvar uma cópia extra do histórico no formato de carimbo de data / hora.

Por exemplo, escrevi o seguinte para fornecer uma trilha de auditoria de quem fez o quê e quando (em um servidor com vários usuários do sudo) e também para preservar o histórico caso a máquina seja invadida:

#! /bin/bash

# /etc/bash.bash_logout
#
# Time-stamped bash history logging
# by Craig Sanders <[email protected]> 2008
#
# This script is public domain.  Do whatever you want with it.

exec >& /dev/null

# LOGDIR must already exist and must be mode 1777 (same as /tmp)
# put it somewhere easily overlooked by script-kiddies.  /var/log 
# is a bad location because slightly-brighter-than-average SK's will
# often 'rm -rf /var/log' to cover their tracks.
LOGDIR='/var/tmp/.history'

[ -d "$LOGDIR" ] || exit 0

# Get current user name and who they logged in as.
CNAME=$(id -u -n)
LNAME=$(who am i | awk '{print $1}')
NAME="$LNAME--$CNAME"

# Get the TTY
TTY=$(tty)

# get the hostname and ip they logged in from
# short (non-fqdn) hostname:
RHOST_NAME=$(who -m  | awk '{print $5}' | sed -r -e 's/[()]|\..*//g')
# or full hostname:
#RHOST_NAME=$(who -m  | awk '{print $5}' | sed -r -e 's/[()]//g')

# if no RHOST_NAME, then login was on the console.
echo "$RHOST_NAME" | grep -q '[:/]' && RHOST_NAME="console"

# get the IP address
RHOST_IP=$(who -m --ips | awk '{print $5}')
echo "$RHOST_IP" | grep -q '[:/]' && RHOST_IP="console"

RHOST=$(echo "$RHOST_NAME--$RHOST_IP")

WHERE="$RHOST--$TTY"
WHERE=$(echo "$WHERE" | sed -e 's/\//-/g' -e 's/^-//')

# Filenames will be of the form:
# $LOGDIR/cas--root--localhost--127.0.0.1---dev-pts-1
# Ugly, but useful/informative. This example shows I logged in as cas
# from localhost, sudo-ed to root, and my tty was /dev/pts/1
HISTLOG="$LOGDIR/$NAME--$WHERE"


# Optionally rotate HISTLOG on each logout, otherwise new history
# sessions just get appended.
#[ -e "$HISTLOG" ] && savelog -l -c 21 -q $HISTLOG > /dev/null 2>&1

# Log some easily parseable info as a prelude, including the current
# history settings (an unusual HISTFILE or zero HISTSIZE setting is
# suspicious and worthy of investigation)

cat <<__EOF__ >> "$HISTLOG"

### TIME ### $(date +'%a,%Y-%m-%d,%H:%M:%S')
### FROM ### $RHOST_NAME,$RHOST_IP,$TTY
### USER ### $LNAME,$CNAME
### WHOM ### $(who -m)
### HIST ### $HISTFILE,$HISTSIZE

__EOF__


# Setting HISTTIMEFORMAT seems to be buggy. bash man page says it uses
# strftime, but all it seems to care about is whether it's set or not -
# 'history -a' always uses seconds since epoch, regardless of what it is
# set to.

HISTTIMEFORMAT="%s"
history -a "$HISTLOG"


# Now write history as normal (this seems buggy too. bash used to always
# write $HISTFILE anyway, but now it won't do it if you've already run
# 'history -a')

unset HISTTIMEFORMAT
history -w

cas
fonte

O que funciona, a menos que o usuário defina HISTFILE=/dev/null...

bahamat

funciona independentemente do que o usuário define HISTFILE. esse era o objetivo de escrevê-lo. leia o script, history -a "$HISTLOG"anexa o histórico a $ HISTLOG. não usa nem se preocupa com $ HISTFILE.

cas

alternativamente, uma versão muito mais simples pode ser colocada nos nsup dos usuários~/.bash_logout

cas

Deve-se mencionar que esse obviamente não é um log seguro. Use as ferramentas de auditoria se você desejar um log seguro.

21413 Chris Down

Re "HISTTIMEFORMAT parece estar com erros" - o formato é para apresentação, não para armazenamento. É usado quando você emite, por exemplo history 10. Para armazenamento, o HISTTIMEFORMAT diz apenas se os registros de data e hora (se configurados para algo) devem ser armazenados ou se não são armazenados (se não estiverem definidos). As entradas são armazenadas apenas como% s.

precisa saber é o seguinte

Rastreando quais comandos foram executados após o sudo para outro usuário

Respostas: