Capturing Other Tcpbased Protocols

Capturing other TCP-based protocols follows much the same process as that in the examples shown. For example, capturing POP3 connections can be accomplished and the entire stream can be captured because POP3, like SMTP, is not encrypted during transit. One protocol is of particular interest because it has confounded network administrators for a long time. That protocol is FTP.

FTP utilizes two TCP ports, 20 and 21. Port 21 is normally used for commands and is sometimes referred to as the control channel. Port 20 in FTP is used for data and is sometimes aptly titled the data channel. Therefore, if you want to capture FTP traffic with TCPDump, you need to grab both ports 20 and 21 to see everything.

A trend over the past few years has been protocols that use nonstandard ports to circumvent firewalls and packet capturing and filtering. Such programs, including much of the peer-to-peer software, can be somewhat difficult to find during packet captures because most of the data during the conversation is binary and is thus not human-readable.

This document is created with trial version of CHM2PDF Pilot 2.15.72. CAPTURING A DNS QUERY

TCPDump handles DNS queries a little differently than a packet that's simply TCP. More information can be gleaned from just the initial packet result line as opposed to making it necessary to increase the snaplen with the -s option. For example, consider the following trace of a simple DNS query that was looking for the IP address of a host named

www.braingia.org:

21:18:39.289121 192.168.1.10.1514 > 192.168.1.1.53: 60792+ A? www.braingia.org. (34) (DF) 21:18:39.289568 192.168.1.1.53 > 192.168.1.10.1514: 60792*- 1/2/2 A 192.168.1.50 (118) (DF)

In the packet trace we see host 192.168.1.10 on an ephemeral port communicating with a destination of 192.168.1.1 on port 53. A query ID number is given; in this case it's 607 92. You see the query ID number is followed by a +. This symbol indicates that the querier asked for recursion on this query. The A? on the trace line indicates that this was an address query. The query was for www.braingia.org, as is shown, and the size of the query is 34 bytes, which does not include IP or UDP overhead.

The answer comes quickly, as we see in the next line of the trace, which shows that the source is now 192.168.1.1 talking to the destination of 192.168.1.10. As you can see, the answer was contained in the same query ID, 60792; however, this time there are two extra characters, the * and the -. The * in a response indicates that this is an authoritative answer, and the - indicates that recursion is available and not set. The next portion of the response, 1/2/2, indicates the number of answer records (1), the number of name server records (2), and the number of additional records (2). The first answer given in this case is of type A and is 192.168.1.50. Finally, the size of the response is given to be 118 bytes.

Was this article helpful?

0 0

Post a comment