... | ... | @@ -9,10 +9,6 @@ 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.
|
|
|
|
|
|
## Operating System 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
|
|
|
|
... | ... | @@ -28,7 +24,7 @@ Kea uses the DHCPv4 and DHCPv6 protocols, which assume the server will open priv |
|
|
|
|
|
## Kea Administrative access
|
|
|
|
|
|
?? Local access while on the machine is via a socket. Access is controlled by the operating system using file access permissions. ??
|
|
|
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).
|
|
|
|
|
|
?? 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).
|
|
|
|
... | ... | @@ -93,13 +89,14 @@ 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.
|
|
|
|
|
|
## Control channel security
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
# 3. Managing Software Vulnerabilities
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
## 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.
|
... | ... | |