|
|
This page discusses various aspects related to Kea software security. This is a living document. This page will eventually be merged into [Kea ARM](https://kea.readthedocs.io).
|
|
|
This page discusses various aspects related to Kea software security. This is a living document. This page will eventually be merged into [Kea ARM](https://kea.readthedocs.io).
|
|
|
|
|
|
>> Vicky: I think it would be more appropriate for the ARM to address this from the perspective of, 'how can you improve the security of your Kea deployment' and provide more of a 'how to' approach.
|
|
|
|
|
|
The sections below are not listed in any particular order.
|
|
|
The sections below are not listed in any particular order.
|
|
|
|
|
|
[[_TOC_]]
|
|
|
|
... | ... | @@ -14,11 +14,11 @@ Kea was designed to be installed into a protected environment in a core network |
|
|
|
|
|
## Component-based design
|
|
|
|
|
|
The Kea architecture is modular, with separate daemons for separate tasks. A typical Kea deployment will consist of: DHCPv4, DHCPv6, and Dynamic DNS daemons, a control agent daemon run on each application server, the `kea-lfc` utility for doing periodic lease file cleanup, and MySQL and or PostgreSQL databases, run either locally on the application servers or accessed over the internal network.
|
|
|
The Kea architecture is modular, with separate daemons for separate tasks. A typical Kea deployment will consist of: DHCPv4, DHCPv6, and Dynamic DNS daemons, a control agent daemon run on each application server, the `kea-lfc` utility for doing periodic lease file cleanup, and MySQL and or PostgreSQL databases, run either locally on the application servers or accessed over the internal network.
|
|
|
|
|
|
This modular architecture minimizes the attack surface by minimizing the code that is loaded and running. For example, `kea-dhcp-ddns` should not be run unless DNS updates are required. Similarly, `kea-lfc` will never be triggered (and can be safely removed or never installed) if memfile is not used.
|
|
|
|
|
|
That is in contrast to ISC DHCP's server `dhcpd`, which is a single binary that does everything.
|
|
|
That is in contrast to ISC DHCP's server `dhcpd`, which is a single binary that does everything.
|
|
|
|
|
|
## Application permissions
|
|
|
|
... | ... | @@ -26,19 +26,19 @@ Kea uses the DHCPv4 and DHCPv6 protocols, which assume the server will open priv |
|
|
|
|
|
## Kea Administrative access
|
|
|
|
|
|
The three primary Kea deamons (`kea-dhcp4`, `kea-dhcp6` and `kea-dhcp-ddns`) all support a control channel, which is implemented as UNIX socket. The control channel is disabled by default, but most configuration examples have it enabled as it's a very popular feature. It opens a UNIX socket. To read from or write to this socket, generally root access is required, although if Kea is configured to run as non-root, the owner of the process can write to it. Access can be controlled using normal file access control on POSIX systems (owner, group, others, read/write).
|
|
|
The three primary Kea daemons (`kea-dhcp4`, `kea-dhcp6` and `kea-dhcp-ddns`) all support a control channel, which is implemented as UNIX socket. The control channel is disabled by default, but most configuration examples have it enabled as it's a very popular feature. It opens a UNIX socket. To read from or write to this socket, generally root access is required, although if Kea is configured to run as non-root, the owner of the process can write to it. Access can be controlled using normal file access control on POSIX systems (owner, group, others, read/write).
|
|
|
|
|
|
Kea configuration is controlled by a JSON file on the Kea server. This file can be viewed or edited by anyone with file permissions (permissions controlled by the operating system). Note that passwords are stored in clear text in the configuration file, so anyone with access to read the configuration file can find this information. As a practical matter, anyone with permissions to edit the configuration file has control over Kea.
|
|
|
|
|
|
## Database connections
|
|
|
|
|
|
Kea can optionally use an external MySQL, PostgreSQL or Cassandra database to store configuration, host reservations or leases. The use of databases is a popular feature, but it is optional. It's also possible to store this data in a flat file on disk.
|
|
|
Kea can optionally use an external MySQL, PostgreSQL or Cassandra database to store configuration, host reservations or leases. The use of databases is a popular feature, but it is optional. It's also possible to store this data in a flat file on disk.
|
|
|
|
|
|
When using a database, Kea will store and use credentials in the form of username, password, host, port and database name in order to authenticate with the database. **These are stored in clear text in the configuration file.**
|
|
|
|
|
|
Depending on the database configuration, it's also possible to check if the system user matches the database username. Consult MySQL or PostgreSQL manuals for details.
|
|
|
Depending on the database configuration, it's also possible to check if the system user matches the database username. Consult MySQL or PostgreSQL manuals for details.
|
|
|
|
|
|
Kea does not support SSL/TLS connection to databases. There is a community contributed patch available for [SSL support for MySQL](https://github.com/isc-projects/kea/pull/15) and [SSL support for Cassandra](https://github.com/isc-projects/kea/pull/118). If the communication channel to the database is a concern, the database can be run locally on the Kea server.
|
|
|
Kea does not support SSL/TLS connection to databases. There is a community contributed patch available for [SSL support for MySQL](https://github.com/isc-projects/kea/pull/15) and [SSL support for Cassandra](https://github.com/isc-projects/kea/pull/118). If the communication channel to the database is a concern, the database can be run locally on the Kea server.
|
|
|
|
|
|
## Kea Logging
|
|
|
|
... | ... | @@ -86,13 +86,13 @@ Kea's Control Agent (CA) exposes a REST API over HTTP. The CA is an optional fea |
|
|
|
|
|
## Authentication for REST API
|
|
|
|
|
|
Kea 1.9.0 added support for basic HTTP authentication [RFC7617](https://tools.ietf.org/html/rfc7617) to control access for incoming REST commands over HTTP. The credentials (username, password) are stored in a local Kea configuration file on disk. The username is logged with the API command so it is possible to determine which authenticated user performed each command.
|
|
|
Kea 1.9.0 added support for basic HTTP authentication [RFC7617](https://tools.ietf.org/html/rfc7617) to control access for incoming REST commands over HTTP. The credentials (username, password) are stored in a local Kea configuration file on disk. The username is logged with the API command so it is possible to determine which authenticated user performed each command.
|
|
|
|
|
|
Kea 1.9.2 introduced a new `auth` hook point. With this new hook point it is now possible to develop an external hook library to extend the access controls, integrate with another authentication authority or add role-based access control to the Control Agent.
|
|
|
|
|
|
## TLS connection to Control Agent
|
|
|
|
|
|
[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.
|
|
|
[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.
|
|
|
|
|
|
|
|
|
|
... | ... | @@ -100,13 +100,13 @@ Kea 1.9.2 introduced a new `auth` hook point. With this new hook point it is now |
|
|
|
|
|
## Operating System Vulnerabilities
|
|
|
|
|
|
Kea runs on a wide selection of open source UNIX/Linux variants. You can choose your preferred OS. ISC provides installer packages for the most popular operating systems. If you prefer a stripped-down OS to minimize the footprint for security purposes, we do provide an installer package for Alpine Linux.
|
|
|
Kea runs on a wide selection of open source UNIX/Linux variants. You can choose your preferred OS. ISC provides installer packages for the most popular operating systems. If you prefer a stripped-down OS to minimize the footprint for security purposes, we do provide an installer package for Alpine Linux.
|
|
|
|
|
|
## Kea Vulnerability Handling
|
|
|
|
|
|
ISC is an experienced and active participant in the industry standard vulnerability disclosure process and maintains accurate documentation on our process and vulnerabilities in ISC software. Any critical vulnerabilities (those that score >5.0 on CVSSv3) are publicly disclosed and documented and reported to Mitre/CERT.
|
|
|
|
|
|
In case of a security vulnerability in Kea, ISC will notify support customers ahead of the public disclosure, and will provide a patch and/or updated installer package that remediates the vulnerability.
|
|
|
|
|
|
In case of a security vulnerability in Kea, ISC will notify support customers ahead of the public disclosure, and will provide a patch and/or updated installer package that remediates the vulnerability.
|
|
|
|
|
|
## Code quality and testing
|
|
|
|
... | ... | @@ -128,7 +128,7 @@ We have a process for running fuzz testing, using [AFL](https://github.com/googl |
|
|
|
|
|
## Release integrity
|
|
|
|
|
|
Software releases are signed with PGP, and distributed via the ISC web site, which is itself DNSSEC-signed, so you can be confident the software has not been tampered with.
|
|
|
Software releases are signed with PGP, and distributed via the ISC web site, which is itself DNSSEC-signed, so you can be confident the software has not been tampered with.
|
|
|
|
|
|
|
|
|
# 4. FAQ
|
... | ... | @@ -139,7 +139,7 @@ Not at this time. The CA exposes REST API over HTTP interface. The Kea ARM expla |
|
|
|
|
|
- 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.
|
|
|
|
|
|
- Is it possible to **block signals**?
|
|
|
|
... | ... | @@ -160,4 +160,4 @@ The following links point to materials of varied maturity, designs, prototypes, |
|
|
- All [open tickets related to security](https://gitlab.isc.org/isc-projects/kea/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=security)
|
|
|
- All [open tickets related to Role Based Access Control](https://gitlab.isc.org/isc-projects/kea/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=rbac-tls)
|
|
|
- RBAC + TLS (Role-Based Access Control and TLS) [discussion](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent-discussion), [requirements](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/rbac-tls-requirements), [design](https://gitlab.isc.org/isc-projects/kea/-/wikis/designs/https-wrapper-for-control-agent-solution)
|
|
|
- #1587 - a security doc ticket with many good comments |
|
|
\ No newline at end of file |
|
|
- #1587 - a security doc ticket with many good comments |