Pcaps and the Tools That Love Them Part 2

There's more to a primitive under the surface, and once we discover what it's actually doing, it opens up a whole new way for us to inspect and filter packets. 

Lets use the TCP primitive as an example. What is it actually doing? How does it show us only TCP packets? 

To see this we need to look at the IP header..not the TCP header. Here's a really simple version of a nicely color coded diagram.

Now we can see in the IP header we have a field called Protocol, or more accurately, Embedded Protocol. This signifies the next layer protocol embedded in the packet. 

If that field is 01, we have an ICMP packet. If it's 06, it's TCP. If it's 0x11 hex, or 17 in decimal, it's UDP.

So the tcp primitive is checking the Protocol field and seeing if that field contains 6, and if so it passes the packet on to be displayed or captured. 

Now, what field IS that. When counting header fields we start counting at zero. So we can count from the beginning of the packet and see that the protocol field is field 9.

Not clear from the diagram? You're right, it's not..too simple now..here's one showing the number of bits in each field.

Now we can see each line is 4 bytes, 32 bits. And starting from zero and counting the bytes we find Protocol in the ninth field.

The first two fields are divided into half bytes, call nibbles, 4 bits each. Just count them both as one byte. 

We'll cover what they do later and why the authors who wrote the protocol divided them up.

Most fields in the protocol header break on byte, or nibble (half byte) boundaries.

There are a few notable examples, which we'll cover as we look at bitmasking. Bitmasking can be simply defined as showing only the bits you need to see and masking out the others.

The same principles apply to any protocol. If there's a header, you can parse it. 

Getting yourself a good set of diagrams, in the format and layout YOU like is really going to help you. Unless you're in the rare position of doing nothing but analyzing packets all day, you're not going to memorize the protocol headers, probably. 

But from practice, you will remember the embedded protocol is in the ninth byte offset from zero in the IP header, or the flags bits are in the 13th byte in the TCP header, or the IP version is in the most significant 4 bits of byte 0 in the IP header. 

Without bunny trailing into big endian and little endian, for the purposes of packet inspection just remember that network byte order always starts from the left (you start counting at the leftmost bit and move right).

So to make this practical (and start at the beginning), the first byte of the IP header (byte zero) is split in half. The first four bits are the IP 

The second 4 bits, or nibble, is the header length. This is a value multiplied by 4. A normal IP header, with no options, is 20 bytes, so this should normally be 5.

Now that's your first visual clue when looking at a packet capture in hex. If the capture included the Ethernet header and you're looking for the start of the IP header, it SHOULD, but isn't always, be 45.

So if you see a packet capture and don't know what it is, a quick way to start orienting yourself is to look for a 45 byte.

Pcaps and the Tools That Love Them Part 1

There are many pcap tools available and which ones you use really depends on what you're using them for. Some are very good at just giving you the raw data, others parse the data and show you certain types of packets..

But maybe we should back up one step and define what we're taking about. What is a pcap? Simply put, a pcap is a binary file that contains packets captured off of a network interface.

How much data, and which fields depends on the manner that you capture the packets. We'll look at some of those options as look at tcpdump. I won't spend a lot of time on that tool because many people are familiar with it, at least the basics. It's actually a powerful tool when combined with BPFs, but we'll cover that as well later.

BPF is short for Berkeley Packet Filters and they allow pcap tools to get granular down to the bit, the BIT, level in specifying what header fields you want to see. For example, the TCP flags are each one bit in size. With BPFs you can specify to your tool to only show you packets that the SYN flag is set. Or SYN and any other combination of flags

The simplest BPFs are built into tcpdump. "tcp" and "port" are primitives. Others include udp, src dst, icmp, host and ether and net.

Other tools built on the libpcap library can use them as well, tools like ngrep and  tshark.

An example would be tcpdump -nn -i eth0 'tcp and port 23' 

This would tell tcpdump to listen on the eth0 interface, don't resolve hostnames, don't do port resolution, and only show packets that are the TCP protocol and either the source or destination port is 23.

If we only wanted to see traffic going to port 23, we could add the primitive dst in front of port.

tcpdump -nn -i eth0 'tcp and dst port 23'

Get into the habit of putting your BPF's into single quotes.

It will make no difference using simple BPFs like "port 80 or port 443", but when you get into complex BPFs using bitmasking, it will keep you from getting syntax errors.

So why use the -nn options, that disable name and port resolution? There are several reasons. One reason is speed and efficiency. 

If your sniffing a fast, busy segment and have to do a DNS lookup on every address, it will slow tcpdump down to the point of starting to drop packets. 

Another reason is if you're monitoring malicious traffic and the attacker controls his/her nameserver, they will see the DNS lookup and know they're being monitored by you. 

Port resolution is done using Linux's services file, in /etc/. This is a mapping of ports to services, so when tcpdump sees port 80 it substitutes http for 80. 

But can other services be bound to port 80? If you're root you can bind any service you like to any port you want. That port 80 traffic could be any protocol. So we'll bypass the commonly used ports and see what the traffic is ourselves.