![\"How](\"https:\/\/live-infoblox-blog.pantheonsite.io\/wp-content\/uploads\/How-Adobe-Systems-a-Silicon-Valley-Pioneer-Avoids-Downtime-and-Stays-Secure.jpg\")
<\/p>\n<\/p>\n
Virtually all organizations now have IPv6-capable systems running on their networks.\u00a0 All modern mobile and computer operating systems run both IPv4 and IPv6 by default.\u00a0 These operating systems try to facilitate access to the IPv6 Internet, if at all possible, and may create IPv6-in-IPv4 tunnels to reach IPv6 content.\u00a0 Some of these processes take place regardless of user input, configuration, or notification (See\u00a0RFC 7123<\/a>, Security Implications of IPv6 on IPv4 Networks). \u00a0This is what is commonly referred to as the \u201cIPv6 latent threat.\u201d\u00a0There is an active protocol in the environment that administrators are not aware of and have not yet taken any steps to secure.<\/p>\n This is something to be concerned about, but is something that can be secured.\u00a0 One approach to mitigating the latent threat issue is to proceed to deploy IPv6. This proactive step helps put you in control of the IPv6 security situation. There are other approaches to mitigate these IPv6 security issues. These approaches are implemented on the local LAN and traverse the network perimeter.<\/p>\n This blog post will focus on the issues and security measures used to protect the use of IPv6 on a local access network.\u00a0 Knowing the network devices that are local and within the neighbor cache (the IPv6 equivalent of the IPv4\u00a0ARP<\/a>\u00a0cache) helps you learn who is on your network and using IPv6.<\/p>\n The vast majority of organizations have not taken any steps to secure the IPv6-capable nodes in their environment.\u00a0 They are also unaware of how IPv6 operates on a LAN and how the protocol is different from the IPv4 protocol they have experience securing.\u00a0 IPv6 has some particular functional differences from IPv4 that may change your LAN threat-mitigation strategy.<\/p>\n We do not want organizations to be overly alarmed about these types of LAN-based IPv6 threats.\u00a0 For the most part, organizations do not implement any security measures to secure their IPv4\u00a0ARP<\/a>\u00a0or\u00a0DHCP<\/a>\u00a0traffic on their access networks. \u00a0Many of the same types of LAN-based attacks for IPv6 have similar or exactly the same vulnerabilities as IPv4 threats.\u00a0 If organizations have not implemented any IPv4 LAN protection measures, then they should not be\u00a0holding IPv6 Neighbor Discovery to a higher standard of security<\/a>.<\/p>\n It should also be mentioned that all of these IPv6 Neighbor Discovery Protocol (NDP<\/a>) attacks occur on the local physical\/virtual link.\u00a0 Therefore, the attacker must have physical access to the local network medium or have compromised and gained control of a system that is on the local network.\u00a0 The attackers\u2019 motivation is to stay hidden and cover up their tracks as well as preserve the access they have achieved.\u00a0 The attackers definitely do not want to alert any IT administrator that they have gained access to an internal computer.<\/p>\n Reconnaissance of IPv6-capable nodes on a local LAN is not practical when the attacker uses brute-force techniques trying to guess the IPv6 addresses used by local nodes.\u00a0 However, there are methods that a resourceful attacker can use to accelerate finding IPv6-capable local nodes.\u00a0 Some of these methods are stealthy and quiet, while others are noisy and leave traces that the attacker is there.\u00a0 An attacker can pivot to other unprotected IPv4 nodes and IPv6 nodes on the local LAN if the attacker already has access to the local link.<\/p>\n Attackers are gaining familiarity with IPv6, but most enterprise security teams are unaware of the protocol and how it works on a LAN.\u00a0 The IPv6 Neighbor Discovery Protocol (NDP<\/a>) (defined in\u00a0RFC 4861<\/a>) is the process that is used for IPv6 nodes on a LAN to facilitate communicating with each other.\u00a0 NDP uses Internet Control Message Protocol (ICMPv6<\/a>) and link-local multicast communications to perform functions similar to IPv4\u2019s Address Resolution Protocol (ARP<\/a>).\u00a0 There are a variety of LAN-based vulnerabilities that a locally-attached attacker can try to take advantage of.\u00a0 These are also documented in IETF RFC titled \u201cOperational Neighbor Discovery Problems\u201d (RFC 6583<\/a>).\u00a0\u00a0This Cisco document<\/a>\u00a0shows how these IPv6 FHS concerns can cause problems for end-nodes.<\/p>\n A link-local attacker could generate malicious ICMPv6 Neighbor Solicitation (NS) or Neighbor Advertisement (NA) messages to confuse node\u2019s neighbor cache.\u00a0 This could result in a DoS condition or facilitate the attacker performing a man-in-the-middle (MITM<\/a>) attack.<\/p>\n A local-connected attacker could also generate ICMPv6 redirect messages to change the direction of traffic from nodes on the local LAN.\u00a0 This could also result in a DoS or MITM situation.<\/p>\n The attack that should raise the most concern is one where an attacker crafts a rogue ICMPv6 Router Advertisement (RA) message and sends it out on a network that only runs IPv4.\u00a0 This RA message would cause all of the IPv6-capable devices on the local network to activate their IPv6 stacks, acquire an IPv6 address based on the information in the RA, and start to attempt to actively use IPv6.\u00a0\u00a0ICMPv6 RA messages are essential and are the first step<\/a>\u00a0in the address assignment phase (and provide the host with information about their local IPv6 default gateway).\u00a0 Spoofed RAs can renumber hosts, cause a DoS condition for a host, or launch a MITM attack.\u00a0 The problems related to Rogue RA messages are well-documented in the IETF RFC titled \u201cRogue IPv6 Router Advertisement Problem Statement\u201d (RFC 6104<\/a>).<\/p>\n When we start to formulate our defensive strategy for these types of IPv6 NDP attacks, the first problem to solve is our lack visibility into how IPv6 is currently used on the LAN.\u00a0 Many organizations do not know which devices are connected to their networks.\u00a0 Knowing which nodes are connected and having an \u201cinventory of authorized and unauthorized devices\u201d are the first steps in the SANS top 20 Critical Security Controls (CSC<\/a>). Common methods of determining what is on our networks involve asking the local IPv6-capable router for its IPv6 neighbor cache through either the CLI or with an SNMP GET to a specific MIB OID.\u00a0 Using something like Infoblox\u2019s\u00a0Switch Port Manager<\/a>\u00a0or\u00a0Network Insight<\/a>\u00a0may also provide visibility.\u00a0 Having an IP address management (IPAM<\/a>) system that is tied into our DHCP services also provides awareness of which IP addresses are in active use.<\/p>\n Organizations also lack capabilities to keep unwanted devices off their networks.\u00a0 Preventing unauthorized LAN access is typically an issue of physical security.\u00a0 Most organizations may only disable unused switch ports and connections in conference rooms and publicly-accessible spaces.\u00a0 Some organizations may use\u00a0port-security<\/a>\u00a0to limit the number of MAC addresses learned on an access port.\u00a0 Fewer organizations use\u00a0IEEE 802.1X<\/a>\u00a0or\u00a0IEEE 802.1AE<\/a>\u00a0(MACsec), Cisco Identity Services Engine (ISE<\/a>) with\u00a0TrustSec<\/a>.\u00a0 Most of the commercially-available network access ontrol (NAC<\/a>) network admission control (NAC<\/a>) systems do not work with IPv6 and do not pay attention to IPv6-connected devices.<\/p>\n There are several host-based monitoring solutions that can observe NS\/NA and RS\/RA messages and detect and prevent NDP attacks.\u00a0 These open source utilities include\u00a0NDPMon<\/a>,\u00a0Ramond<\/a>, Kame\u00a0rafixd<\/a>,\u00a06Guard<\/a>, and\u00a06MoN<\/a>.\u00a0 The constraint of these solutions is that one system on every LAN would need to be running these functions.\u00a0 That may not be scalable for an organization that has many access networks.<\/p>\n A better approach is to put this detection and protection into the access network devices.\u00a0 These IPv6 security measures could be implemented into the Ethernet access switch or wireless controller and protect all the down-stream end-nodes. \u00a0This detection within the access Ethernet switch is similar to how a switch performs\u00a0DHCP snooping<\/a>\u00a0and\u00a0IGMP snooping<\/a>\u00a0(identifying hosts interested in receiving multicast traffic) and\u00a0PIM snooping<\/a>\u00a0(finding the local PIM routers).<\/p>\n An Ethernet switch could be configured to use a\u00a0Port-based ACL<\/a>\u00a0(PACL) to prevent an access port from sending Router Advertisement (RA) messages to other link-local nodes and thus prevent an attacker from acting like a rogue DHCPv6 server.<\/p>\n An example of how this rogue RA detection and prevention can be performed within an Ethernet switch is documented in the IETF RFC titled \u201cIPv6 Router Advertisement (RA) Guard\u201d (RFC 6105<\/a>).\u00a0 Ethernet switches would be able to learn which local IPv6 router should be legitimately sending RA messages to the nodes on the network and detect and drop RA messages being sent from end-nodes.\u00a0 Ethernet switches could also detect if RA messages are being flooded too quickly (more than the standard 200 second interval) and throttle them back.<\/p>\n Other IPv6 FHS features perform snooping DHCPv6 traffic and gleaning which nodes on the network have been allocated which IPv6 addresses.\u00a0 The switch can also snoop IPv6 packets and determine if those nodes are sourcing traffic from their allocated IPv6 addresses.\u00a0 If the IPv6 packets are using IPv6 addresses other than those detected through the snooping process, then the end-node may be creating spoofed packets and they should be blocked.\u00a0 Other features involve the switch monitoring the destination address of packets and detecting multicast and other attack types.<\/p>\n Some vendors have implemented these IPv6 FHS features into their Ethernet switch software by default.\u00a0 Therefore, customers have the flexibility to turn on these features at their leisure for no additional cost.\u00a0 Even organizations that have not implemented IPv6 might be curious if any of this nefarious NDP traffic is taking place on their LANs.\u00a0 Some vendors have been aggressive about incorporating IPv6 security features into their switches, while other vendors have been slower to embrace IPv6 FHS features and implement them.\u00a0 As with other aspects of IPv6, it is important to ask your vendor about their IPv6 features and assess if they have feature parity between what they can do to secure IPv4 and what they can do to secure IPv6.<\/p>\n Modern Cisco switches have these\u00a0IPv6 FHS features<\/a>\u00a0available as part of the default IOS software. This\u00a0page<\/a>\u00a0has a breakdown of the IPv6 FHS features and which IOS software version and platform support these features. This site has additional\u00a0details about configuration<\/a>\u00a0of these IPv6 FHS features.<\/p>\n HP has several classes of their switches (HP K.15.07.0002 on the 5400, 8200, 3500 series) that have\u00a0IPv6 security capabilities<\/a>.\u00a0 H3C\u00a0A5800 switches<\/a>\u00a0with OS version 5.20, among other switches in their line have RA Guard.<\/p>\n Brocade switches (ICX 6430\/6450, FCX, ICX 6610\/6650, FSX 800\/1600, ICX 7450\/7750 Release 08.0.20a) have\u00a0RA Guard<\/a>\u00a0and provide examples of\u00a0how to configure it<\/a>.<\/p>\n However, there are many vendors that have no IPv6 security protection features within their Ethernet switches.\u00a0 Consumers should be aware if their network switches lack these features and prepare to obtain these capabilities to gain visibility into IPv6 activities on LANs, (and should definitely plan on doing so before they deploy IPv6).<\/p>\n","protected":false},"excerpt":{"rendered":" Virtually all organizations now have IPv6-capable systems running on their networks.\u00a0 All modern mobile and computer operating systems run both IPv4 and IPv6 by default.\u00a0 These operating systems try to facilitate access to the IPv6 Internet, if at all possible, and may create IPv6-in-IPv4 tunnels to reach IPv6 content.\u00a0 Some of these processes take place […]<\/p>\n","protected":false},"author":321,"featured_media":2785,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[51,38,15],"class_list":{"0":"post-3025","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-ipam","9":"tag-ipv6","10":"tag-security","11":"entry"},"acf":[],"yoast_head":"\nDon\u2019t Be Overly Alarmed<\/h2>\n
IPv6 NDP Threats<\/h2>\n
Methods for Securing NDP<\/h2>\n
Vendor Support for IPv6 FHS<\/h2>\n