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
This archive was generated by hypermail 2b30 : Wed Jan 30 2002 - 16:13:31 PST