Installing and Modifying Services (Building Internet Firewalls, 2nd Edition)

11.4. Installing and Modifying Services

Some of the services you want to provide may not be provided with your operating system (for example, web servers generally are not). Others may be provided in versions that are inappropriate for use in a secure environment or that are missing features you probably want (for example, stock fingerd and ftpd ). Even those few remaining services that are provided, secure, and up to date in your vendor's operating system release should be protected with the TCP Wrapper package or the netacl program from TIS FWTK to improve security and provide logging. (Although TCP Wrapper and netacl will increase security, they're not perfect; they rely on the source IP address to identify hosts, and IP addresses can be forged.)

For detailed information about individual services, including advice on selecting HTTP, NNTP, and FTP servers, see the chapters in Part III, "Internet Services".

Whatever services you do leave enabled should also be protected to the extent possible by the TCP Wrapper package or the netacl program, as we describe in the following sections. For example, you might want to set up your bastion host so that it accepts Telnet connections from only one specific machine, such as the workstation you normally use.

11.4.1. Using the TCP Wrapper Package to Protect Services

The TCP Wrapper package, written by Wietse Venema, monitors incoming network traffic and controls network activity. It is a simple but very effective piece of publicly available software set up to run whenever certain ports (corresponding to certain services) are connected. TCP Wrapper provides simple access control list protection, as well as improved logging, for services that are started by inetd.

Using the TCP Wrapper package is easy. Here's what you do:

Install the package and set up a pair of simple access control files that define which hosts and networks are allowed to access which services.

Reconfigure your inetd to run the main TCP Wrapper program (called tcpd ) instead of the "real" server.
When a request for a service comes in, inetd starts tcpd, which evaluates the request against the TCP Wrapper configuration files. This program decides whether or not to log the request, and whether or not to carry out the request.
If tcpd decides that the request is acceptable, it starts the "real" server to process the request.

11.4.1.1. TCP Wrapper example

For example, if you want to allow Telnet connections from a specific host (e.g., 172.16.1.2) to your machine, but deny Telnet connections from all other hosts, you would change the line for telnetd in your /etc/inetd.conf file to say something like:

telnet stream tcp nowait root /usr/local/libexec/tcpd telnetd

You would also need to create an /etc/hosts.allow file that tells the TCP Wrapper package (the tcpd program) which host to allow connections from:

telnetd : 172.16.1.2

And finally, you'd need to create an /etc/hosts.deny file to tell the TCP Wrapper package to deny all connections from all hosts by default, and to send email to root about each probe:

ALL : ALL : (/usr/local/etc/safe_finger -l @%h | \ 
    /usr/ucb/Mail -s "PROBE %d from %c" root)&

Note that the /etc/hosts.deny file only applies to services protected by the TCP Wrapper package (that is, services for which you've configured inetd to run tcpd instead of the real server). If you don't tell inetd to run the TCP Wrapper package (the tcpd program) for a given service, then the TCP Wrapper package won't do anything regarding that service.

Despite its name, the TCP Wrapper package supports UDP-based services in addition to TCP-based services. Be aware, however, that the TCP Wrapper package can only control when to start UDP-based servers; it cannot control access to those servers once they're started, and many UDP-based servers are designed to process requests for some period of time beyond the initial startup request. Many eventually time out and exit, but once they've been started through a legitimate request, they're vulnerable to illegitimate requests.

In addition, TCP Wrapper relies on the source IP address for authentication. It is relatively difficult to spoof source IP addresses when TCP is used, because the connection setup process requires a dialog between the source and the destination. It is much easier to spoof source IP addresses when using UDP, so TCP Wrapper provides less protection.

11.4.1.2. Using netacl to protect services

The netacl component of TIS FWTK (described in some detail in Chapter 9, "Proxy Systems") provides much the same capability as the TCP Wrapper package. To implement the same example as the one shown in the previous section (except for the ability to trace probes from unauthorized systems) using netacl, you would change the line for telnetd in your /etc/inetd.conf file to:

telnet stream tcp nowait root /usr/local/lib/netacl telnetd

Then, you would add the following lines to your FWTK netperm configuration file (wherever that is on your system):

netacl-telnetd: permit-hosts 172.16.1.2 -exec /usr/libexec/telnetd

11.4.2. Evaluating and Configuring Unix Services

If you need to install a new service on a bastion host, you will want to secure it as much as possible. You should not assume that services are safe; reputable software companies often ship unsafe packages, and in many cases, their worst problems are easy to find and repair.

Install a test copy of the service on a machine that is otherwise stable and will not change while you are doing the installation. Use find to identify all the files that were changed during the installation, and check to make sure that those files are acceptable. In particular:

Make sure that file permissions are as restrictive as possible; arbitrary users shouldn't be able to write to any executables, configuration files, or temporary directories. If possible, limit read and execute permissions as well.

Closely check all programs that have the setuid bit set, particularly if they are setuid to root. If they can run without setuid, or if it is at all possible to avoid running them, remove setuid permissions.

If the program installs a user account, make sure that the password is set to something other than the program's default. If possible, change the account name to something other than the program's default; attackers will often focus on well-known account names.

Make sure that all programs are run by users with appropriate permissions. Do not run services as root unless they need to be run as root (for instance, to use ports below 1024). If you must run services as root, try to run them under chroot to control what they can access.

If you add special user accounts for services, make sure that they cannot be used as normal login accounts; both the password and shell entries should be invalid, so that attackers cannot use the accounts as entry points.

Check any additions the program has made to startup files or crontab files.