... | ... | @@ -7,54 +7,54 @@ The sections below are not listed in any particular order. |
|
|
[[_TOC_]]
|
|
|
|
|
|
|
|
|
# 1. Kea Security
|
|
|
# 1. Optimizing 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.
|
|
|
Kea was designed to be installed into a protected environment in a core network datacenter. It has not been hardened from a security perspective. Below is a list of considerations should the administrator wish to improve Kea's security. In many cases, there's a trade-off between convenience and higher security.
|
|
|
|
|
|
|
|
|
## 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 Kea deployment could include 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, and a Stork monitoring system.
|
|
|
|
|
|
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.
|
|
|
This modular architecture allows the administrator to minimize 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.
|
|
|
You can minimize potential Kea security issues by running only those processes required in your environment.
|
|
|
|
|
|
## Application permissions
|
|
|
## Limiting 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.
|
|
|
The DHCPv4 and DHCPv6 protocols 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 on how to run Kea without root access.
|
|
|
|
|
|
## Kea Administrative access
|
|
|
## Securing 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.
|
|
|
Kea configuration is controlled by a JSON file on the Kea server. This file can be viewed or edited by anyone with file READ permissions (permissions controlled by the operating system). Note that passwords used by Kea 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. Limiting user permission to read the Kea configuration file is an important security step.
|
|
|
|
|
|
## Database connections
|
|
|
## Securing 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, avoiding the risk of a compromised database connection entirely.
|
|
|
|
|
|
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.**
|
|
|
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 verify that 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 Logging
|
|
|
## Information leakage through 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.
|
|
|
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.
|
|
|
Logs are sent to stdout, stderr, files or syslog. File permissions of the system apply to stdout/stderr and files. Syslog may export the logs over the network, exposing them further to possible snooping.
|
|
|
|
|
|
In conclusion logs are currently security sensitive but the problem will be solved in a future release.
|
|
|
Kea logs currently do contain sensitive information and should be protected. This is being mitigated through further development to obscure passwords in logs.
|
|
|
|
|
|
## 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.
|
|
|
Kea has support for two cryptographic libraries: Botan and OpenSSL. This creates both compile and run-time dependencies. 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.
|
|
|
See also the TLS section of the ARM, added with Kea version 1.9.6.
|
|
|
|
|
|
## TSIG signatures
|
|
|
|
... | ... | @@ -82,7 +82,9 @@ 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.
|
|
|
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.
|
|
|
|
|
|
If raw sockets are not required, disabling this access can improve security.
|
|
|
|
|
|
|
|
|
# 2. Remote Administrative Access
|
... | ... | |