Analyzing Other Protocols (Building Internet Firewalls, 2nd Edition)

13.3. Analyzing Other Protocols

In this book, we discuss a large number of protocols, but inevitably there are some that we've left out. We've left out protocols that we felt were no longer popular (like FSP, which appeared in the first edition), protocols that change often (including protocols for specific games), protocols that are rarely run through firewalls (including most routing protocols), and protocols where there are large numbers of competitors with no single clear leader (including remote access protocols for Windows machines). And those are just the protocols that we intentionally decided to leave out; there are also all the protocols that we haven't heard about, that we forgot about, or that hadn't been invented yet when we wrote this edition.

How do you go about analyzing protocols that we don't discuss in this book? The first question to ask is: Do you really need to run the protocol across your firewall? Perhaps there is some other satisfactory way to provide or access the service desired using a protocol already supported by your firewall. Maybe there is some way to solve the underlying problem without providing the service across the firewall at all. It's even possible that the protocol is so risky that there is no satisfactory justification for running it. Before you worry about how to provide a protocol, analyze the problem you're trying to solve.

If you really need to provide a protocol across your firewall, and it's not discussed in later chapters, how do you determine what ports it uses and so on? While it's sometimes possible to determine this information from program, protocol, or standards documentation, the easiest way to figure it out is usually to ask somebody else, such as the members of the Firewalls mailing list[27] (see Appendix A, "Resources").

[27]But make sure you check the archives first, to see if the question has already been asked and answered.

If you have to determine the answer yourself, the easiest way to do it is usually empirically. Here's what you should do:

Set up a test system that's running as little as possible other than the application you want to test.
Next, set up another system to monitor the packets to and from the test system (using etherfind, Network Monitor, netsnoop, tcpdump, or some other package that lets you watch traffic on the local network). Note that this system must be able to see the traffic; if you are attaching systems to a switch, you will need to put the monitoring system on an administrative port, or otherwise rearrange your networking so that the traffic can be monitored.
Run the application on the test system and see what the monitoring system records.

You may need to repeat this procedure for every client implementation and every server implementation you intend to use. There are occasionally unpredictable differences between implementations (e.g., some DNS clients always use TCP, even though most DNS clients use UDP by default).

Finding Assigned Port Numbers
Port numbers are officially assigned by the Internet Assigned Number Authority (IANA). They used to be documented in an IETF RFC; a new assigned numbers RFC was issued every few years (generally carefully timed to be a round number). These days, this would be an extremely large document, so instead, all numbers assigned by IANA are documented by files at an FTP site:

ftp://ftp.isi.edu/in-notes/iana/assignments
Port numbers are found in the file named port-numbers. Not all protocols use well-defined and legally assigned port numbers, and the names that protocols are given in the assignments list are sometimes misleading (for instance, there are numerous listed protocols with names like "sqlnet" and "sql-net", none of which is Oracle's SQL*Net). Nonetheless, this is a useful starting place for clues about the relationship between protocols and port numbers.

You may also find it useful to use a general-purpose client to connect to the server to see what it's doing. Some text-based services will work perfectly well if you simply connect with a Telnet client (see Chapter 18, "Remote Access to Hosts", for more information about Telnet). Others are UDP-based or otherwise more particular, but you can usually use netcat to connect to them (see Appendix B, "Tools", for information on where to find netcat). You should avoid doing this kind of testing on production machines; it's not unusual to discover that simple typing mistakes are sufficient to cause servers to go haywire. This is something useful to know before you allow anybody to access the server from the Internet, but it's upsetting to discover it by crashing a production system.

This sort of detective work will be simplified if you have a tool that allows you to match a port number to a process (without looking at every running process). Although netstat will tell you which ports are in use, it doesn't always tell you the processes that are using them. A popular tool for this purpose on Windows NT is inzider . Under Unix, this is usually done with fuser, which is provided with the operating system on most systems; versions of Unix that do not have fuser will probably have an equivalent with some other name. Another useful Unix tool for examining ports and the programs that are using them is lsof. Information on finding inzider and lsof is in Appendix B, "Tools".