Easy Read Time: 4 Minutes
Table of Content +
- 1 Elasticsearch Security Best Practices
- 1.1 Hardware Considerations
- 1.2 Operating System
- 1.3 Application
- 1.4 Services/Ports
- 1.5 Logs
- 1.6 Permissions
- 1.7 Monitoring
- 1.8 Third-Party Security
- 1.9 Vulnerabilities
Elasticsearch Security Best Practices
Elasticsearch is a powerful search and analytics engine that is a part of most of the businesses today, providing an easy way to search and analyze all types of data. However, since Elasticsearch is easy to deploy, people often forget to harden its security to protect and ensure authorized access to the data. Below are some of the security best practices you should follow to harden the security of Elasticsearch so that your sensitive information remains protected against cyber attacks.
Protecting Elasticsearch begins with securing your hardware in the first place to prevent malicious attacks that would otherwise happen directly on compromised hardware. This process begins with considering the physical server security first. Make sure that your system is in a secure environment and is accessible by authorized personnel only.
System & Communications Protection and Information Integrity
Boundary protection firewalls
Use a managed interface like firewalls to deploy a demilitarized zone or DMZ to monitor and limit the communications between the internet-facing systems and your private network. Never expose your Elasticsearch cluster to the public web. Always set network.bind_host to a private network IP and never a public IP or DNS. Read the documentation to know more about how to change this in network settings.
Encryption in transit and at rest
Without enabling encryption, your Elastcisearch clusters send all data in plain text, which can even include the passwords, making it vulnerable to network-based attacks. It is vital to encrypt traffic to, from, and within the Elasticsearch cluster to secure data in transit and at rest, and prevent attackers from sending and receiving data through a compromised node. This is possible by securing connections through Transport Layer Security (TLS/SSL). For details on configuring SSL/TLS for internode-communication, follow the steps mentioned in the official documentation.
You can even run your Elasticsearch instance in a FIPS 140-2 compliant mode, which adheres to FIPS-approved/NIST-recommended cryptographic algorithms. To enable FIPS mode, set the xpack.security.fips_mode.enabled to true in elasticsearch.yml. Refer to the documentation for more information on configuring Elasticsearch for FIPS 140-2.
Develop a robust patch management strategy to identify, acquire, install, and monitor security patches for all network devices, operating systems, Elasticsearch cluster, and other in-scope systems.
The next step involves hardening your OS you’ll be using to install Elasticsearch. Follow the security guide specific to your OS and Elasticsearch version to ensure better protection against cyber attacks.
Use the below security guides depending on your OS:
Use a VPN or private network when accessing Elasticsearch from another machine. Also, try and keep your Elasticsearch cluster on an isolated network to separate it from other parts of your system. For example, set up a cluster in a VPC and then define two separate security groups: one for the entire cluster and another for client nodes.
Disable the HTTP layer on nodes not meant to serve REST requests directly. You can do this by setting http.enabled to false.
Disable scripting for pre 5.x clusters and also upgrade your cluster to the latest version immediately if you are using 1.x or 0.x version. This step is necessary because many pre 2.x versions are vulnerable to attacks due to dynamic scripting enabled. If you are using Elasticsearch 2.x, change your scripting language to expression.
One of the ways to enhance the security of your Elasticsearch cluster is to avoid using the default communication node. The engine uses 9200 port by default, and you can change this in network settings. Refer to the documentation to change the default port.
It is also essential that you closely monitor and watch the logs of your Elasticsearch cluster for any suspicious activity. Logging also provides forensic evidence in the event of an attack.
Audit & Accounting
To log security events, you’ll first need to enable audit logging, since audit logs are disabled by default. To enable audit logging, set xpack.security.audit.enabled to true in elasticsearch.yml. Use Auditing Settings to control what events to log and what information to include in the logs. There are a number of security events you can generate. Find the complete list here.
To further harden the security, consider shipping the logs off-site to a third-party log management service since attackers will not be able to track the logs once they’re off the site.
Take advantage of the user authorization features to secure your Elasticsearch cluster. Use Role-based Access Control (RBAC) and Attribute-based Access Control to ensure that the user behind the incoming request has the authority to access and execute the request.
Use RBAC to authorize users by assigning privileges to roles and assigning roles to users or groups. The authorization process consists of the following elements:
- Secured Resource: A resource can be aliases, indices, documents, fields, users, and even Elasticsearch cluster itself.
- Privilege: A privilege is a group of one or more actions that a user can execute against a secured resource. Check out the complete list of privileges here.
- Permissions: It is a set of one or more privileges against a secured resource.
- Role: It is a set of permissions.
- User: A user is an authenticated individual to whom a role can be assigned.
- Group: One or more groups to which a user belongs.
For fine-grain control, you can even use the ABAC mechanism to restrict users to access specific documents and fields based on assigned attributes. Read the documentation for more details on Attribute-based Access Control.
Identification & Authentication
Set up user authentication so that individuals have to prove their identity before accessing the restricted resources. You can either use Elasticsearch’s native support for authenticating users or through external user management systems like LDAP, Active Directory, Kerberos, PKI, and SAML.
Find out how to configure these authentication systems with your Elasticsearch security features here.
Configure your Elasticsearch cluster to collect monitoring data such as search performance, index performance, memory usage, garbage collection, and more to identify the overall health of your cluster and take necessary action. Find out the key Elasticsearch metrics you should monitor in the documentation.
There are third-party integrations available which you can use to enhance the security of your Elasticsearch cluster.
- HTTP Authentication plugin: This plugin provides basic HTTP user authentication and IP ACL for Elasticsearch.
- Search Guard: It is a security plugin that includes features such as encryption, authentication, authorization, RBAC, audit logging, and multi-tenancy for the entire Elastic Stack.
- Readonly REST: This is another security plugin that comes with encryption, authentication, and authorization features for Elasticsearch native REST API.
- CVE-2020-7009: Elasticsearch versions from 6.7.0 to 6.8.7 and 7.0.0 to 7.6.1 contain a privilege escalation flaw if an attacker can create API keys. An attacker who can generate an API key can perform a series of steps that result in an API key being generated with elevated privileges.
- CVE-2019-7619: A username disclosure flaw was found in Elasticsearch’s API Key service. An unauthenticated attacker could send a specially crafted request and determine if a username exists in the Elasticsearch native realm.
- CVE-2019-7614: A race condition flaw was found in the response headers Elasticsearch returns to a request. On a system with multiple users submitting requests, it could be possible for an attacker to gain access to a response header containing sensitive data from another user.
Check out the complete list of known vulnerabilities here.