Logstash HTTP input listening on all interfaces without authentication

Hardening the Logstash HTTP Input

To guarantee that the Logstash HTTP input only accepts connections from trusted interfaces, you must explicitly define the host parameter. By default, the plugin binds to 0.0.0.0, which exposes the endpoint to all available network interfaces.

1. Restricting Interface Binding

To bind the plugin to a specific trusted address (such as a private management IP or localhost), modify the input block in your pipeline configuration:

input {
  http {
    port > 8080
    host > "10.0.1.5" # Replace with your trusted internal IP
  }
}

Note: If you are running Logstash in a container (Docker/Kubernetes), binding to 0.0.0.0 inside the container is often necessary for the orchestrator to route traffic. In these cases, restriction must be handled via Kubernetes NetworkPolicies or Cloud Security Groups rather than the Logstash config.

2. Enabling Authentication and TLS

Because HTTP Basic Auth transmits credentials in base64 (plain text), it should never be used without TLS. Use the Logstash keystore to avoid placing passwords in plain text files.

• Basic Auth: Add user > "username" and password > "${HTTP_PASS}".
• TLS: Set ssl > true and provide the ssl_certificate and ssl_key paths.

3. Verification Without Pipeline Alteration

You can verify the effective configuration and active security settings using these non-disruptive methods:

Configuration Validation

Run the configuration test flag to see how Logstash parses the input settings without fully starting the pipeline:

bin/logstash --config.test_and_exit -f /etc/logstash/conf.d/http-input.conf

Runtime Network Verification

Use the system's socket statistics tool to confirm the actual bind address on the host:

ss -ltnp | grep :8080

If the output shows 10.0.1.5:8080 instead of *:8080 or 0.0.0.0:8080, the restriction is active.

Likely Explanation and Assumptions

The vulnerability typically arises because the host parameter is omitted, leading Logstash to assume a "listen-all" posture. We assume the environment uses a standard Logstash installation (version 7.x or 8.x) where the HTTP input plugin is utilized. If the pipeline is behind a reverse proxy (like Nginx or HAProxy), the Logstash host should be set to 127.0.0.1, and the proxy should handle the TLS termination and IP filtering.

Diagnostic Detail Needed: Are you deploying Logstash as a standalone binary on a VM or within a containerized orchestrator? This determines whether the host setting or the infrastructure firewall is the primary point of control.