Easysearch Audit Log Walkthrough: Who’s Accessing Your Cluster?

Background: Why monitor external IPs

Many teams deploying Easysearch (a Chinese Elasticsearch distribution) focus only on cluster health and overlook a critical security question: who is accessing the cluster and whether any unauthorized external IPs have connected.

Security risk : If the cluster exposes port 9200 to the public, even with a password, regular checks are needed to prevent brute‑force attacks or unknown access.

What is the Audit Log?

In Easysearch the audit log is controlled by the security.audit.type setting. The default value noop means no logging. The available options are: noop: no audit records (default, not recommended for production) internal: write audit events to an internal Easysearch index (recommended for production) log4j: write to a Log4j file (useful for log aggregation) webhook: send events to a webhook endpoint (for alert integration) debug: debug mode (intended for development only)

Step 1 – Enable the audit log

Edit the main configuration file easysearch.yml and change the audit type from noop to internal:

# security feature switch
security.enabled: true

# ✅ Change this line: replace noop with internal
security.audit.type: internal

# SSL transport certificates
security.ssl.transport.cert_file: instance.crt
security.ssl.transport.key_file: instance.key
security.ssl.transport.ca_file: ca.crt
security.ssl.transport.skip_domain_verify: true

# HTTPS (REST layer)
security.ssl.http.enabled: true
security.ssl.http.cert_file: instance.crt
security.ssl.http.key_file: instance.key
security.ssl.http.ca_file: ca.crt

Note : security.audit.type is a static configuration; after editing you must restart the Easysearch service. Perform the restart during a maintenance window to avoid impact on production traffic.

After the change, restart the service (e.g., ./bin/easysearch or the appropriate startup command).

Step 2 – Verify audit configuration in the UI

Open the Easysearch management console, navigate to Security → Audit Log , and click the “Audit Config” button. The panel shows the current audit settings. The default enabled items are:

Enable Audit : on

Read Metadata Only : on

Write Metadata Only : on

Internal Config : on

Items such as External Config and Write Log Diffs are off by default and usually do not need to be enabled.

Step 3 – View audit records

After the service restarts, go to the Audit Log main page. The list shows entries such as “Found 14 records”, confirming that auditing is active.

Key event types you may see: FAILED_LOGIN: a login attempt failed; the Remote Address column displays the attacking IP (e.g., 130.51.96.XX). SSL_EXCEPTION: many SSL handshake failures; the Remote Address column is empty because the handshake never completed. Operator column may show “-” or “<NONE>” when the request was unauthenticated.

Step 4 – Drill into Detail to locate the external IP

For records where the IP is not shown directly (e.g., successful authenticated actions), click the Detail button to open the detail panel.

Example record COMPLIANCE_INTERNAL_CONFIG_READ shows the following fields:

Base Info
─────────────────────────────────────
Event Time:      2026-03-24 16:17:19
Operator:        admin
Event IP:        130.51.96.xx   ← external IP!
Resource Type:   COMPLIANCE_INTERNAL_CONFIG_READ
Origin:          REST
Cluster:         my-application
Node:            node-1

Request Details
─────────────────────────────────────
Node Host Address:   10.0.8.2   ← node internal IP
Resolved Indices:    .security
Request Body:        {"field_names":["audit"]}

Key fields : Event IP : the client IP that initiated the request – the external IP you are looking for. Node Host Address : the internal IP of the node that handled the request. Operator : the authenticated user (e.g., admin ). Resource Type : the type of operation, such as COMPLIANCE_INTERNAL_CONFIG_READ .

Understanding SSL_EXCEPTION

When a client tries to establish an HTTPS connection and the handshake fails (e.g., untrusted certificate, unsupported cipher suite, or plain HTTP to an HTTPS port), the server logs an SSL_EXCEPTION. Because the handshake never completes, the Remote Address field is empty.

Typical sources of these records are:

Internet port scanners (masscan, Shodan, etc.)

Mis‑configured clients that use HTTP on an HTTPS port

Clients that do not trust the CA certificate (e.g., curl -k)

Summary

The complete workflow consists of four steps:

Modify easysearch.yml to set security.audit.type: internal and restart the service.

In the Easysearch UI, enable “Enable Audit” and “Internal Config”.

In the Audit Log list, locate events such as FAILED_LOGIN to see external IPs in the Remote Address column.

Click the Detail button for a record to view the Event IP field, which precisely identifies the external client IP.

Key take‑aways:

Set security.audit.type: internal for production‑grade audit logging.

External IPs appear in the Remote Address column of the list or the Event IP field of the detail view. FAILED_LOGIN indicates brute‑force attempts; the IP is shown directly. SSL_EXCEPTION indicates handshake failures; the IP is usually empty because the connection never completed.

Even legitimate admin actions (e.g., viewing audit config) are recorded, providing a complete audit trail.