Sniffing on a switch

I’m an IP network engineer. When something goes wrong, the first thing I do is sniff packets. Got a SIP phone that won’t register? Forget reading logs; sniff 5060/udp and read the SIP chatter directly. A customer complains that “Yahoo chat doesn’t work”? Sniff 5050/tcp and look for TCP hangups, login failures, or ICMP “port unreachable” messages.

Sniffing is easy when you have access to the intermediate router, but that isn’t always the case. What if you’re just another PC on the same switch? That’s impossible, right?

I’m not the first person to write about this. Switches are not immune to sniffing. There are three techniques for sniffing traffic on an Ethernet switch:

  1. Use a monitor port. With a managed switch, configure one port to receive copies of data sent to other port(s). Useful if you have administrator access to a managed switch.
  2. MAC flooding. Fill up the switch’s MAC table with false entries, causing it to failover into broadcast mode. All packets will be sent to all ports. Easy to detect and hard to do on modern switches.
  3. ARP poisoning. Send unsolicited ARP responses to the target devices (for instance, a PC and its default gateway), telling them to direct traffic to you. Silently route their traffic so they don’t notice an interruption.

It is the last technique that I want to discuss. Many tools exist to poison ARP, from simple command line utilities like arpspoof (part of dsniff), seringe, and arp-sk, to full-featured man-in-the-middle attack suites like Ettercap. Ettercap can poison ARP caches, sniff packets and write them to files, route traffic, and filter/change traffic content. You can find a very helpful step-by-step Ettercap tutorial here, so I won’t cover the same ground. I’d rather explain what these tools do.

ARP poisoning attacks work by sending gratuitous ARP replies to two targets, informing each of them that the attacker’s PC is the opposite target. For instance, suppose I have three devices:

  1. gateway, a router on 192.168.0.1, with MAC 00:1d:73:36:ad:0c
  2. alice, a PC on 192.168.0.101, with MAC 00:13:02:02:56:da
  3. My PC on 192.168.0.102, with MAC 00:17:09:d2:30:25

Alice knows Gateway’s MAC address:

Gateway knows Alice’s MAC address:

When I start the ARP poisoning attack, both Alice and Gateway learn different MAC addresses for each other:

Now Alice will send traffic for Gateway (probably all Internet traffic) to my PC, and Gateway will do the same for traffic intended for Alice. If we stop here, we’ll be able to see what Alice is trying to do, but Alice will quickly realise something is wrong because traffic will stop without explanation.

This is the second part of ARP poisoning (and of any Man-in-the-Middle attack): silently routing traffic onward. You can use the kernel’s IP forwarding to do this:

echo 1 > /proc/sys/net/ipv4/ip_forward

But if you do, you’ll appear in Alice’s traceroute path:

If you use “unified sniffing” with Ettercap, it will silently route traffic in software. Other tools, such as fragrouter (also part of dsniff), can do the same thing from the command line. Both of these tools forward traffic without decrementing the TTL, which makes them invisible to traceroute.

ARP poisoning is not silent. It can be detected by both hosts, because you are manipulating their ARP tables. These gratuitous ARP replies are easily visible with a sniffer:

Most tools send these ARP replies regularly, to keep ARP table entries from timing out. For instance, Ettercap sends them every 10 seconds. This is suspicious, as ARP requests are normally only seen when a host is first discovering another one. It is necessary to prevent true ARP requests from briefly changing the ARP table back to its correct state. Several tools exist to detect or prevent ARP poisoning, like ArpON, arpwatch, and DHCP snooping.

I’ve used traditional security terms like “victim” and “attacker” in this post, and of course ARP poisoning is a useful technique for unauthorised spying. However, it has legitimate uses. I’ve used it a number of times in situations where I had to sniff but couldn’t interrupt the physical cabling or didn’t have a managed switch. Whatever the problem, there is no faster way to understand a network problem than sniffing the raw data.

Tags: , ,

  1. Jamie’s avatar

    Yesss thank you, I am so with you. Most people look at me like I’m nuts or suggesting crazy overkill by mentioning doing a packet capture. It is nearly always the quickest and easiest way to diagnose or narrow down a problem – at least if you’re familiar with the relevant protocols.

    Reply

    1. Tyler Wagner’s avatar

      And there is no better way to become familiar with the relevant protocols than to sniff them! I have a whole bestiary of captured sniffs that I keep for reference, plus Wireshark’s website has a huge set of them.

      Reply

    2. wholesale polo’s avatar

      An exceptionally great post. This short article covers for me personally exactly what this particular subject is determined by and some of the essential advantages that can be caused by knowing about it as should you. A buddy once pointed out that you’ve got a completely different mindset when you do something for several as opposed to when you are just toying with it. In the case of this sort of subject, I believe you are taking, or even start to think of, a more professional as well as comprehensive method of each what and just how you write, which helps you to keep on and get better and manual other people who have no idea anything about what you have shared right here. Thank you.

      Reply

Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">