Référence des ports
Port 6379 (TCP) – Redis
Port par défaut du magasin de données en mémoire et cache Redis.
État par défaut
Historiquement, Redis se liait à toutes les interfaces SANS authentification par défaut ; les versions modernes intègrent un « mode protégé » lié à localhost. De nombreuses instances exposées restent sans authentification.
Attaques courantes
- Accès non authentifié pour lire, modifier ou effacer toutes les données
- RCE via réécriture de configuration (écriture de clés SSH ou de tâches cron via CONFIG SET/SAVE)
- Abus du chargement de modules pour l'exécution de code à distance
- Vol de données et rançonnage des instances exposées
Durcissement
- Lier à localhost ou à une interface privée ; garder le mode protégé activé
- Exiger l'authentification (requirepass / ACL) avec un mot de passe fort
- Ne jamais exposer 6379 à Internet ; limiter par pare-feu aux hôtes de confiance
- Renommer ou désactiver les commandes dangereuses (CONFIG, FLUSHALL, MODULE) et exiger TLS
- Exécuter Redis sous un utilisateur non privilégié et appliquer les correctifs régulièrement
Commande nmap
nmap -p6379 --script redis-info <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Que tourne sur le port 6379 ?
Le port 6379 est le port par défaut de Redis, un magasin de données en mémoire haute performance utilisé comme cache, courtier de messages et base de données. Les applications se connectent via 6379 pour lire et écrire des clés à très faible latence. Redis utilise un protocole texte simple et, point crucial, a historiquement été livré sans authentification activée.
Pourquoi c'est important pour la sécurité
Redis est l'un des services les plus tristement célèbres pour son exposition sur Internet. Pendant des années, il se liait à toutes les interfaces sans mot de passe ; quiconque atteignait 6379 avait donc un contrôle total en lecture/écriture. Pire, Redis peut écrire des fichiers sur disque, ce qui transforme une instance ouverte en primitive d'exécution de code à distance — et au-delà du vol de données, les attaquants effacent souvent les instances exposées et exigent une rançon.
Comment c'est attaqué
Les attaquants scannent les ports 6379 ouverts et se connectent sans identifiants.
Ils vident ou effacent toutes les données, puis escaladent vers le RCE via
réécriture de configuration : en utilisant CONFIG SET et SAVE pour déposer
des authorized_keys SSH ou des tâches cron, ou en chargeant un module
malveillant. Le résultat est souvent un contrôle total de l'hôte qui exécute
Redis.
Liste de durcissement
Liez Redis à localhost ou à une interface privée, gardez le mode protégé
activé, et exigez l'authentification via requirepass ou des ACL avec un
mot de passe fort. N'exposez jamais 6379 à Internet — limitez-le par pare-feu aux
hôtes de confiance. Renommez ou désactivez les commandes dangereuses
(CONFIG, FLUSHALL, MODULE), exigez TLS, exécutez Redis sous un
utilisateur non privilégié et appliquez les correctifs régulièrement. Utilisez
l'extrait nmap ci-dessus pour vérifier l'exposition sur les hôtes que vous êtes
autorisé à tester.
Ports liés
Questions fréquentes
- Redis exige-t-il un mot de passe par défaut ?
- Historiquement non — les premières versions de Redis n'avaient aucune authentification, ce qui a entraîné des compromissions massives. Définissez toujours requirepass ou des ACL, liez à localhost et gardez le mode protégé activé.
- Comment un Redis exposé mène-t-il à l'exécution de code à distance ?
- Un attaquant non authentifié peut utiliser CONFIG SET/SAVE pour écrire des fichiers comme SSH authorized_keys ou des tâches cron, ou charger un module malveillant, transformant l'accès aux données en compromission totale de l'hôte.