Datahorses

Ports de bases de données exposés : MySQL, PostgreSQL, MongoDB, Redis et Elasticsearch

Par · · 4 min de lecture

Un port de base de données est exposé quand n'importe qui sur Internet peut y ouvrir une connexion. Votre application a besoin d'atteindre la base de données ; un ordinateur quelconque dans un autre pays, non. Pourtant, une seule règle de pare-feu, une ligne de configuration modifiée ou un réglage par défaut du cloud peut suffire pour que MySQL, PostgreSQL, MongoDB, Redis ou Elasticsearch répondent à tout Internet.

Un port ouvert n'est pas automatiquement une fuite. Si l'authentification est solide et le logiciel à jour, l'attaquant doit encore la franchir. Mais un port ouvert fait de votre base de données une cible que n'importe qui peut sonder, sur laquelle on peut deviner des mots de passe et tester des vulnérabilités connues. Le fermer supprime toute cette catégorie de risque.

Cet article liste les ports par défaut, montre comment vérifier depuis l'extérieur et explique comment les fermer correctement.

Les ports par défaut à connaître

Voici les ports par défaut indiqués dans la documentation de chaque éditeur :

Les services peuvent tourner sur d'autres ports : considérez cette liste comme un point de départ, pas comme un scan complet.

Comment les bases de données se retrouvent sur Internet

La plupart de ces produits sont plus sûrs par défaut qu'autrefois :

L'exposition vient donc généralement d'une modification volontaire censée être temporaire :

  • quelqu'un a mis bind-address = 0.0.0.0, listen_addresses = '*' ou bindIpAll pour qu'un développeur puisse se connecter depuis chez lui,
  • le mode protégé ou la sécurité a été désactivé « pour que ça marche »,
  • un groupe de sécurité cloud ou une règle de pare-feu autorise le port depuis 0.0.0.0/0,
  • un -p 6379:6379 dans Docker publie le port sur toutes les interfaces de l'hôte,
  • un ancien serveur de test ou de préproduction avec sa propre base de données n'a jamais été arrêté.

La documentation de Redis est directe sur le risque : Redis est conçu pour des clients de confiance dans des environnements de confiance, et une instance exposée peut perdre toutes ses données sur une seule commande FLUSHALL.

Comment vérifier depuis l'extérieur

La vérification doit se faire depuis l'extérieur de votre réseau, sinon vous ne testez que le chemin interne. Utilisez une machine sur une autre connexion (une VM cloud, un partage de connexion depuis un téléphone) et ne testez que des adresses IP qui vous appartiennent :

for port in 3306 5432 27017 6379 9200 9300; do
  nc -z -w 3 203.0.113.10 $port && echo "$port open" || echo "$port closed"
done

Sur le serveur lui-même, regardez sur quelles adresses chaque service écoute :

sudo ss -tlnp | grep -E ':(3306|5432|27017|6379|9200|9300)\b'

127.0.0.1:5432 ou une adresse privée, c'est ce que vous voulez. 0.0.0.0:5432 ou [::]:5432 signifie que le service écoute sur toutes les interfaces, et que seul un pare-feu le sépare d'Internet.

Les scanners d'Internet indexent aussi les ports ouverts de chaque adresse IP accessible depuis Internet. Pour voir rapidement ce qu'ils ont enregistré pour l'une de vos adresses, Shodan propose une consultation simple sur https://internetdb.shodan.io/<your-ip>.

Comment fermer correctement

Utilisez 2 couches, pour qu'une seule erreur n'expose pas de nouveau la base de données :

  1. N'écoutez que sur des interfaces privées. bind-address = 127.0.0.1 (MySQL), listen_addresses = 'localhost' ou une IP privée (PostgreSQL), net.bindIp (MongoDB), bind 127.0.0.1 avec protected-mode yes (Redis), network.host sur une adresse privée (Elasticsearch).
  2. Restreignez au niveau réseau. Le pare-feu ou le groupe de sécurité cloud ne doit autoriser le port de la base que depuis vos serveurs applicatifs.
  3. Accès distant par tunnel. Les développeurs se connectent via des tunnels SSH ou un VPN, jamais par un port ouvert.
  4. Exigez l'authentification partout, même sur les réseaux internes : utilisateurs avec le moindre privilège, mots de passe longs et TLS pour les connexions qui sortent d'un hôte unique.
  5. Maintenez le logiciel à jour, pour que si un port est un jour exposé par erreur, il ne fasse pas tourner en plus une version aux vulnérabilités connues.

Si une base de données a été exposée avec une authentification faible ou absente, considérez que ses données ont pu être copiées : changez les identifiants, examinez les journaux et évaluez vos obligations de notification.

Une courte liste de contrôle

  • Listez toutes les adresses IP visibles depuis Internet utilisées par votre entreprise, y compris les anciens serveurs.
  • Testez les ports de bases de données courants depuis l'extérieur.
  • Vérifiez que chaque base de données n'écoute que sur localhost ou une adresse privée.
  • N'autorisez les ports de bases de données dans le pare-feu que depuis les serveurs applicatifs.
  • Revérifiez après chaque migration, nouveau serveur ou modification Docker.

Les services ouverts apparaissent rarement seuls. Ils se trouvent souvent sur les mêmes serveurs de préproduction oubliés qui laissent aussi fuiter des fichiers .env et des sauvegardes.

Comment Datahorses vous aide

Datahorses surveille votre entreprise depuis l'extérieur chaque jour et montre quels services un attaquant peut voir sur vos adresses visibles depuis Internet, y compris les ports de bases de données et les accès distants comme RDP ou SSH, avec les vulnérabilités connues des versions qu'ils révèlent. Nous n'entrons pas dans vos systèmes et n'avons besoin d'aucun accès. Chaque constat est accompagné d'étapes précises pour votre développeur, comme décrit dans ce qui se passe quand nous trouvons quelque chose. Le tableau de bord d'exemple montre à quoi ressemble un tel rapport.

Plus d’articles

Tous les articles