lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <Pine.LNX.4.56.0503301447050.25366@redsky.antelope.net> Date: Wed, 30 Mar 2005 15:04:24 -0700 (MST) From: Joel Maslak <jmaslak@...elope.net> To: bugtraq@...urityfocus.com Subject: Re: DoS of LAN via D-Link switches On Wed, 30 Mar 2005, Neil Watson wrote: > I believe what you are describing is officially called a bridge loop. A > bridge loop occurs when a switch, or stack of switches are plugged into > themselves. The result is that the switches report the same MAC address > at multiple ports. The solution to this is called Spanning Tree > Protocol. STP is a set of algorithms that help switches remove > redundant MAC entries. Spanning tree does not prevent redundant MAC entries or even remove them. It does however disable redundant links. Spanning tree operates with no knowledge of end device MAC addresses. Description of the problem and why the switch is not broken: Let's take a 4 port switch. Vendor doesn't matter. It's a cheap $25 job, with no intelligence. All it does is relay broadcast packets to all ports except the source port and relay unicast packets to the last port where the destination address was heard as a source of a layer 2 packet. Port 1 is plugged into MAC A Port 2 is plugged into MAC B Port 3 and 4 are unused Once the nodes on port 1 and port 2 each transmit one packet of any type, the switch associated their MAC address with that port. Thus, the MAC table in the switch looks like: PORT 1 -> "A" PORT 2 -> "B" PORT 3 -> NONE PORT 4 -> NONE If Port 3 is plugged into Port 4, and "A" transmits a packet to the broadcast address, that packet is sent out on all ports. Thus it is heard *again* on both port 3 and 4. Since switches cannot begin to transmit a packet on other ports until it is at least partially received, the packet is sent out on port 3 and 4 *after* it is sent to port 1. Thus either port 3 or 4 will become the owner of that MAC address. Thus you will get: PORT 1 -> NONE PORT 2 -> "B" PORT 3 -> "A" PORT 4 -> NONE Of course, if "B" sends a packet to "A", that packet is sent to port 3, received at port 4, sent back to port 3, received at port 4, etc. In the process the MAC table gets changed to: PORT 1 -> NONE PORT 2 -> NONE PORT 3 -> "A" PORT 4 -> "B" Now certainly one solution to this problem could be "Don't move a MAC address from one switch port to another unless the link on that port goes down." But that will break all sorts of clustering solutions and also break any wireless network where there is more then one AP and people roam between them. Some of the nicer managed switches will detect that the MAC is moving between ports very quickly and flag an error. But that method is hardly foolproof. Another solution is something like CDP and the switch intelligence to detect that a switch is plugged into itself. But this will probably break when someone sticks another switch between the two ports (although the problem described above will still likely exist). If it doesn't, you'll probably end up with, basically, Spanning Tree! And if you are going to the bother of implementing your own custom protocol to detect layer 2 loops, you might as well just implement spanning tree since most networking professionals understand how it works and what its limitations are (mainly: possibly slow convergence time and initial state where end device cannot send traffic). As mentioned before, the solution to this problem is Spanning Tree (or some variant of Spanning Tree like Cisco's quicker-to-converge variant). Basically, a $25 switch isn't "just as good as" a $800 switch, especially not in an enterprise environment. There is a reason those managed switches start to cost real money! Of course there are about 1000 ways for an end user to take down an entire LAN other then plugging loops into a switch (they can set up their own DHCP server, for instance; They can enter the IP of the router in their computer, although most routers have a defense against that; etc). If you truly want to ensure that an end user cannot affect others, you probably want them off a router port, not a switch port (and even this is hardly foolproof). -- Joel
Powered by blists - more mailing lists