Home page logo
/

basics logo Security Basics mailing list archives

RE: Caching a sniffer
From: "David Gillett" <gillettdavid () fhda edu>
Date: Wed, 24 Mar 2004 12:48:55 -0800


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

  By Date           By Thread  

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