Writing Capture Filters
|
| < Day Day Up > |
|
Ethereal’s capture filters use the pcap library’s filter mechanism. These filters are often called tcpdump filters, as tcpdump is the most famous program that uses the pcap library, and the filter syntax itself is documented in the tcpdump manpage, or manual page. Any program that uses pcap, like tcpdump or Ethereal, can use this filter syntax.
While tcpdump can decode many protocols, its filter language cannot directly address other protocols. The keywords defined in the tcpdump filter language are oriented mostly toward layer 2 and TCP/IP filtering, with few exceptions.
| Note | A manpage, man page, or manual page, is the documentation that comes with a UNIX program. Man pages can be read with the UNIX man command. For example, to read the tcpdump man page, you would type man tcpdump. The Ethereal man page can be read with man ethereal. Many man pages are available as HyperText Markup Language (HTML) on the web. The tcpdump man page is at www.tcpdump.org/tcpdump_man.html and Ethereal man pages can be viewed at www.ethereal.com by clicking on the links under Information | Documentation on the left-hand side of the web page. |
Tcpdump Syntax Explained
The tcpdump filter language gives you many ways to look at data inside a packet. The language is designed to give you easy access to the most commonly used fields from the layer 2 and TCP/IP (Transmission Control Protocol/_Internet Protocol) group of protocols by providing keywords that are used to match values of host addresses, hardware addresses, and ports. But, the filter language can handle more than just layer 2 and TCP/IP protocols. It also allows you to look for a number of specific protocols, look at arbitrary bytes in the packet data, and look at meta-data bout the packet.
Host Names and Addresses
Probably the most common use of a tcpdump filter is to capture network traffic originating from or destined for a particular Internet Protocol (IP) address. You can identify an IPv4 (Internet Protocol version 4), IPv6 (Internet Protocol version 6) address, or a hostname by using the host keyword. For example, to captures all IPv4 packets that have a source or destination address of 192.168.1.1, you would use:
host 192.168.1.1
Or, you can use an IPv6 address to capture IPv6 packets:
host 2::8100:2:30a:c392:fc5a
You can also use a hostname or a DNS (Domain Name Service), either which resolves to either an IPv4 or IPv6 address:
host wizard host www.ethereal.com
These three examples will return any IP packet, including Transmission Control Protocol (TCP), User Datagram Protocol (UDP), and any other protocol riding on top of IP, as long as it has an IP source address or IP destination address matching the given IP address or hostname. Furthermore, if the hostname resolves to more than one IP address, as Domain Name System (DNS) entries can, then all of those resolved IP addresses are used in the match.
If you would like to narrow the filter to capture packets that only originate from an IP address, then you use the src (short for source) keyword modifier:
src host 192.168.1.1
Similarly, to match a destination IP address, you use the dst (short for destination) keyword modifier:
dst host 192.168.255.255
You can also use a shorthand notation which takes advantage of the fact that host is understood from src and dst, so that you can check host addresses without using host:
src 192.168.1.1 dst 192.168.255.255
The host keyword lets you check for an IP address. Similarly, you can use the net keyword to check for an IP network. Use the net keyword in combination with an address formatted in classless interdomain routing (CIDR) notation. CIDR notation is made up of an IPv4 address and a number, separated by a slash. The number after the slash specifies the number of bits, out of the thirty-two bits in the IPv4 address, that make up the network portion of the address. If you want to look at packets coming from any host on the 192.168.100.0 network, which uses 24 bits for the network number (a 255.255.255.0 netmask), then you would use this capture filter:
src net 192.168.100.0/24
Hardware Addresses (MAC Addresses)
If, instead of using IP addresses, you wish to capture packets based on the hardware address of the network card, you use the ether (short for Ethernet) modifier. For example, to find all broadcast packets, which are packets destined for the hardware address ff:ff:ff:ff:ff:ff, use:
ether host ff:ff:ff:ff:ff:ff
There are also fddi (fiber distributed data interface) and tr (token-ring) keywords that match the hardware addresses of NICs (Network Interface Cards). However, since Ethernet, FDDI, and token-ring all contain 6-byte hardware addresses in their protocol headers, the tcpdump filter language treats ether, fddi, and tr as synonyms. It doesn’t matter which of the three topologies your interface card has, you can use any of the three keywords. In practice, ether is most commonly used.
The ether modifier is placed before the dst and src modifiers; to capture packets destined for a particular hardware address, you enter:
ether dst host ff:ff:ff:ff:ff:ff
Again, you can use short hand, because dst implies host, and instead enter:
ether dst ff:ff:ff:ff:ff:ff
To filter packets based on the source hardware address, the src modifier is again used:
ether src host 00:f9:06:aa:01:03 ether src 00:f9:06:aa:01:03
Ports
The port keyword can be used to capture packets that are destined for certain applications, because some applications communicate on well-known TCP and UDP ports. For example, to capture only Hypertext Transfer Protocol (HTTP) packets, which are commonly sent on TCP port 80, you can use:
port 80
However, this checks for packets on both UDP port 80 and TCP port 80. To narrow it to TCP, tcp can be used as a qualifier:
tcp port 80
Or, if you have http defined for a port number in the /etc/services file on UNIX, you can use:
tcp port http
The udp keyword is also available in case you want to capture UDP packets on a certain port. In either instance, the directional qualifiers src and dst can be used. If you are sniffing for UDP requests being sent to a DNS server, you would want to capture UDP packets destined for port 53, as that’s the port for DNS.
udp dst port 53
If you want the replies, you would look for UDP packets with a source of port 53:
udp src port 53
Logical Operations
The tcpdump filter language allows you to combine several statements with logical operators to create complicated filters. The logic operator not reverses the value of a test, while and and or let you join multiple tests. These three logic keywords have alternate representations, which are used in the C programming language:
-
not is equivalent to !
-
and is equivalent to &&
-
or is equivalent to ||
You can also use parentheses when you need to group multiple statements with logical operations. Parentheses are not always needed, but can be used to make the filter easier to understand.
As an example of negation, to capture everything except DNS lookups, use:
not port 53
Normally, port 53 would capture any TCP or UDP packets with a source or destination port of 53. The logical keyword not reverses the sense of the filter, so that everything is captured except for TCP or UDP packets with a source or destination port of 53.
The logical operator and is used to require that multiple conditions in a test be true. For example, to look at telnet packets to or from the host www.ethereal.com, this filter would be used:
host www.ethereal.com and port telnet
If you wanted either telnet packets or ssh packets, you would use or:
port telnet or port ssh
To combine the port telnet or port ssh test with a test for the www.ethereal.com host, you use and, but you also need to use parentheses:
host www.ethereal.com and ( port telnet or port ssh )
The logical operators and and or have the same precedence, which means that they are analyzed in the order that they are listed in the capture filter. If the parentheses are not used, the capture filter would test for telnet packets to or from the host www.ethereal.com, or ssh packets to or from any IP:
host www.ethereal.com and port telnet or port ssh
Protocols
The tcpdump filter syntax provides some protocol names as keywords, allowing you to test for the existence of these protocols. These protocol keywords are:
-
aarp AppleTalk Address Resolution Protocol
-
ah Authentication Header
-
arp Address Resolution Protocol
-
atalk AppleTalk
-
clnp Connectionless Network Protocol
-
decnet Digital Equipment Corporation Network protocol suite
-
esis (or “es-is”) End System-to-Intermediate System
-
esp Encapsulating Security Payload
-
icmp Internet Control Message Protocol
-
icmp6 Internet Control Message Protocol, for IPv6
-
igmp Internet Group Management Protocol
-
igrp Interior Gateway Routing Protocol
-
ip Internet Protocol
-
ip6 Internet Protocol version 6
-
ipx Internetwork Packet Exchange
-
isis (or “is-is”) Intermediate System-to-Intermediate System
-
iso International Organization for Standardization
-
lat Local Area Transport
-
mopdl Maintenance Operation Protocol
-
moprc Maintenance Operation Protocol
-
netbeui NetBIOS Extended User Interface
-
pim Protocol Independent Multicast
-
rarp Reverse Address Resolution Protocol
-
sca Systems Communication Architecture
-
sctp Stream Control Transmission Protocol
-
stp Spanning Tree Protocol
-
tcp Transmission Control Protocol
-
udp User Datagram Protocol
-
vrrp Virtual Router Redundancy Protocol
For example, to capture all ICMP packets the capture filter is one word:
icmp
To capture everything that is not an IPX packet, use negation and the protocol keyword:
not ipx
We’ve talked about ports in TCP and UDP packets, but some protocols use the concept of protocol to indicate what type of payload it is carrying. For example, the IP header contains a protocol field whose numeric value indicates the type of payload it is carrying. Possible values for this protocol field are 1 for ICMP, 6 for TCP, and 17 for UDP. On a UNIX system, you can find a list of IP protocol numbers in the /etc/protocols file.
The tcpdump filter syntax allows you to test the proto field (short for protocol) for the protocols that have it. You can use the proto keyword with the ether, fddi, tr, ppp, ip, ip6, and iso protocol keywords. For example, while you can test for the presence of the TCP protocol via the tcp keyword, you could also check for 6 as the value of the IP protocol field, as “6” designates TCP.
ip proto 6
Protocol Fields
While tcpdump can decode many protocols, the tcpdump filter syntax does not let you easily test for the values of all fields that tcpdump knows how to parse. You’ve seen that many protocol names are provided as keywords, but very few fields within these protocols have names in the tcpdump filter syntax.
Tcpdump filters do allow you to grab and compare values out of the packet, so that if the offset of a field within a protocol is known, its value can be checked. This method is not as elegant as using a field name, but it works.
To retrieve a single byte from a packet, you use square brackets to indicate the offset of that byte from the beginning of a particular protocol. Offsets start at zero, so that tcp[0] would give the first byte in the TCP header, while tcp[1] would give the second byte. Table 5.1 shows the bit layout of the TCP header, as defined by RFC (Request For Comments) 793, available at www.ibiblio.org/_pub/docs/rfc/rfc793.txt.
| |
Instead of a one-byte integer, you can also retrieve either a two-byte integer or a four-byte integer, using a colon inside the square brackets: tcp[0:2] and tcp[0:4]. Multi-byte integers are always extracted in network order, also known as big-endian order. To compute the value of multi-byte network-order integers, use these formulas:
-
2-byte value = byte0 * 0x100 + byte1
-
4-byte value = byte0 * 0x1000000 + byte1 * 0x10000 + byte2 * 0x100 + byte3
The numbers preceded by “0x” in the formulas are hexadecimal numbers.
Unfortunately, only some protocols allow you to retrieve bytes from their data. Interestingly, some protocols whose names could not be used as keywords allow you to retrieve their data by using square brackets. Square brackets can be used to retrieve bytes from these protocols:
-
arp Address Resolution Protocol
-
atalk Appletalk
-
decnet Digital Equipment Corporation Network protocol suite
-
ether Ethernet
-
fddi Fiber Distributed Data Interface
-
icmp Internet Control Message Protocol
-
igmp Internet Group Management Protocol
-
igrp Interior Gateway Routing Protocol
-
ip Internet Protocol
-
lat Local Area Transport
-
link Link layer
-
mopdl Maintenance Operation Protocol
-
moprc Maintenance Operation Protocol
-
pim Protocol Independent Multicast
-
ppp Point-to-Point Protocol
-
rarp Reverse Address Resolution Protocol
-
sca Systems Communication Architecture
-
sctp Stream Control Transmission Protocol
-
tcp Transmission Control Protocol
-
tr Token-Ring
-
udp User Datagram Protocol
-
vrrp Virtual Router Redundancy Protocol
The value that is retrieved from the packet data is an integer, which can be compared with any of the numeric relations shown in Table 5.2.
| Numeric Relation | Meaning |
|---|---|
| > | Greater Than |
| >= | Greater Than or Equal To |
| < | Less Than |
| <= | Less Than or Equal To |
| = or == | Equal To |
| != | Not Equal To |
Additionally, the arithmetic operators +, -, *, and / are provided, as are the bit-wise operators & and |. The bitwise operator & allows you to logically AND the bits of integers, while | allows you to logically OR the bits.
For example, the icmp keyword will let you filter for any ICMP packet. But there are different types of ICMP packets, depending on their function. What if you wanted to look only for ICMP ping packets? The ICMP ping, or echo request/reply, packet layout is shown in Table 5.3. It comes from RFC 792, available at www.ibiblio.org/pub/docs/rfc/rfc792.txt.
| |
The ICMP protocol has a field called type, which indicates what type the ICMP packet is. If the type field is 8, then the packet is an ICMP echo (ping) request, while if the type field is 0, then the packet is an ICMP echo (ping) reply. That type field is a one-byte field at the very beginning of the ICMP protocol header. This capture filter tests for packets that are either ICMP ping requests or ICMP ping replies by retrieving that first byte:
icmp[0] == 8 or icmp[0] == 0
As a convenience, the libpcap authors have made available some constant value keywords that are named after ICMP fields. Their values give the offset and the possible values of those fields. The value keywords can be used so that the numbers they stand for need not be remembered. For example, the icmptype is equal to the offset of the ICMP type field (which is 0), the icmp-echo variable is equal to 8, which means that the ICMP packet is an echo request, and icmp-echoreply is equal to 0, which means that the ICMP packet is an echo reply. The test for ICMP ping requests and replies can be written as:
icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply
The keywords that define constant values for field offsets are listed in Table 5.4.
| Keyword | Value | Used in Protocol |
|---|---|---|
| icmptype | 0 | icmp |
| icmpcode | 1 | icmp |
| tcpflags | 13 | tcp |
Table 5.5 lists the keywords that provide names for the ICMP type values.
| Keyword | Value |
|---|---|
| icmp-echoreply | 0 |
| icmp-unreach | 3 |
| icmp-sourcequench | 4 |
| icmp-redirect | 5 |
| icmp-echo | 8 |
| icmp-routeradvert | 9 |
| icmp-routersolicit | 10 |
| icmp-timxceed | 11 |
| icmp-paramprob | 12 |
| icmp-tstamp | 13 |
| icmp-tstampreply | 14 |
| icmp-ireq | 15 |
| icmp-ireqreply | 16 |
| icmp-maskreq | 17 |
| icmp-maskreply | 18 |
Bitwise Operators
The TCP flags field is a bit-field. Bit-fields are integers in which the individual bits are used as separate fields. For example, the TCP flags field is an 8-bit integer field, but the bits in that integer represent independent fields that are either true or false, or 1 or 0. In the tcpdump filter language, the fields for TCP flags have keywords with constant values, as shown in Table 5.6.
| Keyword | Value |
|---|---|
| tcp-fin | 0x01 |
| tcp-syn | 0x02 |
| tcp-rst | 0x04 |
| tcp-push | 0x08 |
| tcp-ack | 0x10 |
| tcp-urg | 0x20 |
The tcpdump filter language defines keywords with constant values for the TCP flags field because it is very common to test for values of this field when looking at TCP problems, especially when related to firewalls or Network Address Translation (NAT). It is important to know how to use bit-field operators properly because complications arise when multiple bits can be set in the bit-field. The TCP flags field can have multiple bits set. Table 5.7 shows the flags field of a TCP packet with its SYN bit (tcp-syn) set.
| URG | ACK | PUSH | RST | SYN | FIN |
|---|---|---|---|---|---|
| 0 | 0 | 0 | 0 | 1 | 0 |
In this case, only the tcp-syn bit is set, so the value 0x02 can be tested, which is the value of tcp-syn:
tcp[tcpflag] == 0x02
or
tcp[tcpflag] == tcp-syn
However, in the case of the second packet in a TCP handshake, a SYN/ACK packet, both the tcp-syn and tcp-ack bits are set, as shown in Table 5.8.
| URG | ACK | PUSH | RST | SYN | FIN |
|---|---|---|---|---|---|
| 0 | 1 | 0 | 0 | 1 | 0 |
When SYN and ACK are both set, the TCP flags field will equal 0x02 + 0x10, or 0x12. Thus the filter tcp[tcpflag] == tcp-syn will fail to show the packets that have SYN plus any other field set; the filter will give you packets that have only SYN set. To write a filter to test for the SYN bit being set, you need to use the bitwise-AND operator to mask out all the bits except for the SYN bit.
tcp[tcpflag] & tcp-syn == 0x02
or:
tcp[tcpflag] & tcp-syn == tcp-syn
The bitwise arithmetic using & (bitwise AND) when comparing a TCP flags field that has SYN and ACK set is shown in Table 5.9.
| URG | ACK | PUSH | RST | SYN | FIN | Value | Meaning | |
|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 0 | 0 | 1 | 0 | 0x12 | SYN/ACK | |
| AND | 0 | 0 | 0 | 0 | 1 | 0 | 0x02 | tcp-syn |
| 0 | 0 | 0 | 0 | 1 | 0 | 0x02 | tcp-syn |
In this case, the bitwise AND produces a result of 0x02, which is equal to tcp-syn, so we have determined that the SYN bit is indeed set. By using the bitwise AND, you can tell if any particular bit in the bit-field is set, even if other bits in the bit-field are set. Table 5.10 shows the bitwise arithmetic when the TCP packet is an ACK packet, and the TCP flags field has only ACK set.
| URG | ACK | PUSH | RST | SYN | FIN | Value | Meaning | |
|---|---|---|---|---|---|---|---|---|
| 0 | 1 | 0 | 0 | 0 | 0 | 0x10 | ACK | |
| AND | 0 | 0 | 0 | 0 | 1 | 0 | 0x02 | tcp-syn |
| 0 | 0 | 0 | 0 | 0 | 0 | 0x00 | 0 |
The result is 0x00, which does not equal tcp-syn, so a TCP ACK packet does not pass the tcp[tcpflag] & tcp-syn == tcp-syn test.
Packet Size
The tcpdump filter language allows you to test metadata about the packet instead of data from the packet itself. The packet size is available in a variable named len. It can be tested with the standard arithmetic operators. To test for packets smaller than 100 bytes, use this filter:
len < 100
The less and greater operators are built-in shorthand keywords for testing the len variable against a number. less 100 is the same as len <= 100, while greater 1500 is the same as len >= 1500.
 |
Testing Capture Filters
Would you like to test your capture filter without actually loading Ethereal? Capture filters are the same filters that tcpdump uses, so you can supply the capture filter on tcpdump’s command line to see if tcpdump can understand your capture filter:
|
$ tcpdump less 100
If your capture filter makes use of punctuation that is normally special to the UNIX shell, you need to enclose your capture filter in single quotes:
$ tcpdump 'len > 1500'
Tcpdump has a –d option, which shows you the Berkeley Packet Filter (BPF) code used to operate the capture filter. BPF is the mechanism that many operating systems provide for packet capture filters. You can read about BPF “The BSD Packet Filter: A New Architecture for User-Level Packet Capture”, by Steven McCanne and Van Jacobson, at www.tcpdump.org/papers/bpf-usenix93.pdf. Here’s an example of BPF code:
$ tcpdump -d 'len > 0xff' (000) ld #pktlen (001) jgt #0xff jt 2 jf 3 (002) ret #96 (003) ret #0
Examples
The following list includes a few examples of capture filters.
-
All HTTP packets: tcp port 80
-
Non-HTTP packets: not tcp port 80 or !tcp port 80 or tcp port not 80 or tcp port !80
-
HTTP browsing to www.ethereal.com: tcp port 80 and dst www.ethereal.com
-
HTTP browsing to hosts other than www.ethereal.com: tcp port 80 and not dst www.ethereal.com
-
IPX packets: ipx
-
IPX packets destined for IPX network 00:01:F0:EE: not possible, because you cannot retrieve bytes using the ipx keyword
-
TCP packets: tcp or ip proto 5
-
TCP SYN packets: tcp[tcpflag] & tcp-syn == tcp-syn
-
IP packets with total length > 255: ip[2:2] > 0xff
-
IP or IPX packets: ip or ipx
Using Capture Filters
Tethereal accepts capture filters on the command-line with the –f option, as shown in this example.
# tethereal -i eth1 -f icmp Capturing on eth1 0.000000 10.0.0.5 -> 10.0.0.1 ICMP Echo (ping) request 0.000062 10.0.0.1 -> 10.0.0.5 ICMP Echo (ping) reply 1.010753 10.0.0.5 -> 10.0.0.1 ICMP Echo (ping) request 1.010814 10.0.0.1 -> 10.0.0.5 ICMP Echo (ping) reply
Remember that the argument to –f is a single argument. If your capture filter has spaces in it, you need to surround the capture filter in quotes so that it is passed as the single argument of the –f option:
# tethereal -i eth1 -f 'icmp[0] == 0 or icmp[0] == 8'
Conveniently, Tethereal, like tcpdump, will also accept any leftover arguments on the commandline and use them as a capture filter.
# tethereal -i eth1 icmp[0] == 8
When making use of this facility, you cannot use the –f option.
# tethereal -f icmp -i eth1 icmp[0] == 8 tethereal: Capture filters were specified both with "-f" and with additional command-line arguments
Be aware of characters that are special to the UNIX shell when using capture filters on the command line. This filter should be picking up echo requests and echo replies, but only echo replies are seen.
# tethereal -i eth1 icmp[0] == 0 || icmp[0] == 8 Capturing on eth1 0.000000 10.0.0.1 -> 10.0.0.5 ICMP Echo (ping) reply 1.009672 10.0.0.1 -> 10.0.0.5 ICMP Echo (ping) reply 2.016646 10.0.0.1 -> 10.0.0.5 ICMP Echo (ping) reply
The problem is that the two vertical bars (||) are interpreted by the UNIX shell. The two vertical bars and the rest of the command line are never seen by tethereal. To avoid this behavior, use quotes around the capture filter:
# tethereal -i eth1 'icmp[0] == 0 || icmp[0] == 8' Capturing on eth1 0.000000 10.0.0.5 -> 10.0.0.1 ICMP Echo (ping) request 0.000057 10.0.0.1 -> 10.0.0.5 ICMP Echo (ping) reply 1.010248 10.0.0.5 -> 10.0.0.1 ICMP Echo (ping) request 1.010299 10.0.0.1 -> 10.0.0.5 ICMP Echo (ping) reply
Ethereal, like Tethereal, accepts capture filters with the –f option. If you use Ethereal’s –k option, Ethereal will immediately start capturing packets. You can use the –k option to start a capture and use the –f option to supply a capture filter. Besides –k and –f, Ethereal and Tethereal share many of the same capture-related command line options. However, Ethereal will not accept leftover arguments on the command line and treat them as part of a capture filter.
ethereal [ -vh ] [ -klLnpQS ] [ -a <capture autostop condition> ] ... [ -b <number of ringbuffer files>[:<duration>] ] [ -B <byte view height> ] [ -c <count> ] [ -f <capture filter> ] [ -i <interface> ] [ -m <medium font> ] [ -N <resolving> ] [ -o <preference setting> ] ... [ -P <packet list height> ] [ -r <infile> ] [ -R <read filter> ] [ -s <snaplen> ] [ -t <time stamp format> ] [ -T <tree view height> ] [ -w <savefile> ] [ -y <link type> ] [ -z <statistics string> ] [ <infile> ] tethereal [ -vh ] [ -DlLnpqSVx ] [ -a <capture autostop condition> ] ... [ -b <number of ring buffer files>[:<duration>] ] [ -c <count> ] [ -d <layer_type>==<selector>,<decode_as_protocol> ] ... [ -f <capture filter> ] [ -F <output file type> ] [ -i <interface> ] [ -N <resolving> ] [ -o <preference setting> ] ... [ -r <infile> ] [ -R <read filter> ] [ -s <snaplen> ] [ -t <time stamp format> ] [ -T pdml|ps|text ] [ -w <savefile> ] [ -y <link type> ] [ -z <statistics string> ]
Being a graphical application, Ethereal also accepts capture filters in its graphical user interface. Before starting to capture packets, the Capture Options dialog box, as shown in Figure 5.1, provides a Filter text entry box where you can type a capture filter.
Figure 5.1: Capture Options Dialog Box
|
| < Day Day Up > |
|
EAN: 2147483647
Pages: 105