{"id":3701,"date":"2016-02-09T19:13:45","date_gmt":"2016-02-09T17:13:45","guid":{"rendered":"http:\/\/www.laurentmarot.fr\/wordpress\/?p=3701"},"modified":"2020-02-18T19:18:32","modified_gmt":"2020-02-18T17:18:32","slug":"ttcpdump-advanced-filtering-pour-memoire","status":"publish","type":"post","link":"https:\/\/www.laurentmarot.fr\/wordpress\/?p=3701","title":{"rendered":"tcpdump advanced filtering (pour m\u00e9moire)"},"content":{"rendered":"

TCPDUMP ADVANCED FILTERS<\/strong>
\n===========================<\/p>\n

Merci \u00e0 Sebastien Wains <\/code>
\nhttp:\/\/www.wains.be<\/p>\n

$Id: tcpdump_advanced_filters.txt 36 2013-06-16 13:05:04Z sw $<\/p>\n

Notes :<\/span>
\nJ’ai l’habitude de sp\u00e9cifier l’interface sur laquelle \u00e9couter. C’est l’option -i<\/em> que l’on retrouve dans tous les exemples suivants.
\nChacune des r\u00e8gles suivantes a \u00e9t\u00e9 test\u00e9e depuis mon laptop connect\u00e9 \u00e0 un r\u00e9seau wifi au travers de eth1.
\nN’h\u00e9sitez pas \u00e0 m’envoyer vos commentaires et suggestions ou pour corriger des erreurs.
\nJe sais que je suis vraiment affreux pour expliquer les choses, alors n’h\u00e9sitez pas \u00e0 me solliciter si tout n’est pas clair.<\/p>\n

J’essaierai de mettre \u00e0 jour ce document avec de nouvelles r\u00e8gles utiles.<\/p>\n

Avant de commencer avec les filtres avanc\u00e9s, revoyons la syntaxe basique de tcpdump<\/p>\n

Syntaxe basique :<\/strong><\/span><\/p>\n

Filtrage sur hosts :<\/strong>
\n—————————<\/p>\n

– filtre tout trafic relatif \u00e0 192.168.1.1 en destination ou source
\n# tcpdump -i eth1 host 192.168.1.1<\/code><\/p>\n

– As source only
\n# tcpdump -i eth1 src host 192.168.1.1<\/code><\/p>\n

– As destination only
\n# tcpdump -i eth1 dst host 192.168.1.1<\/code><\/p>\n

 <\/p>\n

Filtering ports :<\/strong>
\n—————————<\/p>\n

– Match any traffic involving port 25 as source or destination
\n# tcpdump -i eth1 port 25<\/code><\/p>\n

– Source
\n# tcpdump -i eth1 src port 25<\/code><\/p>\n

– Destination
\n# tcpdump -i eth1 dst port 25<\/code><\/p>\n

 <\/p>\n

Network filtering :<\/strong>
\n—————————–<\/p>\n

# tcpdump -i eth1 net 192.168
\n# tcpdump -i eth1 src net 192.168
\n# tcpdump -i eth1 dst net 192.168<\/p>\n

 <\/p>\n

Protocol filtering :<\/strong>
\n——————————<\/p>\n

# tcpdump -i eth1 arp
\n# tcpdump -i eth1 ip<\/p>\n

# tcpdump -i eth1 tcp
\n# tcpdump -i eth1 udp
\n# tcpdump -i eth1 icmp<\/p>\n

 <\/p>\n

Let’s combine expressions :<\/strong><\/span><\/p>\n

Negation : ! or \u00ab\u00a0not\u00a0\u00bb (without the quotes)
\nConcatanate : && or \u00ab\u00a0and\u00a0\u00bb
\nAlternate : || or \u00ab\u00a0or\u00a0\u00bb<\/p>\n

—————————<\/p>\n

– This rule will match any TCP traffic on port 80 (web) with 192.168.1.254 or 192.168.1.200 as destination host
\n# tcpdump -i eth1 '((tcp) and (port 80) and ((dst host 192.168.1.254) or (dst host 192.168.1.200)))'<\/code><\/p>\n

– Will match any ICMP traffic involving the destination with physical\/MAC address 00:01:02:03:04:05
\n# tcpdump -i eth1 '((icmp) and ((ether dst host 00:01:02:03:04:05)))'<\/code><\/p>\n

– Will match any traffic for the destination network 192.168 except destination host 192.168.1.200
\n# tcpdump -i eth1 '((tcp) and ((dst net 192.168) and (not dst host 192.168.1.200)))'<\/code><\/p>\n

 <\/p>\n

Advanced header filtering :
\n===========================<\/p>\n

Before we continue, we need to know how to filter out info from headers<\/p>\n

proto[x:y] : will start filtering from byte x for y bytes. ip[2:2] would filter bytes 3 and 4 (first byte begins by 0)
\nproto[x:y] & z = 0 : will match bits set to 0 when applying mask z to proto[x:y]
\nproto[x:y] & z !=0 : some bits are set when applying mask z to proto[x:y]
\nproto[x:y] & z = z : every bits are set to z when applying mask z to proto[x:y]
\nproto[x:y] = z : p[x:y] has exactly the bits set to z<\/p>\n

Operators : >, <, >=, <=, =, !=<\/p>\n

This may not be clear in the first place but you’ll find examples below involving these.<\/p>\n

Of course, it is important to know what the protocol headers look like before diving into more advanced filters.<\/p>\n

IP header<\/strong>
\n——————–<\/p>\n

|<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
0<\/td>\n1<\/td>\n2<\/td>\n3<\/td>\n<\/tr>\n
0<\/td>\n1<\/td>\n2<\/td>\n3<\/td>\n4<\/td>\n5<\/td>\n6<\/td>\n7<\/td>\n8<\/td>\n9<\/td>\n0<\/td>\n1<\/td>\n2<\/td>\n3<\/td>\n4<\/td>\n5<\/td>\n6<\/td>\n7<\/td>\n8<\/td>\n9<\/td>\n0<\/td>\n1<\/td>\n2<\/td>\n3<\/td>\n4<\/td>\n5<\/td>\n6<\/td>\n7<\/td>\n8<\/td>\n9<\/td>\n0<\/td>\n1<\/td>\n<\/tr>\n
+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n<\/tr>\n
|<\/td>\nVersion<\/td>\n|<\/td>\nIHL<\/td>\n|<\/td>\nType of Service<\/td>\n|<\/td>\nTotal Length<\/td>\n|<\/td>\n<\/tr>\n
+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n<\/tr>\n
|<\/td>\nIdentification<\/td>\n|<\/td>\nFlags<\/td>\n|<\/td>\nFragment Offset<\/td>\n|<\/td>\n<\/tr>\n
+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n<\/td>\n<\/tr>\n
|<\/td>\nTime to Live<\/td>\n|<\/td>\nProtocol<\/td>\n|<\/td>\nHeader Checksum<\/td>\n|<\/td>\n<\/td>\n<\/tr>\n
+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n<\/tr>\n
|<\/td>\nSource Address<\/td>\n|<\/td>\n<\/td>\n<\/tr>\n
+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n<\/td>\n<\/tr>\n
|<\/td>\nDestination Address<\/td>\n|<\/td>\n<\/td>\n<\/tr>\n
+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n<\/tr>\n
|<\/td>\nOptions<\/td>\n|<\/td>\nPadding (optional)<\/td>\n|<\/td>\n<–<\/td>\n<\/tr>\n
+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n<\/td>\n<\/tr>\n
|<\/td>\nDATA…<\/td>\n|<\/td>\n<\/td>\n<\/tr>\n
+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n–<\/td>\n+<\/td>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

I’ll consider we are only working with the IPv4 protocol suite for these examples.
\nIn an ideal world, every field would fit inside one byte. This is not the case, of course.<\/p>\n

 <\/p>\n

Are IP options set ?<\/strong><\/p>\n

——————————<\/p>\n

Let’s say we want to know if the IP header has options set. We can’t just try to filter out the 21st byte because if no options are set, data start at the 21st byte. We know a \u00ab\u00a0normal\u00a0\u00bb header is usually 20 bytes (160 bits) long. With options set, the header is longer than that. The IP header has the header length field which we will filter here to know if the header is longer than 20 bytes.<\/p>\n

+-+-+-+-+-+-+-+-+<\/p>\n

|\u00a0 Version\u00a0 |\u00a0\u00a0 IHL \u00a0 |<\/p>\n

+-+-+-+-+-+-+-+-+<\/p>\n

Usually the first byte has a value of 01000101 in binary. Anyhow, we need to divide the first byte in half…
\n0100 = 4 in decimal.
\nThis is the IP version.
\n0101 = 5 in decimal.
\nThis is the number of blocks of 32 bits in the headers.<\/p>\n

 <\/p>\n

5 x 32 bits = 160 bits or 20 bytes. The second half of the first byte would be bigger than 5 if the header had IP options set. We have two ways of dealing with that kind of filters.<\/p>\n

1. Either try to match a value bigger than 01000101.<\/p>\n

This would trigger matches for IPv4 traffic with IP options set, but ALSO any IPv6 traffic !<\/p>\n

In decimal 01000101 equals 69. Let’s recap how to calculate in decimal. 0 : 0 \\ 1 : 2^6 = 64 \\ First field (IP version) 0 : 0 \/ 0 : 0 \/ – 0 : 0 \\ 1 : 2^2 = 4 \\ Second field (Header length) 0 : 0 \/ 1 : 2^0 = 1 \/ 64 + 4 + 1 = 69 The first field in the IP header would usually have a decimal value of 69. If we had IP options set, we would probably have 01000110 (IPv4 = 4 + header = 6), which in decimal equals 70. This rule should do the job : # tcpdump -i eth1 ‘ip[0] > 69’<\/p>\n

Somehow, the proper way is to mask the first half\/field of the first byte, because as mentionned earlier,
\nthis filter would match any IPv6 traffic.<\/p>\n

2. The proper\/right way : \u00ab\u00a0masking\u00a0\u00bb the first half of the byte<\/p>\n

0100 0101 : 1st<\/sup> byte originally
\n0000 1111 : mask (0xf in hex or 15 in decimal). 0 will mask the values while 1 will keep the values intact.
\n=========
\n0000 0101 : final result<\/p>\n

You should see the mask as a power switch. 1 means on\/enabled, 0 means off\/disabled.<\/p>\n

The correct filter :<\/p>\n

In binary
\n# tcpdump -i eth1 ‘ip[0] & 15 > 5’<\/p>\n

or<\/p>\n

In hexadecimal
\n# tcpdump -i eth1 ‘ip[0] & 0xf > 5’<\/p>\n

I use hex masks.<\/p>\n

Recap.. That’s rather simple, if you want to :
\n– keep the last 4 bits intact, use 0xf (binary 00001111)
\n– keep the first 4 bits intact, use 0xf0 (binary 11110000)<\/p>\n

DF bit (don’t fragment) set ?<\/strong>
\n—————————–<\/p>\n

Let’s now trying to know if we have fragmentation occuring, which is not desirable. Fragmentation occurs
\nwhen a the MTU of the sender is bigger than the path MTU on the path to destination.<\/p>\n

Fragmentation info can be found in the 7th and 8th byte of the IP header.<\/p>\n

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\n|Flags| Fragment Offset |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<\/p>\n

Bit 0: reserved, must be zero
\nBit 1: (DF) 0 = May Fragment, 1 = Don’t Fragment.
\nBit 2: (MF) 0 = Last Fragment, 1 = More Fragments.<\/p>\n

The fragment offset field is only used when fragmentation occurs.<\/p>\n

If we want to match the DF bit (don’t fragment bit, to avoid IP fragmentation) :<\/p>\n

The 7th byte would have a value of :
\n01000000 or 64 in decimal<\/p>\n

# tcpdump -i eth1 ‘ip[6] = 64’<\/p>\n

Matching fragmentation ?<\/strong>
\n————————<\/p>\n

– Matching MF (more fragment set) ? This would match the fragmented datagrams but wouldn’t match the last
\nfragment (which has the 2nd bit set to 0).
\n# tcpdump -i eth1 ‘ip[6] = 32’<\/p>\n

The last fragment have the first 3 bits set to 0… but has data in the fragment offset field.<\/p>\n

– Matching the fragments and the last fragments
\n# tcpdump -i eth1 ‘((ip[6:2] > 0) and (not ip[6] = 64))’<\/p>\n

A bit of explanations :
\n\u00ab\u00a0ip[6:2] > 0\u00a0\u00bb would return anything with a value of at least 1
\nWe don’t want datagrams with the DF bit set though.. the reason of the \u00ab\u00a0not ip[6] = 64\u00a0\u00bb<\/p>\n

If you want to test fragmentation use something like :
\nping -M want -s 3000 192.168.1.1<\/p>\n

Matching datagrams with low TTL
\n——————————-<\/p>\n

The TTL field is located in the 9th byte and fits perfectly into 1 byte.
\nThe maximum decimal value of the TTL field is thus 255 (11111111 in binary).<\/p>\n

This can be verified :
\n$ ping -M want -s 3000 -t 256 192.168.1.200
\nping: ttl 256 out of range<\/p>\n

+-+-+-+-+-+-+-+-+
\n| Time to Live |
\n+-+-+-+-+-+-+-+-+<\/p>\n

We can try to find if someone on our network is using traceroute by using something like this on the gateway :
\n# tcpdump -i eth1 ‘ip[8] < 5’ Matching packets longer than X bytes ———————————— Where X is 600 bytes # tcpdump -i eth1 ‘ip[2:2] > 600’<\/p>\n

More IP filtering
\n—————–<\/p>\n

We could imagine filtering source and destination addresses directly in decimal addressing.
\nWe could also match the protocol by filtering the 10th byte.<\/p>\n

It would be pointless anyhow, because tcpdump makes it already easy to filter out that kind of info.<\/p>\n

TCP header
\n———-<\/p>\n

0 1 2 3
\n0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\n| Source Port | Destination Port |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\n| Sequence Number |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\n| Acknowledgment Number |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\n| Data | |C|E|U|A|P|R|S|F| |
\n| Offset| Res. |W|C|R|C|S|S|Y|I| Window |
\n| | |R|E|G|K|H|T|N|N| |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\n| Checksum | Urgent Pointer |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\n| Options | Padding |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\n| data |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<\/p>\n

– Matching any TCP traffic with a source port > 1024
\n# tcpdump -i eth1 ‘tcp[0:2] > 1024’<\/p>\n

– Matching TCP traffic with particular flag combinations<\/p>\n

The flags are defined in the 14th byte of the TCP header.<\/p>\n

+-+-+-+-+-+-+-+-+
\n|C|E|U|A|P|R|S|F|
\n|W|C|R|C|S|S|Y|I|
\n|R|E|G|K|H|T|N|N|
\n+-+-+-+-+-+-+-+-+<\/p>\n

In the TCP 3-way handshakes, the exchange between hosts goes like this :<\/p>\n

1. Source sends SYN
\n2. Destination answers with SYN, ACK
\n3. Source sends ACK<\/p>\n

– If we want to match packets with only the SYN flag set, the 14th byte would have a binary
\nvalue of 00000010 which equals 2 in decimal.
\n# tcpdump -i eth1 ‘tcp[13] = 2’<\/p>\n

– Matching SYN, ACK (00010010 or 18 in decimal)
\n# tcpdump -i eth1 ‘tcp[13] = 18’<\/p>\n

– Matching either SYN only or SYN-ACK datagrams
\n# tcpdump -i eth1 ‘tcp[13] & 2 = 2’<\/p>\n

We used a mask here. It will returns anything with the ACK bit set (thus the SYN-ACK combination as well)<\/p>\n

Let’s assume the following examples (SYN-ACK)<\/p>\n

00010010 : SYN-ACK packet
\n00000010 : mask (2 in decimal)
\n——–
\n00000010 : result (2 in decimal)<\/p>\n

Every bits of the mask match !<\/p>\n

– Matching PSH-ACK packets
\n# tcpdump -i eth1 ‘tcp[13] = 24’<\/p>\n

– Matching any combination containing FIN (FIN usually always comes with an ACK so we either
\nneed to use a mask or match the combination ACK-FIN)
\n# tcpdump -i eth1 ‘tcp[13] & 1 = 1’<\/p>\n

– Matching RST flag
\n# tcpdump -i eth1 ‘tcp[13] & 4 = 4’<\/p>\n

Actually, there’s an easier way to filter flags :
\n# tcpdump -i eth1 ‘tcp[tcpflags] == tcp-ack’<\/p>\n

– Matching all packages with TCP-SYN or TCP-FIN set :
\n# tcpdump ‘tcp[tcpflags] & (tcp-syn|tcp-fin) != 0<\/p>\n

By looking at the TCP state machine diagram (http:\/\/www.wains.be\/pub\/networking\/tcp_state_machine.jpg)
\nwe can find the different flag combinations we may want to analyze.<\/p>\n

Ideally, a socket in ACK_WAIT mode should not have to send a RST. It means the 3 way handshake has not completed.
\nWe may want to analyze that kind of traffic.<\/p>\n

Matching SMTP data :
\n——————–<\/p>\n

I will make a filter that will match any packet containing the \u00ab\u00a0MAIL\u00a0\u00bb command from SMTP exchanges.<\/p>\n

I use something like http:\/\/www.easycalculation.com\/ascii-hex.php to convert values from ASCII to hexadecimal.<\/p>\n

\u00ab\u00a0MAIL\u00a0\u00bb in hex is 0x4d41494c<\/p>\n

The rule would be :<\/p>\n

# tcpdump -i eth1 ‘((port 25) and (tcp[20:4] = 0x4d41494c))’<\/p>\n

It will check the bytes 21 to 24. \u00ab\u00a0MAIL\u00a0\u00bb is 4 bytes\/32 bits long..<\/p>\n

This rule would not match packets with IP options set.<\/p>\n

This is an example of packet (a spam, of course) :<\/p>\n

# tshark -V -i eth0 ‘((port 25) and (tcp[20:4] = 0x4d41494c))’
\nCapturing on eth0
\nFrame 1 (92 bytes on wire, 92 bytes captured)
\nArrival Time: Sep 25, 2007 00:06:10.875424000
\n[Time delta from previous packet: 0.000000000 seconds]
\n[Time since reference or first frame: 0.000000000 seconds]
\nFrame Number: 1
\nPacket Length: 92 bytes
\nCapture Length: 92 bytes
\n[Frame is marked: False]
\n[Protocols in frame: eth:ip:tcp:smtp]
\nEthernet II, Src: Cisco_X (00:11:5c:X), Dst: 3Com_X (00:04:75:X)
\nDestination: 3Com_X (00:04:75:X)
\nAddress: 3Com_X (00:04:75:X)
\n…. …0 …. …. …. …. = IG bit: Individual address (unicast)
\n…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)
\nSource: Cisco_X (00:11:5c:X)
\nAddress: Cisco_X (00:11:5c:X)
\n…. …0 …. …. …. …. = IG bit: Individual address (unicast)
\n…. ..0. …. …. …. …. = LG bit: Globally unique address (factory default)
\nType: IP (0x0800)
\nInternet Protocol, Src: 62.163.X (62.163.X), Dst: 192.168.X (192.168.X)
\nVersion: 4
\nHeader length: 20 bytes
\nDifferentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
\n0000 00.. = Differentiated Services Codepoint: Default (0x00)
\n…. ..0. = ECN-Capable Transport (ECT): 0
\n…. …0 = ECN-CE: 0
\nTotal Length: 78
\nIdentification: 0x4078 (16504)
\nFlags: 0x04 (Don’t Fragment)
\n0… = Reserved bit: Not set
\n.1.. = Don’t fragment: Set
\n..0. = More fragments: Not set
\nFragment offset: 0
\nTime to live: 118
\nProtocol: TCP (0x06)
\nHeader checksum: 0x08cb [correct]
\n[Good: True]
\n[Bad : False]
\nSource: 62.163.X (62.163.X)
\nDestination: 192.168.X (192.168.XX)
\nTransmission Control Protocol, Src Port: 4760 (4760), Dst Port: smtp (25), Seq: 0, Ack: 0, Len: 38
\nSource port: 4760 (4760)
\nDestination port: smtp (25)
\nSequence number: 0 (relative sequence number)
\n[Next sequence number: 38 (relative sequence number)]
\nAcknowledgement number: 0 (relative ack number)
\nHeader length: 20 bytes
\nFlags: 0x18 (PSH, ACK)
\n0… …. = Congestion Window Reduced (CWR): Not set
\n.0.. …. = ECN-Echo: Not set
\n..0. …. = Urgent: Not set
\n…1 …. = Acknowledgment: Set
\n…. 1… = Push: Set
\n…. .0.. = Reset: Not set
\n…. ..0. = Syn: Not set
\n…. …0 = Fin: Not set
\nWindow size: 17375
\nChecksum: 0x6320 [correct]
\n[Good Checksum: True]
\n[Bad Checksum: False]
\nSimple Mail Transfer Protocol
\nCommand: MAIL FROM:\\r\\n
\nCommand: MAIL
\nRequest parameter: FROM:<\/p>\n

Matching HTTP data :
\n——————–<\/p>\n

Let’s make a filter that will find any packets containing GET requests
\nThe HTTP request will begin by :<\/p>\n

GET \/ HTTP\/1.1\\r\\n (16 bytes counting the carriage return but not the backslashes !)<\/p>\n

If no IP options are set.. the GET command will use the byte 20, 21 and 22
\nUsually, options will take 12 bytes (12nd byte indicates the header length, which should report 32 bytes).
\nSo we should match bytes 32, 33 and 34 (1st byte = byte 0).<\/p>\n

Tcpdump is only able to match data size of either 1, 2 or 4 bytes, we will take the following ASCII
\ncharacter following the GET command (a space)<\/p>\n

\u00ab\u00a0GET \u00a0\u00bb in hex : 47455420<\/p>\n

# tcpdump -i eth1 ‘tcp[32:4] = 0x47455420’<\/p>\n

Matching HTTP data (exemple taken from tcpdump man page) :<\/p>\n

# tcpdump -i eth1 ‘tcp port 80 and (((ip[2:2] – ((ip[0]&0xf)<<2)) – ((tcp[12]&0xf0)>>2)) != 0)’<\/p>\n

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\nip[2:2] = | Total Length |
\n+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<\/p>\n

+-+-+-+-+-+-+-+-+
\nip[0] = |Version| IHL |
\n+-+-+-+-+-+-+-+-+<\/p>\n

+-+-+-+-+-+-+-+-+
\nip[0]&0xf = |# # # #| IHL | <– that’s right, we masked the version bits with 0xf or 00001111 in binary +-+-+-+-+-+-+-+-+ +-+-+-+-+ | Data | tcp[12] = | Offset| | | +-+-+-+-+ So what we are doing here is \u00ab\u00a0(IP total length – IP header length – TCP header length) != 0\u00a0\u00bb We are matching any packet that contains data. We are taking the IHL (total IP lenght Matching other interesting TCP things : ————————————— SSH connection (on any port) : We will be looking for the reply given by the SSH server. OpenSSH usually replies with something like \u00ab\u00a0SSH-2.0-OpenSSH_3.6.1p2\u00a0\u00bb. The first 4 bytes (SSH-) have an hex value of 0x5353482D. # tcpdump -i eth1 ‘tcp[(tcp[12]>>2):4] = 0x5353482D’<\/p>\n

If we want to find any connection made to older version of OpenSSH (version 1, which are insecure and subject to MITM attacks) :
\nThe reply from the server would be something like \u00ab\u00a0SSH-1.99..\u00a0\u00bb<\/p>\n

# tcpdump -i eth1 ‘(tcp[(tcp[12]>>2):4] = 0x5353482D) and (tcp[((tcp[12]>>2)+4):2] = 0x312E)’<\/p>\n

Explanation of >>2 can be found below in the reference section.<\/p>\n

UDP header
\n———-<\/p>\n

0 7 8 15 16 23 24 31
\n+——–+——–+——–+——–+
\n| Source | Destination |
\n| Port | Port |
\n+——–+——–+——–+——–+
\n| | |
\n| Length | Checksum |
\n+——–+——–+——–+——–+
\n| |
\n| DATA … |
\n+———————————–+<\/p>\n

Nothing really interesting here.<\/p>\n

If we want to filter ports we would use something like :
\n# tcpdump -i eth1 udp dst port 53<\/p>\n

ICMP header
\n———–<\/p>\n

See different ICMP messages :
\nhttp:\/\/img292.imageshack.us\/my.php?image=icmpmm6.gif<\/p>\n

We will usually filter the type (1 byte) and code (1 byte) of the ICMP messages.<\/p>\n

Here are common ICMP types :<\/p>\n

0 Echo Reply [RFC792]
\n3 Destination Unreachable [RFC792]
\n4 Source Quench [RFC792]
\n5 Redirect [RFC792]
\n8 Echo [RFC792]
\n11 Time Exceeded [RFC792]<\/p>\n

We may want to filter ICMP messages type 4, these kind of messages are sent in case of congestion of the network.
\n# tcpdump -i eth1 ‘icmp[0] = 4’<\/p>\n

If we want to find the ICMP echo replies only, having an ID of 500. By looking at the image with all the ICMP packet description
\nwe see the ICMP echo reply have the ID spread across the 5th and 6th byte. For some reason, we have to filter out with the value in hex.<\/p>\n

# tcpdump -i eth0 ‘(icmp[0] = 0) and (icmp[4:2] = 0x1f4)’<\/p>\n

References
\n———-<\/p>\n

tcpdump man page : http:\/\/www.tcpdump.org\/tcpdump_man.html
\nConversions : http:\/\/easycalculation.com\/hex-converter.php
\nFiltering HTTP requests : http:\/\/www.wireshark.org\/tools\/string-cf.html
\nFiltering data regardless of TCP options : http:\/\/www.wireshark.org\/lists\/wireshark-users\/201003\/msg00024.html<\/p>\n

Just in case the post disappears, here’s a copy of the last URL :<\/p>\n

From: Sake Blok <sake@xxxxxxxxxx>
\nDate: Wed, 3 Mar 2010 22:42:29 +0100
\nOr if your capturing device is capable of interpreting tcpdump style filters (or more accurately, BPF style filters), you could use:<\/p>\n

tcp[(((tcp[12:1] & 0xf0) >> 2) + 8):2] = 0x2030<\/p>\n

Which in English would be:
\n– take the upper 4 bits of the 12th octet in the tcp header ( tcp[12:1] & 0xf0 )
\n– multiply it by four ( (tcp[12:1] & 0xf0)>>2 ) which should give the tcp header length
\n– add 8 ( ((tcp[12:1] & 0xf0) >> 2) + 8 ) gives the offset into the tcp header of the space before the first octet of the response code
\n– now take two octets from the tcp stream, starting at that offset ( tcp[(((tcp[12:1] & 0xf0) >> 2) + 8):2] )
\n– and verify that they are \u00a0\u00bb 0″ ( = 0x2030 )<\/p>\n

Of course this can give you false positives, so you might want to add a test for \u00ab\u00a0HTTP\u00a0\u00bb and the start of the tcp payload with:<\/p>\n

tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450<\/p>\n

resulting in the filter:<\/p>\n

tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 and tcp[(((tcp[12:1] & 0xf0) >> 2) + 8):2] = 0x2030<\/p>\n

A bit cryptic, but it works, even when TCP options are present (which would mess up a fixed offset into the tcp data).<\/p>\n

Cheers,
\nSake<\/p>\n

The end ?
\n———<\/p>\n

Please send more useful recipes !<\/p>\n\n","protected":false},"excerpt":{"rendered":"

TCPDUMP ADVANCED FILTERS =========================== Merci \u00e0 Sebastien Wains http:\/\/www.wains.be $Id: tcpdump_advanced_filters.txt 36 2013-06-16 13:05:04Z sw $ Notes : J’ai l’habitude de sp\u00e9cifier l’interface sur laquelle \u00e9couter. C’est l’option -i que l’on retrouve dans tous les exemples suivants. Chacune des r\u00e8gles suivantes a \u00e9t\u00e9 test\u00e9e depuis mon laptop connect\u00e9 \u00e0 un r\u00e9seau wifi au travers de […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20,39],"tags":[],"_links":{"self":[{"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3701"}],"collection":[{"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=3701"}],"version-history":[{"count":50,"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3701\/revisions"}],"predecessor-version":[{"id":4390,"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=\/wp\/v2\/posts\/3701\/revisions\/4390"}],"wp:attachment":[{"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=3701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=3701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.laurentmarot.fr\/wordpress\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=3701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}