Basic TCPIP

Basic TCP/IP

TCP/IP is the general label applies to a whole bunch of different protocols that hold the Internet together. Each protocol has its own rules and methods. We're going to discuss four protocols here: Internet Protocol, Internet Control Message Protocol, Transmission Control Protocol, and User Datagram Protocol. You can get a partial list of protocols in /etc/protocols.

IP

IP provides two basic services: the formation of packets that can be transmitted over TCP/IP networks and the addressing scheme. We've already discussed both of those in as much detail as we're going to, so I'll leave it here. IP is protocol number 0.

ICMP

Internet Control Message Protocol is a standard for transmitting routing and availability messages across the Internet. Tools such as ping(8) and traceroute(8) use ICMP to gather their results. ICMP packets are vital to normal network behavior, but can be used to gather information about your network. We'll examine how this can be avoided without breaking basic functions in Chapter 17.

UDP

The User Datagram Protocol is arguably the most bare-bones data transfer protocol possible that can run over IP. It has no error handling, no content verification, and no defense whatsoever against data loss. Despite these drawbacks UDP can be a good choice for particular sorts of data transfer, and many vital Internet services use it.

When a host transmits data via UDP, it doesn't know if the data ever reaches its destination. Programs that receive UDP data simply listen to the network and receives what comes that way. When that program receives data via UDP, it has no way to verify the source of that data. While UDP packets include a source address, this is very easily faked. This is why UDP is called connectionless.

An application using UDP most often has its own error-correction requirements that don't jibe with those provided by protocols such as TCP. For example, client DNS queries need to time out within just a few seconds. TCP times connections out after several minutes. Because a system wants to reject a failed DNS request well before that, UDP is used.

TCP

Transmission Control Protocol includes such nifty things as error correction and packet recovery. The receiver must acknowledge every packet sent, or it will be retransmitted. Applications that use TCP can expect reliable data transmission (unless, of course, something goes wrong at the physical layer).

Unlike UDP, TCP is a connected protocol. For data to be transmitted, the two hosts must set up a channel for data to flow across. One host requests a connection, the other host responds to the request, and then the first host starts transmitting. This setup process is known as the three-way handshake. The exact specifics are not important right now, but you should know that this process happens. It will become quite important when we start talking about packet filtering in Chapter 17. Similarly, once a data transmission is complete the system must do a certain amount of work to tear down the connection.

How Protocols Fit Together

You can compare IP, ICMP, TCP, and UDP to sitting with your family at a holiday dinner. IP gives every person at the table a unique chair. ICMP lets you see the other people at the table, and understanding that to hand the peas to your doddering Uncle Chris you must pass it by Cousin Phil. TCP is where you hand someone a dish and the other person must say "thank you" before you will let go. Finally, UDP is like tossing a muffin at Aunt Betty: She might catch it, it might bounce off her forehead, or it could be snatched out of midair by the dog.

Network Ports

Have you ever noticed that computers have too many ports? Well, we're going to add TCP and UDP ports into the mix. Protocol ports permit one server to provide many different network services over a single protocol, multiplexing connections between machines.

When a TCP or UDP packet arrives at a system, it requests delivery to a certain port. Server programs attach, or bind to ports on a system. For example, Internet mail servers generally bind to TCP port 25. Connections intended for the mail server will try to connect to port 25. This means that other programs could connect to the same machine on other ports.

The /etc/services file contains a list of port numbers and the services that they're commonly associated with. It's possible to run almost any service on any port, but by doing so you'll confuse other Internet hosts that try to connect to your system. If someone tries to send you email, their mail program will automatically connect to port 25 on your machine. If your server runs email on port 77, and you have a web server on port 25, that mail will never arrive. What's more, people will never see the web page on that system.

/etc/services has a very simple format, with five columns: the official service name, the port number, the protocol, any aliases for that service, and comments. For example, one service that could be found on many UNIX hosts was Quote of the Day, also known as qotd. If you check /etc/services, you'll find the following entry:

 qotd 17/tcp quote 

The Quote of the Day service runs on TCP and can normally be found on port 17. Many services have both the TCP and UDP ports of a certain number assigned to them, while others have only one of the protocols. For example, the "echo" service runs on port 7 of both TCP and UDP.

Many programs read /etc/services to learn which port to bind to. Depending on the program, you may have to edit /etc/services to assign that protocol to the port. The software instructions will generally tell you if this is the case.

Like all standards, the lists in /etc/services can be violated. The SSH daemon, sshd, normally listens on port 22, but I've run it on port 80 to escape firewalls in some unusual circumstances. This all depends on the program you're using to provide a service.

Low-Numbered Ports

The ports 1024 and below are called low-numbered ports. These are the ports reserved for core Internet infrastructure protocols and important services such as DNS, SSH, HTTP, and so on. Their standard port assignment is basically carved in stone. Only programs that start with root-level privileges can bind to low-numbered ports.

What Ports Are Open?

So, programs bind to ports. The two obvious questions here are, "which ports are open" and "what programs are listening to each?" You can identify this with netstat(1), the same program we used to check mbuf counts.

General Netstat Hints

Any time you use netstat(1) to look at network information you might want to use the "-n" flag. -n tells netstat to not perform DNS lookups on the IP addresses it sees. If most of your network connections are to IP addresses with names cached by your nameserver, then your output will be fairly fast even with DNS lookups. If the system must perform a DNS lookup for every IP address your command will run very slowly, especially if the network between you and your DNS server is performing badly.

The "-f" flag allows you to select a protocol family to examine with netstat(1). If you're only interested in IPv4 connections, use "-f inet". Other valid values for -f include inet6 (for IPv6 connections), ipx (Novell IPX), atalk (AppleTalk), and UNIX (pipes). See netstat(1) for a full list of protocols you can select.

Open Ports and Netstat

Netstat's "-a" flag shows open ports and existing TCP/IP connections. If this machine is an active server, you'll almost certainly want to use the "-n" flag to avoid the DNS lookups, and you'll want to use the "-f inet" option to specify IP connections only. (Try it some time without using either -n or -f, just for your own education.) You'll get a long list back, with six columns.

The first column, PROTO, gives the protocol that this particular connection or listening port is using. We have several TCP ports open, as well as a few UDP ports.

The Recv-Q and Send-Q columns show how many bits are waiting to be handled on this connection. If you see that your system has Recv-Q numbers continually, you know that it cannot process incoming data quickly enough. Similarly, if the Send-Q column keeps having entries, you know that either the network or the other system in the connection cannot accept data as quickly as you can send it. While occasional bursts of either Send-Q or Recv-Q entries are normal, individual entries in these columns should disappear quickly. You need to watch your own system to learn what is normal and what isn't.

The Local Address column is, as you might guess, an open IP address and port number on the local system. The first four numbers are the IP address, and the port number is appended with a period. For example, 192.168.1.250.22 is port 22 on the IP address 192.168.1.250. If this entry is an asterisk, a period, and a port number, it means the system is listening on all available IP addresses for an incoming connection on that port. That particular line does not show any active connections, but the system is ready to accept one.

The Foreign Address column shows the address and port number on the remote end of any connection.

Finally, the (state) column shows the status of the TCP handshake. You don't need to know all of the possible TCP connection states right now; just become familiar with what's normal. ESTABLISHED means that a connection is complete, and data is quite probably flowing over that connection. LAST_ACK, FIN_WAIT_1, and FIN_WAIT_2 mean that the connection is closing. SYN_RCVD, ACK, and SYN+ACK are all parts of the normal connection creation process.

Here we look at the netstat output on a brand-new, out-of-the-box OpenBSD install. I'm using SSH to connect to it, but it has no custom services running.

 # netstat -na -f inet Active Internet connections (including servers) Proto Recv-Q Send-Q  Local Address          Foreign Address      (state) 1 tcp      0      0  192.168.1.250.22       192.168.1.200.49182  ESTABLISHED tcp        0      0  192.168.1.250.22       192.168.1.200.49181  2 TIME_WAIT tcp        0      0  3 127.0.0.1.587        *.*                  LISTEN tcp        0      0  127.0.0.1.25           *.*                  LISTEN tcp        0      0  *.22 4                 *.*                  LISTEN tcp        0      0  *.37                   *.*                  LISTEN tcp        0      0  *.13                   *.*                  LISTEN tcp        0      0  *.113                  *.*                  LISTEN tcp        0      0  127.0.0.1.111          *.*                  LISTEN tcp        0      0  *.111                  *.*                  LISTEN Active Internet connections (including servers) Proto Recv-Q Send-Q  Local Address          Foreign Address      (state) udp        0      0  *.700 5                *.* udp        0      0  *.798                  *.* udp        0      0  *.512                  *.* udp        0      0  127.0.0.1.111          *.* udp        0      0  *.514                  *.* udp        0      0  *.111                  *.* # 

The first entry 1 shows us an existing TCP connection. The local address is 192.168.1.250.22, meaning that the remote side of my connection is talking to this machine on port 22 of the IP address 192.168.1.250. The remote machine is 192.168.1.200, and the connection is coming from port 49182. Finally, we see that this connection is ESTABLISHED; data is quite possibly flowing over this right now.

We also see a TCP connection that has terminated 2 and is in the final stages of teardown.

The next line 3 shows a port that's listening on the local host, but on no other IP addresses. Only systems that can connect to 127.0.0.1 can actually connect to this machine. Because the only machine that can do that is the local host, this port is only available to the local machine.

Shortly thereafter, we 4 see that the machine is listening to TCP port 22 on all available IP addresses. Because there is no remote host and no state, this is a daemon listening for incoming connections.

Near the bottom, we 5 see a series of available connections on UDP ports. You should rarely, if ever, see a remote host running over a UDP connection. They tend to appear very briefly.

What's Listening on Ports?

Now that you know which TCP and UDP ports are open, how can you tell which programs are listening on them? OpenBSD, like many UNIX-like operating systems, supports the lsof(8) program that helps track down which files are open. (Although lsof is not integrated with OpenBSD, it's available in /usr/ports/ sysutils/lsof.) Although many people like lsof, it isn't the only way to get this information out of OpenBSD.

You can look in /etc/services and try to identify the program by the port number. This works well if you're certain that nobody has been tampering with your system. One fun trick an intruder can try is to run a program on a port that should be used by another program. You might not think anything about port 80 being open on a web server, as that's traditionally the port used by web servers. If one IP address has an SSH daemon listening on port 80, you'd never even notice. The only way to be absolutely sure what daemons are running on which ports is to check it yourself.

OpenBSD includes the fstat(1) program, which lists every open file, pipe, or port on the system and various information about its state. I highly recommend perusing fstat(1), as it is a terribly useful program in many different troubleshooting situations. The important thing for us at this moment, however, is that it displays which program is bound to a port. Let's examine TCP port 25, as shown in our example. According to /etc/services this should be "smtp," or email. It probably is, but it's definitely a good example to track down. Run fstat(1) and search its output for port 25. Network ports always appear with a colon before their names, so it's a good idea to include the colon. (Searching for the number 25 in the list of all open files and their states will generate an awful lot of false positives. Go ahead, try it sometime.)

 # fstat | grep ':25' root      2 sendmail  29452  4* internet stream tcp 0xe0b40d70 1 127.0.0.1:25 root      sendmail   29452   5* internet6 stream tcp 0xe0b59004 [::1]:25 # 

At the end of the line we see the IP addresses and port numbers that this connection is listening on, and near the beginning we see the name of the program that is listening on this port. What do you know; this really is the mail server program! My nasty paranoid suspicions were unfounded — this time.

If you're not sure what a program listening on a port does, be sure to check its man page.