LAN switch security: what the hackers know that you don't

Author experts explain how to thwart ARP spoofing, ARP poisoning, P2P traffic, wireless LAN threats and more during a live Network World Chat.

Ethernet switches are not inherently secure. Author experts Christopher Paggen and Eric Vyncke explain how to thwart threats like ARP spoofing, ARP poisoning, P2P traffic, wireless LAN threats and attacks against Spanning Tree Protocol, Cisco Discovery Protocol, data plane protocols and DHCP.

Moderator-Julie: Welcome to Network World Chats. Today's guest is author expert Christopher Paggen discussing the topic, LAN switch security: What hackers know about your switches. He penned a book of the same title. We have a surprise guest coming today, too; Chris's co-author, Eric Vyncke (but Eric will be joining us late). 

Christopher_Paggen: Hello - glad to be here!

ARP spoofing and ARP poisoning

Moderator-Keith: Why should we care about LAN security? Outside hackers can't do much (we're behind a firewall), and we're pretty sure that employees aren't engaging in illicit activities.

Christopher_Paggen: While you are correct with regard to the firewall protecting you from outside LAN attacks, LAN-borne attacks are always performed locally by someone hooked up to a local network port. The range of people performing LAN attacks can range from adventurous employees "playing around" with Swiss-army-knife tools to  motivated malicious guests trying to harvest confidential data.

BartKnight: I've heard it's possible for a hacker operating inside the company to intercept all LAN traffic without ever being noticed. How is this possible?

Christopher_Paggen: Yes, it's indeed possible by using ARP poison routing.

Stiekes: How many of the LAN security risks are more accurately characterized as resulting from compromises of host systems?

Christopher_Paggen: Many very potent LAN attacks such as ARP spoofing are performed on a remote machine connected to same LAN as the victim(s). So even if your host is patched with the latest antivirus software, it talks on the Ethernet segment and remains subject to communication hijacking.

Sully: What about VLAN hopping on a switch? Is it possible and, if so, then how can it be prevented?

Christopher_Paggen: VLAN hopping is one of the trickiest attacks in the sense that it takes many favorable conditions lined up to occur. While tools such as Yersinia make it easy to attempt, the return from a hacker's perspective is fairly minimal: malicious traffic is injected one way from the hacker to the victim. The hacker gets no feedback from the victim as traffic coming back from the victim won't hop VLANs back to the hacker. All in all, I would rate this a low severity, hard to perform attack.

Fred: Can you give us some examples of typical attacks, and how to defend against them?

Christopher_Paggen: Sure. The worst attack is probably ARP poisoning. I rate it worst because it's extremely sneaky, very efficient and (too) easy to perform. There are two ways to protect yourself from an ARP spoofing/poisoning attack: either you monitor suspicious ARP traffic on a machine connected to the LAN (using ARPWatch for instance, a free Linux utility) or you rely on the switch's built-in security mechanism. Most Cisco switches, for instance, ship with protection against ARP spoofing attacks. They do so by associating a MAC entry (including the source Ethernet MAC and the payload of the ARP packet) to a given trusted port. If the same ARP packet shows up on a different port, that port isn't allowed to talk and a violation indication is triggered.

DTC: Can you recommend any tools that can counter ARP spoofing?

Christopher_Paggen: If you are looking for a solution that is independent of the switch itself, you can monitor ARP activity on the LAN using ARPWatch for example. It runs on Linux and it's free (or under the GPL license).

Sully: Can't ARP spoofing be eliminated by using "IP ARP inspection" with DHCP  snooping?  Our typical switch configuration includes port security, ARP inspection, DHCP snooping, BPDU-guard, BPDU -filter, root guard, and CDP off.

Christopher_Paggen: Yes, those are indeed mechanisms that were designed to combat ARP spoofing attacks.

Stiekes: You've described ARP spoofing as a high-risk exploit in which data transiting a switch could be redirected to a compromised host. What other switch vulnerabilities exist that could compromise data transiting the switch?

Christopher_Paggen: That is precisely the issue with ARP poisoning attacks. Tools such as Abel&Cain not only install stale ARP entries but also reroute traffic back to its intended destination! Therefore, you wouldn't even notice that your traffic is being intercepted.

Moderator-Julie: Eric Vyncke has now joined us and is jumping in to answer questions.

Christina: As ARP poisoning keeps coming up, can you recommend some ways to mitigate it?

Eric_Vyncke: Chapter 6 describes the way to mitigate this attacks. In summary, look inside the DHCP traffic in order to learn the official mapping of IP and Ethernet addresses, then inspect all ARP packets and check whether the ARP replies contain the official mapping (the one learned from DHCP). If the mapping is not the official one, drop the ARP reply. Simple and efficient.

echoreply: Referring to the "simple and efficient" comment you made, I'd say, this is not simple if you are using static IPs (as in a data center environment) and have to manually map everything. ;-)

Eric_Vyncke: Agreed. This will then become 'efficient' alone because you need to pre-define the official mapping of MAC vs. IP addresses (which is not so 'easy' even if 'simple').

Stiekes: What level of protection, if any, would the use of private VLANs provide?

Christopher_Paggen: Private VLANs provide excellent isolation between broadcast domains. They create little VLANs inside VLANs if you will, and make sure hosts on isolated ports can only communicate to a trusted port called the promiscuous port. So right out of the bat, ARP spoofing attacks will be more difficult to carry out (although not impossible, but they'll be one-way only).

Peer-to-peer (P2P) traffic

Sully: How do you feel about protected ports for hosts? I'm talking about using them to talk through the router to prevent peer-to-peer traffic as well as permit traffic control with ACL's?  I haven't done this yet because the port will support either port-security sticky or protected but not both.

Christopher_Paggen: Blocking peer-to-peer traffic isn't trivial. P2P software engineers go out of their way to find mechanisms that will work through firewalls, using well known ports such as TCP 80, etc. At the LAN level, it's too early (or too low in the ISO stack) to recognize the nature of the traffic. The switch sees the PC's MAC address and can either permit or deny it, but that isn't sufficient to determine whether the traffic is legitimate or P2P.

june: Can you rate limit P2P traffic?

Eric_Vyncke: Rate limiting P2P is not really linked to LAN security but is indeed doable (mostly in service provider networks because the rate limiting devices are quite expensive to buy). If the P2P runs on a default port, than rate limiting can be done on the switch.

Bob: What steps do you suggest in trying to 'bullet-proof' any PC in a LAN, including peer-to-peer, server-based, etc?

Christopher_Paggen: There are many steps you can take, such as implementing behavior-based anomaly detection software (Cisco's CSA comes to mind). Now keep in mind that LAN attacks exploit LAN protocols themselves, and are able to be performed regardless of the host hardening level. That's because at some point, the host will have to "talk" on the LAN.

Flooding attacks

Cisconow: Do you recommend a particular configuration checklist in order to ensure that common attack points are covered?

Christopher_Paggen: Yes - some time ago, Cisco commissioned a company called AtStake to test the security of VLANs. A report was produced after the engagement.

echoreply: Want to mention I've read the book and loved it. I have a question regarding the manner in which Cisco switches will fail under DoS attacks. Is there any test information that exists which points out how Cisco switches will react under varying levels of DoS/DDoS attacks? In terms of VLANs failing open etc.

Christopher_Paggen: Glad you liked the book! That is a good question. You will usually find that vendors publish guidelines for many features. For instance, in terms of BPDU and generic protocol tunneling we publish guidelines as to how many frames per second this or that processor is comfortable with. Same thing with logical number of spanning-tree ports. However, vendor recommendations can't supplant a full-blow professional assessment from a reputable pen-testing company. Vendors can't control each and every configuration deployed out there, so it's important to rely on our own assessment on top of vendors' guidelines.

echoreply: In terms of layer 2 hardening everything you have described makes sense, but what I have run into in the enterprise is that many of the hardcore InfoSec types (ISS employees included) continue to argue that Cisco switches are vulnerable to flooding attacks which will cause VLAN segmentation to fail open versus failing closed. I guess my question is, what documentation within Cisco either supports or disputes this claim of Cisco switches (VLANs) failing open under stress (besides the AtStake doc)?

Eric_Vyncke: It is really surprising that this old story keeps appearing :-) As far as I know, there is no additional document apart from the AtStake document. Flooding attacks will never cause VLAN segmentation to fail open but Cisco does not have any external documents about it. I'm pretty sure that nobody in the switching industry has this kind of document. The threat of IEEE .1q is well understood nowadays. This is an old story :-)

echoreply: Eric that is what I keep trying to explain to the InfoSec group I work with, but they are a bit hard headed. ;-)

Eric_Vyncke: Tell me :-)  Not sure how we can help you there. You may want to revert their technique: show me an example of an attack doing this by pure flooding. Or else, just use one switch per VLAN (your Cisco account manager will be happy!). And even in this case (used in some very high security environments), there is still the issue of HUMAN mistakes: putting the cable in the wrong place. Bottom line, a centralized switch with multiple VLANs is safer because you don't need to care about cables going in the wrong places. BTW, this was the same decision made by a highly secure organization. Use a switch. It is safer.

STP, VTP and BPDU

Timmy: What are some examples of Spanning Tree Protocol and VLAN Trunking Protocol hacks?

Eric_Vyncke: STP attacks can include DoS against the STP control plane (sending too many BPDU to the CPU to go to 100% of load), pretending to be the root of the STP in order to change the 'routing' topology. VTP hacks could be used to change which VLANs are recognized (assuming the use of a non-authenticated VTP), also a DoS if you make some VLAN disappear from your campus network.

Timmy: On the STP attack, anything exist such as a rate-limit type suppression for BPDU 's to protect against the floods?  [Cisco's] BPDU Guard and Root Guard should help with some of these, correct ?

Eric_Vyncke: Timmy, you are correct. The control plane attacks can be mitigated with BDPU Guard (Chapter 3) AND with control plane policing (Chapter 13).

Christina: What would you do to combat DoS against STP?  BPDU Guard, bpdu-filter, Root Guard?  Which is better?  By default, I hardcode the root priority.

Christopher_Paggen: Generally speaking, an end station (a host) has no business participating in spanning-tree. Therefore, I would recommend bpdu-filtering towards host ports. This silently discards incoming and outgoing BPDUs, removing all potential for STP DoS attacks originating from hosts.

Stiekes: Any known challenges with implementing BPDU Guard in the data center as appliances and host platforms move steadily toward virtualization?

Eric_Vyncke: Virtualization is indeed an exciting trend in the industry. I know about no challenge linked to virtualization and BPDU guard.

Mobile / laptop security

Bob: What steps would you suggest to protect laptops when you're traveling or moving about in wireless environments?

Eric_Vyncke: Wireless laptops should associate only to trusted networks (to prevent your laptop believing it is in a secure environment), that is, they should be able to check whether the AP (actually the RADIUS server behind the AP) is from a trusted person; this can be done with PEAP, EAP-TLS, etc. Now, if your laptop also associates in hot spots when travelling, you are exposed to attacks from your WIFI neighbors of course. Some hot spots prevent the direct communication from a local WIFI station to another local WIFI station (but you cannot be sure whether your hot spot is configured like this). The final protection is a personal firewall or host intrusion prevention system (like Cisco Security Agent).

Sully: How do you handle port security with mobile users' laptops on the same switch?

Christopher_Paggen: I would recommend adjusting the inactivity timeout parameter, along with a dynamic MAC learning mode. It will require some amount of tuning as it depends on how much time elapses between user_X sitting at port A and user_X sitting at port B.

General security / LAN switch questions

tshoot: How do you handle security for a user plugged into the data port of a phone that is authenticated via 802.1x, etc, but the user may not be?

Christopher_Paggen: Recent IOS versions include mechanisms to protect the phone itself but not the data port.

Related:
1 2 Page 1
Page 1 of 2
IT Salary Survey: The results are in