Menu
Home
People
Places
Arts
History
Plants & Animals
Science
Life & Culture
Technology
Reference.org
Link layer security
open-in-new
<h2 id="network-interface-layer">Network interface layer</h2> <p>The link layer is the interface between the host system and the network hardware. It defines how data packets are to be formatted for transmission and routings. Some common link-layer protocols include <a href="/facts/IEEE_802.2/JIkDGFMY">IEEE 802.2</a> and <a href="/facts/X.25/yaGPqw2Y">X.25</a>.<a class="footnote-ref" id="fnref:1" href="#fn:1"><sup>1</sup></a> The data link layer and its associated protocols govern the physical interface between the host computer and the network hardware. The goal of this layer is to provide reliable communications between hosts connected on a network. Services provided by this layer of the network stack include:<a class="footnote-ref" id="fnref:2" href="#fn:2"><sup>2</sup></a> </p> <ul><li>Data Framing – Breaking up the data stream into individual frames or packets.</li> <li>Checksums – Sending <a href="/facts/Checksum/AqxQ0I8g">checksum</a> data for each frame to enable the receiving node to determine whether or not the frame was received error-free.</li> <li>Acknowledgment – Sending either a positive (data was received) or negative (data was not received but expected) acknowledgement from receiver to sender to ensure reliable data transmission.</li> <li>Flow Control – Buffering data transmissions to ensure that a fast sender does not overwhelm a slower receiver.</li></ul> <h2 id="vulnerabilities-and-mitigation-strategies">Vulnerabilities and mitigation strategies</h2> <h3>Wired networks</h3> <h4>Content Address Memory (CAM) table exhaustion attack</h4> <p>The data link layer addresses data packets based on the destination hardware's physical Media Access Control (MAC) address. Switches within the network maintain Content Address Tables (CAMs) that maps the switch's ports to specific MAC addresses. These tables allow the switch to securely deliver the packet to its intended physical address only. Using the switch to connect only the systems that are communicating provides much greater security than a network hub, which broadcasts all traffic over all ports,<a class="footnote-ref" id="fnref:3" href="#fn:3"><sup>3</sup></a> allowing an eavesdropper to intercept and monitor all network traffic. A CAM Table Exhaustion Attack basically turns a switch into a hub.<a class="footnote-ref" id="fnref:4" href="#fn:4"><sup>4</sup></a> The attacker floods the CAM table with new MAC-to-port mappings until the table's fixed memory allotment is full. At this point the switch no longer knows how to deliver traffic based on a MAC-to-port mapping, and defaults to broadcasting traffic over all ports. An adversary is then able to intercept and monitor all network traffic traversing the switch to include passwords, emails, instant messages, etc.<a class="footnote-ref" id="fnref:5" href="#fn:5"><sup>5</sup></a> </p><p>The CAM table-overflow attack can be mitigated by configuring port security on the switch. This option provides for either the specification of the MAC addresses on a particular switch port or the specification of the number of MAC addresses that can be learned by a switch port. When an invalid MAC address is detected on the port, the switch can either block the offending MAC address or shut down the port.<a class="footnote-ref" id="fnref:6" href="#fn:6"><sup>6</sup></a> </p> <h4>Address Routing Protocol (ARP) spoofing</h4> <p class="note">Main article: <a href="/facts/ARP_spoofing/NcWv5skQ">ARP spoofing</a></p> <p>At the data link layer a logical <a href="/facts/IP_address/z9V22Sw9">IP address</a> assigned by the network layer is translated into a physical <a href="/facts/MAC_address/SVcTfgUH">MAC address</a>. In order to ensure reliable data communications all switches in the network must maintain up-to-date tables for mapping logical (IP) to physical (MAC) addresses. If a client or switch is unsure of the IP-to-MAC mapping of a data packet it receives it will send an Address Resolution Protocol (<a href="/facts/Address_Resolution_Protocol/1QyKybkn">ARP</a>) message to the nearest switch asking for the MAC address associated with the particular IP address. Once this is accomplished the client or switch will update its table to reflect the new mapping. In an <a href="/facts/Address_Resolution_Protocol/1QyKybkn">ARP</a> spoofing attack the adversary broadcasts the IP address of the machine to be attacked along with its own MAC address. All neighboring switches will then update their mapping tables and begin transmitting data destined to the attacked system's IP address to the attacker's MAC address.<a class="footnote-ref" id="fnref:7" href="#fn:7"><sup>7</sup></a> Such an attack is commonly referred to as a "man in the middle" attack. </p><p>Defenses against ARP spoofing generally rely on some form of certification or cross-checking of ARP responses. Uncertified ARP responses are blocked. These techniques may be integrated with the <a href="/facts/Dynamic_Host_Configuration_Protocol/lpASHnhz">Dynamic Host Configuration Protocol</a> (DHCP) server so that both dynamic and static IP addresses are certified. This capability may also be implemented in individual hosts or may be integrated into Ethernet switches or other network equipment.<a class="footnote-ref" id="fnref:8" href="#fn:8"><sup>8</sup></a> </p> <h4>Dynamic Host Configuration Protocol (DHCP) starvation</h4> <p>When a client system without an <a href="/facts/IP_address/z9V22Sw9">IP address</a> enters a network it will request an IP address from the resident <a href="/facts/DHCP_server/lpASHnhz">DHCP server</a>. The DHCP server will reserve an IP address (so anyone else asking for one is not granted this one) and it will send that IP address to the device along with a lease identifying how long the address will be valid. Normally, from this point, the device will respond by confirming the IP address with the DHCP server and the DHCP server finally responds with an acknowledgement. </p><p>In a DHCP starvation attack, once the adversary receives the IP address and the lease period from the DHCP server, the adversary does not respond with the confirmation. Instead, the adversary floods the DHCP server with IP address requests until all addresses within the server's address space have been reserved (exhausted). At this point, any hosts wishing to join the network will be denied access, resulting in a <a href="/facts/Denial_of_service/6nkoK02J">denial of service</a>. The adversary can then set up a rogue DHCP server so that clients receive incorrect network settings and as a result transmit data to an attacker's machine.<a class="footnote-ref" id="fnref:9" href="#fn:9"><sup>9</sup></a> </p><p>One method for mitigating this type of attack is to use the IP source guard feature available on many Ethernet switches. The IP guard initially blocks all traffic except DHCP packets. When a client receives a valid IP address from the DHCP server the IP address and switch port relationship are bound in an <a href="/facts/Access_Control_List/t38J9Vao">Access Control List</a> (ACL). The ACL then restricts traffic only to those IP addresses configured in the binding.<a class="footnote-ref" id="fnref:10" href="#fn:10"><sup>10</sup></a> </p> <h3>Wireless networks</h3> <h4>Hidden node attack</h4> <p>In a wireless network many hosts or nodes are sharing a common medium. If nodes A and B are both wireless laptop computers communicating in an office environment their physical separation may require that they communicate through a <a href="/facts/Wireless_access_point/701JjIzt">wireless access point</a>. But only one device can transmit at a time in order to avoid packet collisions. Prior to transmitting, Node A sends out a Ready to Send (RTS) signal. If it is not receiving any other traffic the access point will broadcast a Clear to Send (CTS) signal over the network. Node A will then begin transmitting while Node B knows to hold off transmitting its data for the time being. Even though it cannot directly communicate with Node A, i.e. Node A is hidden, it knows to wait based on its communication with the access point. An attacker can exploit this functionality by flooding the network with CTS messages. Then every node assumes there is a hidden node trying to transmit and will hold its own transmissions, resulting in a <a href="/facts/Denial_of_service/6nkoK02J">denial of service</a>.<a class="footnote-ref" id="fnref:11" href="#fn:11"><sup>11</sup></a> </p><p>Preventing hidden node attacks requires a network tool such as NetEqualizer.<a class="footnote-ref" id="fnref:12" href="#fn:12"><sup>12</sup></a> Such a tool monitors access point traffic and develops a baseline level of traffic. Any spikes in CTS/RTS signals are assumed to be the result of a hidden node attack and are subsequently blocked. </p> <h4>De-auth (de-authentication) attack</h4> <p>Any client entering a wireless network must first authenticate with an access point (AP) and is thereafter associated with that access point. When the client leaves it sends a deauthentication, or deauth, message to disassociate itself with the access point. An attacker can send deauth messages to an access point tied to client IP addresses thereby knocking the users off-line and requiring continued re-authenticate, giving the attacker valuable insight into the reauthentication handshaking that occurs.<a class="footnote-ref" id="fnref:13" href="#fn:13"><sup>13</sup></a> </p><p>To mitigate this attack, the access point can be set up to delay the effects of deauthentication or disassociation requests (e.g., by queuing such requests for 5–10 seconds) thereby giving the access point an opportunity to observe subsequent packets from the client. If a data packet arrives after a deauthentication or disassociation request is queued, that request is discarded since a legitimate client would never generate packets in that order.<a class="footnote-ref" id="fnref:14" href="#fn:14"><sup>14</sup></a> </p> <h2 id="references">References</h2> <ol> <li id="fn:1"><p>"The TCP/IP Protocol Framework". Retrieved 8 February 2013. <a href="http://sourcedaddy.com/windows-xp/the-tcp-ip-protocol-framework.html" target="_blank">http://sourcedaddy.com/windows-xp/the-tcp-ip-protocol-framework.html</a> <a href="#fnref:1" class="footnote-back-ref">↩</a></p></li> <li id="fn:2"><p>"Data Link Layer". Retrieved 8 February 2013. <a href="http://web.cs.wpi.edu/~cs4514/b98/week3-dll/week3-dll.html" target="_blank">http://web.cs.wpi.edu/~cs4514/b98/week3-dll/week3-dll.html</a> <a href="#fnref:2" class="footnote-back-ref">↩</a></p></li> <li id="fn:3"><p>"CAM Table & STP Attacks" (PDF). Polytechnic Institute of New York University. Retrieved 8 February 2013. <a href="http://isis.poly.edu/courses/cs996-pent-test-f2004/Lectures/pre1.pdf" target="_blank">http://isis.poly.edu/courses/cs996-pent-test-f2004/Lectures/pre1.pdf</a> <a href="#fnref:3" class="footnote-back-ref">↩</a></p></li> <li id="fn:4"><p>O'Connor, Terrence. "Detecting and Responding to Data Link Layer Attacks". SANS Institute. Retrieved 8 February 2013. <a href="http://www.sans.org/reading_room/whitepapers/detection/detecting-responding-data-link-layer-attacks_33513" target="_blank">http://www.sans.org/reading_room/whitepapers/detection/detecting-responding-data-link-layer-attacks_33513</a> <a href="#fnref:4" class="footnote-back-ref">↩</a></p></li> <li id="fn:5"><p>Akeung, Darryl. "Switch Security – DHCP Starvation and Flooding CAM Tables (Fail Open) Part 1". Archived from the original on 2 February 2013. Retrieved 8 February 2013. <a href="https://web.archive.org/web/20130202040743/http://dakeung.com/2011/12/20/switch-security-dhcp-starvation-and-flooding-cam-tables-fail-open-part-1/" target="_blank">https://web.archive.org/web/20130202040743/http://dakeung.com/2011/12/20/switch-security-dhcp-starvation-and-flooding-cam-tables-fail-open-part-1/</a> <a href="#fnref:5" class="footnote-back-ref">↩</a></p></li> <li id="fn:6"><p>"Network Security at the Data Link Layer (Layer 2) of LAN". Javvin Network Management & Security. Archived from the original on 11 April 2013. Retrieved 14 February 2013. <a href="https://archive.today/20130411061206/http://www.javvin.com/networksecurity/NetworkSecurity.html" target="_blank">https://archive.today/20130411061206/http://www.javvin.com/networksecurity/NetworkSecurity.html</a> <a href="#fnref:6" class="footnote-back-ref">↩</a></p></li> <li id="fn:7"><p>O'Connor, Terrence. "Detecting and Responding to Data Link Layer Attacks". SANS Institute. Retrieved 8 February 2013. <a href="http://www.sans.org/reading_room/whitepapers/detection/detecting-responding-data-link-layer-attacks_33513" target="_blank">http://www.sans.org/reading_room/whitepapers/detection/detecting-responding-data-link-layer-attacks_33513</a> <a href="#fnref:7" class="footnote-back-ref">↩</a></p></li> <li id="fn:8"><p>Gmoskov. "ARP Spoofing Attack and Defense". Retrieved 14 February 2013. <a href="http://think-security.com/arp-spoofing-attack-and-defense/" target="_blank">http://think-security.com/arp-spoofing-attack-and-defense/</a> <a href="#fnref:8" class="footnote-back-ref">↩</a></p></li> <li id="fn:9"><p>Dmitry, Davletbaev. "Dhcpstarv - DHCP Starvation Utility". SourceForge.net. Retrieved 14 February 2013. <a href="http://dhcpstarv.sourceforge.net/" target="_blank">http://dhcpstarv.sourceforge.net/</a> <a href="#fnref:9" class="footnote-back-ref">↩</a></p></li> <li id="fn:10"><p>"Mitigating Layer 2 Attacks" (PDF). Retrieved 14 February 2013.[permanent dead link] <a href="http://icon.clnchina.com.cn/attachment/0/7/8/8870_Mitigating%20Layer%202%20Attacks.pdf" target="_blank">http://icon.clnchina.com.cn/attachment/0/7/8/8870_Mitigating%20Layer%202%20Attacks.pdf</a> <a href="#fnref:10" class="footnote-back-ref">↩</a></p></li> <li id="fn:11"><p>"NetEqualizer Lite and Hidden Nodes: A Real Solution to a Virtual Problem". NetEqualizer. Retrieved 14 February 2013. <a href="http://www.netequalizer.com/Hidden_Node_White_Paper.php" target="_blank">http://www.netequalizer.com/Hidden_Node_White_Paper.php</a> <a href="#fnref:11" class="footnote-back-ref">↩</a></p></li> <li id="fn:12"><p>"NetEqualizer Lite and Hidden Nodes: A Real Solution to a Virtual Problem". NetEqualizer. Retrieved 14 February 2013. <a href="http://www.netequalizer.com/Hidden_Node_White_Paper.php" target="_blank">http://www.netequalizer.com/Hidden_Node_White_Paper.php</a> <a href="#fnref:12" class="footnote-back-ref">↩</a></p></li> <li id="fn:13"><p>"Deauthentication". Aircrack-ng. Retrieved 14 February 2013. <a href="http://www.aircrack-ng.org/doku.php?id=deauthentication" target="_blank">http://www.aircrack-ng.org/doku.php?id=deauthentication</a> <a href="#fnref:13" class="footnote-back-ref">↩</a></p></li> <li id="fn:14"><p>Bellado, John. "Deauthentication Attack". Proceedings of the USENIX Security Symposium, Aug 2003. Archived from the original on 14 December 2017. Retrieved 14 February 2013. <a href="https://web.archive.org/web/20171214024338/http://www.sysnet.ucsd.edu/~bellardo/pubs/usenix-sec03-80211dos-html/node11.html" target="_blank">https://web.archive.org/web/20171214024338/http://www.sysnet.ucsd.edu/~bellardo/pubs/usenix-sec03-80211dos-html/node11.html</a> <a href="#fnref:14" class="footnote-back-ref">↩</a></p></li> </ol>