Digital Elephant
Boundary Services
A variety of network-related services may be offered at a protection barrier. These are generally useful to requestors outside the protection fence, who have legitimate communication needs with systems that are otherwise protected from outside contact.
E-mail -- port 25, TCP
Many boundary systems run the sendmail daemon to accept and deliver e-mail across the boundary. If this daemon runs on a machine with one port on the public side and one port on the private side, it can handle e-mail transfer very efficiently. Unfortunately, this makes it a prime target for hackers as well, so considerable attention has to go into making sure that the sendmail daemon is correctly configured and remains uncorrupted. In such a configuration, a good choice is to install SpamAssassin as a filter for the multitude of unsolicited commercial e-mail (aka SPAM)
An alternate mail transport daemon is Postfix, a modular collection of programs that was designed for reliability and security from the ground up, and which can be configured perhaps with a shorter learning curve than sendmail.
Web Service (HTTP) -- port 80, TCP (HTTPS) -- port 443, TCP
The most popular HTTP server is the Apache system. This daemon provides web pages to all requestors, and can be configured in quite a number of ways. It knows about both the HTTP and HTTPS protocols, and so can offer secure web service as well as normal, unprotected service; it can authenticate users who try to gain access to privileged areas; and it can be configured to support multiple websites (also known as Virtual Hosts) using HTTP. A cart-before-horse problem restricts HTTPS access to a single website per IP address.
Domain Name Service -- port 53, UDP and TCP
Two different kinds of service may be provided by DNS daemons: first, if you manage a domain, the named daemon will provide authoritative data to any requestor anywhere in the Internet about your domain. Second, named will assist a subsystem called resolv resolve requests on behalf of your protected machines by contacting other parts of the DNS to get authoritative data about other domains.
DNS does not deal gracefully with Private Networking unless special arrangements are made, since Private Network addresses are, by definition, not available to any requestor on the Internet. For one way of setting things up so that local machines can take advantage of DNS without exposing their addresses on the public Internet, see Private DNS Services.
Network Time Service -- port 123, UDP
Many parts of the service daemons depend on knowing what the correct time is, at least approximately. David Mills, at the University of Delaware, has made a career out of designing and promulgating schemes to allow any machine on the Internet to make corrections to its own clock so that it will agree fairly closely with clocks elsewhere in the network. His ntpd daemon takes care of this chore.
FTP Service -- port 21, TCP
Sometimes, nothing else will handle the job, and you will be forced to use the File Transfer Protocol to move data from one machine to another. After sendmail, FTP is the second favorite target of hackers, since a large number of holes have been discovered in various implementations of this protocol. If you can get a version that has these holes repaired, then setting up file transfer service is not too difficult. But it seems like a good idea to be fairly wary of it, because the daemon that accepts an arbitrary file and stores it on one of your trusted machines is a very tempting target.
Secure Shell Service -- port 22, TCP
It is considered a serious gaffe to permit unprotected Telnet connections to a boundary machine from the public Internet, because the Telnet protocol passes passwords in the clear, where they may be intercepted by anyone with a decent packet sniffer (tcpdump for instance). When shell access to protected systems from outside the firewall is desired, the Secure Shell protocol is indicated instead. This protocol negotiates a session key for encryption of the stream, and then encrypts all further communication, including the user name and password used to log onto the target machine.
BOOTP and DHCP -- port 67, 68, UDP
The primary use of BOOTP these days is by the Dynamic Host Configuration Protocol (DHCP) service. DHCP service allows machines connected to a common network to acquire network addresses without preconfiguration; this is the essence of network plug-and-play. It is how wireless networks in coffee shops work, and how many network operators deal with the constantly shifting population of devices that require network addresses. Since all the communication occurs using the IP broadcast address 255.255.255.255, two ports are needed to distinguish between messages originating from clients and messages originating from one or more DHCP servers.
A client starts out without an IP address, which makes communication difficult, but not impossible. It broadcasts a request asking for an address on UDP port 67, and gets a broadcast reply offering an address lease (which will expire eventually) on port 68. The client confirms its receipt by broadcasting another message on UDP port 67 (so that, if more than one DHCP server is listening, it can know that its offer was declined). The successful offering server then broadcasts an acknowledgment, and the dance is complete.