Understanding BSD Daemons
Pages: 1, 2
TCP/IP applications actually have a choice of two transports, or the protocols used to "transport" the data between the server and the client. If an application uses the TCP transport, a logical connection is first created between the client and the server; once this connection has been established, "streams" of data can flow between the server and the client. If an application uses the UDP transport, no connection is created; instead the client sends out a "datagram" of information in the hopes that it is received by the server.
To create the necessary connection, TCP uses a mechanism known as the "three-way handshake," as three packets are required to fully establish the connection. The first packet is sent out by the client and indicates which port number or application it wishes to make a connection with. The second packet is sent out by the server and includes the socket. Since the server needs to keep the original port number open so it can continue to listen for requests from other clients, it will choose a random, high port number not being used by any other daemon. It will "bind" the IP address of the client to that port number to create the socket. The IP address of the client is important, as a daemon may actually be responding to several clients at a time; for example, an FTP server may have many clients logged in simultaneously and needs to ensure that it is sending the correct data to the correct client. Finally, the third packet is sent by the client; it contains information confirming that it knows what socket it is bound to and states that it is ready for data transfer to occur.
Returning to our example:
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
genisis navigato 3758 20 tcp4 220.127.116.11:4472 18.104.22.168:80
The user genisis used Netscape Navigator (an HTTP client) to access the httpd or web server running on port 80 of a computer with the IP address of 22.214.171.124. The httpd responded by choosing to bind port number 4472 to my IP address of 126.96.36.199. The reason why port 4472 did not show up in our
/etc/services is because it represents a socket or open connection, not a listening service.
Also from FreeBSD Basics:
If the sockstat output had shown this instead:
LOCAL ADDRESS FOREIGN ADDRESS 188.8.131.52:80 184.108.40.206:4472
it would indicate that a user on a computer with the IP address of 220.127.116.11 had made a connection to my web server using port 80. To summarize, if a port number in the LOCAL ADDRESS column is found in the
/etc/services file, it either represents a daemon on your computer listening for requests or it will be bound to the IP address of a client that has already established a connection with one of your daemons. If a port number used in a socket under the LOCAL ADDRESS column does not appear in
/etc/services, it means that your computer used a client application to connect to another computer running TCP/IP.
The last thing I'd like you to notice in the
sockstat output are the lines that mention
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS root inetd 172 4 tcp4 *:21 *:* root inetd 172 5 tcp4 *:23 *:* root inetd 172 6 udp4 *:512 *:* root inetd 172 7 udp4 *:518 *:* root inetd 172 8 udp4 *:69 *:*
You'll notice that this one command has one PID, but it is actually listening on five different ports. Let's
grep /etc/services to see what applications those ports represent:
cat /etc/services | grep -w 21 ftp 21/tcp #File Transfer [Control] ftp 21/udp #File Transfer [Control] cat /etc/services | grep -w 23 telnet 23/tcp telnet 23/udp cat /etc/services | grep -w 512 aed-512 149/tcp #AED 512 Emulation Service aed-512 149/udp #AED 512 Emulation Service exec 512/tcp #remote process execution; biff 512/udp comsat #used by mail system to notify users cat /etc/services | grep -w 518 ntalk 518/tcp ntalk 518/udp cat /etc/services | grep -w 69 tftp 69/tcp #Trivial File Transfer tftp 69/udp #Trivial File Transfer
It looks like this one daemon is listening on behalf of the
tftp protocols. Now let's see what
whatis inetd inetd.conf(5), inetd(5) - internet super-server
Looks like it is the internet super-server and that it has its own configuration file. The
inet daemon was created to save resources on Unix systems. Rather than creating processes for daemons that may not be used that often, this one daemon will listen on behalf of other daemons. If a client requests a connection on a port that is monitored by
inetd will start a process for the daemon normally associated with that port so it can respond to the client's request. The configuration file tells inetd which ports to listen on; for example, if you don't want your FreeBSD computer to accept FTP connection requests, you need to tell
inetd not to listen on port 21 on behalf of the FTP daemon.
Let's take a look at
inetd's configuration file:
ls -l /etc/inetd.conf -rw-r--r-- 1 root wheel 4859 Jan 9 09:34 /etc/inetd.conf
It looks like anyone can read this file, but only the superuser can edit it. Let's take a look at the top few lines of this file; I've snipped the output of my "more" command:
# $FreeBSD: src/etc/inetd.conf,v 18.104.22.168 2000/10/04 07:58:51 kris Exp $
# Internet server configuration database
# @(#)inetd.conf 5.4 (Berkeley) 6/30/90
ftp stream tcp nowait root /usr/libexec/ftpd ftpd -l
telnet stream tcp nowait root /usr/libexec/telnetd telnetd
#shell stream tcp nowait root /usr/libexec/rshd rshd
#login stream tcp nowait root /usr/libexec/rlogind rlogind
#finger stream tcp nowait/3/10 nobody /usr/libexec/fingerd fingerd -s
#exec stream tcp nowait root /usr/libexec/rexecd rexecd
#uucpd stream tcp nowait root /usr/libexec/uucpd uucpd
#nntp stream tcp nowait usenet /usr/libexec/nntpd nntpd
# run comsat as root to be able to print partial mailbox contents w/ biff,
# or use the safer tty:tty to just print that new mail has been received.
comsat dgram udp wait tty:tty /usr/libexec/comsat comsat
ntalk dgram udp wait tty:tty /usr/libexec/ntalkd ntalkd
tftp dgram udp wait nobody /usr/libexec/tftpd tftpd /tftpboot
#bootps dgram udp wait root /usr/libexec/bootpd bootpd
You'll notice that this file contains a line for every daemon that
inetd can listen on behalf of. If a line begins with the comment character
inetd will not listen on the port associated with that daemon. For the lines that have not been commented out,
inetd needs the following information in this order:
- the name of the daemon, so it can look it up in
/etc/servicesand know which port number to listen on
- whether this daemon understands streams of data or datagrams
- whether this daemon uses TCP or UDP as its transport
inetdshould wait for the daemon to finish transferring data to the client or not bother waiting before listening for more client requests on the port number
- the name of the user account to start the daemon under
- the full path to the daemon to start
- any arguments that need to be passed to the daemon when starting it
Notice that in my
/etc/inetd.conf file, there are five lines that have not been commented out. Not surprisingly, these lines are for the five services that showed up under
inetd's PID in the output of my
Next week, let's take a closer look at
inetd's configuration file and see how it is integrated into the TCP wrappers program.
Dru Lavigne is a network and systems administrator, IT instructor, author and international speaker. She has over a decade of experience administering and teaching Netware, Microsoft, Cisco, Checkpoint, SCO, Solaris, Linux, and BSD systems. A prolific author, she pens the popular FreeBSD Basics column for O'Reilly and is author of BSD Hacks and The Best of FreeBSD Basics.
Read more FreeBSD Basics columns.