Sidestep DNS Queries

To get a better understanding of the need for a NIDS to be protocol savvy, we'll examine DNS queries that are formed by running sidestep. First, most NIDS, whether protocol aware or not, should catch a normal query. The evasive query will be discussed next to contrast it with the normal query and demonstrate that a NIDS that looks for strings in a packet would probably

miss the clever manipulations employed.

Normal Query

Let's examine the output that was generated by TCPdump from the sidestep program using a normal query. This is displayed in standard TCPdump output followed by a hexadecimal dump of

the packet to understand the context of the activity:

12:39:30.027400 10.100.100.201.1128 > DNS.SERVER.domain: 10+ TXT CHAOS)? version.bind. (30)

4500	003a	052c	0000	8011	c056	0a64	64c9	E..:.,.....V.dd.
0a64	6402	0468	0035	0026	6325	<000a 0100		.....h.5.&c%....
0001	0000	0000	0000	0776	6572	7369	6f6e	.........version
0462	696e	6400	0010	0003>				.bind.....

First you see the standard TCPdump display output of host 10.100.100.201 querying DNS.SERVER on UDP port 53 (domain) with a DNS identification number of 10 and with recursion desired (+) for a TXT type record and a CHAOS class record of version.bind.

Let's examine the hexadecimal output of the actual DNS query. The DNS portion of this packet has been delimited with the < > to easily identify the part of the record we will scrutinize.

DNS questions have a prescribed format. A DNS question has a series of nodes that end in a 00 to form the question. We typically see nodes that are separated by periods when we express a

hostname or IP address. For instance, if an IP address resolution were desired for www.yahoo.com, the DNS question that would be generated would treat the name as a series

of nodes—www, yahoo, and com. Preceding each node is a byte count that tells how many bytes are in the following node.

The version.bind question that was generated using sidestep's normal option is as follows:

0776 6572 7369 6f6e 0462 696e 6400

The bolded bytes represent labels. The first label is 07, which means that there should be 7 bytes in the first node of the query. In this instance, the hex characters that follow are the ASCII representation of the node "version". Next, you see a label of 04 meaning that there are 4 bytes in the following node, which is the hex representation of the ASCII "bind". A 00 label ends the query, which is the final label that is seen.

Each question requires a DNS type and class, each of which is a 2-byte field. The various different types and classes can be found in RFC 1035, but for the purposes of the BIND version query, these must be a type of TXT represented by a 16 (or hex 0010) and a class of CHAOS represented as a 3 (or hex 0003). An accessible DNS server that does not prevent version.bind

queries will respond to the above query with the version of BIND that is running.

Evasive Query

Let's examine the output that was generated by TCPdump displayed in hexadecimal to

understand the evasive activity:

12:39:56.674320 10.100.100.201.1129 > DNS.SERVER.domain: 42 (32)

4500	003c	0577 0000	8011	c009	0a64	64c9	E..<.w	.......dd.
0a64	6402	0469 0035	0028	e445	<002a 0000		.....i.5.(.E.*..
0001	0000	0000 0000	0756	6572	7369	6f6e	.........	Version
c01a 0010		0003 0442	494e	4400>		|	.......	BIND.
	|
	|					|