Référence des ports
Port 9300 (TCP) – Transport Elasticsearch
Port par défaut du protocole de transport binaire d'Elasticsearch utilisé pour la communication nœud-à-nœud et de cluster.
État par défaut
Les anciennes versions d'Elasticsearch exposaient le protocole de transport sur 9300 sans authentification ni TLS ; un hôte atteignant 9300 pouvait donc rejoindre ou interroger le cluster. Les versions modernes activent la sécurité et se lient de façon privée.
Attaques courantes
- Accès transport non authentifié pour interroger ou exfiltrer les données du cluster
- Nœuds malveillants rejoignant le cluster pour lire ou manipuler les index
- RCE de scripting propre à certaines versions, comme l'ère Groovy de CVE-2015-1427
- Divulgation de l'état du cluster et des documents indexés
Durcissement
- Lier le transport à une interface privée (transport.host) ; ne jamais exposer 9300 à Internet
- Activer les fonctions de sécurité (authentification et TLS nœud-à-nœud)
- Limiter 9300 par pare-feu aux seuls membres du cluster
- Désactiver le scripting dynamique sur les anciennes versions et corriger les failles RCE
- Maintenir Elasticsearch à jour et auditer l'appartenance au cluster
Commande nmap
nmap -p9300 --script banner <target>Remplacez <target> par l’hôte ou la plage que vous êtes autorisé à scanner.
Que tourne sur le port 9300 ?
Le port 9300 est le port par défaut du protocole de transport d'Elasticsearch, le canal binaire que les nœuds utilisent pour communiquer entre eux afin de former le cluster, répliquer les shards et exécuter des requêtes internes. Il est distinct de l'API HTTP/REST orientée client sur 9200 ; le 9300 est destiné au trafic intra-cluster entre les nœuds Elasticsearch.
Pourquoi c'est important pour la sécurité
La couche de transport porte toute la confiance du cluster. Les anciennes versions d'Elasticsearch exposaient 9300 sans authentification ni TLS ; tout hôte pouvant l'atteindre pouvait donc interroger les données ou rejoindre le cluster en tant que nœud et manipuler les index. La même époque d'Elasticsearch permettait aussi l'abus du scripting dynamique, dont le RCE Groovy (CVE-2015-1427), rendant l'exposition du transport très dangereuse.
Comment c'est attaqué
Les attaquants scannent les ports 9300 ouverts et, sans authentification, interrogent ou exfiltrent les données du cluster ou tentent d'y faire rejoindre un nœud malveillant capable de lire et de manipuler les index. Contre les anciennes versions, ils exploitent le RCE de scripting dynamique comme CVE-2015-1427 pour exécuter du code sur un nœud. L'état du cluster divulgué facilite l'énumération aux côtés de l'API HTTP sur 9200.
Liste de durcissement
Liez le transport à une interface privée via transport.host et gardez 9300
hors d'Internet. Activez les fonctions de sécurité intégrées (authentification
et TLS nœud-à-nœud), et limitez 9300 par pare-feu aux seuls membres du
cluster. Sur les anciennes versions, désactivez le scripting dynamique et
corrigez les failles RCE, maintenez Elasticsearch à jour et auditez
l'appartenance au cluster. 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
- Quelle est la différence entre les ports Elasticsearch 9200 et 9300 ?
- Le 9200 est l'API HTTP/REST utilisée par les clients, tandis que le 9300 est le protocole de transport binaire utilisé pour la communication nœud-à-nœud et de cluster. Les deux doivent être liés de façon privée, sécurisés par TLS et authentification, et limités par pare-feu.
- Est-il sûr d'exposer le transport Elasticsearch sur le port 9300 ?
- Non. Sans sécurité, un hôte atteignant 9300 peut rejoindre le cluster ou interroger les données, et les anciennes versions permettaient le RCE de scripting (CVE-2015-1427). Liez le transport de façon privée, activez le TLS nœud-à-nœud et limitez le port par pare-feu.