Forum Linux.général Accès SSH, récupérer ip, nom de la personne

Posté par (page perso) .
Tags : aucun
1
30
juin
2009
Hello,

J'administre actuellement pas mal de serveurs et c'est un peu toujours la galère quand quelqu'un fait des modifs dans un fichier de conf pour retrouver qui l'a fait ...
Alors ça, j'aimerais que quand quelqu'un se connecte en SSH, un script lui demande son petit nom, ce qu'il vient faire et stocke tout ca et l'IP dans un fichier de log ...

Je pense qu'il n'est pas possible de faire une sorte de surcouche à SSH mais par contre, peut être qu'à l'ouverture de la session on peut lancer un script non ?

Merci :)
  • # Grsecurity

    Posté par (page perso) . Évalué à 1.

    http://www.grsecurity.net/

    C'est un patch noyau, qui permet en autre d'auditer les commandes lancées par les utilisateurs...

    Système - Réseau - Sécurité Open Source

    • [^] # Re: Grsecurity

      Posté par (page perso) . Évalué à 1.

      Ca me semble bien intéréssant merci.

      Cependant, j'ai peur que ca soit trop compliqué pour ce que je veux faire ...
      Je souhaiterais en fait, juste lancer un petit script ;-)
      • [^] # Re: Grsecurity

        Posté par (page perso) . Évalué à 3.

        Je souhaiterais en fait, juste lancer un petit script ;-)

        Ce n'est pas un "petit script" mais celui-ci est prévu pour un besoin similaire au tiens. À adapter... (et probablement aussi corriger, tout n'est sûrement pas parfait)


        #!/bin/bash

        # cree un fichier journal et un fichier de configuration
        # correspondant a l'action effectue sur le routeur ou le pare-feu

        export LANG=fr_FR

        horodatage=$(/bin/date +"%Y%m%d")
        operateur=$LOGNAME
        dateoperation=$(/bin/date +"%e %B %Y - %H:%M")

        generelog()
        {
        version=1
        while [ -r $fichier-$horodatage-0$version.log -o -r $fichier-$horodatage-$version.log ]
        do
        let version=$(($version+1))
        done

        if [ $version -lt 10 ]
        then
        fichierlog=$fichier-$horodatage-0$version.log
        else
        fichierlog=$fichier-$horodatage-$version.log
        fi

        /bin/touch $fichierlog

        echo "Operateur : $operateur" > $fichierlog
        echo "Date : $dateoperation" >> $fichierlog
        echo "Detail de l'intervention : " >> $fichierlog

        echo "Editez le fichier $fichierlog"
        }

        genereconf()
        {
        version=1
        while [ -r $fichier-$horodatage-0$version -o -r $fichier-$horodatage-$version ]
        do
        let version=$(($version+1))
        done

        if [ $version -lt 10 ]
        then
        fichierconf=$fichier-$horodatage-0$version
        else
        fichierconf=$fichier-$horodatage-$version
        fi

        /bin/touch $fichierconf
        /bin/chmod 666 $fichierconf

        echo "Fichier $fichierconf genere."
        }

        # Tests sur les arguments passes au script
        if [ $# -lt 1 ]
        then
        echo "usage : $0 [-r|-f]"
        exit 1
        fi

        if [ ! -w . ]
        then
        echo "Repertoire non accessible"
        exit 1
        fi

        case "$1" in
        -r)
        fichier="routeur"
        generelog
        genereconf
        ;;
        -f)
        fichier="pare-feu"
        generelog
        genereconf
        ;;
        *)
        echo "usage : $0 [-r|-f]"
        ;;
        esac

        # EoF
  • # gestion de version de /etc

    Posté par (page perso) . Évalué à 1.

    Peut-être que des outils comme etckeeper peuvent répondre à ton besoin de savoir qui modifie quel fichier de conf et pourquoi.

    http://joey.kitenet.net/code/etckeeper/
    • [^] # Re: gestion de version de /etc

      Posté par (page perso) . Évalué à 1.

      Oui mais en fait, on se log tous en ssh avec le même compte ...
      Donc on aurait tous les mêmes "noms".

      Qui plus est, ce n'est pas que de la modif de fichier de conf mais toute sorte de choses (ajout/suppression de fichiers, modifications...)
      • [^] # Re: gestion de version de /etc

        Posté par . Évalué à 7.

        Oui mais en fait, on se logue tous en ssh avec le même compte ...

        Au risque d'enfoncer une porte ouverte : pourquoi ne pas créer N utilisateurs aux mêmes droits ?
        • [^] # Re: gestion de version de /etc

          Posté par . Évalué à 6.

          un login par utilisateur, c'est un point de depart interessant,

          cet utilisateur peut donc se connecter sur la machine et ensuite il serait en mesure de faire un sudo sur les commandes souhaitées/autorisées

          tu pourrais meme avoir un ldap qui gere tes utilisateurs, et un ssh qui identifie tes utilisateurs via pam_ldap

          ainsi, quand quelqu'un quitte la boite, tu fermes son compte ldap, et il n'a plus acces à aucun serveur...
          • [^] # Re: gestion de version de /etc

            Posté par (page perso) . Évalué à 3.

            En temps normal, je ne supporte pas les réponses du genre "Pourquoi tu veux faire ça, fais plutôt ça", mais une fois n'est pas coutume, j'abonde complètement dans le sens dse deux précédents commentaires.
            L'utilisation d'un login unique sur une prod est une hérésie en terme de sécurité, en terme de gestion de droits, en terme de beaucoup de choses en fait.

            Pour moi une meilleure résolution de ta problématique passe effectivement par le couple 1 login/utilisateur + fichier sudoers approprié.
            C'est certes plus couteux en temps, mais c'est diablement plus efficace et ça renforce la sécurité de ta prod...
            Ensuite, tu couples cette solution avec des mécanismes de centralisation de logs, et ensuite t'as plus qu'à cliquer dans ton navigateur pour savoir qui a fait quoi (genre syslog-ng avec mysql, et un front end PHP quelconque). Mais ça c'est du bonus :)
            • [^] # Re: gestion de version de /etc

              Posté par (page perso) . Évalué à 1.

              En temps normal, je n'aime pas non plus les gens qui me disent de faire autre chose que je demande !
              Mais, je vais moi aussi, faire une exception ;-)

              LDAP m'intéresse beaucoup mais il semble être très compliqué. Sachant que j'ai un parc de serveurs relativement important et qu'il y a beaucoup d'utilisateur à s'y connecter et ceci, par plusieurs moyens (SSH, FTP...).
              Serait ce une solution appropriée ?

              De plus, nous utilisons différents logiciels de gestion (tels que Trac et OpenERP), y'a t'il des plugins pour ceux ci qui pourront permettre de les coupler à LDAP ?

              Merci pour toutes vos réponses :)
              • [^] # Re: gestion de version de /etc

                Posté par . Évalué à 3.

                SSH/FTP peuvent utiliser PAM_LDAP
                pour interroger ldap au lieu de /etc/passwd et /etc/group

                LDAP n'est pas compliqué si tu lis bien la documentation

                je ne sais pas si Trac et OpenERP dispose de module ldap
                mais ils peuvent peut-etre aussi utiliser pam_ldap
  • # Remplacer le shell

    Posté par (page perso) . Évalué à 1.

    Tu peux remplacer le shell de la personne qui se connecte par un script qui fait ce que tu demande et qui se termine par un exec bash -i
    • [^] # Re: Remplacer le shell

      Posté par . Évalué à 2.

      ce script serait exécuté lors de chaque appel au shell :
      nouveau terminal ouvert
      sous shell
      lancement de scripts
      et j en passe.
      donc peut être pas vraiment valable.

      y a un contournement du genre :
      check première connection -> exécution -> désactivation -> ré-activation lors de la déconnection pour la session suivante.
      mais c' est sale.

      un script lui demande son petit nom, ce qu'il vient faire et stocke tout ca et l'IP
      regarde du côté de pam et de syslog. (à mon humble avis, ton script tu dois le faire en pensant "nouvelle règle pam", même si elle est simple.)

      maintenant la vraie réponse c' est peut être des vrais comptes...

      Maintenant, personnellement, comme un bon gros feignant, j' utiliserai HIST de bash.
      En le customisant un peu, tu peux obtenir ce que tu recherches : un fichier consignant les connections, avec horodatage et ip source, ainsi que les actions effectuées.
      Reste à protéger ce fichier...
      Et ensuite j' ajouterai une tache Cron à base de tail, tout simplement.
      Quoi qu 'en découvrant etckeeper, ça à l' air très sympa ! pourquoi le refaire si c' est déjà fait et en mieux ?
      • [^] # Re: Remplacer le shell

        Posté par (page perso) . Évalué à 2.

        Euh non, le shell par défaut d'un personne ne s'exécute que lorsuque la personne se connecte. Par contre il est vrai que c'est valable autant en ssh qu'en local.

        Les sous shell est autres sont comme d'habitude en /bin/kivabien et ne sont pas changés.
  • # Bash, ssh et history

    Posté par . Évalué à 2.

    Salut,

    Est-ce que l'adresse IP du client SSH peut te suffire pour tracer ce que tu veux ?

    Si c'est le cas, tu peux arriver à tes fins simplement en jouant un peu de la configuration dans le fichier .bashrc :
    - lors d'une connexion SSH, tu doit avoir les variables SSH_CLIENT et SSH_CONNECTION positionnées. Le premier mot de ces variables indique l'adresse IP du client
    - pour savoir s'il s'agit d'une prière connexion (et pas d'un sous-shell), il suffit de vérifier que la variable SHLVL est égale à 1 : ça peut te servir pour faire un test dans .bashrc avant de poser tes questions au besoin
    - une fois que tu as récupéré l'adresse IP ou le nom du client, tu peux créer un fichier d'historique des commandes personnalisé en attribuant une valeur à la variable HISTFILE (par exemple "export HISTFILE=~/.bash_history_$IP")
    - pense à modifier la valeur de HISTFILESIZE si tu veux conserver plus de commandes que les 500 par défaut
    - positionne la variable HISTTIMEFORMAT à quelque chose comme "%Y%m%d-%H%M%S " pour avoir un horodatage des commandes passées par les utilisateurs

    Evidemment, ce type de chose est aussi possible avec d'autres shell comme ksh (à part peut être l'horodatage) ou zsh (avec l'option EXTENDED_HISTORY on peut même avoir la durée des commandes).

    Bien sûr tout ceci suppose d'avoir une certaine confiance envers les utilisateurs concernés : rien ne les empêche de supprimer les fichiers d'historiques...

    J'espère que tout cela pourra t'aider.

    A+
    JJD
    • [^] # Re: Bash, ssh et history

      Posté par (page perso) . Évalué à 2.

      L'inconvénient est que certains utilisateurs n'ont pas nécessairement bash comme shell par défaut.
      • [^] # Re: Bash, ssh et history

        Posté par . Évalué à 1.

        Oui, mais :
        - comme je l'ai écrit ce type de chose (historique par utilisateur) marche parfaitement avec d'autres shells, moyennant un paramétrage spécifique par shell utilisé (je l'ai fait avec ksh sous AIX pour éviter de retrouver autre chose que mes propres commandes lorsque je remontais dans l'historique)
        - dans la problématique de Tom, j'ai l'impression qu'il n'y a qu'un seul user unix utilisé par plusieurs personnes. Sauf paramétrage tordu,je pense que ces différents utilisateurs ont donc bien le même shell
  • # audit

    Posté par . Évalué à 4.

    Cela correspond exactement à ce que tu veux mettre en place :
    http://librenix.com/?inode=10248
    http://www.cyberciti.biz/tips/linux-audit-files-to-see-who-m(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.