Consigner toutes les commandes exécutées par les administrateurs sur les serveurs de production
Les administrateurs ont pour politique de se connecter aux serveurs via un nom d'utilisateur personnel, puis d'exécuter Sudo -i pour devenir root. Lors de l'exécution Sudo -i, Sudo créera une variable d'environnement appelée Sudo_USER, qui contient le nom d'utilisateur de l'utilisateur d'origine.
Existe-t-il un moyen de consigner TOUTES LES COMMANDES dans syslog avec quelque chose qui ressemble à la syntaxe suivante:
${TIME/DATE STAMP}: [${REAL_USER}|${Sudo_USER}]: ${CMD}
Un exemple d'entrée serait:
Sat Jan 19 22:28:46 CST 2013: [root|ksoviero]: yum install random-pkg
De toute évidence, il ne doit pas être exactement la syntaxe ci-dessus, il suffit d'inclure un minimum de l'utilisateur réel (par exemple, root), l'utilisateur de Sudo (par exemple, ksoviero) et la commande complète qui a été exécutée (par exemple, yum installer random-pkg).
J'ai déjà essayé snoopy, mais il n'incluait pas le Sudo_USER variable.
Mise à jour : 2 autres choses qui sont apparues dans les commentaires et les questions de suivi:
- L'utilisation de
auditdde cette façon augmentera considérablement votre volume de journal, surtout si le système est largement utilisé via la ligne de commande. Ajustez votre politique de conservation des journaux. Auditdles journaux sur l'hôte où ils sont créés sont tout aussi sécurisés que les autres fichiers de la même boîte. Transférez vos journaux vers un serveur de collecte de journaux distant comme ELK ou Graylog pour préserver l'intégrité de vos journaux. De plus, en ajoutant au point ci-dessus, il permet de supprimer de manière plus agressive les anciens journaux.
Comme l'a suggéré Michael Hampton, auditd est l'outil approprié pour le travail ici.
J'ai testé cela sur une installation Ubuntu 12.10, donc votre kilométrage peut varier sur d'autres systèmes.
Installez
auditd:apt-get install auditdAjoutez ces 2 lignes à
/etc/audit/audit.rules:-une sortie, toujours -F Arch = b64 -F euid = 0 -S execve - une sortie, toujours -F Arch = b32 -F euid = 0 -S execve
Ceux-ci suivront toutes les commandes exécutées par root (euid=0). Pourquoi deux règles? L'appel système execve doit être suivi à la fois en code 32 et 64 bits.
Se débarrasser de
auid=4294967295messages dans les journaux, ajoutezaudit=1à la ligne de commande du noyau (en modifiant/etc/default/grub)Placer la ligne
session required pam_loginuid.so
dans tous les fichiers de configuration PAM pertinents pour la connexion (/etc/pam.d/{login,kdm,sshd}), mais pas dans les fichiers pertinents pour su ou Sudo. Cela permettra à auditd d'obtenir correctement l'utilisateur uid lors de l'appel de Sudo ou su.
Redémarrez votre système maintenant.
Connectons-nous et exécutons quelques commandes:
$ 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 [...]
Cela produira quelque chose comme ça dans /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)
La colonne auid contient le uid de l'utilisateur appelant, qui vous permet de filtrer les commandes exécutées par cet utilisateur avec
ausearch -ua 1000
Cela répertoriera même les commandes que l'utilisateur a exécutées en tant que root.
Sources:
N'oubliez pas que Sudo lui-même enregistre toutes les commandes Sudo dans le syslog, donc tous les utilisateurs privés doivent être éduqués non seulement à Sudo pour obtenir un shell racine, mais à:
Sudo command p1 p2 ... pn
Le problème avec cette approche ou toute autre approche à laquelle j'ai pensé est qu'en tant qu'utilisateur root, il est assez difficile d'empêcher un utilisateur d'échapper à tout type spécifique de journalisation. Ainsi, tout ce que vous essayerez sera <100%, je suis désolé de le dire.
L'éducation, la documentation, l'application et surtout la confiance sont ce qui est nécessaire.
J'étais une fois confronté au même problème et j'ai dû trouver une solution rapide et sale - chaque utilisateur Sudo aura son propre fichier d'historique une fois qu'il exécutera la commande Sudo -i
Dans /root/.bashrc J'ai ajouté la ligne suivante -
export HISTFILE=/root/.bash_history-$Sudo_USER
export HISTTIMEFORMAT="%F %T "
Ainsi, chaque utilisateur qui fait un root à sudos aura un fichier historique .bash_history-username.
Une autre méthode -
Ajoutez le code suivant à /root/.bashrc et il ajoutera le nom d'utilisateur, Sudo-user et la commande au fichier journal, où que le niveau de notification soit défini, très probablement/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édit à - http://backdrift.org/logging-bash-history-to-syslog-using-traps
Un certain nombre d'établissements interdisent en fait l'utilisation d'Auditd car il consomme beaucoup de ressources et peut entraîner une possibilité d'attaques par déni de service.
Une solution consiste à configurer le dernier shell Korn (ksh-93, voir http://kornshell.com/ pour plus de détails) pour consigner toutes les commandes exécutées en tant que root sur un serveur syslog distant, puis exiger par une politique qui, sauf en cas d'urgence, les administrateurs système se connectent avec des comptes personnels et exécutent le Korn Shell amélioré via Sudo. L'examen des journaux peut détecter lorsqu'un administrateur lance un autre shell à partir du shell approuvé afin de couvrir leurs traces, et le SA peut ensuite être éduqué si nécessaire.
Sudo a quelque chose appelé sudoreplay lorsque les sessions activées sont enregistrées et peuvent être relues plus tard, fonctionne de la même manière que la commande script qui crée un TypeScript de session de terminal qui peut être rejoué plus tard avec le scriptreplay commande.
Non pas qu'il y ait quelque chose de mal avec les autres réponses jusqu'à présent, mais si vous décidez que la journalisation de Sudo via syslog est satisfaisante, puis-je suggérer une ride: connectez-la via le réseau à un hôte d'audit distant .
Cela résout le problème de "maintenant que je suis devenu root, je peux supprimer toute trace de mes malversations des journaux". Vous pouvez maintenant être root sur la boîte locale, mais vous ne pouvez pas rappeler ce paquet de journaux à partir du réseau et vous (sans doute) ne disposez pas des privilèges root sur l'hôte d'audit distant.
Je fais cela avec certains des réseaux que je gère depuis des années, et cela a deux autres avantages de signal:
Tout d'abord, il y a un endroit sur le réseau pour vérifier tous les journaux système, ce qui permet une corrélation beaucoup plus facile des incidents, tout comme un guichet unique pour les enquêtes comme "Quand juno se plaignait que le serveur NFS hera ne répondait pas, quelqu'un d'autre se plaignait-il de la même chose en même temps? Si oui, hera est probablement le problème, voyons ce qu'elle a enregistré; sinon, la connexion réseau de juno est plus suspect, voyons ce que juno a enregistré à ce moment-là. ".
Deuxièmement, la rotation des journaux syslog devient plus facile: vous ne conservez pas de copies des journaux sur les hôtes locaux pendant plus de quelques jours, mais vous vous assurez que le serveur d'audit dispose d'énormes quantités d'espace disque et conservez tous les syslog pendant plusieurs années. De plus, si, par exemple, vous souhaitez les écrire sur des supports WORM, par exemple à des fins d'audit judiciaire, vous ne devez acheter qu'un seul lecteur WORM.
Depuis la version 2.0.0 snoopy est capable d'enregistrer une variable d'environnement arbitraire.
Cependant, une récente contribution a souligné que le propriétaire du journal de tty est une réponse assez efficace et élégante à la question "Qui a exécuté cette commande, en tant que root?".
Divulgation: je suis le mainteneur snoopy.