Port 9200 (Elasticsearch)

What port 9200 is

TCP port 9200 is the HTTP REST API of Elasticsearch, and of OpenSearch, which kept the same defaults. Clients, Kibana, Logstash, Beats and your application all send JSON requests there. Nodes in a cluster talk to each other on a second port.

Whether 9200 is encrypted depends on the version and configuration. Since Elasticsearch 8.0, security is on by default for new installs: the first start generates certificates, enables TLS on 9200 and creates a password for the elastic user. Older versions, and clusters upgraded with security switched off, answer plain HTTP without authentication.

Should it be open to the internet?

No. An Elasticsearch API with no authentication lets anyone read every index, delete it, or change cluster settings. Exposed clusters have been behind many large data leaks, and automated scripts routinely wipe open clusters and leave a ransom note index. Even with authentication, keep 9200 on a private network and let only your application servers and Kibana reach it. Port 9300 should never be reachable from outside the cluster.

Security settings

In elasticsearch.yml, bind to a private address and keep security on:

network.host: 192.0.2.10
http.port: 9200
xpack.security.enabled: true
xpack.security.http.ssl.enabled: true
xpack.security.transport.ssl.enabled: true

With no network.host set, Elasticsearch binds to loopback only. Once you bind to a non-loopback address it runs its production bootstrap checks, so settings like vm.max_map_count must be correct or it refuses to start.

Create a separate user or API key for each application with only the index privileges it needs, rather than sharing the elastic superuser. OpenSearch uses its own security plugin with similar concepts; its configuration keys differ, so follow the OpenSearch documentation for your version.

Firewall rules

sudo ufw allow from 192.0.2.20 to any port 9200 proto tcp
sudo ufw allow from 192.0.2.0/24 to any port 9300 proto tcp

sudo iptables -A INPUT -p tcp -s 192.0.2.20 --dport 9200 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 9200 -j DROP

With Docker, publish on loopback (-p 127.0.0.1:9200:9200). Ports published on all interfaces bypass ufw on most Linux hosts.

How to check what is listening

sudo ss -tlnp | grep -E ':(9200|9300)'
sudo lsof -i :9200
curl -k -u elastic https://127.0.0.1:9200/

The root endpoint returns the cluster name and version. Use http:// instead for a cluster without TLS. To test from outside, run nc -zv search.example.com 9200 from another network; it should time out or be refused. If curl http://search.example.com:9200/_cat/indices from outside lists your indices, the cluster is exposed and needs fixing now.

Our Port Scanner does not probe 9200, so use these commands to check it.

"Port 9200 already in use"

Usually a second Elasticsearch or OpenSearch instance, often a container next to a system package. Find it with sudo lsof -i :9200, stop one, or set http.port: 9201 (or map -p 127.0.0.1:9201:9200). Older versions defaulted to a port range and could quietly move to 9201; the startup log shows the address a node actually bound.

Related ports

• Port 27017: MongoDB, another data store often found exposed.
• Port 6379: Redis.
• Port 5432: PostgreSQL.
• Port 443: where a proxy in front of the API should listen if it must be public.

To check the database ports our scanner does cover on the same host, run the Port Scanner.