• Home
  • Archives
  • À propos
  • Sitemap
  • Contact
Subscribe: Posts | Comments | E-mail
  • linuxSoftware is like sex, it's better when it's free
  • serveur
  • tutoriel
  • wallpapers

Phollow.me

Posted on February 4, 2010 - by Jérôme M.

Renforcer la sécurité de son serveur SSH

linux tutoriel

Le protocole SSH est utilisé pour transmettre des informations de manière sécurisé entre deux terminaux. Par exemple comme se loguer sur une machine distante, ou échanger des fichiers, le tout crypté. Il est de par sa conception très sécurisé, mais une mauvaise configuration peut tout gâcher.

Fichiers de configuration par défaut

  • /etc/ssh/sshd_config - Fichier de configuration du serveur SSH.
  • /etc/ssh/ssh_config – Fichier de configuration du client SSH
  • ~/.ssh/ – Répertoire de configuration SSH d’un utilisateur.
  • /etc/nologin – Si ce fichier existe, personne ne peut se connecter à part root.
  • /etc/hosts.allow et /etc/hosts.deny : Blacklist et whitelist .
  • SSH port par défaut : TCP 22

Utiliser le protocole SSH 2

Le protocole 1 est obsolète et vulnérable à de nombreuses attaques (comme man-in-the-middle). Il doit être évité à tout pris. Vérifiez dans le sshd_config que la ligne suivante existe :

Protocol 2

Choisir les utilisateurs

Par défaut n’importe quel utilisateur à le droit de se connecter en SSH. Par exemple un utilisateur ftp à la possibilité de se connecter. Ce n’est pas super pertinent. Alors on peut restreindre le serveur SSH à n’autoriser que certains compte utilisateur. Pour ça on peut utiliser (toujours dans le sshd_config)  :

AllowUsers root rydgel

Qui autorise ces 2 utilisateurs à pouvoir se connecter. Inversement la commande DenyUsers, permet de refuser la connexion.

Désactiver les fichiers .rhosts

Ces fichiers permettent de se connecter automatiquement au serveur sans avoir besoin de retaper le mot de passe. Sympa pour les feignants mais pas sécurisé du tout. Donc il vaut mieux désactiver l’utilisation de ces fichiers avant que quelqu’un ne tombe dessus ;)

IgnoreRhosts yes

Ajouter un timeout sur l’inactivité

Garder la session ouverte indéfiniment n’est pas non plus une bonne idée. Vous êtes au boulot, vous vous absentez une heure ou deux et vous oubliez de fermer votre session, n’importe qui peut attraper votre shell en root et faire ce qu’il veut pendant votre absence.

ClientAliveInterval 360
ClientAliveCountMax 0

Désactiver le login de root

Une autre manière de sécuriser est de désactiver le login de root et d’utiliser un user avec des droits moindres + sudo.

PermitRootLogin no

Changer le port par défaut d’openSSH

Le port 22 est connu par tous les pirates pour être celui d’openSSH. Les robots scannent en priorité ce port, pour le changer c’est tout simple :

Port 6345

N’autoriser que certaines IP à se connecter

Par exemple si je veux que seulement ces 2 adresses IP ait le droit de se connecter sur mon serveur (192.168.1.5 et 202.54.1.5). Il y a deux solutions. La première est d’utiliser les fichiers /etc/hosts.allow et /etc/hosts.deny. On commence par bloquer toutes les IPs dans le hosts.deny, puis on autorise seulement celles que l’on veut.

dans /etc/hosts.deny :
sshd: ALL
On bloque par défaut toutes les IPs, puis dans le /etc/hosts.allow :
sshd: 192.168.1.5
sshd: 202.54.1.5

La deuxième solution (et la meilleure à mon avis) est d’utiliser le firewall du système (iptables, pf) et d’autoriser seulement les IPs que l’on veut sur le port d’OpenSSH.

Utiliser un bon mot de passe

On voit encore trop souvent des mots de passe du style ‘12345′ ou ‘admin’. Le plus simple est de se créer un mot passe aléatoirement avec des chiffres, des lettres (majuscules et minuscules) et des caractères spéciaux. http://www.goodpassword.com/ est un site qui permet de le faire pour vous :)

Personne ne doit avoir un mot de passe vide

Vérifiez que les utilisateurs de votre machine n’ont pas de mot de passe vide. On peut aussi dire à OpenSSH de ne pas accepter les connexions d’utilisateurs sans mot de passe.

PermitEmptyPasswords no

Garder OpenSSH et votre système à jour

On ne le dira jamais assez mais les mises-à-jour sont vraiment importantes. Elles corrigent la plupart du temps des failles qui peuvent être utilisées par des pirates pour compromettre votre système. Personnellement je regarde si des mises à jours de sécurité sont disponibles tous les jours.

Désactiver OpenSSH si vous ne l’utilisez pas

Ça ne sert à rien de laisser des services ouverts sur l’ordinateur si vous ne vous en servez pas. Désinstallez le serveur openSSH s’il n’est pas utilisé. Ça fera toujours une porte de moins pour accéder à votre machine.

Conclusion

Il y a encore des dizaines de manips possibles pour augmenter encore plus la sécurité, comme le chrootage des utilisateurs, la configuration d’un firewall, l’installation de fail2ban contre les attaques brute-force etc. Mais je pense que ce petit article est un bon début, pour éviter de faire des bêtises sur son serveur.

This entry was posted on Thursday, February 4th, 2010 at 14:28 and is filed under linux, tutoriel. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

31 Comments

We'd love to hear yours!



  1. Visit My Website

    February 4, 2010

    Permalink

    phollow said:


    Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  2. Visit My Website

    February 4, 2010

    Permalink

    gonzague said:


    RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  3. Visit My Website

    February 4, 2010

    Permalink

    cr0vax said:


    RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  4. Visit My Website

    February 4, 2010

    Permalink

    Gonzague said:


    le changement de port ça te protège des script kiddies tout au plus non? :-)

    J’aurai bien ajouté qu’un petit fail2ban ne fait pas de mal ^_^

    Reply


    • Visit My Website

      February 4, 2010

      Permalink

      Jérôme M. said:


      Waip j’en parle à la fin de fail2ban ;)

      Mais je pense qu’il mérite à lui seul un billet, tellement on peut s’amuser avec :D

      Reply


  5. Visit My Website

    February 4, 2010

    Permalink

    LGnap said:


    Simple, basique mais hyper pratique ^^ -> à mettre en favoris ;-)

    Reply


  6. Visit My Website

    February 4, 2010

    Permalink

    kmb said:


    « Le protocole openSSH est utiliser  »

    -> utilisé
    -> OpenSSH n’est pas un protocole

    Reply


    • Visit My Website

      February 4, 2010

      Permalink

      Jérôme M. said:


      fixed ;)

      thanks

      Reply


  7. Visit My Website

    February 4, 2010

    Permalink

    kmb said:


    presque, SSH pas SSL ;-)

    Bonne journée

    Reply


  8. Visit My Website

    February 4, 2010

    Permalink

    pydubreucq said:


    RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  9. Visit My Website

    February 4, 2010

    Permalink

    Edouard said:


    « Il doit être éviter à tout pris » -> Il doit être évité à tout prix

    Bookmarked !

    Reply


  10. Visit My Website

    February 4, 2010

    Permalink

    hobbestigrou said:


    RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  11. Visit My Website

    February 4, 2010

    Permalink

    Nicolas said:


    la partie «N’autoriser que certaines IP à se connecter» est fausse, en aucun cas la directive ListenAdress ne limite les IPs qui sont autorisée à se connectées sur un serveur SSH.

    Reply


    • Visit My Website

      February 4, 2010

      Permalink

      Axel said:


      +1 pour le Listen Adress. Il permet juste de spécifier les interfaces d’écoute.

      Celà dit tu as raison, il faut aussi filtrer les IPs entrantes.

      Je pense qu’il faudrait également penser à désactiver le tunneling, SFTP, et SCP s’il y en a pas besoin et forcer explicitement l’utilisation d’algorithme de chiffrement authentification le plus robustes.

      Reply


    • Visit My Website

      February 4, 2010

      Permalink

      Jérôme M. said:


      Autant pour moi, je corrigerai ça ce soir.

      Reply


  12. Visit My Website

    February 4, 2010

    Permalink

    DuaelFr said:


    RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  13. Visit My Website

    February 4, 2010

    Permalink

    Alex57185 said:


    RT @talktweetmeme Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  14. Visit My Website

    February 4, 2010

    Permalink

    tshirtman said:


    Autoriser root à se connecter est une mauvaise idées, il y des bots qui bruteforces les mots de passes (d’ou l’intérêt de fail2ban) et avoir un user aussi commun que root autorisé, surtout avec les droits que ça impliques, c’est prendre un risque inutile… donc allowRootLogin = False ;)

    je vois moins l’intérêt du changement de port, c’est juste de l’obscurité, mais bon….

    Reply


    • Visit My Website

      February 4, 2010

      Permalink

      Jérôme M. said:


      Waip j’en ai parlé de ça :)

      Reply


    • Visit My Website

      February 5, 2010

      Permalink

      louiz’ said:


      Ben le changement de port ça sert déjà à éviter tous les bots qui tentent des centaines d’users et de login sur des centaines de machines, au hasard.

      Reply


      • Visit My Website

        February 5, 2010

        Permalink

        Jérôme M. said:


        Tout à fait !

        Reply


  15. Visit My Website

    February 4, 2010

    Permalink

    Logive said:


    RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  16. Visit My Website

    February 4, 2010

    Permalink

    S4RuM4N said:


    RT @phollow: Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


  17. Visit My Website

    February 4, 2010

    Permalink

    Edouard said:


    à tout priX ;)

    Reply


  18. Visit My Website

    February 4, 2010

    Permalink

    Bristow said:


    Merci pour tous ces rappels, c’est toujours mieux en français et avec quelques phrases d’explications ;)

    Reply


  19. Visit My Website

    February 4, 2010

    Permalink

    bartounet said:


    Tu aurais aussi put parler du port knocking, un bon moyen de se protéger tout en laissant ouvert un accès de n’importe ou.

    Reply


    • Visit My Website

      February 11, 2010

      Permalink

      Alex said:


      Le SPA (single packet authorization) pallie à de nombreux défaut du port-knocking.
      Sujet intéressant car c’est un grand classique.

      Reply


  20. Visit My Website

    February 5, 2010

    Permalink

    feilong said:


    L’authentification par clé public et clé privée serait un plus également.

    Si tu veux limiter l’accès à une adresse ip ou à un sous réseau, il faut passer par une configuration de iptables me semble t il.

    Reply


  21. Visit My Website

    February 5, 2010

    Permalink

    lepingouin said:


    Renforcer la sécurité de son serveur SSH | Phollow.me http://bit.ly/cMFkh0

    This comment was originally posted on Twitter

    Reply


  22. Visit My Website

    February 5, 2010

    Permalink

    dk88 said:


    Pour l’histoire du mot de passe, le mieux est évidement de ne travailler que par clef.

    Sinon pour générer un mot de passe « aléatoire », tu as la commande pwgen

    Reply


  23. Visit My Website

    February 15, 2010

    Permalink

    Darth_K0d3R said:


    RT @talktweetmeme Renforcer la sécurité de son serveur SSH http://goo.gl/fb/0bSC

    This comment was originally posted on Twitter

    Reply


Leave a Reply


Here's your chance to speak.

Cliquer ici pour annuler la réponse.

  1. Name (required)

    Mail (required)

    Website

    Message

  • Ad Ad Ad Ad
  • Search

  • Blogoliste

    • Antoine Guiral
    • Blog Jaune
    • Colibri
    • Cyrille Borne
    • Devil505
    • Divarvel
    • eGainMoney
    • FredZone
    • Ichigo
    • Jonasluthi.com
    • La pomme croquée
    • Lyricis
    • Mind Overflow
    • Planet Libre
    • SckyzO
    • Tadpu !
    • Tux Planet
    • Tuxargon
    • Uselink
    • Youyouk
  • Archives

    • mars 2010
    • février 2010
    • janvier 2010
    • décembre 2009
    • novembre 2009
    • octobre 2009
    • septembre 2009
    • août 2009
    • juillet 2009
    • juin 2009
    • mai 2009
    • avril 2009
    • mars 2009
    • février 2009
    • janvier 2009
    • décembre 2008
    • novembre 2008
    • octobre 2008
© 2008 Phollow.me - I am the visionaire, phollow me if you dare.
The Papercut theme by WooThemes - Premium Wordpress Themes