Comment suivre les activités des super-users

J'aimerais savoir quelles sont les meilleures approches pour le suivi des activités de super-user sur un environnement Linux.

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

  • A) Enregistrement des frappes de touches sur un server syslog sécurisé
  • B) Possibilité de reproduire des sessions shell (quelque chose comme scriptreplay)
  • C) Idéalement, cela devrait être quelque chose d'impossible (ou assez difficile) à contourner sans avoir access physique au server.

Pensez-y à partir d'un sharepoint vue de security / audit, dans un environnement où différents systèmes administratifs (ou même des tiers) doivent être autorisés à effectuer des opérations privilégiées sur un server.

Chaque administrateur aurait son ou son propre count nominal, et chaque session interactive devrait être entièrement enregistrée, avec la possibilité de la rejouer si nécessaire (par exemple, si quelqu'un utilisait mc pour supprimer ou modifier des files critiques, il ne suffirait pas de sachez que cette personne a émis la command 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 l'a souligné womble, la meilleure option serait de ne pas avoir des users qui se connectent avec des privilèges root pour effectuer des modifications sur les servers, mais plutôt par le biais d'un système de gestion de configuration. Supposons donc une situation où nous n'avons pas un tel système et nous devons accorder l'access au niveau racine à différentes personnes sur le même server .
  2. Je ne suis pas intéressé de le faire de façon subreptice: chaque personne qui se connecte à un server avec des privilèges root est totalement consciente que la session sera enregistrée (de la même manière que, par exemple, les opérateurs du centre d'appels savent que leurs conversations sont étant enregistré)
  3. Personne n'utiliserait un count superuser générique ("root")
  4. Je suis conscient de ttyrpld et il semble faire ce que je cherche. Mais avant d'aller de cette façon, j'aimerais savoir si cela peut être résolu en utilisant un kernel non modifié. Je veux savoir s'il existe des outils pour Debian en particulier (ou Linux en général) qui permettent une vérification complète des counts superuser sans patch le shell ou le kernel.

10 Solutions collect form web for “Comment suivre les activités des super-users”

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

Utilisez sudo pour tout – sudo est extrêmement configurable et facilement logiable.

Enregistrez toutes les connections ou les sous pour enrayer et les enquêter alors que quelqu'un est en train de contourner vos règles établies.

D'une part, quel type d'access user root cherchez-vous à surveiller? Des erreurs stupides d'administration ou un initié malveillant? L'ancien – vous voudrez une bonne solution de gestion de la configuration, comme cela a déjà été suggéré. Ce dernier – s'ils savent ce qu'ils font, vous ne pouvez qu'attendre assez pour indiquer quelque chose qui mérite d'être étudié. Vous voulez simplement savoir qu'une partie de l'activité non autorisée a commencé et être alerté de ce fait. S'ils sont intelligents, ils désactiveront la plupart des loggings que vous construisez (en modifiant l'état du server ou en apportant leurs propres outils), mais, espérons-le, vous pouvez saisir les débuts de l'incident.

Cela dit, je suggère quelques outils que vous pouvez utiliser. Tout d'abord, commencez par une bonne politique sudo (ce qui a déjà été suggéré). Deuxièmement, vérifiez la sudochasse si vous devez donner à ces administrateurs l'access aux racines. Troisièmement, probablement votre meilleur pari (bien que le plus intensif), searchz l'audit du kernel linux.

Ce que vous pourriez faire, c'est utiliser cette bibliothèque pour sudo, donner à chacun sa propre count user et mettre sudo -i dans son profil. De cette façon, ils ont un access racine instantané et chaque command qu'ils utilisent est en train d'être enregistrée.

Ils ont la racine. Le meilleur que vous pouvez espérer est de voir au less 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 quelqu'un.

L'option «la meilleure» que je peux envisager est de prévoir l'utilisation d'une automation et d'une gestion de configuration omnipresente, et de gérer vos manifestes à l'aide d'un système de contrôle de révision et de déployer des mises à jour à travers cela. Ensuite, évitez les connections racines réelles aux servers. (L'urgence "oh noes, j'ai cassé quelque chose", l'access peut être fourni par un mot de passe non-dissortingbué et changé après chaque utilisation ou une key SSH, et tout le monde peut regarder le sysadmin qui a foutu pour s'assurer qu'ils ne le font 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 chacun dans ce sens, je suppose que vous êtes dans un environnement incommode et ennuyeux par d'autres moyens que cela a gagné Je pense que c'est un gros problème.

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

J'appendais régulièrement la sauvegarde du file historique bash. Apparemment souvent négligé, mais peut parfois être une excellente source d'information … requestz à 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 security (tuer les process de surveillance), déchiffrer les files journaux / les réduire etc … Mais encore …

En supposant que plusieurs administrateurs bénéficient de privilèges root, ils fonctionnent en équipe. Et la racine peut tuer tout process de surveillance aussi. Malheureusement, cette connection / mot de passe devient publique. Ou ils obtiennent une société indésirable.

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

Dans / etc / ssh / sshd_config Modification de la ligne vers: PermitRootLogin non

est recommandé. Donc, ici, un user se connecte à l'utilisation de son count normal (le timbre date-date est enregistré avec (peut-être l'adresse IP falsifiée)) Ensuite, passe en root. utilisant la command su

Et la connection directe en tant que root est empêchée comme celle-ci.

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

Sudo devrait être bon. Sauvegarde / etc directory Les files de configuration devraient être bons. / var / directory Les files journaux doivent être envoyés par courrier électronique périodiquement ou stockés sur un NFS distinct.

Qu'en est-il de rédiger des scripts qui intègrent des API à partir de sociétés de la passerelle mobile qui regroupent tous les mobiles de l'user root, dont l'un d'eux est hors de la maison pour fonctionner. Je sais que ce serait irritant, mais toujours.

Breaking SSH est surtout hors de question.

Comme d'autres l'ont dit, il n'y a presque aucun moyen de connecter des users avec un access root complet d'une manière qu'ils ne peuvent pas désactiver, mais si vous utilisez debian / ubuntu, regardez snoopy , ce qui est très proche de ce que vous voulez

snoopy est simplement une bibliothèque partagée qui est utilisée comme enveloppe de la fonction execve () fournie par libc pour save tous les appels vers syslog (authpriv). les administrateurs système peuvent find utile dans des tâches telles que la surveillance du système léger / lourd, le suivi des autres actions de l'administrateur ainsi que l'obtention d'une bonne «sensation» de ce qui se passe dans le système (par exemple apache exécutant des scripts cgi).

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

  • De même, ouvrez-vous pour vous authentifier avec kerberos sur AD (counts personnels)
  • Autorisation uniquement pour certains groupes AD d'administrateurs Unix
  • groupe de sudoers == groupe AD
  • OSSEC HIDS agents sur chaque server et un gestionnaire sur un server durci
  • OSSEC Web UI
  • Splunk 3 avec Splunk-for-OSSEC

Il savea chaque utilisation de sudo sur les servers et suivra également les modifications apscopes aux files, l'installation des packages, les process suspects, etc.

Nous avons plusieurs servers de terminaux pour accéder à tous nos équipements, ce qui signifie que l'on peut se connecter à tout ou à partir du server de terminal ou s'il y a un access physique.

Sshd sur les servers de terminal est corrigé avec http://www.kdvelectronics.eu/ssh-logging/ssh-logging.html , fonctionne bien, mais n'a pas été mis à jour depuis longtime. Je l'ai modifié un peu pour fonctionner sur openssh 4.7, mais je n'ai pas réussi à le faire avec 5.1. Séquences de sshd rembourrées, et aussi longtime que je n'ai pas assez de time pour résoudre ce problème, j'ai presque changé pour ttyrpld.

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

  • Sudosh : semble soutenir A et B (pas complètement sûr d'A cependant)
  • Sudoscript : semble supporter B (Sudoscript a un composant appelé sudoshell, et si c'est ce que les romandas ont suggéré, merci pour le conseil)
  • Snoopy Logger ou sudo_exetrace : pas exactement ce que je cherche, mais pourrait être un bon complément (grâce à theotherreceive et blauwblaatje pour ces liens)

Connaissez-vous d'autres outils similaires qui n'impliquent pas le patch du kernel ou d'autres composants du système?

  • SELinux vs. AppArmor vs. grsecurity
  • Quel est le format / algorithm hash par défaut d'Active Directory?
  • Pourquoi il est parfois nécessaire de se déconnecter et de vous connecter à nouveau en ajoutant un groupe à un user
  • SSH étrange, security du server, j'aurais pu être piraté
  • Liste de security Active Directory
  • Enregistrement sécurisé des references AWS sur une machine personnelle
  • Qu'est-ce qu'un résolveur DNS ouvert, et comment protéger mon server d'être mal utilisé par les pirates informatiques?
  • Le pare-feu sur Windows Server 2008 R2 est-il suffisant?
  • Passé le vérificateur SSL, mais le browser ne s'affiche pas en toute security?
  • Conformité PCI IIS 6.0 - "Vulnérabilité de divulgation d'information"
  • Le journal MySQL montre 3 utilisateurs root, 2 sans mots de passe? Pourquoi?
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de réseau.