IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Tentative d'effraction par SSH


Sujet :

Sécurité

  1. #1
    Membre éclairé Avatar de jmelyn
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Septembre 2007
    Messages
    703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Septembre 2007
    Messages : 703
    Points : 823
    Points
    823
    Par défaut Tentative d'effraction par SSH
    Bonjour,

    J'ai installé Fedora 10 il y a quelques semaines et je vérifiais les logs à la recherche d'éventuelles erreurs lorsque je suis tombé sur le fichier de sécurité /var/log/secure. Il m'indiquait que depuis plusieurs jours, lorsque ma machine était allumée, "quelqu'un" tentait de se connecter par SSH comme root! J'ai en effet laissé ouvert le port 22 afin de pouvoir me connecter depuis le boulot.

    Voici une partie du log:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    Dec 12 16:12:50 ma_machine sshd[4781]: Failed password for root from 91.198.50.114 port 34694 ssh2
    Dec 12 16:12:50 ma_machine sshd[4782]: Received disconnect from 91.198.50.114: 11: Bye Bye
    Dec 12 16:12:52 ma_machine sshd[4783]: Address 91.198.50.114 maps to gateway.cybervisiontech.com.ua, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
    Comme j'ai envie de conserver une porte ouverte depuis l'extérieur, je dois renforcer son verrou! J'ai donc modifié le fichier de config de sshd pour l'utilisateur root puis redémarré le service:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    #PermitRootLogin yes
    PermitRootLogin without-password
     
    service sshd restart
    Cela veut dire que la connexion directe comme root utilisant l'authentification par mot de passe est refusée, mais la connexion par clé (RSA/DSA) fonctionne toujours. Cependant, le mot de passe est toujours demandé et à la troisième tentative la connexion est refusée, meme si le mot de passe est correct. Et sshd affiche chez le client:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Permission denied (publickey,gssapi-with-mic,password).
    Je trouve ce message indiscret, et en plus il est faux puisque l'option password n'est pas active pour root.

    Mes questions sont les suivantes:
    1) Est-il possible de désactiver la requete de mot de passe pour root?
    2) Est-ce que le changement de port SSH (22 --> 32 par exemple) est efficace pour éliminer les tentatives d'effraction?
    3) Voyez-vous d'autres choses à faire?

    Merci d'avances pour vos réponses.
    Un problème bien posé est déjà résolu (H. Bergson).

  2. #2
    Membre actif Avatar de SaintAmand
    Homme Profil pro
    Inscrit en
    Janvier 2006
    Messages
    174
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations forums :
    Inscription : Janvier 2006
    Messages : 174
    Points : 203
    Points
    203
    Par défaut
    Bonjour,

    Citation Envoyé par jmelyn Voir le message
    Mes questions sont les suivantes:
    1) Est-il possible de désactiver la requete de mot de passe pour root?
    Oui via une authentification par clés. Néanmoins il y a possibilité de protéger votre clé par une passphrase. Le recours à ssh-agent vous évitera de retaper votre passphrase à chaque ouverture d'une session ssh. Bien entendu celle-ci peut-etre vide mais c'est à vos risques et périls.

    2) Est-ce que le changement de port SSH (22 --> 32 par exemple) est efficace pour éliminer les tentatives d'effraction?
    Oui. Vous pouvez aussi utiliser fail2ban. Il permet de bannir automatiquement les IP après un certains nombres d'échecs. C'est très efficace contre les attaques par force brut.

    3) Voyez-vous d'autres choses à faire?
    http://www.linux-france.org/prj/edu/...e/ch13s03.html

  3. #3
    ovh
    ovh est déconnecté
    Rédacteur
    Avatar de ovh
    Homme Profil pro
    Architecte devops web full stack
    Inscrit en
    Mai 2002
    Messages
    3 841
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 46
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Architecte devops web full stack

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 841
    Points : 6 514
    Points
    6 514
    Par défaut
    Les logins par clé c'est bien, mais si tu dois pouvoir te connecter à ta machine depuis n'importe ordi, c'est pas gagné (tu ne te trimballes pas avec tes clés rsa sur toi tout le temps j'imagine, ou il n'y a pas toujours moyen de les utiliser, je pense aux cybers ou autres).

    Ceci dit c'est quand même une bonne chose à mettre en place

    MAIS, j'ajouterais d'abord ces règles-ci :
    - autoriser uniquement un user standard à se connecter à distance, et personne d'autre (ensuite, ce user devra faire un su pour avoir les droits d'admin; comme ça même s'il parvient à rentrer il ne sera que simple utilisateur et aura cette barrière supplémentaire à franchir)
    - changer le port par défaut pour un port > 1024 est très efficace contre la plupart des scanners automatiques qui ne scannent que les ports courants

    Tutoriels sur les UPS, e-commerce, PHP, critiques de livres...

    Pensez à consulter les FAQs et les cours et tutoriels.
    FAQ Linux - Cours et tutoriels Linux - FAQ PHP - Cours et tutoriels PHP
    Ce forum est fait pour vous et surtout par vous, merci d'en respecter les règles.

    Je n'ai rien à voir avec la société www.ovh.com !

  4. #4
    Membre éclairé Avatar de jmelyn
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Septembre 2007
    Messages
    703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Septembre 2007
    Messages : 703
    Points : 823
    Points
    823
    Par défaut
    1) J'utilise déjà les clés donc supprimer les connexions par mot de passe ne m'a pas gêné. Je n'utilise jamais les passphrases, fraudrait que j'y jette un coup d'oeil.

    2) Fail2Ban est directement dans la distribution Fedora 10 (version 0.8.3). Je viens de l'installer!

    3) J'ai plus qu'à me plonger dans la doc...

    Merci pour toutes ces infos.
    Un problème bien posé est déjà résolu (H. Bergson).

  5. #5
    Membre éclairé Avatar de jmelyn
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Septembre 2007
    Messages
    703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Septembre 2007
    Messages : 703
    Points : 823
    Points
    823
    Par défaut
    J'ai finalement réactivé le firewall de ma machine (je le désactivais systématiquement puisque mon routeur possède aussi un firewall) afin que fail2ban puisse être fonctionnel.

    Et puis j'ai supprimé l'accès à ma machine directement en root. Ainsi il faut connaître mon nom d'utilisateur, mais en plus j'ai un mot de passe à rallonge vraiment aléatoire avec beaucoup de caractères spéciaux (c'est d'ailleurs un peu gênant avec un clavier différent). Là, je me sens plus en sécurité.

    Et puis j'ai utilisé une nouvelle fonctionnalité de sudo (enfin, pas si nouvelle que ça quand même): sudo -i qui fait la même chose, a priori, que su -. Sauf qu'il est possible de paramétrer sudo pour que, de mon user, il n'y ait pas de demande de mot de passe.

    Voilà, maintenant je me sens plus à l'abri. Merci pour les conseils.
    Un problème bien posé est déjà résolu (H. Bergson).

  6. #6
    Membre éprouvé
    Profil pro
    Inscrit en
    Mai 2004
    Messages
    792
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2004
    Messages : 792
    Points : 1 206
    Points
    1 206
    Par défaut
    A ce qui a été dit plus haut je rajouterais:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    # restriction utilisateurs
    AllowUsers toto marcel jules etc...
     
    # ou, au niveau du groupe
    AllowGroups amis_ssh
     
    # restreindre les conditions de login
    LoginGraceTime 10
    MaxAuthTries 2
    Quant à l'utilisation de sudo comme tu l'as configuré, je serais plus nuancé. Si tu as mis un truc du genre : ton_user ALL = NOPASSWD: ALL autant te passer en root par su! Un script malveillant qui s'exécuterait sous ton username n'aurait qu'à faire sudo pour accéder à tout.

    Si tu es un nouvel utilisateur Linux, autant t'habituer directement à tout faire hors root. Il n'y a que peu de choses qui requièrent l'escalade en root. Et pour ces choses là, sudo *avec* passwd suffit. Et encore, en limitant le timeout de sudo. Si on court-circuite les sécurités qui existent dans Unix/linux/BSD depuis plus de 30 ans, on va finir par tomber dans les défauts de Windows!
    :q :q! :wq :w :w! :wq! :quit :quit! :help help helpquit quit quithelp
    :quitplease :quitnow :leave :shit ^X^C ^C ^D ^Z ^Q QUITDAMMIT
    Jabber: ripat at im.apinc.org

  7. #7
    Membre éclairé Avatar de jmelyn
    Homme Profil pro
    Administrateur systèmes et réseaux
    Inscrit en
    Septembre 2007
    Messages
    703
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 60
    Localisation : France

    Informations professionnelles :
    Activité : Administrateur systèmes et réseaux

    Informations forums :
    Inscription : Septembre 2007
    Messages : 703
    Points : 823
    Points
    823
    Par défaut
    Bonjour,

    Sur ma machine (maison), il n'y a que mon user et root qui n'ont pas /sbin/nologin. Donc la restriction sur les users est inutile. J'ai déjà LoginGraceTime 15 et MaxAuthTries 3. Mais je peux encore les réduire...

    À la maison, j'ai effectivement mon_user ma_machine = NOPASSWD: ALL. Ça m'évite de taper le mot de passe root à chaque fois que je veux faire une commande admin, et ça arrive souvent parce que c'est mon travail, alors je fais pas mal de tests. Et comme je coupe dès que j'ai terminé (habitude boulot), je passerais mon temps à taper le f...u mot de passe.

    Je suis d'accord avec toi pour ne pas utiliser le compte root lorsqu'on en a pas besoin, et surtout de ne pas donner des droits supplémentaires au user d'un administrateur (je fais des erreurs comme tout le monde), sauf que j'effectue le passage user --> root à longueur de journée. À moi de bien protéger mon compte...
    Un problème bien posé est déjà résolu (H. Bergson).

  8. #8
    Membre confirmé Avatar de Tchetch
    Inscrit en
    Mars 2002
    Messages
    401
    Détails du profil
    Informations personnelles :
    Âge : 39

    Informations forums :
    Inscription : Mars 2002
    Messages : 401
    Points : 477
    Points
    477
    Par défaut
    Bonjour,

    Citation Envoyé par ripat
    Si tu es un nouvel utilisateur Linux, autant t'habituer directement à tout faire hors root. Il n'y a que peu de choses qui requièrent l'escalade en root. Et pour ces choses là, sudo *avec* passwd suffit. Et encore, en limitant le timeout de sudo. Si on court-circuite les sécurités qui existent dans Unix/linux/BSD depuis plus de 30 ans, on va finir par tomber dans les défauts de Windows!
    Il y a des jours où l'on doit être avec les droits maximum toutes la journée. Maintenant, il y a un équilibre à trouver entre la sécurité et les besoins.

    Citation Envoyé par jmelyn
    Je suis d'accord avec toi pour ne pas utiliser le compte root lorsqu'on en a pas besoin, et surtout de ne pas donner des droits supplémentaires au user d'un administrateur (je fais des erreurs comme tout le monde), sauf que j'effectue le passage user --> root à longueur de journée. À moi de bien protéger mon compte...
    Et bien suivant tes besoins, il est des domaines où l'on est plus souvent en root qu'en utilisateur normal, donc ouais.

    Citation Envoyé par ovh
    changer le port par défaut pour un port > 1024 est très efficace contre la plupart des scanners automatiques qui ne scannent que les ports courants
    C'est une bonne solution.

    Un truc qui peut-être intéressant, c'est le port-knocking[1] et le web-knocking[2]. Des solutions intéressantes, mais j'ai jamais pris le temps de les tester (j'ai jamais eu le temps non plus par ailleurs), mais c'est un bon truc (perso je pencherais plus pour le web-knocking, car pas besoin de logiciel spécial).

    [1] http://en.wikipedia.org/wiki/Port_knocking
    [2] http://www.webknocking.de/semaphor.p...webknocking_en
    Mon wiki (on y parle Debian principalement) : http://www.tchetch.net/

Discussions similaires

  1. lancer server java par SSH
    Par goldorax113 dans le forum Réseau
    Réponses: 9
    Dernier message: 21/12/2006, 16h27
  2. Exécution du .profile impossible par SSH
    Par djanggawul dans le forum Réseau
    Réponses: 4
    Dernier message: 22/11/2006, 11h00
  3. Partage par ssh
    Par troumad dans le forum Réseau
    Réponses: 19
    Dernier message: 15/04/2006, 08h02
  4. Sauvegarde de base de donnée par SSH
    Par onet dans le forum Réseau
    Réponses: 2
    Dernier message: 05/03/2006, 22h42
  5. script de connexion par ssh
    Par black_code dans le forum Modules
    Réponses: 2
    Dernier message: 25/07/2005, 15h10

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo