Network Protection at Layers 2 and 3

After you're inside the perimeter, you can protect hosts at several layers. In Chapters 12 through 14 ("Server and Client Hardening," "Protecting User Applications," "Protecting Services and Server Applications," respectively), we discuss protecting the hosts and the applications that run on them. In this chapter, we're primarily exploring protecting hosts by using the lower layersparticularly at layer 2 (the data link layer) and layer 3 (the network layer).

At layer 2 we focus on keeping bad guys off the network in the first place. This is the layer at which VLANs and 802.1X (a network authentication protocol) operate . These technologies allow us to keep systems from being able to pass electrons (or photons , as the case may be) to each other. There are some distinct advantages to protecting the network at this layer. First, by not letting bad systems on to the network, you do not have to worry about them flooding the network with traffic to bring down routers and other devices. Second, it means that if a device is capable of speaking to another device, it's probably allowed to be there. However, there are some disadvantages too. 802.1X requires switches that can participate in an authentication infrastructure. It doesn't work with hubs.

Although you may not have many physical hubs, every virtual machine host is a hub. In a virtual machine environment, only the host is authenticated to the network. Thus, if your objective is, for instance, to keep unpatched systems off the network, 802.1X won't be able to do so with virtual machine guests. Finally, 802.1X requires 802.1X-capable devices, both on computers and other equipment. Generally speaking, building this out involves taking all the really old routers, switches, concentrators, access points, and other gear you've been meaning to replace someday anyway and putting it in the Dumpster behind the building. Then you replace it with all new routers, switches, concentrators , and other gear. Look at this as a budget-depleting year-end project you can use to ensure next year's budget doesn't get reduced.

At layers 3 and 4 the primary network protection tool is IPsec. IPsec is our hands-down favorite for "most useful security tool ever invented." It is infinitely flexible and can be applied to a number of different purposes. IPsec is particularly good for blocking traffic, even if that was not what you originally intended. For that reason, you need to be very careful with IPsec. It is challenging to implement.

IPsec solves most of the problems with 802.1X, but it doesn't prevent a flooding attack. You can't keep a malicious host from sending data with IPsec, although you can detect it pretty easily and simply air-gap that device's switch port. You can only keep other machines from listening. That means that if a malicious host gets on your network, it can take down most of the network's bandwidth by flooding it with data. To solve that problem, you need to use 802.1X or something similar in conjunction with IPsec. In the remainder of this chapter, we look at each of these technologies in turn .

The Problem with ARP

It's amazing that despite the cool stuff we introduce in this chapter, there isn't much you can do to protect against ARP attacks. ARP is the protocol a computer relies on to translate 32-bit IP addresses into 48-bit MAC addresses. ^[1] Normally, when one computer needs to find another one, it broadcasts a request for that computer's MAC address. That computer replies directly to the requester. There are other kinds of ARP communications: a computer might send a gratuitous ARP reply to any device it wants to (usually an upstream router or load-balancing device); a computer might also broadcast an unsolicited ARP request claiming that it owns a particular IP address. Receiving computers must accept these replies and requests without verificationleading to potential attacks.

^[1] "An Ethernet address resolution protocol" (http://www.rfc-editor.org/rfc/rfc826.txt).

All computers honor and cache ARP replies, whether normal or gratuitous (although statically assigned ARP entries won't be overridden). You can force redirection by poisoning a computer's ARP cache with spoofed entries (although proxy ARP, used by many routers, does this legitimately). Or an attacker can easily turn your shiny expensive Ethernet switch into a cheap useless hub by flooding the switch's memory with bogus ARP-to-IP mappings. Because it then has no memory left to store legitimate mappings, the switch mirrors all traffic on all ports. This is the default behavior of many switches.

ARP is also vulnerable to man-in-the-middle attacks. An attacker waits until a client learns the MAC of a server it wants to communicate with. Then the attacker sends a gratuitous ARP reply to the client claiming that the server's IP address maps to the attacker's MAC address. He also sends a gratuitous ARP reply to the server, this time claiming that the client's IP address maps to the attacker's MAC address. Now the attacker can intercept, eavesdrop on, and modify all traffic between the client and the server.

There are no defenses built in to the protocol itself. Arpwatch ^[2] can help you keep track of MAC-IP pairings but requires that you configure one of your switch ports to mirror all traffic. The features on some switches can help, toosome switches allow you to configure a rule permitting only one MAC address per port, but managing this can be a nightmare if someone changes his or her NIC or installs a workgroup switch in an office. It's better to periodically compare requests and replies to other mapping information that DHCP servers and some DHCP snooping might provide.

^[2] http://www-nrg.ee.lbl.gov.

You might think that you should just give up now, set all your computer and network gear on fire, and haul out the stone knives and bearskins. (Actually, the network bonfire sounds like a lot of fun.) But with the correct application of the appropriate technologies we describe in this chapter, you can pretty much eliminate the usefulness of these kinds of attacks. Which, as network defenders, is really what we're all trying desperately to figure out how to do.