Journal "Venez, c'est ouvert "

Posté par  (site web personnel) .
Étiquettes : aucune
0
3
jan.
2005
Voici une phrase qui résume assez bien la situation.
De plus en plus de new_linuxiens(tm) que j'ai l'occasion de croiser ont ssh sur leur machine, avec un compte user:root/pass:plop

S'il vous plait messieurs (mesdemoiselles, mesdames), si vous ne voulez pas changer le mot de passe de votre root, désactiver au moins le login root de ssh, ca forcera l'intrus a d'abord tenter de se connecter avec un simple user (si toutefois il ne s'obstine pas a tenter le root n'ayant pas saisi qu'il a été désactivé), et une fois connecté, il devra, a coup de su root, trouver cette fois ci le mot de passe root.

C'est quand même plus sûr mince !

Pour info, la directive PermitRootLogin [yes|no] du fichier /etc/ssh/sshd_config indique si le root a le droit ou non de se connecter directement via ssh

Toujours pour info, etant un grand parano, chez moi le compte root a un très long mot de passe, mes users aussi, et j'ai désactivé le login root :)

Voilou
  • # oui mais..

    Posté par  (site web personnel, Mastodon) . Évalué à 4.

    Moi je laisse le login root activé pour pouvoir me logguer par clé.

    Je ne connais même pas par coeur les mots de pass root des serveurs que j'administre...

    Mes livres CC By-SA : https://ploum.net/livres.html

    • [^] # Re: oui mais..

      Posté par  (site web personnel) . Évalué à 2.

      Et si tu te connect en User et apres en root ? ca va pas ?
    • [^] # Re: oui mais..

      Posté par  (site web personnel) . Évalué à 2.

      Oui c'est aussi une solution, mettre des mots de passe de 40 caractères. Mais je m'adresse surtout a ceux qui mettent plop ou 12345 comme mot de passe root, et qui ensuite laissent leur pc connecté au Grand et vilain Ternet.
    • [^] # Re: oui mais..

      Posté par  . Évalué à 2.

      > Moi je laisse le login root activé pour pouvoir me logguer par clé.

      A titre purement informatif, l'identification par clé fonctionne pour les users et pas juste pour root ;-)
  • # utilité de ssh?

    Posté par  (site web personnel) . Évalué à 7.

    Je ne nie pas que tu ai l'utilité de ssh, mais ce n'est pas mon cas, j'ai donc installé ssh mais je ne le lance que lorsque je sais en avoir besoin, et je ne peut l'utiliser (iptables) que sur le réseau local.
    Je pense que le mieux c'est quand même de ne faire tourner que les services dont on a besoin.
    PS mon PC est directement connecté à internet via un modem ethernet. J'envisage de reprendre un vieux PC et de m'en servir comme passerelle, et dans ce cas, il est évident que j'installerais SSH, mais même là, seul le réseaux local y aura accès.
    • [^] # Re: utilité de ssh?

      Posté par  (site web personnel) . Évalué à 3.

      Oui certes, mais encore une fois je m'adresse aux nouveaux, qui seront surement d'avantage motivés pour aller faire la modif du fichier de conf (ou pourquoi pas de désactiver ssh s'ils ne s'en servent pas), que d'aller bidouiller iptables

      Autrement tu as parfaitement raison, un ptit drop sur tout ce qui vient de l'exterieur et c'est du tout bon
    • [^] # Re: utilité de ssh?

      Posté par  . Évalué à 3.

      Je tiens quand même à rappeller que le fichier de conf de sshd permet de spécifier les adresses ip sur lequel le serveur écoute.
      par exemple sur ma passerelle j'ai ça:
      ListenAddress 192.168.1.1

      Je drop aussi avec iptables tout ce qui arrive sur ce port.
      2 mesures valent mieux qu'une :)
      Notez qu'il est important aussi d'avoir bien configuré le sysctl.conf, à mon avis.
      (argh d'ailleurs en disant ça je me suis aperçu que j'avai zappé un ou 2 trucs. http://www.linuxfr-france.org.invalid/prj/inetdoc/cours/config.interface/proc(...) )
  • # c clair

    Posté par  (site web personnel, Mastodon) . Évalué à 5.

    d'ailleurs je vous invite aussi a regarder les vos fichiers de log : en l'occurence les /var/log/auth.log* car y'a pas mal de petit malin qui s'amuse à essayer de profiter de ce genre de "failles", d'ailleurs y'a t'il encore des distribs qui par défaut permette le login par root en ssh ????

    en tout cas pour moi ça commence par :

    echo "sshd: $(grep Fail /var/log/auth.log* | grep sshd | grep "Failed password for root" | tr -s " " | cut -d" " -f11 | sort |uniq | tr '\n' ' ')" > /etc/hosts.deny


    ensuite il faut affiner car ils utilise aussi des comptes connus comme backup, irc, lp, mail, mysql, nobody, operator, www-data, ..... etc....

    donc une bonne configuration de ssh par défaut est triviale...

    M.
    • [^] # Re: c clair

      Posté par  (site web personnel, Mastodon) . Évalué à 4.

      je rajouterais que l'idéal est d'utiliser la primitive "AllowUsers" dans la config de ssh pour filtrer les utilisateurs qui se connectent ou bien encore de créer un groupe sshusers et d'utiliser la primitive "AllowGroups" et de n'ajouter à ce groupe que les utilisateurs succeptibles d'utiliser ssh...

      M.
    • [^] # Re: c clair

      Posté par  . Évalué à 3.

      " y'a t'il encore des distribs qui par défaut permette le login par root en ssh ???? "

      Ubuntu ...
    • [^] # Re: c clair

      Posté par  . Évalué à 0.

      Il y a encore des distrib' qui permettent le login en root tout court ?

      BeOS le faisait il y a 20 ans !

      • [^] # Re: c clair

        Posté par  (site web personnel) . Évalué à 2.

        Il y a encore des distrib' qui permettent le login en root tout court ?

        Alors, comment fais-tu pour installer sudo ?
    • [^] # Re: c clair

      Posté par  (site web personnel, Mastodon) . Évalué à 1.

      Autre mesure de sécurité : changer le port de ssh pour le mettre sur un port non standard, par ex (dans /etc/ssh/sshd_config) :
      ListenAddress 0.0.0.0:463

      Chez moi c'est très efficace, depuis que j'ai changé de port, plus aucune tentative d'intrusion :)

      WeeChat, the extensible chat client

      • [^] # Re: c clair

        Posté par  (site web personnel) . Évalué à 2.

        idem, chez moi il est sur 443, c'est plus simple pour faire des tunnels via des proxy un peu trop restrictifs, et le serveur web tourne déjà sur le port 80...
  • # Mot de passe utilisateur

    Posté par  . Évalué à 2.

    et une fois connecté, il devra, a coup de su root, trouver cette fois ci le mot de passe root.


    Mais bon si il a trouvé le mot de passe du bon utilisateur ---> sudo su - et c'est torché.



    1) Mettre un gros mot de passe aussi à votre utilisateur qui fait du sudo
    2) Preferer l'authentification ssh par clé
    3) Eviter le ALL=(ALL) ALL dans /etc/sudoers
    • [^] # Re: Mot de passe utilisateur

      Posté par  (site web personnel) . Évalué à 1.

      Heu chez moi sudo demande le mot de passe de l'utilisateur hein.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: Mot de passe utilisateur

        Posté par  . Évalué à 3.

        justement, l'astuce est que sudo demande le mot de passe de l'utilisateur courant, pas du root.

        Donc si la personne a réussi à trouver ton mot de passe user, un "sudo su -" lancera "su" déjà en temps que superutilisateur, donc sans demander de mot de passe root pour su lui même.
    • [^] # Re: Mot de passe utilisateur

      Posté par  (site web personnel) . Évalué à 3.

      Mais bon si il a trouvé le mot de passe du bon utilisateur ---> sudo su - et c'est torché
      Comme tu le dis plus bas, il suffit de ne pas configurer sudo comme un porc !! Quand on installe sudo (sur ma debian il n'y en a pas et je n'en ai jamais eu l'utilité), le fichier de conf n'est pas paramétré en ALL (pas configuré du tout), et c'est a l'utilisateur de le configurer via visudo. Et là, ce n'est pas une manip que font les débutant, la plupart des gars dont je parlais ne connaissent même pas sudo, et ne sauraient même pas le paramètrer :)

      Mais bon tu as raison de rappeler qu'un sudo ne doit JAMAIS être paramétré pour un ensemble de commande, mais au coup par coup, ex :

      cho7 ALL=(root) /usr/bin/mon_programme
      • [^] # Re: Mot de passe utilisateur

        Posté par  . Évalué à 5.

        A partir du moment ou tu possedes le compte d'un utilisateur qui augmente ses privileges c'est fini, ce n'est plus qu'une question de temps.

        Simplement un alias sur su et voila (mais il y a plus subtile).

        Ne pas se loger en root n'apporte aucune securite supplémentaire c'est un mythe. Ce que ca apporte c'est que l'on sait quel compte fait quoi rien de plus rien de moins. Je dors beaucoup mieux avec un ssh root et un root qui ne se log que depuis la console qu'avec une machine ou l'utilisateur peut se suer/sudoer... Il ne reste que deux risques, un mot de passe trop faible (c'est bien la le probleme et il est tres facile a resoudre) et une faille ssh. Pour la deuxieme y'a pas grand chose a faire de toute facon.
        • [^] # Re: Mot de passe utilisateur

          Posté par  (site web personnel) . Évalué à 2.

          > d'un utilisateur qui augmente ses privileges

          = tout utilisateur qui a acces a un prog en setuid root, comme /usr/bin/passwd ?

          > Simplement un alias sur su et voila

          Ton "sudo" fait la résolution des alias toi ?
          • [^] # Re: Mot de passe utilisateur

            Posté par  . Évalué à 2.

            > = tout utilisateur qui a acces a un prog en setuid root, comme /usr/bin/passwd ?

            Tu sors un peu la phrase de son contexte mais l'idée est :
            Si tu as le compte d'un utilisateur qui peut elever ses privilege alors tu peux acceder aux mêmes privilèges.

            C'est plus ou moins compliqué. Ca va du sudo sans mot de passe, au su via empreinte digitial + mot de passe a usage unique en passant par le traditionel su + mot de passe. Mais au final on doit presque toujours pouvoir y arriver. Pour le setuid tu pourras faire ce que t'autorise le programme ou plus si faille.

            > Ton "sudo" fait la résolution des alias toi ?

            Non mais alias su="mysu", ou utilisation des variables environement, ou keylogger ou faille local ou.... Bref des attaques veilles comme le monde qui fonctionneront sur 99.9% des machines, le reste étant sécurisé c'est une autre histoire :-)

Suivre le flux des commentaires

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