Comment suivre les activités des superutilisateurs

Je voudrais savoir quelles sont les meilleures approches pour suivre les activités des super-utilisateurs dans un environnement Linux.

Plus précisément, je recherche ces fonctionnalités:

• A) Enregistrement des frappes sur un serveur Syslog sécurisé
• B) Possibilité de rejouer des sessions shell (quelque chose comme scripttreplay)
• C) Idéalement, cela devrait être impossible (ou assez difficile) à contourner sans avoir un accès physique au serveur.

Pensez à cela d'un point de vue sécurité / audit, dans un environnement où différents administrateurs système (ou même des tiers) doivent être autorisés à effectuer des opérations privilégiées sur un serveur.

Chaque administrateur aurait son propre compte nominal, et chaque session interactive devrait être entièrement enregistrée, avec la possibilité de la relire si nécessaire (par exemple, si quelqu'un a utilisé mc pour supprimer ou modifier des fichiers critiques, il ne suffirait pas de sachez que cette personne a émis la commande mc; il doit y avoir un moyen de voir exactement ce qui a été fait après le lancement de mc).

Notes supplémentaires :

1. Comme womble l'a souligné, la meilleure option pourrait être de ne pas se connecter avec des privilèges root pour effectuer des modifications sur les serveurs, mais plutôt de le faire via un système de gestion de la configuration. Donc , supposons une situation où nous ne disposons pas d' un tel système et nous devons accorder un accès au niveau de la racine à des personnes différentes sur le même serveur .
2. Je ne suis pas du tout intéressé à le faire subrepticement: chaque personne se connectant à un serveur avec des privilèges root serait pleinement consciente que la session sera enregistrée (de la même manière que, par exemple, les opérateurs de centre d'appels savent que leurs conversations sont en cours d'enregistrement)
3. Personne n'utiliserait un compte de superutilisateur générique ("root")
4. Je connais ttyrpld et il semble faire ce que je recherche. Mais avant de procéder de cette façon, j'aimerais savoir si cela peut être résolu en utilisant un noyau non modifié. Je veux savoir s'il existe des outils pour Debian en particulier (ou Linux en général) qui permettent un audit complet des comptes de superutilisateur sans patcher le shell ou le noyau.

Pour les environnements avec plusieurs administrateurs, n'utilisez simplement pas root - jamais si possible.

Utilisez sudo pour tout - sudo est extrêmement configurable et facilement enregistrable.

Connectez-vous à toutes les connexions ou à toutes les connexions à rooter et examinez-les car quelqu'un contourne ensuite vos règles établies.

D'une part, quel type d'accès utilisateur root souhaitez-vous surveiller? Erreurs d'administration stupides ou initiés malveillants? Le premier - vous voudrez une bonne solution de gestion de configuration, comme cela a déjà été suggéré. Ce dernier - s'ils savent ce qu'ils font, vous ne pouvez qu'espérer en attraper suffisamment pour indiquer que quelque chose s'est passé qui mérite d'être étudié. Vous voulez juste savoir qu'une certaine forme d'activité non autorisée a commencé et être alerté de ce fait. S'ils sont intelligents, ils désactiveront la plupart des journaux que vous créez (en changeant l'état du serveur ou en apportant leurs propres outils) mais j'espère que vous pourrez rattraper les débuts de l'incident.

Cela étant dit, je suggère quelques outils que vous pouvez utiliser. Tout d'abord, commencez par une bonne politique sudo (qui a déjà été suggérée). Deuxièmement, consultez sudoshell si vous avez besoin d'accorder à ces administrateurs un accès au shell racine. Troisièmement, probablement votre meilleur pari (bien que le plus intensif), examinez l'audit du noyau Linux.

Ce que vous pourriez faire, c'est utiliser cette bibliothèque pour sudo, donner à chacun son propre compte d'utilisateur et mettre sudo -i dans le profil de tout le monde. De cette façon, ils ont un accès root instantané et chaque commande qu'ils utilisent est enregistrée.

Ils ont racine. Le mieux que vous puissiez espérer est de voir au moins quand ils ont décidé de sortir de votre petite utopie de surveillance, mais au-delà de ce qu'ils ont fait, c'est la supposition de n'importe qui.

La "meilleure" option à laquelle je peux penser est de rendre obligatoire l'utilisation d'une automatisation et d'une gestion omniprésentes de la configuration, et de gérer vos manifestes à l'aide d'un système de contrôle des révisions et de déployer des mises à jour par ce biais. Ensuite, empêchez les connexions root réelles aux serveurs. (L'accès d'urgence "oh noes I cassé quelque chose" peut être fourni par un mot de passe ou une clé SSH non distribué et modifié après chaque utilisation, et tout le monde peut regarder l'administrateur système qui a foiré pour s'assurer qu'il ne le fait pas changer quoi que ce soit).

Oui, cela va être gênant et ennuyeux, mais si vous êtes assez paranoïaque pour vouloir surveiller les actions de tout le monde à ce degré, je suppose que vous êtes dans un environnement qui est gênant et assez ennuyeux à d'autres égards que cela a gagné ne semble pas être un gros problème.

Comme d'autres l'ont dit, il n'y a pratiquement aucun moyen de consigner les utilisateurs avec un accès root complet d'une manière qu'ils ne peuvent pas désactiver, mais si vous utilisez debian / ubuntu, jetez un œil à snoopy , qui se rapproche assez de ce que vous voulez

snoopy est simplement une bibliothèque partagée qui est utilisée comme wrapper pour la fonction execve () fournie par libc pour enregistrer chaque appel à syslog (authpriv). Les administrateurs système peuvent trouver snoopy utile dans des tâches telles que la surveillance du système léger / lourd, le suivi des actions d'autres administrateurs ainsi que d'avoir une bonne idée de ce qui se passe dans le système (par exemple, apache exécutant des scripts cgi).

Je suis d'accord avec les commentaires de disabledleopard sur l'utilisation de sudo pour tout. Cela rend certainement les choses un peu plus faciles à enregistrer.

J'ajouterais également la sauvegarde périodique du fichier d'historique bash. Apparemment souvent négligé, mais peut parfois être une excellente source d'informations ... il suffit de demander à Goldman Sachs. ;-)

http://www.guardian.co.uk/business/2009/jul/12/goldman-sachs-sergey-aleynikov

Ce serait difficile ...

root peut exécuter des scripts soigneusement testés qui peuvent enfreindre toutes les mesures de sécurité (tuer les processus de surveillance), déchiqueter les fichiers journaux / les couper, etc ... Mais quand même ...

En supposant que plusieurs administrateurs disposant de privilèges root fonctionnent en équipe. Et root peut également tuer n'importe quel processus de surveillance. Et malheureusement, ce login / mot de passe devient public. Ou ils obtiennent une compagnie indésirable.

La création de plusieurs comptes racine avec UID 0, bien que non recommandée, peut être applicable ici.

Dans / etc / ssh / sshd_config Changer la ligne en: PermitRootLogin no

est recommandé. De sorte que, ici, un utilisateur se connecte en utilisant son compte normal (le cachet datetime est enregistré avec (peut-être une adresse IP usurpée)) puis passe en root. en utilisant la commande su

Et la connexion directe en tant que root est empêchée comme ceci.

Nous devons penser à ce que la racine ne peut pas faire ici.

sudo devrait être bon. La sauvegarde des fichiers de configuration du répertoire / etc devrait être bonne. / var / directory Les fichiers journaux doivent être envoyés régulièrement par e-mail ou stockés sur un NFS distinct.

Que diriez-vous d'écrire des scripts qui intègrent des API de sociétés de passerelle mobile qui regroupent SMS tous les mobiles des utilisateurs root, que l'un d'entre eux est hors de chez lui pour travailler. Je sais que ce serait irritant, mais quand même.

Briser SSH est pour la plupart hors de question.

Nous avons la configuration suivante sur le site d'un client:

• De même ouvert pour s'authentifier avec Kerberos sur AD (comptes personnels)
• Autorisation uniquement à certains groupes AD d'administrateurs Unix
• groupe sudoers == groupe AD
• Agents OSSEC HIDS sur chaque serveur et gestionnaire sur un serveur renforcé
• Interface Web OSSEC
• Splunk 3 avec Splunk-for-OSSEC

Il enregistrera chaque utilisation de sudo sur les serveurs et suivra également les modifications apportées aux fichiers, l'installation de packages, les processus suspects, etc.

Nous avons plusieurs serveurs de terminaux pour accéder à tous nos équipements, ce qui signifie que l'on peut se connecter à n'importe quoi depuis le serveur de terminaux ou si l'on a un accès physique.

Sshd sur les serveurs de terminaux est corrigé avec http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , fonctionne bien, mais n'a pas été mis à jour depuis longtemps. Je l'ai un peu modifié pour travailler sur openssh 4.7, mais je n'ai pas réussi à le faire avec 5.1. Patchs de sshd corrigés, et tant que je n'ai pas assez de temps pour résoudre ce problème, je suis presque passé à ttyrpld.

Jusqu'à présent, voici ce que j'ai:

• sudosh : semble supporter A et B (pas tout à fait sûr de A cependant)
• Sudoscript : semble prendre en charge B (Sudoscript a un composant appelé sudoshell, et si c'est ce que les romandas ont suggéré, merci pour l'astuce)
• Snoopy Logger ou sudo_exetrace : pas exactement ce que je recherche, mais pourrait être un bon complément (merci à theotherreceive et blauwblaatje pour ces liens)

Connaissez-vous d'autres outils similaires qui n'impliquent pas de correction du noyau ou d'autres composants du système?