Article

Security Tools in FreeBSD

Guy Helmer

This article provides a summary of security features in FreeBSD, a freely available FreeBSD UNIX-like operating system. FreeBSD provides a number of features that can be configured to reduce the risk of compromise. A well-configured FreeBSD system can provide needed services to users while being highly resistant to attacks.

Introduction

Any UNIX system administrator or network manager on a tight budget, but with a need for stable, high-performance network servers is prompted to consider alternatives to conventional commercial operating systems. While FreeBSD and similar systems obviously offer inexpensive alternatives for UNIX-like workstations and servers, their suitability from a security perspective may be less obvious. This article explores FreeBSD's security features with an eye toward assisting you in making a decision about whether it is suitable for your requirements. Before launching into an exploration of FreeBSD, suffice it to say that the relationship of UNIX to Internet security is a massive topic. There are numerous books and other resources that discuss various elements of the subject, some of which are included in the References at the end of this article. In particular, the interested reader is referred to Practical UNIX and Internet Security [4] and Firewalls and Internet Security [3], which are two of many well-known books on this topic.

Related Work

OpenBSD, a close relative of FreeBSD, is being developed with one of its stated goals being to improve the security of the BSD-based operating system. FreeBSD has and will likely continue to incorporate relevant security fixes identified by OpenBSD. OpenBSD information is available online at:

http://www.openbsd.org/.

Road Map

The article will begin by discussing general system issues, most of which apply to nearly any UNIX system but for which FreeBSD provides specific assistance. Items included in the system discussion are physical system security, privileged programs, and filesystems. Next, network issues will be covered, with emphasis on weaknesses of particular protocols, reasons for avoiding certain network services, and solutions to known problems. The last half of the article concentrates on security features available on FreeBSD but not always provided by other UNIX systems. These features include system security levels, IP packet filtering, one-time passwords, and controlling remote access to user accounts.

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 privileges programs that 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 of a FreeBSD system 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. If the system is in an extremely unsecure area, such as an unsupervised university lab, the system case should be locked shut. Some system cases even offer a tab (albeit flimsy and probably easily cut) through which a padlock and perhaps a security cable can be attached.

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 whose code was 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

Using the generated list of setuid and setgid files, determine which of the programs are not necessary for system operation and use the command chmod gu-s filename to turn off the setuid and setgid bits of the unnecessary setuid/setgid programs. A list of common setuid and setgid commands and their uses are given in Figures 1 and 2.

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". 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. The nosuid and nodev options are especially important on filesystems that are NFS-mounted from an untrusted system. A rogue user on the other system could create a setuid-root executable or a /dev/kmem-equivalent device special file on the server's filesystem, then use that file on the client to gain root privileges. The noexec option may also be useful on a filesystem mounted from an untrusted server.

Monitoring the File System

Some system attacks are carried out through the UNIX filesystem, usually by abusing daemons or setuid programs. Typically these attacks create or change configuration files, such as user's .rhosts files, that then allow a cracker further access to a system. These attacks are typically prevented by closing holes in daemons and setuid programs, but the holes must first be found. Thus, it's good to either reduce the usefulness of these attacks or monitor the system for problems.

File System Monitoring

FreeBSD sends a daily security report to the root user every day. It checks for new or changed setuid programs or device special files. If new setuid programs appear, the time or size of setuid programs mysteriously changes, or new UID 0 (root-equivalent) users appear, it's probably time for further investigation. But, if a system is thoroughly cracked, the reports will not indicate any problems because the security script and its data files are vulnerable to tampering. Only tripwire (see below), when correctly installed and used, can reliably detect system compromise. Unfortunately, due to the way the system is scanned for setuid programs, it is possible for the whitespace in the list of setuid programs to change, causing an occasional false alarm in the "setuid files and devices" section of the security report. Before you become too alarmed when a long list of "changed" setuid files appear in this report, you should doublecheck whether the messages are just due to changes in the whitespace in the list of files.

Advanced Monitoring with tripwire

tripwire is an add-on package that monitors the filesystem for changes in files and permissions. The installation instructions provided with tripwire provide an excellent overview of the package and the correct installation procedure.

Essentially, tripwire should be installed and initialized on a pristine system (so that there is no chance that the system could have already been compromised before the tripwire installation). The tripwire executable file, linked as a static executable to avoid using the systems shared libraries, and its database file, which contains the digital signatures that verify the integrity of the files on the system, should be written to media that can be physically set read-only. Then, when tripwire is used to verify the integrity of the filesystem, it should be invoked directly from its executable on the read-only media. In sample installations by the author, the tripwire executable and database for each system was kept on a 3.5-inch floppy diskette on which the read-only tab was set to prevent modification. The author used tripwire for years and detected occasional anomalies that would have otherwise gone unnoticed. tripwire is available as a port on FreeBSD as security/tripwire.

rhosts and hosts.equiv

If the remote shell (shell) or remote login (login) network services are enabled in /etc/inetd.conf on a system, the files /etc/hosts.equiv and .rhosts are important for security. hosts.equiv defines which systems have users who are trusted to use any matching account without requiring a password. Each user's $HOME/.rhosts defines the remote systems and the users who may use that account without giving a password. See the man page hosts.equiv(5) for the particulars, but essentially no system's name should be listed in these files unless that host and the networks between them are truly trustworthy.

Note that if the line + + appears in these files, the system is completely unsecure - any user on any other system can login to that system without a password unless the shell and login services are disabled. It has been reported on the BUGTRAQ mail list that crackers often leave a + + in a .rhosts file, which would allow the cracker back into that account from any other host.

A form of attack may be executed where an intruder uses a vulnerability, typically in a system daemon or setuid program, to create a .rhosts file in a user's directory or append data to an existing .rhosts file. This attack seems to be less frequent since improvements have been made in the checks for ownership and permissions of the .rhosts file that rlogin and rsh make before they allow access. However, these attacks are still possible.

One method to completely eliminate the problem is to turn off the rlogin and rsh services by commenting out or removing the login and shell service lines in /etc/inetd.conf. However, turning off these services often is not an option. For example, the shell protocol is used for other services, such as rdump remote backups.

An often more acceptable method of limiting exposure is to limit the systems to which rlogin and rsh are allowed. This limitation is often implemented by installing the TCP wrappers daemon [8] by Weitse Venema. See the FreeBSD package net/tcp_wrappers-7.4.tgz and its accompanying manual pages for details.

Another solution is to add the -l option to the rlogind and rshd services in the appropriate /etc/inetd.conf entries to prevent authentication using any .rhosts file other than root's.

A last option in the rlogin and rsh area is to monitor the filesystem for .rhosts files that contain odd entries. However, this can be too little too late if an intrusion has already occurred.

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.

An attack via device special files can be mounted by using a vulnerability in a daemon or setuid program to create a /dev/kmem-equivalent device, and then writing into the kernel via the newly created device to increase the privilege level of the intruder's shell. If the device special files are not properly protected, the intruder's task of raising her privilege is even easier.

The device special files are given good default protection during an installation of FreeBSD, but one should verify that the permissions of these important files are set properly. Some of the device special files of particular interest are shown in Figure 3.

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 [6, 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 [8] 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.
If possible, using a Kerberos authentication server [7] and Kerberos-enabled versions of rlogin and rsh for strong authentication and secrecy.

The ssh secure shell package offers remote logins and file transfers that encrypt all data traversing 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). If NFS is used in a hostile environment (e.g., connected to the Internet without the benefit of a packet filtering router or firewall), the command fsirand(8) should be used to randomize the inode numbers of files and thus make guessing NFS file handle numbers more difficult for attackers. See the manual page for usage information on fsirand - it can't be used on mounted filesystems.

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 an Internet address and network mask pair. For example:

172.16.0.0 255.255.0.0
192.168.5.0 255.255.255.0

Features of FreeBSD and Relatives

FreeBSD offers several features not usually found in stock UNIX-like systems. Some of these features are common to other BSD-derived systems (NetBSD and OpenBSD) or Linux, so one may wish to consult the system's documentation to see whether these features are available.

System Security Levels

UNIX system security has suffered from the all-powerful access given to the root-privileged user. Once a cracker obtains root privileges, the entire system becomes vulnerable to the cracker. The 4.4BSD-derived systems offer a new security feature called "system security levels" (see the man page for init(8) for details on these security levels). Raised system security levels prevent certain actions on a system irrespective of a user's privilege. Used properly, this can prevent an assortment of system compromises, including the introduction of Trojan horses and back doors into system binaries and modification of configuration files.

System security levels are: -1, permanently unsecure mode; 0, unsecure mode - no additional protections enabled; 1, secure mode - files may be protected from modification and memory device special files may not be opened for writing; 2, highly secure mode - protection of level 1 plus disk devices may not be opened for writing; 3, extended secure mode - protection of level 2 plus the IP packet filter list may not be changed. The default system security level of -1 is called "permanently unsecure mode" because init(8) will not automatically raise the level to 1 when the system goes into multiuser mode as it would if the security level were 0. Raising the security level above 0 causes the kernel to disallow all of these operations:

Removal of the immutable and append-only flags on files
Direct writes to disk devices that are mounted at security level 1, or direct writes
to all disk devices at security levels higher than 1
Writes to the /dev/mem and /dev/kmem device special files
Changes to any file whose immutable flag is set
Loading any loadable kernel module
Changes to the IP packet filter lists (at security levels greater than 2)

When a FreeBSD system is installed by using a make world on the source code, a number of system files are installed with the immutable flag. In general, executable files that are setuid root are installed with the immutable flag. Note that systems installed via sysinstall (e.g., installed via the network or from CD-ROM) do not have the immutable flag set on any files by the installation program.

At any time, the schg flag may be set on files with chflags, but the flag can only be cleared when the system is at security level \0001 or 0. During multiuser operation, the system security level may only be raised. The command to raise the security level to level 1 is:

sysctl -w kern.securelevel 1

The system security level can be raised automatically at system startup by including the above sysctl command in the system's /etc/rc.local file (and /etc/rc.local should then have its schg flag set as well). Raising the security level will limit file management activities, so you may not wish to use this feature on frequently changing systems. Once the security level has been raised, the only way to lower the security level is to restart the system. If you need to perform maintenance on the system, it can be booted into single user mode where the security level will be its default of -1.

IP Firewall

Several TCP/IP protocols included with FreeBSD, such as NFS and NIS, may be more secure if they are unaccessible from outside the trusted part of the network. For protocols that may not be restricted any other way, a packet filter that allows only designated protocols can be used to block external access.

FreeBSD's kernel option IPFIREWALL enables IP firewalling, which applies filter rules to IP packets entering or exiting the machine. When a kernel built with the IPFIREWALL option starts, its default action is to drop every IP packet. Additional filter rules must be given to a system to allow it to accept and output desired IP packets. The startup script /etc/rc.firewall provides sample filters that will have to be modified before they can be used. The sample filter types are selected by the firewall option in rc.conf, which include:

open - No limitations on any protocols; any IP packet may enter or exit any interface.

client - Protects a system which is a client on a network. Given the client system's network number, subnet mask, and IP address, a basic filter is setup to allow all traffic originating from or destined for the local network, allow packets for any established TCP connection, allow incoming email and any outgoing TCP connection, and allow Domain Name Service and Network Time Protocol UDP packets (everything else is denied).

simple - Setup a simple packet filter on a system that routes between networks, which is suitable for a simple FreeBSD router with two network interfaces. Given the network numbers, subnet masks, and IP addresses of the external ("unsafe") network and internal ("safe") network, this option in rc.firewall creates a packet filter that:

Prevents outside packets with a source IP address of the internal network from entering, and likewise prevents packets from going outside unless they have a source address of the internal network (to prevent spoofing)
Allows all packets for established TCP sessions
Allows TCP connections for incoming email, Domain Name Service, and World Wide Web requests
Rejects and logs all attempts to connect to TCP services other than those allowed above
Allows all Domain Name Service and Network Time Protocol UDP requests and responses
Denies anything not explicitly allowed

If the system security level is above 2, changes are not allowed to the packet filter list. This allows a system administrator to prevent modifications to the packet filter list in the event of a system compromise, much like the raised security level can prevent modifications to parts of the filesystem.

The IP firewall option can assist in monitoring attempted attacks on a system. The kernel option IPFIREWALL_VERBOSE enables logging of packet filtering messages via syslogd(8). The logged information can be useful in spotting port scanning or break-in attempts.

One-Time Passwords

Password sniffing has plagued the Internet for some time [2]. Users logging into telnet or ftp across the Internet may be well advised to use one-time passwords for logins from remote sites to avoid having their reusable password captured and abused by crackers.

FreeBSD uses the S/Key software [5] to provide one-time passwords. Users can set up one-time passwords on a FreeBSD system by using the command:

keyinit

which will ask for a private password that only the user knows. This password probably should be different from the regular system login password, but doesn't have to be. Then keyinit will show something like:

ID fred s/key is 99 sp99609
BUY OUR BOLD LEER YOKE COW

The user can then generate a series of one-time passwords to take on her travels by using the command:

key -n 10 98 sp99609

which will ask for the user's private password used in the keyinit step above and generate the one-time passwords for the next 10 logins (98 down to 89). The user can print these passwords and take them along for her next remote logins over the Internet. (Of course, the printed password list poses other security concerns.)

A FreeBSD system can require the use of S/Key passwords for logins from all sites other than local systems. The file /etc/skey.access (see the skey.access(5) manual page for complete information about this file) defines where S/Key passwords must be used. For example, if the administrator trusts the systems in his own network (numbered 172.16), but wanted users to always use S/Key one-time passwords for logins from other sites, he could use a /etc/skey.access file like this:

permit 172.16.0.0 255.255.0.0
deny

Note that /etc/skey.access does not affect all remote access methods, just telnet, ftp, and rlogin. For example, ssh, pop daemons, and imap daemons ignore S/Key restrictions.

Disallowing Logins

If a password is disclosed in any way to a cracker, that cracker may access the compromised user's account via protocols such as telnet and ftp. This may lead to further compromise of the site's system and network on which the account resides.

An administrator can completely restrict telnet and ftp access for particular users and sites by adjusting the /etc/login.access file. This option can reduce the usefulness of compromised passwords by limiting the sites from which a system can be abused (see the login.access(5) manual page for details on this file).

Note that login.access does not affect all remote access methods, just telnet, ftp, and rlogin. For example, ssh, pop daemons, and imap daemons ignore the restrictions in login.access.

For example, if an administrator wanted to allow logins for all accounts to his or her system from two networks, 172.16 and 192.168.32, and allow all users in the group wheel to also login from the system with IP address 192.168.2.2, this /etc/login.access file could be used:

+:ALL:172.16.
+:ALL:192.168.32.
+:wheel:192.168.2.2
-:ALL:ALL

Conclusion

Thanks to its development team and support from related developers, FreeBSD is a solid system that can be configured to stand up to security attacks. While the default installation is still fairly open and friendly to users, FreeBSD provides many security mechanisms and several add-on packages can improve a system's resistance. These security improvements can ensure the operation and availability of the system, as well as the confidentially of the information it contains.

Acknowledgments

Thanks to Adam Shostack, Falko Dressler, Robert N. Watson, and other reviewers for significant comments on previous versions of an unpublished article on which this article was based.

Thanks to the FreeBSD core team and all of the FreeBSD contributors who have made FreeBSD an excellently performing, extremely stable operating system. Thanks also to the developers who produce security fixes, usually within days after security issues are found. (Online FreeBSD security support includes ftp://ftp.freebsd.org/pub/FreeBSD/CERT/ for advisories and patches, and the mail list freebsd-security@freebsd.org. The mailing list archives are available and can be searched at http://www.freebsd.org/search.html.)

References

[1] Steven M. Bellovin. Security problems in the TCP/IP protocol suite. Computer Communications Review, 19(2), April 1989.

[2] CERT Advisory 94.01: Ongoing network monitoring attacks. [Online] ftp://info.cert.org/pub/cert_advisories/CA-94:01.network.monitoring.attacks, August 17 1997.

[3] Bill Cheswick and Steve Bellovin. Firewalls and Internet Security: Repelling the Wily Hacker. Addison-Wesley, 1994.

[4] Simson Garfinkel and Eugene H. Spafford. Practical UNIX and Internet Security. O'Reilly & Associates, Inc., Sebastapol, California, 1996. Second Edition.

[5] Neil M. Haller. The S/KEY one-time password system. In Proceedings of the Internet Society Symposium on Network and Distributed System Security, San Diego, CA, February 1994.

[6] Robert T. Morris. A weakness in the 4.2BSD UNIX TCP/IP software. Science of Computer Programming, February 25 1985.

[7] Jennifer G. Steiner, B. Clifford Neuman, and Jeffrey I. Schiller. Kerberos: An authentication service for open network systems. In Proceedings of the Winter 1988 Usenix Conference, February 1988. (Version 4).

[8] Wietse Venema. TCP wrapper: Network monitoring, access control, and booby traps. In Proceedings of the UNIX Security III Symposium. USENIX, September 1992.

About the Author

Guy Helmer is a graduate student in Computer Science at Iowa State University, concentrating on security in operating systems and networks. Previously, Guy was a system programmer and network engineer for a university, where he engineered local and wide area networks and administered UNIX servers, including several FreeBSD servers. Guy has been a beta tester and occasional contributor for the FreeBSD Project since its inception.