Consigner toutes les commandes exécutées par les administrateurs sur des serveurs de production

Les administrateurs ont pour politique de se connecter aux serveurs via un nom d'utilisateur personnel, puis de s'exécuter sudo -ipour 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 une syntaxe proche de 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

Évidemment, il ne doit pas nécessairement s'agir de la syntaxe ci-dessus, il faut simplement inclure un minimum d'utilisateurs réels (par exemple, root), d'utilisateur sudo (par exemple, ksoviero) et de la commande complète qui a été exécutée (par exemple, yum installer random-pkg).

J'ai déjà essayé snoopy, mais cela n'incluait pas la SUDO_USERvariable.

Mise à jour : 2 autres choses qui sont apparues dans les commentaires et les questions suivantes:

• L'utilisation de auditdcette méthode augmentera considérablement le volume de votre journal, en particulier si le système est fortement utilisé via la ligne de commande. Ajustez votre stratégie de conservation des journaux.
• AuditdLes journaux de l'hôte sur lequel ils sont créés sont 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 tel qu'ELK ou Graylog afin de préserver l'intégrité de vos journaux. De plus, en ajoutant au point ci-dessus, cela permet de supprimer de manière plus agressive les anciens journaux.

Comme suggéré par Michael Hampton, auditdest le bon outil pour le travail ici.

J'ai testé cela sur une installation Ubuntu 12.10, de sorte que votre kilométrage peut varier sur d'autres systèmes.

• Installer auditd:

  apt-get install auditd

• Ajoutez ces 2 lignes à /etc/audit/audit.rules:

  -a une sortie, toujours -F arch = b64 -F euid = 0 -S execve
  -a 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' execveappel système doit être suivi dans les codes 32 et 64 bits.

• Pour supprimer les auid=4294967295messages dans les journaux, ajoutez audit=1à la cmdline du noyau (en la modifiant /etc/default/grub)

• Placez la ligne

  session required pam_loginuid.so

dans tous les fichiers de configuration PAM pertinents pour login ( /etc/pam.d/{login,kdm,sshd}), mais pas dans les fichiers pertinents pour suou sudo. Cela permettra auditdd’obtenir uidcorrectement l’appelant lorsqu’il appelle sudoou su.

• Redémarrez votre système maintenant.

• Connectons-nous et exécutons quelques commandes:

    $ id -u
    1000
    $ sudo ls /
    bin boot données dev etc.
    $ sudo su -
    # ls / etc
    [...]

Cela donnera 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 auidcolonne contient l’utilisateur appelant uid, ce qui vous permet de filtrer les commandes exécutées par cet utilisateur avec

 ausearch -ua 1000

Cela listera même les commandes que l'utilisateur a exécuté en tant que root.

Sources:

• 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

N'oubliez pas que sudo enregistre lui-même toutes les commandes sudo dans le syslog. Par conséquent, tous les utilisateurs privés doivent apprendre à ne pas simplement utiliser sudo pour obtenir un shell root, mais à

sudo command p1 p2 ... pn

Le problème avec cette approche ou toute autre approche à laquelle j'ai pensé est qu'en tant rootqu'utilisateur, il est assez difficile d'empêcher un utilisateur de se soustraire à un type particulier de journalisation. Ainsi, tout ce que vous essayez sera <100%, je suis désolé de le dire.

L'éducation, la documentation, l'application et surtout la confiance est ce qui est nécessaire.

J'ai déjà eu à faire face au même problème et je devais trouver une solution rapide et délicate: chaque utilisateur sudo aurait son propre fichier d'historique une fois qu'il aurait exécuté la commande. sudo -i

Dans /root/.bashrcj'ai ajouté la ligne suivante -

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

Ainsi, chaque utilisateur souhaitant accéder à la racine aura un fichier d’historique .bash_history-username.

Une autre méthode -

Ajoutez le code suivant à /root/.bashrcet le nom d'utilisateur, sudo-user, et la commande seront ajoutés au fichier journal, quel que soit le niveau de notification défini, 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

En fait, un certain nombre d’établissements interdisent l’utilisation de auditd parce qu’il nécessite beaucoup de ressources et peut donner lieu à des 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) afin de consigner toutes les commandes exécutées en tant que root sur un serveur syslog distant, puis de demander à la stratégie de le faire, sauf en cas d'urgence. Dans certains cas, les administrateurs système se connectent avec des comptes personnels et exécutent le shell amélioré Korn via sudo. L'examen des journaux peut détecter le moment où 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 qui s'appelle sudoreplay quand les sessions activées sont enregistrées et peuvent être rejouées plus tard. Son fonctionnement est similaire à celui de la scriptcommande qui crée un script de type de session de terminal qui peut ensuite être rejoué avec la scriptreplaycommande.

Jusqu'à présent, les réponses ne sont pas fausses, mais si vous décidez que sudola journalisation syslogest satisfaisante, permettez-moi de vous suggérer une solution: connectez-la via le réseau à un hôte de contrôle distant.

Cela contourne le problème de "maintenant que je suis devenu root, je peux enlever toute trace de mes méfaits des journaux". Vous êtes peut-être maintenant root sur le serveur local, mais vous ne pouvez pas rappeler ce paquet de journal à partir du réseau et vous (probablement) ne disposez pas des privilèges root sur l'hôte d'audit distant.

Je le fais avec certains des réseaux que je gère depuis des années et présente deux autres avantages:

Premièrement, il existe un emplacement sur le réseau où consulter tous les syslogs, ce qui permet une corrélation beaucoup plus facile des incidents. Il en va de même pour les enquêtes telles que "Quand junose plaignait-il que le serveur NFS herane répondait-il pas? Si herale problème est susceptible de se produire, voyons ce qu’elle a enregistré; sinon, junola connexion réseau est plus suspecte, voyons ce qu’il ya d’autre junoà ce moment-là. ".

Deuxièmement, la rotation des journaux syslog devient plus facile: vous ne gardez pas des copies des journaux sur les hôtes locaux pendant plus de quelques jours, mais vous vous assurez que le serveur d'audit dispose d'une quantité considérable d'espace disque et y conservez tous les syslog pendant plusieurs années. De plus, si, par exemple, vous souhaitez les écrire sur le support WORM à des fins d'audit légal, par exemple, vous ne devez acheter qu'un seul disque WORM.

Depuis la version 2.0.0, Snoopy est capable de consigner des variables d’environnement arbitraires.

Cependant, une récente contribution a souligné que le propriétaire 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 mainteneur snoopy.