Understanding BSD Daemons
01/31/2001In the last few articles, we've looked at creating users and password policies. Password policies are just one layer in the many-layered approach needed to create a secure computing environment that protects both users and resources.
If you recall from the article on the System Startup Daemon init, there are three types of terminals on your FreeBSD system, as there are three different ways of accessing a computer running FreeBSD.
The first method is to physically walk up to a FreeBSD box and type in a username and password at a login prompt. The second is to dial into a FreeBSD system using a dial-up modem and a phone number. The third is to access the FreeBSD system over a network connection using an IP address.
In the next few articles, I'd like to concentrate on network connections. Since FreeBSD uses TCP/IP as its networking protocol, let's start by reviewing the basics of TCP/IP. You may want to take a few moments to skim over the article Networking with TCP/IP to remind yourself how TCP/IP ports and IPV4 addresses work.
TCP/IP applications always have 2 components: the server component, also called the daemon, "listens" for connection requests; the client component "initiates" connection requests. In order for two computers to share data using a TCP/IP application, one computer must use the client component and the other computer must provide the server component. Let's take a look at the snipped output of the following command:
apropos ftp
ftp(1), pftp(1), gate-ftp(1) - ARPANET file transfer program
ftpd(8) - Internet File Transfer Protocol server
Notice the two results for ftp: ftp(1) is the client portion while ftpd(8) is the server portion of the ftp application protocol. Often you'll see the letter d after an application name; the d represents the daemon so you know that it is the server component. If you read the manpage for ftp, you'll learn how to use the FTP client to transfer files to and from a remote site. However, if you read the manpage for ftpd, you'll learn how to configure server issues such as welcome screens, authentication methods, and logging.
In order for users to connect to your FreeBSD system over a network, they need to have the client component of the application they wish to use, and the matching server component must be listening for requests on your computer. For example, a user can use a telnet client to connect to your telnet daemon. However, if your telnet daemon is not listening for requests, a connection can not be created and the user will instead receive an error message.
It's important to know which of your daemons are listening for requests to ensure that network users aren't connecting to services you're not aware of, and users are able to connect to the services you wish them to connect to. One way of determining which of your daemons are waiting for connection requests from clients is to use the sockstat command:
whatis sockstat
sockstat(1) - list open socketsThe sockstat utility will show which daemons will accept IPV4 requests, IPV6 requests, and local Unix requests. If you just type sockstat, it will show all three types of requests; to specify one type of request, use the -4, -6, or -u switches with the command. Let's see which daemons on my computer are waiting for connection requests from clients running IPV4:
sockstat -4
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
tty comsat 8372 0 udp4 *:512 *:*
tty comsat 8372 1 udp4 *:512 *:*
tty comsat 8372 2 udp4 *:512 *:*
genisis navigato 3758 20 tcp4 24.141.117.39:4472 209.225.2.218:80
genisis navigato 3758 30 tcp4 24.141.117.39:4469 208.201.239.36:80
root XF86_SVG 3752 0 tcp4 *:6000 *:*
root sshd 185 4 tcp4 *:22 *:*
root sendmail 181 4 tcp4 *:25 *:*
root sendmail 181 5 tcp4 *:587 *:*
root lpd 177 6 tcp4 *:515 *:*
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 *:*
daemon portmap 152 3 udp4 *:111 *:*
daemon portmap 152 4 tcp4 *:111 *:*
root syslogd 149 4 udp4 *:514 *:*
root dhclient 125 3 udp4 *:* *:*
root dhclient 125 6 udp4 *:68 *:*
Let's pick apart this output. Notice that each listening daemon is a process as it has a PID. Also, each daemon has the choice of using either the TCP or the UDP transport protocol; you may notice that portmap actually uses both. The local address section shows either which port that daemon listens on, or the socket for a connection that has already been established.
Remember that there are thousands of TCP/IP application protocols, and each one has been assigned a port number. This number is used by the client to indicate which daemon it wishes to make a connection to. For example, the port number for SMTP is 25 and the port number for HTTP is 80. Since clients request connections by using a port number, the associated daemon listens for requests on that port number.
If you are unsure which application is associated with a certain port number, do a grep through the /etc/services file. For example, let's concentrate on this line in our output:
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
tty comsat 8372 0 udp4 *:512 *:*
^^ ^^^
To see which daemon is listening on the local address port number of 512, we could issue this command:
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
^^^^^^^Even though we received four results, only one matches port number 512 using UDP. Let's see what biff is:
whatis biff
biff(1) - be notified if mail arrives and who it is from
comsat(8) - biff serverIt's not surprising that we received two results back from our whatis command, since we're dealing with a TCP/IP application. The client portion of this application is called biff, and the server portion is called comsat, or the biff server. Notice that the word comsat occurs under the COMMAND section of our sockstat output as it is the daemon that has the PID of 8372 that is listening on port 512 of my FreeBSD system.
Now let's concentrate on this line of output:
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
genisis navigato 3758 20 tcp4 24.141.117.39:4472 209.225.2.218:80This line represents an active TCP connection on my computer. You'll notice that both the local address and foreign address sections are filled in with an IP address followed by a colon followed by a port number. An IP address followed by a port number is called a socket, hence the name of the utility we are using. You may recognize the port number of 80 as belonging to HTTP; let's see what port 4472 is:
cat /etc/services | grep -w 4472If you try the above command, you won't receive any results, just your command prompt back. To understand why, we need to look at how TCP connections are established.
Pages: 1, 2 |
