FreeBSD System Security Overview

Tags

bsdconfig, exploit, FreeBSD, patching, security, update, upgrade, vulnerability

Elsewhere on this blog I’ve probably mentioned that patching, a properrly configured firewall and updated anti-malware protection will prevent 99% of security threats. Fortunately all three can be readily added to a FreeBSD installation, and there are some other native features in this operating system that can provide pretty solid security.
The most important things, in my opinion, are exploit prevention and mitigation – that is, making it hard as possible for something to exploit software vulnerabilities, and restricting what an exploit could do if executed.

BSD Configuration Options
Already present in a FreeBSD installation is the ‘bsdconfig’ utility, which enables low-level configuration changes. The Security and Startup options are the ones we might want to configure, after everything’s set up.

The Securelevel options are used for limiting the actions that could be performed with root privileges, assuming no malicious program is capable of undoing these configuration changes. In Highly secure mode, the loading/unloading of kernel modules, the mounting of additional filesystems and certain configuration changes are disabled. This could provide an additional safeguard against the installation of kenel-mode rootkits. There is a help page describing what each Securelevel option does.

Patching
If an anti-malware system has reacted to a malware infection attempt, it typically means a vulnerability has already been exploited and shellcode was executed. Patching known vulnerabilities and removing software we don’t need really is the first line of defence, if the operating system doesn’t have native exploit prevention measures such as ASLR.
The following commands are used to fetch available updates to the base system, and install whatever has been fetched:
#freebsd-update fetch
#freebsd-update install

This sorts the updates for the core operating system, but there are also a load of other packages that were added later. The following looks for vulnerability notices associated with installed applications:
#pkg audit -F

Vulnerability disclosures are posted quite regularly, so it makes sense to make periodic checks.

To check for packages that could be upgraded to a more recent version:
#pkg version

Another tool we could use for checking for outdated pakages is portmaster.
#portmaster -a

Exploit Mitigation
PolicyKit/PolKit is something I’d need to look into further, but it seems the rough equivalent of SELinux here. Essentially it checks a request to a privileged process from an unpriviliged process, according to specific policies. The idea is that an exploited or compromised program remains limited by whatever policies are set.
A configured PolKit is included as part of the base system, and a GUI for it’s included with KDE by default.

Jails
There is a ‘jail’ utility native to the system, which is based on the chroot concept. Essentially this changes the root directory location for a given process, so that it cannot refer to anything beyond it. The FreeBSD jail adds further mechanisms to restrict access to hardware resources from a process in the chroot, so it almost provides a fake environment with predefined resources. For this to work, the FreeBSD jail requires its own jail name, host name and IP address attributes. A jail could be made to resemble a complete FreeBSD system, or a ‘service’ jail dedicated to one or two processes.
We might use this for compiling a new Linux/UNIX system within a pre-existing host installation, and the FreeBSD handbook makes reference to extracting the contents of an ISO file into the /mnt directory.

Anti-Malware
With UNIX-based systems, the anti-malware solutions have the advantage of performing more thorough checks for anything suspicious in the operating system components.
With FreeBSD’s package repositories, we have a choice of rkhunter, chkrootkit and clamAV. Each has a different method of looking for activity associated with malicious programs, but generally they check for signs of privilege escalation, replaced binaries and processes being hidden from user space.

It might take a little knowledge and experience to understand the command line output from these programs. Of course, the full output of these programs can be dumped to a text file using a command like:
#rkhunter -c >> scanlog.txt

Since all three employ slightly different methods for uncovering rootkits, best results are gained by running all three separately periodically.

Firewall and Packet Filtering
Packet filtering in FreeBSD (and Linux) happens at the kernel level, with the packets passing through the network interface and then the packet filtering module. I think this is more for FreeBSD boxes on the network perimeter, or even to use a FreeBSD box as a firewall, but it’s not a bad idea to have a host-based setup as threats are stopped at the kernel level.

FreeBSD includes three firewalls: PF, IPFW and IPF. IPFW seems the default choice here, as there’s already a ruleset file in /etc/rc.firewall, and it might be easier for most users to simply modify this as needed. There seems to be a disadvantage that IPFW only works with IP addresses, port numbers and transport layers, whereas PF looks at the session layer as well and includes a few other proxying and NAT features.

To enable the IPFW as a service at startup, add the following lines to /etc/rc.conf:

The firewall profiles are listed in rc.firewall. The alternative for a desktop system is ‘client’. For an offline machine it might be ‘closed’. Or we could set this variable to ‘filename’ if we wanted to load all the rules from elsewhere. To list the currently applied firewall rules:
#ipfw list

Then, if any changes were made and the ruleset needs reloading:
#service ipfw restart

inetd
Slightly related to the packet filtering and firewall features, FreeBSD’s repositories include xinetd, which can replace the pre-installed inetd. These programs listen for incoming network traffic, and starts a predefined server process to handle requests for whichever port, while applying any relevant policies. This ensures the right programs respond to incoming requests, and to prevent servers being misused. For example, we might want Apache to handle incoming traffic on ports 80 and 443 only, and to limit the number of session attempts for each IP address.

The rules are defined in /etc/inetd.conf, and the port-service mappings in /etc/services.