Journalisation d'une activité «personnes» sous Linux


11

J'ai donc lu de nombreux articles liés à cela et je viens de me retrouver plus confus qu'auparavant. Il existe des recommandations pour divers outils, y compris ttyrec, snoopy, acct, rootsh, sudosh, ttyrpld, unix auditing et plus encore.

Dans mon cas, je veux pouvoir enregistrer toutes les commandes exécutées sur un système (comme l'historique avec les horodatages activés), mais je veux aussi savoir qui a fait quoi? Cependant, nous nous connectons tous via ssh au même petit sous-ensemble de comptes d'utilisateurs (selon ce que nous faisons). Comment puis-je obtenir un journal des commandes, y compris les informations qu'un "qui" me donnera (concernant la connexion) afin que je puisse retracer l'action à une personne spécifique comme posée à un "utilisateur" générique?


Snoopy devrait être en mesure de le faire, et probablement de nombreuses autres alternatives.
3molo

2
Appels système, sudo, historique du shell, modifications du système de fichiers? Tous les processus utilisateur ne sont pas nécessairement démarrés à partir de shells de connexion.

Réponses:


9

Le auditdpackage est conçu pour cela, vous pouvez utiliser PAM pour attribuer à chaque connexion un ID de session afin que vous puissiez suivre l'activité sur un compte jusqu'à la connexion d'origine (puis vérifier le journal de connexion pour déterminer d'où cette personne s'est connectée), et utiliser la ausearchcommande pour localiser les événements qui vous intéressent. Vous pouvez lire un guide assez complet ici même si certains des détails les plus fins devront être modifiés pour correspondre à votre distribution. Redhat a un site avec une FAQ et quelques autres documents ici .

Étant donné que cela ne repose pas sur la tentative de journalisation des commandes tapées dans des shells ou sur l'enregistrement de l'historique des commandes des utilisateurs, cela devrait consigner des choses comme l'ouverture de vi (qui pourrait être effectuée sur X ou dans screen), l'écriture d'un script (peut-être un caractère à la fois). avec les commandes couper / coller de vi et quelques exécutions de :.!/usr/games/fortunepour obtenir des données sources que vous ne pourrez peut-être pas enregistrer), puis exécutez la :%!/bin/bashcommande.


C'est la réponse la plus prometteuse ... L' audit vous permet de suivre de manière cohérente les actions d'un utilisateur, de la connexion à la déconnexion, quelles que soient les identités que cet utilisateur pourrait adopter en utilisant des ID d'audit créés lors de la connexion et transmis à tout processus enfant du processus de connexion d'origine. Un peu plus de lecture de ma part maintenant pour savoir comment le mettre en œuvre. Merci d'avoir réduit le nombre de choix!
Ashimema

Toutes mes excuses pour avoir mis tant de temps à marquer cette réponse comme acceptée. J'essayais! Fonctionne un rêve .. Bravo les gars!
Ashimema

4

Il existe déjà une variété d'outils à votre disposition, que votre question (et ces réponses) font allusion à l'historique, snoopy, auditd, sudo logs, etc ... mais si vous avez un "sous-ensemble de comptes" que les gens utilisent, il y a aucun moyen sur le serveur pour dire qui a fait quoi. La seule façon de savoir précisément qui l'a fait est que les utilisateurs disposent de leur propre ordinateur qu'ils utilisent spécifiquement et utilisent des enregistreurs de frappe pour dire ce qu'ils tapaient physiquement sur ce clavier.

Chaque fois que vous partagez des comptes, vous ne pouvez pas dire ce qui se passait réellement, car vous auriez besoin de preuves supplémentaires qui utilisait votre compte root ou votre compte bob ou quoi que vos gens faisaient. Si vous essayez d'enquêter sur ce qui s'est passé dans un incident spécifique, vous devrez peut-être revoir vos politiques et procédures d'accès, vos procédures de récupération et évaluer vos employés et / ou vous engager dans une reconversion si nécessaire (ou leur fiabilité avec des comptes sensibles) plutôt que de se concentrer directement sur la recherche de qui a fait quelque chose, car cela peut absorber plus de ressources que vous ne gagnez à trouver la personne qui l'a fait.

Sinon, vous voudrez peut-être étudier les techniques d'investigation médico-légale pour retracer ce qui s'est passé (imagerie du lecteur, suivi des journaux, etc.) Si vous n'enquêtez pas sur un incident, examinez vos politiques et installez un meilleur suivi et une meilleure vérification des comptes (vous seul avez root, seul Bob utilise son compte en utilisant sudo pour accéder à des privilèges plus élevés, installer et surveiller auditd, etc.) et faites attention à ne pas donner à votre cercle de confiance l'impression d'être détenu au microscope ou vous pourriez aliéner les gens qui essaient pour faire leur travail (ou les empêcher de faire leur travail).


2

L'audit Linux ( http://people.redhat.com/sgrubb/audit/ ) vous donnera le plus de pouvoir pour regarder qui a fait quoi. Vous en avez plus à ce sujet dans la réponse de DerfK.

Cependant, rien ne vous dira qui s'est connecté en tant que webadmin s'il n'y a pas de personnes qui ont accès au compte webadmin. Je suggère d'utiliser des comptes nommés pour chaque utilisateur, puis d'utiliser su - ou sudo pour exécuter les commandes à partir du compte "function".

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.