|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
|
# 1. Kea Security
|
|
|
|
|
|
This page discusses various aspects related to the 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).
|
|
|
|
|
|
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.
|
|
|
|
|
|
## Cryptography in Kea
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
That is in contrast to ISC DHCP's `dhcpd`, which is a single binary that does everything.
|
|
|
|
|
|
## Application permissions
|
|
|
|
|
|
Kea uses the DHCPv4 and DHCPv6 protocols, which assume the server will open privileged UDP port 67 (DHCPv4) or 547 (DHCPv6). Under normal circumstances that requires **root access**. However, with the use of the capabilities mechanism, Kea can run from an unpriviliged account. See [the Kea ARM](https://kea.readthedocs.io/en/kea-1.8.1/arm/install.html#running-kea-from-non-root-account-on-linux) for details.
|
|
|
|
|
|
## Database connection
|
|
|
|
|
|
Kea can optionally use an external MySQL, PostgreSQL or Cassandra database to store configuration 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, credentials in the form of username, password, host, port and database name can be specified. 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.
|
|
|
|
|
|
[how is the username and password stored/protected in Kea?]
|
|
|
|
|
|
As of today, Kea does not support SSL 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.
|
|
|
|
|
|
## Cryptography components
|
|
|
|
|
|
Kea has support for two cryptographic libraries: Botan and OpenSSL. This is both compile and run-time dependency. The library is chosen at compilation time. The binaries use only one library that is chosen at compilation time. Most deployments use OpenSSL, because it's much more popular, but Botan remains a fully supported alternative.
|
|
|
|
... | ... | @@ -21,51 +45,44 @@ Kea supports the following algorithms when signing DNS Updates with TSIG signatu |
|
|
- HMAC-SHA384
|
|
|
- HMAC-SHA512
|
|
|
|
|
|
See [Kea ARM](https://kea.readthedocs.io/en/kea-1.8.1/arm/ddns.html?highlight=HMAC-md5#tsig-key-list) for up to date list.
|
|
|
See [the Kea ARM](https://kea.readthedocs.io/en/kea-1.8.1/arm/ddns.html?highlight=HMAC-md5#tsig-key-list) for an up to date list.
|
|
|
|
|
|
Kea uses uses SHA256 to calculate DHCID records. This is irrelevant from the cryptography perspective, as the DHCID record is only used to generate unique identifiers for two devices that may have been assigned the same IP address at different times.
|
|
|
|
|
|
## Component features
|
|
|
|
|
|
Kea architecture assumes that for each specific task there is a separate daemon or utility, e.g. 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. That is in contract to ISC DHCP's `dhcpd`, which is a single binary that does everything. The Kea architecture allows not running components that are not used. 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.
|
|
|
|
|
|
## Database connection
|
|
|
|
|
|
Kea can optionally use MySQL, PostgreSQL or Cassandra databases. The usage of databases is a popular feature, but it's not mandatory. It's possible to store configuration and leases in a flat file on disk. When using a database, credentials in the form of username, password, host, port and database name can be specified. 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.
|
|
|
|
|
|
As of today, Kea does not support SSL 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).
|
|
|
|
|
|
## Raw sockets usage
|
|
|
|
|
|
In principle, Kea DHCPv4 uses raw sockets to receive traffic from clients. The difficulty is with receiving packets from devices that don't have an IPv4 address yet. When dealing with a direct traffic (both client and server connected to the same link, not via relays), the kernel normally drops the packet as the source IP address is 0.0.0.0. Therefore Kea needs to open raw sockets to be able to receive this traffic.
|
|
|
In principle, Kea DHCPv4 uses raw sockets to receive traffic from clients. The difficulty is with receiving packets from devices that don't have an IPv4 address yet. When dealing with direct traffic (where both client and server are connected to the same link, not separated by relays), the kernel normally drops the packet as the source IP address is 0.0.0.0. Therefore Kea needs to open raw sockets to be able to receive this traffic.
|
|
|
|
|
|
However, this is not necessary if all the traffic is coming via relays. In that case normal UDP sockets can be used. There is a `dhcp-socket-type` parameter that can be used.
|
|
|
|
|
|
Raw socket is the default, as it is most versatile.
|
|
|
The default is to permit raw socket usage, as it is most versatile.
|
|
|
|
|
|
When using raw sockets, Kea is able to receive raw layer 2 packet, bypassing most firewalls (including iptables). This effectively means that when raw sockets are used, the iptables can't be used to block DHCP traffic. This is a design choice of the Linux kernel.
|
|
|
|
|
|
Kea can be switched to use UDP sockets. This will work when only relayed traffic (via relays) is received. It will not work for directly connected devices. With Kea is running with UDP sockets, iptables are working properly.
|
|
|
|
|
|
## Running Kea as non-root
|
|
|
# 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.
|
|
|
|
|
|
## CA authentication
|
|
|
|
|
|
Kea uses DHCPv4 and DHCPv6 protocol, which assumes the server will open privileged UDP port 67 (DHCPv4) or 547 (DHCPv6). Under normal circumstances that requires root access. However, with usage of capabilities mechanism, Kea can run from non-root account. See [Kea ARM](https://kea.readthedocs.io/en/kea-1.8.1/arm/install.html#running-kea-from-non-root-account-on-linux) for details.
|
|
|
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.
|
|
|
|
|
|
## TLS connection to Control Agent
|
|
|
|
|
|
Kea's Control Agent provides 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.
|
|
|
[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.
|
|
|
|
|
|
[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.
|
|
|
|
|
|
## Security of control channel
|
|
|
|
|
|
The three primary Kea deamons (`kea-dhcp4`, `kea-dhcp6` and `kea-dhcp-ddns`) all provide a control channel, with is implemented as UNIX socket. The control channel is disabled by default, but most config 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).
|
|
|
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).
|
|
|
|
|
|
|
|
|
## CA authentication
|
|
|
|
|
|
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.
|
|
|
|
|
|
# 2. Code quality and testing
|
|
|
# 3. 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:
|
|
|
|
... | ... | @@ -83,11 +100,8 @@ 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.
|
|
|
|
|
|
# Security audit
|
|
|
|
|
|
ISC initiated a process to audit ISC software from a security perspective. We have completed audit for Stork, a dashboard solution for Kea in Oct. 2020. The audit was conducted by two members of ISC staff. Both have extensive security background experience in large scale corporate deployments (@manu) and security research (@fdupont). Similar audit for Kea is planned for early 2021.
|
|
|
|
|
|
# 3. Future improvements
|
|
|
# 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:
|
|
|
|
... | ... | @@ -97,4 +111,8 @@ This is a list of improvements that are planned in the future. Please contact IS |
|
|
|
|
|
- **Block signals**. Since its early days, Kea is able to react to POSIX signals. This simple, but very reliable mechanism is very popular. By sending a HUP signal to Kea, it can be told to reload its configuration. This is frequently used to trigger reconfiguration event in Kea, without restarting the whole service. However, there is a deficiency from accountability perspective. The signal mechanism does not provide any information about its sender. In general, only the process owner or root are able to send signals and that is enforced by the kernel. In the future, we may provide a configuration parameter to disable HUP and TERM signals. This would improve accountability as, together with configured authentication, it would eliminate the potential for a root user to reconfigure Kea. This is only a minor improvement, though, as root can always edit the local config file, kill the process and restart it. However, this is a much more intrusive process, so it would be much harder to hide in case of bad actor trying to plant unauthorized changes.
|
|
|
|
|
|
- **SSL support for DB connections**. Support to TLS connection for databases can be added. There are two community contributed patches on github for MySQL and Cassandra. |
|
|
\ No newline at end of file |
|
|
- **SSL support for DB connections**. Support to TLS connection for databases can be added. There are two community contributed patches on github for MySQL and Cassandra.
|
|
|
|
|
|
- **Security audit**.
|
|
|
|
|
|
We have completed a security audit for Stork, a dashboard solution for Kea in Oct. 2020. The audit was conducted by two members of ISC staff. Both have extensive security background experience in large scale corporate deployments (@manu) and security research (@fdupont). A similar audit for Kea is planned for 2021. |