Re: switch jamming

[Blue Boar <BlueBoar () thievco com>]

Just a minor point, in case there is someone out there reading this
thread, and this is new to them.

There are two widely-understood ways to make a switch send traffic your
way that it normally wouldn't, for the purpose of sniffing.  One is to
attempt to cause the MAC address cache to roll over (the is the CAM table
in the Cisco world.)  The other is to poison the ARP cache of one or more
nodes in the same broadcast domain as the sniffer.  The latter is not an
attack against the switch itself per se, but rather the ARP stack of
the victims.  The small bit of confusion (terminology usage, really) is
that people are referring to the MAC address cache rollover attack
as an ARP attack as well.  The frames that cause the problem do not
have to be ARP packets, though they could be if you want.

The original poster did not say whether he would have legitimate
control over the switch, nor what he wanted to monitor traffic for.

Neither of the above mentioned attacks are permanent, nor 100%
reliable.  You're taking advantage of a race condition in
a broadcast medium.  You have to keep re-injecting the spoofed
frames/packets in order to maintain your monitoring, since the
MAC tables and ARP caches will eventually time out.

So, if your goal is to grab the occasional password, or to see
part of a TCP connection so that it can be hijacked, then the
above attacks may be suitable.  You won't need all of the
traffic all of the time to accomplish that.

On the other hand, if you're asking "how does my IDS work after
a switch is installed", then the above attacks are completely
unsuitable (and the question is off-topic for the list).  The
answer for that is that there must be a mirror/span port of
some kind, or you must monitor the uplink.  Check with the
snort-users, or focus-ids lists for more details on the latter.

(Of course, if you've got admin access to the switch, then sniffing
passwords is easy, too.)

                                        BB