Using 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.

Enabling IP filtering

edit

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

You configure IP filtering by specifying the shield.transport.filter.allow and shield.transport.filter.deny settings in in elasticsearch.yml. Allow rules take prececence over the deny rules.

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

Specifying 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.

HTTP Filtering

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
    }
}'

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 Configuring Clients and Integrations »