luxolus
/
open-consul
2
0
Fork 0
Code Issues 1 Pull Requests Packages Releases Wiki Activity

Update security notices around script checks

This commit is contained in:
Paul Banks 2018-11-27 17:15:01 +00:00
parent f728e413d1
commit 9a849faeb8
No known key found for this signature in database
GPG Key ID: C25A851A849B8221
3 changed files with 63 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
website/source/docs/agent/checks.html.md
View File

@ -36,6 +36,12 @@ There are several different kinds of checks:
* [`enable_script_checks`](/docs/agent/options.html#_enable_script_checks): enable
script checks regardless of how they are defined.
~> **Security Warning:** Enabling script checks in some configurations may
introduce a remote execution vulnerability which is known to be targeted by
malware. We strongly recommend `enable_local_script_checks` instead. See [this
blog post](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
for more details.
* HTTP + Interval - These checks make an HTTP `GET` request every Interval (e.g.
every 30 seconds) to the specified URL. The status of the service depends on
the HTTP response code: any `2xx` code is considered passing, a `429 Too Many

27
website/source/docs/agent/options.html.md
View File

@ -198,15 +198,21 @@ will exit with an error at startup.
in the "consul." domain. This flag can be used to change that domain. All queries in this domain
are assumed to be handled by Consul and will not be recursively resolved.
* <a name="_enable_script_checks"></a><a href="#_enable_script_checks">`-enable-script-checks`</a> This
controls whether [health checks that execute scripts](/docs/agent/checks.html) are enabled on
this agent, and defaults to `false` so operators must opt-in to allowing these. If enabled, it is recommended
to [enable ACLs](/docs/guides/acl.html) as well to control which users are allowed to register new checks to
execute scripts. This was added in Consul 0.9.0.
* <a name="_enable_script_checks"></a><a
href="#_enable_script_checks">`-enable-script-checks`</a> This controls
whether [health checks that execute scripts](/docs/agent/checks.html) are
enabled on this agent, and defaults to `false` so operators must opt-in to
allowing these. This was added in Consul 0.9.0.
~> **Security Warning:** Enabling script checks in some configurations may
introduce a remote execution vulnerability which is known to be targeted by
malware. We strongly recommend `-enable-local-script-checks` instead. See [this
blog post](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
for more details.
* <a name="_enable_local_script_checks"></a><a href="#_enable_local_script_checks">`-enable-local-script-checks`</a>
Like [`enable_script_checks`](#_enable_script_checks), but only enable them when they are defined in the local
config files. Script checks defined in HTTP API registratrions will still not be allowed.
configuration files. Script checks defined in HTTP API registrations will still not be allowed.
* <a name="_encrypt"></a><a href="#_encrypt">`-encrypt`</a> - Specifies the secret key to
use for encryption of Consul
@ -1036,6 +1042,15 @@ default will automatically work with some tooling.
* <a name="enable_script_checks"></a><a href="#enable_script_checks">`enable_script_checks`</a> Equivalent to the
[`-enable-script-checks` command-line flag](#_enable_script_checks).
~> **Security Warning:** Enabling script checks in some configurations may
introduce a remote execution vulnerability which is known to be targeted by
malware. We strongly recommend `enable_local_script_checks` instead. See [this
blog post](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations)
for more details.
* <a name="enable_local_script_checks"></a><a href="#enable_local_script_checks">`enable_local_script_checks`</a> Equivalent to the
[`-enable-local-script-checks` command-line flag](#_enable_local_script_checks).
* <a name="enable_syslog"></a><a href="#enable_syslog">`enable_syslog`</a> Equivalent to
the [`-syslog` command-line flag](#_syslog).

39
website/source/docs/internals/security.html.md
View File

@ -35,11 +35,44 @@ to learn about them without having to go spelunking through the source code.
## Secure Configuration
The Consul threat model is only applicable if Consul is running in a secure configuration. Consul does not operate in a secure-by-default configuration. If any of the settings below are not enabled, then parts of this threat model are going to be invalid. Additional security precautions must also be taken for items outside of Consul's threat model as noted in sections below.
The Consul threat model is only applicable if Consul is running in a secure
configuration. Consul does not operate in a secure-by-default configuration. If
any of the settings below are not enabled, then parts of this threat model are
going to be invalid. Additional security precautions must also be taken for
items outside of Consul's threat model as noted in sections below.
* **ACLs enabled with default deny.** Consul must be configured to use ACLs with a whitelist (default deny) approach. This forces all requests to have explicit anonymous access or provide an ACL token.
* **ACLs enabled with default deny.** Consul must be configured to use ACLs with
a whitelist (default deny) approach. This forces all requests to have explicit
anonymous access or provide an ACL token.
* **Encryption enabled.** TCP and UDP encryption must be enabled and configured to prevent plaintext communication between Consul agents. At a minimum, verify_outgoing should be enabled to verify server authenticity with each server having a unique TLS certificate. verify_incoming provides additional agent verification, but shouldn't directly affect the threat model since requests must also contain a valid ACL token.
* **Encryption enabled.** TCP and UDP encryption must be enabled and configured
to prevent plaintext communication between Consul agents. At a minimum,
verify_outgoing should be enabled to verify server authenticity with each
server having a unique TLS certificate. verify_incoming provides additional
agent verification, but shouldn't directly affect the threat model since
requests must also contain a valid ACL token.
### Known Insecure Configurations
In addition to configuring the non-default settings above, Consul has several
non-default options that potentially present additional security risks.
* **Script checks enabled with network-exposed API.** If a Consul agent (client
or server) exposes its HTTP API to the network beyond localhost,
[`enable_script_checks`](/docs/agent/options.html#_enable_script_checks) must
be `false` otherwise, even with ACLs configured, script checks present a
remote code execution threat.
[`enable_local_script_checks`](/docs/agent/options.html#_enable_local_script_checks)
provides a secure alterative if the HTTP API must be exposed and is available
from 1.3.0 on. This feature was also back-ported to patch releases 0.9.4,
1.1.1, and 1.2.4 [as described here](https://www.hashicorp.com/blog/protecting-consul-from-rce-risk-in-specific-configurations).
* **Remote exec enabled.** Consul includes a [`consul exec`
feature](/docs/commands/exec.html) allowing execution of arbitrary commands
across the cluster. This is disabled by default since 0.8.0. We recommend
leaving it disabled. If enabled, extreme care must be taken to ensure correct
ACLs restrict access, for example any management token grants access to
execute arbitrary code on the cluster.
## Threat Model