K2289: Using advanced tcpdump filters

Transcription

1 K2289: Using advanced tcpdump filters Non-Diagnostic Original Publication Date: May 17, 2007 Update Date: Sep 21, 2017 Topic Introduction Filtering for packets using specific TCP flags headers Filtering for packets using source or destination port Filtering for packets using specific IP addresses Filtering for packets using ICMP header properties General trace principles References Introduction When you are analyzing a captured tcpdump, it is often useful to find packets with specific properties. To assist with this process, the tcpdump utility allows the creation of filter expressions based on the following protocol types: ether fddi ip arp rarp tcp udp icmp TCP flag headers are located in the 14th byte of the header. Since numbering starts at byte 0, the TCP flag header is in byte 13. Note: For diagrams of the TCP packet structure, refer to Byte 13 can contain up to eight one-bit flags; however, TCP can use only six flags. The other two bits are reserved and should be set to zero. For TCP headers with a single flag, there is one byte per bit and byte 13 contains the following binary values in decimal: Final (Fin) = 1 Sync (Syn) = 2

2 Reset (Rst) = 4 Push = 8 Acknowledgement (ack) = 16 Urgent (Urg) = 32 Reserved = 64 and 128 (should be zero) If multiple flags are set for the TCP header, the value of byte 13 is the binary sum of the values for all the bits that are set. For example: Fin, ack = 17 (1 + 16) Syn, ack = 18 (2 + 16) Push, ack = 24 (8 + 16) Fin, Push = 9 (1 + 8) Fin, Push, ack = 25 ( ) Note: When capturing traffic to send to F5 technical support, you should not use the advanced filters unless directed to from technical support. Filtering for packets using specific TCP flags headers If you know the expected value for byte 13 of the TCP header, you can create a filter to look for that specific byte using the following syntax: header[byte #] == value For example, if you want to see only the Syn packets, you would create the following filter to report all TCP headers that contain a TCP flag byte equal to 2 flag (Syn flag set): Note: The following examples assume a byte length of 1. tcpdump -ni internal 'tcp[13] == 2' Important : You must use the half-quotes (') in all the filters to protect the filter expression from the shell so that it is passed, intact, to the tcpdump utility. The output would appear similar to the following example: tcpdump: listening on internal 23:36: > : S : (0) win :36: > : S : (0) win :36: > : S : (0) win :36: > : S : (0) win 1638 To view only the Syn and ack packets, you would create the following filter to report all TCP headers that contain a TCP flag byte equal to 18 (Syn flag set + ack flag set = = 18): tcpdump -ni internal 'tcp[13] == 18' The output would appear similar to the following example:

3 tcpdump: listening on internal 23:38: > : S : (0) ack :38: > : S : (0) ack :38: > : S : (0) ack :38: > : S : (0) ack 2196 ^C 28 packets received by filter 0 packets dropped by kernel To view the Syn packets and the Syn and ack packets, you would create the following filter that accepts either value for the flag byte: tcpdump -ni internal 'tcp[13] == 18' or 'tcp[13] == 2' You could also create a filter that looks for the set Syn bit and ignores the rest of the flags in the header. You must set the filter to perform a logic AND (&) to remove all but the value of the Syn bit and then test it. For example, if the TCP flags are and the mask for Syn is (2 in binary) then = You can then test the resulting value against the Syn flag, by setting the filter as follows: tcpdump -ni internal 'tcp[13] & 2 == 2' The output would appear similar to the following example: tcpdump: listening on internal 23:44: > : S : (0) win :44: > : S : (0) win :44: > : S : (0) win :44: > : S : (0) ack :44: > : S : (0) win :44: > : S : (0) ack :44: > : S : (0) ack :44: > : S : (0) ack 1446 ^ C28 packets received by filter 0 packets dropped by kernel You can also use the following filter for a more general setting; however, it is best to write the rule as specifically as possible so that you do not have to re-write it later in the event that further troubleshooting is required: 'tcp[13] & 2!= 0' The!= [number] construct checks if any of the flags included in [number] are set and the == [number] construct checks if all the TCP header flags in [number] are set. Following are additional examples of filters for TCP header flags: Criteria Filter View only the Fin bit set 'tcp[13] == 1'

4 View only the Push bit set 'tcp[13] == 8' View only the Syn bit set 'tcp[13] == 2' View only Syn set, ignore the others 'tcp[13] & 2 == 2' View only Syn and ack set 'tcp[13] == 18' View Syn set and ack set, ignore all others 'tcp[13] & 18 == 18' View Rst set, ignore the others 'tcp[13] & 4 == 4' View both Syn and Fin set 'tcp[13] & 3 == 3' View either Syn or Fin set 'tcp[13] & 3!= 0' View only Syn or only Fin set 'tcp[13] == 2 or tcp[13] == 1' Filtering for packets using source or destination port You can create a filter that spans several bytes of the TCP header, such as the two-byte source and destination port numbers. (In the TCP header, the source port is bytes 0 and 1 and the destination port is bytes 2 and 3.) Note: The IANA Assigned Internet Protocol Numbers list may be found on the Protocol Numbers page. As with the TCP flag example, the first entry of the filter is the offset and the second entry is the number of bytes to check. If there is no second entry, the length defaults to 1 (as do the previous examples in this article). The first two bytes of a TCP packet are the source port. If its offset is zero and the length is 2 bytes, the filters are: tcp[0:2] for the source and tcp[2:2] for the destination port. You can view traffic with the same source and destination using the following filter: 'tcp[0:2] == tcp[2:2]' For example, to view traffic destination on TCP port 80, you can use the following filter: 'tcp[2:2] == 80' Filtering for packets using specific IP addresses You can configure filters for IP header properties using the same logic as the port source and destination filter. You can view all traffic with the same source and destination IP by using the following filter: 'ip[12:4] == ip[16:4]' Note: You can combine the TCP port filter and the IP address filter to detect the LAND attack. The flags section of an IP header is only 3 bits long, and 1 bit is reserved; therefore, the only 2 bits that you can toggle in this octet are: the 1 bytes These correspond to the following two IP flags: DF (don't fragment) bit set (IP)

5 Example filter: 'ip[6] & 64!= 64' MF (more fragments) bit set (IP) Example filter: 'ip[6] & 32!= 32' Filtering for packets using ICMP header properties The first byte in an ICMP packet is the message type; the second byte is the code. You can refer to net/rfc792.txt for the numbers you need to use in the following filter, changing the two sets of numbers to the appropriate type and code as provided in RFC792. Following are type 3 Destination unreachable ICMP messages codes: Code Message 0 network unreachable 1 host unreachable 2 protocol unreachable 3 port unreachable 4 fragmentation needed but don't fragment bit set Following are type 11 Time exceeded ICMP messages codes: Code Message 0 TTL exceeded in transit (too many hops? routing loop?) 1 fragment reassembly time exceeded (frag attack? bad streaming media performance?) The IP header byte 9 is the protocol field, and the ICMP protocol is represented by a value of 1. For example: tcpdump -ni internal 'ip[9] == 1' The output would appear similar to the following example: tcpdump: listening on internal 00:06: > : icmp: echo request 00:06: > : icmp: echo reply 00:06: > : icmp: echo request

6 00:06: > : icmp: echo reply ^C Following are additional examples of filters for packets using ICMP header properties: Criteria Filter View only the ICMP Echo Requests 'icmp[0] == 8' View only the ICMP Echo Replies 'icmp[0] == 0' View all ICMP packets except ICMP Echo Requests and Replies View only the ICMP "Fragmentation needed but DF bit set" (Type 3, code 4) packets Non-header filters Following are examples of non-header filters. Match against all traffic involving a particular network: net Match against a more specific network: net mask Match against a more specific network, using CIDR notation: net /29 Match against all traffic from a specific network: src net 192 Packet length Following are examples of packet length filters: Match packets 1400 bytes long: len == 1400 Match packets greater than or equal to 1400 bytes: 'len >= 1400' 802.1q VLAN tagging Following are examples of VLAN tagging filters: Match packets with a VLAN tag of 10: vlan 10 'icmp[0]!= 8 and icmp [0]!= 0' 'icmp[0] == 3 and icmp [1] == 4'

7 To get the same result, without using the built-in keyword (such as on non-f5 modified versions of tcpdump ), use the following filter: 'ether[14:2] & 4095 == 10' This works because the Ethernet header appears as follows (per-bit): SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD Each character in the Ethernet header is defined as follows: Character Definition Size S src 6 bytes D dst 6 bytes T type 2 bytes P priority 3 bits C canonical 1 bit Q 802.1Q vlan tag 12 bits Therefore, to ensure that you are not including the priority or canonical bits as part of the VLAN tag, perform a logic AND of 4095 against the contents of bytes 14 and 15 as follows: & = General trace principles Tracing a single session bi-directionally When tracing a single session, generally the ephemeral port is enough (the dynamic port used by the client). For example, the following stream shows two unique TCP sessions using the ephemeral ports 1039, and 1034: > : P 1:99(98) ack 1 win > : P 1:147(146) ack 99 win > :. ack 3085 win > :. 4109:4621(512) ack 529 win > :. 4621:5133(512) ack 529 win > :. ack 4109 win > :. 5133:5645(512) ack 529 win You could use this ephemeral port to isolate a single session, for example port 1039, to view only the following: > : P 1:99(98) ack 1 win > : P 1:147(146) ack 99 win 16616

8 If the ephemeral port is not specific enough to use as a unique identifier (which can be the case in very large tcpdumps), you could filter using more criteria. For example, port 1039 and host and port 443 and host Tracing a single session uni-directionally It may make more sense to filter traffic in only one direction. For example, using src port 443 to view only the following: > : P 1:147(146) ack 99 win > :. 4109:4621(512) ack 529 win > :. 4621:5133(512) ack 529 win > :. 5133:5645(512) ack 529 win Generally, however, it is more useful to filter what a client sends (uni-directionally, but in the opposite direction than the first example). For example, using src port 1039 to view the following: > : P 1:99(98) ack 1 win 8576 Or to gather everything a client sends on any port, using src host to view the following: > : P 1:99(98) ack 1 win > :. ack 3085 win > :. ack 4109 win 8576 Or lastly, to gather a single session from a client and server using the same ports for two different connections. For example: > 4354 is one connection > 4343 is another connection It is not generally done, but if you recognize those ports (the iquery protocol) you can understand the need to filter in this way. To create a filter that tracks connections where both the source and destination are the same port, you would modify a specific filter and add more detail. For example: '( src port 1039 and src host and dst host and dst port 443 )' Or: '( dst port 1039 and dst host and src host and src po

9 The output would appear similar to the following example: > : P 1:99(98) ack 1 win 8576 Note: It would not make sense to filter a TCP stream this short. If the whole packet dump is only a few hundred lines you can use grep to efficiently view it without writing complex filters. However, if you are dealing with a large tcpdump (such as 200 megabytes), filters are the only way to make it manageable. Additional Ethernet header details The Ethernet header is very short (14 bytes), with only 3 fields ( src, dst, and type). The source ( src) and destination ( dst) are the hardware (MAC) addresses for the sending and receiving units (respectively). The type field indicates the next layer protocol that is being transported. For example: Protocol Decimal HEX IP x0800 ARP x0806 VLAN x8100 Slow Protocols (for example, LACP) x8809 Note: In the case of VLANs, there are 2 additional bytes after the type field, indicating the VLAN tag. You can filter traffic based on the type field by using the filter ether proto <protocol>. Protocol can be either the decimal or hexadecimal value, as noted in the previous table. Tracing Ethernet header type LACP LACP is handled by the switch fabric, therefore packets must be captured directly on the physical interface, for example, 1.1, as opposed to the VLAN or 0.0. To capture only LACP packets, use the following syntax: tcpdump -ni <interface> -e ether proto 0x8809 Note: The -e switch prints the link-level header on each line. For example, to capture LACP packets on interface 1.1 of a Link Aggregation Group (LAG), type the following command: tcpdump -ni 1.1 -e ether proto 0x8809 The output would look similar to the following example: 15:21: :50:56:92:2a:82 > 01:80:c2:00:00:02, ethertype 802.1Q (0x8100), length 128: vlan 0, p 0, ethertype Slow Protocols, LACPv1, length: 110

10 Note: LACP sends one packet per second during its initial detection period, to a multicast MAC of 01:80:c2: 00:00:02. After the connection is either established or marked down (LACP marks the link down after three consecutive control packets with no response from the peer), LACP packets are sent either every thirty seconds, if configured for a LONG timeout, or every one second, if configured for a SHORT timeout. If the LAG is configured for a LONG timeout in ACTIVE mode, then you may only see one packet every thirty seconds. Because of this, F5 recommends that you allow the capture to run for at least one full minute. References This section contains specific examples as well as suggested reading. Miscellaneous filter examples Match all arps using either of the following two methods: arp ether[12:2] == 2054 Match all IP packets using either of the following two methods: ip ether[12:2] == 2048 Match against a specific hardware (MAC) address: ether host 0:2:b3:7:10:73 Match against src: ether src host 0:2:b3:7:10:73 Gather all traffic passing through a specific gateway (firewall, router), where 0:2:b3:7:10:73 is the gateway's MAC address and is the gateway's IP address, excluding traffic to and from the gateway itself:: ether host 0:2:b3:7:10:73 and not host Note: If you need to perform this type of task frequently, you can make the appropriate entries in the /etc /ethers and /etc/hosts files and specify your gateways by name. ASCII header diagrams Following are additional header diagrams examples. IP header (RFC791) Version IHL Type of Service Total Length

11 Identification Flags Fragment Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Padding TCP header (STD7) Source Port Destination Port Sequence Number Acknowledgment Number Data U A P R S F Offset Reserved R C S S Y I Window G K H T N N Checksum Urgent Pointer Options Padding data UDP header (STD6) Source Destination Port Port Length Checksum data octets ICMP header (RFC792) ICMP ECHO / ECHO REPLY Type Code Checksum

12 Identifier Sequence Number Data Ethernet header (basically IEEE 802.3) Preamble (8) Preamble cont. Destination address (6) Destination address cont. Source address (6) Source address cont. Type (2) Pri C 802.1q tag if type!=0x8100, prev. 2 bytes are part of this field ( bytes of data)... Frame Check Sequence, FCS (4) Note: Although the previous diagram correctly shows both Preamble and Frame Check Sequence, tcpdump does not include these in the totals for header bytes (presumably because the data is fixed, so there is no reason to match against it.) As a result, if you are basing ether expressions on this chart, you must subtract 12 (as if the Preamble and FCS sections do not exist.) DNS header (RFC1035) MESSAGE FORMAT Header Question the question for the name server Answer RRs answering the question Authority RRs pointing toward an authority Additional RRs holding additional information HEADER ID QR Opcode AA TC RD RA Z RCODE

13 QDCOUNT ANCOUNT NSCOUNT ARCOUNT QUESTION / QNAME / / / QTYPE QCLASS RESOURCE RECORDS: ANSWER/ADDITIONAL/AUTHORITY / / / NAME / TYPE CLASS TTL RDLENGTH / RDATA / / / MESSAGE COMPRESSION OFFSET OFFSET refers to the byte before a preceding occurrence of a domain name. LDAP LDAP message Always 0x30 Length Always 0x02 Len of msgid msgid... Protocol Op. Operation ICMP codes

14 Type Code Definition 0 0 ECHO REPLY (ping reply) 3 DESTINATION UNREACHABLE 0 network unreachable 1 host unreachable 2 protocol unreachable 3 port unreachable 4 frag needed 5 source route failed 6 destination network unknown 7 destination host unknown 8 source host isolated 9 destination network administratively prohibited 10 destination host administratively prohibited 11 network unreachable for TOS 12 host unreachable for TOS 13 prohibited by filtering 14 host precedence violation 15 precedence cutoff 4 0 SOURCE QUENCH 5 REDIRECT 0 network 1 host 2 network & TOS 3 host & TOS 8 0 ECHO REQUEST (ping request) 9 0 ROUTER ADVERTISEMENT 10 0 ROUTER SOLICITATION 11 TIME EXCEEDED 0 TTL=0 during transmit 1 TTL=0 during reassembly 12 PARAMETER PROBLEM 13 0 TIMESTAMP REQUEST 14 0 TIMESTAMP REPLY 15 0 INFO REQUEST 16 0 INFO REPLY 17 0 ADDRESS MASK REQUEST 18 0 ADDRESS MASK REPLY

15 Supplemental Information SANS Institute TCP/IP and tcpdump primer Note: This link takes you to a resource outside of AskF5. The third party could remove the document without our knowledge. K411: Overview of packet tracing with the tcpdump utility K4714: Performing a packet trace and providing the results to F5 Technical Support K6546: Recommended methods and limitations for running tcpdump on a BIG-IP system K1893: Packet trace analysis K13637: Capturing internal TMM information with tcpdump K7227: Considerations when using the tcpdump utility with tagged VLAN traffic K13328: Troubleshooting LDAP authentication with tcpdump K13301: Overview of packet tracing a BIG-IP APM Network Access tunnel with the tcpdump utility K7823: Troubleshooting and debugging Enterprise Manager icontrol connectivity K5564: Saving large tcpdump packet traces when disk space is limited