DePaul University Networks & Telecom J. Kristoff Request for Comments: 4 R&D/N&T Category: Experimental April, 2002 Class: Public Revision: 1.0 Network Port Security Status of this Memo This document specifies an Experimental Practice for the DePaul University community, and requests discussion and feedback for improvement. It does not specify a DePaul University standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) DePaul University (2002). All rights reserved. Abstract The lack of authentication within low level network communication protocols presents a potential area of abuse by rogue or compromised hosts. Data link technologies such as Ethernet inherently allow end stations to alter the source medium access control (MAC) address on any frames transmitted. While this may be useful in some circumstances, it can be used to launch a number of low level network communication attacks. This document proposes a means with which to limit the abuse that can be done by some types of low level source addressing attacks. Kristoff Experimental [Page 1] RFC 4 Network Port Security April 2002 Table of Contents 1. Address Tables..........................................2 1.1. Bridge Address Tables.................................2 1.2. Address Resolution Protocol (ARP) Tables..............3 2. Low Level Network Address-based Attacks.................4 2.1. Impersonation.........................................4 2.2. Forced Flooding.......................................5 3. Network Port Security...................................6 3.1. Learned versus Manual Configuration...................6 3.2. Address Aging Timers..................................7 3.3. Single versus Multiple Addresses......................7 3.4. Port Violation Actions................................8 3.5. Inactive Ports........................................8 4. General Design Considerations...........................8 Acknowledgements...........................................8 References.................................................8 Security Considerations....................................9 Editor's Address...........................................9 1. Address Tables Various internetworking devices often maintain many types of address tables that are used to make forwarding and filtering decisions. This section describes the generic use of bridge address and address resolution protocol (ARP) tables in internetworking devices. The reader should make note that implementations of address tables can differ greatly. Consult the documentation that accompanies specific products for further details. 1.1. Bridge Address Tables Devices that forward frames using low-level communication protocols such as Ethernet are called layer 2 bridges (or LAN switches to use a more recent and popular term). If the low level communications network is using transparent bridging, layer 2 devices maintain a bridge address table [802.1D]. This bridge address table contains a list of layer 2 source addresses and the associated bridge ports addresses were last seen on. This list is consulted each time a frame is received by a bridge port so that the bridge can make the proper decision to either forward the frame to the appropriate destination port or to filter the frame and prevent it from being seen on other layer 2 networks. If the destination address of a received frame is not in the address table, the bridge will typically flood the frame to all other ports except to the port the frame was received on. A transparent bridge listens promiscuously to each of its interfaces in order to make a forwarding or filtering decision for every frame on each layer 2 network. A layer 2 transparent bridge builds its address table by associating each layer 2 network with the set of hosts that reside there through a Kristoff Experimental [Page 2] RFC 4 Network Port Security April 2002 process known as source address learning. That is, each time a frame is sent on one of the attached networks of the layer 2 bridge, the bridge automatically learns the source address and puts it in its table with the associated port. If the address is already in the table, the table is updated with the new information. This source address learning process makes internetworking with low level communication protocols extremely simple. However, a number of low level network attacks are possible through source addressing spoofing as described in a later section. 1.2. Address Resolution Protocol (ARP) Tables IP hosts and routers that use low level communication networks such as Ethernet must encapsulate IP datagrams into layer 2 frames. For an IP datagram to traverse the layer 2 network, corresponding layer 2 addresses must be used for the source and destination hosts on the layer 2 network. The layer 2 source address is readily available to the sending host, but the destination layer 2 address must be manually configured or automatically discovered. Manually configuring destination layer 2 addresses for each sending host would be tedious and management intensive. Therefore, an automatic discovery mechanism is used to identify destination layer 2 addresses. This mechanism, called the address resolution protocol (ARP), uses a simple layer 2 broadcast request to find the host with the designated next-hop IP address [RFC826]. This next-hop address may be a router or the actual IP destination endpoint. The layer 2 host that is configured to respond to ARP requests for the IP destination address in question will generate an ARP reply. Within the ARP reply to the original sender will be a specific unicast layer 2 address that should be used in subsequent frames to the intended next-hop IP address. The sending host which receives the ARP reply will typically cache the layer 2 destination address to IP address mapping in an ARP cache table. The ARP cache table can then be consulted directly for future transmissions. Typically ARP cache table entries learned through ARP replies have associated aging timers that are used to periodically flush stale layer 2 to IP mappings. In addition, other nearby hosts that see ARP requests and have existing entries in their ARP cache table for the sender may update their ARP cache table entries with the sender's information if it has changed. The use of ARP request and reply frames makes running IP networks on top of low level communications networks such as Ethernet relatively simple. However, similar to the problems with bridge address tables, ARP tables can be subject to various low level network attacks as described in the next section. Various implementations of ARP tables may differ across platforms. For example, many UNIX based implementations combine ARP cache tables with route cache tables. Care must be taken therefore when altering the behavior of one or the other so that the effects do not cause unexpected problems. Kristoff Experimental [Page 3] RFC 4 Network Port Security April 2002 2. Low Level Network Address-based Attacks While a number of low level network attacks are possible, this document focuses on attacks against the low level address tables and address mappings. Unauthenticated address table entries and address mapping protocols lead to particularly damaging failure scenarios. In particular, hosts that transmit layer 2 frames with spoofed addresses and hosts that incorrectly claim a layer 2 address in ARP replies are discussed in this section. Hosts that generate frames with source addresses other than their own can be used by attackers in a number of ways. As stated in the DePaul Network Security Principles RFC [dpuinfosec-3001]: "Attackers may spoof source addresses to hide the origin of an attack, often as part of a denial of service [...]. Attackers may also employ spoofed source addresses to circumvent name or address based host authentication schemes" While the referenced document specifically discusses the case of source address spoofing using the IP protocol, many of the same issues are present in low level network protocols that use source addresses. 2.1. Impersonation While it may be useful for end hosts to use a source address other than that which they were configured for (e.g. clustering or load balancing devices may use ARP spoofing to achieve redundancy), generally end hosts are assigned a single layer 2 address per physical interface attached to each layer 2 network. It is trivial for end hosts to alter their source address through software configuration. If a rogue host knows or learns the source address of a victim machine, the rogue may impersonate the victim by either accepting frames it sees destined for the victim or by telling others on the layer 2 network that it is the victim host. A rogue host can masquerade itself on the layer 2 network by generating layer 2 frames with the victim's source address, which may update bridge address tables. A rogue host may also create fake ARP requests or respond to various ARP requests with spoofed address information in order to populate ARP caches with falsified information. If a rogue host generates spoofed address frames, a bridge may unwittingly update its bridge address table with an incorrect bridge port to source address association. This can result in a form of hi-jacking as outlined in the next section. Alternatively, a rogue host may generate or respond to standard and inverse ARP request packets with spoofed address information. In these cases, the rogue host may trick other hosts on the network to associate a victim's layer 2 address, layer 3 address or both with itself. Kristoff Experimental [Page 4] RFC 4 Network Port Security April 2002 If any of these low-level address attacks succeed a rogue host can impersonate a victim host. Impersonation may result in rudimentary network traffic snooping, man-in-the-middle attacks, hi-jacking or service interruption through a denial of service or black holing scenario. 2.2. Forced Flooding Transparent bridges make frame forwarding decisions based on the destination layer 2 address of received frames. When a transparent bridge receives a frame, it must perform a bridge address table lookup process to determine if it knows which bridge port is associated with that particular destination address. If the destination is in the address table, the bridges make a forwarding or filtering decision. If the destination is associated with the port the frame was received on, the bridge simply filters the frame from being forwarded to any other port. If the destination is associated on a port other than the one the frame was received on, the bridge will forward the frame to the associated layer 2 network on that port. If a transparent bridge knows all of the destination layer 2 addresses the process is relatively straightforward. However, if the bridge has not learned a particular destination address or if the destination address has been flushed from the bridge address table, presumably from an aging timer process, the bridge must flood the frame to all ports other than the port the frame was received on. This process of flooding is not optimal, but it does provide a mechanism for the destination to see the frame no matter which attached layer 2 network it resides on. Bridge address tables are generally bounded in size to hold only a subset of all possible layer 2 address entries. Typically layer 2 networks are designed within the constraints of bridge address table size limitations. However, a rogue host could attempt to overflow a bridge address table by generating multiple frames each with different layer 2 source addresses. If a rogue host can generate enough spoofed addresses and overflow a bridge address table with invalid entries, bridges may be forced to flood frames to all bridge ports rather than the actual port the bridge would have known before the overflow occurred. This type of forced flooding attack can be used by rogue hosts to either see traffic it might not have otherwise have seen or as a layer 2 denial of service attack. Since bridges with address tables that are in forced flooding mode will copy all traffic to all ports except the port for which traffic was received, hosts on other layer 2 networks can potentially eavesdrop on all of the flooded traffic. Layer 2 interfaces can often be set to operate in promiscuous mode by simple software configuration. Promiscuous mode allows the host to watch and copy all traffic see on its layer 2 network regardless of its intended destination. Kristoff Experimental [Page 5] RFC 4 Network Port Security April 2002 3. Network Port Security While the network should not rely on low level source addresses for authentication, network access ports should be secured to help limit low level source address-based attacks from occurring. Many low level communication devices such as multi-station LAN repeaters (also known as hubs) and bridges (also known as LAN switches) have the capability to be configured so that each port only allows a subset of layer 2 source addresses from being sent to the device. In addition, parameters may be available to learn the first address seen, an aging timer for learned source addresses and an action to take in the case of a source address violation. Enabling the use of these mechanisms and parameters on low level communications devices are often referred to as network port security or just simply as 'port security'. The following sections outline recommendations for these device configurations that may help prevent the low-level layer 2 source address-based attacks from jeopardizing the integrity of layer 2 networks. 3.1. Learned versus Manual Configuration Low level communication devices often allow the option of populating the bridge address table manually. That is, an administrator would enter all the layer 2 addresses and their associated network access ports into the low communications device configuration. The intent with manual address configuration is to provide the utmost control over end hosts attached to a layer 2 device. Devices that allow source addresses to be learned are generally setup to learn the current subset of addresses attached to the device. Once addresses are learned, those addresses remain associated with the port indefinitely or until an aging timer expires after not having seen any transmissions from the source address(es) in question. As long as the correct set of source addresses are learned and the aging timers do not prematurely expire, either learned or manual address configuration should provide similar protection of address-based attacks. Due to the overhead in administration and the susceptibility for human error, it is recommended that source addresses be learned at the time of initial installation of end hosts. Presumably new hosts being installed on the network for the first time can be trusted to provide the correct layer 2 address for its first transmission, which will be learned by the low level communications device. Kristoff Experimental [Page 6] RFC 4 Network Port Security April 2002 3.2. Address Aging Timers Entries in bridge address tables can generally have an associated aging timer, which allows stale table entries to be periodically flushed in order to save resources and allow for mobility. Here we assume end hosts are generally not mobile and so address table entries should remain relatively stable over time. If source addresses and their associated ports do not remain stable over time, network port security may be an inappropriate method for helping to prevent source address-based attacks. Aging timers for associated ports and layer 2 addresses can generally range from a few minutes to a number of hours. Generally there is also an option to mark the table entry as permanent, requiring intervention from an administrator if the table entry needs to be changed. Often administrators of the network equipment are not the same as the administrators of the end hosts that are attached to the network. For this reason, it is recommended that aging timers be used in order to minimize multi-party intervention when changes to end hosts or the network are made. Aging timers should last long enough to prevent lightly used end hosts from being aged out, but short enough to allow for end host changes to be done with minimal downtime if network administrators are unavailable to intervene. It is recommended that aging timers be a minimum of 30 minutes and a maximum of 4 hours. Thirty minutes should be used for end hosts that change infrequently and generally have at least some background management traffic to keep the aging timer updated. This also allows for these more critical devices to be changed out quickly in the rare cases that they need to be upgraded or replaced. Four hours should be used for end hosts that may change infrequently, but are often idle for extended periods of time. 3.3. Single versus Multiple Addresses Port security may allow only a single address to be associated with a port or multiple source addresses. Multiple source addresses may be required if attached to the port is another low level communications device such as a LAN hub or bridge. In most cases, it is anticipated that a maximum of one single source address is sufficient, however, there may be a number of circumstances where multiple source addresses per port would be desirable. While it is not the intention of this document to limit the use of the network by end hosts and users, we recommend that ports be configured to support a small number of source addresses. It is recommended that Kristoff Experimental [Page 7] RFC 4 Network Port Security April 2002 well known services such as servers and routers be connected to devices that permit only a single source address per port. It is further recommended that devices connecting end users be allowed to support a minimum of 16 source addresses per port by default. 3.4. Port Violation Actions Devices implementing port security may have the option to handle source address violations in a number of ways. One option may be to completely disable the port if an invalid source address is seen. We feel this is too stringent. We recommend that invalid source addresses should simply be discarded by the low level communications device. We also recommend that invalid source addresses seen should be logged so that out-of-profile events can be brought to the attention of an administrator. 3.5. Inactive Ports It is recommended that ports on low level communication devices that are not in use be disabled by default to prevent unauthorized use of network ports. 4. General Design Considerations Trade-offs in security and usability dictated much of the decisions in this document. While the most stringent of parameter settings may have been seen as the most secure configuration, these recommendations hopefully provide the majority of the security benefit while still allowing some flexibility and ease of use for users and administrators. Network port security is one additional measure to implement a defense-in-depth approach to network security at DePaul University. While no system is foolproof, network port security may help prevent low level source address-based attacks. Acknowledgments Thanks to Eric Pancer and Bill Eaheart for their discussion on this topic, which forced the writing of this document. Also thanks to Rob Thomas for his valuable feedback on an early draft. References 802.1D 802.1D IEEE MAC Bridges Working Group, http://www.ieee802.org/1/pages/802.1D.html. dpuinfosec-3001 J. Kristoff, Network Security Principles, DePaul University INFOSEC RFC 3001, January 2002. Kristoff Experimental [Page 8] RFC 4 Network Port Security April 2002 RFC826 David C. Plummer, An Ethernet Address Resolution Protocol, RFC 826, November 1982. Security Considerations The source address attacks described in this document may still be possible due to faulty hardware, software and misconfiguration. It is also well known that network port security offers no additional authentication mechanisms to content in layer 2 frames. Furthermore, other uses of ARP, such as proxy ARP, have been purposefully left out of this document since DePaul does not generally use those mechanisms. However, there may be other low level communication attacks that are not addressed here. Additional security is needed at all layers of the communication system to help prevent other types of attacks. Editor's Address John Kristoff Research & Design, Networks & Telecom DePaul University 1 East Jackson Boulevard Chicago, IL 60604 USA Phone: +01 312 362-5878 EMail: jtk@depaul.edu Kristoff Experimental [Page 9]