checker-kerberos/README.md

62 lines
2.3 KiB
Markdown

# checker-kerberos
happyDomain checker that audits a Kerberos realm from its DNS records.
Starting from the realm name (or from the SRV records grouped under the
`abstract.Kerberos` service), the checker performs a series of
**anonymous probes**, and an optional **authenticated round-trip** when
credentials are supplied, to give a complete picture of the realm's
availability and security posture.
## What gets checked
- SRV layout, `_kerberos._tcp.`, `_kerberos._udp.`,
`_kerberos-master._tcp.`, `_kerberos-adm._tcp.`, `_kpasswd._tcp.`,
`_kpasswd._udp.`.
- Forward resolution of every SRV target (A + AAAA).
- TCP reachability of each KDC/kadmin/kpasswd host.
- UDP reachability of the KDC via a real AS-REQ.
- Anonymous AS-REQ probe: realm confirmation, supported enctypes
(from `ETYPE-INFO2`), PKINIT hint (`PA-PK-AS-REQ`), clock skew.
- Weak enctype detection (DES / RC4).
- Optional authenticated round-trip when `principal` and `password`
are supplied: TGT acquisition then TGS-REQ for `targetService`.
The HTML report surfaces the most common misconfigurations with a
direct remediation hint:
| Failure | Hint |
| --- | --- |
| No SRV records | publish `_kerberos._tcp.REALM. SRV …` |
| SRV target DNS failure | add A/AAAA for the target |
| Port 88 unreachable | open TCP+UDP 88 inbound |
| Clock skew > max | run ntpd/chrony |
| Weak enctypes only | switch to `aes256-cts-hmac-sha1-96` |
| Wrong realm in reply | fix `default_realm` / realm config |
| AS-REP roasting exposure | enable `requires_preauth` |
## Build
```sh
make # standalone binary
make plugin # shared object for happyDomain
make docker # container image
```
## Run
```sh
./checker-kerberos -listen :8080
```
## Deployment
The HTTP listener has no built-in authentication or rate-limiting, and
will issue DNS queries and Kerberos AS-REQ / TGS-REQ exchanges against
whatever realm and KDCs the caller asks for. When a `principal` and
`password` are supplied, those credentials are forwarded to the target
KDC over the network as part of an authenticated round-trip. It is
meant to run on a trusted network, reachable only by the happyDomain
instance that drives it. Restrict access via a reverse proxy with
authentication, a network ACL, or by binding the listener to a private
interface; do not expose it directly to the public internet.