hi all, just wondering, MAC flooding attack. In a typical MAC flooding attack, a switch is flooded with packets, each containing different source MAC addresses. If we consume the limited memory set aside in the switch to store the MAC address-to-physical port translation table it will start to remove valid MAC-to-port mappings. All incoming packets are broadcast out on all ports (as with a hub), instead of just down the correct port as per normal operation. A malicious user could then use any packet sniffer (such as Wireshark) running in promiscuous mode to capture sensitive data from other computers (such as unencrypted passwords, e-mail and instant messaging conversations), which would not be accessible were the switch operating normally. How can it be technically possible, I mean the MAC table is filled with garbage MAC addresses, removing all valid entries ... so what would happen if I'm in the middle of a file copy between to hosts and both the source and destination MAC addresses get removed? The source MAC is not anymore in the CAM Table (it will not be added because let's say we have reached the limit of 15,000 allowed entries or it would remove another entry to make room for the hosts valid MAC ?? ). What about the destination MAC ? it will broadcast an ARP request in the middle of the file copy process (TCP stream)??? how can be the data intercepted by Wireshark useful for me ? I appreciate all comments! BR Adam asked 29 Dec '15, 13:09  adasko |
One Answer:
You mix two things together, the MAC table of the switch and the arp table of the protocol stack on the connected machine. The MAC flood will make the switch send a copy of any received packet out through all ports, which is a default behaviour for any destination MAC unknown to the switch even if there is no ongoing flood. But any receiving machine will ignore packets whose destination MAC is not that machine's own one, and it will not learn those fake source MACs because it does not need them. Similarly, the sending machine will not lose the association between destination IP and destination MAC, so it has no reason to send a new arp request. If it does have a reason, the arp request will reach its destination as it would normally (as arp requests are normally broadcast anyway), and the response will be delivered too. All this is valid if the MAC flood does not cause packet loss, because as ingress traffic from any port is copied to all ports at egress, the total throughput of the switch is equivalent to the nominal bit rate of a single port (same like with a hub). The switch itself never sends ARP requests, it builds the association between ports and a MAC addresses solely based on source MACs of packets coming in through a given port. It means that if you connect a piece of equipment to a port of a switch, the switch does not know its MAC until the piece of equipment sends the first packet. In most cases, such first packet will be an arp response, because any other piece of equipment will first ask for the new equipment's MAC address by sending and arp request. In rare cases, the sending equipment will send a unicast packet with destination MAC of the newly connected one without first using an arp request to determine it, but in such cases, the switch will broadcast that first packet not because its destination MAC address is a broadcast/multicast one but because it is unknown to it. And it will continue to do so until it learns the MAC from an incoming packet which has it as a source one - or forever, see how e.g. Microsoft Network Load Balancing works. And even if an arp request arrives to a network adaptor (of a PC) between two packets of a TCP session, it causes no trouble, it is a normal event. answered 29 Dec '15, 14:25  sindy edited 29 Dec '15, 14:28 |
But before i can send traffic to a host i need to know it's MAC address. If there's an entry in the CAM table for host A and the receiving host B it will know that it has (the switch) to forward all pacekts for host B to let's say port eth 0/1. After an attack valid entries are removed,so the entry for host B as well. So how can the switch still know where to move the packets? It will broadcast to all ports. But The CAM table is full so how it can again update hosts B mac in it‘s table?
Once again: if the mapping table (MAC -> port) of the switch does not contain (for any reason) a destination MAC address of a packet, the switch sends the packet out through all ports, i.e. does the same thing it would do if the packet's dst mac would be a broadcast one.
This behaviour does not affect arp requests, arp responses and normal communication between any two pieces of connected equipment because this is exactly the same what hubs are doing and equipment connected to hubs was doing just fine for years.
The only purpose of the mapping table is to reduce the collisions: on a hub, if port A receives a packet for port B at the same time when port C receives a packet for port D, both packets will be corrupt because both will be sent to all ports. Thus they will have to be retransmitted (after random delay so that they wouldn't collide again). On a switch, the switching matrix has a throughput which is a double of a sum of ports' speeds, so if the packets do not meet at the same egress (output) port, they do not collide.
The other part is the recovery after the MAC flood ends. The switch replaces the oldest records in the MAC->port table with the newest arrivals, which is also a normal operation principle (think about how changes in the network configuration on the fly can be handled). So as long as the flood of fake unique source MACs keeps coming in, the switch keeps doing that, quickly pushing the real MACs of connected equipment out of the table again when they get there. As soon as you stop the flood, the switch learns the valid MACs again in no time because they keep coming.
thank you @sindy for taking the time to answer my questions, I really appreciate it!
to double check.the switch is behaving like a hub during a mac flooding attack, right ? and because of this, each station running a network analyzer could "see" packets exchanged between each and every hosts in the give LAN segment, right ?
BR
Adam
right and right.
Just don't forget that you cannot be 100% sure that the network analyzer will see all packets: during the flood, the real MACs of connected equipment also keep appearing as source ones, so for short periods of time, until they get pushed out by the flood again, they exist in the MAC -> port mapping table of the switch. Due to this, some packets may be delivered to their proper destination ports directly and thus not reach the analyzer.
Thank you "sindy. It's finally clear now! Great help!
wish you a happy new year !