| Port | 9200 |
|---|---|
| Transport | TCP |
| Service | Elasticsearch |
| Category | Databases and caches |
| Range | registered (1024–49151) |
| Encrypted | Optional, must be configured |
| Exposure | Private network or VPN only |
Port 9200 Elasticsearch · TCP
Elasticsearch and OpenSearch HTTP API. Before Elasticsearch 8, clusters shipped with no authentication, and the number of exposed 9200 ports with customer data in them became a genre of data-breach news.
What runs on port 9200
Elasticsearch and OpenSearch HTTP API. Before Elasticsearch 8, clusters shipped with no authentication, and the number of exposed 9200 ports with customer data in them became a genre of data-breach news. Since 8.0 security is on by default; OpenSearch requires the security plugin. Either way: TLS, authentication, and a private network.
Software that uses it: Elasticsearch · OpenSearch · Logstash, Beats, Kibana (clients) · Elastic Cloud, Amazon OpenSearch
Should port 9200 be open?
Private network or VPN only. Nothing good comes from this port being reachable from the internet. Keep it on an internal network, reach it over a VPN or an SSH tunnel, and firewall it from everything that does not need it.
- curl -s http://host:9200/ returning a JSON banner with no 401 means the cluster is open; _cat/indices would list everything.
- _cluster/health, _cat/nodes and _cat/indices?v are the three commands you run first.
Check port 9200
# on the host: is anything listening, and which process? ss -ltnp 'sport = :9200' sudo lsof -i :9200 # from another machine: is it reachable? nc -zv host 9200 nmap -p 9200 host curl -v telnet://host:9200 # raw TCP connect test, Ctrl-C to leave
A port that answers from the internet when it should not is the finding; nmap from a machine outside your network (or a VPS) is the honest test, because scans from inside the LAN pass the firewall you are trying to verify.
Allow or block port 9200
# ufw (Ubuntu/Debian) sudo ufw allow from 10.0.0.0/8 to any port 9200 proto tcp sudo ufw deny 9200/tcp # nftables nft add rule inet filter input ip saddr 10.0.0.0/8 tcp dport 9200 accept nft add rule inet filter input tcp dport 9200 drop # iptables (legacy) iptables -A INPUT -p tcp --dport 9200 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp --dport 9200 -j DROP # firewalld sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.0.0.0/8 port port=9200 protocol=tcp accept'
Replace 10.0.0.0/8 with the networks that need access. Allowing by source address is the rule that matters; "allow 9200" with no source is just "open".
Related ports
Part of the port number reference. Ports are 16-bit numbers; see also the subnet calculator and the packet decoder, which shows ports inside TCP and UDP headers.
Questions
Is port 9200 TCP or UDP?
TCP. Elasticsearch is a connection-oriented protocol; there is no UDP service on 9200 by default (a scanner reporting UDP 9200 open is usually seeing a filtered port).
Is port 9200 encrypted?
Optional, must be configured. Turn encryption on in the service configuration before using it across any network you do not control.
How do I check whether port 9200 is open?
On the server, ss -ltnp (or -lunp for UDP) shows whether something listens on 9200 and which process. From another machine, nc -zv host 9200 or nmap -p 9200 host tests reachability. "Open" in a scan means something answered; a firewall usually makes the port filtered (no answer) rather than closed (RST).
Can Elasticsearch run on a different port?
Yes; the number is a convention, not a requirement. Changing it reduces log noise from scanners but does not add security, and every client, firewall rule and monitoring check then needs the new number. Keep the default unless you have a concrete reason.