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/
Geen opmerkingen:
Een reactie posten