Hardening

FREEBSD SECURITY & HARDENDING GUIDE This guide is intended to identify the options you have for securing your FreeBSD system. Additionally, there are many aspects to security maintenance that are not specific to FreeBSD, but are an important part of keeping your systems secure.

Security is not just a list of steps to take. It really is a philosophy. But it is important to understand that no matter how paranoid your philosophy, if your server is accessible to the world, there is a chance that it will be compromised. The philosophy can be boiled down to this: Limit exposure internally and externally to only those people and services that are absolutely necessary. Always assume that every application will be vulnerable at some point. By default, all known exploits should be patched, but the system can be configured to mitigate the existence of many unknown vulnerabilities, though not all.

It is also true that operational security is a balance between convenience and system security. Some risks are worth taking for the benefit they provide, some are not. It will be up to each person or organization to determine their risk tolerance.

Hardening FreeBSD can be broken down like this:

Harden the OS:

Remove unnecessary suid/sgid applications, or secure them to a more restrictive group. The less such applications you have on your system, the less likely you will be compromised by a local exploit. Even if your system does not allow shell access to outsiders, if some other remotely exploitable vector allows an attacker to gain even an unprivileged shell, they could use a local exploit to gain elevated permissions. You can find all suid and sgid files by running the following command:

find / -type f ( -perm -04000 -o -perm -02000 ) -exec ls -lg {} ;

An extra measure of security for protecting suid/sgid files is to mount / and /usr as read-only. The downside to this is that any time you want to upgrade the operating system, you will esentially need to change back to read-write and reboot. The upside is that an attacker would not easily be able to replace binaries or add new ones earlier in the search path.

Mount all other partitions with the “nosuid” option. This does two things – it prevents suid/sgid executables from being modified to perform other tasks and it prevents suid/sgid files from being created and possibly using some other weakness to gain elevated privileges.

For file systems that are writeable by all users, or where binary programs are not being stored, like /tmp and /var, it is strongly recommended that those file systems be mounted with the "nosuid" and "noexec" flags. Depending on your configuration, either or both of these settings may prevent some applications from functioning properly.

Turn on the immutable flags for all “system binaries” in /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, and the like. The immutable flags is one of a set of file flags that can be applied to files in FreeBSD. When the immutable flag is set the file cannot be changed, even by root, until the flag is removed. Immutable flags can be set using the "chflags schg <filename>" command. They can be removed with "chflags noschg <filename>".

Set kern_securelevel="2" in /etc/rc.conf. This will prevent any changes to any files marked with the immutable flag until the securelevel is decreased or the system is run in single user mode. This prevents file systems from being unmounted while the system is up, as well as preventing kernel modules from being loaded while the system is in multi-user mode. Many FreeBSD attackers will use a kernel module to mask their activities once they have compromised the system.

If extreme security is called for, set securelevel to 2 or higher, set the SCHG flag on all system binaries and libraries, and also /etc/rc.conf. In this configuration, the ONLY way to drop the security level to a state where binaries can be changed is by booting into single user mode, and editing /etc/rc.conf.

Add the “nodev” flag to all drives in /etc/fstab, except /dev. This will prevent an attacker from creating a device file with alternate permissions, potentially allowing them to read or write to an otherwise secure device.

Change permissions on home directories, including root, to be 600. This will effectively restrict an attacker who has not yet gained root permission from accessing files inside home directories, like known_hosts and authorized_keys.

Change permissions on all log files in /var/log to 600. Set newsyslog.conf to recreate all log files with those permissions. If an attacker does gain entry to your system, they will often try to either use the logs to determine activity on the system or modify the logs to remove the evidence of their trespass. This will not help if the attacker has root privileges, but it will help substantially if the attacker has an unprivileged account. These restrictive settings are also helpful as a normal precaution when your system is accessible to many different people, as in a hosting environment or shell server.

To help ensure that logs are available even after a compromise, it is a good strategy to have your syslogs forwarded to a remote host.

Remove all non-needed applications. FreeBSD ships with a wide array of applications, many of which will not be needed in a given situation. Some of these applications, like the lp print system have had numerous vulnerabilities in the past. If you are building a web server, clearly the lp system and all its components will not be needed. There are many examples of this in the binary directories. Note, however, that simply removing a binary does not mean that the risk is completely mitigated. Depending on the details of the exploit, it may be possible for an attacker to copy a needed binary from some other source using fetch or ftp.

{Section on MAC - to be written}

These changes essentially make it difficult to further compromise a system once an intruder has access. You must work under the assumption that there will always be some flaw in some component of the operating system or application software that will allow am intruder to gain access. The key is to limit the opportunity for someone to "get in" by pairing back the possible vectors for entry (see the networking section below) and to limit the permissions an attacker has if she does get in.

Chroot/Jails

{Section on jail & chroot use - to be written}

Networking:

As stated earlier, it is very important to limit the exposure of your server, creating a smaller target if you will, by minimizing the number of services that listen on the network. Clearly, it is not reasonable to reduce the risk to zero - doing to will most certainly render the usefulness of the server to zero as well.

After your host is configured with the applications you need, running sockstat -l will list all process that are bound to the network. A thorough review of the list will help you catch any unitended services, let you know what ports you need to open & close in the firewall configuration and generally get you more familiar with your server.

It is strongly advisable the you disable all NFS related tools, like portmap. Unless you have a specific need for it, portmap will cause nothing but heartache. Adding the following lines to /etc/rc.conf will disable them:

portmap_enable="NO" single_mountd_enable="NO" nfs_reserved_port_only="YES"

The most common network security defense implement is a firewall. FreeBSD has a few firewall options, but I prefer ipfw, primarily because of the readability of the rules it uses. The documentation on ipfw included with FreeBSD, and the default config file, /etc/rc.firewall, are very thorough references to the configuration of ipfw. A starting note, however, is to add the lines:

firewall_enable="YES" firewall_type="CLIENT"

to /etc/rc.conf. Also, if you are remotely configuring firewall rules, editing the rules script through /usr/share/examples/ipfw/change_rules.sh is a must! It is very easy to insert a rule that renders your host completely inaccessible from the network. Using the script will automatically revert to the previous ruleset if that happens.

Configuration of the firewall is conceptually very easy: adopt an exception-based allow list, rather than an exception based deny. That means that, by default, you are rejecting all traffic. Then go back and add services one at a time before the deny rule. Using the list given from sockstat -l will help you determine what ports need to be opened. Also, if the entire internet does not need to connect to a given port, specifically limit the source addresses on the "allow" rule for that port.

In the latest version of FreeBSD, bind (the DNS server) is configured to run inside of a chroot'd environment. This is extermely important as bind has repeatedly had serious remotely exploitable vulnerabilities in the past. If it wasn't such a good DNS server, people would have surely dumped it by now. The chrooted environment basically limits the damage that an attacked can do using a bind explot to just the directory of the chroot'd jail, using the credentials that bind was run as.

Ongoing Security

Many people start to roll their eyes at this part, but it is THE single most important part of this guide: the security of your system must be actively maintained. All the work in hardening your server keeps the bad guys out right now. Next week, or next month or next year, there WILL be some aspect of your system that is seriously vulnerable to attack. Likewise, as the system is maintained and evolved, changes to the security precautions must also change and evolve. Many many compromises happen to systems that were adequately secured when they were deployed, but over time, vulnerabilities and exploits were discovered in applications runing on the host which go unpatched. At that point, it is only a matter of time before someone takes over your system.

The best way to stay informed about security problems is to subscribe to the annoucement or security mailing lists for FreeBSD and any non-native FreeBSD applications that you run. Know what versions you are running and you will be able to quickly determine your risk exposure as security notices come in from those lists. Patch or upgrade any applications that are vulnerable in a timely manner. It is very important to note that after patching or upgrading applications, particularly the OS itself, it is necessary to run through many of the OS hardening steps detailed above, as the security settings will be overwritten with the defaults, and deleted applications will reappear.

Using the FreeBSD ports system for adding and removing applications to your system provides a great benefit in addition to being extremely easy to use. The portaudit utility, avialable in security/portaudit, will query a frequently updated XML database of known vulnerabilities in the ports colleciton. So, after installing and running portauidt, a listing of all ports and packages that have known vulnerabilities will be displayed. Also, with portaudit installed, the nightly security report runs a database update and portaudit and includes the results in the security email. I can tell you now that trying to stay up-to-date with ports is a struggle under the best of circumstances, but it is a necessary one. Some of the vulnerabilities are acceptable if there are mitigating circumstances, like being a local exploit only, but very strong hardening has been performed and there are not local users on the machine.

Regularly monitoring logs is another very important step. It is not only good sys-admin practice to review logs, looking for system problems, it will also cue you into to potential or real security incidents. Looking for anything out of the ordinary in the logs, then searching on the appropriate mailing list will often shed light on what you are looking at. It is important to note that ALL hosts that are connected to the Internet are going to be subjected to hundreds, if not thousands of "attacks" per day. These include port scanning, ssh attempts, attempts at relaying spam, and other bad things. While it is important to know that they are happening, unless you are actually compromised, it is almost certain that no one will take any action to stop it - including the ISP of the attacker. The problem has simply grown too large for ISPs to deal with problems individually.

Log files do contain the evidence of bad things happening to a system, but is it tedious to stay on top of the logs. What is very beneficial here is to use some of the applications that exist to extract only the important information out of the logs, and send only those to you. There are a whole host of applications that do this in some fashion found here: http://www.syslog.org/Web_Links+index-req-viewlink-cid-4.phtml One of the easiest to use is called Devialog (http://devialog.sourceforge.net/). Devialog looks at your log files, creates a signature pattern based on them, and lets you edit those signatures to add or exclude things that are or aren't important. Once running, devialog will send anything it doesn't recognize to you. If it is unimportant, you can add it to the signature file pretty easily, which lets you hone in on a system that only sends the really important logs to you.

WHATEVER YOU DO, DO NOT IGNORE THE SYSTEM LOGS. They are there for a purpose. Syslog.org is very dedicated to raising the awareness of logs and log data, as well as ways to look at, parse and use the data that are in those logs.

{Using the periodic security emails}

{Automating hardening activities}

Backup strategies

Hopefully the need to have a good backup strategy is clear. Backup strategies can vary from the basic to the extravagent, and from cheap to very expensive. Certainly there are many options to choose from, and most of the deciding factors are related to your particular situation, like how much data you have to backup, how frequently it needs to be backed up, how long the backups need to be kept and so on.

On very simple and cost effective backup option that I have implemented very successfully uses rsnapshot (www.rsnapshot.org). Rsnapshot is available in the FreeBSD ports collection in sysutils.

Essentially, rsnapshot leverages the differential file copy capabilities of rsync and adds a management layer to it. Rsnapshot lets you maintain a backup set of a collection of files and each time a new collection is created, only the changed files are added. This means that rsnapshot is very efficient with bandwidth and drive space.

My implementation works like this: I have two servers at a colocation facility. Every four hours, each server takes an rsnapshot of the other. This means that if either server were to lose data from corruption, drive failure, or compromise, I lose a maximum of 4 hours worth of data. The last snapshot of the day becomes a one of 7 weekly snapshots, the last weekly snapshot becomes one of 12 monthly snapshots, and so on. That provides a historical backup archive that can be used to compare files with, etc.

The second component of this is that I take a nightly snapshot of both systems back to a system at my house attached to my cable modem. The first snapshot takes a good amount of time and bandwidth (proportional to the amount of data being backed up), but subsequent snapshots take very little bandwidth, related to how many files change in a given day, which for most systems, is not a whole lot.

The system that the snapshots are captured on at my house runs Samba, which I use to export the archive directories to my Windows clients, where I perform a monthly DVD backup. Those DVDs are kept at a safety deposit box. My data is now backed up to 3 different locations, where most "high end" backup strategies have it backed up to one or two at the most. Having the backups archived on a drive also makes restoration very fast indeed.

Reader's note:

This document originally appeared at syslog. All updates will be done to this version.

Below are some links to other FreeBSD security guidelines:

This is a good security implementation guide convering a broad range of topics: people.freebsd.org/~jkb/howto.html

This is a great security guide from DALnet on hardening FreeBSD servers: http://www.dal.net/admin/vote/seceval.php3

Here is a very detailed writeup, with examples, of FreeBSD's MAC (mandatory access control) structure: http://rootshell.be/~bugghy/tutorials/security/mac.txt

http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html

www.daemonnews.org/200108/security-howto.html

http://www.secinf.net/unix_security/FreeBSD_Security_HowTo.html