One place for hosting & domains

      sécuriser

      Comment installer et sécuriser Redis sur Ubuntu 20.04 [Démarrage rapide]


      Introduction

      Redis est une base de données de valeurs-clés en mémoire renommée pour sa flexibilité, ses performances et son vaste support linguistique. Ce didacticiel de démarrage rapide est conçu pour vous apprendre à installer, configurer et sécuriser Redis sur un serveur Ubuntu 20.04.

      Conditions préalables

      Pour suivre ces instructions, vous aurez besoin d’accéder à un serveur Ubuntu 20.04 doté d’un non-root user avec des privilèges sudo et un pare-feu configuré avec ufw. Vous pouvez configurer ceci en suivant notre Guide de configuration initiale du serveur pour Ubuntu 20.04.

      Étape 1 — Installation et configuration de Redis

      Commencez par mettre à jour votre cache local de package apt :

      Installez ensuite Redis en saisissant ce qui suit :

      • sudo apt install redis-server

      Ensuite, ouvrez le fichier de configuration Redis avec votre éditeur de texte favori :

      • sudo nano /etc/redis/redis.conf

      Dans le fichier, recherchez la directive supervised qui vous permet de déclarer un système init qui gérera Redis en tant que tant Étant donné que vous exécutez Ubuntu, qui utilise le système init systemd, remplacez sa valeur no par systemd :

      /etc/redis/redis.conf

      . . .
      
      # If you run Redis from upstart or systemd, Redis can interact with your
      # supervision tree. Options:
      #   supervised no      - no supervision interaction
      #   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
      #   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
      #   supervised auto    - detect upstart or systemd method based on
      #                        UPSTART_JOB or NOTIFY_SOCKET environment variables
      # Note: these supervision methods only signal "process is ready."
      #       They do not enable continuous liveness pings back to your supervisor.
      supervised systemd
      
      . . .
      

      Enregistrez et fermez le fichier lorsque vous avez terminé. Si vous avez modifié le fichier avec nano, faites-le en appuyant sur CTRL + X, Y, puis sur ENTER.

      Ensuite, redémarrez le service Redis pour valider les modifications que vous avez apportées au fichier de configuration :

      • sudo systemctl restart redis.service

      Pour vérifier si Redis fonctionne correctement, connectez-vous au serveur à l’aide de redis-cli, le client de la ligne de commande de Redis :

      Dans l’invite qui suit, testez la connectivité avec la commande ping :

      Output

      PONG

      Ce résultat confirme que la connexion au serveur est active. Ensuite, vérifiez que vous pouvez configurer des clés en exécutant les commandes suivantes :

      Output

      OK

      Récupérez la valeur en saisissant :

      En supposant que tout fonctionne correctement, vous pourrez récupérer la valeur que vous avez sauvegardée :

      Output

      "It's working!"

      Après avoir confirmé que la valeur est récupérable, quittez l’invite Redis pour revenir au shell :

      Étape 2 — Configuration d’un mot de passe Redis

      Vous pouvez configurer un mot de passe Redis directement dans le fichier de configuration de Redis, /etc/redis/redis.conf. Ouvrez à nouveau ce fichier avec votre éditeur favori :

      • sudo nano /etc/redis/redis.conf

      Faites défiler l’écran jusqu’à la section SECURITY et recherchez une directive commentée indiquant ce qui suit :

      /etc/redis/redis.conf

      . . .
      # requirepass foobared
      . . .
      

      Décommentez-la en supprimant le # et remplacez foobared par un mot de passe sécurisé :

      /etc/redis/redis.conf

      . . .
      requirepass your_redis_password
      . . .
      

      Une fois le mot de passe configuré, enregistrez et fermez le fichier, puis redémarrez Redis :

      • sudo systemctl restart redis.service

      Pour vérifier si le mot de passe fonctionne, ouvrez le client Redis :

      Ci-après vous voyez une séquence de commandes qui permet de tester le bon fonctionnement du mot de passe Redis. La première commande essaie de définir une clé sur une valeur avant l’authentification :

      Cela ne fonctionnera pas si vous ne procédez pas à l’authentification. Redis renverra alors une erreur :

      Output

      (error) NOAUTH Authentication required.

      La commande suivante procède à l’authentification avec le mot de passe spécifié dans le fichier de configuration Redis :

      Redis valide :

      Output

      OK

      Après cela, la ré-exécution de la commande précédente sera probante :

      Output

      OK

      get key1 interroge Redis pour obtenir la valeur de la nouvelle clé.

      Output

      "10"

      Après avoir confirmé que vous êtes en mesure d’exécuter des commandes dans le client Redis suite à l’authentification, vous pouvez quitter ​​redis-cli​​​ ​​​:

      Étape 3 – Renommer les commandes dangereuses

      Redis intègre une autre fonctionnalité de sécurité qui consiste à renommer ou à désactiver complètement certaines commandes considérées comme dangereuses. Voici certaines des commandes considérées comme dangereuses : FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME et DEBUG. En désactivant ou en renommant ces commandes ainsi que d’autres, vous rendez toute reconfiguration, destruction ou suppression de vos données plus difficile aux utilisateurs non autorisés.

      Pour renommer ou désactiver les commandes Redis, rouvrez le fichier de configuration :

      • sudo nano /etc/redis/redis.conf

      Attention : les étapes suivantes qui vous montrent de quelle manière désactiver et renommer des commandes sont données à titre d’exemple. Vous devez décider de désactiver ou de renommer uniquement les commandes qui ont du sens pour vous. Vous pouvez consulter la liste complète des commandes par vous-même et déterminer de quelle manière elles peuvent être utilisées à mauvais escient sur redis.io/commands.

      Pour désactiver une commande, renommez-la simplement dans une chaîne de caractères vide (indiquée par une paire de guillemets sans aucun caractère entre eux), comme illustré ci-dessous :

      /etc/redis/redis.conf

      . . .
      # It is also possible to completely kill a command by renaming it into
      # an empty string:
      #
      rename-command FLUSHDB ""
      rename-command FLUSHALL ""
      rename-command DEBUG ""
      . . .
      

      Pour renommer une commande, donnez-lui un autre nom comme indiqué dans les exemples ci-dessous. Les commandes renommées doivent être difficiles à deviner pour les autres, mais faciles à retenir pour vous :

      /etc/redis/redis.conf

      . . .
      # rename-command CONFIG ""
      rename-command SHUTDOWN SHUTDOWN_MENOT
      rename-command CONFIG ASC12_CONFIG
      . . .
      

      Sauvegardez vos modifications et fermez le fichier.

      Après avoir renommé une commande, appliquez la modification en redémarrant Redis :

      • sudo systemctl restart redis.service

      Pour tester la nouvelle commande, saisissez la ligne de commande Redis :

      Puis procédez à l’authentification :

      Output

      OK

      En supposant que vous avez renommé la commande CONFIG avec ASC12_CONFIG comme dans l’exemple précédent, essayez d’utiliser la commande d’origine CONFIG. L’opération devrait échouer, car vous l’avez renommée :

      Output

      (error) ERR unknown command `config`, with args beginning with:

      Toutefois, en saisissant la commande renommée, cela devrait fonctionner. Elle n’est pas sensible à la casse :

      • asc12_config get requirepass

      Output

      1) "requirepass" 2) "your_redis_password"

      Conclusion

      Au cours de ce didacticiel de démarrage rapide, vous avez installé et configuré Redis, vérifié que votre installation Redis fonctionne correctement et utilisé ses fonctions de sécurité intégrées pour le rendre moins vulnérable aux attaques d’utilisateurs malveillants.



      Source link

      Comment installer et sécuriser Redis sur Ubuntu 20.04


      Une version précédente de ce tutoriel a été rédigée par Justin Ellingwood

      Introduction

      Redis est une base de données de valeurs-clés en mémoire renomée pour sa flexibilité, ses performances et son vaste support linguistique. Ce tutoriel est conçu pour vous apprendre à installer, configurer et sécuriser Redis sur un serveur Ubuntu 20.04.

      Conditions préalables

      Pour suivre ces instructions, vous aurez besoin d’accéder à un serveur Ubuntu 20.04 doté d’un non-root user avec des privilèges sudo et un pare-feu configuré avec ufw. Vous pouvez configurer ceci en suivant notre Guide de configuration initiale du serveur pour Ubuntu 20.04.

      Étape 1 — Installation et configuration de Redis

      Nous utiliserons le gestionnaire de packages APT pour installer redis à partir des référentiels Ubuntu officiels. À ce jour, la version disponible dans les référentiels par défaut est 5.0.7.

      Commencez par mettre à jour votre cache local de package apt :

      Installez ensuite Redis en saisissant ce qui suit :

      • sudo apt install redis-server

      Cette opération permettra le téléchargement et l’installation de Redis et de ses dépendances. Suite à cela, vous devez effectuer un changement de configuration important dans le fichier de configuration Redis, qui a été automatiquement généré lors de l’installation.

      Ouvrez ce nouveau fichier avec votre éditeur de texte préféré :

      • sudo nano /etc/redis/redis.conf

      Dans le fichier, trouvez la directive supervised. Cette directive vous permet de déclarer un système init qui gérera Redis en tant que service et vous donnera plus de contrôle sur son fonctionnement. La directive supervised est configurée sur no par défaut. Etant donné vous exécutez Ubuntu, qui utilise le système init systemd, remplacez cette valeur par systemd :

      /etc/redis/redis.conf

      . . .
      
      # If you run Redis from upstart or systemd, Redis can interact with your
      # supervision tree. Options:
      #   supervised no      - no supervision interaction
      #   supervised upstart - signal upstart by putting Redis into SIGSTOP mode
      #   supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
      #   supervised auto    - detect upstart or systemd method based on
      #                        UPSTART_JOB or NOTIFY_SOCKET environment variables
      # Note: these supervision methods only signal "process is ready."
      #       They do not enable continuous liveness pings back to your supervisor.
      supervised systemd
      
      . . .
      

      À ce stade, c’est la seule modification que vous devez apporter au fichier de configuration Redis. Vous pouvez donc le sauvegarder et le fermer une fois l’opération terminée. Si vous avez modifié le fichier avec nano, faites-le en appuyant sur CTRL + X, Y, puis sur ENTER.

      Ensuite, redémarrez le service Redis pour valider les modifications que vous avez apportées au fichier de configuration :

      • sudo systemctl restart redis.service

      Ainsi, vous avez installé et configuré Redis et il fonctionne désormais sur votre machine. Avant de commencer à l’utiliser, cependant, il est prudent de vérifier tout d’abord si Redis fonctionne correctement.

      Étape 2 — Tester Redis

      Comme pour tout logiciel nouvellement installé, il est conseillé de vous assurer que Redis fonctionne comme prévu avant d’apporter d’autres modifications à sa configuration. Au cours de cette étape, nous allons passer en revue plusieurs façons de vérifier que Redis fonctionne correctement.

      Commencez par vérifier si le service Redis fonctionne :

      • sudo systemctl status redis

      S’il s’exécute sans erreur, cette commande produira un résultat similaire à ce qui suit :

      Output

      ● redis-server.service - Advanced key-value store Loaded: loaded (/lib/systemd/system/redis-server.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-04-30 23:26:54 UTC; 4s ago Docs: http://redis.io/documentation, man:redis-server(1) Process: 36552 ExecStart=/usr/bin/redis-server /etc/redis/redis.conf (code=exited, status=0/SUCCESS) Main PID: 36561 (redis-server) Tasks: 4 (limit: 2345) Memory: 1.8M CGroup: /system.slice/redis-server.service └─36561 /usr/bin/redis-server 127.0.0.1:6379 . . .

      Ici, vous pouvez voir que Redis est en cours d’exécution et est déjà activé. Cela signifie qu’il est configuré pour se lancer à chaque fois que le serveur démarre.

      Note : ce paramètre est conseillé pour de nombreux cas usuels d’utilisation de Redis. Si, toutefois, vous préférez lancer Redis manuellement à chaque démarrage de votre serveur, vous pouvez le configurer en utilisant la commande suivante :

      • sudo systemctl disable redis

      Pour vérifier si Redis fonctionne correctement, connectez-vous au serveur à l’aide de redis-cli, le client de la ligne de commande de Redis:

      Dans l’invite qui suit, testez la connectivité avec la commande ping :

      Output

      PONG

      Ce résultat confirme que la connexion au serveur est active. Ensuite, vérifiez que vous pouvez configurer des clés en exécutant les commandes suivantes :

      Output

      OK

      Récupérez la valeur en saisissant :

      En supposant que tout fonctionne correctement, vous pourrez récupérer la valeur que vous avez sauvegardée :

      Output

      "It's working!"

      Après avoir confirmé que la valeur est récupérable, quittez l’invite Redis pour revenir au shell :

      Nous allons procéder à un dernier test en vérifiant si Redis est capable de conserver les données même après avoir été arrêté ou redémarré. Pour ce faire, redémarrez tout d’abord l’instance Redis :

      • sudo systemctl restart redis

      Ensuite, connectez-vous à nouveau le client de la ligne de commande :

      Puis confirmez que votre valeur de test est encore disponible

      La valeur de votre clé devrait encore être accessible :

      Output

      "It's working!"

      Une fois que vous avez terminé, sortez pour aller dans le shell :

      Ainsi, votre installation Redis est entièrement opérationnelle et prête à être utilisée. Cependant, certains de ses paramètres de configuration par défaut ne sont pas sécurisés et donnent la possibilité aux acteurs malveillants d’attaquer et d’accéder à votre serveur et à ses données. Les étapes restantes de ce tutoriel couvrent les méthodes qui vous permettront de minimiser ces vulnérabilités, comme prescrit par le site officiel de Redis. Bien que ces étapes soient facultatives et que Redis fonctionnera malgré tout si vous choisissez de ne pas les suivre, il est fortement recommandé de les respecter afin de renforcer la sécurité de votre système.

      Étape 3 – Liaison à localhost

      Par défaut, Redis n’est accessible qu’à partir de localhost. Cependant, si vous avez installé et configuré Redis en suivant un tutoriel différent de celui-ci, vous avez peut-être mis à jour le fichier de configuration et ainsi autorisé les connexions depuis n’importe où. Cette méthode n’est pas aussi sûre qu’une liaison à localhost.

      Pour y remédier, ouvrez le fichier de configuration Redis pour le modifier :

      • sudo nano /etc/redis/redis.conf

      Localisez cette ligne et assurez-vous qu’elle n’est pas commentée (supprimez le # s’il existe) :

      /etc/redis/redis.conf

      bind 127.0.0.1 ::1
      

      Une fois que vous avez fini, sauvegardez et fermez le fichier (appuyez sur CTRL + X, Y, puis sur ENTER).

      Ensuite, redémarrez le service pour vous assurer que systemd lit bien vos modifications :

      • sudo systemctl restart redis

      Pour vérifier si cette modification est bien entrée en vigueur, exécutez la commande netstat suivante :

      • sudo netstat -lnp | grep redis

      Output

      tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 14222/redis-server tcp6 0 0 ::1:6379 :::* LISTEN 14222/redis-server

      Remarque : il se peut que la commande netstat ne soit pas disponible par défaut sur votre système. Si tel est le cas, vous pouvez l’installer (avec un certain nombre d’autres outils de mise en réseau pratiques) avec la commande suivante :

      • sudo apt install net-tools

      Ce résultat montre que le programme redis-server est lié à localhost (127.0.0.1) et reflète le changement que vous venez de faire au fichier de configuration. Si vous voyez une autre adresse IP dans cette colonne (0.0.0.0, par exemple), vérifiez si vous avez bien décommenté la bonne ligne et redémarrez le service Redis à nouveau.

      Maintenant que votre installation Redis n’écoute que sur localhost, les acteurs malveillants auront plus de mal à faire des requêtes ou à accéder à votre serveur. Cependant, la configuration actuelle de Redis n’oblige pas les utilisateurs à s’authentifier avant de modifier sa configuration ou aux données qu’il contient. Pour y remédier, Redis vous permet d’exiger que les utilisateurs s’authentifient avec un mot de passe avant de pouvoir apporter des modifications via le client Redis (redis-cli).

      Étape 4 — Configuration d’un mot de passe Redis

      La configuration d’un mot de passe Redis permet d’activer l’une de ses deux fonctions de sécurité intégrées – la commande auth, qui exige à ce que les clients s’authentifient pour accéder à la base de données. La configuration du mot de passe se fait directement dans le fichier de configuration de Redis, /etc/redis/redis.conf. Donc, ouvrez à nouveau ce fichier avec votre éditeur préféré :

      • sudo nano /etc/redis/redis.conf

      Faites défiler l’écran jusqu’à la section SECURITY et recherchez une directive commentée indiquant ce qui suit :

      /etc/redis/redis.conf

      . . .
      # requirepass foobared
      . . .
      

      Décommentez-la en supprimant le # et remplacez foobared par un mot de passe sécurisé.

      Remarque : au-dessus de la directive requirepass dans le fichier redis.conf, vous trouverez une mise en garde commentée :

      /etc/redis/redis.conf

      . . .
      # Warning: since Redis is pretty fast an outside user can try up to
      # 150k passwords per second against a good box. This means that you should
      # use a very strong password otherwise it will be very easy to break.
      #
      . . .
      

      Il est donc important que la valeur du mot de passe soit très forte et très longue. Plutôt que de créer vous-même un mot de passe, vous pouvez utiliser la commande openssl qui en générera un au hasard, comme dans l’exemple suivant. En redirigeant le résultat de la première commande vers la deuxième commande openssl, comme illustré ici, cela supprimera tous les sauts de ligne produits par la première commande :

      • openssl rand 60 | openssl base64 -A

      Votre résultat devrait ressembler à ce qui suit :

      Output

      RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

      Après avoir copié et collé le résultat de cette commande comme nouvelle valeur de requirepass, vous devriez avoir :

      /etc/redis/redis.conf

      requirepass RBOJ9cCNoGCKhlEBwQLHri1g+atWgn4Xn4HwNUbtzoVxAYxkiYBi7aufl4MILv1nxBqR4L6NNzI0X6cE

      Une fois le mot de passe configuré, enregistrez et fermez le fichier, puis redémarrez Redis :

      • sudo systemctl restart redis.service

      Pour vérifier si le mot de passe fonctionne, ouvrez le client Redis :

      Vous pouvez voir ci-après une séquence de commandes qui permet de tester le bon fonctionnement du mot de passe Redis. La première commande tente de définir une clé sur une valeur avant l’authentification :

      Cela ne fonctionnera pas car vous ne vous êtes pas authentifié et Redis renvoie donc une erreur :

      Output

      (error) NOAUTH Authentication required.

      La commande suivante procède à l’authentification avec le mot de passe spécifié dans le fichier de configuration de Redis :

      Redis valide :

      Output

      OK

      Après cela, la ré-exécution de la commande précédente sera probante :

      Output

      OK

      get key1 interroge Redis pour obtenir la valeur de la nouvelle clé.

      Output

      "10"

      Après avoir confirmé que vous étiez en mesure d’exécuter des commandes sur le client Redis suite à l’authentification, vous pouvez quitter ​​redis-cli​​​ :

      Ensuite, nous allons voir comment renommer les commandes Redis qui, si elles sont entrées par erreur ou par un acteur malveillant, pourraient endommager sérieusement votre allons

      Étape 5 – Changement de nom des commandes dangereuses

      Redis intègre une autre fonctionnalité de sécurité qui consiste à renommer ou à désactiver complètement certaines commandes considérées comme dangereuses.

      Lorsqu’elles sont exécutées par des utilisateurs non autorisés, ces commandes peuvent être utilisées pour reconfigurer, détruire ou effacer vos données. Comme le mot de passe d’authentification, la configuration qui permet de renommer ou désactiver les commandes, se fait dans la même section SECURITY du fichier /etc/redis/redis.conf​​​.

      Voici certaines des commandes considérées comme dangereuses : FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME, et DEBUG. Cette liste n’est pas exhaustive, mais c’est un bon point de départ de renommer ou désactiver toutes les commandes de cette liste pour améliorer la sécurité de votre serveur Redis.

      Que vous deviez désactiver ou renommer une commande, cela dépend de vos besoins spécifiques ou de ceux de votre site. Si vous savez que vous n’utiliserez jamais une commande qui pourrait faire l’objet d’un abus, vous pouvez la désactiver. Sinon, il serait peut-être dans votre intérêt de la renommer.

      Pour renommer ou désactiver les commandes Redis, rouvrez le fichier de configuration :

      • sudo nano /etc/redis/redis.conf

      Attention : les étapes suivantes qui vous montrent de quelle manière désactiver et renommer des commandes sont données à titre d’exemple. Vous devez décider de désactiver ou de renommer uniquement les commandes qui ont du sens pour vous. Vous pouvez consulter la liste complète des commandes par vous-même et déterminer de quelle amnière elles peuvent être utilisées à mauvais escient sur redis.io/commands.

      Pour désactiver une commande, renommez-la simplement dans une chaîne de caractères vide (indiquée par une paire de guillemets sans aucun caractère entre eux), comme illustré ci-dessous :

      /etc/redis/redis.conf

      . . .
      # It is also possible to completely kill a command by renaming it into
      # an empty string:
      #
      rename-command FLUSHDB ""
      rename-command FLUSHALL ""
      rename-command DEBUG ""
      . . .
      

      Pour renommer une commande, donnez-lui un autre nom comme indiqué dans les exemples ci-dessous. Les commandes renommées doivent être difficiles à deviner pour les autres, mais faciles à retenir pour vous :

      /etc/redis/redis.conf

      . . .
      # rename-command CONFIG ""
      rename-command SHUTDOWN SHUTDOWN_MENOT
      rename-command CONFIG ASC12_CONFIG
      . . .
      

      Sauvegardez vos modifications et fermez le fichier.

      Après avoir renommé une commande, appliquez la modification en redémarrant Redis :

      • sudo systemctl restart redis.service

      Pour tester la nouvelle commande, saisissez la ligne de commande Redis :

      Ensuite, authentifiez-vous :

      Output

      OK

      Supposons que vous avez renommé la commande CONFIG par ASC12_CONFIG, comme dans l’exemple précédent. Tout d’abord, essayez d’utiliser la commande originale CONFIG. L’opération devrait échouer, car vous l’avez renommée :

      Output

      (error) ERR unknown command `config`, with args beginning with:

      Toutefois, en saisissant la commande renommée, cela devrait fonctionner. Elle n’est pas sensible à la casse :

      • asc12_config get requirepass

      Output

      1) "requirepass" 2) "your_redis_password"

      Enfin, vous pouvez quitter redis-cli​​

      Notez que si vous utilisez déjà la ligne de commande Redis et que vous redémarrez ensuite Redis, vous devrez vous réauthentifier. Sinon, vous obtiendrez l’erreur suivante si vous tapez une commande :

      Output

      NOAUTH Authentication required.

      Concernant la pratique de renommer les commandes, une mise en garde se trouve à la fin de la section SECURITY dans /etc/redis/redis.conf qui indique ce qui suit :

      /etc/redis/redis.conf

      . . .
      # Please note that changing the name of commands that are logged into the
      # AOF file or transmitted to replicas may cause problems.
      . . .
      

      Note: Le projet Redis choisit d’utiliser les termes «maître» et «esclave», tandis que DigitalOcean préfère généralement les alternatives «primaire» et «secondaire». Pour éviter toute confusion, nous avons choisi d’utiliser ici les termes utilisés dans la documentation Redis.

      Cela signifie que si la commande renommée n’est pas dans le fichier AOF, ou si elle l’est mais que le fichier AOF n’a pas été transmis aux esclaves, il ne devrait pas y avoir de problème.

      Donc, gardez cela à l’esprit lorsque vous essayez de renommer des commandes. Le meilleur moment pour renommer une commande est lorsque vous n’utilisez pas la persistance AOF ou juste après l’installation, c’est-à-dire avant le déploiement de votre application utilisant Redis.

      Lorsque vous utilisez AOF et que vous traitez une installation maître-esclave, prenez en considération cette réponse qui provient de la page de problème GitHub du projet. Voici une réponse à la question de l’auteur :

      Les commandes sont journalisées sur l’AOF et répliquées sur l’esclave de la même manière qu’elles sont envoyées. Donc si vous essayez de rejouer l’AOF sur une instance qui n’est pas renommée de la même manière, vous risquez de rencontrer des incohérences car la commande ne peut pas être exécutée (idem pour les esclaves).

      Ainsi, dans des cas comme celui-ci, la meilleure façon de gérer le changement de nom consiste à s’assurer que les commandes renommées sont appliquées à toutes les instances dans les installations maître-esclave.

      Conclusion

      Dans ce didacticiel, vous avez installé et configuré Redis, vérifié que votre installation Redis fonctionne correctement et utilisé ses fonctionnalités de sécurité intégrées pour le rendre moins vulnérable aux attaques d’acteurs malveillants.

      Gardez à l’esprit qu’une fois qu’une personne est connectée à votre serveur, il est très facile de contourner les fonctionnalités de sécurité spécifiques à Redis que nous avons mises en place. Par conséquent, la fonctionnalité de sécurité la plus importante de votre serveur Redis reste votre pare-feu (que vous avez configuré si vous avez suivi le tutoriel Configuration initiale du serveur) qui rend extrêmement difficile pour les acteurs malveillants de franchir cette barrière.



      Source link

      Comment sécuriser Apache avec Let’s Encrypt sur Ubuntu 20.04


      Introduction

      Let’s Encrypt est une autorité de certification (CA) qui facilite l’obtention et l’installation de certificats TLS/SSL gratuits, permettant ainsi le cryptage HTTPS sur les serveurs web. Il simplifie le processus en fournissant un logiciel client, Certbot, qui tente d’automatiser la plupart (sinon la totalité) des étapes requises. Actuellement, l’ensemble du processus d’obtention et d’installation d’un certificat est entièrement automatisé sur Apache et Nginx.

      Dans ce guide, nous utiliserons Certbot pour obtenir un certificat SSL gratuit pour Apache sur Ubuntu 20.04, et nous nous assurerons que ce certificat est configuré pour se renouveler automatiquement.

      Ce tutoriel utilise un fichier d’hôte virtuel séparé au lieu du fichier de configuration par défaut d’Apache pour configurer le site web qui sera sécurisé par Let’s Encrypt. Nous recommandons de créer de nouveaux fichiers d’hôtes virtuels Apache pour chaque domaine hébergé dans un serveur, car cela permet d’éviter les erreurs courantes et de conserver les fichiers de configuration par défaut comme configuration de repli.

      Conditions préalables

      Pour suivre ce tutoriel, vous aurez besoin de :

      • Un serveur Ubuntu 20.04 configuré en suivant cette configuration initiale du serveur pour le tutoriel Ubuntu 20.04, comprenant un utilisateur sudo non root et un pare-feu.

      • Un nom de domaine entièrement enregistré. Ce tutoriel utilisera your_domain comme exemple tout du long. Vous pouvez acheter un nom de domaine sur Namecheap, en obtenir un gratuitement sur Freenom, ou utiliser le bureau d’enregistrement de domaine de votre choix.

      • Les deux enregistrements DNS suivants ont été configurés pour votre serveur. Vous pouvez suivre cette introduction à DigitalOcean DNS pour savoir comment les ajouter.

        • Un enregistrement A avec your_domain pointant sur l’adresse IP publique de votre serveur.
        • Un enregistrement A avec www.your_domain​​​​​​ pointant à l’adresse IP publique de votre serveur.
      • Apache installé en suivant le guide Comment installer Apache sur Ubuntu 20.04. Assurez-vous que vous disposez d’un fichier d’hôte virtuel pour votre domaine. Ce tutoriel utilisera /etc/apache2/sites-available/your_domain.conf comme exemple.

      Étape 1 — Installation de Certbot

      Pour obtenir un certificat SSL avec Let’s Encrypt, nous devons d’abord installer le logiciel Certbot sur votre serveur. Nous utiliserons pour cela les dépôts de packages Ubuntu par défaut.

      Nous avons besoin de deux packages : certbot, et python3-certbot-apache. Ce dernier est un plugin qui intègre Certbot à Apache, permettant d’automatiser l’obtention d’un certificat et la configuration HTTPS au sein de votre serveur web avec une seule commande.

      • sudo apt install certbot python3-certbot-apache

      Vous serez également invité à confirmer l’installation en appuyant sur Y, puis sur ENTER.

      Certbot est maintenant installé sur votre serveur. Dans l’étape suivante, nous allons vérifier la configuration d’Apache pour nous assurer que votre hôte virtuel est correctement configuré. Ainsi, le script client certbot pourra détecter vos domaines et reconfigurer votre serveur web pour utiliser automatiquement votre nouveau certificat SSL généré.

      Étape 2 — Vérification de la configuration de votre hôte virtuel Apache

      Afin de pouvoir obtenir et configurer automatiquement le SSL pour votre serveur web, Certbot doit trouver le bon hôte virtuel dans vos fichiers de configuration Apache. Le(s) nom(s) de domaine de votre serveur sera récupéré à partir des directives ServerName et ServerAlias définies dans votre bloc de configuration VirtualHost.

      Si vous avez suivi l’étape de configuration de l’hôte virtuel dans le tutoriel d’installation d’Apache, vous devriez avoir un bloc VirtualHost configuré pour votre domaine à /etc/apache2/sites-available/your_domain.conf avec les directives ServerName et ServerAlias déjà définies de manière appropriée.

      Pour vérifier cela, ouvrez le fichier d’hôte virtuel de votre domaine à l’aide de nano ou de votre éditeur de texte préféré :

      • sudo nano /etc/apache2/sites-available/your_domain.conf

      Trouvez les lignes ServerName et ServerAlias existantes. Elles devraient ressembler à ceci :

      /etc/apache2/sites-available/your_domain.conf

      ...
      ServerName your_domain
      ServerAlias www.your_domain
      ...
      

      Si vous avez déjà configuré votre ServerName et ServerAlias de cette manière, vous pouvez quitter votre éditeur de texte et passer à l’étape suivante. Si vous utilisez nano, vous pouvez sortir en tapant CTRL+X, puis Y et ENTER pour confirmer.

      Si la configuration actuelle de votre hôte virtuel ne correspond pas à l’exemple, mettez-la à jour en conséquence. Lorsque vous avez terminé, sauvegardez le fichier et quittez l’éditeur. Ensuite, exécutez la commande suivante pour valider vos modifications :

      • sudo apache2ctl configtest

      Vous devriez obtenir Syntax OK en guise de réponse. Si vous obtenez une erreur, rouvrez le fichier de l’hôte virtuel et vérifiez s’il y a des fautes de frappe ou des caractères manquants. Une fois que la syntaxe de votre fichier de configuration est correcte, rechargez Apache pour que les modifications prennent effet :

      • sudo systemctl reload apache2

      Grâce à ces changements, Certbot sera en mesure de trouver le bloc VirtualHost correct et de le mettre à jour.

      Ensuite, nous allons mettre à jour le pare-feu pour permettre le trafic HTTPS.

      Étape 3 — Autorisation du HTTPS à travers le pare-feu

      Si vous avez activé le pare-feu UFW, comme le recommandent les guides des conditions préalables, vous devrez ajuster les paramètres pour autoriser le trafic HTTPS. Lors de l’installation, Apache enregistre quelques profils d’application UFW différents. Nous pouvons utiliser le profil Apache Full pour autoriser le trafic HTTP et HTTPS sur votre serveur.

      Pour vérifier quel type de trafic est actuellement autorisé sur votre serveur, vous pouvez utiliser :

      Si vous avez suivi l’un de nos guides d’installation d’Apache, votre sortie devrait ressembler à ceci, ce qui signifie que seul le trafic HTTP sur le port 80 est actuellement autorisé :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache (v6) ALLOW Anywhere (v6)

      Pour permettre également le trafic HTTPS, autoriser le profil “Apache Full” et supprimer le profil “Apache” redondant :

      • sudo ufw allow 'Apache Full'
      • sudo ufw delete allow 'Apache'

      Votre statut ressemblera désormais à ceci :

      Output

      Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere Apache Full ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) Apache Full (v6) ALLOW Anywhere (v6)

      Vous êtes maintenant prêt à exécuter Certbot et à obtenir vos certificats.

      Étape 4 — Obtention d’un certificat SSL

      Certbot propose différents moyens d’obtenir des certificats SSL par le biais de plugins. Le plugin Apache se chargera de reconfigurer Apache et de recharger la configuration chaque fois que nécessaire. Pour utiliser ce plugin, tapez ce qui suit :

      Ce script vous invitera à répondre à une série de questions afin de configurer votre certificat SSL. Tout d’abord, il vous demandera une adresse électronique valide. Cette adresse électronique sera utilisée pour les notifications de renouvellement et les avis de sécurité :

      Output

      Saving debug log to /var/log/letsencrypt/letsencrypt.log Plugins selected: Authenticator apache, Installer apache Enter email address (used for urgent renewal and security notices) (Enter 'c' to cancel): you@your_domain

      Après avoir fourni une adresse électronique valide, appuyez sur ENTER pour passer à l’étape suivante. Vous serez ensuite invité à confirmer si vous acceptez les conditions d’utilisation du service Let’s Encrypt. Vous pouvez confirmer en appuyant sur A et ensuite sur ENTER :

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Please read the Terms of Service at
      https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf. You must
      agree in order to register with the ACME server at
      https://acme-v02.api.letsencrypt.org/directory
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      (A)gree/(C)ancel: A
      

      Ensuite, il vous sera demandé si vous souhaitez partager votre adresse électronique avec l’Electronic Frontier Foundation pour recevoir des nouvelles et d’autres informations. Si vous ne souhaitez pas vous abonner à leur contenu, tapez N. Sinon, tapez Y. Ensuite, appuyez sur ENTER pour passer à l’étape suivante.

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Would you be willing to share your email address with the Electronic Frontier
      Foundation, a founding partner of the Let's Encrypt project and the non-profit
      organization that develops Certbot? We'd like to send you email about our work
      encrypting the web, EFF news, campaigns, and ways to support digital freedom.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      (Y)es/(N)o: N
      

      La prochaine étape vous invitera à informer Certbot des domaines pour lesquels vous souhaitez activer le HTTPS. Les noms de domaine listés sont obtenus automatiquement à partir de la configuration de votre hôte virtuel Apache, c’est pourquoi il est important de s’assurer que vous avez les paramètres ServerName et ServerAlias corrects configurés dans votre hôte virtuel. Si vous souhaitez activer le HTTPS pour tous les noms de domaine répertoriés (recommandé), vous pouvez laisser l’invite vide et appuyer sur ENTER pour continuer. Sinon, sélectionnez les domaines pour lesquels vous souhaitez activer le HTTPS en énumérant chaque numéro approprié, séparé par des virgules et/ou des espaces, puis appuyez sur ENTER.

      Which names would you like to activate HTTPS for?
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      1: your_domain
      2: www.your_domain
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Select the appropriate numbers separated by commas and/or spaces, or leave input
      blank to select all options shown (Enter 'c' to cancel):
      

      Vous verrez une sortie de ce type :

      Obtaining a new certificate
      Performing the following challenges:
      http-01 challenge for your_domain
      http-01 challenge for www.your_domain
      Enabled Apache rewrite module
      Waiting for verification...
      Cleaning up challenges
      Created an SSL vhost at /etc/apache2/sites-available/your_domain-le-ssl.conf
      Enabled Apache socache_shmcb module
      Enabled Apache ssl module
      Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
      Enabling available site: /etc/apache2/sites-available/your_domain-le-ssl.conf
      Deploying Certificate to VirtualHost /etc/apache2/sites-available/your_domain-le-ssl.conf
      

      Ensuite, vous serez invité à choisir si vous voulez ou non que le trafic HTTP soit redirigé vers le HTTPS. En pratique, cela signifie que lorsqu’une personne visite votre site web par des canaux non cryptés (HTTP), elle sera automatiquement redirigée vers l’adresse HTTPS de votre site web. Choisissez 2 pour activer la redirection, ou 1 si vous souhaitez conserver HTTP et HTTPS comme méthodes distinctes d’accès à votre site web.

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      1: No redirect - Make no further changes to the webserver configuration.
      2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
      new sites, or if you're confident your site works on HTTPS. You can undo this
      change by editing your web server's configuration.
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
      
      

      Après cette étape, la configuration de Certbot est terminée, et les dernières remarques sur votre nouveau certificat vous seront présentées, ainsi que l’emplacement des fichiers générés et la manière de tester votre configuration à l’aide d’un outil externe qui analyse l’authenticité de votre certificat :

      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      Congratulations! You have successfully enabled https://your_domain and
      https://www.your_domain
      
      You should test your configuration at:
      https://www.ssllabs.com/ssltest/analyze.html?d=your_domain
      https://www.ssllabs.com/ssltest/analyze.html?d=www.your_domain
      - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
      
      IMPORTANT NOTES:
       - Congratulations! Your certificate and chain have been saved at:
         /etc/letsencrypt/live/your_domain/fullchain.pem
         Your key file has been saved at:
         /etc/letsencrypt/live/your_domain/privkey.pem
         Your cert will expire on 2020-07-27. To obtain a new or tweaked
         version of this certificate in the future, simply run certbot again
         with the "certonly" option. To non-interactively renew *all* of
         your certificates, run "certbot renew"
       - Your account credentials have been saved in your Certbot
         configuration directory at /etc/letsencrypt. You should make a
         secure backup of this folder now. This configuration directory will
         also contain certificates and private keys obtained by Certbot so
         making regular backups of this folder is ideal.
       - If you like Certbot, please consider supporting our work by:
      
         Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
         Donating to EFF:                    https://eff.org/donate-le
      
      

      Votre certificat est maintenant installé et chargé dans la configuration d’Apache. Essayez de recharger votre site web en utilisant https:// et remarquez l’indicateur de sécurité de votre navigateur. Il doit indiquer que votre site est correctement sécurisé, généralement en incluant une icône de cadenas dans la barre d’adresse.

      Vous pouvez utiliser le SSL Labs Server Test pour vérifier la qualité de votre certificat et obtenir des informations détaillées à son sujet, dans la perspective d’un service externe.

      Dans la prochaine et dernière étape, nous testerons la fonction de renouvellement automatique de Certbot, qui garantit que votre certificat sera renouvelé automatiquement avant la date d’expiration.

      Étape 5 — Verification du renouvellement automatique de Certbot

      Les certificats Let’s Encrypt ne sont valables que quatre-vingt-dix jours. Cette mesure vise à encourager les utilisateurs à automatiser le processus de renouvellement de leurs certificats, ainsi qu’à garantir que les certificats utilisés abusivement ou les clés volées expirent le plus tôt possible.

      Le package certbot que nous avons installé prend en charge les renouvellements en incluant un script de renouvellement dans /etc/cron.d, qui est géré par un service systemctl appelé certbot.timer. Ce script est exécuté deux fois par jour et renouvellera automatiquement tout certificat qui se trouve dans une période de trente jours précédant son expiration.

      Pour vérifier le statut de ce service et vous assurer qu’il est actif et qu’il fonctionne, vous pouvez utiliser :

      • sudo systemctl status certbot.timer

      Vous aurez une sortie similaire à celle-ci :

      Output

      ● certbot.timer - Run certbot twice daily Loaded: loaded (/lib/systemd/system/certbot.timer; enabled; vendor preset: enabled) Active: active (waiting) since Tue 2020-04-28 17:57:48 UTC; 17h ago Trigger: Wed 2020-04-29 23:50:31 UTC; 12h left Triggers: ● certbot.service Apr 28 17:57:48 fine-turtle systemd[1]: Started Run certbot twice daily.

      Pour tester le processus de renouvellement, vous pouvez faire un essai avec certbot :

      • sudo certbot renew --dry-run

      Si vous ne voyez pas d’erreurs, tout est prêt. Si nécessaire, Certbot renouvellera vos certificats et rechargera Apache pour récupérer les modifications. Si le processus de renouvellement automatisé échoue, Let’s Encrypt enverra un message à l’adresse électronique que vous avez indiquée, vous avertissant de l’expiration prochaine de votre certificat.

      Conclusion

      Dans ce tutoriel, vous avez installé le certbot client Let’s Encrypt, configuré et installé un certificat SSL pour votre domaine, et confirmé que le service de renouvellement automatique de Certbot est actif dans systemctl. Si vous avez d’autres questions sur l’utilisation de Certbot, leur documentation est un bon point de départ.



      Source link