Bind Elasticsearch to a private interface

The fix/etc/elasticsearch/elasticsearch.yml

network.host: 127.0.0.1
# or, to serve a private network explicitly:
# network.host: 10.0.1.5
# http.host: 10.0.1.5
# transport.host: 127.0.0.1

sudo systemctl restart elasticsearch

Why it matters

network.host sets the address Elasticsearch binds. The default is loopback, which is safe and useless for anything but a single-node local setup — so people change it, and the change is where the exposure comes from.

The failure mode is specific and common: someone needs a remote client to connect, sets network.host: 0.0.0.0, and now the cluster listens on every interface — including the public one, if there is one. Combined with security disabled, that is the exact configuration behind most of the Elasticsearch data breaches.

0.0.0.0 is almost never what you actually want. You want the one private interface your clients use.

The two ports do different jobs

Elasticsearch listens on two ports, and conflating them is a common mistake:

Port	Purpose	Who should reach it
9200	HTTP / REST API	Your applications and Kibana
9300	Transport (inter-node)	Only other cluster nodes

The transport port is the more dangerous exposure. It’s how nodes join the cluster and replicate data, and it should never be reachable from anywhere except your other nodes. You can split them:

http.host: 10.0.1.5         # apps reach the API here
transport.host: 127.0.0.1   # or the private cluster interface only

On a single node, bind transport to loopback. On a multi-node cluster, bind it to the private interface the nodes share — and nothing else.

Production mode is a safety feature, not an obstacle

This is the part worth understanding rather than working around.

When you set network.host to anything other than a loopback address, Elasticsearch switches from development mode to production mode and enforces bootstrap checks. These are hard preconditions — vm.max_map_count, heap settings, discovery configuration, file descriptor limits — and if any fails, the node refuses to start.

People hit a bootstrap check failure, find that reverting network.host to loopback makes it start, and conclude the checks are the problem. They are not. The checks are Elasticsearch saying “you are about to run this where it matters, and these settings would bite you under load.” A node that only passes because it’s bound to loopback is a node that will fall over the first time it’s stressed.

Fix the checks it names — they’re documented and specific — rather than dodging them by staying in development mode. The bootstrap checks are one of the better safety mechanisms in any service on this site.

Verify it worked

Check what’s actually listening:

sudo ss -lntp | grep -E ':9200|:9300'

Expect the private or loopback address — not 0.0.0.0 on either port. 0.0.0.0:9300 is the worse of the two.

Confirm against the running node:

curl -sk -u elastic https://localhost:9200/_nodes/_local/http,transport?filter_path='**.bound_address'

Then prove it from another host — both ports:

curl -sk --connect-timeout 5 https://your.es:9200/ -o /dev/null -w 'http: %{http_code}\n'
nc -zv -w5 your.es 9300 2>&1 | tail -1

A timeout on both is the goal. A response on 9200 means the API is reachable (fine only if authenticated and firewalled); anything on 9300 from outside your node network is a serious finding.

Check which mode the node booted in — the log says so at startup:

sudo journalctl -u elasticsearch | grep -iE 'bootstrap check|development mode|production mode' | tail

Before you apply this

Changing network.host needs a restart, and on a multi-node cluster it can break cluster formation if you get the transport binding wrong — nodes that can’t reach each other on 9300 won’t form a cluster, and the symptom is a node that starts but never joins.

Two things to get right before restarting:

Bootstrap checks will now be enforced. If this node has only ever run in development mode, the restart may fail a check it previously skipped. Read the node’s requirements first — the common one is vm.max_map_count:

sysctl vm.max_map_count        # needs to be at least 262144
# fix persistently:
echo 'vm.max_map_count=262144' | sudo tee /etc/sysctl.d/99-elasticsearch.conf
sudo sysctl --system

Better to set these before the restart than to discover a node won’t start.

Know your clients’ addresses. Narrowing from 0.0.0.0 to one interface disconnects any client that was reaching a different one. List what’s connected:

curl -sk -u elastic https://localhost:9200/_nodes/stats/http?filter_path='**.clients' 2>/dev/null

Binding is not firewalling. A private-interface bind still accepts every host on that network. On a cloud VPC that’s a large group. Bind narrows the interface; a firewall on 9200/9300 narrows the source — do both, and keep 9300 reachable only by your nodes.

Related

• Enable security — do this too; binding alone isn’t enough.
• Enable TLS — the transport port needs it between nodes.
• Elasticsearch exposed to the internet — what 0.0.0.0 plus no auth means.