RE: Caching a sniffer

["David Gillett" <gillettdavid () fhda edu>]

> -----Original Message-----
> From: Shawn Jackson [mailto:sjackson () horizonusa com]
>
> > > > 1. Dump the entire MAC table.  Switch acts as if power on 
> > reset just 
> > > > occurred.
> > >
> > > Seams logical, but I've never seen it implemented. It would
> > > halt traffic while learning resumes, in addition if other checks 
> > > needed to run (Spanning Tree/CDP) it would take much longer.
> >
> >   No.  Traffic will flood while learning restarts from 
> > scratch. Nothing was said about dumping STP/CDP statuses.
>
> Traffic will halt because the switch can't forward at the point it's 
> trying to learn the network.

  You've confused routine learning of source MAC addresses with the
"learning" mode that ports go through while spanning tree is reconverging.
It's true that packets won't be forwarded in the latter case, but 
resetting the MAC table (forgetting learned source MACs) need not force
a spanning-tree reconvergence, and if it doesn't then the traffic will
flood temporarily (as source MACs are re-learned) rather than be dropped.
 
> > > > 2. Stop learning.  All previously learned MAC addresses
> > > > remain, and so only traffic for unrecognized MAC addresses 
> > > > gets sent to all ports.
> > >
> > > That would damage the network. If a new client fires up, they
> > > would not get added to the switches tables and not receive any 
> > > traffic.
> >
> >   Destinations not in the table normally get flooded, not 
> > dropped. Dropping this traffic is possible, but not a normal 
> > part of the action being suggested.
>
> If the system fires up on the afflicted switch. If it's in another
> segment of the network all systems and paths on the afflicted switch 
> would be dark because the switch would use it's current MAC->Port 
> table, and not add additional MAC's to the port.

  Flooding unknown destinations to all ports (except the origin) 
*includes* forwarding to uplink/inter-switch ports.  So hosts on 
the afflicted switch will still be able to reach hosts on other
switches, and vice versa.

> > > > 3. Partial Purge of table.  Some portion of the table 
> gets purged 
> > > > and the switch continues, treating those purged MAC 
> > addresses as if 
> > > > this was the first time they were seen.  Depending upon how the 
> > > > purged addresses are selected - oldest first, youngest first, 
> > > > random, lowest MAC addresses, highest MAC addresses or 
> something 
> > > > else - will cause the switch to act differently for 
> > different users.
> > > Seams a better solution out of the bunch, could be a pain to
> > > implement.
> >
> >   Some switches routinely age unused entries out of the 
> > table. Accelerating this process if the table fills shouldn't 
> > be too hard.
>
> You can usually modify aging in the configuration. But the aging time
> would have to outpace the flood to keep the table clear, this would 
> result in more traffic and load for the switch.

  I think this suggestion was that the MAC flood would trigger the aging,
so it keeps pace automatically.  That, in turn, requires the malicious 
host that's flooding bogus MAC addresses to continue doing so, in order 
to try to keep valid MACs from being retained in the table (long enough 
to keep their traffic from flooding and being seen by the sniffer).

David Gillett


---------------------------------------------------------------------------
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: 
http://www.infosecinstitute.com/courses/ethical_hacking_training.html
----------------------------------------------------------------------------