BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


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 24.141.117.39:4472 209.225.2.218: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 209.225.2.218. The httpd responded by choosing to bind port number 4472 to my IP address of 24.141.117.39. The reason why port 4472 did not show up in our grep of /etc/services is because it represents a socket or open connection, not a listening service.

Also from FreeBSD Basics:

Fun with Xorg

Sharing Internet Connections

Building a Desktop Firewall

Using DesktopBSD

Using PC-BSD

If the sockstat output had shown this instead:

LOCAL ADDRESS		FOREIGN ADDRESS
24.141.117.39:80	209.225.2.218:4472

it would indicate that a user on a computer with the IP address of 209.225.2.218 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 inetd:

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 ftp, telnet, biff, ntalk, and tftp protocols. Now let's see what inetd is:

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, 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:

more /etc/inetd.conf

# $FreeBSD: src/etc/inetd.conf,v 1.44.2.3 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:

  1. the name of the daemon, so it can look it up in /etc/services and know which port number to listen on
  2. whether this daemon understands streams of data or datagrams
  3. whether this daemon uses TCP or UDP as its transport
  4. whether inetd should 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
  5. the name of the user account to start the daemon under
  6. the full path to the daemon to start
  7. 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 sockstat command.

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.





Sponsored by: