/PLAYBOOK · 2026-08-17

Elasticsearch Security Hardening: Unauthorized Access Defense and X-Pack Configuration

From unauthorized-access exposure to TLS and RBAC. Elasticsearch hardening: use cases, config steps, and verification, including X-Pack security.

Use Cases

Elasticsearch hardening fits: a cluster with no auth, 9200 reachable from the internet or other internal hosts, full index read; ES holding logs, business data, or secrets under compliance/audit; or after suspected unauthorized access (deleted data, tampered indices) and you need access control now.

Prerequisites

Elasticsearch 7.x or 8.x, service up
root or rights to ES config
Official distro (X-Pack basic security included)
Node cert and password plan ready

How It Works

Elasticsearch defaults to 0.0.0.0:9200. Early versions (6.x and older) ship with no auth. Any client that can hit the port reads/writes via REST. Classic unauthorized-access bug. Attackers probe with `curl http://ip:9200/_cat/indices`, then `_search`, `_delete` to steal or wreck data. Hardening is three layers: firewall source-IP allow-list, TLS on the wire, X-Pack security for password auth and RBAC.

Procedure

Step 1: Kill public exposure, enable firewall

Confirm bind address. If 0.0.0.0, lock it down now:

# Check listen
netstat -tlnp | grep 9200

# iptables: internal subnet only
iptables -A INPUT -p tcp --dport 9200 -s 192.168.1.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 9200 -j DROP
iptables-save > /etc/sysconfig/iptables

Step 2: Enable X-Pack security

Edit `/etc/elasticsearch/elasticsearch.yml`:

network.host: 192.168.1.10
http.port: 9200
xpack.security.enabled: true
xpack.security.transport.ssl.enabled: true
xpack.security.transport.ssl.verification_mode: certificate
xpack.security.transport.ssl.keystore.path: /etc/elasticsearch/certs/elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: /etc/elasticsearch/certs/elastic-certificates.p12

Step 3: Issue node certs and set passwords

# Generate CA and node cert
/usr/share/elasticsearch/bin/elasticsearch-certutil cert   -out /etc/elasticsearch/certs/elastic-certificates.p12 -pass ""

# Restart, then set built-in user passwords
systemctl restart elasticsearch
/usr/share/elasticsearch/bin/elasticsearch-setup-passwords interactive

Step 4: Verify auth is on

# No creds -> 401
curl http://192.168.1.10:9200/
# With creds -> OK
curl -u elastic:password http://192.168.1.10:9200/_cluster/health

Verification

Checklist: unauthenticated requests all 401; valid user/pass reads and writes; inter-node traffic is TLS; 9200 open only to the internal subnet.

FAQ

Q1: Kibana cannot connect after enabling security?

Point Kibana at the ES URL, user, and password. Install matching-version certs. In `kibana.yml` set `elasticsearch.username` and `elasticsearch.password`. Trust the CA.

Q2: Forgot the elastic password?

Use `elasticsearch-reset-password`: `/usr/share/elasticsearch/bin/elasticsearch-reset-password -u elastic -i`. Needs local filesystem access.

Summary

Three layers: network source restriction, TLS in transit, app-layer auth + RBAC. After this, unauthorized access is largely gone. Meets baseline compliance and internal audit for data access control.