Sécuriser un VPS / Serveur dédié Debian (9, 10, 11)
Debian

Sécuriser un VPS / Serveur dédié Debian (9, 10, 11)

Bonjour à tous,

Ces derniers temps j’ai pas mal travaillé sur mon VPS et je suis devenu obsédé par la sécurité. Alors bien sûr, le principal de la sécurité est une question de bon sens, mais la mise en place de certains éléments peut s’avérer essentielle pour l’améliorer. Je vais vous montrer comment configurer SSH, bloquer la connexion de l’utilisateur root, la mise en place de la connexion par clés SSH, et comment mettre en place Fail2ban pour une sécurité déjà avancée.

Au fil du temps mon dossier de favoris consacré à mon VPS est devenu très conséquent. Je me suis découvert une passion pour Linux. Cet OS sur lequel on ne tape que des lignes de commandes ou presque. Je vous partage donc ce que j’ai pu apprendre ces dernières semaines. À force de bloquer son serveur et de le réinstaller, on apprend !

Première connexion sur le serveur

Votre VPS ou serveur dédié fraîchement installé, on va commencer par s’y connecter. Personnellement j’utilise l’invite de commandes Windows, je ne passe par Putty. Pour utiliser le terminal de Windows, vous devrez activer OpenSSH

activation openssh windows 10 securité serveur webandsun

activation openssh windows 10 securité serveur webandsun

 

Vous n’avez plus qu’à cliquer sur Ajouter une fonctionnalité, chercher OpenSSH et l’installer. Vous pouvez voir sur ma capture d’écran qu’il est déjà installé de mon côté.

Pour vous connecter à votre serveur depuis le terminal Windows, tapez cette commande et adaptez là à votre cas.

ssh utilisateur@votreip

 

Une fois connecté on va commencer par mettre le système à jour :

sudo apt-get update && apt-get dist-upgrade

 

Le système mis à jour, on va changer le port de connexion SSH pour ceux qui le souhaitent. Cette étape n’est pas obligatoire, mais elle peut vous protéger d’un certain nombre de tentatives de connexion. En effet, le port 22 est le port par défaut. Il est très souvent attaqué par des robots qui crawl les sites web pour récupérer l’adresse IP du serveur. Sachez quand même que si vous changez le port de connexion vous ne pourrez sans doute pas vous connecter à votre serveur depuis votre travail, école, etc. Les autres ports sont généralement bloqués sur ce type de réseaux.

Changer le port par défaut de SSH

Rendez-vous dans le fichier config de SSH :

sudo nano /etc/ssh/sshd_config

 

Modifiez la ligne suivante pour y mettre la valeur voulue.
Attention de ne pas utiliser un port réservé. Choisissez donc une valeur entre 1024 et 65535 et notez là ! Mieux vaut ne pas perdre le numéro du port de connexion SSH…

Port 22

 

Une fois que c’est fait, sauvegardez votre fichier et redémarrez le service SSH.

systemctl restart sshd

Bloquer la connexion de l’utilisateur « root »

Nous allons créer un nouvel utilisateur. Choisissez-en un dont vous vous souviendrez, pas la peine de faire très original, évitez juste votre prénom, le nom de votre entreprise, « admin » etc… Question de bon sens !

sudo adduser

 

Pour la suite, libre à vous de remplir ou non les informations concernant l’utilisateur.

Maintenant on ajoute le nouvel utilisateur au fichier sudoers  pour qu’il puisse utiliser la commande sudo. Nous l’ajoutons au groupe root.

usermod -a -G sudo votre_identifiant

 

Pour voir si l’utilisateur a bien été ajouté au groupe, connectez vous dessus :

su votre_identifiant

 

Exécutez ensuite la commande :

sudo whoami

 

Si l’utilisateur est bien dans le groupe root, le terminal doit vous retourner sudo. Comme ci-dessous.

whoami sécuriser server debian 9 stretch

Je ne prends pas la peine de cacher mon nom d’utilisateur car comme j’ai bien fait les choses, c’est un utilisateur qui comme root, ne peut pas se connecter en SSH.

Une fois que c’est bon, déconnectez-vous de votre serveur et reconnectez-vous avec le nouvel utilisateur. C’est important car nous allons empêcher la connexion via l’utilisateur root. S’il y a eu un dysfonctionnement quelque part, vous ne pourrez plus accéder à votre serveur.

Si tout est bon, on retourne dans le fichier config SSH.

sudo nano /etc/ssh/sshd_config

 

Cherchez cette ligne :

#PermitRootLogin yes

 

et changez la en

PermitRootLogin no

On redémarre SSH

systemctl restart sshd

 

Bravo ! Vous venez de changer le port de connexion et empêcher root de s’y connecter. Dans les faits nous n’avons pas fait grand chose mais ça vous évitera déjà beauuuuucoup d’ennuis.

Connexion par clé SSH

La connexion par clé SSH est une méthode de connexion plus sécurisée que le mot de passe et moins contraignante si vous vous connectez souvent à votre serveur depuis le même ordinateur. En effet, avec cette méthode, plus besoin de mot de passe, enfin presque. Seulement une passphrase pour confirmer qu’il s’agit bien de vous et pas de n’importe quelle personne utilisant votre ordinateur. Étant donné qu’il ne sera pas possible pour une personne extérieure de faire un brute-force pour trouver votre passphrase, pas besoin de définir quelque chose de très compliqué.

Je vais vous expliquer la démarche à suivre si vous utilisez le terminal Windows. Si vous utilisez Putty, je vous invite à regarder ici.

On commence par générer les clés, il suffit d’aller dans l’invite de commandes Windows (déconnectez-vous de votre serveur ou ouvrez en un autre si vous utilisez le terminal Windows pour accéder à votre serveur) et de taper la ligne suivante :

ssh-keygen -t rsa -b 4096

 

Par défaut c’est une clé 2048 bits qui est générée. Dans un souci de paranoïa, j’utilise le 4096. J’indique donc que je souhaite une clé de 4096 bits.

Ce qui nous donne ce résultat :

C:\Users\Vous>ssh-keygen -t rsa -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (C:\Users\Vous/.ssh/id_rsa):

 

Indiquez l’endroit où la clé doit-être enregistrée. Vous pouvez juste indiquer un nom de fichier et la clé sera enregistrée à la racine du dossier C:\Users\Votre_Nom. On vous demande ensuite d’ajouter une passphrase. Libre à vous de le faire. Je vous le conseille, et n’allez pas chercher très loin. Puis c’est censé être une passphrase pas un mot de passe. Donc mettez une phrase facile, qui vous faire rire ou comme vous voulez, mais c’est censé sécuriser votre connexion tout en vous facilitant la vie.

Vous vous retrouvez donc avec 2 fichiers portant le même nom, à la différence que l’un des deux contient l’extension .pub. C’est le fichier contenant la clé publique. La clé que vous devez autoriser sur le serveur.

Maintenant il faut indiquer au serveur quelle clé ils doit autoriser et pour quel utilisateur. Donc si vous avez suivi, ça ne sera pas root.

Connectez-vous à votre serveur, et mettez-vous sur l’utilisateur avec lequel vous voulez utiliser la connexion par clé SSH.

Tapez la commande suivante pour éditer le fichier autorisant les clés :

nano .ssh/authorized_keys

 

Si le dossier n’existe pas, pas de panique. Exécutez ces commandes une par une.

cd
mkdir .ssh
touch .ssh/authorized_key
touch .ssh/instance_keys
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
chmod 600 .ssh/instance_keys

 

Une fois que c’est fait, on recommence :

nano .ssh/authorized_keys

 

Vous n’avez plus qu’à copier / coller la clé contenue dans votre_fichier.pub.

Attention avec cette méthode (insérer les clés manuellement) elles vont être effacées lors du prochain reboot de votre serveur. Vous devez donc aussi mettre la clé dans le fichier instance_keys.

On redémarre :

systemctl restart sshd

 

Déconnectez-vous de votre serveur, et reconnectez-vous en utilisant cette commande :

ssh -i C:\Path\to\your\key utilisateur@votre.ip -p votre_port

 

Le -i sert à indiquer à Windows qu’il doit envoyer tel fichier lors de la connexion. Vous envoyez donc le fichier ne contenant pas l’extension .pub.

Si tout va bien, le serveur vous demande votre passphrase, et hop vous êtes connecté !  Magique.

Si tout fonctionne, vous pouvez donc désactiver la connexion par mot de passe. On retourne une fois de plus dans le fichier config SSH :

sudo nano /etc/ssh/sshd_config

 

Si vous souhaitez bloquer la connexion par mot de passe pour un seul utilisateur ajoutez les lignes suivantes :

Match user mon_utilisateur
PasswordAuthentication no

 

Si vous préférez forcer la connexion avec clé SSH pour tous les utilisateurs, rendez-vous aux lignes suivantes :

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

 

Décommentez les lignes et changez yes par no. Ce qui donne,

# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
PermitEmptyPasswords no

 

Sauvegardez, et redémarrez SSH

systemctl restart sshd

 

Vous pouvez maintenant vous connecter uniquement en utilisant votre clé SSH.

Faites quand même le test, essayez de vous connecter en utilisant :

ssh votre_identifiant@votre.ip -p votre_port

 

Vous devriez avoir ce type de réponse

votre_identifiant@votre.ip: Permission denied (publickey).

Il ne vous reste plus qu’à installer Fail2ban et vous serez protégé de la majorité des robots !

 

Installation et configuration de fail2ban

Fail2ban bloque les adresses IP appartenant à des hôtes qui tentent de casser la sécurité du système.

Il lit les logs de divers services (SSH, Apache, FTP…) à la recherche d’erreurs d’authentification répétées et ajoute une règle iptables pour bannir l’adresse IP de la source.

Vous l’aurez compris, Fail2ban sert à bannir les adresses IP qui tentent de se connecter à votre serveur. Il n’agit pas en temps réel. Il regarde les logs pour trouver les erreurs récurrentes. Vous allez voir que le nombre d’IP bannies va grimper à vitesse grand V si vous avez laissé le port 22.

 

fail2ban debian webandsun

Installation

On installe Fail2ban :

sudo apt-get install fail2ban

 

et on fait une copie du fichier jail.conf pour pouvoir revenir à la config de base en cas d’erreurs.

cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.conf.save

 

Configuration

Nous allons maintenant modifier ce fichier pour activer la surveillance des ports voulus :

sudo nano /etc/fail2ban/jail.conf

 

Première étape, autoriser sa propre IP pour éviter qu’elle soit bannie.

Cherchez la ligne suivante

ignoreip = 127.0.0.1/8

 

et ajoutez-y votre IP. Pas besoin de spécifier le masque de sous réseau. Ce qui donne par exemple

ignoreip = 127.0.0.1/8 1.1.1.1.1

 

Paramétrage

On va passer à la configuration par défaut qui s’appliquera aux prisons que vous allez activer.

Bantime correspond au temps que l’IP sera bannie (en seconde). La valeur par défaut est de 600 soit, 10 minutes. Vous pouvez mettre la valeur que vous voulez, mais il faut la spécifier en secondes. Si vous souhaitez mettre en place des ban définitifs, il vous suffit d’indiquer une valeur négative. Personnellement elle est définie sur -1.

bantime = 600

 

Il y a ensuite maxretry. Je ne sais plus quelle est la valeur par défaut, mais je la définie sur 3. Au final dans la vie courante, on a souvent le droit à 3 essais avant d’être bloqué, comme avec une carte bancaire.

maxretry = 3

 

Pour finir, nous avons findtime. Ce paramètre correspond à l’intervalle de temps entre le nombre d’occurrences. En d’autres termes, si vous avez un maxretry de 6 et un findtime de 300 (5 minutes), si une personne essaye de se connecter 5 fois à raison de 1 fois par minute, elle ne sera jamais bannie. Car elle aura fait 5 tentatives en 5 minutes et il en faut 6 pour un ban.

J’ai donc défini le findtime à 86400 ce qui correspond à 24h.

findtime = 86400

 

Pour récapituler, avec ma config actuelle toute  IP échouant 3 fois en 24h pour se connecter, est bannie définitivement. Ou du moins jusqu’à ce que je décide le contraire.

Je vous conseille dans un premier temps de vous laisser un peu de marge sur le maxtry  et le bantime. En cas de mauvaise manipulation, ça vous évitera un ban définitif ou trop long. Une fois que vous serrez sûr de vous, vous pourrez être plus strict et vous permettre (comme moi) d’être sévère sur les ban.

Maintenant que la configuration par défaut est paramétrée, on active la prison SSHD.  Vous pouvez (si vous le souhaitez) ajouter ces lignes directement à la fin de votre fichier jail.conf.

Il est possible de définir des paramètres autres que ceux par défaut en ajoutant maxretry =, findtime =, bantime =  dans les lignes qui suivent.

Les prisons

Petite précision, [sshd] correspond au nom de la prison. Vous pouvez modifier le nom si le cœur vous en dit, mais par souci de gestion, je ne le vous conseille pas.

[sshd]
enabled = true
port = ssh, sftp
filter = sshd
logpath = /var/log/auth.log

 

Chaque prison est configurée par défaut sur :

enabled = false

 

Il est donc important d’insérer cette ligne pour l’activer :

enabled = true

 

La ligne port indique le port qui doit être surveillé. Vous pouvez indiquer comme moi les protocoles, ou le port de SSH. 22 par défaut, ou la valeur que vous avez choisie.

port = ssh, sftp

 

Filter indique à Fail2ban quel filtre il doit utiliser. Ici, sshd.
Logpath est la localisation de vos fichiers logs. Sans l’accès à ces fichiers, Fail2ban ne pourra pas faire son travail.

On enregistre, on quitte le fichier et on active le service.

service fail2ban start

 

Vous pourrez vérifier l’état de vos prisons avec

fail2ban-client status

 

et si vous souhaitez voir une prison particulière :

fail2ban-client status nom_de_la_prison

 

Nous venons de faire la configuration basique de Fail2ban. Si vous souhaitez ajouter des prisons présentes par défaut, vous connaissez maintenant la démarche. Si vous voulez ajouter des prisons personnalisées, je vous invite à faire quelques recherches. Il y a de nombreux scripts disponibles sur internet. N’oubliez pas de vérifier ce que vous ajoutez sur votre serveur, encore une fois, la sécurité c’est principalement une question de bon sens.

Vous trouverez plus d’informations et de commandes sur le site officiel de Fail2ban.

 

Je reviens bientôt pour vous parler de l’installation de LAMP et de la sécurisation de vos sites web.

 

kermit thumbs up webandsun

5/5 (5 Reviews)
Partager
Written by Antoine Lounis

6 Comments

  • Nicolas 8 novembre 2018 at 22 h 52 min

    Sympa ! Bien apprécié le rappel de l’utilisation des clés SSH avec un mot de passe dessus 🙂

    Pour ma part, je me suis basé sur les recommandations Lynis pour sécuriser mon serveur (qq options en plus dans sshd_config).

    Reply
    • Antoine Lounis 9 novembre 2018 at 20 h 43 min

      Merci 🙂
      Je ne connaissais pas Lynis, ça a l’air vraiment pas mal. Je vais creuser le sujet !

      Reply
  • Moi 9 novembre 2018 at 20 h 32 min

    Salut, bel article.
    Petite erreur dans : usermod -aG sudo votre_identifiant
    Il s’agit de usermod -a -G sudo votre_identifiant plutôt, non ?

    Reply
    • Antoine Lounis 9 novembre 2018 at 20 h 40 min

      Merci 🙂
      Sauf erreur de ma part, les 2 solutions fonctionnent

      Reply
  • Pierre Le Pallec 12 novembre 2018 at 15 h 37 min

    Salut, très bon article riche en bons conseils !
    Si tu veux pousser un peu plus loin regarde du côté de Knockd et des policy Iptables 🙂

    Reply
    • Antoine Lounis 12 novembre 2018 at 21 h 58 min

      Merci 🙂
      Iptables je connais mais je n’en ai pas parlé ici. L’article était déjà suffisamment assez long. Je vais regarder pour Knockd !

      Reply

    Please Post Your Comments & Reviews

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

    Instagram

    Instagram n'a pas retourné le status 200.

    Follow us