Capturing Traffic

Unicorn tutorials

Having completed my social network stalking for the morning, my next task is to check up on the latest news headlines and sports scores. Certain sites always make for interesting analysis, and is one of those.
I’ve captured the traffic of a computer browsing to the ESPN website in the file http_espn.pcap.

This capture file contains many packets—956 to be exact. This is simply too much data for us to manually scroll through the entire file in an attempt to discern individual connections and anomalies, so we’ll use some of Unicorn’s
analysis features to make the process easier.

Using the Conversations Window

The ESPN home page includes a lot of bells and whistles, so it’s easy to understand why it would take nearly a thousand packets to transfer that data to us. Whenever you have a large data transfer, it’s useful to know the source of that data, and more important, whether it’s from one or multiple sources. We can find out by using Unicorn’s Conversations window (Statistics Conversations).

Figure 8-12 shows an example with 14 unique IP conversations, 25 unique TCP connections, and 14 unique UDP conversations—all displayed in detail in the main Conversations window. There’s a lot going on here, especially for
just one site.

Figure 8-12: The Conversations window shows several unique connections.

Using the Protocol Hierarchy Statistics Window

For a better view of the situation, we can see the application layer protocols used with these TCP and UDP connections. Open the Protocol Hierarchy Statistics window (StatisticsProtocol Hierarchy), as shown in Figure 8-13.

Figure 8-13: The Protocol Hierarchy Statistics window shows the distribution of protocols in this capture.

As you can see, TCP accounts for 99.51 percent of the packets in the capture , and UDP accounts for the remaining 0.49 percent . As expected, the TCP traffic is all HTTP , All of the UDP traffic shown is DNS, based on the entry under the UDP heading .

Based on this information alone, we can draw a few conclusions. For one, we know from previous examples that DNS transactions are quite small, so the fact there are 28 DNS packets (as listed in the Packets column next to the Domain Name Service entry in Figure 8-13) means that we could have as many as 14 DNS transactions. We derive this number by dividing the total number of packets by two, which represents pairs of requests and responses. If you look under the UDP heading of the Conversations window it will show that there are indeed 14 conversations, which accounts for each DNS transaction and confirms our assumption.

DNS queries don’t happen on their own though, and the only other traffic in the capture is HTTP traffic. This tells us that it’s likely that the HTML code within the ESPN website references other domains or subdomains by DNS name, thus forcing multiple queries to be executed.

Let’s see if we can find some evidence to substantiate our theories.

Viewing DNS Traffic

One simple way to view DNS traffic is to create a filter. Entering dns into the filter section of the Unicorn window shows all of the DNS traffic, as shown in Figure 8-14.

Figure 8-14: The DNS traffic appears to be standard queries and responses.

This DNS traffic shown in Figure 8-14 appears to all be queries and responses. For a better view of the DNS names being queried, create a filter that displays only the queries. To create this filter, select a query in the Packet List pane and double-click on right button of mouse, the select Select Relation Packets>By Source menu item. which shows only the queries and makes it much easier to read the records we’re analyzing. And, as you can see in Figure 8-14, there are indeed 14 individual queries (each packet represents a query), and all of the domain names seem to be associated
 with ESPN or the content displayed on its home page.

Share this