... | ... | @@ -6,11 +6,35 @@ The sections below are not listed in any particular order. This is not a recomme |
|
|
|
|
|
## Cryptography in Kea
|
|
|
|
|
|
- TSIG
|
|
|
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 usage 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.
|
|
|
|
|
|
## 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
|
|
|
|
|
|
## Running as non-root
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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
|
|
|
|
|
|
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 access. 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.
|
|
|
|
|
|
## TLS connection to Control Agent
|
|
|
|
... | ... | @@ -27,4 +51,6 @@ This is a list of improvements that are planned in the future. Please contact IS |
|
|
|
|
|
- **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.
|
|
|
|
|
|
- **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. |
|
|
\ No newline at end of file |
|
|
- **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 |