Trawl for Packets with Wireshark - Page 2

 By Paul Rubens
Page 2 of 2   |  Back to Page 1
Print Article

Dissecting ARP

I mentioned earlier that the bottom part of Wireshark shows a hexdump of any given highlighted packet that the analyzer sniffs. This offers some interesting possibilities, especially for hackers. For example, lets imagine that a hacker sniffs an ARP response, using the filter:


to find one easily.

If you look at figure 4, an ARP response has been highlighted in the top pane. In the middle pane, the additional information includes the sender MAC and IP address, and the target MAC and IP address. The bottom pane shows the actual ARP response packet as a hexdump – if you look you can identify the parts of the packet that contain these MAC and IP addresses.

By copying this hex data into a hex editor, a hacker could change the portion of the packet containing the sender MAC address to a different MAC address – his own for example. This modified ARP packet, if sent on to the network, would tell the recipient machine that henceforth any packets destined for the source IP address (in this case should be sent to the hacker's MAC address. In other words, a very basic man in the middle attack would have been performed by capturing an ARP packet in Wireshark, opening it as a file and editing it manually in a hex editor, and finally sending the edited file as a raw Ethernet frame on to the network using an application such as the Linux utility file2cable. (In fact, a hacker would be more likely to use a more specialist tool such as Ettercap or Cain to do an ARP poisoning exploit like this, but this does illustrate the power of Wireshark.)

There's far, far more that Wireshark can do than what's just been described, but this article should give you an idea of the basics.

When You Don't Get What You Expected

Before finishing it’s worth mentioning a common problem with Wireshark – failing to capture the packets you'd expect. Assuming the software is installed correctly, there are a couple of things to watch out for.

The first is simply that the network interface you have chosen is not capable of being placed in promiscuous mode, and is there for only capturing packets traveling to and from the host running Wireshark.

The other reason is to do with switched networks, and hubs that behave as switches. Since switches only send packets to ports leading to the destination machine, if you plug your monitoring machine into certain ports then some packets won't reach your network interface card at all. (Some switches have a special port which replicates traffic to all other ports – plugging your monitoring machine into this port does enable you to see all traffic through that switch.) And some hubs (which should send traffic to all ports) are actually switched, so again you'll miss out on some traffic.

But if you take time to understand your network topology and your hardware, you should be able to work out the best place (or places) to connect Wireshark to the network to capture all the packets you are interested in. If all else fails, connecting it at the Internet gateway (assuming there is only one) will ensure that you capture all traffic to and from your network even if you miss some internal traffic.

Many people describe using Wireshark as a revelation – the difference between getting a feel for their network and turning on the lights and looking at it. If you want to get a clear view of what is traveling over yours, you'd be well advised to take it for a spin.

This article was originally published on Feb 29, 2008
Get the Latest Scoop with Networking Update Newsletter