FreeRADIUS With Its Own EAP Certificate And BlastRADIUS Settings

freeradius

FreeRADIUS from AppStream, made to start and made safe to point a NAS at: a CA and an EAP server certificate of its own, a generated shared secret per client, every client required to sign its requests (the BlastRADIUS settings), users stored as SHA-512 crypt hashes, listeners on loopback by default, and every change checked by radiusd -XC on a copy of the configuration before it lands. Original role for EL 10, live-tested with podman on Rocky Linux 10.

No download, and no version to pin. EL 10 packages FreeRADIUS 3.2 in AppStream, so the role installs freeradius by name (and openssl for the certificates) and takes what the distribution ships: a security update arrives through dnf, not through a new release of this role. What the role owns is the configuration and the proof that the server works.

The distribution's unit, our configuration. The package's unit runs radiusd -C before every start, and the role keeps it. The role edits the package's own files in place rather than replacing them - the four EAP certificate lines, the listen addresses of the default site, the auth log switch, two include lines at the top of the users file - and writes clients.conf (root:radiusd 0640) whole.

The package does not start as installed. /etc/raddb/certs holds only the generator for EAP's certificates, so rlm_eap_tls fails, radiusd -XC exits 1, and the unit's own radiusd -C refuses to start the server (measured). The generator, run by hand, makes example certificates - "Example Server Certificate", key password "whatever" - that expire in 60 days, so a server set up that way loses EAP two months later. The role makes a CA of its own (10 years) and a server certificate it signs (825 days, the name from freeradius_tls_server_name), with no key password: the server's key root:radiusd 0640, the CA's key root 0600, because radiusd never needs the key that signs certificates. Set freeradius_tls_generate: false and the paths to bring your own.

Signed requests only. Every client gets require_message_authenticator = yes and limit_proxy_state = yes, the BlastRADIUS (CVE-2024-3596) settings. The live test sends the same request with and without a Message-Authenticator: signed, it is answered; unsigned, it gets no answer at all - and with the setting at no the unsigned one was answered (measured), so it is the setting that refuses it. A request with the wrong shared secret is dropped too, and radius.log says why: "Received packet from 127.0.0.1 with invalid Message-Authenticator! (Shared secret is incorrect.)".

A secret per client, made on the host. The stock localhost client's secret is testing123. The role writes clients.conf from freeradius_clients; a client given no secret gets one made on the host, kept in /etc/raddb/iacbazaar-secrets/<name> (root 0600) for you to give the NAS.

Hashes, never passwords. freeradius_users takes a SHA-512 crypt hash per user (openssl passwd -6). Users managed outside Ansible go in /etc/raddb/mods-config/files/local-users, which the role creates empty once and never writes; both files are included at the top of the users list. FreeRADIUS has no optional include there ($-INCLUDE and a missing target both fail the check - measured), which is why the role makes the file.

Checked on a copy. FreeRADIUS checks its whole configuration, not one file, so /usr/local/libexec/iacbazaar-radiusd-check puts the candidate into a copy of /etc/raddb and runs radiusd -XC there; the four EAP lines change together, so the whole tree is checked again before any restart.

What the live test does not cover. No EAP conversation: EL 10 packages no eapol_test. The certificate EAP would present is checked (issuer, name, validity), the EAP methods themselves are not exercised.

License

Commercial - IaC Bazaar EULA. (c) IaC Bazaar.