Introduction
This article aims to be a central resource for all things related to Kea security.
Security stance necessarily varies with the needs of the operator and the environment. A dedicated server which only runs Kea will have different security needs than a multi-purpose server hosting many services and users. Larger organizations with more people typically have tighter security requirements. As such, this article can only provide guidelines for typical scenarios. Kea administrators will have to tailor these guidelines for their particular policies and environment.
By default, the Kea packages provided by ISC implement protections suitable for most installations.
General
- All best practices for servers apply
- In particular: Keep current with updates to new versions for security and stability
- Monitor the
kea-announcemailing list for new releases and advisories - Be aware of important information resources:
- Run Kea daemons as an unprivileged user (not
root)
Files and permissions
A detailed discussion of directories, files, and protections can be found in Kea files and directories. A quick summary is:
| File type | Typical path | Kea | Admins | Others |
|---|---|---|---|---|
| Executables | /usr/sbin |
Read-only | Read-only | Read-only |
| Libraries | /usr/lib/kea |
Read-only | Read-only | Read-only |
| Scripts | /usr/share/kea |
Read-only | Read-only | Read-only |
| Configuration | /etc/kea |
Varies | Writable | None |
| System Logs | /var/log |
None | Read-only | None |
| Kea Logs | /var/log/kea |
Writable | Read-only | None |
| Data | /var/lib/kea |
Writable | None | None |
| Transients | /var/run/kea |
Writable | None | None |
Again, see Kea files and directories for details.
Securing the API
As noted in Kea Sockets, the Kea API is very powerful. Depending on how Kea is configured to run, access to the Kea API can potentially be used to take over or corrupt the entire host server. Due to this power, operators are very strongly encouraged to take steps to protect the API from abuse. These steps might include some subset of the following:
- If you do not use the API, do not configure any control sockets at all
- Restrict the directories containing Unix domain sockets
- Bind HTTP listeners to loopback (
127.0.0.1and/or::1) - Bind HTTP listeners to privileged ports
- Use a firewall to restrict access to HTTP listeners
- Require HTTP authentication (password)
- Use HTTPS/TLS encryption
- Require HTTPS/TLS client certificates (mutual authentication)
- Restrict HA listeners to HA-related commands