From version 5.0 onward, Shield is part of X-Pack. For more information, see Securing the Elastic Stack.

« Separating node to node and client traffic Auditing »

› ›

IP filtering

You can apply IP filtering to application clients, node clients, or transport clients, in addition to other nodes that are attempting to join the cluster.

If a node’s IP address is on the blacklist, Shield will still allow the connection to Elasticsearch. The connection will be dropped immediately, and no requests will be processed.

Elasticsearch installations are not designed to be publicly accessible over the Internet. IP Filtering and the other security capabilities of Shield do not change this condition.

Node filtering

edit

Shield features an access control feature that allows or rejects hosts, domains, or subnets.

Configuration setting

edit

IP filtering configuration is part of the elasticsearch.yml file

Configuration Syntax

edit

The configuration file for IP filtering consists of a list of one allow and deny statement each, possibly containing an array. Also, the allow rule is prioritized over the deny rule.

Example 1. Allow/Deny Statement Priority.

shield.transport.filter.allow: "192.168.0.1"
shield.transport.filter.deny: "192.168.0.0/24"

The _all keyword denies all connections that are not explicitly allowed earlier in the file.

Example 2. _all Keyword Usage.

shield.transport.filter.allow: [ "192.168.0.1", "192.168.0.2", "192.168.0.3", "192.168.0.4" ]
shield.transport.filter.deny: _all

IP Filtering configuration files support IPv6 addresses.

Example 3. IPv6 Filtering.

shield.transport.filter.allow: "2001:0db8:1234::/48"
shield.transport.filter.deny: "1234:0db8:85a3:0000:0000:8a2e:0370:7334"

Shield supports hostname filtering when DNS lookups are available.

Example 4. Hostname Filtering.

shield.transport.filter.allow: localhost
shield.transport.filter.deny: '*.google.com'

Disabling IP Filtering

edit

Disabling IP filtering can slightly improve performance under some conditions. To disable IP filtering entirely, set the value of the shield.transport.filter.enabled attribute in the elasticsearch.yml configuration file to false.

Example 5. Disabled IP Filtering.

shield.transport.filter.enabled: false

You can also disable IP filtering for the transport protocol but enable it for HTTP only like this

Example 6. Enable HTTP based IP Filtering.

shield.transport.filter.enabled: false
shield.http.filter.enabled: true

Support for TCP transport profiles

edit

In order to support bindings on multiple host, you can specify the profile name as a prefix in order to allow/deny based on profiles

Example 7. Profile based filtering.

shield.transport.filter.allow: 172.16.0.0/24
shield.transport.filter.deny: _all
transport.profiles.client.shield.filter.allow: 192.168.0.0/24
transport.profiles.client.shield.filter.deny: _all

Note: When you do not specify a profile, default is used automatically.

Support for HTTP

edit

You may want to have different filtering between the transport and HTTP protocol

Example 8. HTTP only filtering.

shield.transport.filter.allow: localhost
shield.transport.filter.deny: '*.google.com'
shield.http.filter.allow: 172.16.0.0/16
shield.http.filter.deny: _all

Dynamically updating ip filter settings [1.1.0] Added in 1.1.0.

edit

In case of running in an environment with highly dynamic IP addresses like cloud based hosting it is very hard to know the IP addresses upfront when provisioning a machine. Instead of changing the configuration file and restarting the node, you can use the Cluster Update Settings API like this

curl -XPUT localhost:9200/_cluster/settings -d '{
    "persistent" : {
        "shield.transport.filter.allow" : "172.16.0.0/24"
    }
}'

You can also disable filtering completely setting shield.transport.filter.enabled like this

curl -XPUT localhost:9200/_cluster/settings -d '{
    "persistent" : {
        "shield.transport.filter.enabled" : false
    }
}'

Note: In order to not lock yourself out, the default bound transport address will never be denied. This means you can always SSH into a system and use curl to apply changes.

« Separating node to node and client traffic Auditing »