OK, here’s a hint to point you in the right direction.

The challenge was: “Write a tcpdump/windump filter that will capture ICMPv6 Multicast Listener packets.”

Sounds easy, right?

With a little help from Google you’ll find that the “type” for Multicast listener is 130, and the ICMPv6 type field is the first byte in the header. So this should be as easy as:

tcpdump -nn -p -v -s 0 icmp6[0]=130

however if you run the command you’ll get back:

tcpdump: IPv6 upper-layer protocol is not supported by proto[x]

In other words, you can use “icmp6″ to see all ICMPv6 packets, but you can’t use it to filter on any of the ICMPv6 header fields.

So we need a “Plan B”. Figure out plan B and you’ve solved the challenge.

Building on the IPv6 challenge from last time, I have a new one for you: Write a tcpdump/windump filter which will capture ICMPv6 Multicast Listener packets.

That’s it! Pretty easy, right?

Well its now Thursday so I figured its time to post the answers to last weekend’s challenge.

First, why should you even care about IPv6 if you have not started deploying it? I felt much the same way till I found IPv6 being used as a covert communication channel within a client’s network. The data was then being pushed out to the Internet via Teredo. If you are not familiar with the technique, Scott Hogg has some excellent posts on the topic.

So even if you are not currently using IPv6, it pays to start cutting the cure on the technology as well as watching for it on your local network.

So to review, the challenge was:

Write a tcpdump or Windump filter that will capture all traffic with a source IPv6 address of 2001:db8::10 through 2001:db8::20.

There are a couple of caveats with writing this filter. The first few I covered in the last post. The final one, which I knew but never really thought was a problem till I started working with IPv6 pretty heavily, is that tcpdump/Windump will only let you use 1, 2 or 4 byte masks. So while we would love to solve this with an initial filter statement of “ip6[8:14]=”, we can’t because we’re limited to 4 bytes. There is in fact a way to get around this, but I’ll come back to it.

So here’s the filter I’ve been working with:

(ip6[8:4]=0x20010db8 and ip6[12:4]=0 and ip6[16:4]=0 and (ip6[20:4]>=0×0010 and ip6[20:4]<=0050))

Bit long, but it works. Elizabeth came up with a solution that is far more elegant than my own:

src net 2001:db8::/122 and ip6[23] >= 0×10 && ip6[23] <= 0×20

So by starting with the Libpcap format, she’s able to combine my first three statements into one. Not to be a size queen, but that makes her solution is much shorter than mine. In this case that’s a good thing.

That’s about it. I’ll post another IPv6 type challenge tomorrow.

Wow, the sound of crickets is deafening. Surely someone has the skills to get us through this dilemma? 

OK, some hints to get you through the challenge. Let’s start by solving this as an IPv4 address and then we’ll work our way into IPv6. Assume the address range we want to capture is 192.168.1.10 – 192.168.1.20. The big problem is the IPs are not on an even byte boundary. We could do something like:

src net 192.168.1.0/27

but that would give us addresses .0 – .31, more IPs than we actually wanted to see. To solve this problem we’ll need to use some operators and primitives.  One possibility is:

(ip[12]=192 and ip[13]=168 and ip[14]=1 and (ip[15]>=10 and ip[15]<=20))

Starting with the inner most brackets, the above statement reads “byte 15 must be greater than or equal to 10, but it also must be less than or equal to 20. If this statement is true, make sure byte 12 is equal to 192, byte 13 is equal to 168 and byte 14 is equal to 1.”

Can we shorten this expression? Absolutely! First we must convert it to Hex however. Why Hex? If I write a statement such as “ip[12:2]=” tcpdump will assume that the result will be a 16-bit number, not two 8-bit numbers. This is why you can write something like “tcp[2:2]=12345″ and have it work. tcpdump converts the two bytes into a 16-bit value and matches it against the value you specified. By converting to Hex we avoid this problem. So:

192.168.1.10 = 0xC0A8010A

192.168.1.20 = 0xC0A80120

Now we simply write our expression:

ip[12:4]>=0xC0A8010A and ip[12:4]<=0xC0A80120

That’s all there is to it.

While IPv4 uses 4 byte addresses, IPv6 uses 16 bytes. Because the addresses are so long, we write them in Hex to save some space. So the addresses I gave you in the challenge were:

2001:0db8:0000:0000:0000:0000:0000:0010

2001:0db8:0000:0000:0000:0000:0000:0020

Notice I didn’t initially write them that way. There’s a few conventions you can use to save space when writing an IPv6 address. First, we can truncate leading zeroes. So:

2001:0db8:0000:0000:0000:0000:0000:0010

becomes:

2001:db8:0000:0000:0000:0000:0000:10

Now, see all those zeroes in the middle? We can chop them out too. When you see “::” that means to fill in that space with enough zeroes to expand the address back out to 16 bytes. So add in this trick as well and we get:

2001:db8::10

Far easier to write. The caveat is you can only remove one group of zeroes with the double colon trick. Consider the following address:

2001::1234::10

We have no idea where to place the byte sequence “1234″ in the address. It start anywhere from byte 6 through byte 12.

When working with IPv4, tcpdump and Windump use the protocol keyword “ip”, as shown in the above examples. The IPv6 compliment to that is “ip6″. Where’s the source address field in the IPv6 header? Well I can’t give you all there answers or it is no longer a “challenge”

Here’s another challenge to test your bit wienie skills:

Write a tcpdump or Windump filter that will capture all traffic with a source IPv6 address of 2001:db8::10 through 2001:db8::20. Pretty easy, right? If you have not tried it, your going to find that tcpdump/Windump throws a few curves at you.

To check your work, here’s a capture file:

ipv6-icmp

The file contains a mix of source IPv6 addresses. Obviously your filter should only display the specified range of addresses.

The winner gets to inspire awe and admiration in lesser geeks. 

If this challenge seemed harder than it should be,you are on the right track.

I ran across this problem when writing my Packet Decode tool. I have to say, it was a cool exercise for me, as I never really thought about creating tcpdump and Wireshark filters for every possible IP, TCP, UDP and ICMP field and/or value. By far the TCP options field is the most “broken” from a packet decode perspective than any other IP field.

First let’s talk about how the TCP options should have been implemented. If you look at the IPv4 options field, it begins with a “Type” identifier. If you are interested in a specific IP option, it is just a matter of checking this field for the right bit combination. Had the TCP options been implemented this way, this challenge would have been pretty straight forward.

Just about all TCP options have a “Kind” and a “Length” field, both of which are 1 byte in size. The exceptions are “End of Option List” and “No-Operation” which only have a Kind field, and thus are one byte in size. Here’s a list of the common TCP options:

Page 15 of RFC 793 tells us “The TCP header (even one including options) is an integral number of 32 bits long.” In other words, the TCP header size in bytes must be evenly divisible by four (20 bytes, 24 bytes, etc.). If you look at the list of TCP options, only “maximum segment size” is divisible by four. So the use of any other options are going to require padding.

How the padding should be applied is a bit unclear. If we look at page 26 of RFC 1323 we find this:

APPENDIX A:  IMPLEMENTATION SUGGESTIONS

   The following layouts are recommended for sending options on non-SYN
   segments, to achieve maximum feasible alignment of 32-bit and 64-bit
   machines.

       +--------+--------+--------+--------+
       |   NOP  |  NOP   |  TSopt |   10   |
       +--------+--------+--------+--------+
       |          TSval   timestamp        |
       +--------+--------+--------+--------+
       |          TSecr   timestamp        |
       +--------+--------+--------+--------+

Note the NOP padding appears before the timestamp option, not at the end like you might expect. Also note the RFC specifically says this is for “non-SYN segments” and that it is “recommended”, not required. Seems however that most operating systems follow this recommendation and always place padding before the Kind and Length bytes. I’ve checked Windows, Linux, Mac, various hardware, etc. and they all put the padding at the beginning.

So we can count on this being the “standard”, right? Not quite.  Page 17 of RFC 793 describes NOP this way:

        This option code may be used between options, for example, to
        align the beginning of a subsequent option on a word boundary.
        There is no guarantee that senders will use this option, so
        receivers must be prepared to process options even if they do
        not begin on a word boundary.

In other words, its not just that NOP may or may not show up at the beginning, NOP might not be used at all! It is entirely legal to layout the TCP option field with no NOP padding and just use End of Option List as filler at the end to achieve the proper boundary.

So what do we end up with for a filter? If we count on NOP before the option we end up with a filter that looks like this:

tcp[13]&2=2 and tcp[12]&240>80 and ((tcp[20]=1 and tcp[21:2]=0×0303) or (tcp[24]=1 and tcp[25:2]=0×0303) or (tcp[28]=1 and tcp[29:2]=0×0303) or (tcp[32]=1 and tcp[33:2]=0×0303) or (tcp[36]=1 and tcp[37:2]=0×0303) or (tcp[40]=1 and tcp[41:2]=0×0303) or (tcp[44]=1 and tcp[45:2]=0×0303) or (tcp[48]=1 and tcp[49:2]=0×0303) or (tcp[52]=1 and tcp[53:2]=0×0303) or (tcp[56]=1 and tcp[57:2]=0×0303))

To break down what this filter is doing:

• Only check SYN & SYN/ACK packets:  tcp[13]&2=2
• TCP header is greater than 20 bytes (options are set): tcp[12]&240>80
• Check the first byte of each four byte boundary for NOP: tcp[20]=1, tcp[24=1, ...
• Check the next two bytes to see if Kind=3 and Length=3: tcp[21:2]=0×0303, tcp[25:2]=0×0303, …

If however we want to ensure that we catch all possibilities in case a system does not implement NOP we end up with:

tcp[13]&2=2 and tcp[12]&240>80 and (tcp[20:2]=0×0303 or tcp[21:2]=0×0303 or tcp[22:2]=0×0303 or tcp[23:2]=0×0303 or tcp[24:2]=0×0303 or tcp[25:2]=0×0303 or tcp[26:2]=0×0303 or tcp[27:2]=0×0303 or tcp[28:2]=0×0303 or tcp[29:2]=0×0303 or tcp[30:2]=0×0303 or tcp[31:2]=0×0303 or tcp[32:2]=0×0303 or tcp[33:2]=0×0303 or tcp[34:2]=0×0303 or tcp[35:2]=0×0303 or tcp[36:2]=0×0303 or tcp[37:2]=0×0303 or tcp[38:2]=0×0303 or tcp[39:2]=0×0303 or tcp[40:2]=0×0303 or tcp[41:2]=0×0303 or tcp[42:2]=0×0303 or tcp[43:2]=0×0303 or tcp[44:2]=0×0303 or tcp[45:2]=0×0303 or tcp[46:2]=0×0303 or tcp[47:2]=0×0303 or tcp[48:2]=0×0303 or tcp[49:2]=0×0303 or tcp[50:2]=0×0303 or tcp[51:2]=0×0303 or tcp[52:2]=0×0303 or tcp[53:2]=0×0303 or tcp[54:2]=0×0303 or tcp[55:2]=0×0303 or tcp[56:2]=0×0303 or tcp[57:2]=0×0303 or tcp[58:2]=0×0303)

The difference with this filter is that we are checking Kind=3 and Length=3 all the way through the options field (as Elizabeth suggested).

Can either of these filters generate false positives? Absolutely! Two possibilities:

1. The value of Timestamp may match the pattern we are looking for.
2. The filter assumes a 40 byte option field. It could be less with these values in the payload.

So which filter should you use? The first will generate fewer false positives but miss systems that are RFC compliant but different from the norm. The second will always catch Window Scale if it has been set, but the chance of a false positive is higher.

I’m going to designate Elizabeth as the winner of the challenge. A few others were just as close but she was the only one with the guts to post her train of thought in the comments. I’m going to award a second prize to Jeff who came up with this solution partially kidding around:

tcpdump -nn | grep ‘wscale ‘ > wscale-matches.txt

This will not generate an actual packet capture, but you could do a:

tcpdump -nn -X -s 0 | grep ‘wscale ‘ > wscale-matches.txt

And then run the output through txt2cap to get it back into pcap format. He didn’t follow the challenge specifically, but you’ve gotta give kudos for thinking outside the box as this fixes all false positive issues.

Elizabeth and Jeff, I’ll be contacting you both via e-mail. Congrats!

I’ve had one thread post and four e-mails that are soooooo close to the right answer. Here’s one last clue to hopefully get folks over the final hurdle.

I mentioned the helpful tshark command. Here’s the output:

C:\testing>tshark -n -r linux-syn.cap -T fields -e tcp.options
02:04:05:b4:04:02:08:0a:02:47:4a:a8:00:00:00:00:01:03:03:05

So what you have above is the TCP options section (byte 20 and higher) of the test packet. The Window Scale option is the last option in the list.

I know writing this filter is not easy. In fact that’s why I turned it into a challenge. It is possible however.