Sidebar : A Summary of Security Concerns

In general, a system should be as physically secure as necessary, and the system should have only a minimal set of services and privileged programs as are necessary to the system's desired level of operation. The following sections discuss various areas of security concerns in more detail.

Physical System and Console

With physical access to the system, an attacker can give a -s option at the FreeBSD boot prompt and get a single user mode shell with root privilege. To avoid this, if a system is not in a physically secured location (such as in a locked room with access limited to authorized personnel), it is a good idea to mark the console as insecure in /etc/ttys so that the system will require the root password when it enters single-user mode. See the init(8) manual page for details.

If the system is not physically secure, it should not have a floppy disk drive. An attacker can use the FreeBSD boot prompt to boot a rogue kernel or mount the floppy disk as the root partition, thereby avoiding any safeguards in the standard /etc/ttys.

setuid Programs and Daemons

Problems in daemons and setuid programs are often exploited by crackers to gain root privileges on systems. It is wise to prune the daemons and setuid programs on systems to reduce the opportunities for trouble in case a vulnerability in one of these programs is found by a cracker.

Daemons

The idea with daemons is to turn off any that are not needed. Edit /etc/rc.conf and /etc/inetd.conf to turn off unused services. For example, if the rlogin or rsh services are not necessary, one can disable them in /etc/inetd.conf by commenting them out with a # symbol. Likewise, if the lpr line printer daemon is not needed, set the lpd_enable option in rc.conf to "NO".

Another strategy is to replace daemons that are known to have had problems in the past with daemons that provide the same services but were designed with security in mind. For example, while FreeBSD's sendmail daemon is kept in sync with the most current versions available, one could replace it with qmail, which was designed and written entirely with security in mind. qmail is available from http://www.qmail.org/.

setuid Programs

setuid programs are special programs in the system that run with the privilege of the program's owner when any user executes them. For example, the PPP program /usr/sbin/ppp performs some tasks that only root has permission to do, so its setuid bit is set and it is owned by root. As a result, when any user runs PPP, it runs with the security permissions of the root user. See the manual page for chmod(1) for information on the setuid bit and other file permission bits.

setuid programs are a security problem because the programs often contain bugs that allow crackers to misuse them. Supplying user input or a command line argument that overruns the program's stack with malicious code is a common attack on setuid programs. Since the program is running with root privilege, the cracker's code executes with root privilege. The simplest way to review all setuid and setgid programs in the system is to execute the commands:

find / -perm -4000 -print
find / -perm -2000 -print

With help from the system manual pages, identify the setuid and setgid programs that are not needed for system operation and use the command chmod gu-s filename to turn off the setuid and setgid bits of those programs.

Filesystems

On a system where the user's filesystems are separate from the filesystems containing the system executables and device special files, a couple of filesystem options can stop some potential attacks or "back doors". Because one method of gaining root access or leaving a back door to gain root access again later is creating a setuid-root executable or creating a device special file to allow write access to the system's memory, the nosuid and nodev mount options can be used in /etc/fstab for filesystems on which there should be no setuid or device special files. See the mount(8) and fstab(5) manual pages for details.

These options should be used on filesystems on which users can create files. It is a good idea to break apart the directories containing user files, such as /home, /tmp, and /var/tmp, onto separate filesystems from the /usr filesystem so that the nosuid and nodev options may be used on those filesystems.

Device Special Files

Device special files give users direct access to the hardware of the system via names in the filesystem, such as /dev/mem for access to the memory of the system. Access to critical hardware should be strongly restricted. For example, if /dev/mem were readable by everyone, a user's password could be observed by reading the data segment of the login program while it is running.

The file /etc/fbtab specifies a list of devices that should have their ownership changed to that of the user who logs into the console. See the fbtab(5) manual page for details. Devices that one may want to list in this file include /dev/audio* and /dev/console.

Network Protocols

Weaknesses exist in several network services protocols and TCP/IP itself [7, 1]. Here is a brief summary of solutions for network security issues:

• Disabling unneeded network services in the inetd.conf and rc.conf configuration files.

• Filtering packets entering a site's network that have the site's IP network address in the source address. Such packets are obviously forged or originate from an incorrectly configured host.

• Using the TCP wrappers daemon [9] on TCP services started via inetd to prevent IP source routing, verify the source IP address and host name of the remote host, and implement access restrictions based on the source IP address. See the FreeBSD package net/tcp_wrappers-7.4.tgz and its accompanying manual pages for details.

The ssh secure shell package offers remote logins and file transfers that encrypt all data that traverses the network. For this reason alone, ssh is a great replacement for telnet, rlogin, and ftp, especially for remote system administration. Its encryption of all data between the source and destination renders sniffing useless.

The Network File System (NFS) protocol, which shares filesystems between systems via the network, has numerous security issues. If it is used, it is best hidden behind a firewall (note that FreeBSD can act as a packet filtering firewall).

Like NFS, the Network Information Service (NIS, also known as "Yellow Pages") has several security issues. NIS is useful for distributing user account information in a network of UNIX systems. Unlike NFS, NIS does not use a particular set of network ports, so it can't be specifically hidden behind a packet filtering firewall. FreeBSD's NIS uses the configuration file /var/yp/securenets to limit client access to NIS information. Each line in the securenets file is either a comment (denoted by a # symbol as the first character of the line) or a Internet address and network mask pair, like:

172.16.0.0 255.255.0.0
192.168.5.0 255.255.255.0