Securing the Elasticsearch, Logstash, and Kibana (ELK) Stack is a critical requirement for modern data observability within complex network infrastructures. In environments such as smart energy grids, industrial water management systems, or high-scale cloud platforms, the ELK Stack acts as the central nervous system for telemetry. Without rigorous security protocols, log data is vulnerable to injection attacks, unauthorized exfiltration, and tampering. The integrity of the log pipeline ensures that incident response teams are working with unmodified evidence during forensic audits. Ensuring ELK Stack Security requires a multi-layered approach centered on the encapsulation of data in transit, strict identity management, and the minimization of the attack surface. This manual addresses the transition from a default, insecure installation to a hardened, production-ready environment. By implementing Role-Based Access Control (RBAC) and mutual TLS (mTLS), administrators can eliminate the risk of unauthenticated actors intercepting sensitive payloads or manipulating the underlying indices through the REST API.
Technical Specifications
| Requirement | Default Port / Range | Protocol / Standard | Impact Level | Recommended Resources |
| :— | :— | :— | :— | :— |
| Elasticsearch REST API | 9200 | HTTPS (TLS 1.2/1.3) | 10 | 16GB-64GB RAM; 8+ vCPU |
| Node Transport Layer | 9300-9400 | Proprietary TLS | 9 | 10Gbps Network Latency <2ms |
| Kibana Web Interface | 5601 | HTTPS / Browser | 8 | 4GB RAM; 2 vCPU |
| Logstash Beats Input | 5044 | TCP / mTLS | 7 | 8GB RAM; High Throughput |
| Cluster Health Check | ICMP / Monitoring | RFC 792 | 5 | Minimal Overhead |
The Configuration Protocol
Environment Prerequisites:
Successful hardening requires Elasticsearch version 8.x or higher, as security features are integrated by default in these versions. The underlying operating system must be a hardened Linux distribution such as RHEL 9 or Ubuntu 22.04 LTS. Users must possess sudo or root privileges to modify kernel parameters and service configurations. All nodes in the cluster must have synchronized clocks via NTP to prevent certificate validation failures caused by time drift. Ensure that openssl and the Java KeyTool are installed and available in the system PATH.
Section A: Implementation Logic:
The engineering design follows the principle of Least Privilege and Defense in Depth. We begin by securing the transport layer, which is the internal communication between Elasticsearch nodes. This prevents “man-in-the-middle” attacks within the private network. We then move to the HTTP layer to secure client-to-cluster traffic. By utilizing a private Certificate Authority (CA), we create a trusted identity circle for all components. The logic dictates that every request, whether from a Logstash pipeline or a Kibana dashboard, must be cryptographically verified and mapped to a specific user role. This prevents unauthorized lateral movement within the stack if one component, such as an edge-facing Logstash instance, is compromised.
Step-By-Step Execution
1. Generating the Certificate Authority
Navigate to the Elasticsearch installation directory and execute the bin/elasticsearch-certutil ca command. This utility generates a new Certificate Authority (CA) in a PKCS#12 format. When prompted, choose a strong password and store the resulting elastic-stack-ca.p12 file in a secure vault.
System Note: This action creates a self-signed root certificate that the cluster will use to sign individual node certificates. The chmod 600 command should be applied to this file to prevent non-privileged users from reading the private key.
2. Issuing Node Certificates
Run bin/elasticsearch-certutil cert –ca elastic-stack-ca.p12 to generate certificates for every node in the cluster. You should provide the DNS names or IP addresses for each instance to ensure the certificates are valid for the specific hosts where they reside.
System Note: This command interacts with the java-keystore to wrap the certificates. It ensures that node-to-node transport is encrypted, which mitigates the risk of packet-sniffing on the internal backplane of the network.
3. Configuring Elasticsearch Kernel Parameters
Modify the sysctl.conf file to include vm.max_map_count=262144. Apply the changes using sysctl -p. Additionally, update /etc/security/limits.conf to set memlock to unlimited.
System Note: Elasticsearch uses mmap to store its indices. Insufficient virtual memory maps can lead to out-of-memory (OOM) errors and service instability. The memlock setting prevents the kernel from swapping the Elasticsearch process memory to disk, which would introduce severe latency and thermal-inertia in storage response times.
4. Enabling Security in elasticsearch.yml
Open /etc/elasticsearch/elasticsearch.yml and set xpack.security.enabled to true. Point the node to the generated certificates by defining xpack.security.transport.ssl.keystore.path and xpack.security.http.ssl.truststore.path.
System Note: This configuration restarts the internal security engine. Once the service is reloaded via systemctl restart elasticsearch, the REST API will no longer accept unencrypted or unauthenticated requests. It effectively locks the front door of the database.
5. Hardening Kibana with HTTPS
In the kibana.yml file, set server.ssl.enabled to true and provide the paths to the server.crt and server.key. Use the bin/kibana-keystore to store the elasticsearch.password securely instead of writing it in plain text.
System Note: Enabling SSL on Kibana protects the credentials of administrative users as they traverse the network from their workstations to the dashboard. The systemctl manager tracks the Kibana process to ensure the PID remains stable after certificate rotation.
6. Securing Logstash with Mutual TLS
Configure the Logstash input plugin for Beats by setting ssl => true and ssl_verify_mode => “peer”. You must provide the ssl_certificate_authorities path to ensure Logstash only accepts data from authorized Filebeat or Metricbeat agents.
System Note: This creates a strict tunnel where both the server and the client must prove their identity. It prevents rogue data injection, ensuring that the payload remains untainted from the source to the indexing engine.
Section B: Dependency Fault-Lines:
A frequent point of failure is certificate mismatch during mTLS handshakes. If the Common Name (CN) or Subject Alternative Name (SAN) in the certificate does not match the actual hostname used in the configuration files, the connection will be dropped with a “SSLHandshakeException”. Another bottleneck occurs when the ulimit for open file descriptors is set too low. Elasticsearch handles thousands of concurrent socket connections; if the OS limit is the default 1024, the service will refuse new connections, leading to massive packet-loss from incoming log streams.
THE TROUBLESHOOTING MATRIX
Section C: Logs & Debugging:
When a service fails to start after hardening, the first point of audit is the journalctl -u elasticsearch -f output. Look for the string “AccessControlException” which indicates a permissions conflict on the certificate files. If the error “handshake_failure” appears in the Logstash logs located at /var/log/logstash/logstash-plain.log, verify that the ciphersuites configured in the JVM are compatible between the client and the server.
If the cluster state remains “Red”, use the curl -XGET -u elastic “https://localhost:9200/_cluster/health?pretty” command. If this returns a 401 Unauthorized status despite correct credentials, check if the native realm is enabled in the configuration. Visual cues from the Kibana “Stack Monitoring” tab can highlight nodes with high signal-attenuation in their heartbeat signals, often caused by a firewall blocking port 9300. Use tcpdump -i any port 9300 to verify that encrypted packets are moving between nodes.
OPTIMIZATION & HARDENING
Performance Tuning
To maintain high throughput under a heavy security load, adjust the JVM heap size in jvm.options to exactly 50 percent of available physical RAM. This prevents the garbage collector from causing latency spikes during intense indexing bursts. Ensure that concurrency is optimized by setting the number of shards relative to the number of CPU cores; a common ratio is one shard per 20GB of data per node.
Security Hardening
Implement a host-based firewall using iptables or firewalld to restrict port 9200 access only to the Logstash and Kibana IP addresses. Disable all unused plugins to reduce the attack surface. Ensure that the ELASTIC_PASSWORD is rotated every 90 days and that audit logging is enabled in elasticsearch.yml to track every query executed against sensitive indices.
Scaling Logic
As traffic increases, horizontal scaling is preferred over vertical scaling. Add “Data-Only” nodes to the cluster to distribute the indexing payload. Ensure that the new nodes inherit the same CA-signed certificates to join the cluster seamlessly. Use a load balancer in front of the Logstash fleet to distribute incoming Beats traffic, terminating SSL at the balancer to reduce the overhead on individual Logstash instances.
THE ADMIN DESK
How do I reset the elastic user password?
Run the utility bin/elasticsearch-reset-password -u elastic from the terminal. This command will generate a new random password and update the native realm immediately. Ensure the cluster is running before executing this command.
Why is Kibana unable to connect to Elasticsearch?
Check the elasticsearch.hosts setting in kibana.yml. If security is enabled, the protocol must be https. Verify that the Kibana service account has the kibana_system role assigned via the Elasticsearch RBAC API.
How do I check certificate expiration dates?
Execute openssl x509 -in /path/to/certificate.crt -text -noout. Look for the Not After field. It is vital to renew certificates before this date to prevent a total cluster communication blackout.
What is the impact of enabling ‘mlockall’?
Enabling bootstrap.memory_lock: true ensures that the Elasticsearch process memory is never swapped to disk. This maintains low latency for search queries and prevents performance degradation during high concurrency periods.
Can I use certificates from a public CA?
Yes; however, for internal node-to-node transport, a private CA is often more efficient. For the Kibana web interface, a public CA certificate is recommended to avoid browser trust warnings for end-users accessing the dashboard.
