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 11:08:56 -0800

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