Comment installer et sécuriser Redis sur Ubuntu

Introduction

Redis est un magasin de clés-valeurs en mémoire reconnu pour sa flexibilité, ses performances et son large support de langages. Il est souvent utilisé comme base de données, cache ou courtier de messages. Bien qu'une installation par défaut soit fonctionnelle, elle n'est pas sécurisée et laisse vos données et votre serveur vulnérables aux attaques. Une instance Redis non sécurisée peut entraîner des violations de données, un accès non autorisé et même la compromission du serveur.

Ce tutoriel vous guidera à travers l'installation de la dernière version de Redis sur un serveur Ubuntu et la mise en œuvre d'une configuration de sécurité prête pour la production. Vous apprendrez à configurer l'accès des utilisateurs avec des listes de contrôle d'accès (ACL), à chiffrer le trafic avec TLS, à restreindre l'accès au réseau à l'aide d'un pare-feu, et à appliquer des mesures supplémentaires de renforcement du système couvrant la gestion de la mémoire, la persistance et la configuration sécurisée du réseau.

Prérequis

Pour compléter ce guide, vous aurez besoin d'un accès à un serveur Ubuntu disposant d'un utilisateur non-root avec des privilèges sudo et d'un pare-feu configuré avec ufw. Vous pouvez le configurer en suivant notre guide de configuration initiale du serveur pour Ubuntu.

Étape 1 — Installation et configuration de Redis

Nous utiliserons le gestionnaire de paquets APT pour installer Redis à partir des dépôts officiels d'Ubuntu. Au moment de la rédaction, la version disponible dans les dépôts par défaut est la 7.0.15.

Commencez par mettre à jour le cache des paquets locaux apt :

sudo apt update

Puis installez Redis en tapant :

sudo apt install redis-server

Cela téléchargera et installera Redis ainsi que ses dépendances. Une fois l'installation terminée, il est recommandé de vérifier la version installée :

redis-server --version

Suite à cela, il y a un changement de configuration important à apporter au fichier de configuration de Redis, qui a été généré automatiquement lors de l'installation.

Ouvrez ce 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 d'initialisation pour gérer Redis en tant que service, vous offrant ainsi un meilleur contrôle sur son fonctionnement. La directive supervised est définie sur no par défaut. Comme vous utilisez Ubuntu, qui utilise le système d'initialisation systemd, changez-la en systemd :

. . .

# 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

. . .

C’est le seul changement que vous devez apporter au fichier de configuration de Redis pour le moment, alors enregistrez-le et fermez-le lorsque vous avez terminé. Si vous avez utilisé nano pour modifier le fichier, faites-le en appuyant sur CTRL + X, Y, puis ENTRÉE.

Ensuite, redémarrez le service Redis pour que les modifications apportées au fichier de configuration soient prises en compte :

sudo systemctl restart redis.service

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

Étape 2 — Tester Redis

Comme pour tout logiciel nouvellement installé, il est recommandé de s'assurer que Redis fonctionne correctement avant d'apporter d'autres modifications à sa configuration. Nous allons passer en revue quelques méthodes pour vérifier que Redis fonctionne correctement à cette étape.

Commencez par vérifier que le service Redis est en cours d'exécution :

sudo systemctl status redis

S'il s'exécute sans aucune erreur, cette commande produira une sortie similaire à ce qui suit :

● 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 qu'il est déjà activé, ce qui signifie qu'il est configuré pour démarrer à chaque démarrage du serveur.

sudo systemctl disable redis

Pour vérifier que Redis fonctionne correctement, connectez-vous au serveur en utilisant redis-cli, le client en ligne de commande de Redis :

redis-cli

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

ping

PONG

Cette sortie confirme que la connexion au serveur est toujours active. Ensuite, vérifiez que vous pouvez définir des clés en exécutant :

set test "It's working!"

OK

Récupérez la valeur en tapant :

get test

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

"It's working!"

Après avoir confirmé que vous pouvez récupérer la valeur, quittez l'invite Redis pour revenir au shell :

exit

Comme test final, nous vérifierons 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 d'abord l'instance Redis :

sudo systemctl restart redis

Puis reconnectez-vous avec le client en ligne de commande :

redis-cli

Et confirmez que votre valeur de test est toujours disponible

get test

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

"It's working!"

Sortez à nouveau dans le shell lorsque vous avez terminé :

exit

Avec cela, votre installation de Redis est entièrement opérationnelle et prête à être utilisée. Cependant, certaines de ses configurations par défaut sont peu sécuritaires et offrent aux acteurs malveillants des opportunités d’attaquer et d’accéder à votre serveur et à ses données. Les étapes restantes de ce tutoriel couvrent les méthodes pour atténuer ces vulnérabilités, comme le recommande le site officiel de Redis. Bien que ces étapes soient optionnelles et que Redis fonctionne toujours si vous choisissez de ne pas les suivre, il est fortement recommandé de les compléter afin de renforcer la sécurité de votre système.

Étape 3 — Liaison à localhost

Par défaut, Redis n'est accessible que depuis localhost. Cependant, si vous avez installé et configuré Redis en suivant un tutoriel différent de celui-ci, il se peut que vous ayez modifié le fichier de configuration pour permettre les connexions depuis n'importe où. Cela n’est pas aussi sûr que de se lier à localhost.

Pour corriger cela, ouvrez le fichier de configuration de Redis pour le modifier :

sudo nano /etc/redis/redis.conf

Localisez cette ligne et assurez-vous qu'elle n'est pas commentée (retirez le # si elle existe) :

bind 127.0.0.1 ::1

Enregistrez et fermez le fichier une fois terminé (appuyez sur CTRL + X, Y, puis ENTRÉE).

Ensuite, redémarrez le service pour vous assurer que systemd prend en compte vos modifications :

sudo systemctl restart redis

Pour vérifier que ce changement a été pris en compte, exécutez la commande netstat suivante :

sudo netstat -lnp | grep redis

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  

sudo apt install net-tools

Cette sortie montre que le programme redis-server est lié à localhost (127.0.0.1), reflétant le changement que vous venez de faire dans le fichier de configuration. Si vous voyez une autre adresse IP dans cette colonne (0.0.0.0, par exemple), vous devriez alors vérifier que vous avez bien décommenté la ligne correcte et redémarrer le service Redis.

Maintenant que votre installation de Redis n'écoute que sur localhost, il sera plus difficile pour des acteurs malveillants de faire des requêtes ou d'accéder à votre serveur. Cependant, Redis n'est actuellement pas configuré pour exiger que les utilisateurs s'authentifient avant de modifier sa configuration ou les données qu'il contient. Pour remédier à cela, Redis permet d'exiger que les utilisateurs s'authentifient avec un mot de passe avant de faire des modifications via le client Redis (redis-cli).

Étape 4 — Sécuriser Redis avec des listes de contrôle d'accès (ACL)

À partir de Redis 6, les listes de contrôle d'accès (ACL) sont la méthode privilégiée pour gérer l'accès des utilisateurs et leurs permissions. Les ACL remplacent l'ancienne directive requirepass par un système plus flexible qui vous permet de définir plusieurs utilisateurs avec des mots de passe et des permissions de commande distincts.

Générer un mot de passe sécurisé

Tout d'abord, générez un mot de passe fort pour votre utilisateur. Vous pouvez utiliser la commande openssl pour créer une chaîne longue et aléatoire.

openssl rand 60 | openssl base64 -A

Copiez le résultat, car vous l’utiliserez comme mot de passe pour votre nouvel utilisateur Redis.

Configuration d'un nouvel utilisateur

Maintenant, ouvrez à nouveau le fichier de configuration de Redis.

sudo nano /etc/redis/redis.conf

Faites défiler jusqu'à la section ACL. Pour créer un nouvel utilisateur, vous devez ajouter une directive user. Il est également recommandé, pour des raisons de sécurité, de désactiver l'utilisateur default, qui par défaut n'a pas de mot de passe et dispose de toutes les autorisations.

Ajoutez les lignes suivantes à votre configuration :

# Disable the default user.
user default off

# Create a new user with a strong password and full permissions.
user myuser on >your_generated_password ~* &* +@all

Voici un aperçu de la nouvelle règle pour les nouveaux utilisateurs :

• myuser : Le nom d'utilisateur.
• activé : Permet à l'utilisateur.
• >votre_mot_de_passe_généré : Définit le mot de passe de l’utilisateur.
• ~* &* +@all : Une règle qui permet à l'utilisateur d'exécuter toutes les commandes (+@all) sur tous les espaces de clés (~*) et tous les canaux Pub/Sub (&*).

Enregistrez et fermez le fichier, puis redémarrez Redis.

sudo systemctl restart redis.service

Vérification de la configuration ACL

Pour vérifier que les modifications ont fonctionné, essayez de vous connecter avec redis-cli et exécutez une commande sans vous authentifier.

redis-cli ping

Comme l’utilisateur default est maintenant désactivé, Redis renverra une erreur d’authentification.

NOAUTH Authentication required.

Cela confirme que l'accès non authentifié est bloqué. Maintenant, testez le nouvel utilisateur. Utiliser l'option --askpass est plus sûr que de taper le mot de passe directement, car cela empêche que le mot de passe soit enregistré dans l'historique de votre shell.

redis-cli --user myuser --askpass

Entrez le mot de passe que vous avez généré lorsqu'on vous le demande. Une fois connecté, essayez d'exécuter une commande.

ping

Redis devrait retourner PONG. Votre configuration ACL fonctionne correctement.

Étape 5 — Chiffrement des communications Redis avec TLS

Les ACL protègent votre instance Redis contre tout accès non autorisé, mais elles ne protègent pas les données transmises sur un réseau. TLS (Transport Layer Security) chiffre ce trafic, empêchant l'écoute clandestine entre le client et le serveur.

Génération de certificats TLS

Tout d'abord, créez un répertoire pour stocker vos certificats.

sudo mkdir /etc/redis/tls

Ensuite, utilisez openssl pour générer une autorité de certification (CA) auto-signée, une clé serveur et un certificat serveur. Il vous sera demandé de saisir des informations (nom du pays, nom de l'organisation, etc.).

# Generate CA Key and Certificate

sudo openssl genrsa -out /etc/redis/tls/ca.key 4096

sudo openssl req -x509 -new -nodes -key /etc/redis/tls/ca.key -sha256 -days 365 -out /etc/redis/tls/ca.crt



# Generate Server Key and Certificate Signing Request (CSR)

sudo openssl genrsa -out /etc/redis/tls/redis.key 2048

sudo openssl req -new -key /etc/redis/tls/redis.key -out /etc/redis/tls/redis.csr



# Sign the server certificate with the CA

sudo openssl x509 -req -in /etc/redis/tls/redis.csr -CA /etc/redis/tls/ca.crt -CAkey /etc/redis/tls/ca.key -CAcreateserial -out /etc/redis/tls/redis.crt -days 365 -sha256

Définissez les autorisations correctes pour vous assurer que seul l'utilisateur redis peut accéder à ces fichiers sensibles.

sudo chmod 640 /etc/redis/tls/*

sudo chown redis:redis /etc/redis/tls/*

Configuration de Redis pour TLS

Ouvrez le fichier de configuration de Redis.

sudo nano /etc/redis/redis.conf

Ajoutez ou modifiez les lignes suivantes pour activer TLS. La meilleure pratique consiste à désactiver le port non chiffré en définissant port 0 et à n'utiliser que le port activé pour TLS.

# Disable the non-encrypted TCP port.
port 0

# Enable the TLS port on the standard Redis port.
tls-port 6379

# Point to your certificate files.
tls-cert-file /etc/redis/tls/redis.crt
tls-key-file /etc/redis/tls/redis.key
tls-ca-cert-file /etc/redis/tls/ca.crt

Enregistrez le fichier et redémarrez Redis.

sudo systemctl restart redis.service

Test de la connexion TLS

Pour se connecter avec redis-cli, vous devez maintenant spécifier les paramètres TLS.

redis-cli --user myuser --askpass --tls --cacert /etc/redis/tls/ca.crt

Après authentification, votre connexion à Redis est entièrement cryptée.

Optionnel : Configuration du TLS mutuel (mTLS)

Pour un niveau de sécurité encore plus élevé, vous pouvez configurer le TLS mutuel (mTLS), où le client doit également présenter un certificat valide au serveur.

Tout d'abord, générez une clé client et un certificat, signés par votre AC.

# Generate client key and CSR

openssl genrsa -out client.key 2048

openssl req -new -key client.key -out client.csr



# Sign the client certificate with your CA

sudo openssl x509 -req -in client.csr -CA /etc/redis/tls/ca.crt -CAkey /etc/redis/tls/ca.key -CAcreateserial -out client.crt -days 365 -sha256

Ensuite, activez l'authentification client dans /etc/redis/redis.conf.

tls-auth-clients yes

Redémarrez Redis. Maintenant, les clients doivent présenter leur certificat et leur clé pour se connecter.

redis-cli --user myuser --askpass --tls \

  --cacert /etc/redis/tls/ca.crt \

  --cert client.crt \

  --key client.key

Étape 6 — Configuration des règles de pare-feu et de l'accès à distance sécurisé

Un pare-feu est une couche de sécurité essentielle qui limite le trafic réseau vers votre serveur. Par défaut, Redis n'écoute que sur l'interface de bouclage locale (127.0.0.1), donc il n'est pas exposé à Internet public. Si vous devez vous connecter depuis un serveur externe, vous devez configurer Redis pour qu'il écoute sur son IP publique et définir des règles de pare-feu strictes.

Règles de pare-feu pour un serveur distant

Si vous devez autoriser des connexions directes, utilisez ufw pour permettre le trafic sur le port TLS de Redis (6379) uniquement à partir d'une adresse IP spécifique et de confiance.

sudo ufw allow from your_trusted_ip/32 to any port 6379 proto tcp

Remplacez your_trusted_ip par l'adresse IP statique de votre serveur d'application.

Assurez-vous toujours que votre port SSH est autorisé.

sudo ufw allow OpenSSH

Enfin, activez le pare-feu s’il n’est pas déjà activé.

sudo ufw enable

Alternatives plus sécuritaires pour l'accès à distance

Au lieu d'ouvrir le port Redis à tout le monde, envisagez ces méthodes plus sécuritaires :

• VPN : Configurez un réseau privé en utilisant un VPN comme WireGuard ou OpenVPN. Votre serveur d'application et votre serveur Redis peuvent alors communiquer via un canal privé et sécurisé sans exposition publique.
• Tunnel SSH : Créez un tunnel SSH chiffré depuis votre machine cliente vers le serveur Redis. Cela redirige un port local de votre client vers le port Redis sur le serveur via la connexion SSH sécurisée.

Exemple de création d'un tunnel SSH :

ssh -L 8000:127.0.0.1:6379 user@your_redis_server_ip

Vous pouvez ensuite connecter votre client Redis local à localhost:8000, et le trafic sera acheminé de manière sécurisée vers le serveur Redis.

Étape 7 — Application de techniques de renforcement supplémentaires

Vous pouvez renforcer davantage la sécurité de votre instance Redis avec ces mesures supplémentaires.

Restreindre les commandes avec des ACL (l'approche moderne)

Au lieu de renommer des commandes dangereuses (une pratique plus ancienne), utilisez des règles ACL pour les restreindre par utilisateur. Cela offre un contrôle plus granulaire et ne perturbe pas les clients Redis ni les outils de surveillance.

Par exemple, pour empêcher myuser d'utiliser des commandes pouvant causer des dommages importants (comme FLUSHALL, DEBUG, SHUTDOWN), vous pouvez modifier leur règle ACL en supprimant la catégorie @all et en ajoutant des catégories plus spécifiques, tout en bloquant explicitement les commandes dangereuses.

# Example of a more restrictive user
user myuser on >your_generated_password ~* &* +@read +@write +@connection -@dangerous -FLUSHALL

Cette règle permet à l'utilisateur d'exécuter des commandes de lecture, d'écriture et de connexion, mais bloque explicitement la catégorie de commandes @dangerous ainsi que la commande FLUSHALL.

Renommer la commande (Méthode héritée - Non recommandée)

La pratique de renommer les commandes est en grande partie obsolète et devrait être évitée au profit des ACL. Renommer des commandes peut casser les bibliothèques clientes, compliquer la maintenance et provoquer des problèmes avec la persistance (AOF) et la réplication.

Si vous rencontrez un système utilisant cette méthode, les commandes sont renommées dans /etc/redis/redis.conf de cette manière :

# rename-command FLUSHALL ""
# rename-command CONFIG MY_SECURE_CONFIG_COMMAND

Gestion de la mémoire et sécurité

Un attaquant pourrait tenter une attaque par déni de service (DoS) en remplissant la mémoire de votre serveur. Configurez Redis pour définir une limite de mémoire afin de prévenir cela.

Dans /etc/redis/redis.conf, décommentez et définissez les directives maxmemory et maxmemory-policy :

maxmemory 2gb
maxmemory-policy allkeys-lru

• maxmemory : Définit une limite stricte à la quantité de mémoire que Redis peut utiliser.
• maxmemory-policy : Indique à Redis quoi faire lorsque la limite est atteinte. allkeys-lru évince les clés les moins récemment utilisées, ce qui est un choix courant pour les caches.

Configuration du réseau et délais d'attente

• Sockets Unix : Pour les applications s'exécutant sur la même machine que Redis, utiliser un socket Unix est plus sécuritaire qu'un port TCP car il contourne la pile réseau. Activez-le dans redis.conf :

  unixsocket /var/run/redis/redis.sock
  unixsocketperm 770

  Puis connectez-vous avec redis-cli -s /var/run/redis/redis.sock.

/etc/redis/redis.conf

• Temporisation d'inactivité : Fermez automatiquement les connexions inactives pour libérer des ressources et réduire la surface d'attaque.

  timeout 300

  Cela fermera les connexions inactives depuis 300 secondes.

/etc/redis/redis.conf

AppArmor

Ubuntu inclut AppArmor, un module de sécurité qui confine les programmes à un ensemble limité de ressources. Le paquet redis-server est livré avec un profil AppArmor par défaut qui est activé automatiquement.

Vous pouvez vérifier son statut avec :

sudo aa-status | grep redis

Ce profil fournit une couche de défense importante en limitant les actions que le processus Redis peut effectuer sur le système. Sur d'autres distributions Linux comme CentOS, SELinux remplit un rôle similaire.

Étape 8 — Surveillance de l'activité et des journaux de Redis

Il est important de surveiller régulièrement les journaux pour détecter les erreurs, les problèmes de performance et les activités suspectes.

Journaux du système

Vous pouvez consulter les journaux en temps réel gérés par systemd avec journalctl.

sudo journalctl -u redis-server.service -f

Faites attention à des motifs comme :

• Un grand nombre de nouvelles connexions provenant d'adresses IP inconnues.
• Échecs d’authentification répétés (NOAUTH).
• Erreurs liées aux commandes que vous avez restreintes.

Pour les systèmes de production, transférez ces journaux vers une plateforme de journalisation centralisée (comme une pile ELK) afin de configurer des alertes automatiques pour les schémas suspects.

Journal des opérations lentes de Redis

Le journal des requêtes lentes de Redis enregistre les requêtes qui dépassent un temps d'exécution spécifié. Il est utile pour identifier les goulots d'étranglement en termes de performance et peut également aider à repérer les commandes abusives ou inefficaces provenant des clients.

Activez-le dans /etc/redis/redis.conf :

slowlog-log-slower-than 10000
slowlog-max-len 128

• slowlog-log-slower-than : consigne les commandes prenant plus de temps que cette valeur en microsecondes (10000=10 ms).
• slowlog-max-len : Le nombre maximal d'entrées dans le journal des commandes lentes.

Afficher le journal des opérations lentes avec redis-cli :

redis-cli SLOWLOG GET

Étape 9 — Configuration de la persistance et des sauvegardes de Redis

Par défaut, Redis conserve toutes les données en mémoire. Les mécanismes de persistance sauvegardent ces données sur disque, les protégeant ainsi de la perte en cas de redémarrage du serveur.

Options de persistance

Redis offre deux principaux modes de persistance :

• RDB (Base de données Redis) : Effectue des instantanés ponctuels de votre jeu de données à des intervalles spécifiés. C'est généralement plus rapide.
• AOF (Fichier de journalisation uniquement en ajout) : Enregistre chaque opération d’écriture reçue par le serveur. Il offre une meilleure durabilité, mais peut entraîner des fichiers plus volumineux.

Vous pouvez activer l'un ou l'autre, ou les deux, dans /etc/redis/redis.conf. La configuration par défaut active RDB. Pour activer AOF :

appendonly yes

Sécurisation des fichiers de données et des sauvegardes

Les fichiers de données Redis (dump.rdb, appendonly.aof) sont stockés par défaut dans /var/lib/redis/. Assurez-vous que ce répertoire et ses fichiers appartiennent à l'utilisateur redis et qu'ils ne sont pas accessibles en lecture par tous.

sudo ls -l /var/lib/redis

Pour la reprise après sinistre, vous devez sauvegarder ces fichiers.

• Stockage sécurisé : Conservez les sauvegardes dans un emplacement sécurisé et à distance (comme un compartiment de stockage d’objets).
• Chiffrement : Chiffrez vos fichiers de sauvegarde à l'aide d'un outil comme gpg avant de les transférer hors du serveur.
• Test de récupération : Testez régulièrement vos procédures de récupération en restaurant une sauvegarde sur un serveur de mise en scène afin de vous assurer que les sauvegardes sont valides et que le processus fonctionne comme prévu.

FAQ

1. Pourquoi devrais-je utiliser les ACL Redis plutôt que l’ancienne méthode requirepass ?

Les listes de contrôle d'accès (ACL) de Redis, introduites dans Redis 6, sont la norme moderne pour gérer les autorisations des utilisateurs. Contrairement au mot de passe unique fourni par requirepass, les ACL vous permettent de créer plusieurs utilisateurs avec des mots de passe uniques et des autorisations détaillées. Vous pouvez contrôler les commandes qu'un utilisateur peut exécuter, les clés auxquelles il peut accéder et les canaux Pub/Sub qu'il peut utiliser. Ce « principe du moindre privilège » est une pratique essentielle en matière de sécurité, car il limite le dommage potentiel qu’un attaquant pourrait causer si les identifiants d’un seul utilisateur sont compromis.

2. Est-il sécuritaire d'exposer directement mon instance Redis à l'internet public ?

Non, c’est fortement déconseillé. Exposer Redis directement, même avec un mot de passe et TLS, en fait une cible pour les attaques par force brute et les vulnérabilités potentielles zero-day. Les méthodes les plus sécurisées pour l’accès à distance impliquent un réseau privé. Vous devriez utiliser un VPN (comme WireGuard ou OpenVPN) ou un tunnel SSH pour créer un canal sécurisé et chiffré entre votre serveur d’application et votre instance Redis sans jamais exposer le port Redis sur Internet.

3. Quelle est la différence entre la persistance RDB et AOF, et laquelle devrais-je utiliser ?

RDB et AOF sont tous deux des méthodes pour sauvegarder vos données Redis en mémoire sur le disque.

• RDB (base de données Redis) : Crée des instantanés de votre ensemble de données à des intervalles spécifiés (par exemple, toutes les 5 minutes s'il y a au moins une écriture). Il est généralement plus rapide pour créer des sauvegardes et redémarrer Redis.
• AOF (Fichier en mode Append Only) : Enregistre chaque opération d’écriture reçue par le serveur. Cela offre une durabilité des données bien meilleure, car vous risquez de ne perdre qu’au maximum une seconde de données en cas de panne, mais les fichiers journaux peuvent devenir volumineux.

Pour la plupart des cas d'utilisation en production, il est recommandé d'activer les deux méthodes de persistance afin de bénéficier à la fois de la durabilité (AOF) et de la commodité des sauvegardes (RDB).

4. Comment puis-je protéger Redis contre l'épuisement de la mémoire ?

Un attaquant pourrait lancer une attaque par déni de service (DoS) en écrivant continuellement des données jusqu'à ce que la mémoire de votre serveur soit épuisée. Pour éviter cela, vous devriez définir une limite de mémoire dans votre fichier redis.conf en utilisant la directive maxmemory (par exemple, maxmemory 2gb). Vous devriez également définir une maxmemory-policy (comme allkeys-lru) pour indiquer à Redis comment expulser les clés une fois cette limite atteinte.

5. Devrais-je renommer les commandes Redis dangereuses pour des raisons de sécurité ?

Renommer les commandes est une pratique de sécurité héritée qui n'est plus recommandée. L'approche moderne et plus efficace consiste à utiliser les ACL de Redis pour restreindre l'accès aux commandes dangereuses pour chaque utilisateur. Renommer les commandes est difficile à maintenir, peut casser les bibliothèques clientes et les outils de surveillance, et cause des complications avec la réplication et la persistance AOF.

6. J'ai un mot de passe configuré avec des ACL. Pourquoi ai-je aussi besoin de TLS ?

Les ACL et les mots de passe protègent votre serveur Redis contre les accès non autorisés (authentification), mais ils ne protègent pas les données lorsqu'elles circulent sur un réseau. Sans TLS (Transport Layer Security), toutes vos données — y compris les commandes et les réponses — sont envoyées en texte clair. Un attaquant sur le réseau pourrait intercepter ce trafic pour voler des informations sensibles. TLS chiffre l’ensemble de la connexion, garantissant que toute communication entre votre client et le serveur Redis est privée et sécurisée.

7. Comment puis-je surveiller mon instance Redis pour détecter toute activité suspecte ?

Vous devriez surveiller à la fois les journaux du système et le journal lent de Redis.

• Journaux système (journalctl -u redis-server.service) : Vérifiez-les pour un volume élevé de tentatives d'authentification échouées, des connexions inattendues provenant d'adresses IP inconnues ou des erreurs liées à des commandes bloquées.
• Journal lent de Redis : Activez cette fonctionnalité pour enregistrer les requêtes qui prennent beaucoup de temps à s'exécuter. Bien qu'elle soit principalement utilisée pour l'optimisation des performances, elle peut également révéler des commandes abusives ou mal conçues provenant d'un client compromis pouvant faire partie d'une attaque.

Pour les systèmes en production, ces journaux devraient être envoyés à une plateforme de journalisation centralisée où vous pouvez configurer des alertes automatisées pour ces motifs.

8. Qu'est-ce qu'AppArmor et dois-je le configurer pour Redis ?

AppArmor est un module de sécurité Linux inclus avec Ubuntu qui confine les programmes à un ensemble limité de ressources système. Le paquet redis-server est fourni avec un profil AppArmor préconfiguré qui est activé par défaut. Ce profil limite les fichiers et les capacités réseau que le processus Redis peut accéder, offrant une couche de défense critique si un attaquant trouve une vulnérabilité dans Redis lui-même. Pour une installation standard, aucune configuration supplémentaire n’est requise.

9. Comment me connecter de manière sécurisée à Redis depuis une application sur le même serveur ?

Lorsque votre application et Redis fonctionnent sur la même machine, la méthode de connexion la plus sûre est une socket Unix, et non un port TCP. Une socket Unix est un fichier sur le système de fichiers utilisé pour la communication entre processus, et elle contourne entièrement la pile réseau. C'est plus rapide et plus sûr, car elle est soumise aux permissions du système de fichiers et ne peut pas être accessible depuis l'extérieur du serveur.

10. J’ai configuré le TLS avec des certificats auto-signés. Est-ce que c’est acceptable pour la production ?

Les certificats auto-signés sont acceptables pour le développement, les tests ou les services internes où vous pouvez distribuer en toute sécurité votre propre autorité de certification (AC) à chaque client. Cependant, pour les applications se connectant via Internet public ou dans des environnements de production plus grands et plus complexes, il est fortement recommandé d’utiliser des certificats TLS délivrés par une autorité de certification publique et fiable comme Let’s Encrypt. Cela simplifie la gestion des certificats et évite les problèmes de confiance avec les clients.

Conclusion

Dans ce tutoriel, vous avez installé et configuré Redis, vérifié que votre installation de Redis fonctionne correctement, et utilisé ses fonctionnalités de sécurité intégrées pour la 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 fonction de sécurité la plus importante de votre serveur Redis est votre pare-feu (que vous avez configuré si vous avez suivi le tutoriel préalable Configuration initiale du serveur), car cela rend extrêmement difficile pour les acteurs malveillants de franchir cette barrière.

Bien que ce guide vous aidera à commencer l'installation et la sécurisation de Redis, nous vous recommandons fortement de consulter la documentation officielle pour une meilleure sécurité :

• Administration de Redis
• Sécurité Redis
• Configuration de Redis

Merci de apprendre avec la communauté Linux-Console.net.