Security

Synopsis

There may be multiple methods of attacking a server. This section holds the configuration items that minimize the impact of those attacks.

Directives

allow_core_dumps
Syntax

allow_core_dumps = boolean

Default

no

Description

Core dumps are a bad thing. This value should only be set to yes if a problem with the server is being debugged.

allow_vulnerable_openssl
Syntax

allow_vulnerable_openssl = boolean

Default

no

Description

Allows the server to start with versions of OpenSSL known to have critical vulnerabilities.

This check is based on the version number reported by libssl and may not reflect patches applied to libssl by distribution maintainers.

chroot
Syntax

chroot = filename

Default

/path/to/chroot/directory

Description

The directory where the server does chroot.

The chroot process is done very early in the course of starting the server. After the chroot process has been performed, the server switches to the user configuration item listed in this document (which MUST be specified). If group is specified, the server switches to that group, too. Any other groups listed for the specified user in /etc/group are also added as part of this process.

The current working directory (chdir / cd) is left outside of the chroot process until all of the modules have been initialized. This allows the raddb directory to be left outside of the chroot process. Once the modules have been initialized, the server does a chdir to ${logdir}. Proceeding in this manner means that it should be impossible to break out of the chroot.

To avoid any security issues related to this use of chdir, simply ensure that the raddb directory is inside of the chroot and run cd raddb BEFORE starting the server.

If the server is statically linked, then the only files that have to exist in the chroot are ${run_dir} and ${logdir}. If you do the "cd raddb" as discussed above, then the "raddb" directory has to be inside of the chroot directory, too.

group
Syntax

group = string

Default

radius

Description

Radiusd is run as the number of this group.

If commented out, the server will run as the group that started it. In order to change to a different group, the server MUST be started as root (or have root privileges).

It is STRONGLY recommended that the server be run with as few permissions as possible. That is, if shadow passwords are not being used, then the group items below should be set to radius.

NOTE that some kernels refuse to setgid(group) when the value of (unsigned)group is above 60000; don’t use group nobody on these systems!

On systems with shadow passwords, group = shadow might need to be set for the server to be able to read the shadow password file. If users can be authenticated while in debug mode, but not while in daemon mode, then it may be that the debugging mode server is running as a user that can read the shadow info and that the user listed below cannot.

The server will also try to use initgroups to read /etc/groups. It will join all groups where user is a member. This can allow for some finer-grained access controls.

max_attributes
Syntax

max_attributes = integer

Default

200

Description

The maximum number of attributes permitted in a RADIUS packet. Packets that have MORE than this number of attributes in them will be dropped.

If this number is set too low, then no RADIUS packets will be accepted.

If this number is set too high, then an attacker may be able to send a small number of packets that will cause the server to use all available memory on the machine.

Setting this number to 0 means "allow any number of attributes".

reject delay
Syntax

reject_delay = integer

Default

1

Description

When sending an Access-Reject, a delay of a few seconds may occur. This delay may help slow down a DoS attack. The delay also helps to slow down any potential use of brute-force to crack a user’s password.

Setting this number to 0 means "send rejects immediately"

If this number is set higher than cleanup_delay, then the rejects will be sent at cleanup_delay time, when the request is deleted from the internal cache of requests.

Useful ranges: 1 to 5

status_server
Syntax

status_server = boolean

Default

yes

Description

Whether or not the server will respond to Status-Server requests.

When sent a Status-Server message, the server responds with an Access-Accept or Accounting-Response packet.

This is mainly useful for administrators who want to "ping" the server without adding test users or creating fake accounting packets.

It’s also useful when an NAS marks a RADIUS server "dead". The NAS can periodically "ping" the server with a Status-Server packet. If the server responds, it must be alive, and the NAS can start using it for real requests.

See also raddb/sites-available/status

user
Syntax

user = string

Default

radius

Description

Radiusd is run as the name of this user.

If commented out, the server will run as the user that started it. In order to change to a different user, the server MUST be started as root (or have root privileges).

It is STRONGLY recommended that the server be run with as few permissions as possible. That is, if shadow passwords are not being used, then the user items below should be set to radius.

NOTE that some kernels refuse to setgid(group) when the value of (unsigned)group is above 60000; don’t use group nobody on these systems!

On systems with shadow passwords, group = shadow might need to be set for the server to be able to read the shadow password file. If users can be authenticated while in debug mode, but not while in daemon mode, then it may be that the debugging mode server is running as a user that can read the shadow info and that the user listed below cannot.

The server will also try to use initgroups to read /etc/groups. It will join all groups where user is a member. This can allow for some finer-grained access controls.