... | ... | @@ -7,10 +7,16 @@ This page discusses various aspects related to Kea software security. This is a |
|
|
|
|
|
The sections below are not listed in any particular order. This is not a recommendation for any specific practices. Many topics here are simply something to consider. In many cases, there's a trade-off between convenience and higher security. It is up to the administrator to make those choices.
|
|
|
|
|
|
## OS Security
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
## Component-based design
|
|
|
|
|
|
The Kea architecture is modular, with separate daemons for separate tasks. For example, the kea-dhcp4 binary is dedicated to providing DHCPv4 service, `kea-lfc` is a separate tool for doing periodic lease file cleanup when memfile is used, `kea-dhcp-ddns` is dedicated to sending DNS Updates to DNS servers etc. 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 necessary. Similarly, `kea-lfc` will never be triggered (and can be safely removed or never installed) if memfile is not used.
|
|
|
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 `dhcpd`, which is a single binary that does everything.
|
|
|
|
... | ... | @@ -64,25 +70,32 @@ Kea can be switched to use UDP sockets. This will work when only relayed traffic |
|
|
|
|
|
# 2. Remote Administrative Access
|
|
|
|
|
|
Kea's Control Agent provides a REST API over HTTP interface. The CA is disabled by default. When enabled, it uses loopback (127.0.0.1 or ::1) by default, unless configured otherwise.
|
|
|
Kea's Control Agent (CA) exposes a REST API over HTTP interface. The CA is an optional feature that is disabled by default. When enabled, it uses loopback (127.0.0.1 or ::1) by default, unless configured otherwise.
|
|
|
|
|
|
## CA authentication
|
|
|
## Authentication for REST API
|
|
|
|
|
|
Control Agent exposes REST API over HTTP interface. CA is an optional component that is not run by default, but it's a popular feature. Since Kea 1.9.0, it can optionally use basic HTTP authentication (RFC7617) to control access of the incoming REST commands. The credentials (username, password) can be stored in local Kea config file on disk. Kea 1.9.2 introduced auth hook point. It's possible to develop an external hook library that will provide access control. Such a library providing RBAC capabilities is planned in the 1.9 series.
|
|
|
Kea 1.9.0 added support for basic HTTP authentication (RFC7617) to control access for incoming REST commands. 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.
|
|
|
|
|
|
## 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 TLS wrapper around it. A native TLS implementation in Kea is considered in 1.9 series.
|
|
|
[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.
|
|
|
|
|
|
## Control channel security
|
|
|
|
|
|
## Security of control channel
|
|
|
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 access control on POSIX systems (owner, group, others, read/write).
|
|
|
|
|
|
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. The access can be controlled using normal access control on POSIX systems (owner, group, others, read/write).
|
|
|
|
|
|
# 3. Managing Software Vulnerabilities
|
|
|
|
|
|
## 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. Kea vulnerabilities are publicly disclosed, and any critical vulnerabilities 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.
|
|
|
|
|
|
# 3. Code quality and testing
|
|
|
## Code quality and testing
|
|
|
|
|
|
Kea undergoes extensive tests during its development. The following is a excerpt from all the processes that are used to ensure adequate code quality:
|
|
|
|
... | ... | @@ -100,12 +113,16 @@ Kea undergoes extensive tests during its development. The following is a excerpt |
|
|
|
|
|
We have a process for running fuzz testing, using [AFL](https://github.com/google/AFL). There are two modes which are run. First fuzzes incoming packets, effectively throwing millions of mostly broken packets at Kea per day. The second mode fuzzes configuration structures and forces Kea to attempt to load them. Those two modes are being run continuously since around 2018.
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
|
|
|
# 4. Future improvements
|
|
|
|
|
|
This is a list of improvements that are planned in the future. Please contact ISC if any of them are of particular importance for you:
|
|
|
This is a list of improvements that are possible. Please contact ISC if any of them are of particular importance for you:
|
|
|
|
|
|
- **Implement TLS support in CA**. 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 the whole reverse proxy is a nuisance from maintenance perspective, especially if the number of servers is large. We are planning to implement a more lightweight solution.
|
|
|
- **Native TLS support in the Control Agent (CA)**. 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 the whole reverse proxy is a nuisance from maintenance perspective, especially if the number of servers is large. We are planning to implement a more lightweight solution.
|
|
|
|
|
|
- **Role Based Access Control**. As of Kea 1.9.3, there' is basic HTTP authentication 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. There is a work in progress to provide this capability.
|
|
|
|
... | ... | |