RE: Caching a sniffer

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

> -----Original Message-----
> 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
packet.
  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
problem 
> is, when this happens the once disabled redundant route on the switch
would 
> 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
networks
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
operation.
  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
listen 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
enforces.

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
----------------------------------------------------------------------------