BSD Adventures

How to Harden FreeBSD

 Print This Post

By default FreeBSD is very secure. Security vulnerabilities in the core OS pop up relatively infrequently. That being said it can still be a good idea to harden FreeBSD and follow best practices to make a FreeBSD install more resilient to malicious activity, especially if it’s a publicly facing server.

Patching

Like any other OS, regular patching is critical to keeping a system secure. Unlike a Linux install with a package manager, FreeBSD has two separate update mechanism: one for the core OS and one for software packages. By keeping both components patched you minimize attack vectors for your FreeBSD install. For specifics on patching refer to this post. Patches should be applied on the same schedule as other machines on the network. At least monthly is ideal but that may cause too many interruptions for a critical server. At the very least patches should be applied every quarter. Software packages will require at most a restart of any associated service. Core patches involving the kernel will require a reboot.

In addition to a regular patch cycle it’s a good idea to keep an eye on patches as they’re released. Critical patches may come out that warrant an out-of-cycle update. Updates for core FreeBSD and popular software packages are posted here. An RSS feed is available to make it easier to stay on top of announcements.

User Security

An often overlooked aspect of security are the users of a system. It’s important to properly manage not only accounts for actual people but service accounts. All users should have their own limited account to ensure they can’t access things they shouldn’t. It also sets up proper accountability. Users should have strong passwords that are changed on a regular basis. The password complexity and rotation rules can vary depending on the organization. The root password should be known by as few people as possible. User accounts should also be audited periodically to ensure that people who no longer need access have their accounts disabled or removed.

Root should never be logged on directly. To implement a technical control to prevent root from logging in, edit /etc/ttys and replace every instance of secure with insecure like so:

ttyv0 "/usr/libexec/getty Pc"             xterm       on        insecure
...
dcons "/usr/libexec/getty std.9600"       vt100       off       insecure

The sudo command from Linux is a great way to gain privileges temporarily instead of logging in as or switching to root. sudo is not installed by default in FreeBSD 11 but it’s available in the pkg and ports systems. To install it via pkg, simply run:

pkg install sudo

To install the port, run:

cd /usr/ports/security/sudo && make install

See this post for details on the pkg and ports systems. The first time sudo is installed you need to give at least one account privileges to use it. Either users or an entire group can be allowed to use sudo. To modify the list of accounts and groups that can use sudo, while elevated as root, run:


visudo

To add specific users, navigate to the section entitled blah and use this syntax:

avolpe ALL=(ALL) ALL

To add a group, use this syntax:

%wheel ALL=(ALL) ALL

The wheel group is a default group in FreeBSD that is typically used for users that should have administrator privileges. You can use that instead of making a new group.

Common Technical Controls

FreeBSD 11 offers some common hardening options at install time:

ALL of the controls should be enabled unless there’s a good reason not to do so. For example, the “Disable opening Syslogd network socket” option should be unchecked if the system is forwarding logs to a remote syslog server. In fact, this is a good practice if a syslog server is available.

To manually enable these options, add these lines to /etc/sysctl.conf

security.bsd.see_other_uids=0
security.bsd.see_other_gids=0
security.bsd.unprivileged_read_msgbuf=0
security.bsd.unprivileged_proc_debug=0
kern.randompid=$(jot -r 1 9999)
security.bsd.stack_guard_page=1

and these lines to /etc/rc.conf:

clear_tmp_enable=”YES”
syslogd_flags=”-ss”
sendmail_enable=”NONE”

Tamper Detection

There are a few software packages that monitor important configuration files on the system for changes. In the unlikely event that someone gains access to the system, or if a valid user changes things they shouldn’t, this software will keep track of it. AIDE is the easiest to get up and running. To get started, install it from pkg:

pkg install aide

or with ports:

make install /usr/ports/security/aide

The configuration file which tells AIDE which files to monitor is located at /usr/local/etc/aide.conf. The default file is pretty good, but you can learn how to customize it from the official AIDE documentation.
After the install, run:

aide --init
cd /var/db/aide/databases
mv aide.db.new aide.db

Each time a database is generated, a snapshot of the current state of the config files is taken. To compare the database to the current config files, just run:

aide

If you run this just after installing AIDE you’ll see that nothing has changed.
It’s a good idea to automatically have AIDE inspect your files on a regular basis. The reports section of this guide is a pretty good way to set up regular reports and have them e-mailed to you. If you kept the reports on the local system, someone who changed the config files could just as easily modify AIDE’s reports to make it look like nothing happened!

Auditing

FreeBSD includes a powerful auditing tool called OpenBSM. This provides extra logging and human readable reports. It’s a good idea to regularly review audit logs for a system. It saves a lot of time from sifting through the regular logs. Because of the complexity of the regular logs you might also miss something. The official FreeBSD documentation on auditing provides a better guide than I ever could.

Other Technical Controls

There are a few other controls that can be set to make the system a little stealthier on the network. These options may break some legitimate network scanning tools.
Add the following lines to /etc/sysctl.conf:

net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1

Other FreeBSD flavors

There are some FreeBSD forks which incorporate additional security features like exploit mitigation. The most popular one is HardenedBSD. Because this is an entirely separate OS, you would have to do a fresh install. If you want extra security from the get-go this may be a good alternative. Keep in mind that HardenedBSD is a relatively new project so there is a chance that development may slow or even halt.