elasticsearch/docs/reference/security/using-ip-filtering.asciidoc

[role="xpack"]
[[ip-filtering]]
== Restricting connections with IP filtering

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

If a node's IP address is on the denylist, the {es} {security-features} allow
the connection to {es} but it is be dropped immediately and no requests are
processed.

NOTE: Elasticsearch installations are not designed to be publicly accessible
      over the Internet. IP Filtering and the other capabilities of the
      {es} {security-features} do not change this condition.

[discrete]
=== Enabling IP filtering

The {es} {security-features} contain an access control feature that allows or
rejects hosts, domains, or subnets. If the
<<operator-privileges,{operator-feature}>> is enabled, only operator users can
update these settings.

You configure IP filtering by specifying the `xpack.security.transport.filter.allow` and
`xpack.security.transport.filter.deny` settings in `elasticsearch.yml`. Allow rules
take precedence over the deny rules.

IMPORTANT: Unless explicitly specified, `xpack.security.http.filter.*` and
`xpack.security.remote_cluster.filter.*` settings default to
the corresponding `xpack.security.transport.filter.*` setting's value.

[source,yaml]
--------------------------------------------------
xpack.security.transport.filter.allow: "192.168.0.1"
xpack.security.transport.filter.deny: "192.168.0.0/24"
--------------------------------------------------

The `_all` keyword can be used to deny all connections that are not explicitly
allowed.

[source,yaml]
--------------------------------------------------
xpack.security.transport.filter.allow: [ "192.168.0.1", "192.168.0.2", "192.168.0.3", "192.168.0.4" ]
xpack.security.transport.filter.deny: _all
--------------------------------------------------

IP filtering configuration also support IPv6 addresses.

[source,yaml]
--------------------------------------------------
xpack.security.transport.filter.allow: "2001:0db8:1234::/48"
xpack.security.transport.filter.deny: "1234:0db8:85a3:0000:0000:8a2e:0370:7334"
--------------------------------------------------

You can also filter by hostnames when DNS lookups are available.

[source,yaml]
--------------------------------------------------
xpack.security.transport.filter.allow: localhost
xpack.security.transport.filter.deny: '*.google.com'
--------------------------------------------------

[discrete]
=== Disabling IP Filtering

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

[source,yaml]
--------------------------------------------------
xpack.security.transport.filter.enabled: false
--------------------------------------------------

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

[source,yaml]
--------------------------------------------------
xpack.security.transport.filter.enabled: false
xpack.security.http.filter.enabled: true
--------------------------------------------------

[discrete]
=== Specifying TCP transport profiles

<<transport-profiles,TCP transport profiles>>
enable Elasticsearch to bind on multiple hosts. The {es} {security-features} enable you to apply
different IP filtering on different profiles.

[source,yaml]
--------------------------------------------------
xpack.security.transport.filter.allow: 172.16.0.0/24
xpack.security.transport.filter.deny: _all
transport.profiles.client.xpack.security.filter.allow: 192.168.0.0/24
transport.profiles.client.xpack.security.filter.deny: _all
--------------------------------------------------

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

[discrete]
=== HTTP filtering

You may want to have different IP filtering for the transport and HTTP protocols.

[source,yaml]
--------------------------------------------------
xpack.security.transport.filter.allow: localhost
xpack.security.transport.filter.deny: '*.google.com'
xpack.security.http.filter.allow: 172.16.0.0/16
xpack.security.http.filter.deny: _all
--------------------------------------------------

[discrete]
=== Remote cluster (API key based model) filtering

If other clusters connect <<remote-clusters-api-key,using API key
authentication>> for {ccs} or {ccr}, you may want to have different IP filtering
for the remote cluster server interface.

[source,yaml]
--------------------------------------------------
xpack.security.remote_cluster.filter.allow: 192.168.1.0/8
xpack.security.remote_cluster.filter.deny: 192.168.0.0/16
xpack.security.transport.filter.allow: localhost
xpack.security.transport.filter.deny: '*.google.com'
xpack.security.http.filter.allow: 172.16.0.0/16
xpack.security.http.filter.deny: _all
--------------------------------------------------

NOTE: Whether IP filtering for remote cluster is enabled is controlled by
`xpack.security.transport.filter.enabled` as well. This means filtering for
the remote cluster and transport interfaces must be enabled or disabled together.
But the exact allow and deny lists can be different between them.

[discrete]
[[dynamic-ip-filtering]]
=== Dynamically updating IP filter settings

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_. For example:

[source,console]
--------------------------------------------------
PUT /_cluster/settings
{
  "persistent" : {
    "xpack.security.transport.filter.allow" : "172.16.0.0/24"
  }
}
--------------------------------------------------

You can also dynamically disable filtering completely:

[source,console]
--------------------------------------------------
PUT /_cluster/settings
{
  "persistent" : {
    "xpack.security.transport.filter.enabled" : false
  }
}
--------------------------------------------------
// TEST[continued]

NOTE: In order to avoid locking yourself out of the cluster, the default bound
      transport address will never be denied. This means you can always SSH into
      a system and use curl to apply changes.