Most Unix servers determine their port numbers by looking up each port in the /etc/services file using the getservbyname ( ) library call. The /etc/services file can be supplemented or replaced by distributed database systems such as NIS, NIS+, Netinfo, DCE, or an LDAP-based service. Most of these distributed databases patch the system’s getservbyname ( ) function, so the use of the network database is transparent to applications running on most Unix systems.

Some network servers bypass the getservbyname ( ) function and simply hardcode the service number into their programs. Others allow a port number to be specified in a configuration file. Still other servers listen simultaneously to several ports! Thus, if you make a change to a program’s port number in the /etc/services file, the server may or may not change the port to which it is listening. This can result in significant problems if it becomes necessary to change the port used by a service; fortunately, well-known services seldom change their ports.

It’s important to remember that port assignments are standards, but they are not set in stone. Servers can be run on ports that are unassigned or are assigned to other protocols. This is especially problematic for organizations that wish to block some kinds of protocols from leaving their organizations while allowing others through—if you allow the packets for any specific IP port to travel unrestricted from the inside of your organization to the outside, then a malicious insider can effectively use that hole to tunnel any protocol through your defenses.

For example, because the SSL protocol cannot be effectively proxied, many organizations allow TCP connections on port 443 to travel from inside their organization to the outside. This is because attempts to proxy the SSL protocol are effectively man-in-the-middle attacks and are specifically detected by the SSL protocol. In the Spring of 2001, one of the authors had to spend two days at the offices of a major consulting firm. Their firewall was configured to allow packets through on port 443 but not packets on port 22 (SSH). The reason, allegedly, was “security”: the network administrator had made a determination that SSH was too dangerous a protocol to allow from the inside of the organization to the outside. To get around this minor inconvenience, the author simply telephoned a friend and asked him to set up an SSH server running on port 443. A few moments later, the author used the ssh command on his laptop to connect to that remote SSH server. On top of this SSH connection the author tunneled a variety of other protocols, including POP, SMTP, IMAP, HTTP, and X. So much for the restrictive firewall!

Most network analysis tools cannot detect a protocol that is being run on an unexpected port: making this determination requires that each TCP connection be reassembled from the individual IP packets and then analyzed. If the contents are encrypted, even reassembly combined with content analysis may not be sufficient to determine the protocol being used.

Servers that are always running are usually started by the Unix system at startup. Unfortunately, there are many, many different strategies that different Unix systems use for deciding which servers to launch when the system starts. Old versions of Unix launched servers that were listed in a single shell script, /etc/rc. To provide for local customization, the last line of /etc/rc ran a second shell script, /etc/rc.local, if that script was present.

System V-based systems, including Solaris and Linux, have a complex startup system that uses multiple directories and a variety of run levels. Individual servers are started by scripts located in the /etc/init.d/ and /etc/rc n .d/ directories, in which n is the appropriate run level; servers can be enabled by placing executable scripts in these directories. (More specifically, they are placed in the /etc/init.d directory and linked into the run level directory, where they are run in alphabetical order by filename.)

Modern BSD-based systems start up servers that are located in the /usr/local/etc/rc.d/ directory. Some scripts execute the shell scripts /etc/rc.conf and /etc/defaults/rc.conf; these scripts set shell variables that are used by the startup scripts to determine which daemons should be run.

Mac OS X implements yet another startup system, based on startup packages located in the /System/Library/StartupItems directory.

The lines in an /etc/rc file that start up the Simple Mail Transfer Protocol (SMTP) server might look like this:

if [ -f /usr/lib/sendmail -a -f /etc/sendmail/sendmail.cf ]; then
 /usr/lib/sendmail -bd -q1h && (echo -n ' sendmail') > /dev/console
fi

This example checks for the existence of /usr/lib/sendmail and the program’s control file, /etc/sendmail/sendmail.cf. If the two files exist, /etc/rc runs the sendmail program and prints the word sendmail on the system console.

Chapter 12 is what a startup script for sendmail looks like on SuSE Linux, which uses System V-style initialization scripts.

#! /bin/sh
# Copyright (c) 1996-99 SuSE Gmbh Nuernberg, Germany.
#
# Author: Florian La Roche <florian@suse.de>, 1996, 1997
#         Werner Fink <werner@suse.de>, 1996, 1999
#

. /etc/rc.config

test -s /etc/rc.config.d/sendmail.rc.config && \
      . /etc/rc.config.d/sendmail.rc.config

# Determine the base and follow a run-level link name.
base=${0##*/}
link=${base#*[SK][0-9][0-9]}

# Force execution if not called by a run-level directory.
test $link = $base && SMTP=yes
test "$SMTP" = yes || exit 0

# The echo return value for success (defined in /etc/rc.config).
return=$rc_done
case "$1" in
    start)
        echo -n "Initializing SMTP port. (sendmail)"
        startproc /usr/sbin/sendmail -bd -q1h || return=$rc_failed
        echo -e "$return"
        ;;
    stop)
        echo -n "Shutting down SMTP port:"
        killproc -TERM /usr/sbin/sendmail || return=$rc_failed
        echo -e "$return"
        ;;
    restart)
        $0 stop  &&  $0 start  ||  return=$rc_failed
        ;;
    reload)
        echo -n "Reload service sendmail"
        killproc -HUP /usr/sbin/sendmail || return=$rc_failed
        echo -e "$return"
        ;;
status)
        echo -n "Checking for service sendmail: "
        checkproc /usr/sbin/sendmail && echo OK || echo No process
        ;;
    *)
        echo "Usage: $0 {start|stop|status|restart|reload}"
        exit 1
esac

# Inform the caller not only verbosely and set an exit status.
test "$return" = "$rc_done" || exit 1
exit 0

This script is maintained in /etc/init.d/sendmail and symlinked to /etc/rc2.d/S80sendmail and /etc/rc2.d/K20sendmail. During the boot process, when the system enters run level 2, each script in /etc/rc2.d that begins with “S” will be run with the “start” argument. During the shutdown process, scripts beginning with “K” are run with the “stop” argument. On SuSE Linux, the insserv program is used to establish these links automatically.^[133]

No matter how sendmail is started, after the program is running, sendmail will bind to TCP/IP port number 25 and listen for connections.^[134] Each time the sendmail program receives a connection, it uses the fork( ) system call to create a new process to handle that connection. The original sendmail process then continues listening for new connections.