Suivi des commandes exécutées après sudo vers un autre utilisateur


8

J'ai fourni sudoà dix utilisateurs de devenir un autre utilisateur comme nsup.

Je veux suivre quel utilisateur exécute quelle commande après être devenu nsup. S'il existe un moyen de stocker les fichiers journaux dans un fichier commun, ce serait bien.

J'ai essayé de regarder /var/log/secure, mais à partir de là, je ne peux pas distinguer quel utilisateur a exécuté quelle commande après être devenu nsup. Il montre uniquement quel utilisateur a exécuté la commande pour devenir nsup , et rien au-delà.


2
C'est vrai, si l'on utilise sudo pour ouvrir un nouveau shell, les actions effectuées dans le shell ne sont pas enregistrées. S'il existe un moyen de les enregistrer, je ne m'attends pas à ce que ce soit via sudo. Et je n'ai jamais entendu parler d'une quelconque façon de faire une telle journalisation qui ne soit pas "volontaire" (c'est-à-dire que l'utilisateur ne pouvait pas passer outre). Pour la journalisation "volontaire", vous pouvez écrire un script qui récupère la dernière ligne de / var / log / secure au démarrage d'un shell et combine cela avec l'historique normal du shell. Ou consultez unix.stackexchange.com/questions/6554/…
dubiousjim

Il pourrait aussi y avoir un défaut. Considérez 2 utilisateurs connectés à sametime et ils deviennent des utilisateurs nzsup et commencent à exécuter une commande.Comment trouver quel utilisateur a exécuté quelle commande après avoir été transféré à nzsup.all, la commande exécutée sera dans le fichier historique de nzsup uniquement.
Venom

J'imaginais qu'une session shell déterminerait au début qui était l'utilisateur d'origine. Mais oui, il y aurait une condition de concurrence si deux utilisateurs exécutaient un nouveau shell à la fois. Le fil que j'ai lié à discute d'une autre façon de déterminer qui était l'utilisateur d'origine.
dubiousjim

Réponses:


5

Si vos utilisateurs utilisent bash, vous pouvez utiliser un script /etc/bash.bash_logout pour enregistrer une copie supplémentaire de l'historique au format horodaté.

Par exemple, j'ai écrit ce qui suit pour fournir une piste d'audit de qui a fait quoi et quand (sur un serveur avec plusieurs utilisateurs sudo), et également pour conserver l'historique au cas où la machine serait entrée par effraction:

#! /bin/bash

# /etc/bash.bash_logout
#
# Time-stamped bash history logging
# by Craig Sanders <cas@taz.net.au> 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

1
Qui fonctionne sauf si l'utilisateur définit HISTFILE=/dev/null...
bahamat

1
cela fonctionne indépendamment de ce que l'utilisateur définit HISTFILE. c'était tout l'intérêt de l'écrire. lire le script, history -a "$HISTLOG"ajoute l'historique à $ HISTLOG. n'utilise pas ou ne se soucie pas de $ HISTFILE.
cas

1
alternativement, une version beaucoup plus simple pourrait être mise dans l'utilisateur nsup~/.bash_logout
cas

4
Il convient de mentionner que ce n'est évidemment pas un journal sécurisé. Utilisez des outils d'audit si vous souhaitez une journalisation sécurisée.
Chris Down

Re "HISTTIMEFORMAT semble être buggé" - le format est pour la présentation, pas pour le stockage. Il est utilisé lorsque vous émettez par exemple history 10. Pour le stockage, HISTTIMEFORMAT indique uniquement s'il faut stocker les horodatages (s'ils sont définis sur quelque chose) ou ne pas les stocker du tout (s'ils ne sont pas définis). Les entrées sont uniquement stockées en tant que% s.
kubanczyk

0

J'ai implémenté de cette façon.

dans le fichier rsylog.conf, j'ai ajouté les lignes ci-dessous pour suivre

$umask 0000                 
$FileCreateMode 0666         
local2.info /var/log/usercommands
$umask 0077                 

Dans le fichier /etc/skel/.bashrc, j'ai ajouté des lignes ci-dessous.

entrez la description de l'image ici

J'espère que cela pourrait être utile

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.