[Debian] Sécuriser (un minimum) le SSH

Le protocole SSH peut être utilisé à diverses & nombreuses finalités, comme l’envoi crypté de documents sur FTP (ce qui est appelé SFTP), ou encore la connexion à distance d’un utilisateur sur une machine pour faire de la télé-maintenance, etc…

Cependant, ce protocole est souvent la cible d’attaques récurrentes effectuées par les pirates…


Pour mettre en place quelques règles de sécurité et ainsi paralyser les pirates lambda peu connaisseurs (Script-kiddies), je vais modifier & ajouter des règles dans le fichier de configuration du serveur SSH. Ce fichier se trouve (par défaut) dans le dossier « /etc/ssh/« . Nous devons modifier « sshd_config« .

cp /etc/ssh/sshd_config /etc/ssh/sshd_config-BACKUP && nano sshd_config

N.B. : Le fichier de configuration a été dupliqué pour garder une version originale du fichier de configuration, en cas de pb ou d’erreur de manipulation.

Une fois dans le fichier, certaines options sont déjà paramétrées par défaut :

  • Port 22 –> Numéro du port de connexion SSH
  • Protocole n° 2 (Version SSH la plus sécurisée à se jour)
  • Utilisateur « Root » interdit pour se connecter en SSH
  • Pas d’authentification par clés

Ces options sont viables pour de petits serveurs locaux de tests, mais malheureusement connues de tous, et surtout des pirates. De plus, elles peuvent être facilement trouvables sur le net, puisque se sont les options par défaut de tous les serveurs SSH.


I. Numéro de port

Le port 22 est à changer, même si celui-ci n’offre qu’une « faible protection » : il sera un peu plus difficile à trouver pour certains (soi-disant) pirates. Prenez un numéro aléatoire (6832, 9812, 45282…) et non pas un numéro facilement identifiable / repérable, comme 1234, 12345, 222, 2222
Attention, il se peut que certains ports soient déjà utilisés, faites donc attention lors de votre choix, prenez des ports au dessus de 2000.

Soit dans le fichier de configuration :

Port 58273


II. Autoriser / bloquer des utilisateurs

Avec ce paramètre, vous restreignez grandement l’accès SSH. En effet, en autorisant des utilisateurs spécifiques ou un groupe d’utilisateurs, un pirate devra trouver d’une part quel utilisateur peut se connecter, mais aussi le mot de passe de cet utilisateur
De plus, en bloquant les utilisateurs « types » utilisés par certains services installés sur votre serveur (MySQL, Python etc…), vous bloquerez les tentatives de certains pirates.

AllowUsers user1 user2
DenyUsers root MySQL


III. Empêcher l’utilisateur « Root » de se connecter

Aujourd’hui, les configurations SSH des serveurs Linux ont évoluées : L’utilisateur « root » ne peut plus se connecter par défaut sur le serveur via SSH.
Vous pouvez toutefois lever cette interdiction en cherchant la ligne suivante :

PermitRootLogin no

Et remplacer « no » par « yes ».


IV. « Activer » l’authentification par clés

// PARTIE EN COURS DE SAISIE


Vous aussi, participez à l’élaboration de cet article ! Envoyez-moi vos astuces par e-mail ou par commentaires pour que je puisse continuer cet article ! 🙂

Julien H

Passionné depuis toujours par l'informatique, je transforme ma passion en expertise. J'utilise quotidiennement les outils et systèmes Microsoft. Je ne délaisse pas mon côté ouvert, notamment via l'utilisation des OS Debian et Archlinux. L'infosec m'ouvre les yeux sur les enjeux actuels et futurs de l'IT.

3 commentaires

  1. Je complèterais également avec l’outil FAIL2BAN qui est très pratique pour éviter les brutes forces en bloquant les ip et il avertit par mail 😉

    Ta commande « cp /etc/ssh/sshd_config /etc/ssh/sshd_config-BACKUP && nano sshd_config »
    ne fonctionnera pas, enfin… Ton fichier de config’ que tu créé avec « nano » ne fonctionnera pas et de sera pas pris en compte par le serveur ssh. Ton « nano sshd_config » va créer le fichier de config dans ton répertoire courant ($home)

    Soit tu fais
    cd /etc/ssh/
    cp sshd_config sshd_config-BACKUP && nano sshd_config

    ou alors
    cp /etc/ssh/sshd_config /etc/ssh/sshd_config-BACKUP && nano /etc/ssh/sshd_config

    Sinon cool !
    Et surtout bonne année !

    1. Merci pour ces informations complémentaires !
      En effet, FAIL2BAN est vraiment l’outil en plus à avoir absolument – Il est dans ma todo-list, je dois m’y mettre… ! 😉

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

Share This
Fermer
Fermer