End of internship

This will be my last blog post in this particular blog (for now at least) since my internship ends today. It has been a great 13 weeks of working here with a lot of learning experiences, not only about IPv6 security but also about IT security in general. As I never looked from the vantage point of security before, I can now say with confidence, that this internship had a huge impact on me on that regard & I even want to persue a career in IT security now should I get the chance!

First of all I would like to thank my mentors at the internship, Dieter Vandenbroeck & Roel Vansteenberghe, for giving me the opportunity of doing my internship here.

I would also like to thank the 2 other interns for their support, so Yannick Stevens & Jan "Mr. BigShot" Weyens thanks for the support and good luck at working at EY!

Last but certainly not least I would like to thank all the other colleagues for their help, certainly in the first few weeks, and support on the subject.

Regretting the end of the internship I now close this chapter in my life and the blog post!

-- Kevin Wille

Test Results: Firewall Rules Set

In this last real technical blog post we will discuss the test results with the firewall rules in place on the OS. In Windows distributions this is just the standard firewall. In Linux I used Ip6tables and for FreeBSD ipfw. We still want to have good IPv6 connectivity so it's not the intention to block all "dangerous" traffic and have no auto configuration or anything anymore. We will try to accomplish this by denying all traffic and whitelisting all trusted traffic. The rules we added are discussed in the previous blog post. Keep in mind variations of these results are always possible if some of the rules used are modified.

UNIX

Scanning

Since ICMPv6 Response & Request messages are blocked by ipfw, none of these scans went through.

DoS

All floods except for the DAD attack were let through. This is because while not all traffic is let through. RA's/NA's are limited to the default router/local traffic but they still have to check these packages. So when a flood is in effect, they have a lot less load increase but it is still present (about 20-30%) per DoS.

MITM

None of the MITM attack work anymore. This is because we limit RA's to only be accepted from our default router, and NA's only for local traffic.

LINUX

Scanning

Since ICMPv6 Response & Request messages are blocked by ip6tables, none of these scans went through.

DoS

Because in Linux we can limit the traffic allowed through for specific packets, we did this for RA's and NA's to be limit to 10 packets per second. This meant no DoS attacks had any real impact.

MITM

All distributions tested blocked all MITM attacks except for Ubuntu. Ubuntu got spoofed with the NA/NS MITM attacks.

WINDOWS

Scanning

Since ICMPv6 Response & Request messages are blocked by ipfw, none of these scans went through.

DoS

All DoS attacks still worked on all OS's because in Microsoft the amount of packets cannot be limited. Because of this Microsoft OS's are still susceptible by DoS Attacks.

MITM

None of the MITM attacks work anymore. This is because we limit RA's to only be accepted from our default router, and NA's only from local traffic.

Conclusion

After implementing some basic firewall rules we can conclude that most malicious traffic can be stopped. Of course for some platforms of OS's additional software or an additional firewall still should be implemented to try and completely block all malicious traffic. In Linux and Unix enough configurations can be made to limit all incoming traffic. While in windows you cannot.

There are of course many other ways to implement IPv6 security, and it is always best to check for BCP that are relevant to the security measures one wishes to implement. e.g. The following link discusses BCP's for ICMPv6 messages in firewalls.

http://tools.ietf.org/html/draft-ietf-v6ops-icmpv6-filtering-bcp-01

Securing OS's againt IPv6 attacks

In this blog post we will overview some firewall rules to protect a specific OS against IPv6 threats. It is a given these should be some form of last resort since normally a perimeter firewall should be in place alongside an IDS or RA Guard. Because the configuration of these devices fall out of the scope for the internship they will not be discussed here. It can be noted however that all firewall rules reviewed in this blog post should be applicable to a perimeter firewall.

The configuration for these rules will be divided into Windows XP, the rest of the windows distributions, Linux Distributions and Unix.

Windows XP

Not much can be said about windows XP, since no extra firewall rules can be added. IPv6 is supported in the firewall configuration but these configurations run alongside their IPv4 counterpart. Meaning that ICMPv6 request and response are blocked but RS/RA, NA/RA or other IPv6 protocols that don't exist in IPv4 will not be affected by these firewall rules. If wanting to use Windows XP in an IPv6 network it should be secured by other firewalls since it's base firewall is not compatible enough with IPv6 to be effective.

Windows versions

All the rest of the tested windows versions (vista, 7, 8, 8.1, 2008, 2012) have the same firewall configurations so the same rules apply for each OS. Assuming only one router is present in the network, we'd want to limit getting router advertisements from anywhere but the router. This should be done on the local level for extra security. This can be achieved by going into the advanced firewall configuration, setting both incoming and outgoing traffic to deny and finding their respective RA/RS configs. You will also notice that most ICMPv6 types are allowed through on default even if in/out traffic is denied. Disable the rules of the ICMPv6 traffic you do not need or limit them to at least the local network. In our case, none of these were needed so we disabled all the extra rules.

Now for the RA/RS rules, you don't need to change anything except for the range. You will have a global and a local range. Since we only want RA/RA messages from our local network (only the router), you set the global range to "specified range" but don't fill in any range. For the local network you should do the same but here fill in a single address: the LLA address of your default router. You can also specify the global address of the router, but only the LLA should be enough.

Next up are the NS/NA messages. It is optional if you want to enable these if other traffic is allowed on the same private network, but since we don't want to limit every functionality of IPv6, only restricting it should be fine. In Windows it is not possible to limit the rate of packets coming in so be careful who you allow through. In our example we allowed NS/NA traffic from the local network, which is not ideal since a breach of the local network would nullify these rules. For the NS/NA rules, we specified on the local part that only traffic from and to fe80::/10 should be allowed.

These are all the firewall rules that should be changed in our setup for the attacks we tested. Almost all of the MITM / DoS attacks use these protocols and so should be limited.

Linux

In the Linux distributions the IPtables were used to restrict traffic through our network. A lot of these distributions have GUI versions for these IPtables, but these can be different in each version. So since IPtables are the core for all distributions, it is easier to use this.

First of all set the default policies to drop (by default they are set to accept) and flush them just to be sure. Normally now all traffic should be denied. We will take the same approach on which traffic to accept as with windows, only iptable rules can be modified more detailed and complex. First of all we would want to accept traffic from our default router. This can be done by allowing traffic from it's LLA to our system. e.g.
ip6tables -A INPUT -s fe80::a00:27ff:ff27:00a -j ACCEPT

With these we allow all trafiic from our default router. This ensures that the only RA/RS messages accepted will be those of the default router.

The NS/NA messages will also only be allowed from our local network but are limited.

ip6tables -A INPUT -s fe80::/10 -p icmpv6 --icmpv6-type 135 -m limit --limit 5/sec --limit-burst 10 -j ACCEPT

This rule will ensure the use of the NDP but will also make it harder for attackers to flood our system with NA/NS packets.

Of course all these rules should be reversed at the output rules where -s (source) is changed to -d. Else the host will receive those packets but will not respond to them.

UNIX

FreeBSD has no IPtables like the linux distributions, but has IP filter /IP Firewall which are very much alike to iptables. As with the Microsoft and Linux distro's we will restrict all traffic from and to our system by only allowing traffic from the default router. A slight mix-up here in FreeBSD is that it does not support to specify NS/NA yet (with ipfw) so we a)block all traffic like usual but we can't add an allow NS/NA rule so NDP does not work anymore or b) we accept all icmpv6 traffic. I think it is safe to say for the purpose of these tests that we shouldn't allow all ICMPv6 traffic... You can however allow all ICMPv6 traffic and then block the specific ICMPv6 types that are available to overlap with each other.

An example of this is when we block RA/RA messages from the local network. You will notice since this is not iptables anymore, that the syntax is a little different for FreeBSD. First things first, we need to enable the firewall in the /etc/rc.conf. You add these sentences to the file:

firewall_enable="YES"
firewall_script="YES"
firewall_script="/etc/ipfw.rules"

These allow the firewall to be enabled on boot, and allow us to load a script with our firewall rules on load. You specify the rules you wish in the file /etc/ipfw.rules. Do not forget to flush ipfw first in the script, else there might be problems with the default rules.

An example of blocking RA/RS messages:

ipfw add deny ip6 from fe80::/10 to any icmp6types 5,9,10 in

These icmp6types can be found in the types list on the manpages of ipfw.

Conclusion

As we can see, these firewall rules can be a reasonable line of last defense in case the perimeter firewall is breached, but still most of these rules are to incomplete to work effectively. Most of the time some sacrifice has to be made either security wise where some protocols you do not wish to pass that do pass or where some protocols (like NDP) that you want to let through but can't. The most complete rules are those of the iptables since these have the most options available plus they can limit the rate of the packages let through. Unix is not bad either, but is more complex.

Test Results: Default Firewall

Like my previous blogpost, I will discuss some of my findings during my tests of IPv6 networks where the systems have their default firewalls enabled. The same OS's will be tested with the same attacks. These tests are made so we can have an insight at how well networks would handle attacks once the perimiter firewalls or IDS is bypassed. Note that these tests work with the assumption of an IT administrator that just left the default values as they were in the firewall regarding IPv6. The IPv4 part of the firewall can very well be adequatly protected.

Another thing to note is that most Linux OS's do not have any default rules whatsoever. Linux distributions work with IP tables. On the distributions I tested, these allowed everything. One more point of interest is Windows XP. Since it does not support IPv6 natively and had to be installed, by default no firewall rules were in place for the IPv6 network. This is adjusted since Service Pack 2 where IPv6 firewall rules are grouped under IPv4 firewall rules. This means that traffic that both IP's use will be subject to these firewall rules while the others will not. E.g. Echo Request and Responses (pings) will be blocked since both IPv4 and IPv6 make use of them. RA, RS, NA and NS messages on the other hand will not be blocked.

UNIX

Scanning

FreeBSD uses the ipfw (IP firewall) which is not enabled by default, but can be enabled with some default firewall rules in place. Most rules allow traffic on the local level but not on the global level. For scanning this is the most interesting path anyway. There are two rules however that only allow some ICMPv6 type messages to get through on the global level. These being 1,2, 135, 136. This means that for our scanning tests, the scans failed. None of the scan tests tested managed to find the FreeBSD Host

DoS

Since the DoS attacks work both on the global as the local level, none of the DoS were effectively blocked.

MITM

The NA and redirect MITM attacks did fail this time around since the redirect I tested used global addresses. Normally NA MITM should be successful but as this is a local MITM attack, and the firewall only allows the packets with a global address through, this attack also failed.

LINUX

As stated previously in Linux distributions no real default rules are added. The IP tables let all traffic through by default.

WINDOWS

Scanning

As expected, just like with the IPv4 firewall rules, all Echo Request/Response packets are blocked by the default firewall. So all the ping scan tests failed. On the portscan however, Windows 7, 2008 and 2012 still had ports open. (port 5357)

DoS

No Windows system actively blocked one of the DoS attacks. This can be verified by looking at the firewall rules, where the inbound rules state that almost all ICMPv6 traffic (except for pings) is allowed through.

MITM

Same as with the DoS attacks, no system actively blocked more MITM attacks then they already did (or didn't).

Conclusion

While Linux systems generally handle IPv6 traffic a little better than Microsoft systems (e.g. during floods), their default allow-all rules obviously did not help in these set of tests. Of course one can argue that most IT administrators that use Linux distributions generally know what they are doing and would not leave the "default" firewall rules (in this case IP tables) the same.

FreeBSD did very well on this test, with the pleasant surprise of at least some form of IPv6 rules that made some attacks impossible. Still Floods can be the most disruptive (and hard to deflect) attacks, these all still worked.

Microsoft had no real surprises other than that they blocked pings. Almost all other ICMPv6 traffic was allowed through making the effort of blocking the pings obsolete.

In general it is safe to say decent firewall rules are not widely used yet because IPv6 is not as common as IPv4 yet. One can argue however, that those who make the transition to IPv6 (or use dualstack) generally know what they are doing and at least implement some basic firewall rules

Test Result Overview: No Firewall

In this blogpost I will give a quick overview of my test results when testing attacks on an IPv6 network where the victim systems have no firewall enabled. The purpose of this test is twofold: to see what the attacks can do on different systems if the firewalls could be breached and disabled. Furthermore this test serves as a baseline for further tests. It's also important not to assume every IT administrator leaves at least his default firewall on, now can we? It probably occurs that IT admins rely heavily on their perimeter firewall/router to fend off the bad guys and run into less problems by just disabling the firewall for the private networks.

I will not go into detail on these test results, but will give more of an overview with the most interesting results. The OS's tested are divided into 3 groups. The first group is UNIX, which only consists of one OS's, FreeBSD 10.0. The second group is Linux which includes Debian 7.4.0, Ubuntu 12.04, Fedora 20 and CentOS6.5. I chose these to try and cover quite a large range of distro's, since most other are related/derived from these. The only exception to this are the SUSE distro's which I did not include in these tests yet, if enough time is lefover after the final tests SUSE will also be tested. The last group of course is Microsoft, its ease of use and widespread use makes that the most OS's that are encountered in the wild will be from Microsoft. These include Windows XP SP3, Vista SP1, 7, 8, 8.1, server 2008 R2 and server 2012. These are chosen because I think these are the most common versions out there. The SP ratio might seem random, but I used what was available to me.

The attacks itself I will divide into 3 groups: Scanning, since it is no use trying to access a network if you don't know the addresses of the victims. DoS because this can cause severe problems if used on a server and MITM which includes maybe the most dangerous attack of them all.

UNIX

Scanning

Here I tested a portscan, a general scan of the network, scan on known OUI, IPv4 or sequential addresses. As expected, without any firewall this is like shooting fish in a barrel. Because I left the IPv6 address to the distribution of the router, the system generated an IPv6 address based on the OUI of the virtual software. It also uses the same address every time it boots. All tests were successful in finding the victim except for the one where I searched based on IPv4 embedded addresses. As I said these results were expected since no firewall stopped ICMP traffic

DoS

As I researched some of the attacks (like RA flood, smurf, NA flood, NS flood) many sources claimed that RA flood is fended off by Linux and Unix systems' IP stack and thus should not have that great an effect. Well tests proved otherwise: while only the RA flood completely froze the system, the other ones also had huge load increases ranging from 50 to 80%! If you know that FreeBSD is exclusively used as a server, which may or may not run under a very high load already, you can easily spot the problem.

MITM

In this category FreeBSD scored better than in the previous tests. I tested MITM attacks with spoofed RA's, spoofed redirects, spoofed NA's and the dreaded SuddenSix SLAAC attack. The redirect is indeed successful, but the malicious packet should constantly be resent if this is to work efficiently, else the system discards the redirect. Spoofed NA's completely did not work. Spoofed RA's did work but the greatest surprise was that the SuddenSix attack did not. This is because FreeBSD has to be completely configured manually, IPv6 addresses can be acquired dynamically (via RA's) but IPv4 addresses cannot (at least not with a lot of tinkering). So FreeBSD might accept the packets sent out by SuddenSix, but just doesn't handle them since it only knows to set and IPv4 address statically (which again, is part of its exclusive use as a server, it has no need of dynamic addresses)

LINUX

Scanning

The same as with the UNIX systems, most scans worked except for the  IPv4-embedded one. Only Ubuntu and Fedora had the exception of even with no firewall enabled, no open ports could be detected.

DoS

Where Fedora scored "best" on in scanning, it dropped the ball on the DoS. ALL of the DoS attacks worked on it. None of them actually caused it to freeze, but all of them made them run VERY slow and thus unworkable. CentOS on the other hand performed excellent! Even without any firewall rules whatsoever, only the smurf attack used up a few resources. All other DoS attacks did not manage to increase the load by even 10% or didn't do anything at all! Ubuntu and Debian on first glance did not fall for the RA flood, as only 10 addresses or so are accepted and added to the NIC so no freeze BUT it disconnects the systems from the network which is also a DoS.

MITM

As good as most of the systems scored on the DoS tests, none of them scored well against the MITM attacks, on every system, every attack worked or at least spoofed some addresses in the neighbor cache. This is because while they are protected against floods, the MITM attacks are no different from real traffic and are only sent out periodically.

MICROSOFT

Scanning

Windows actually performed better than expected on these tests because of the way the generation of an IPv6 address is implemented. When windows systems generate their IPv6 addresses, they actually generate 2, one "set" addresses that stays after reboot and a temporary address that is different every time. If you scan the network the only address you get to see is the temporary one which makes it a little harder for attackers to continually attack those systems since they have to recheck the addresses every time the systems are rebooted. Also, the OUI scan where all Linux and UNIX systems failed, does not work for windows since their addresses are not based on the OUI of vBox, they only exception for this is windows XP. Still except the OUI scan all other scans worked, but it is nice to see, some measurements are taken to at least make it a little harder for attackers.

DoS

No real surprises here, almost all systems are affected by all the attacks (even the smurf attack, which is described to only work on Linux based systems) with only a few exceptions, Windows 7 and server 2008 are not affected by the NA flood whatsoever, and windows 8.1 is not affected by the NS flood. RA flood completely freezes every system except for windows 8.1. Windows 8 and 2012 do run normal again after the attack is stopped, while all other systems have to be rebooted (sometimes manually!) for them to work normal again. Also there is no hope for improvement of the RA flood on the older systems as security researcher Sam Bowne tested this attack against many different systems, and notified the manufacturers (in this case Mircosoft) but Microsoft coldly responded with something along the lines of: we will only "prevent" this attack for windows 8 and further ( if you can call causing them to freeze or have a constant CPU load of 100% preventing it...) and older systems will not receive this treatment, meaning they will continue to be affected by it. [1]

MITM

Also had the expected results where most of these attacks did work and route all IPv6 traffic through the attacker EXCEPT two systems. Since XP does not have IPv6 support "out of the box" (you have to enable it) it does not completely handle some packets right, an NA MITM does not work on XP because it does not respond on NA from other systems. It only sends out its own NS on the network and only responds on those. If this shortcoming is good or bad is open for discussion, on the one hand it is not affected by that attack, on the other it only acts that way because it does not know how to handle NA records properly... All other MITM attacks do work however.
The second and greatest surprise is Windows 7. This OS is completely unaffected by the SuddenSix attack. It still baffles me why and how it does not work on this system alone. Win 8, 8.1, server 2008, server 2012 are all still affected by it and ONLY windows 7 not. It does not get a spoofed IPv6 address, no router entry for the attacker nothing. I have searched the internet far and wide as to why it isn't affected but could not find out why. Is because of my setup? It could possibly but all other systems are setup exactly the same way... Is it because it is a virtual machine? All others are too... Did I configure something wrong? Possibly but since I just had to disable the firewall, I cannot see why I did misconfigure. It also accepts IPv6 traffic in the settings, and does gain an IPv6 address automatically when given out by a router so why does it not work? All other MITM attacks DO work on Win 7, it is only the SuddenSix one that doesn't...

Conclusion

While many of these results are expected some OS took me by surprise. Unix and Linux systems performed as expected from research with a few exceptions, but for me it is windows that takes the cake. Microsoft can implement some good ways to deter attackers (IPv6 address not based on OUI, also generate a temp address that is the only one picked up by scans) and on the other hand, they completely ignore some more pressing attacks like the RA flood (except on win8 and further). They also have the most "flukes" if you can call it that with WinXP that does not (always) respond to NA's because of an implementation error (probably) and Win7's complete disregard for the SuddenSix attack!
Of course more interesting results will follow when the default firewalls are actually turned on.

References:
Cisco Press: IPv6 security by Eric Vyncke
http://samsclass.info/ipv6/proj/RA_flood2.htm
SI6 toolkit by SI6 Networks
THC Toolkit
Scapy tool
SuddenSix script by Neohapsis Labs

Progress of the internship

This week the blogpost will summarize my time here up until now at EY. This is because the internship in now more or less halfway done. I will elaborate on my steps until this week and how/why I did it that way.

Step 1: Research

When the internship just started, I only knew the basics of IPv6 networking. In the class ANT we had seen how IPv6 worked, the different kinds of addresses, how an IPv6 packet looks like, etc. Still security is a whole other branch where those basics should be common knowledge so you at least understand when a specific test works or doesn't work.

My teacher M. Vansteenberghe lent me a book about IPv6 since this expanded more on the subject and frankly, the class about IPv6 was almost a year ago so I knew I had to refresh the subject before starting my internship. When the book was finished, I also started collecting information I could find to gain a headstart when starting at EY

When starting my internship, my biggest help would have been the cisco book of Eric Vyncke: IPv6 Security. This covered alot of the security issues I now test and as also described how one could try to prevent such an attack on the network. I viewed many other sources like the RFC's about IPv6/ Neighbor discovery and so on.

Step 2: Choosing the toolkits

When researching for the different kinds of attacks, I also had to consider how to test them. Alot of the "attacks" or security breaches I found did not have enough information on how to test them on your own network. It would of course be probematic if I only researched  2 or 3 highly complex attacks that may or may not fault any network, secure or non-secure when at the same time I could research many different smaller attacks that may be more common.

The toolkits I needed if found rather quickly, THC IPv6 Attack toolkit has the most tools to test with and is easy to use. SI6 IPv6 was another known toolkit which had fewer attacks to test, but were more complex and could be more expanded upon. E.g. the scan in THC "alive6" just scans the local network, while the scan6 tool of SI6 can scan for various options like embedded IPv4 address, OUI, sequenced numbers, etc. My last major tool would be scapy. Very handy for getting a closer look at the specific packets and is used to test those few attacks that THC and SI6 did not cover (E.g. RHO or Router Alert).

Step 3: Setting up the test environments

After the research was done and my documents about the tests were done, it was time to think about the environments where to test them. They had to be light on the CPU load since most of it is tested in a virtual environment. With this I also had to make sure the test networks were small as I would overload the CPU otherwise. Eventually I went for simple networks where a router deals out the addresses, a switch and a victim. And of course our attacking computer.

A router would ideally have been a cisco router, since this gives the most options to later expand on security, but was hard to accomplish since again, it would take up alot of resources and not every cisco router is available to me nor has every cisco router IPv6 support. The choice was made to use pfSense which acts as a router and a firewall.

When the test environment was set up, all that remained was to set up all our devices. Most were just the typical install and wait theme, but for others like pfSense, a little documention was required.

Step 4: Testing the environments

Right now I am in the middle of testing so I will not disclose to much information as of yet (wait for further blog posts!). But I will disclose my 3 typical scenario's. First of all, all the attacks will be tested against an OS with no firewall enabled. This is mostly to look which OS has bugs in their TCP/IP stack by default or which OS handels the attacks the best. Otherwise there are still alot of IT admins that just disable their firewalls (or in case of some linux distro's don't configure them) so traffic flows more freely and they don't encounter many problems.

The second scenario is the same tests against the same OS's but this time with their default firewall settings. Even more common then IT admins disabling their firewalls or IT admins simply leave the defaults on because it will be enough "as is". Of course most of these OS's have reasonable firewall rules so that you are more or less "safe" in an IPv4 network, but there is the catch, since IPv6 is different, or they have no IPv6 specific rules (like rules for NA/RA/) or they are badly configured.

The last scenario is those same tests against a network and hosts that have the BCP (Best Common Practices) enabled. So that means the correct firewall rules, manual IP addresses (if possible, in larger networks this might not work out) and then some! This will be the most important test to see which attacks are actually the more dangerous ones to look out for in an already secure network.

Conclusion

The internship has been fun and very interesting up until this point, I personally think it's great to think about the security aspect of networks and such and having the opportunity to test and improve those networks. Of course my research here is not ground breaking, all these attacks are known  already and tested properly but I found it hard (at least at the time of writing) to find a complete "guide" with multiple toolkits. Also little information is found on how these attacks react to different kinds of OS's and versions of those OS.

References:
- Cisco Press: IPv6 Security by Eric Vyncke
- THC IPv6 Toolkit: https://www.thc.org/thc-ipv6/
- SI6 Networks IPv6 Toolkit : http://www.si6networks.com/tools/ipv6toolkit/
- Scapy : http://www.secdev.org/projects/scapy/

IPv6 Header Manipulation Part 2

In our previous blogpost we talked about the security issues with the IPv6 Header that can be manipulated for multiple attacks. While these attacks may occur from time to time "in the wild", what really is a concern with Header Manipulation is fragmentation of the IPv6 header/packet. This is used to bypass firewalls / IDS or RA Guard on a switch. As you can see, this poses even greater risks as the attacks explained in the previous post are either not a great threat in small numbers or ,assuming you frequently update/upgrade your systems, simply don't work anymore. I will explain ways you can achieve a bypass via fragmentation.

Method 1: Fragmentation

This part is the base of fragmentation bypasses. The way this is exploited is by how firewalls / IDS or RA Guard check an IPv6 packet. First of all for routers that have work as a firewall to (like in my test setups, pfSense acts both as a router and as a firewall) or just routers in general, as long as the "Hop-by-Hop" Next Header is not specified, routers will not perform "deep" inspection of the packets, this means they will only look at the information needed from the IPv6 Header to forward the packet (which is usually the first packet unless specified otherwise). Which of course makes it easy do "hide" malicious data in the other fragments (e.g. Spoofed RA).
With firewalls, they most commonly only look at the unfragmentable part of the packet and check that for any malicious intent. Another way is to spread the attack into multiple fragmented packets that seemingly look safe but when reassembeld by the destination host, make a malicious packet. As you can see in figure one, a firewall will most likely only look at the unfragmentable part, so if they put an attack in the second fragment (like a RA) this could go unnoticed

Figure 1: Fragmentation. [1]

 

 



Method 2: Large Destination Header Option

Another method to try and bypass a firewall / RA Guard is by spoofing a large Destination Header with more than 2kb of payload of useless data causing it to be split (fragmented). Usually Firewalls will then only check the remainder of the Destiantion Header Option payload in the next fragment and thus a packet like an RA could be added. Since this is a Destination Header Option, routers should not inspect this packet since it is only ment to be checked at the destination. An added "bonus" with this bypass is that due to the large payload of the Destination Header Option you could inadvertadly crash the firewall since it should not have to process such a large Option. This only happens with firewalls that have low resources / not alot of processing power or badly configured ones. In figure 2 it is shown how such a large destination header fragmentation works.

 

Figure 2: Large destination bypass [2]

 

 

 

Method 3: Hop-by-Hop Header Option

The third method is also somewhere along the lines of the second methode, only this time you do it with Hop-by-Hop Header option. You again craft a Hop-by-Hop option that is to large to be fit in one packet so that it is fragmented. In the second packet you then add an RA (for your attack) after the fragmented Hop-by-Hop option. Again, routers will only look at the second fragment for the Hop-by-Hop information and will not see the RA that follows the option. I refer back to figure 2 for this bypass, as the only thing that changes is the Dest. Opt. Header into the hop-by-hop Option Header.

 

Conclusion

As you can see there are a few ways you can try to bypass staple IPv6 network security machines like firewalls and RA Guard. The reason I discussed multiple of essentialy the same concept is that some firewalls protect agains some attacks or some routers protect against some attacks. E.g. If you test this bypass on your firewall but you let the fragments overlap, this will almost centainly be picked up by any modern / updated firewall whereas if you use the Large destination option header bypass instead, the attack might still work. In general alot of these bypasses can be caught if you use deep packet inspection but it is worth considering that of course this slows down traffic into your network significantly and a complex well constructed packet could still be passed through.

 

There are other ways you could try to spoof the packets into fragmentation with different payloads, different options etc. These are the most easily tested since they are included in the THC IPv6 Toolkit as option in various attacks.

References:
[1] Cisco: IPv6 Security by Eric Vyncke
[2] http://blog.si6networks.com/

https://tools.ietf.org/html/rfc6980
http://tools.ietf.org/search/rfc5722
http://www.si6networks.com/presentations/deepsec2011/fgont-deepsec2011-hacking-ipv6-networks.pdf
https://tools.ietf.org/html/draft-krishnan-ipv6-hopbyhop-05
https://tools.ietf.org/html/rfc2460