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 ----------------------------------------------------------------------------
Current thread:
- Re: Caching a sniffer, (continued)
- Re: Caching a sniffer Patrick Toomey (Mar 24)
- RE: Caching a sniffer Shawn Jackson (Mar 24)
- RE: Caching a sniffer Burton M. Strauss III (Mar 25)
- RE: Caching a sniffer Fernando Gont (Mar 25)
- RE: Caching a sniffer Shawn Jackson (Mar 24)
- RE: Caching a sniffer David Gillett (Mar 24)
- RE: Caching a sniffer Fernando Gont (Mar 25)
- RE: Caching a sniffer David Gillett (Mar 25)
- RE: Caching a sniffer David Gillett (Mar 24)
- RE: Caching a sniffer Fernando Gont (Mar 25)
- RE: Caching a sniffer Shawn Jackson (Mar 25)
- RE: Caching a sniffer David Gillett (Mar 25)
- RE: Caching a sniffer Shawn Jackson (Mar 25)
- RE: Caching a sniffer David Gillett (Mar 25)
- RE: Caching a sniffer Shawn Jackson (Mar 25)
- RE: Caching a sniffer Andrew Shore (Mar 25)
- RE: Caching a sniffer Paul Blackstone (Mar 25)
- RE: Caching a sniffer Byron Copeland (Mar 26)
- Re: Caching a sniffer Aaron (Mar 29)
- RE: Caching a sniffer Paul Blackstone (Mar 25)
- RE: Caching a sniffer David Gillett (Mar 25)