... | ... | @@ -42,8 +42,11 @@ Kea does not support SSL/TLS connection to databases. There is a community contr |
|
|
|
|
|
## Kea Logging
|
|
|
|
|
|
- what security sensitive information might be in the logs?
|
|
|
- where are logs stored, presumably access can be controlled via file permissions?
|
|
|
Kea can log a whole configuration with included passwords and secrets in it. This problem is being fixed by replacing the value of all entries finishing by `password` or `secret` with asterisks as it is already done for database logs.
|
|
|
|
|
|
Logs are sent to stdout, stderr, files or syslog. For the firsts the file permissions of the system apply. Syslog can export the logs over the network so is harder to secure.
|
|
|
|
|
|
In conclusion logs are currently security sensitive but the problem will be solved in a future release.
|
|
|
|
|
|
## Cryptography components
|
|
|
|
... | ... | @@ -51,6 +54,8 @@ Kea has support for two cryptographic libraries: Botan and OpenSSL. This is both |
|
|
|
|
|
The primary use case for the cryptographic libraries is generation of TSIG signatures and calculating DHCID records when sending DNS Updates. One way to limit OpenSSL or Botan exposure is to choose to not use DDNS. The libraries would still be necessary to build Kea, but the code would never be used, so any potential bugs in them would never had a chance to be exploited.
|
|
|
|
|
|
See also the TLS section for Kea version 1.9.6 and upper.
|
|
|
|
|
|
## TSIG signatures
|
|
|
|
|
|
Kea supports the following algorithms when signing DNS Updates with TSIG signature:
|
... | ... | @@ -94,7 +99,11 @@ Kea 1.9.2 introduced a new `auth` hook point. With this new hook point it is now |
|
|
|
|
|
[The Kea ARM](https://kea.readthedocs.io/en/kea-1.8.1/arm/agent.html#secure-connections) explains how to set up a reverse proxy to provide a TLS wrapper. This enables the administrator to apply whatever security policy they have for any other http server to Kea.
|
|
|
|
|
|
## TLS/HTTPS support
|
|
|
|
|
|
Since Kea 1.9.6 TLS/HTTPS is supported by Kea and the Control Agent can be configured to use TLS. This closes a security hole when using a reverse proxy to secure network access to the Control Agent using a tunnel: the protection is effective only inside the tunnel, not between ends and tunnel entries. For instance an attacker with a local access to the system where the Control Agent runs may inject directly bad commands to the Control Agent when basis HTTP authentication is not configured.
|
|
|
|
|
|
In a future version of Kea (scheduled for 1.9.7) the TLS/HTTPS support will be used by the High Availability hook library providing a complete protection when configured between Kea servers.
|
|
|
|
|
|
# 3. Managing Software Vulnerabilities
|
|
|
|
... | ... | @@ -135,11 +144,16 @@ Software releases are signed with PGP, and distributed via the ISC web site, whi |
|
|
|
|
|
- Does the Control Agent (CA) support TLS connections?
|
|
|
|
|
|
Not at this time. The CA exposes REST API over HTTP interface. The Kea ARM explains how to set up a reverse proxy, e.g. using apache or nginx to provide HTTPS transport for it. However, setting up a reverse proxy can be a burden when deploying a large number of DHCP servers. We are considering adding native TLS support to the CA.
|
|
|
Not before Kea 1.9.6. The CA exposes REST API over HTTP interface. The Kea ARM explains how to set up a reverse proxy, e.g. using apache or nginx to provide HTTPS transport for it. However, setting up a reverse proxy can be a burden when deploying a large number of DHCP servers.
|
|
|
Kea 1.9.6 added native TLS/HTTPS support to the CA.
|
|
|
|
|
|
- Does the High Availability (HA) hook library support TLS connections?
|
|
|
|
|
|
Adding native TLS/HTTPS support to the HA is scheduled for the incoming 1.9.7 release.
|
|
|
|
|
|
- Is there support for Role Based Access Control?
|
|
|
|
|
|
As of Kea 1.9.3, basic HTTP authentication is available. It can be used to authenticate users who send API commands. However, the access is basic right now - it's all or nothing. A more fine grained access control is needed. Extended access control is in development now.
|
|
|
As of Kea 1.9.3, basic HTTP authentication is available. It can be used to authenticate users who send API commands. However, the access is basic right now - it's all or nothing. A more fine grained access control is needed. Extended access control is in development now using identity based on the basic HTTP authentication or TLS credential (i.e. the client end-entity certificate).
|
|
|
|
|
|
- Is it possible to **block signals**?
|
|
|
|
... | ... | |