Home page logo
/

basics logo Security Basics mailing list archives

RE: Caching a sniffer
From: "David Gillett" <gillettdavid () fhda edu>
Date: Thu, 25 Mar 2004 11:45:59 -0800

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

  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.

  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.

  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.

David Gillett


-----Original Message-----
From: Shawn Jackson [mailto:sjackson () horizonusa com]
Sent: Thursday, March 25, 2004 11:09 AM
To: gillettdavid () fhda edu; security-basics () securityfocus com
Subject: RE: Caching a sniffer


  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.

Correct, the TTL will decrement at each hop witch rewrites the IP
header. But a router won't change the destination or source address,
it's mealy part of the transport chain. MAC are determined by ARP
resolution, and are not contained in the IP header. Also routers deal
with packets, frames exist at a lower level at the OSI which cannot be
routed. Routers work with the network layer protocols, for 
that is where
the address information is stored. Now if the router is a edge router
you could argue that the router has to rewrite the packet/frame for
transmit over the async line. But that packet, like it is on the
switched network is reassembled again and sent on it's way. The Frame
Check Sequence is for the layer 2 information, the IP header, which a
router will work on contains the checksum value for the payload. The
systems dealing with the lower level data might rewrite the 
FCS for the
frame, but it's not a operation of the router which is 
running at layer
3. 

Check out http://www.faqs.org/rfcs/rfc791.html for IP (v4) protocol
specs.

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

Or MAC addresses that are not authorized. Or MAC addresses 
that are tied
to specific IP addresses.

  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.

STP (Spanning-Tree Protocol) in IEEE 802.1D relies on BPDU's (Bridge
Protocol Data Units) to communicate regarding link statuses. Once the
Switch (bridge) component of the switch can no longer function it is
unable to send out BPDU's on link status for discovery to 
other switches
and then disable the additional route (usually with the higher cost)
that causes the loop. If the switch can retain link-state 
information on
the additional route then the network would be fine. But 
without switch
STP would be unable to discover additional router during that 
time. It's
not a bug, it's protocol design and implantation. STP was originally
intended for bridges, not switches.

  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

Good point, your absolutely right.

Though I absolutely love the conversation (getting my butt 
kicked), I do
feel a little bad that we (might/are) drifting off topic for 
a security
(basics) list.

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

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

  By Date           By Thread  

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