Comment déployer des nodes sentinelles dans le réseau Archway ?
Lors du déploiement d'un node basé sur Cosmos SDK tel qu'Archway, nous devons garder à l'esprit que les réseaux P2P sont exposés au risque d'attaques par déni de service, et qu'un moyen efficace d'atténuer ce type d'attaque est d'utiliser des nodes sentinelles.
Pourquoi est-il important de prévenir les attaques par déni de service (DDOS) ?
Lorsque notre node subit une attaque par déni de service qui ne peut être contrée par le fournisseur du serveur, il est probable que ce dernier soit inopérant pendant la durée de l'attaque, car, étant saturé, il cessera de répondre aux demandes formulées par le reste des nodes du réseau.
Si notre node devient inopérant, cela signifie que nous ne participons plus aux tours de consensus, notre node ne signera plus de blocs et ne générera plus de récompenses pour les délégateurs et en l'espace de quelques minutes, le node sera mis en cage et pénalisé.
En plus d'être un risque pour les opérateurs de nodes en raison des pénalités liées à la mise en cage, c'est aussi un risque pour le réseau, car si plusieurs nodes sont attaqués en même temps, la stabilité et la sécurité du réseau en seraient affectées.
Les réseaux P2P
Un réseau P2P (peer-to-peer), comme celui d'Archway, est un réseau où un ensemble d'ordinateurs (2, 10 ou 130, peu importe le nombre) sont interconnectés les uns avec les autres. Contrairement à ce qui se passe lorsque nous visitons une page Web où il y a un serveur auquel nous adressons une requête, il n'y a pas de serveur central dans un réseau P2P, mais toutes les machines sont égales entre elles et communiquent en permanence pour effectuer la validation des blocs du réseau.
Le problème des réseaux P2P est que pour que les différentes machines (nodes) qui font partie du réseau puissent communiquer entre elles, un point d'entrée est nécessaire pour établir les connexions ; ce point d'entrée est l'adresse IP et le port. Connaissant l'adresse IP et le port P2P de la machine, les autres nodes du réseau peuvent lui adresser des requêtes et, en bref, l'intégrer au réseau P2P, mais c'est aussi le point d'entrée pour les attaques par déni de service d'un attaquant.
Les nodes sentinelles, qui cachent l'IP de notre validateur au reste du monde
Comme mentionné précédemment, lorsque nous exposons l'IP de notre node validateur, le reste des nodes du réseau peut se connecter à nous, mais nous permettons également à quiconque de saturer notre machine.
L'utilisation de nodes sentinelles est une solution pour empêcher le reste du réseau de connaître l'IP de notre node validateur, mais en permettant à notre node validateur de continuer à communiquer avec d'autres nodes validateurs dans le réseau Archway, car si le node était isolé à 100 %, il ne pourrait pas participer au réseau et ne générerait donc pas de récompenses pour les délégateurs.
Un node sentinelle est un pont entre notre node validateur et le reste du réseau, de sorte que le reste du réseau ne connaît pas l'IP du node validateur, mais l'IP des nodes sentinelles.
Comme vous pouvez le voir dans l'image ci-dessus, le « node validateur » n'est connecté qu'à nos nodes sentinelles, mais pas au reste du réseau. Ainsi, seuls les nodes sentinelles connaîtront l'IP de notre node validateur.
Les nodes sentinelles peuvent-ils subir des attaques DDOS ?
Oui, mais comme il s'agit de nodes qui ne valident pas les transactions et qu'ils ne font que servir de pont entre le réseau et le node validateur, nous pourrions rapidement déployer de nouveaux nodes sentinelles ou même changer l'adresse IP du node sentinelle attaqué.
Combien de nodes sentinelles peut-il y avoir ?
Il n'y a pas vraiment de nombre maximum, plus nous avons de nodes sentinelles, plus notre node validateur sera résistant aux attaques par déni de service. Cependant, il faut tenir compte du fait que plus nous avons de nodes sentinelles, plus il sera complexe de maintenir nos nodes lors de la réalisation de la maintenance ou des mises à jour, en plus de l'augmentation des coûts du serveur. Vous devriez avoir au moins deux nodes sentinelles et si possible avoir l'un d'entre eux dans un centre de données différent de celui où est hébergé le node validateur.
Où les nodes sentinelles doivent-ils être hébergés ?
Si deux nodes sentinelles doivent être montés, l'un d'entre eux peut l'être dans le même centre de données que notre node validateur, ce qui réduira la latence entre les deux serveurs et, par conséquent, la connexion entre les deux serveurs sera assez rapide. L'autre node sentinelle pourrait être situé dans un centre de données différent ; de cette façon, au cas où le réseau du centre de données où se trouve notre node validateur serait en panne pour une raison quelconque, nous aurions toujours un node avec le bloc actuel disponible pour synchroniser notre node validateur.
Guide étape par étape
Pour suivre ce guide, nous utiliserons un node créé dans le testnet torii-1 d'Archway. Au cas où vous n'auriez pas encore déployé le node, vous pouvez vous appuyer sur la documentation officielle d'Archway ainsi que sur la documentation spécifique à torii-1.
Création des nodes sentinelles
Une fois que nous avons contracté les deux serveurs des nodes sentinelles et que nous avons les IP d'accès, nous devons effectuer la même installation que s'il s'agissait d'un node validateur sur les deux serveurs.
🚀 Astuce : si vous utilisez MobaXterm, vous pouvez utiliser l'option MultiExec pour effectuer les mêmes commandes sur les deux serveurs en même temps.
Tout d'abord, nous devons télécharger et compiler le binaire d'Archway.
git clone https://github.com/archway-network/archway
cd archway
git checkout main
Remarque : il est possible qu'à l'avenir, la branche principale ne soit pas la plus appropriée et qu'il soit nécessaire de télécharger la version publiée dans la documentation officielle d'Archway. Dans tous les cas, la version doit être la même que celle que nous avons dans notre node de validation.
Une fois téléchargée, nous allons procéder à la compilation du binaire :
make install
Il faudra également initialiser le node pour que le répertoire .archway soit créé, pour cela nous pouvons utiliser les commandes suivantes, chacune dans le serveur correspondant :
- Sur le node sentinelle A :
archwayd init "Stakely.io - Sentry A" --chain-id torii-1
- Sur le node sentinelle B :
archwayd init "Stakely.io - Sentry B" --chain-id torii-1
Une fois l'étape précédente effectuée, le dossier .archway sera créé, nous pouvons donc télécharger le fichier genesis.json :
curl -s https://raw.githubusercontent.com/archway-network/testnets/main/torii-1/genesis.json > ~/.archway/config/genesis.json
Enfin, nous allons configurer le service d'Archway :
sudo nano /etc/systemd/system/archway.service
Avec le contenu suivant, n'oubliez pas de remplacer l'utilisateur que vous utilisez à l'endroit où il est indiqué <utilisateur ici>.
[Unit] Description=Archway Daemon After=network-online.target
[Service] User=<usuario aquí> ExecStart=/home/<usuario aquí>/go/bin/archwayd start --p2p.laddr tcp://0.0.0.0:26656 --home /home/<usuario aquí>/.archway Restart=on-failure RestartSec=3 LimitNOFILE=4096
[Install] WantedBy=multi-user.target
Une fois l'édition terminée, nous allons activer le service :
sudo systemctl enable archway
Configuration de base des nodes sentinelles
Pour l'instant, il n'y a rien de différent de ce que nous ferions lors de la configuration d'un node validateur, bien qu'il y ait plusieurs choses que nous n'avons pas faites, comme créer le wallet ou exécuter la commande de création du validateur « tx staking create-validator ». En effet, nous ne voulons pas créer de nodes validateurs, seulement des nodes qui se synchronisent avec le reste des nodes du réseau et que nous pouvons utiliser pour synchroniser notre node validateur de manière sécurisée sans exposer notre IP au reste du réseau.
Les nodes sentinelles (les deux) doivent avoir des pairs pour être synchronisés à tout moment, nous allons ajouter les pairs suivants au fichier config.toml dans le dossier config.
persistent_peers = "[email protected]:26656,[email protected]:46656,[email protected]:26656,[email protected]:26756,[email protected]:30273,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26656,[email protected]:26686"
Remarque : les pairs ont été obtenus depuis Discord dans le canal de torii-1.
Il serait également souhaitable d'ajouter comme persistent peer les nodes sentinelles eux-mêmes les uns aux autres. En d'autres termes, faites du node sentinelle B un pair persistant du node sentinelle A, de la même manière que le node sentinelle A est un pair persistant du node sentinelle B ; cela nous donnera plus de redondance.
Dans le fichier config.toml du dossier config des nodes sentinelles (les deux), il est nécessaire de spécifier l'ID du node validateur dans le paramètre private_peer_ids. Ceci afin que nos nodes sentinelles ne partagent jamais avec le reste des pairs du réseau l'existence de notre node validateur.
private_peer_ids = "node validateur"
Cela devrait ressembler à ce qui suit :
Si vous ne savez pas comment obtenir l'ID de votre node de validation, vous pouvez l'obtenir avec la commande suivante :
archwayd tendermint show-node-id
Remarque : à l'ID reçu, il faut concaténer l'IP et le port P2P comme indiqué dans l'image ci-dessus.
Dans le même fichier de configuration, nous trouverons également le paramètre unconditional-peer-ids auquel nous devons obligatoirement ajouter notre node validateur comme nous l'avons fait avec le paramètre private_peer_ids. Cette étape est nécessaire, car les nodes sont limités dans le nombre de pairs auxquels ils peuvent se connecter.
Afin d'éviter le risque de laisser notre node validateur sans communication, en définissant son ID dans le paramètre unconditional-peer-ids, nous nous assurerons que les nodes sentinelles sont toujours connectés au node validateur même si la limite de pairs auxquels ils peuvent être connectés a été dépassée. Optionnellement, nous pouvons aussi ajouter dans ce même paramètre (séparé par des virgules) le node sentinelle homologue pour garantir que les nodes sentinelles seront toujours connectés l'un à l'autre.
unconditional-peer-ids = "validator node, homologous sentinel node".
Remarque : par node sentinelle homologue, nous entendons que si vous configurez le node sentinelle A, l'homologue sera le node sentinelle B, et si vous éditez le node sentinelle B, l'homologue sera le node sentinelle A.
À ce stade, nous pourrions démarrer nos nodes sentinelles et les laisser se synchroniser et être découverts par le reste du réseau. Pour ce faire, nous utiliserons la commande suivante :
sudo systemctl start archway
Si vous avez effectué toutes les étapes correctement, vous devriez voir que les deux nodes sentinelles se synchronisent :
Configuration du node validateur
Une fois que les nodes sentinelles se sont synchronisés, nous pouvons configurer le node validateur avec l'assurance qu'il ne se désynchronisera pas. Nous devrons éditer le fichier config.toml dans le dossier config, où nous trouverons les lignes suivantes :
# Comma separated list of nodes to keep persistent connections to
# Do not add private peers to this list if you don't want them advertised
persistent_peers =[list of sentry nodes]
Dans persistent_peers, nous n'ajouterons que les identifiants des nodes sentinelles, c'est-à-dire que si le node était déjà monté auparavant, nous devrions supprimer le contenu de ce champ avant d'ajouter nos nodes sentinelles.
Cela devrait ressembler à ce qui suit :
Dans le même fichier de configuration, nous trouverons le paramètre pex, que nous devons définir à « false ». Ce paramètre ne découvre pas d'autres pairs, il utilisera seulement ceux définis dans le paramètre persistent_peers.
pex = false
Si le validateur a déjà été exposé au réseau, nous pouvons supprimer le carnet d'adresses afin qu'il ne « connaisse » que les nodes sentinelles ; s'il s'agit d'un validateur qui n'a jamais été démarré, cette étape n'est pas nécessaire. Une fois dans le dossier config et avec le node arrêté, exécutez la commande suivante :
rm addrbook.json
À ce stade, nous pouvons démarrer le node et il se synchronisera en utilisant uniquement les nodes sentinelles.
Pour vérifier que nous sommes bien connectés à seulement deux pairs et que ce sont bien les nodes sentinelles, nous pouvons écrire la commande suivante sur notre node validé ; la sortie est un JSON qui nous indiquera le nombre et les pairs auxquels nous sommes connectés, le nombre devant être deux et les pairs devant être nos nodes sentinelles.
curl -s localhost:26657/net_info
Ici vous pouvez voir le nombre de pairs auxquels notre node validateur est connecté, dans ce cas c'est deux, ce qui est correct.
Et dans l'objet JSON, si nous continuons à regarder, nous verrons que les deux pairs que nous avons sont « Sentry A » et « Sentry B ».
Bonus : Protéger le node validateur par un firewall
À l'heure actuelle, le port P2P de notre node validateur est ouvert et n'importe qui peut établir une connexion. Si nous nous contentons de mettre en place le node validateur, avec les configurations effectuées, personne ne devra trouver notre node validateur, cependant, pour plus de sécurité, il est conseillé de fermer le port P2P et de n'autoriser le trafic que vers les IP de nos nodes sentinelles.
Il y a plusieurs façons de le faire, il est possible que votre fournisseur de serveur vous permette de le faire par le biais d'une interface graphique. Ufw est une alternative facile à utiliser vous pouvez en savoir plus sur ufw ici.
Les commandes à utiliser avec ufw sont les suivantes :
sudo ufw allow from <ip sentry A> proto tcp to any port 26656
sudo ufw allow from <ip sentry B> proto tcp to any port 26656
Bonus : Réseaux privés
Lorsque le node de validation se trouve dans le même centre de données que l'un des nodes sentinelles, il est possible d'utiliser un adressage privé.
Si vous souhaitez utiliser l'adressage privé, vous devrez modifier le paramètre addr-book-strict du fichier config.toml et lui attribuer la valeur false dans le node validateur et le node sentinelle qui communiquent sous l'adressage privé. Ce paramètre, lorsqu'il est défini sur « true », n'ajoutera que les adresses routables au carnet d'adresses, les adresses privées définies dans le RFC-1918 ne sont pas routables et ne seront donc pas ajoutées au carnet d'adresses. Nous devrons donc le remplacer par false pour pouvoir utiliser les adresses IP des plages privées.
addr-book-strict: boolean. Par défaut, les nodes ayant une adresse routable seront pris en compte pour la connexion. Si ce paramètre est désactivé (false), les adresses IP non routables, telles que les adresses d'un réseau privé, peuvent être ajoutées au carnet d'adresses. Source : https://docs.tendermint.com/master/nodes/validators.html
Conclusions
La mise en place de nodes sentinelles permet non seulement de s'assurer que votre node de validation ne subisse pas d'attaque par déni de service ou DDOS, mais aussi de rendre le réseau Archway plus robuste. L'installation des nodes sentinelles n'est pas très différente de celle d'un node validateur, et les configurations supplémentaires à effectuer sont très simples et intuitives.
Maintenant qu'Archway a réalisé le testnet sur torii-1, c'est le moment pour essayer d'installer des nodes sentinelles et, une fois que le mainnet sera lancé, de le répliquer avec l'expérience d'avoir pu le tester sur torii-1. Si vous avez déjà votre node sur torii-1, qu'attendez-vous pour mettre en place vos nodes sentinelles et vous protéger des attaques indésirables ?
