Hating to beat dead horses, but, feeling folks trusting VLANs as secure
should be clued there remain issues <Wesley? (grin) you out here?>:
---------- Forwarded message ----------
Date: Mon, 20 May 2002 09:38:25 -0700
From: "COULOMBE, TROY" <[EMAIL PROTECTED]>
To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
Subject: Catalyst 4000
Issue:
Unicast packets flooded out switch ports they shouldn't be.
Platform:
Cisco Catalyst 4000
OS:
5.5.5; 6.3.5; 7.1.2; probably all others
Environment:
Single VLAN, non-default "VLAN 1"; No Spanning Tree; 10/100 48 port
blades.
NO SPAN session is created.
Using a sniffer to capture broadcasts/multicasts, etc only.
Vendor, Vendor Notified, Date Notified:
Yes, Cisco, 04/10/2002; case C579249, no fix supplied
Detailed description:
Middle of a TCP conversation, unicast packets sent to a host are
flooded out all ports.
Using a sniffer [EtherPeek NX for Windows, NAI Sniffer Pro], the
Cat4006 floods TCP packets out
to all ports. Packets captured are unicast-mac and are not destined for the
port the sniffer is on.
No SPAN session is created on the switch; only broadcasts/multicasts and
_initial_ session packets should be
flooded. Sniffer is on a different port than the workstation and servers.
Given:
It is understood that if the switch doesn't know where a MAC is, it
will flood the packet out all
ports until the MAC is learned, and the CAM table is populated. Initial TCP
packets are also captured by the
sniffer, however, these packets would be indicated by the "SYN" flag, and
are considered normal.
However, what is happening, is that TCP session packets are being flooded,
although the switch _should_ have learned
the MAC.
Example:
01) workstation --> DNS server
UDP DNS request packet
02) workstation <-- DNS server
UDP DNS response packet
03) workstation --> Server
Initial TCP SYN packet
04) workstation <-- Server
TCP SYN-ACK packet
05) workstation --> Server
TCP ACK Packet
06) workstation <-- Server
TCP Packet W
07) workstation <-- Server
TCP Packet X
08) workstation <-- Server
TCP Packet Y
09) workstation <-- Server
TCP Packet Z
Packet #01 is _not_ seen by the sniffer, and rightly so, assuming the switch
knows the MAC entry for the DNS server.
Packet #02 is seen by the sniffer, but shouldn't have been. The switch
should have learned the workstation's MAC
entry from packet #01.
Packet #03 is _not_ seen by the sniffer, and rightly so, assuming the switch
knows the MAC entry for the Server.
Packet #04 is seen by the sniffer, but shouldn't have been; no matter what.
The switch now has had 2 different packets
from the workstation to learn it's MAC.
Packet #05 is _not_ seen by the sniffer, and rightly so...
Packet #06 through #09 are seen by the sniffer, but shouldn't have been!
Packet #10 is assumed to be an "ACK" from the workstation and suddenly the
switch registers the workstation's MAC. No
additional packets are seen for _this_ conversation.
I have captured telnet sessions, ftp sessions, etc; with a portion of a
telnet session's password visible. There is no
special setup required to see this other than physical Ethernet connection &
sniffer software.
Exploit:
Patience
Workaround:
Setting the CAM agingtime to a larger time _helps_ but does not
completely eliminate the problem. "set cam agingtime xx 14400" where xx is
VLAN #.
Still waiting on an official fix from Cisco..
Thanks,
Troy Coulombe
_______________________________________________
Firewalls mailing list
[EMAIL PROTECTED]
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls
