Author Archives: Ferry

In the process of setting up secure DNS (Domain Name System) for the ipv6security.nl domain, I found out that my workstation was not able to use this additional security feature. With secure DNS transactions (DNSSEC) you will benefit from the fact that no one can tamper the name-to-address translation (DNS), so you will connect to the correct system in stead of a fake or man-in-the-middle (MITM) system.

There are three parts to it, which should work together:

1. Authoritative DNS server, holding the RR-records for name to IP resolution or visa-versa
2. Resolver DNS server, resolving queries on behave of clients
3. Client resolver, querying the Resolver DNS for name to IP translation or visa-versa

Step 1. is currently work in progress, by which SIDN (Dutch Domain Registration Authority) did validate the ipv6security.nl domain and will include the DS RR-record in the nl. TLD soon.

Step 3. is part of modern Operating Systems and will probably work for you

Step 2. turned out to be an issue at my place, for which I had to make some changes to get it to work.

How to enable DNSSEC validation with BIND?

Note: the dnssec-validation option is only supported on BIND v9.4 or above, on v9.3 the dnssec-enable option covers validation as well.

You have to tell your DNS server to do DNSSEC validation checks, by enabling it in the named.conf configuration file. Put it in the “options” section.

options {
dnssec-validation yes;
};

BIND will now attempt DNSSEC validation, which relies on a chain-of-trust untill it reaches a trused authority. In my case this SEP (Secure Entry Point) was missing in my named.conf file.  Adding this trust-anchor can simply be done by obtaining the DNSKEY of the “.” domain with the dig command.

dig . DNSKEY

You will get two public keys called 256 (ZSK) and 257 (KSK), of which you have to add the section with 257 in the named.conf file. I have to mention that obtaining the “root” DNSKEY via dig is not 100% secure and checking it against another way of obtaining it should be considered.

trusted-keys {
"." 257 3 8 "AwEAAag........" ;
};

Restart BIND and you should have a DNSSEC validating enabled DNS server.

An excellent way to validate if DNSSEC validation is working properly, is to go to  SIDN DNSSEC validation page which should give you a green “You are protected” check mark as shown below.

How do I see that I had a secure DNS transaction?

An easy and simple why to indicate that you’re browsing on a website translated by DNSSEC, is by installing the FireFox DNSSEC Validator plug-in. You will get a collored key in the address bar, in front  of the URL.

As part of a secured presence on the internet, IPv6:Security::nl prepared DNSSEC for the ipv6security.nl domain. No waiting on SIDN to insert the DS RR-records in the nl. TLD-domain.

The advantages of #IPv6

IPv6 offers a significantly larger pool of addresses by using 128-bit addresses: 340 undecillion (3.4×1038), compared with the 4.3 billion available in 32-bit IPv4 addresses. This extended pool of addresses provides scalability, but also introduces additional security by making host scanning and identification more challenging for attackers. But IPv6 provides more than just new addresses — it also provides a range of benefits for security, integrity and performance.

Security benefits

IPv6 was built from the ground up to be capable of end-to-end encryption. While this technology was retrofitted into IPv4, it remains an optional extra and isn’t universally used. The encryption and integrity-checking used in current VPNs is a standard component in IPv6, available for all connections and supported by all compatible devices and systems. Widespread adoption of IPv6, when properly implemented, could therefore make man-in-the-middle (MITM) attacks significantly more difficult.

IPv6 also supports more-secure name resolution. The Secure Neighbor Discovery (SEND) protocol is capable of enabling cryptographic confirmation that a host is who it claims to be at connection time. This renders Address Resolution Protocol (ARP) poisoning and other naming-based attacks much more difficult. And while not a replacement for application- or service-layer verification, it still offers a greatly improved level of trust in connections. In an IPv4 network it’s fairly easy for an attacker to redirect traffic between two legitimate hosts, allowing him to manipulate the conversation or at least observe it. IPv6 makes this very hard. (Not all device and OS implementations of IPv6 have applied this feature yet.)

This added security depends entirely on proper design and implementation, and the more complex and flexible infrastructure of IPv6 makes for more work ensuring every “t” is crossed and every “i” dotted. Nevertheless, properly configured IPv6 networking will be significantly more secure than its predecessor.

Performance benefits

Data packets transferred under IPv4 are severely size-restricted, and those that are too big must be fragmented and reassembled. Routers and other intermediary devices along the transport path handle this fragmentation, but the work involved can be inefficient, time-consuming and ultimately costly. Under IPv6, the protocol design incorporates end-to-end fragmentation, simplifying and lightening the load of handling fragmented packets. With less work required to identify and properly split data, speed goes up and the workload along the transport path goes down.

IPv6 also does away with the need for integrity-checking of packets during transit, leaving this to higher-level protocols such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP), freeing up valuable router time that can be better spent pushing data around as fast as possible.

There are also notable benefits in IPv6 for mobile devices, which will be able to maintain the same address when moving from one connection to another — going from a 3G network to Wi-Fi provided by your local coffee shop, for example. Rather than picking up a new address from the new connection service, the mobile device can keep the same “home” address at all times. This removes the need for “triangular routing,” in which data sent to the mobile device must first go through the network of the mobile provider. These changes not only provide greater speed, simplicity and usability, but also make connections more resilient and secure. Given the prevalence of mobile devices today, this enhancement should be most welcome.

Thanks to improved identity checking, IPv6 avoids many of the performance and security issues surrounding Multicast and Anycast broadcasting, and offers better autoconfiguration, with ICMP6 messages used to determine an appropriate address and configuration. Upgraded DHCP6 is also available for those who require more stateful control of network connections, and of course conventional static address assignment is possible if needed. The combination of a wider address pool and a more sophisticated address structure solves a lot of address conflict issues, which arise most commonly when company mergers or takeovers lead to integration and readdressing of networks. Organization-specific prefixes are a core part of the IPv6 infrastructure, and ensure no collisions even when lower portions of address overlap. Changing addressing structures is also simpler and more efficient.

What are the problems with IPv6?

Several vulnerabilities in the IPv6 infrastructure have already come to light. One issue, which has been fixed since its discovery, concerns the Router Heading Type 0 (RH0) “feature,” which proved potentially useful in running DDOS attacks and forging host identities. It’s likely we’ll see more problems as adoption of IPv6 picks up and people spend more time and effort analyzing how to subvert its built-in security. Similar issues were and still are present in IPv4, and as new problems are uncovered, we’ll need new methods and tools to overcome them.

Proper deployment and configuration is also a serious issue. Because attempting to deploy IPv6 in the same way as IPv4 guarantees problems, IT administrators must learn a whole new approach to networking, from simple network troubleshooting to configuring firewalls and monitoring security logs. The new knowledge so administrators will need leave many opportunities for confusion and mistakes.

There’s no instant switch to change from IPv4 to IPv6, so partial adoption means using tunneling technologies to transport IPv6 over IPv4. This kind of workaround is another potential source of confusion, misconfiguration and security gaps.

So far the bad guys have paid little attention to IPv6, thanks mainly to its limited adoption, but already we’ve seen widespread malware with IPv6-based command-and-control capabilities. Given the relative lack of attention paid to IPv6, this technique can bypass existing protection completely. (Your server might enable IPv6 by default but your firewall might not.) As adoption picks up and more people look in to IPv6, we’ll inevitably see more flaws and ways of abusing the system for malicious ends.

What help can I expect from my security provider?

Security providers need to be on the ball regarding the IPv6 switchover. Many security products will require changes to handle new networking patterns, both as a transport medium for updates, lookups, and management and reporting systems and as a means to ensure continued provision of scanning and protection features.

Going forward, it’s inevitable that fundamental approaches to security will evolve as network practices change. We’ll see new vulnerabilities and threat vectors appear — and security providers must be ready to face them.

One of the clearest shifts in security practices will be toward the endpoint, as greater use of end-to-end encryption makes perimeter security difficult and inefficient. For example, network DLP technologies will struggle to inspect content as it is encrypted until it reaches the endpoint. Combined with users’ tendency to roam (their traffic not necessarily even routing through the corporate network), this forces a much more endpoint-centric approach to security. Corporate, academic and government networks will face such significant decisions as whether to implement Internet Protocol security across the board or to keep existing gateway-level filters and scanners, and whether to allow encryption to ensure data reaches the endpoint intact and unseen, or to disable it to allow internal checking, filtering and possible snooping. This is a deep and complex question, involving a potential conflict between security and privacy, but given the growing trend away from the perimeter for other reasons, all quality security providers must be moving toward enabling more complete security provision at the desktop level.

Security vendors will need to invest time and money to ensure proper and complete support for IPv6, and must stay alert for the new dangers IPv6’s adoption will bring.

So what do I need to do?

Migration to IPv6 is no longer a question of if, but when. Services like Google and Facebook are already available via IPv6. Several large ISPs, telecommunications and web service providers are now either running trials or actively migrating. Mobile operators are increasingly pushing for wider IPv6 implementation to support their high-speed networks. This means all businesses should consider their adoption plans, if they haven’t already. On June 8, 2011, World IPv6 Day will see major providers around the world running full public tests on IPv6. We should all watch the results carefully and start to build our own pragmatic plans.

You should think through the design and configuration of your adoption plans to ensure minimal disruption and maximum satisfaction. There are a number of key issues to bear in mind when planning and implementing the switch:

1. Be cautious when using tunneling during the initial overlap period. While tunnels can provide vital connectivity between IPv4 and IPv6 components, or enable partial IPv6 in parts of networks still based on IPv4, they can also introduce notable security risks. For example, tunnels can cut through your perimeter firewall rules, but might be less restricted than your firewall. This could allow attackers to connect to resources inside the “hard shell” of your network without your knowledge. Complexity is always a danger, so keep tunnels to a minimum and use them only where absolutely necessary. Carefully check the setup of “automatic tunneling” tools such as “6to4” and Teredo. Traffic tunneling will also make network security systems (e.g., IPS devices) much less likely to identify attacks.
2. Remember to look at the bigger picture. Network layout under IPv6 is very different from that under IPv4, so simply replicating your existing setup will not provide ideal results. You need to significantly redesign your network structures to get the best out of IPv6 (detailed guides are available from vendors such as Cisco and Microsoft). Plan for this at the outset, rather than running multiple migrations, to avoid problems with performance and security. Also, be sure to consider the architecture of both the Internet facing and LAN resources — don’t casually get rid of your DMZ!
3. Check that your entire networking infrastructure is compatible and up to date. It’s easy to miss switches and routers in patching regimes, and you may need to update these to the latest versions of firmware and software. Check that these devices are ready for IPv6; if they aren’t, have a plan to make them so over time. At first, IPv6 could introduce more risks at the protocol level (as we all learn about using it in a real environment), so make sure you pay close attention to patching. Many organizations do not include their network infrastructure in their patching plans, which can leave them open to very nasty attacks. This would be a good time to check your processes in this area.
4. Make sure all your security solutions are up to the job. More use of IPSec is a great idea and fully supported by IPv6, but the end-to-end encryption may interfere with some perimeter-level security processes. Protection may have to migrate closer to the desktop level, so ensure desktop security includes Data Loss Prevention (DLP) and web security. You may need to upgrade or reconfigure your firewalls as well. Check that your endpoint provider has the full range of controls you require to replace conventional perimeter controls.
5. Don’t enable IPv6 until you’re fully ready. Many platforms come with IPv6 enabled by default, but make sure it’s switched off until properly configured. Many current firewalls focus exclusively on IPv4 and will not filter IPv6 traffic at all — leaving systems completely exposed. Disable unnecessary services and check the ports and protocols used by the services you need. I’ve seen numerous customer systems running IPv6 by default, which could allow attackers to bypass their security controls and wreak havoc. You can find easy instructions online for enabling/disabling IPv6 on Linux, Mac and Windows.

By James Lyne, Director of Technology Strategy, Sophos

It turns out to be that the Cisco Router Advertisement Guard is not thoroughly implemented. This means it can be circumvented.

To bypass the Router Advertisement Guarding feature in the (very few)
Cisco switches (and images) that support it:

Attack:

Make the evil Router Advertisement fragmented and put the ICMPv6 into
the second fragment, eg. by putting a very large Destination extension
header before the ICMPv6 part.

So the packets look like:

Fragment 1:
IPv6 Header
Fragmentation Header
Destination Header (~1400 bytes)

Fragment 2:
IPv6 Header
Fragmentation Header
Destination Header (continued with some bytes)
ICMPv6 with RA

Workaround:

To prevent this attack, put the following IPv6 ACL on all ports:

deny ip any any undetermined-transport

This will drop all packets where the switch is not able to identify the
IPv6 transport type like in this attack. Note that this might drop some
unusual valid traffic too.

Workaround Bypass:

Craft the packets in a way so that the first fragment has an ICMPv6 echo
request and the second fragment overwrites the first fragment with the
ICMPv6 router advertisement.

Fragment 1:
IPv6 Header
Fragmentation Header
Destination Header (8 bytes)
ICMPv6 with Echo Request

Fragment 2:
IPv6 Header
Fragmentation Header with offset == 1 (equals position of 8th byte ==
start of Echo Request in first fragment)
ICMPv6 with RA

Note that the handling of overlapping fragments differs between
platforms, some take the first fragment received, others the latest, so
send the packets accordingly to your target.

Consumer marked prepares itself for #IPv6, having the most IPv6Ready approvals. When looking through the IPv6Ready phase-1/phase-2 approval list, it comes to my notice that not the network networking but the peripheral industry dominate the list.

You will find a lot of IPv6Ready approvals for Samsung, Panasonic, Dell, Minolta. On the networking site Zyxel, D-Link and Cisco are active participating.

Forbes publishing on IPv6, with a three step approach. A fourth step, gaining knowledge by training, is missing. Please at that to your preparation.

Step 1:
Inventory: Because IPv6 will affect every device and application on a network, the first step towards a successful migration is to conduct an inventory all of the devices that are currently connected to the network.

Step 2:
Research: After taking inventory, go to each vendor’s support pages for an IPv6 roadmap and timeframe for full compliancy. This research should reveal if the device requires a simple software update or a complete hardware refresh.

Step 3:
Budget: Once the type of upgrade is determined, the costs associated with updating to a newer device or firmware needs to be factored in. Understanding these IPv6 related costs makes it easier to integrate them within a normal IT refresh cycle.

You can find the article here.

If you are running an IPv6 based network with SLAAC, or want to keep an eye on your network to prevent running IPv6, the use of a Neighor Discovery monitor is advisable. Such a monitor will monitor your network segments for rogue RAs (Route Advertisements) which could enable auto configuration or reconfiguration of the IPv6 stack. These RAs are used to instruct the client devices to generate an IPv6 address, enable the IPv6 stack and start the communication over IPv6 whenever the DNS (Domain Name System) returns an IPv6 answer (AAAA resource record) for a host (FQDN).

A free neighbor discovery protocol monitor with logging, alerting and mitigation is available on Sourceforge as “NDPMon“.

Recently we see more attention for the SLAAC (StateLess Adress AutoConfiguration) attack, through intentional use of rogue RAs (Router Advertisements). This is a general threat to IPv6 capable devices, although there are article telling that it is a flaw in specific operating systems like Microsoft Windows, MacOS etc.

It is known for quite a while that we have to prepare for unintentional and/or intentional RAs on networks where IPv6 capable devices are connected. These RAs can disrupt (renumber) or influence (active IPv6 usage which has often presidents over IPv4) connected devices, and become a threat to users or organizations.

A longer term solution is the use of SEND (SEcure Neighbor Discovery), but equipment support for this “heavy weight” mitigation is falling short. Alternative light weight solutions are available, but you have to pick and chose the one(s) that suite you the best. For now you will find yourself searching if your current (network) equipment supports the features to protect against rogue RAs. When buying new equipment, it should be a selection criteria.

You can read about the “SLAAC man-in-the-middle-attack“ and the “RFC 6104“ outlining the options to prevent or monitor for SLAAC attacks, in these excellent documents.