Tcpdump patterns: Difference between revisions

From TykWiki
Jump to navigationJump to search
Line 37: Line 37:
Explanation: A bit of backgound information on UDP and DNS packets is neccesary for this:
Explanation: A bit of backgound information on UDP and DNS packets is neccesary for this:


* The UDP packet header is 8 bytes and tcpdump is counting from zero, so the DNS packet header begins at "byte number 8" in tcpdump match syntax. See [http://www.ietf.org/rfc/rfc768.txt RFC768] for more on UDP packet characteristics.  
* The UDP packet header is 8 bytes and tcpdump is counting the bytes from zero when matching, so the DNS packet header begins at "byte number 8" in tcpdump match syntax. See [http://www.ietf.org/rfc/rfc768.txt RFC768] for more on UDP packet characteristics.  
* According to [http://www.ietf.org/rfc/rfc1035.txt rfc1035] (section 4.1.1, page 25), the two first bytes ("number 8 and 9" in tcpdump match syntax) in the DNS header is the transaction ID.  
* According to [http://www.ietf.org/rfc/rfc1035.txt rfc1035] (section 4.1.1, page 25), the two first bytes ("number 8 and 9" in tcpdump match syntax) in the DNS header is the transaction ID.  
* The next two bytes ("number 10 and 11" in tcpdump match syntax) make up the flags for the DNS packet, for the purpose of matching ServFail responses I need to check the RCODE which is in the four low bits of the second of the two bytes.  
* The next two bytes ("number 10 and 11" in tcpdump match syntax) make up the flags for the DNS packet. The two bytes contain a lot of information (refer to [http://www.ietf.org/rfc/rfc1035.txt rfc1035] section 4.1.1, page 26), but for the purpose of matching ServFail responses I only need to check the RCODE field which is contained in the four low bits of the second of the two bytes. Two bytes is 16 bits, so if these two example bytes were the two bytes that make up the DNS flags:
<pre>
00000000 00001111
</pre>
I would need to check the four last bits, the 1's in this example.


So: I need to check the four low bits in byte number 11.  
So to sum up: I need to check the four low bits in byte number 11 of the packet.


According to [http://www.ietf.org/rfc/rfc1035.txt rfc1035] (section 4.1.1, page 26), an RCODE of 2 (thats binary 0010 in the four low bits of byte 11) means ServFail.  
According to [http://www.ietf.org/rfc/rfc1035.txt rfc1035] (section 4.1.1, page 26), an RCODE of decimal 2 (thats binary ''0010'' in the four low bits of byte 11) means ServFail.  


Binary xxxx0010 (meaning that I don't care what the four high bits are, I only care that the four low bits are exactly 0010) can be matched with tcpdump by using a '''bit-by-bit "binary AND" against a bitmask'''. This basically means:
You can check the individual bits that make up the bytes in a packet with tcpdump by using a '''bit-by-bit "binary AND" against a bitmask'''. Since the RCODE of the response is only a half-byte, I don't care what the four high bits are, I only care that the four low bits are exactly ''0010''. This can be checked like so:


* If I wanted the third-lowest bit of byte 11 (couting from 0) to be 0 in matched packets, thats decimal 4 binary 100, I would add 'udp[11] & 4 = 0' to the tcpdump pattern.  
* If I wanted the third-lowest bit in byte 11 to be 0 in matched packets, that bit is decimal 4 or binary ''00000100'', I would add 'udp[11] & 4 = 0' to the tcpdump pattern.  
* If I wanted the fourth-lowest bit byte 11 (couting from 0) to be 1 in matched packets, thats decimal 8 binary 1000, I would add 'udp[11] & 8 = 1' to the tcpdump pattern.
* If I wanted the fourth-lowest bit in byte 11 to be 1 in matched packets, that bit is decimal 8 or binary ''00001000'', I would add 'udp[11] & 8 = 1' to the tcpdump pattern.
* If I for some reason wanted to the highest bit in byte 17 to be 1 in matched packets, that bit is decimal 128 or binary ''10000000'', I would add 'udp[17] & 128 = 1' to the tcpdump pattern.


The pattern in the example to match ServFail responses above matches '''all four low bits in byte 11 of the UDP packet, and makes sure they are exactly 0010'''.
'''Summary:''' The tcpdump pattern to match ServFail responses in the example above matches '''all four low bits in byte 11 of the UDP packet, and makes sure they are exactly ''0010'''''.


== Links ==  
== Links ==  
See [http://acs.lbl.gov/~jason/tcpdump_advanced_filters.txt this page] for much more on bit matching with tcpdump.
See [http://acs.lbl.gov/~jason/tcpdump_advanced_filters.txt this page] for much more on bit matching with tcpdump.

Revision as of 16:35, 2 August 2009

On http://danielmiessler.com/study/tcpdump_recipes/ I found this nice list:

Show me all URG packets:
# tcpdump 'tcp[13] & 32 != 0'

Show me all ACK packets:
# tcpdump 'tcp[13] & 16 != 0'

Show me all PSH packets:
# tcpdump 'tcp[13] & 8 != 0'

Show me all RST packets:
# tcpdump 'tcp[13] & 4 != 0'

Show me all SYN packets:
# tcpdump 'tcp[13] & 2 != 0'

Show me all FIN packets:
# tcpdump 'tcp[13] & 1 != 0'

Show me all SYN-ACK packets:
# tcpdump 'tcp[13] = 18'

Matching DNS Traffic

To show incoming nsupdate queries run the following:

tcpdump port 53 and 'udp[10] = 0x28'

To show ServFail replies run the following:

tcpdump port 53 and 'udp[11] & 8 = 0' and 'udp[11] & 4 = 0' and 'udp[11] & 2 = 2' and 'udp[11] & 1 = 0'

Explanation: A bit of backgound information on UDP and DNS packets is neccesary for this:

  • The UDP packet header is 8 bytes and tcpdump is counting the bytes from zero when matching, so the DNS packet header begins at "byte number 8" in tcpdump match syntax. See RFC768 for more on UDP packet characteristics.
  • According to rfc1035 (section 4.1.1, page 25), the two first bytes ("number 8 and 9" in tcpdump match syntax) in the DNS header is the transaction ID.
  • The next two bytes ("number 10 and 11" in tcpdump match syntax) make up the flags for the DNS packet. The two bytes contain a lot of information (refer to rfc1035 section 4.1.1, page 26), but for the purpose of matching ServFail responses I only need to check the RCODE field which is contained in the four low bits of the second of the two bytes. Two bytes is 16 bits, so if these two example bytes were the two bytes that make up the DNS flags:
00000000 00001111

I would need to check the four last bits, the 1's in this example.

So to sum up: I need to check the four low bits in byte number 11 of the packet.

According to rfc1035 (section 4.1.1, page 26), an RCODE of decimal 2 (thats binary 0010 in the four low bits of byte 11) means ServFail.

You can check the individual bits that make up the bytes in a packet with tcpdump by using a bit-by-bit "binary AND" against a bitmask. Since the RCODE of the response is only a half-byte, I don't care what the four high bits are, I only care that the four low bits are exactly 0010. This can be checked like so:

  • If I wanted the third-lowest bit in byte 11 to be 0 in matched packets, that bit is decimal 4 or binary 00000100, I would add 'udp[11] & 4 = 0' to the tcpdump pattern.
  • If I wanted the fourth-lowest bit in byte 11 to be 1 in matched packets, that bit is decimal 8 or binary 00001000, I would add 'udp[11] & 8 = 1' to the tcpdump pattern.
  • If I for some reason wanted to the highest bit in byte 17 to be 1 in matched packets, that bit is decimal 128 or binary 10000000, I would add 'udp[17] & 128 = 1' to the tcpdump pattern.

Summary: The tcpdump pattern to match ServFail responses in the example above matches all four low bits in byte 11 of the UDP packet, and makes sure they are exactly 0010.

Links

See this page for much more on bit matching with tcpdump.