Skip to content

GitLab

Last edited by Francis Dupont
Page history

security

This page discusses various aspects related to Kea software security. This is a living document. This page will eventually be merged into Kea ARM.

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.

1. Kea Security

Kea was designed to be installed into a protected environment in a core network datacenter. It is not hardened from a security perspective. 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.

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.

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.

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 for details.

Kea Administrative access

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.

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.

Kea does not support SSL/TLS connection to databases. There is a community contributed patch available for SSL support for MySQL and SSL support for Cassandra. If the communication channel to the database is a concern, the database can be run locally on the Kea server.

Kea Logging

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

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.

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:

  • HMAC-MD5
  • HMAC-SHA1
  • HMAC-SHA224
  • HMAC-SHA256
  • HMAC-SHA384
  • HMAC-SHA512

See the Kea ARM 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.

Raw socket support

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.

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. While Kea is running with UDP sockets, iptables are working properly.

2. Remote Administrative Access

Kea's Control Agent (CA) exposes a REST API over HTTP. The CA is an optional feature that is disabled by default, but it is extremely popular. When enabled, it listens on loopback address (127.0.0.1 or ::1) by default, unless configured otherwise.

Authentication for REST API

Kea 1.9.0 added support for basic HTTP authentication 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 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

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 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.

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:

  • each line of code goes through a formal review before it is accepted. The review process is documented and available publicly
  • roughly 50% of the source code is dedicated to unit-tests. As of Dec. 2020, there are over 6000 unit-tests. There is a requirement that every new piece of code has to come with unit-tests before it is accepted.
  • there are around 1500 system tests available that test Kea. Those simulate correct and invalid situations, covering network packets (mostly DHCP, but also DNS and others), command-line usage, API calls, database interactions, scripts and more.
  • there are performance tests with over 80 scenarios that test Kea overall performance and resiliency to various levels of traffic, measuring various metrics (latency, leases per seconds, packets per seconds and others).
  • Kea uses CI (Continuous Integration). This means that great majority of tests (all unit and system tests, and most performance tests) are run for every commit. Many lighter tests are ran on branches, before the code is even accepted.
  • Negative testing. Many unit and system tests check for negative scenarios, such as incomplete, broken, truncated packets, API commands, configuration files, incorrect sequences (such as sending packets in invalid order) and more.
  • We use many tools that perform automatic code quality checks
  • We use static code analyzers: Coverity Scan, shellcheck, danger
  • We use dynamic code analyzers: Valgrind, clang's Thread Sanitizer (TSAN)

Fuzz testing

We have a process for running fuzz testing, using 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. FAQ

  • Does the Control Agent (CA) support TLS connections?

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 using identity based on the basic HTTP authentication or TLS credential (i.e. the client end-entity certificate).

  • Is it possible to block signals?

Since its early days, Kea has been 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.

  • Is there SSL/TLS support for DB connections?

Not in the official Kea distribution at the moment. There are two community contributed patches on Github for MySQL and Cassandra.

  • Has there been a Security audit of Kea?

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.

5. Other materials

The following links point to materials of varied maturity, designs, prototypes, tickets planned and in progress etc.