Using IP Filteringedit
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 filteringedit
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 Filteringedit
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 profilesedit
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 Filteringedit
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.