Simple FreeBSD Security Guide v1
by psygnosis (Last updated 20020305) 

Chapter 1

This document discusses the lockdown procedures of a FreeBSD machine. This document assumes that the end reader has a basic and general knowledge on FreeBSD, file permissions, kernel configuration, man pages, text file editing, basic ssh usage, and basic FreeBSD filesystem layout. This document only discusses basic security hints and tips on a FreeBSD machine. If I have time, I will be discussing more advanced security issues like IPSec, encryption, suid bits, PGP/GPG, OpenSSL, and race condition on my next documentations.

Credits to the FreeBSD Handbook, man pages, and other resources somewhere out there.

System Logs

First, we will be discussing one of the most important areas in security, which is logging. FreeBSD default logging setting might not be useful. Things don't really log to useful places and some users finds it very annoying.

Now we might try to modify /etc/syslog.conf to suit our needs.

auth.* /var/log/auth

This sample logs all auth activities in /var/log/auth. You can view the file to watch over ssh connections (by default ssh logins use the logging facility auth). You may log it on another log file, if you like but don't forget to update your /etc/newsyslog.conf (man syslog.conf and newsyslog.conf for more details).

Note that it is also a good thing to modify /etc/newsyslog.conf to fix some permissions on the log files, especially the logs with world readable permissions. I usually change some log files not really needed to be world readable to 600.

Also take note that console logging might not be a good idea especially for servers or publicly accessible machines as it could lead to compromise of information, maybe console logging is a good idea on workstation and desktops for it to read the informations easily.

Syslog configuration files should not be world readable, the reason in this idea is simple, you do not want to give other people any additional information as it might be able to use it against you. You may change the permissions of these files as readable only by owner.

# chmod 600 /etc/newsyslog.conf
# chmod 600 /etc/syslog.conf

For more info, see the chmod man page.

Also note that you can tell syslogd not to listen to syslog messages from other systems in secure mode, by adding "-s" or "-ss" to your /etc/rc.conf file.

syslogd_flags="-ss"

Also you can make your /etc/rc.conf, readable only by root

# chmod 600 /etc/rc.conf

There are a also a few, more secure alternatives to the standard syslog:

http://www.core-sdi.com/Core-SDI/english/slogging/ssyslog.html 
http://cheops.anu.edu.au/~avalon/nsyslog.html

Filesystem

FreeBSD considers everything as a file, it is important to have a stable filesystem. Protecting a filesystem is a very important to a FreeBSD system, however this process starts before installing the OS itself, you need to calculate your partition layout, the mount points, and others. In a Linux world, you may notice that Linux puts everything under one root "/" partition, and in FreeBSD by default gives "/", "/usr" and "/var". This makes it easy to use programs like dump, and there are several advantages as well. Here are some reasons for using separate filesystems, instead of Linux default-style shoving everything into one filesystem.

• Stability. Critical programs runs on a different filesystem do not get interrupted by a misbehaved program on a different filesystem.
• Speed. Having one file system only is prone to heavy fragmentation, however separate filesystems are less prone to heavy fragmentation.
• Integrity. You can mount different filesystem as nosuid, noexec, nodev, readonly and more.
• Backup. Separate filesystem makes program like dump (a backup program) easier to operate.

For example, you can have this following filesystem layout (as saved in /etc/fstab)

/dev/ad0s1a / ufs rw 1 1
/dev/ad0s1b none swap 0 0
/dev/ad0s1g /var ufs rw,nosuid,nodev 1 2
/dev/ad0s1h /usr/home ufs rw,nosuid,nodev 1 2
/dev/ad0s1i /tmp ufs rw,nosuid,nodev 1 2
/dev/ad0s1j /usr ufs rw,nodev 1 2

You may refer to the mount man page for more info.

Kernel Securelevels

FreeBSD has securelevel settings on it. It may not be so much secure as firewalls, but it can simply stop some avarage script kiddies. Securelevels comes on different levels, it may be raise by root, but only init can lower it. It can be raised using sysctl command.

# sysctl -w kern.securelevel=<level>

The levels of kernel securelevel comes as follows:

• Level -1 ( Permanently insecure mode) : Always run the system in level 0.
• Level 0 (Insecure mode): Immutable and append-only flags may be turned off. All devices has read/write access depending on thier permissions.
• Level 1 (Secure mode): Immutable and append-only flags may be not be turned off. /dev/mem and /dev/kmem may not be opened for writing.
• Level 2 (Highly secure mode): Same as secure mode, plus more, like running newfs is prohibited in multi-user mode.
• Level 3 (Network secure mode): Same as highly secure mode, plus more, like adding, deleting, editing and disabling firewall rules are prohibited.

Take note, that higher securelevel can disable some services. If you are running a web server, you can safely raise the securelevel to 2, however, running X on system with securelevel 1 or 2 can give you some problem because X server needs to open /dev/mem and /dev/kmem for writing.

System Immutable Flags

System immutable flags can be turned on/off via chflags command. However, you cannot turned off system immutable flags if the system securelevel is raised to 1 or higher. Files or directories with system immutable flags can't be modified even by root. To turn on system immutable flags the syntax is:

# chflags schg <file or dir>

To turn off system immutable flags:

# chflags noschg <file or dir>

Also take note that you can view files with system immutable flags using the ls command.

# ls -lo

System immutable flags can stop an average script kiddie from wreaking havoc on your system. This will make harder for someone to backdoor your system with a rootkit. However, this may also cause problems with "make world" in a multi-user environment, anyway it is always recommended to do a "make world" in a single-user environment.

Basic Network Services

Services
Turn off services, you do not really need. You should have a good idea of what services you really need and what you does not really need, if you're in doubt of a certain service, it's better to disable it first, anyway you can always enable it if it is needed.

Telnet 
Telnet are known for it's security flaws, so why would you use telnet if there is a more secure alternative like ssh. To disable telnet, you can edit /etc/inetd.conf and comment (putting # on the line) the telnet

#telnet stream tcp nowait root /usr/libexec/telnetd

and restart inetd

# kill -HUP <pid of inetd>

Also, if you wish, you can make your /etc/inetd.conf, readable only by root

# chmod 600 /etc/inetd.conf

Portmapper
Disable portmap, unless you have a good reason of enabling it (such as NFS and NIS). Many users usually looks for any exploitable rpc. If you really need portmap, it's better to drop destination port 111 at your border router.

To disable portmap:

# kill KILL <pid of portmap> or simply,
# killall portmap

You can also disable launching portmap on startup by editing /etc/rc.conf

portmap_enable="NO"

Sendmail
Disable sendmail, unless you are running a mailserver or a mail gateway, but if you really want a more secure smtp gateway, you may use postfix or qmail.

sendmail_enable="NO"

FTP daemon
Now let's take a look at ftpd (File Transfer Protocol Daemon), FreeBSD can configure ftpd to do some logging (note that ftpd is started with "-l" switch from /etc/inetd.conf). Take note, however, you need to edit /etc/syslog.conf for the syslogd to provide support for the log generated by ftpd.

You may add the following line to /etc/syslog.conf

ftp.* /var/log/ftplog

Don't forget to create the file /var/log/ftplog first since syslogd can't write to a file which isn't created first. Also, don't forget to add the file to which you will log ftp activities to /etc/newsyslog.conf.

If you want to use scp (Secure Copy, scp is a part of the SSH suite), and still want to use anonymous access, you can start your ftpd with "-A" switch. Edit /etc/inetd.conf and modify the line:

ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l -A

See the ftpd manual page for more details on ftpd.

Fingerd
Secure by default, that's what FreeBSD's finger services. It does not allow queries without a username, however to log fingerd activities, you may add the "-l" switch to the file /etc/inetd.conf to enable logging.

finger stream tcp nowait nobody /usr/libexec/fingerd fingerd -s -l

Note that some paranoid people feels not running fingerd at all.

Blackholing

Enable blackholing. By default FreeBSD sends an RST packet when they receive data close ports, they build a new whole packet and send it off. Usually we do not want portscanning on our system be easier, nor we do not want to waste resources on useless DoS attacks so we can take advantage of a feature on FreeBSD called blackholing, in FreeBSD 4.3 and below, tcp blackholing is done by recompiling the kernel with option TCP_RESTRICT_RST and in FreeBSD 4.4 blackholing is simple done by sysctl command.

# sysctl net.inet.tcp.blackhole=1
# sysctl net.inet.udp.blackhole=1

You may enable blackholing every time you boot by editing /etc/sysctl.conf

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

Also you can make your /etc/sysctl.conf, only readable by root

# chmod 600 /etc/sysctl.conf

Blackholing is not really a replacement for packet filters or firewalls, but it simple adds a layer of security on the system.

Packet Filtering

FreeBSD comes with two packet filtering suite, the IPFW and Dareen Reed's IPF, we will be discussing a little on IPFW since it is the default packet filtering tool on FreeBSD. For someone using IPF, its better to download the IPF HOWTO at the following sites:

http://www.obfuscation.org/ipf/  
http://www.unixcircle.com/ipf 
http://www.grunta.com/ipf 

To use IPFW on FreeBSD, you can either compile IPFW support in the kernel or just use the module. I'd recommend compiling it in the kernel anyway.

To compile IPFW in the kernel you need to add the following keyword(s):

options IPFIREWALL # this is required

The following are optional:

options IPFIREWALL_VERBOSE # enable IPFW logging via syslog
options IPFIREWALL_VERBOSE_LIMIT=<value> # limit logging
options IPFIREWALL_DEFAULT_TO_ACCEPT # common sense ;)

Also take note that the option IPFIREWALL_DEFAULT_TO_ACCEPT is not a correct approach to a good firewall configuration. If you are building a secure system or a production firewall, make sure everything is denied first and then add rules to allow packets on a case by case basis.

For a more complete and detailed explanation on IPFW, you can check ipfw man page, /etc/rc.firewall file or check the FreeBSD Handbook on IPFW at

http://www.freebsd.org/handbook/index.html

Dropping Some "Possible Dangerous" Packets

ICMP Redirects
ICMP redirects also needs to be dropped as an added security on the system. ICMP redirects can be used on DoS and hijacks. You can drop ICMP redirect by editing /etc/rc.conf.

icmp_drop_redirect="YES"

Anyway, you can do this in a more flexible way thru packet filtering.

Dropping SYN+FIN
You can also drop SYN+FIN packets. This, however is not recommended on systems running a webserver. This feature requires the option TCP_DROP_SYNFIN to be included in the kernel. To enable this feature, edit /etc/rc.conf and put the line

tcp_drop_synfin="YES"

Also take note that dropping SYN+FIN packets makes tools such as nmap and queso hard to guess the remote operating system.

Filesystem Quota

Quotas has also important duties in security, especially if you are running a shell server. Quotas can protect your system from DoS attacks, like programs generating random data that can fill up the whole user filesystem.

To enable quote, edit /etc/rc.conf and modify the line

check_quotas="NO"
to
check_quotas="YES"

Also make sure to add "userquota" to your /etc/fstab file (see man 5 fstab for details). Take note that if "userquota" are specified in fstab, the filesystem is automatically processed by quotacheck command (see man quotacheck for more info).

You may also enable disk quota on your kernel configuration file

options QUOTA

Secure Shell - A Short Discussion of OpenSSH configuration

In some cases, you do not need inetd services completely, like if you're only running a web or a news server. You might ask "How can I configure my machine remotely without inetd (coz telnet is a part of inetd)?" You can, by using SSH (Secure SHell). Unlike telnet, ssh is more secure. Telnet, rlogin, rsh and other sends everything over the network in clear text, including passwords. The combination of our reliance on the Internet with the prolifiration of script kiddies and other packet sniffing deviants has made administrative clear-text network application obsolete. SSH is a suite of tools that roughly corresponds to telnet, rsh, rcp and rlogin commands, but with one very important difference: paranoia. SSH lets you do everything rsh, rcp, telnet and rlogin do, using high-grade encryption and authentication methods.

The sshd configuration file is /etc/ssh/sshd_config. Theoretically, it's better to uncomment Protocol 2,1 line and change it to read since ssh protocol 1 is not  considered as secure as SSH protocol 2.

Since SSH can take up a lots of memory and it's commonly attacked by DoS, the configuration file has a line called "MaxStartUps", you can always modify the values of it.

MaxStartUps specifies the concurrent unauthenticated connections to the sshd daemon. Random early drop can be enabled by specifying the three colon separated values (start:rate:full), for example:

MaxStartUps 10:30:60

SSHd will refuse connection attempts with a probability of "rate/100" (30%) if there are currently "start" (10) unauthenticated connections. The probability increases linearly and all connections attempts are refused if the number of unauthenticated connection reaches "full" (60).

PasswordAuthentication no

Why no? Simple. Password authentication is not merely secure method regardless of protocols. It can be guessed, enginnered, stoled from other sources or beaten out of an employee. It is strongly suggested to use DSA and RSA keys rather than using static passwords.

X11Forwarding [no/yes]

If you are running a server, you obviously don't need X. Anyway disabling this does not really improve security in any way, as users can always install thier own forwarders. Also, note than X11Forwarding is automatically disabled if UseLogin is enabled.

Also take note, that if your system has lots of accounts on it but most of the accounts should have no shell access in it, you can use the keyword AllowGroups in the configuration file, for example.

AllowGroups wheel

This can be a group or a list of group names separated by commas. If the number of users with shell access is relatively small, you can use the keyword AllowUsers in the configuration file, for example:

AllowUsers psygnosis

This can be a user or users separated by commas. Only usernames are valid, not a numerical user ID.

I know almost all intermediate FreeBSD users know it, if you don't want users to have shell access, you can specify /sbin/nologin as the shell.

For more information, you may consult the sshd man page.

Miscellaneous

Crontab
Cron is a daemon that can execute scheduled commands, so you should be careful in selecting users you'll allow in executing cron. Cron can be used by an end user to setup bots, execute dangerous programs, waste resources and other malicious activities. In the past, users can use crontab (crontab is the program to used to install, deinstall, or list the tables to drive the cron daemon) to gain root access. Many times it is the fault of a badly written script. The users "www", "nobody", and "bind" should be totally denied from creating crontabs.

Create a file /var/cron/allow and put the user list you want to use cron. In most cases, its better to create an exclusive list rather than creating a list of denied users. For more information see the crontab and cron man pages.

Loadable Kernel Modules (LKM)

It is said that Loadable Kernel Modules or LKM's are not recommended on a production system (see Phrack Magazine Volume 7, Issue 51, September 01, 
1997, article 9).

BPF (Berkeley Packet Filter)
BPF is a tool required in performing network sniffing. Some programs like tcpdump and nmap use BPF. However, sniffers also use BPF. Having BPF in the kernel makes sniffing easier on your system. It is recommended not to use BPF if you dont really need it. BPF can be disable by removing the line

pseudo-device bpf

in your kernel configuration file.

Patches and Updates
Bugs may be discovered after you install the OS. Patches are available at:

http://www.freebsd.org/security.html

/etc/hosts.allow file
You can edit your /etc/hosts.allow file to allow only trusted ip address, for example:

ftpd: friendhost : allow
sshd: friendhost : allow
ALL : ALL : deny

General Overview

FreeBSD has a lot of security features on it, like chroot, groups, jails, users, and securelevels. However, we don't use any of it by default because most services are run as root. And even the ones that aren't barely touch even the first layer of security offered by FreeBSD. Each runs as its own user and group but does not bother with anything else.

I think the best approach in security is to simply assume that everything on your networked system can be compromised. We must be aware not only to prevent compromises but also we must learn how to deal in case of system compromise. Here are some basic questions regarding compromises:

What if my network is being sniffed?
Allow only encrypted connections between machines (e.g. SSH), even connections on LAN, if someone has managed to break into it, the amount of  damage they could do would be limited.

Despite of my security efforts, someone has managed to break a user account my webserver is running. What if they want to deface the site?
You can make all the directories and static files owned and writable by some other user and only readable by the webserver.

What if hackers want to steal my currently stored credit card numbers?
Encrypt the credit card numbers anywhere and don't give the webserver access to the decryption key.

What if they break root and want (once again) to steal credit cards?
Don't store the decryption key in that host at all, instead run the decryption code on a different machine entirely (probably a machine that does not have any remote logins in it).

Enough for now, just always remember never to trust any solution to solve all your problems. Remember that even some solutions aren't guaranteed. You might not able to build a security policy without inconvenience of others.

General Security Points

Although there is no such thing as "total secure system", you can always add a layer of security to the system, although you are not guaranteed it can't be compromised, it can make your system harder to get compromised.

Here are some security points:

• Dont run unnecessary services - As the security motto always says "If you don't use it, lose it".
• Use some packet filtering tool - FreeBSD comes with IPFW and Dareen Reed's IPF. These tools can add a layer of security to your system.
• Audit your security setup - You may use sockstat to audit your security setup and to see what ports are exposed.
• Jails - FreeBSD comes with a feature named jail, which allow programs to run as root with only limited access to certain aspects of the system.
• Securelevels - FreeBSD implements a securelevel on the kernel which denies access to some raw devices.
• Logging - make sure you properly setup what to log on.
• Restrict automated remote access
• Use only encrypted login services and disallow all unencrypted login services.
• IPSec - If possible, use encrypted host to host communication.
• Secure your filesystems - You may mount some filesystems nosuid, readonly, etc.
• Backups - The BEST solution in case of compromises.

Suggestions and comments?

If you have any suggestions on how to improve this document, feel free to email me at norbert@feu-nrmf.ph.