search

elastic / kibana

Your window into the Elastic Stack
https://www.elastic.co/products/kibana
Other
19.7k stars 8.12k forks source link

Limit outgoing TCP sockets to certain hosts #58466

Open watson opened 4 years ago

watson commented 4 years ago

To help prevent data from being sent from Kibana to an untrusted 3rd party, we need a feature that can limit to which hosts/ports outgoing TCP sockets can be established.

I would consider this a breaking change, so we should leave it off in 7.x by default, but have a config option that allowed users to turn it on and to set which hosts/ports were allowed.

In 8.x we could then turn this on by default to say not allow anything except the configured ES cluster + maybe localhost.

elasticmachine commented 4 years ago

Pinging @elastic/kibana-security (Team:Security)

kobelb commented 4 years ago

I'm potentially restating the obvious, but it'd be great if we could also specify certain hosts to deny all traffic.

watson commented 4 years ago

@kobelb so instead of a whitelist, then a blacklist? If I understand you correctly, what would the use-case be for that?

kobelb commented 4 years ago

Conceptually, we're building an in-application firewall and being able to deny traffic to certain ip addresses is a common feature of a firewall. Occasionally various Cloud providers will have sensitive services accessible on internal IP addresses which would be nice to block traffic to.

jportner commented 4 years ago

To play devil's advocate: do we have a good reason to essentially re-invent a host-based firewall inside of Kibana?

legrego commented 4 years ago

To play devil's advocate: do we have a good reason to essentially re-invent a host-based firewall inside of Kibana?

I was going to ask the same thing. Is this essentially a defense-in-depth argument? Otherwise I think we could just defer to a host-based firewall (perhaps configuring our shipped docker image with one), and publish guidelines on which hosts a vanilla install would require.

kobelb commented 4 years ago

Deferring entirely to a host-based firewall assumes that Kibana is the only thing that is running on the host.

For example, what if a customer was using Filebeat to ship logs to a separate Elasticsearch cluster. Kibana itself shouldn't necessarily be able to access the Filebeat logs cluster, but we still need Filebeat to be able to.

legrego commented 4 years ago

Deferring entirely to a host-based firewall assumes that Kibana is the only thing that is running on the host.

I don't think that's necessarily true. iptables, for example, has an "owner match" extension to enable per-process rules. I believe Windows has similar options, but I haven't tried this in a while.

Although we shouldn't ignore the additional administration efforts to get these host-based systems working and kept in sync with Kibana...if we want to be "Simple and Secure" out of the box, then having Kibana limit its own connections could be beneficial

kobelb commented 4 years ago

I don't think that's necessarily true. iptables, for example, has an "owner match" extension to enable per-process rules. I believe Windows has similar options, but I haven't tried this in a while.

Very interesting, I honestly wasn't aware of this.

The original inspiration for the creation of this issue was to find a way to move away from the purpose-specific whitelists which we currently support in the kibana.yml to prevent SSRF. For example, the timelion.graphiteUrls setting.

While I don't want to be reinventing something that already exists, telling end-users that they have to configure a per-process based firewall seems problematic with our desire to be secure by default.

jportner commented 4 years ago

Although we shouldn't ignore the additional administration efforts to get these host-based systems working and kept in sync with Kibana...if we want to be "Simple and Secure" out of the box, then having Kibana limit its own connections could be beneficial

Perhaps a good middle-ground would be to simply add a feature that enforces the minimal whitelist Thomas stated (localhost and ES cluster), enabled by default, and only allow this to be toggled off.

I.e., maybe we don't need to support detailed configuration of whitelist and/or blacklist when a host-based firewall would be a more appropriate tool for that use case. If the default stated above would be sufficient for a majority of our users.

kobelb commented 4 years ago

Perhaps a good middle-ground would be to simply add a feature that enforces the minimal whitelist Thomas stated (localhost and ES cluster), enabled by default, and only allow this to be toggled off.

A whitelist will potentially be a sufficient middle-ground, but I don't think it can be as simple as only allowing communication to localhost and the ES cluster. Kibana's increasingly being integrated with external services, for example Enterprise Search, and we don't want to make these super complicated for users to configure.

azasypkin commented 4 years ago

Just for my understanding: am I wrong in thinking that implementing such in-app-firewall would allow to prevent mostly unintentional violations (e.g. when new legitimate plugin adds interaction with the external host that may or may not be influenced by the user without proper security review) unless we fully control child_process (e.g. if malicious code intentionally spawns something else that can talk to the blacklisted hosts) and process.kill (e.g. if combination of ability to send SIGHUP with a file-write access can force another/same process to bypass Kibana own blacklist)?

We also may need to implement this in a way that would cover CLI tools we ship with Kibana as well (cli_plugin and friends).

P.S.: having a Kibana DevOps/IT team best practices checklist would be great to have in any case though :slightly_smiling_face: