#Sécuriser votre nœud

L'objectif de ce guide est de vous accompagner dans les étapes que vous pouvez suivre pour sécuriser votre nœud contre les acteurs malveillants. Que vous exécutiez un serveur local chez vous ou un serveur VPS / machine virtuelle dans le cloud, les conseils présentés ici vous aideront à renforcer votre nœud contre les attaques extérieures et à le protéger tout au long de sa durée de vie.

Cette section décrit à la fois les actions essentielles, que vous devez entreprendre, et les actions souhaitables, qui sont utiles mais non obligatoires.

#Hypothèses de ce guide

Ce guide suppose que votre nœud fonctionne sous Ubuntu 20.04 LTS. Les concepts s'appliqueront à d'autres systèmes mais les exemples de commandes peuvent différer.

Comme pour toutes les commandes de ce guide, nous supposons que vous vous connectez à distance au terminal de commande de votre nœud en utilisant ssh. Si vous avez besoin d'un rappel sur l'utilisation de ssh, consultez d'abord le guide Introduction à Secure Shell.

#ESSENTIEL : Sécurisez votre machine cliente

La plupart des opérateurs Smartnode interagissent avec leur nœud à distance en se connectant à son terminal depuis un autre ordinateur en utilisant ssh :

• La machine à laquelle vous vous connectez (dans ce cas, votre machine de nœud) est appelée le serveur.
• La machine depuis laquelle vous vous connectez (comme votre ordinateur portable, ordinateur de bureau, ou même votre téléphone) est le client.

L'une des choses les plus importantes que vous puissiez faire pour sécuriser votre Smartnode est de maintenir votre machine cliente sécurisée. Si votre machine cliente est compromise et que vous l'utilisez pour vous connecter à votre nœud, la plupart des paramètres de sécurité que vous appliquez au nœud peuvent être contournés.

Par exemple : si vous utilisez un ordinateur portable comme client SSH, et qu'il a un enregistreur de frappe installé, alors toutes les choses secrètes que vous tapez sur le nœud (comme votre mot de passe ou votre mnémonique de récupération) lorsque vous êtes connecté via SSH seront volées.

Il n'existe pas de guide définitif pour sécuriser votre machine cliente, mais être conscient que c'est un facteur dans votre sécurité est une bonne première étape. Assurez-vous que votre machine cliente est aussi sécurisée que possible.

Voici quelques conseils :

• N'utilisez pas votre machine cliente pour des activités à risque (comme visiter des sites web peu fiables ou installer des programmes inutiles)
• Maintenez votre machine cliente à jour avec les derniers correctifs de sécurité
• Si possible, utilisez un programme de protection anti-malware et antivirus pour votre système d'exploitation

Pour une sécurité maximale, vous pourriez vouloir utiliser une machine dédiée comme client SSH, bien que cela ne soit peut-être pas pratique pour vous.

#ESSENTIEL : Sécurisez votre accès SSH

Que vous exécutiez votre Smartnode chez vous ou que vous utilisiez un VPS dans un centre de données distant, il est probable que vous y accédiez via SSH, ou que SSH soit activé même si vous ne l'utilisez pas.

Les connexions SSH sont basées sur une cryptographie sécurisée, mais comme pour tout système sécurisé, la vraie sécurité vient d'une utilisation correcte. Il y a deux choses principales à faire pour vos paramètres SSH :

1. Utiliser une clé SSH pour se connecter à distance au lieu d'un nom d'utilisateur et d'un mot de passe
2. Désactiver complètement l'authentification par mot de passe, de sorte que les clés SSH soient la seule option de connexion à distance

Comme vous en avez probablement l'habitude maintenant, la façon par défaut de se connecter à votre nœud via SSH est avec un nom d'utilisateur et un mot de passe. L'inconvénient de ceci est que votre mot de passe est généralement quelque chose de plutôt "court" et susceptible aux attaques par force brute.

Heureusement, il existe une autre façon de se connecter via SSH : une paire de clés SSH.

Les paires de clés SSH fonctionnent de manière similaire aux portefeuilles blockchain ; elles comportent une partie publique (comme votre adresse de portefeuille) et une partie privée (la clé privée pour votre adresse de portefeuille) :

• Vous fournissez la partie publique à votre nœud. De cette façon, le nœud sait que vous êtes autorisé à vous y connecter, et il sait que c'est vraiment vous qui essayez de vous connecter.
• Vous conservez la partie privée pour vous-même sur votre machine cliente. De cette façon, vous (et seulement vous) pouvez vous connecter à votre nœud.
  • Vous pouvez (et devriez !) protéger la partie privée avec un mot de passe, de sorte que quelqu'un qui vole votre clé ne puisse pas l'utiliser.
• Du point de vue d'un ordinateur, la clé privée est exponentiellement plus difficile à craquer qu'un mot de passe. Cela atténue le risque d'une attaque par force brute contre votre nœud.

#Création d'une paire de clés SSH

Commençons par créer une nouvelle paire de clés SSH sur votre machine cliente. Il existe de nombreuses variétés de clés, mais nous allons utiliser un type de clé appelé ed25519 qui offre une excellente sécurité.

Exécutez la commande suivante sur votre machine cliente (c'est-à-dire que vous ne devez pas exécuter ceci pendant que vous êtes déjà connecté en SSH à votre machine de nœud - si c'est le cas, quittez SSH d'abord) :

ssh-keygen -t ed25519 -C "your_email@example.com"

Vous verrez ce qui suit :

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/username/.ssh/id_ed25519):

Ceci vous demande où vous souhaitez enregistrer votre fichier de clé privée. SSH est compatible avec la valeur par défaut fournie et l'utilisera automatiquement pour vous si vous la sélectionnez. Cependant, vous avez la possibilité de la changer pour autre chose si vous le souhaitez.

Si vous êtes à l'aise avec le paramètre par défaut, appuyez simplement sur Entrée.

Sinon, tapez l'emplacement souhaité pour la clé. Ce doit être un chemin absolu (par ex. /home/username/.ssh/rocketpool_key sur Linux, ou /Users/username/.ssh/rocketpool_key sur OSX). Appuyez sur Entrée lorsque vous avez terminé.

Après avoir appuyé sur Entrée, vous verrez :

Enter passphrase (empty for no passphrase):

Ceci deviendra le mot de passe pour la clé privée elle-même. Chaque fois que vous utilisez la clé pour vous connecter à votre nœud, vous devrez d'abord entrer ce mot de passe.

Une fois que vous avez fini de taper le mot de passe, appuyez sur Entrée. Il vous demandera de le retaper pour confirmation.

Après cela, vous verrez quelque chose comme la sortie suivante :

Your identification has been saved in /home/username/.ssh/id_ed25519
Your public key has been saved in /home/username/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:CASbPZETiQ83lLhpUO2aoT05TxMVLwqiWtdsRtoPt4s your_email@example.com
The key's randomart image is:
+--[ED25519 256]--+
| .o*==..         |
|. +=O...         |
|..+B++o .        |
|..=.+X o         |
|.+.=+.O S        |
|o.B.oo + .       |
|.  = .  o        |
|    .  . .       |
|      E .        |
+----[SHA256]-----+

La première ligne indique l'emplacement de la clé privée, qui s'appelle id_ed25519 par défaut (notez qu'elle n'a pas d'extension de fichier). Ubuntu chargera cette clé pour vous automatiquement lorsque vous utilisez ssh si ce fichier de clé privée se trouve à l'emplacement par défaut.

La deuxième ligne indique l'emplacement de la clé publique, qui s'appelle id_ed25519.pub par défaut. Nous aurons besoin de la clé publique pour l'étape suivante.

ssh-add $HOME/.ssh/id_ed25519

eval $(ssh-agent)

nano ~/.bashrc

alias loadkey='ssh-add $HOME/.ssh/id_ed25519'

#Ajout de la clé publique à votre nœud

Une fois que vous avez votre paire de clés SSH, vous pouvez maintenant ajouter la clé publique à votre nœud. Cela vous permettra de vous y connecter via ssh en utilisant la clé privée que vous venez de générer, au lieu de votre nom d'utilisateur et mot de passe.

Il y a deux façons de le faire - si l'une ne fonctionne pas, essayez l'autre :

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub username@node.ip.address

ssh-copy-id -i $HOME/.ssh/id_ed25519.pub staker@192.168.1.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/username/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys

Number of key(s) added: 1

Now try logging into the machine with:   "ssh 'username@node.ip.address'"
and check to make sure that only the key(s) you wanted were added.

cat ~/.ssh/id_ed25519.pub

type %USERPROFILE%\.ssh\id_ed25519.pub

type $ENV:UserProfile\.ssh\id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGUgU3a6mNjy3N1TyWOwY+VA/nifAeABl2Ch2yIl1bGa your_email@example.com

mkdir -p ~/.ssh
nano ~/.ssh/authorized_keys

Vous devriez maintenant pouvoir vous connecter au nœud via ssh comme vous le feriez normalement, mais maintenant vous n'aurez pas à taper le mot de passe du compte utilisateur.

Au lieu de cela, vous devrez taper le mot de passe de votre clé privée SSH. En fonction des paramètres de votre système, vous devrez peut-être le faire une seule fois par redémarrage, ou vous devrez peut-être le faire à chaque fois que vous utilisez la clé pour vous connecter à votre nœud.

#Désactiver la connexion par mot de passe

Même si vous avez configuré une paire de clés SSH, votre nœud permettra toujours à d'autres machines d'essayer de se connecter en utilisant la méthode de nom d'utilisateur et mot de passe. Cela annule tout l'intérêt d'utiliser des clés SSH en premier lieu, donc l'étape suivante consiste à désactiver celles-ci.

Commencez par vous connecter à votre machine en utilisant ssh comme d'habitude :

ssh user@your.node.ip.address

Pour rappel, vous devriez faire ceci deux fois sur deux terminaux séparés afin d'avoir une session de secours au cas où. Vous pouvez ignorer la session de secours pour l'instant - nous vous dirons quand vous en aurez besoin. Exécutez les commandes suivantes uniquement dans la première session.

Ouvrez le fichier de configuration pour le serveur SSH :

sudo nano /etc/ssh/sshd_config

Comme pour toutes les commandes qui commencent par sudo, cela vous demandera le mot de passe de votre compte utilisateur. C'est un fichier volumineux, vous devrez donc naviguer dedans en utilisant les touches fléchées de votre clavier ou Page Up / Page Down.

Effectuez les modifications suivantes :

1. Décommentez #AuthorizedKeysFile s'il est commenté (en supprimant le # devant)
2. Changez KbdInteractiveAuthentication yes en KbdInteractiveAuthentication no et décommentez (en supprimant le # devant) - notez que les versions plus anciennes de SSH appellent cette option ChallengeResponseAuthentication au lieu de KbdInteractiveAuthentication
3. Changez PasswordAuthentication yes en PasswordAuthentication no et décommentez (en supprimant le # devant)
4. Changez PermitRootLogin yes en PermitRootLogin prohibit-password sauf s'il est déjà défini sur cela et a un # devant

Une fois que vous avez terminé, enregistrez avec Ctrl+O et Entrée, puis quittez avec Ctrl+X.

Enfin, exécutez sudo sshd -T | grep -i passwordauthentication et assurez-vous qu'il affiche passwordauthentication no. S'il ne le fait pas, vous devrez peut-être exécuter sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf et définir PasswordAuthentication yes sur PasswordAuthentication no dans ce fichier également. Enregistrez et quittez comme avant, avec Ctrl+O et Entrée, puis Ctrl+X

Ensuite, redémarrez le serveur SSH afin qu'il récupère les nouveaux paramètres :

sudo systemctl restart ssh.service

Après cela, la connexion à SSH via un nom d'utilisateur et un mot de passe devrait être désactivée.

#(Optionnel) Activer l'authentification à deux facteurs

L'authentification à deux facteurs implique de requérir une deuxième mesure de sécurité en plus de votre mot de passe ou clé SSH, généralement sur un appareil séparé de votre appareil principal.

Par exemple, vous connaissez peut-être la connexion à un site web tel qu'une plateforme d'échange de crypto en utilisant à la fois un mot de passe et un code Google Authenticator (ou un code SMS). Ce processus en deux étapes est un exemple d'authentification à deux facteurs.

SSH peut également être configuré pour requérir un code Google Authenticator, ce qui signifie qu'un attaquant qui aurait d'une manière ou d'une autre compromis votre clé SSH et sa phrase de passe aurait encore besoin de l'appareil avec l'application d'authentification dessus (présumablement votre téléphone). Cela ajoute une couche de sécurité supplémentaire à votre système.

Commencez par installer Google Authenticator (ou un équivalent compatible) sur votre téléphone si vous ne l'avez pas déjà. Pour les utilisateurs Android, considérez andOTP qui est une alternative open-source qui prend en charge le verrouillage par mot de passe et les sauvegardes pratiques.

Ensuite, installez le module Google Authenticator sur votre nœud avec cette commande :

sudo apt install -y libpam-google-authenticator

Maintenant, indiquez à PAM (pluggable authentication modules) d'utiliser ce module. D'abord, ouvrez le fichier de configuration :

sudo nano /etc/pam.d/sshd

Trouvez @include common-auth (il devrait être en haut) et commentez-le en ajoutant un # devant, de sorte qu'il ressemble à ceci :

# Standard Un*x authentication.
#@include common-auth

Ensuite, ajoutez ces lignes en haut du fichier :

# Enable Google Authenticator
auth required pam_google_authenticator.so

Ensuite, enregistrez et quittez le fichier avec Ctrl+O, Entrée, et Ctrl+X.

Maintenant que PAM sait utiliser Google Authenticator, l'étape suivante consiste à dire à sshd d'utiliser PAM. Ouvrez le fichier de configuration de sshd :

sudo nano /etc/ssh/sshd_config

Maintenant changez la ligne KbdInteractiveAuthentication no en KbdInteractiveAuthentication yes de sorte qu'elle ressemble à ceci :

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
KbdInteractiveAuthentication yes

(Les versions plus anciennes de SSH appellent cette option ChallengeResponseAuthentication au lieu de KbdInteractiveAuthentication.)

Ajoutez la ligne suivante en bas du fichier, qui indique à sshd qu'il nécessite à la fois une clé SSH et le code Google Authenticator :

AuthenticationMethods publickey,keyboard-interactive:pam

Ensuite, enregistrez et quittez le fichier avec Ctrl+O, Entrée, et Ctrl+X.

Maintenant que sshd est configuré, nous devons créer nos codes 2FA. Dans votre terminal, exécutez :

google-authenticator

D'abord, il vous demandera à propos des jetons basés sur le temps. Répondez y à cette question :

Do you want authentication tokens to be time-based: y

Vous verrez maintenant un grand code QR sur votre écran ; scannez-le avec votre application Google Authenticator pour l'ajouter. Vous verrez également votre secret et quelques codes de secours ressemblant à ceci :

Your new secret key is: IRG2TALMR5U2LK5VQ5AQIG3HA4
Your verification code is 282436
Your emergency scratch codes are:
  29778030
  86888537
  50553659
  41403052
  82649596

Enfin, il vous demandera quelques paramètres supplémentaires ; les valeurs par défaut recommandées sont les suivantes :

Do you want me to update your "/<username>/.google_authenticator" file: y
Do you want to disallow multiple uses of the same authentication token: y
By default... < long story about time skew > ... Do you want to do so: n
Do you want to enable rate-limiting: y

Une fois que vous avez terminé, redémarrez sshd afin qu'il récupère les nouveaux paramètres :

sudo systemctl restart sshd

Lorsque vous essayez de vous connecter en SSH à votre serveur avec vos clés SSH, vous devriez maintenant également être invité à entrer un code de vérification 2FA, mais pas de mot de passe.

#ESSENTIEL : Activer les mises à jour de sécurité automatiques

Les fournisseurs de systèmes d'exploitation publient régulièrement des mises à jour et des correctifs de sécurité, il est donc important que vous mainteniez votre système à jour avec les derniers correctifs. Le moyen le plus simple de le faire est d'activer les mises à jour automatiques.

Exécutez les commandes suivantes sur votre machine de nœud :

sudo apt update
sudo apt install -y unattended-upgrades update-notifier-common

Vous pouvez modifier les paramètres de mise à jour automatique en éditant /etc/apt/apt.conf.d/20auto-upgrades :

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

Voici un exemple de paramètres de mise à jour automatique raisonnables :

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
APT::Periodic::AutocleanInterval "7";
Unattended-Upgrade::Remove-Unused-Dependencies "true";
Unattended-Upgrade::Remove-New-Unused-Dependencies "true";

# This is the most important choice: auto-reboot.
# This should be fine since Rocketpool auto-starts on reboot.
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Lorsque vous avez terminé d'ajouter vos modifications, enregistrez avec Ctrl+O et Entrée, puis quittez avec Ctrl+X.

Ensuite, assurez-vous de charger les nouveaux paramètres :

sudo systemctl restart unattended-upgrades

#ESSENTIEL : Activer un pare-feu

En général, votre machine ne devrait accepter que le trafic réseau sur les ports que votre client Execution, client Consensus et pile Smartnode utilisent. Pour appliquer cela et empêcher tout trafic inattendu ou indésirable, nous pouvons installer un pare-feu sur le nœud.

Ubuntu est livré avec ufw installé par défaut (le uncomplicated fire wall), qui est un utilitaire pratique pour gérer les paramètres de pare-feu de votre nœud.

Les commandes suivantes configureront ufw avec une bonne configuration par défaut pour votre Smartnode. Exécutez-les sur votre machine de nœud.

Refusez les connexions sauf si elles sont explicitement autorisées par des règles ultérieures :

sudo ufw default deny incoming comment 'Deny all incoming traffic'

Autorisez SSH :

sudo ufw allow "22/tcp" comment 'Allow SSH'

Autorisez le client execution (anciennement appelé ETH1) :

sudo ufw allow 30303/tcp comment 'Execution client port, standardized by Rocket Pool'
sudo ufw allow 30303/udp comment 'Execution client port, standardized by Rocket Pool'

Autorisez le client consensus (anciennement appelé ETH2) :

sudo ufw allow 9001/tcp comment 'Consensus client port, standardized by Rocket Pool'
sudo ufw allow 9001/udp comment 'Consensus client port, standardized by Rocket Pool'

Si vous exécutez le client lighthouse v4.5.0+, vous pouvez utiliser le protocole quic pour réduire la latence / augmenter la bande passante, le protocole quic utilise le --port de lighthouse + 1 pour écouter les messages quic par défaut : https://lighthouse-blog.sigmaprime.io/Quic,%20Networking.html

sudo ufw allow 8001/udp comment 'Consensus client port, standardised by Rocket Pool'

Enfin, activez ufw :

sudo ufw enable

#(Optionnel) Activer la protection contre les attaques par force brute et DDoS

Pour protéger votre serveur des attaques DDoS et des tentatives de connexion par force brute, vous pouvez installer fail2ban. Ce programme surveillera les connexions entrantes et bloquera les adresses IP qui tentent de se connecter avec des informations d'identification erronées à répétition.

Consultez ce guide pour plus d'informations sur la prévention des intrusions.

Exécutez les commandes suivantes sur votre machine de nœud :

Installez le service :

sudo apt install -y fail2ban

Ensuite, ouvrez /etc/fail2ban/jail.d/ssh.local :

sudo nano /etc/fail2ban/jail.d/ssh.local

Ajoutez le contenu suivant :

[sshd]
enabled = true
banaction = ufw
port = 22
filter = sshd
logpath = %(sshd_log)s
maxretry = 5

Vous pouvez modifier le paramètre maxretry, qui est le nombre de tentatives qu'il autorisera avant de bloquer l'adresse incriminée.

Une fois que vous avez terminé, enregistrez et quittez avec Ctrl+O et Entrée, puis Ctrl+X.

Enfin, redémarrez le service :

sudo systemctl restart fail2ban

Et avec cela, vous venez de grandement améliorer la posture de sécurité de votre nœud. Félicitations !