Categories
Deploy360 Events Improving Technical Security IPv6

TODAY! Free “Security in an IPv6 World” Webinar at 1PM ET

Today’s the day! At 1300 EDT (1700 UTC) our Chris Grundemann is teaming up with USTelecom for a webinar. From the session abstract:

Security in an IPv6 World: Myth & Reality

Now that IPv6 is being actively deployed around the world, security is more and more a growing concern. Unfortunately, there are still a large number of myths that plague the IPv6 security world. Join The Internet Society and USTelecom for a comprehensive webcast that will look at some of the most common IPv6 security myths, and the reality behind them.

This largely follows our series of IPv6 Security Myths here on this site, and he’s given some version of this talk at conferences around the world. This is your chance to hear it for yourself without having to leave your desktop.

If you want to listen in and ask some questions, register now! It starts in about two hours from right now. We hope to see you online.

Categories
Deploy360 IPv6 To archive

Upcoming USTelecom Webinar on IPv6 Security Myths

ustelecom logoI’m very happy to announce that I’ll be giving a talk next week that doesn’t require me to get on a plane! On Thursday, 16 April at 1300 EDT I’ll be teaming up with USTelecom for a webinar:

Security in an IPv6 World: Myth & Reality

Now that IPv6 is being actively deployed around the world, security is more and more a growing concern. Unfortunately, there are still a large number of myths that plague the IPv6 security world. Join The Internet Society and USTelecom for a comprehensive webcast that will look at some of the most common IPv6 security myths, and the reality behind them.

This is a talk I’ve given at several conferences around the world. I did the original research for a talk I was asked to give at CaribNOG 5. Apparently the content struck a chord with many folks. It’s been so popular that I recently wrote up much of the material I cover as a series of blog posts. If you want a chance to listen in and ask some questions, register now!

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #10 – Deploying IPv6 is Too Risky

Security in an IPv6 WorldAfter a quick break to catch our breath (and read all those IPv6 Security Resources), it’s now time to look at our tenth and final IPv6 Security Myth. In many ways this myth is the most important myth to bust. Let’s take a look at why:

Myth: Deploying IPv6 Makes My Network Less Secure
Reality: Deploying IPv6 Now is the Best Way to Ensure Ongoing Network Security

I can hear you asking “But what about all those security challenges we identified in the other myths?” To really dig into this, let’s walk through the first 9 IPv6 Security Myths and see what turns up:

In Myth #1 we learned that IPv6 traffic often shows up on networks long before that network has deployed IPv6. Once you know that “Your Devices are Using IPv6” and “Your Users are Using IPv6” it’s easy to see that the best way to mitigate risk on your network is by turning on and protecting IPv6 now. You can’t protect against what you can’t see.

Myth #2 may have scared many of you, and it should have! Network security is all about mitigating risks. Knowing where the risks are hiding is the first step. Any good security expert must be a little paranoid, always seeking out potential sources of harm. We must also take a step back from these risks and look at the big picture though. When we do this, it is clear that Myth #2 provides a set of risks that must be considered. However a careful examination will show that none of them are serious enough to prevent the deployment of IPv6. The bottom line remains that securing an IPv6 host or IPv6 network does not happen automagically. It takes the same forethought and diligence required to secure any valuable asset. Hopefully the challenges outlined in Myth #2 give you a head start in that process.

Myth #3 showed us that deploying IPv6 allows the removal of NAT devices, which is a good thing as long as they are replaced by stateful firewalls. NAT is not a security feature and removing NAT from your network will NOT make it less secure. In fact, it may actually increase your overall security.

In Myth #4 we discovered that IPv6 networks are not, in fact, too big to scan. Of course, we also learned several ways to keep them much harder to scan than comparable IPv4 networks. In the end, the larger address space remains an advantage for IPv6.

Myth #5 showed us that while “privacy addresses” are not perfect, there are several options for maintaining user privacy in IPv6 networks. This is another area where attention should be paid but full-on paranoia is likely unwarranted.

Myth #6 introduced us to some existing IPv6 security tool-kits and repositories of IPv6 bugs and vulnerabilities. The great news here is that they are all publicly available. This means that you can use them to probe, test, and harden your own network before the bad guys get their chance!

In Myth #7 we examined many of the fundamental differences between IPv4 and IPv6 from a security perspective. As I’m sure you’ll agree, there is a need for training and awareness of these differences in order to maintain network security when deploying IPv6. What I think is just as clear is that none of these changes make IPv6 any less secure than legacy IPv4 networks.

Myth #8 is all about ensuring that you get what you pay for. The need to document, verify, and test network security gear is not new. You must treat IPv6 like you would any other new technology being deployed on your network. Ensure that all new equipment meets your specific needs, and remember to trust but verify when it comes to IPv6 support.

Finally, in Myth #9 we learned that we’re not alone! There are IPv6 security resources out there for us to reference and learn from. When it comes to network security, knowing the risks ahead of time may make it scarier, but it also makes it safer to deploy.

In summary, these nine IPv6 security myths have given us the tools and information we need to securely deploy IPv6. So what about today’s myth?

Myth: Deploying IPv6 is Too Risky
Reality: Deploying IPv6 Now Lowers Your Risk

The bottom line here is that the sooner you deploy IPv6, the more secure your network will be in the long run. From giving you visibility into the IPv6 that may already be on your network, to giving you time to find and mitigate IPv6 risks, to providing staff more time for training and experience; all indicators suggest that your best bet is to deploy IPv6 today.

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #9 – There Aren't Any IPv6 Security Resources

Security in an IPv6 WorldWe are approaching the end of this 10 part series on the most common IPv6 security myths. Now it’s time to turn our eyes away from security risks to focus a bit more on security resources. Today’s myth is actually one of the most harmful to those who hold it. If you believe that there is no good information out there, it’s nearly impossible to find that information. So let’s get down to it and dispel our 9th myth. We’ll start by looking at a few of the high level principles and then look at a selection of resources, which contain much more detail.

Myth: There are no IPv6 Security BCPs yet
Reality: There are!

Many security standards don’t discuss IPv6 specifically. However, any general guideline related to IP likely applies to both versions – many security policies are (and should be) higher level. We saw this in Myth’s #2 and #7 to some extent and it’s also evident below, as many of these security practices apply to both IPv6 and IPv4.

Here are a few of the key principles to keep your IPv6 network secure:

  • Perform IPv6 filtering at the perimeter
  • Use RFC2827 (BCP38) and RFC3704 (BCP84) ingress filtering throughout the network
  • Use manual tunnels (with IPsec whenever possible) instead of dynamic tunnels and deny packets for transition techniques not used
  • Use common access-network security measures (NAC/802.1X, disable unused switch ports, Ethernet port security, MACSec/TrustSec)
  • Strive to achieve equivalent protections for IPv6 as with IPv4
  • Continue to let vendors know what you expect in terms of IPv6 security features

Myth: There are no IPv6 Security Resources available
Reality: There are!

The BCPs above are really just the tip of the iceberg when it comes to all the things you need to know to securely deploy IPv6. For a deeper dive on how to actually execute on these high level policies you’ll want to do some more reading. Here are a couple of the best IPv6 security resources I’m aware of. Read them and you’re well on your way to being a true IPv6 security expert!

What are your favorite IPv6 security resources? Leave a comment!

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #8 – It Supports IPv6

Security in an IPv6 WorldMost of our IPv6 Security Myths are general notions, often passed on unwittingly between colleagues, friends, conference attendees, and others. Today’s myth is one that most often comes specifically from your vendors or suppliers. Whether it’s a hardware manufacturer, software developer, or Internet Service Provider (ISP), this myth is all about trust, but verify.

Myth: It Supports IPv6
Reality: It Probably Doesn’t

I am not saying that no products or services support IPv6. What I am saying is that a simple check-box in an RFx isn’t enough. If a sales person tells you “it supports IPv6” without any further details or collateral – you probably need to dig deeper.

Many products and services do in fact support IPv6 today. More companies add IPv6 support to their products every day. The catch, especially from a security standpoint, is what that word “support” really means. Sometimes “IPv6 support” means that a device can be configured with an IPv6 address. Sometimes it means the service passes IPv6 packets. Sometimes it just means the application won’t puke all over itself when deployed in an IPv6 enabled environment.

What you need “IPv6 support” to mean is full feature parity with your existing (likely IPv4) products and services. You also need that IPv6 support to provide the foundation for future changes and improvements as well, of course. What that means is that you must bust this myth yourself every time it pops up.

How can you avoid falling for the “it supports IPv6” myth? Start with detailed requirements. What is it that you need this product or service to do? RIPE-554, “Requirements for IPv6 in ICT Equipment” includes a section specific to “network security equipment” that I highly recommend as a starting place when crafting such a requirements list. Once you find a product or service that meets your needs on paper, lab testing and limited launches (pilot programs / first office installs) will help ensure that you aren’t bitten by this myth. Seeking independent verification is sometimes warranted as well, for an example check out this list of tested home routers published by the University of New Hampshire (UNH) InterOperability Lab (IOL).

The bottom line for this myth is simple: Treat IPv6 like you would any other new technology being deployed on your network. Ensure that all new equipment meets your specific needs, and remember to trust but verify when it comes to IPv6 support.

Have you already deployed IPv6? We’d love to hear about your experiences, publish your lessons learned, and promote your success story along with our other IPv6 resources – especially if they relate to IPv6 security directly! If not, what are you waiting for?!? Get started today.

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #7 – 96 More Bits, No Magic

Security in an IPv6 WorldThis week’s myth is interesting because if we weren’t talking security it wouldn’t be a myth. Say what?

The phrase “96 more bits, no magic” is basically a way of saying that IPv6 is just like IPv4, with longer addresses. From a pure routing and switching perspective, this is quite accurate. OSPF, IS-IS, and BGP all work pretty much the same, regardless of address family. Nothing about finding best paths and forwarding packets changes all that much from IPv4 to IPv6. For many experienced network engineers, instruction in IPv6 contains a lot of things that can be described to “work just like in/with IPv4.”

This likely explains why virtually every transit provider and backbone operator on the planet has already rolled out IPv6. If all you’re concerned about is moving data, the phrase is true: IPv6 is 96 more bits, no magic.

From a security perspective however, that view has some complications.

Myth: 96 More Bits, No Magic
Reality: IPv6 Address Format is Drastically new

Routing 128 bit addresses is really not much different from routing 32 bit addresses. There’s a source address, a destination address, and hopefully a path or more between them.

Things get more complicated when we start talking about securing the network though. In addition to IPv6 addresses being 96 bits longer, they are also represented in hexadecimal notation instead of decimal. They use colons as delimiters instead of periods. They also introduce zero compression, in addition to zero suppression, expanding the possible formats that an IPv6 address may be represented in.

So what? Well, a lot of network security involves either filtering or forensics, both of which are often heavily (or completely) reliant on identifying nodes by IP address. You can no longer grep logs for decimal numbers separated by periods to find all instances of IP addresses. Now you need to look for hex characters and colons – and don’t forget to think about those double colons! Scripts, filters, and other tools written with IPv4 addresses in mind must be updated to handle IPv6 addresses.

Myth: 96 More Bits, No Magic
Reality: Multiple Addresses on Each Node

To make matters even more complicated, IPv6 nodes (hosts) are pretty much assumed to always have multiple addresses. At the very least they should all have a link-local IP address and a Global Unicast Address (GUA / public IP address), likely in addition to a legacy IPv4 address. Many nodes will also have a Unique Local Address (ULA – somewhat similar to RFC1918 address space in IPv4), one or more constantly changing privacy addresses, and other GUAs as needed.

This means that the node you are searching for may have a different IP address in the logs than the one you are looking for. It means that you may need to filter multiple addresses to have the desired affect on a single node. It means a paradigm shift in how you think about IP addresses as they relate to securing your network.

Myth: 96 More Bits, No Magic
Reality: Syntax Changes

In addition to changing how we think about IP addresses in this new IPv6 enabled world, we must also deal with syntax changes on our gear.

One of the great things about deploying a new version of IP is that we can use the opportunity to fix mistakes made in the old version. This is as true at the software and hardware level as it is at the network and security levels. The downside of this is that improvements at many equipment manufactures mean new syntax for network operators and security experts alike.

Instead of just ping, we now must remember to ping6. Our old friend tracert requires that we add -6 when executing an IPv6 traceroute. The ‘show route’ command is now supplemented by ‘show ipv6 route’ on some routers. The list goes on and on, and is different for each platform or vendor.

These changes affect everyone. As we learned in Myth #1; ignorance is no protection, and no excuse. To keep your network secure today, you must learn the new syntax of IPv6.

Myth: Configure IPv6 Filters the Same as IPv4
Reality: DHCPv6 and Neighbor Discovery Introduce Nuance

This is a more specific version of the ‘no magic’ myth and again, it’s not far from the truth. From a policy perspective you really should treat IPv6 and IPv4 security the same. For example: If a particular activity, destination, or traffic type is blocked for IPv4 it should very likely be blocked for IPv6 as well. The nuts and bolts of doing this aren’t quite the same however.

We’ve already talked about how address format, multiple addresses, and syntax changes may affect your configurations and actions. In addition to these general considerations, firewall filters have a couple of additional things to remember.

One of the biggest things to keep in mind when creating IPv6 filters is that Neighbor Discovery (ND) uses ICMP. This of course means that default ‘deny all ICMP’ rule you are likely to be using in legacy IPv4 filters can’t be copied over directly. Another consideration that may not be obvious at first is that DHCPv6 messages use link-local addresses, which you may typically want to filter out (why would link-local traffic be transiting a router?).

Here is an example stateful firewall filter for a Mikrotik router:

Flags: X – disabled, I – invalid, D – dynamic
0 ;;; Not just ping – ND runs over icmp6.
chain=input action=accept protocol=icmpv6 in-interface=ether1-gateway
1 chain=input action=accept connection-state=established in-interface=ether1-gateway
2 ;;; related means stuff like FTP-DATA
chain=input action=accept connection-state=related in-interface=ether1-gateway
3 ;;; for DHCP6 advertisement (second packet, first server response)
chain=input action=accept protocol=udp src-address=fe80::/16 dst-address=fe80::/16
in-interface=ether1-gateway dst-port=546
4 ;;; ssh to this box for management (note non standard port)
chain=input action=accept protocol=tcp dst-address=[myaddr]/128 dst-port=2222
5 chain=input action=drop in-interface=ether1-gateway

As you can see, rule 0 is in place to allow ND to work and rule 3 allows the node to hear its own DHCPv6 reply. This is just an example but hopefully it illustrates the point: There are subtle differences between IPv4 and IPv6 that must be considered when securing modern networks.

That’s it for this week, but you don’t have wait for the next IPv6 security myth; get started with IPv6 today!

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #6 – IPv6 is Too New to be Attacked

Security in an IPv6 WorldHere we are, half-way through this list of the top 10 IPv6 security myths! Welcome to myth #6. Since IPv6 is just now being deployed at any real scale on true production networks, some may think that the attackers have yet to catch up. As we learned in Myth #2, IPv6 was actually designed starting 15-20 years ago. While it didn’t see widespread commercial adoption until the last several years, there has been plenty of time to develop at least a couple suites of test/attack tools.

Myth: IPv6 is too New to be Attacked
Reality: Tools are Already Available

The first toolkit I learned about is THC-IPv6 (THC stands for The Hackers Choice). Originally released in 2005, the current version 2.5 was published just this past summer (2014-06-02). THC-IPv6 is, according to it’s own website, “A complete tool set to attack the inherent protocol weaknesses of IPV6 and ICMP6, and includes an easy to use packet factory library.” This publicly available toolkit includes:

– parasite6: icmp neighbor solitication/advertisement spoofer, puts you as man-in-the-middle, same as ARP mitm (and parasite)
– alive6: an effective alive scanng, which will detect all systems listening to this address
– dnsdict6: parallized dns ipv6 dictionary bruteforcer
– fake_router6: announce yourself as a router on the network, with the highest priority
– redir6: redirect traffic to you intelligently (man-in-the-middle) with a clever icmp6 redirect spoofer
– toobig6: mtu decreaser with the same intelligence as redir6
– detect-new-ip6: detect new ip6 devices which join the network, you can run a script to automatically scan these systems etc.
– dos-new-ip6: detect new ip6 devices and tell them that their chosen IP collides on the network (DOS).
– trace6: very fast traceroute6 with supports ICMP6 echo request and TCP-SYN
– flood_router6: flood a target with random router advertisements
– flood_advertise6: flood a target with random neighbor advertisements
– exploit6: known ipv6 vulnerabilities to test against a target
– denial6: a collection of denial-of-service tests againsts a target
– fuzz_ip6: fuzzer for ipv6
– implementation6: performs various implementation checks on ipv6
– implementation6d: listen daemon for implementation6 to check behind a fw
– fake_mld6: announce yourself in a multicast group of your choice on the net
– fake_mld26: same but for MLDv2
– fake_mldrouter6: fake MLD router messages
– fake_mipv6: steal a mobile IP to yours if IPSEC is not needed for authentication
– fake_advertiser6: announce yourself on the network
– smurf6: local smurfer
– rsmurf6: remote smurfer, known to work only against linux at the moment
– sendpees6: a tool by willdamn(ad)gmail.com, which generates a neighbor solicitation requests with a lot of CGAs (crypto stuff 😉 to keep the CPU busy. nice.
– thcping6: sends a hand crafted ping6 packet
[and about 30 more tools for you to discover!]

That’s fairly comprehensive from what I can tell!

The other IPv6 toolkit I am currently aware of is from SI6 Networks: “The SI6 Networks’ IPv6 toolkit is a set of IPv6 security assessment and trouble-shooting tools. It can be leveraged to perform security assessments of IPv6 networks, assess the resiliency of IPv6 devices by performing real-world attacks against them, and to trouble-shoot IPv6 networking problems. The tools comprising the toolkit range from packet-crafting tools to send arbitrary Neighbor Discovery packets to the most comprehensive IPv6 network scanning tool out there (our scan6 tool).” This toolkit includes:

addr6: An IPv6 address analysis and manipulation tool.
flow6: A tool to perform a security asseessment of the IPv6 Flow Label.
frag6: A tool to perform IPv6 fragmentation-based attacks and to perform a security assessment of a number of fragmentation-related aspects.
icmp6: A tool to perform attacks based on ICMPv6 error messages.
jumbo6: A tool to assess potential flaws in the handling of IPv6 Jumbograms.
na6: A tool to send arbitrary Neighbor Advertisement messages.
ni6: A tool to send arbitrary ICMPv6 Node Information messages, and assess possible flaws in the processing of such packets.
ns6: A tool to send arbitrary Neighbor Solicitation messages.
ra6: A tool to send arbitrary Router Advertisement messages.
rd6: A tool to send arbitrary ICMPv6 Redirect messages.
rs6: A tool to send arbitrary Router Solicitation messages.
scan6: An IPv6 address scanning tool.
tcp6: A tool to send arbitrary TCP segments and perform a variety of TCP-based attacks.

What should be clear now is that IPv6 is not safe from attack based on a lack of tools. The understanding and “equipment” necessary is readily available to any potentially nefarious folks. Luckily these tools are also available to you and your security team, to test and harden your own network before the attackers show up!

Another aspect of a device, technology, or protocol being too new to attack is knowledge of bugs and vulnerabilities. Having tools to probe for deployment weaknesses is great but if you can jump right to a software bug all the better, right?

Myth: IPv6 is too New to be Attacked
Reality: Bugs and Vulnerabilities are Published

The fact is that folks are paying attention to IPv6, now more than ever. This means that you can’t rely on any type of security through obscurity. Hardware and software bugs and other vulnerabilities are well known and widely published.

One of my favorite sites to keep track of such bugs and vulnerabilities is securityfocus.com. An easy way to pull a list of IPv6 specific vulnerabilities is to search for: “securityfocus.com inurl:bid ipv6”

The bottom line is that while IPv6 may be new to you or your organization, it’s not new to those who may want to attack your network. They have the tools and knowledge they need, so be sure that you do as well. I sincerely hope that this series of posts on IPv6 security is your first step in acquiring that knowledge – be sure to check out all the posts so far, and stay tuned for the next 4 installments!

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #5 – Privacy Addresses Fix Everything!

Security in an IPv6 WorldInternet Protocol addresses fill two unique roles. They are both identifiers and locators. They both tell us which interface is which (identity) and tell us how to find that interface (location), through routing. In the last myth, about network scanning, we focused mainly on threats to IPv6 addresses as locators. That is, how to locate IPv6 nodes for exploitation. Today’s myth also deals with IPv6 addresses as identifiers.

As we learned in the last myth:

Traditionally SLAAC uses modified EUI-64 format interface identifiers, which basically takes the interface’s MAC address and stuffs the hexadecimal word “0xfffe” in between the OUI (Organizationally Unique Identifier) and the second half of the MAC address, plus setting the “Universal” bit to 1. For example, the MAC address 00.00.5E.00.53.01 would become the IID (Interface Identifier) 0200:5EFF:FE00:5301.

This mapping of IEEE link-layer (MAC) addresses into IPv6 addresses has significant privacy implications when you consider the identification role of those addresses. When my interface identifier (the second 64 bits of my IPv6 address) is built deterministically from my MAC address, it doesn’t change (unless I change my network interface hardware, another issue that can be problematic for network administrators). An unchanging interface identifier can be used to track my device and it’s Internet activity. Even as it moves from network to network the prefix changes but the IID does not and my identity is revealed.

In response to this privacy threat, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” were developed and are now published in RFC 4941. Ultimately the idea documented here is to generate “privacy addresses” (also known as “temporary addresses”) that change over time. Unpredictable and short-lived, these addresses are meant to combat the threat of your devices being identified and tracked as you use the Internet.

Myth: Privacy Addresses Fix Everything!
Reality: It’s Complicated

The first thing to note about privacy addresses is that they are created in addition to, not in place of, your “regular” SLAAC address. This means that for the purposes of scanning and locating hosts, privacy addresses are of little help.

Another issue that should be considered with regard to privacy addresses is their short-lived nature and its affect on troubleshooting and forensics. It is very hard for network administrators to manage a network full of devices constantly changing their source addresses. Setting up filters, looking back at logs, and many other regular tasks become much more difficult when you can’t predict what address a node will be using, nor guess which address it was using.

The obvious solution to both of these challenges is to use a single, stable address that is not based on the interface’s MAC address. Replacing the EUI-64 based SLAAC address with a randomized one does reduce the ability for an attacker to target OUI patterns or other heuristics. Making the address stable (across reboots and network moves) makes filtering, troubleshooting, and forensics much more possible than with truly temporary addresses. Unfortunately, an unchanging address does not address the privacy concerns that prompted the creation of privacy addresses in the first place – unchanging IIDs can be used to identify and track a given device.

A more recent solution to this is being called “Semantically Opaque Interface Identifiers” and a method for generating them is documented in RFC 7217:

This document specifies a method to generate Interface Identifiers that are stable for each network interface within each subnet, but that change as a host moves from one network to another. Thus, this method enables keeping the “stability” properties of the Interface Identifiers specified in [RFC4291], while still mitigating address-scanning attacks and preventing correlation of the activities of a host as it moves from one network to another.

Not bad! I do note that on-network correlation is still possible, since the addresses only change when moving from one network to another. But that is of course what makes the address easier to manage from a network administrator point of view. It should also be noted that a device could use privacy addresses for outbound communication and opaque addresses for inbound communication, possibly frustrating network admins but improving privacy.

The alternative to all of this would be to use properly configured DHCPv6 instead of SLAAC on your networks. Just be sure to take into account all the risks of scanning mentioned in the last myth, and consider using privacy/temporary addresses with your DHCP implementation for user privacy.

Still confused? This is a tricky topic that is currently in flux a bit. If you want more information or have some clarifying questions, please don’t hesitate to look at our IPv6 security resources or to contact us directly!

Final note: I want to also point out that I intentionally left Cryptographically Generated Addresses (CGA) out of this conversation. I made this choice to simplify the topic in light of the extremely low adoption rate of SEND (Secure Neighbor Discovery) at this time.

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #4 – IPv6 Networks are Too Big to Scan

Security in an IPv6 WorldHere we are, all the way up to Myth #4! That makes this the 4th installment of our 10 part series on the top IPv6 Security Myths.

This myth is one of my favorite myths to bust when speaking with folks around the world. The reason for that is how many otherwise well-informed and highly experienced engineers, and others, hold this myth as truth.

It’s understandable, really. In IPv4 the largest subnet you’re likely to encounter on any given LAN is a /24, which allows for up to 256 host addresses. Scanning 256 addresses for responsive devices and open ports is downright trivial – and most subnets are even smaller than that! In the brave new world of IPv6, the standard minimum subnet size for any LAN is a /64. An IPv6 /64 allows for up to 18,446,744,073,709,551,616 (about 18.4 Quintillion) host addresses. To frame this a bit better, my friend and colleague Jan Zorz is fond of asking: “How many hosts can you fit in one /64?” The answer, of course, is “all of them.” Now you can see where the myth comes from: Using traditional techniques, it is impossible to scan that many addresses in a single human lifetime. If you could scan one million addresses every second, it would take about 584,555 years to scan just one /64!

Myth: IPv6 Networks are too Big to Scan
Reality: Many Addressing Techniques Reduce the Search Space

Fortunately for attackers, IPv6 nodes tend to clump up in certain IPv6 address ranges. In other words, scanning IPv6 networks is not impossible because there are shortcuts available that allow attackers to find devices without scanning all the addresses. Let’s take a look at some of these, and how you can help prevent making it so easy for the bad guys.

There are generally three ways to configure the IPv6 address for a given node/interface (SLAAC, DHCP, manual) and all of them are wrong. OK, not quite, but they can all be done wrong, in ways that will expose your network to address and port scanning attacks.

SLAAC (StateLess Address AutoConfiguration)

Traditionally SLAAC uses modified EUI-64 format interface identifiers, which basically takes the interface’s MAC address and stuffs the hexadecimal word “0xfffe” in between the OUI (Organizationally Unique Identifier) and the second half of the MAC address, plus setting the “Universal” bit to 1. For example, the MAC address 00.00.5E.00.53.01 would become the IID (Interface Identifier) 0200:5EFF:FE00:5301.

The main problem here is twofold. One, every SLAAC address created in this way includes 0xfffe as bytes 4 and 5 of the IID, signaling the address type and simultaneously reducing the search space (the number of numbers to scan). Two, OUIs are well known and so attackers can further reduce the search space by focusing on existing OUIs, OUIs for specific device types, etc.

Making matters worse, virtual machines and groups of devices bought all together may have sequential (or other distinguishably patterned) MAC address numbering. This can further reduce the search space or even, in some cases, mean that finding one responsive address could lead easily to finding the others (by searching sequentially up and down from the “hit”).

The best solution to this challenge is to use “Semantically Opaque Interface Identifiers” as described in RFC 7217. Luckily, work is underway to make that the default method for generating the IPv6 addresses assigned by SLAAC. Until then, think carefully about the risks of embedding hardware addresses in your IIDs before deploying SLAAC, and perhaps look for implementations that already use the RFC 7212 scheme.

DHCPv6 (Dynamic Host Configuration Protocol version 6)

Many network administrators looking for greater accountability and control over their dynamically configured network turn, quite rightly, to DHCPv6. This can be problematic from an address scanning point of view because many DHCPv6 servers assign addresses to clients sequentially (e.g. ::100, ::101, etc.). As you can probably guess, this significantly reduces the search space. All an attacker has to do is scan the lowest IIDs of any network to find all of your network’s nodes.

You can mitigate this risk by starting your addressing pools with a numerically high address (i.e. not ::10) and, even more importantly, by randomizing the sequence and sparseness of assigned addresses. As stated in RFC 5157:

Further, it is desirable that allocated addresses are not sequential and do not have any predictable pattern to them. Unpredictable sparseness in the allocated addresses is a desirable property.

Manually configured addresses

Manually configured interface addresses are often plagued by the same problems that DHCPv6 assigned addresses are but worse. Namely low numerical value and sequential numbering. Hoe many times have you configured a point to point link that ended in ::1 and ::2 (or 0 and 1, etc.)? Probably more than once.

Low-byte sequential addresses aren’t the only risk here though. Many of us have found clever ways to use the new hexadecimal address space. Unfortunately, many of these can actually make it easier for attackers to scan our networks. Embedding the IPv4 address, the TCP/UDP port number, or human readable words (e.g. ::dead:beef) into the IID all make those addresses easer to find.

Additional Threats

Regardless of your chosen address configuration method, there are some additional risks to keep in mind when considering the validity of this myth.

With any address scanning technique or methodology, the attacker must know which network to scan, right? Part of this is unavoidable, you have to announce your IPv6 address space out via BGP, put a listing in WHOIS, etc. But you can make it harder (or easier) for attackers to find individual /64s within your aggregate IPv6 space. Just like with individual interface identifiers, it’s likely a bad idea to build obvious patterns into your subnet identifiers. Some examples are numbering sequentially or embedding addresses/VLANs/IPv4 subnets/etc. Just like with IIDs, I have to recommend against using these visible patterns in your network addresses.

Many tunneling techniques such as 6to4, ISATAP, and Teredo use well-known addresses or algorithms for addressing that make devices using these technologies potential targets for network scanning. Worse is that some of these transition/co-existence mechanisms are active by default on some devices. Keep an eye out!

There are also ways around network scanning all together in some cases. Watch out for application-layer protocols leaking out IPv6 addresses (e.g. email). Remember that if one local node is compromised, neighbor discovery, link-local multicast addresses, and node information queries can all make short work of discovering and documenting the entire local network, and beyond.

Finally, don’t forget that anything published in the DNS (including reverse mappings) is potentially open to public probing!

I highly recommend that folks interested in this topic take a look at draft-ietf-opsec-ipv6-host-scanning, which treats this subject in much more detail. As always, there are also many additional IPv6 resources including some security specific resources available from Deploy360.

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #3 – No IPv6 NAT Means Less Security

Security in an IPv6 WorldWe’re back again with part 3 in this 10 part series that seeks to bust 10 of the most common IPv6 security myths. Today’s myth is a doozy. This is the only myth on our list that I have seen folks raise their voices over. For whatever reason, Network Address Translation (NAT) seems to be a polarizing force in the networking world. It also plays a role in differentiating IPv4 from IPv6.

In IPv4, NAT (technically NAT overload or NAPT) is required for multiplexing due to the shortage of addresses. In IPv6 we have 340 trillion, trillion, trillion addresses available, and therefore no need for address sharing. This means that the NAT we have in IPv4 is not part of our IPv6 world. Some people keep saying this is a security issue, which brings us to today’s myth.

Myth: No IPv6 NAT Means Less Security
Reality: Stateful Firewalls Provide Security (Not NAT)

We can argue the merits of NAT, the end-to-end principle, and security until we’re blue in the face – and many have – but the reality is that NAT does not provide any real network security. Worse yet, it actually prevents many security measures and provides an additional attack surface for your network.

The cause for much of this confusion stems from the fact that NAT requires state. By “state” I mean that the NAT device must remember which internal addresses to swap for which external addresses, and vice verse. This in turn means that any device performing NAT overload must act as a stateful firewall.

A stateful firewall uses state to determine which packets to allow into the network. That is, it remembers when you send packets out and to whom so that it can allow packets back in only from those hosts with which you initiated communication. In other words, a stateful firewall stops all incoming traffic unless it is a reply to valid traffic that you sent.

While the NAT may provide a bit of obfuscation, by hiding your internal addresses, it is really this stateful firewall function that protects your network from unwanted intrusion.

What’s worse than giving NAT credit for the work of our trusty stateful firewall? NAT making you less secure. That obfuscation trait of NAT we mentioned earlier actually prevents IPsec, DNSSEC, Geolocation, and other applications – many of which are designed to provide security – from working.

NAT also introduces its own set of security flaws. NAT devices stand in front of your network as a single point of failure. All NAT’ed packets must terminate on the NAT device and get a new IP header with their new, translated, address. This means that every flow into and out of a NAT’ed network is wholly dependant on the NAT device, and consumes resources on the NAT device. This opens these devises up to many DoS attacks. An attacker can consume available connection state, available addresses or ports, or simply overload the CPU with ALG (Application Layer Gateway) or other requests.

The bottom line is that NAT is not a security feature and removing NAT from your network will NOT make it less secure. In fact, it may actually increase your overall security.

Can’t wait for the next IPv6 Security Myths post? Not to worry, you can check out tons of great IPv6 resources right now!


Read the full series of IPv6 Security Myths articles and visit our Start Here page to get started with IPv6 today!

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #2 – IPv6 Has Security Designed In

Security in an IPv6 WorldToday we continue with part 2 of the 10 part series on IPv6 Security Myths by debunking one of the myths I overhear people propagating out loud far too much: That you don’t need to worry about security because IPv6 has it built into the protocol. In this post, we’ll explore several of the reasons that this is in fact a myth and look at some harsh realities surrounding IPv6 security.

Myth: IPv6 Has Security Designed In
Reality: IPv6 was Designed 15-20 Years Ago

The IPv6 protocol was primarily developed in the late 1990’s. In fact, RFC 2460, the “Internet Protocol, Version 6 (IPv6) Specification” is dated December 1998. This was a time when the commercial Internet had just started to flourish; security threats at this time were not anywhere near the sophistication and scale of threats common today.

While updates have been made to the protocol since 1998, the bottom line remains that relying on developers working well over a decade ago to protect you from security threats today and into the future is simply irresponsible.

This is the point where someone invariably points out that IPv6 requires IPsec (Internet Protocol Security), but…

Myth: IPv6 Has Security Designed In
Reality: IPsec is Not New

IPsec, which provides end-to-end per-packet IP layer authentication and encryption, has worked with both IPv6 and IPv4 since it was first standardized in RFC2401. This means that IPsec exists for IPv4 and that deploying it in IPv6 brings feature parity, not necessarily an enhancement.

The fact that IPv6 requires IPsec does mean that it’s available for use on all IPv6 capable devices, which is a step up over IPv4. It does not, however, guarantee the use of IPsec, which is what actually provides security. The responsibility remains with the application developer, the systems administrator, and the end user to actively apply IPsec for authentication and encryption.

[Correction 26 January: IPv6 no longer requires IPsec. Section 11 of RFC 6434, which obsoletes RFC 4292 on IPv6 Node Requirements, now states that IPsec SHOULD be supported (vs. the previous MUST). When I speak on this topic I usually point out that IPsec was required when many devices and applications with existing IPv6 support implemented it and that new implementations are still recommended to include IPsec support. These two facts combine to mean that although IPsec is no longer strictly required in every IPv6 node, it is still generally available pretty much everywhere it would be useful. The fact remains:]

You must actively use IPsec for it to provide any security whatsoever.

Myth: IPv6 Has Security Designed In
Reality: Extension Headers are Designed In

In order to make IPv6 as simple and interoperable as possible, it uses a minimalist standard packet header. In order to make IPv6 as extensible as possible, it allows “extension headers,” additional chunks of meta-data that can be strung behind the IP header to provide additional features and functionality. IPsec leverages the extension header mechanism to carry necessary authentication and encryption data, for one example.

Unfortunately, having extension headers designed into the protocol for extensibility also means having security flaws designed in along with them.

Myth: IPv6 Has Security Designed In
Reality: Source Routing was Designed In

The first example of this is Routing Header Type 0 (RH0), which is an extension header that facilitates source routing. That is, allowing the sender to determine the path the packet takes across the network, rather than allowing the routers to route the packet naturally.

This functionality can be abused. For example you could potentially “program” a packet, or a string of packets, to “bounce” back and forth between two routers – potentially exhausting the available bandwidth on that link. Luckily, this threat was identified and RH0 was deprecated in RFC 5095:

The functionality provided by IPv6’s Type 0 Routing Header can be exploited in order to achieve traffic amplification over a remote path for the purposes of generating denial-of-service traffic.

Although RH0 has been deprecated, there is always a chance of older or unpatched networking gear being affected by a source routing attack using RH0. Therefor, you should always discard packets using RH0, and any other extension headers that may be deprecated in the future as well.

Myth: IPv6 Has Security Designed In
Reality: The Hop-by-Hop Option Header is Designed In

Another potentially problematic extension header is the Hop-by-Hop option header. As the name implies, this header is intended to provide options at every hop along the packet’s path. In other words, every IPv6 node that inspects, routes, or otherwise looks at the IP header must process the Hop-by-Hop option header. Most interestingly, perhaps, is that the Hop-by-Hop option header is generic and is designed to be filled with sub options, or TLVs (Type-Length-Values). These TLVs are unrestricted and unlimited, meaning you can stuff virtually any amount of virtually any data into the Hop-by-Hop option header.

In sum, this means that the Hop-by-Hop option header can be used to pull off an effective low-bandwidth Denial of Service (DoS) attack. The threat is detailed in an expired IETF Internet Draft, “The case against Hop-by-Hop options:”

The denial of service attack can be carried out by forming an IP datagram with a large number of TLV encoded options with random option type identifiers in the hop-by-hop options header.

This extension header has not been deprecated and may have valid uses on your network, so each network will need to deliberately decide how to mitigate this threat. Two popular options are discarding packets with the Hop-by-Hop header and rate-limiting packets with the Hop-by-Hop header, particularly when router CPE usage is high.

Myth: IPv6 Has Security Designed In
Reality: Extension Headers are Vulnerable in General

Beyond the two specific extension header types detailed above, there are vulnerabilities that come with using extension headers at all. Stuffing tons of bits into an unnaturally large header, adding multitudes of individual headers to a single packet, and using invalid extension headers are all methods of attack.

Because extension headers are part of the IP packet, they must be identified and dealt with by at least some of the nodes on any IPv6 path. This means that IPv6 routers, firewalls, and other networking devices can have their CPU and memory resources exhausted dealing with malicious extension headers.

Myth: IPv6 Has Security Designed In
Reality: Neighbor Discovery is Vulnerable to LAN Attacks

Another one of the major enhancements to IPv6 (beyond address length and header structure) is Neighbor Discovery (ND). ND basically replaces the smattering of ICMP and ARP used by IPv4 with a more comprehensive, unified approach.

Unfortunately, as you may have guessed, there are some potential vulnerabilities in ND. Due to its trusting, on-net focus, attackers who gain access to a victim’s Local Area Network (LAN) can use ND to attack other hosts on that LAN. Forged ND messages can be used to glean information about other hosts, re-direct traffic, renumber other hosts, and even intercept traffic or launch a man in the middle attack. ND can also be exploited

Rogue Router Advertisements (RAs) have the potential to be particularly problematic. That threat is detailed in RFC 6104:

However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network. In this document, we summarise the scenarios in which rogue RAs may be observed and present a list of possible solutions to the problem.

Your primary defense against most ND based attacks is preventing unauthorized LAN access (and misconfigurations) in the first place.

Myth: IPv6 Has Security Designed In
Reality: Neighbor Discovery is Vulnerable

There is another NDP attack that does not necessarily require LAN access (although it makes it much easier). Just like ARP tables in IPv4, IPv6 routers and switches must keep track of LAN hosts. This is all done with NDP in IPv6. The problem arises from the fact that IPv6 networks have many, many more addresses than many switches and routers have NDP entries, so firing off packets with random source and/or destination addresses can trivially flood many devices’ neighbor cache. This results in a form of DoS on the network under attack.

Because Secure Neighbor Discovery (SeND) is not widely implemented, possible mitigations include using devices that are not vulnerable, blocking the source of the malicious traffic, using subnets smaller than a /64 (this has it’s own complications currently), and/or using static NDP entries. Beyond that, we need to demand more NDP configuration knobs from our vendors, to provide more granular control (logging, limiting, policing).

Myth: IPv6 Has Security Designed In
Reality: Many Attacks have Nothing To Do with IP

Finally, with all of that said, it is crucial to remember that buffer overflows, database injections, cross-site scripting, phishing, SPAM, DNS amplification, and many more of the most common attacks happen at layers above, or below, the IP layer. In other words, many attacks are completely unaffected by which version of IP you are using.

The bottom line is that securing an IPv6 host or IPv6 network does not happen automagically. It takes the same forethought and diligence required to secure any valuable asset. We’d like to give you a head start in that process with our IPv6 security resources, part of the Deploy360 portal.


Read the full series of IPv6 Security Myths articles and visit our Start Here page to get started with IPv6 today!

Categories
Deploy360 Improving Technical Security IPv6

IPv6 Security Myth #1 – I’m Not Running IPv6 so I Don’t Have to Worry

Security in an IPv6 WorldNow that IPv6 is being actively deployed around the world, security is more and more a growing concern. Unfortunately, there are still a large number of myths that plague the IPv6 security world. These are things that people state as fact but simply aren’t true.

While traveling the world, talking to the people who’ve already deployed IPv6, I’ve identified what I believe are the ten most common IPv6 security myths. This is the first post in a ten (10) part series that will debunk them each in turn and provide a quick introduction to IPv6 security along the way. Ten parts!?! Don’t worry! That’s how we keep each one short and to the point! =)

Myth: I’m Not Running IPv6 so I Don’t Have to Worry
Reality: Your Devices are Using IPv6

Systems running Linux, BSD, Mac OS X, and newer versions of Microsoft Windows, iOS, and Android all come with IPv6 support built in. Often, IPv6 is enabled by default. In many cases IPv6 is preferred over IPv4. Meaning that communication is always attempted on IPv6 first and then the device falls back to IPv4 only if IPv6 communication fails.

This means that even in a network where no one has intentionally deployed IPv6, it is quite likely that devices are sending IPv6 packets and have IPv6 sockets open. This, in turn, means that a potentially major security flaw exists on all of those devices. Someone, maybe you, has probably spent time installing, deploying, and tuning firewalls on your network. If they are all focused on IPv4 only, you’ve just allowed a major back door to exist within your network!

The fact is that devices on your network are most likely already using IPv6 and need to be protected, now.

Myth: I’m Not Running IPv6 so I Don’t Have to Worry
Reality: Your Users are Using IPv6

In addition to having IPv6 support enabled by default, several major operating system versions also include support for IPv6 “auto-tunneling.” The most common automatic (also called dynamic) tunneling mechanisms are 6in4 and Teredo. In both cases the device automatically creates an IPv6-in-IPv4 tunnel across the IPv4 network. The intention was virtuous: Allowing IPv6 communication between IPv6 capable nodes over a legacy IPv4-only network. The practical result is often more nefarious: Allowing IPv6 communication to pass through IPv4 firewalls, even when that communication violates your policy!

Note: While 6in4 and Toredo are the most common automatic tunneling mechanisms, many other tunneling protocols can also allow users or attackers to bypass your network security. 6in4, 6to4, 6in6, ISATAP, Toredo, 6rd, and DS-Lite all need to be taken into consideration.

A final consideration with regard to the “I’m Not Running IPv6 so I Don’t Have to Worry“ myth is mobility. When your devices and your users are out on the road, away from the office, what networks are they connecting to? The fact is that it’s very likely they will, at some point, connect to a dual-stack (IPv4 and IPv6) network. In fact, several major wireless operators are now deploying IPv6-centric LTE networks, which means that any smart phone on one of those networks will use IPv6. Now you potentially have a device you thought was protected using an unsecured protocol to communicate on an unknown network…

Of course, the best way to prevent all of this is to intentionally deploy IPv6, and conduct a full security audit as part of the process. It’s no myth that turning on and protecting IPv6 now could save you lots of heartache later.

P.S. Want to get started with IPv6? Please visit our Start Here page to begin – and also check out our IPv6 security page.