Home page logo

basics logo Security Basics mailing list archives

RE: Caching a sniffer
From: "Shawn Jackson" <sjackson () horizonusa com>
Date: Thu, 25 Mar 2004 12:24:10 -0800

  I've enjoyed this exchange too, but I think it's coming to 
the end of its usefulness.

I get that feeling too, all I can hope is that we didn't confuse anyone
else on the list.

  Some of your mental conceptions of how switches and routers 
work is at odds with both my experience and the CCNA/CCNP 
materials I've been studying recently.  (My current CCNA 
expires in May; I plan to pass my CCNP before it does.)
  Presumably, this reflects that your experience to date has 
been different from mine, and there's nothing either of us 
can do to fix that.  It's like trying to reconcile particle 
physics with wave physics.

You assume I have mental conceptions :-). My knowledge is based on
analysis I have done and research in the RFC and IEEE specs. Though I
get vender certs in the future, I try and stay as vendor neutral as
with my core knowledge, that could be where are knowledge forks.

  Probably as a result, your conception of how macoff 
(macor?) works requires that it force a catastrophic 
breakdown of the switch functionality at all levels, AND that 
a switch so totally crashed fall back on operating like a hub.
  Within the conception of a switch as documented by Cisco (and 
every other source I've seen), it is sufficient for macoff/macor 
to fill up a switch's MAC table, and for the switch to stop 
learning source MAC addresses when the table fills, to achieve 
its effects -- without any interruption of the other normal switch 
processes.  This has the obvious advantage of standing some 
sane chance of working on ANY switch, not just ones afflicted 
with a particular semi-miraculous bug, and the less obvious 
advantage of not attracting admin attention by crashing 
network equipment.

It's MacOf, I always tend to put two f's when I'm not closely paying
attention to what I'm writing. MacOf is part of the dSniff package from
http://naughty.monkey.org/~dugsong/dsniff/. It's been my poor choice of
words/terminology that I'm sure is causing more of the problems
throughout the conversations, for that I apologize. When Cisco switches
are faced with a MAC flood they being to operate like a hub, i.e. they
don't do layer 2 forwarding anymore, instead send all traffic to all
ports. This keeps the network operational and I'm sure keeps the switch
online. The switch returns to normal when the bad MAC entries are 'aged'
out of the table. This was, more of less, what Cisco told me and the
networking/security staff at a bank I did work with a while back, it's
not a bug or anything like that, it's by design. Port-Security solves
that problem and that was Cisco's answer. We tested some other vendors
and had the same results, during that time period.

  I don't see any way to reconcile our two different 
conceptions of the networking universe.  Do you?  If not, 
then maybe it's time to let it rest and talk about something else.

Maybe over drink, but your most likely right. I made my final statement
above and I hope it clarified my position, I tried to write is as clear
as possible, but I'm not very good at writing.

Shawn Jackson
Systems Administrator
Horizon USA
1190 Trademark Dr #107
Reno NV 89521

Email: sjackson () horizonusa com
Phone: (775) 858-2338
       (800) 325-1199 x338 

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:

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]