mailing list archives
RE: Caching a sniffer
From: "David Gillett" <gillettdavid () fhda edu>
Date: Wed, 24 Mar 2004 12:48:55 -0800
From: Shawn Jackson [mailto:sjackson () horizonusa com]
... if you redefine "router" to include a concept similar to "layer 2
router", at which many people will look at you rather strangely. The
term normally refers to a layer 3 packet-forwarder which rewrites
packets, whereas switches are multiport bridges that forward frames,
without rewriting, based on the destination MAC address.
But you have wire speed layer 2 switches, which most (large) networks
use are their core switch. Then you have lower end switches that actually
look at the IP information to forward the packet to the correct port. So
indeed the vast majority of switches have a layer 3 routing mechanism in
them. Most routers don't re-write the packet, they just forward them on
the interface their protocols tell them to.
A properly-functioning layer 3 router must decrement the TTL in the IP
packet header. It may make other changes, up to and including fragmenting
the packet if necessary (and permitted).
Then it encapsulates it with new source and destination MAC addresses,
and recalculates the FCS. The frame that finally leaves an interface is
substantially different from the one which arrived.
No switch/bridge ever does that -- unless it is ALSO serving as a layer 3
router. And while most of the switches I work with every day include that
as a capability, it's turned off in the "vast majority" of cases, and the
other brands of switches I've worked with have not, generally, included
it by default in every box.
Switches "learn" what MAC addresses are on what port by collecting
source addresses from frames into a table. Traffic will be flooded
to all ports if the destination MAC address is not in the table.
If the switch cannot learn the MAC and other responding switches don't
have the MAC in table the packet is either forwarded to the default
router or dropped.
The switch learns the source, and forwards according to the destination.
There's no direct connection between these two parts of processing the
At the switch/bridge forwarding layer, there's no such concept as
"default router". There's
a) destination MAC found in table
forward frame via designated interface
b) destination MAC not found in table
forward frame to all but source interface
c) destination MAC is "broadcast"
forward frame to all but source interface (may just be a special
case of above; all that is necessary is that the switch never
learn the broadcast MAC even if it's spoofed as a source)
But this is not the only possible reaction of a switched network to
macoff! If Cisco's port security is enabled, the switch may
just shut down the port running macoff.
Correct, but how many switches have Port-Security? I have on
my Cisco's, but my Bay Network and HP switches don't have that
facility. port-security will just kill the port if
an unauthorized ARP-to-MAC is detected or a ARP notified
limit has been exceeded. Port-Security can easily break large
interconnected networks using legacy technology connected to the
switch, i.e. old hubs with multiple systems connected to a
single switch port.
Port security has nothing to do with ARP, per se. It has to do with
the number of different source MAC addresses seen on an interface.
And you're correct that this breaks if you legitimately have multiple
devices on a switch port (breaks, or becomes unmanageable, which sooner
or later amounts to the same thing).
The poster who started the thread specified a "switched network", and
I called it the same thing in the quote above. So "but not if the network
isn't fully switched" doesn't really refute the point.
If the network consists of multiple switches, something like
macoff may prompt a spanning-tree reconvergence, disrupting
the entire network for 30 seconds or so. I'm sure there are
other possibilities depending on manufacturer/model/firmware of
the switches in the network.
Spanning tree will not work on the switch inflicted by macoff. Because
macoff attacks the 'memory' of the switch, to keep the network operational
it shuts down the switch system, which spanning tree relies on. The
is, when this happens the once disabled redundant route on the switch
be enabled and cause serious network loops.
If any of this explanation is true, it describes a BUG in some specific
switch implementation which is likely to be fixed by replacement with a
different code release, model, or manufacturer. If macoff relies on
to retain buggy equipment, it's a moot point. Filling up the MAC table
with spurious addresses so that learned addresses age out and are not
relearned is sufficient and does not require bizarre bugs in the switch
However, the transition of the port from one active MAC address to many
may be detected as a network topology change, as if a switch or hub had
been plugged into the port.
Personally, if I had to sniff traffic on a switched network without
admin access, I'd prefer to use arp poisoning, a la ettercap. The
MAC address tables on the switches go right on functioning
normally, just all of the traffic to/from the client you're
interested in gets sent to the sniffer machine's MAC address and
forwarded to the intended destination from there, with minimal
impact on other network traffic or performance. About the only
visibility is if the victim happens to run "arp -a" and understands
what they're seeing.
Same, only problem with that is you need to know the system
your trying to listen to.
If you have the bandwidth, you can do ARP poisoning for the entire
subnet. At least long enough to decide who's interesting enough to
Port security also will stop this sniffing as well.
I don't think so, because I still only have one MAC address associated
with my port. I never violate the condition that port security
Ethical Hacking at the InfoSec Institute. Mention this ad and get $545 off
any course! All of our class sizes are guaranteed to be 10 students or less
to facilitate one-on-one interaction with one of our expert instructors.
Attend a course taught by an expert instructor with years of in-the-field
pen testing experience in our state of the art hacking lab. Master the skills
of an Ethical Hacker to better assess the security of your organization.
Visit us at:
RE: Caching a sniffer Andrew Shore (Mar 25)
RE: Caching a sniffer Shawn Jackson (Mar 25)