Sommaire
Présentation
La plupart de temps, les hébergeurs livrent les VPS avec une IP publique (directement accessible sur internet) et le pare-feu n’est pas systématiquement activé.
Dans cet article, nous verrons comment sécuriser un VPS pour éviter qu’il soit la cible d’attaques automatiques. Pour cela, nous aborderons la configuration du service SSH, du pare-feu et plus encore.
Attention : Les configurations décrites ci-après peuvent entraîner une perte d’accès totale à votre VPS. Il est donc recommandé de faire un snapshot ou une sauvegarde avant de commencer. Vérifiez aussi que votre hébergeur propose une solution similaire au « Mode de secours » de Hostinger.
1) Mise à jour des paquets
Commencez par mettre à jour les paquets. Certains pourraient être obsolètes ou présenter des vulnérabilités corrigées dans de nouvelles versions.
|
1 |
sudo apt update -y && sudo apt upgrade -y |
Remarque : Si sudo n’est pas installé, passer à l’étape 2.
2) Installation de sudo
Installer sudo pour effectuer des opérations d’administration sans avoir à se connecter en tant que root.
|
1 |
apt install -y sudo |
3) Création d’un utilisateur différent de root
Créer un utilisateur différent de root et l’ajoutez au groupe sudo pour qu’il ait les droits d’administration sur le serveur.
Le but est d’éviter voire de s’interdire les connexions directes en tant que root.
3.1) Créer un nouvel utilisateur
|
1 |
sudo adduser myNewUser |
3.2) Ajouter l’utilisateur au groupe sudo
|
1 |
sudo usermod -aG sudo myNewUser |
3.3) Se connecter avec ce nouvel utilisateur
Ne plus utiliser le compte root pour se connecter au VPS mais ce nouvel utilisateur membre du groupe sudo.
|
1 |
ssh myNewUser@82.xxx.yyy.zzz |
Remarques :
Pour la suite de cet article, nous considérerons que vous êtes connecté en tant qu’utilisateur non-root et que sudo est installé. Les commandes suivantes seront donc précédées de sudo.
3.4) Autoriser la connexion par clé publique
Remarque : Nous supposons ici que vous avez déjà généré un couple clé privée et publique à la commande ssh-keygen.
Attention : Vous devez être connecté avec votre utilisateur non-root ou utiliser le chemin absolu /home/muNewUser/.ssh/authorized_keys.
3.4.1) Créer le répertoire .ssh à la racine du répertoire d’accueil de l’utilisateur non-root
|
1 |
mkdir ~/.ssh |
3.4.2) Éditer le fichier authorized_keys de l’utilisateur non-root
|
1 |
nano ~/.ssh/authorized_keys |
Ajouter le contenu de la clé publique sur une nouvelle ligne du fichier authorized_keys.
3.4.3) Vérifier la connexion ssh par clé
Relancer une connexion ssh pour vérifier le bon fonctionnement de la connexion ssh par clé. Dans mon cas, l’exemple serait :
|
1 |
ssh -i ~/.ssh/id_rsa myNewUser@82.xxx.yyy.zzz |
-i : Spécifier une clé privée si ce n’est pas ~/.ssh/id_rsa. (Je n’étais donc pas obligé d’utiliser -i dans mon cas précis)
4) Sécurisation du service ssh d’un VPS
Il faudra créer un nouveau fichier de configuration dans le répertoire /etc/ssh/sshd_conf.d.
4.1) Créer un nouveau fichier de configuration
|
1 |
sudo nano /etc/ssh/sshd_config.d/01-custom.conf |
Le nom de fichier 01-custom.conf est un exemple.
4.2) Éditer le fichier de configuration
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
# Modification du port d'écoute Port 48322 # PermitRootLogin # - no : Refuser catégoriquement la connexion pour l'utilisateur root # - prohibit-password : Refuser l’authentification par mot de passe pour l'uilisateur root PermitRootLogin no # Liste des utilisateurs autorisés à se connecter AllowUsers myNewUser myNewUser2 # Refuser l'authentification par mot de passe pour tous les utilisateurs PasswordAuthentication no # Idem que ci-dessus mais pour la nouvelle méthode plus sécurisée KbdInteractiveAuthentication no # Message avant connexion Banner /etc/issue.net |
Remarques :
La configuration ci-dessus est un exemple. Vous pouvez ajouter, modifier ou supprimer des directives en fonction de votre contexte. Pensez à modifier les valeurs Port et AllowUsers.
Attention :
L’interprétation des fichiers de configuration par OpenSSH est contre intuitive.
Pour éviter les confusions, n’utilisez un paramètre qu’une seule fois dans l’ensemble des fichiers de configuration. Certaines directives, comme PermitRootLogin, ne peuvent pas être surchargées. Seule la 1ère directive sera utilisée et les suivantes seront ignorées. Le fichier 01-custom.conf sera lu avant le 02-custom.conf.
Dans tous les cas, il faudra s’aider de la commande sshd -T pour afficher la configuration effective après lecture des fichiers de configuration par OpenSSH.
4.2) Vérifier la configuration
|
1 |
sudo sshd -T | egrep -i "^Port|^PermitRootLogin|^AllowUsers|^PasswordAuthentication|^KbdInteractiveAuthentication|^Banner" |
Remarques :
Si la valeur d’un paramètre n’est pas représentative de ce que vous avez renseigné, vérifiez que le paramètre n’est pas déjà renseigné dans un autre fichier. Si c’est le cas, il faudra supprimer ou commenter la ligne concernée. (Voir le paragraphe « Attention » plus haut).
4.3) Modifier le message connexion réseau
Il s’agit plutôt d’une dissuasion permettant d’avertir la personne qui tente de se connecter que toutes les activités sont enregistrées sur ce serveur.
Modifier le message avant connexion
|
1 |
sudo nano /etc/issue.net |
Contenu :
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
************************************************************************ * WARNING NOTICE * ************************************************************************ * * * This system is for the use of authorized users only. By accessing * * this system, you agree that your actions may be monitored and * * recorded. Unauthorized use of this system is prohibited and may be * * subject to criminal and/or civil penalties. All activities are * * logged. If you do not have authorization, terminate your session * * immediately. * * * * Authorized users may proceed with their login. * * * ************************************************************************ |
Il s’agit encore d’un exemple. Libre à vous de modifier ce message.
4.4) Redémarrer le service ssh
|
1 |
sudo systemctl restart ssh |
4.5) Vérifier la connexion ssh
Relancer une connexion ssh pour vérifier que vous êtes toujours autorisé à vous connecter à votre serveur. Dans mon cas, l’exemple serait :
|
1 |
ssh -i ~/.ssh/id_rsa myNewUser@82.xxx.yyy.zzz -p 48322 |
-p : Spécifier un port réseau différent de 22
-i : Spécifier une clé privée si ce n’est pas ~/.ssh/id_rsa. (Je n’étais donc pas obligé d’utiliser -i dans mon cas précis)
5) Configuration du pare-feu d’un VPS
Installer le pare-feu ufw pour sécuriser le serveur et le configurez pour refuser par défaut toutes les connexions entrantes.
Configurer ensuite des règles pour autoriser les connexions entrantes pour les services installés sur le serveur.
5.1) Installer ufw
|
1 |
sudo apt install -y ufw |
5.2) Interdire par défaut toutes les connexions entrantes avec ufw
|
1 |
sudo ufw default deny incoming |
5.3) Configurer des règles entrantes spécifiques pour vos services avec ufw
Les règles qui vont suivre sont des exemples. Ajustez-les en fonction de votre situation.
5.3.1) Autoriser le trafic entrant http et https avec ufw
|
1 2 |
sudo ufw allow http sudo ufw allow https |
http et https sont des alias pour configurer le flux web avec ufw. La règle IPv6 sera configurée. Le protocole UDP ne sera pas configuré, uniquement TCP.
5.3.2) Autoriser le trafic entrant ssh (personnalisé) avec ufw
|
1 |
sudo ufw allow 48322 |
Pour rappel : 48322 est le port d’écoute personnalisé choisi un peu plus haut pour le service ssh.
5.3.3) Autoriser la connexion ssh uniquement pour des adresses IP spécifiques
|
1 |
sudo ufw allow from 82.xxx.yyy.zzz to any port 48322 proto tcp |
from doit être suivi de l’adresse ip publique autorisée à se connecter sur le port 48322.
Vous pouvez créer la règle équivalent avec l’IPv6.
Remarque : Remplacez l’adresse IP et le port dans la commande précédente. Pensez à supprimer la règle précédente (Étape 5.3.2) si elle a été créée : sudo ufw delete allow 48322.
Attention : Si vous êtes dans l’incapacité de vous connecter à partir de cette IP Publique source (Ex : Adresse IP FAI non-fixe, Déménagement, changement de FAI, coupure réseau etc…). Assurez-vous de disposer d’une alternative, comme un terminal web ou un mode d’urgence dans le panneau de contrôle de votre hébergeur VPS.
5.4) Activer le pare-feu ufw
|
1 |
sudo ufw enable |
5.5) Vérifier les règles de pare-feu
|
1 |
sudo ufw status verbose |
Résultat :
5.6) Vérifier la connexion ssh
Relancer une connexion ssh pour vérifier que vous êtes toujours autorisé à vous connecter à votre serveur. Dans mon cas, l’exemple serait :
|
1 |
ssh -i ~/.ssh/id_rsa myNewUser@82.xxx.yyy.zzz -p 48322 |
-p : Spécifier un port réseau différent de 22
-i : Spécifier une clé privée ce n’est pas ~/.ssh/id_rsa. (Je n’étais donc pas obligé d’utiliser -i dans mon cas précis)
Voilà ! C’est terminé !
Vous avez enfin sécurisé votre VPS.
Il ne vous reste plus qu’à :
- Configurer des règles dans le pare-feu ufw
- Dormir sur vos 2 oreilles
- Utiliser la section commentaires pour me faire part de vos remarques ou problèmes rencontrés
En savoir plus sur Jj World
Subscribe to get the latest posts sent to your email.
Merci pour cet article, très utile pour comprendre les bases de la sécurisation d’un serveur virtuel.