This is the final blog post about 6Guard(download link), a honeyot-based IPv6 attack detector. Here I will introduce the overview of 6Guard in brief firstly, then describe the new features that was added to 6Guard in detail.
6Guard is a honeypot-based IPv6 attack detector aiming at detecting the link-local level attacks, especially when the port-mirror feature of switch is unavailable.It can help the network administrators detect the link-local IPv6 attacks in the early stage. Currently 6Guard can detect most attacks initiated by The THC-IPv6 suit , the advanced host discovery methods used by Nmap, some attacks initialed by Evil Foca and Metasploit.
The picture above shows the architecture of 6Guard. From the picture we can see that, 6Guard mainly use Python and Scapy, mainly has three moudles, Honeypot and Globalpot and Event Analysis. The Honeypot module is responsible for detetecting unicast attacks, The Globalpot module focus on detecting multicast attacks, and The Event Analysis moudule get event message from Honeypot and Globalpot and generate attack message if attack is detected.
New freatures and Detecting example
1. Project description
The goal of the project is to improve current IPv6 honeypot (6Guard) detection mechanism for various latest IPv6 attacks, get the results and have a proper logging method. Currently IPv6 honeypot (6Guard) is capable to detect certain IPv6 attacks. As there are various new IPv6 attacks technique discovered and tools were released since last year, we need to improve the detection mechanism. For example, it should be able to fully detect the attack scenarios with various Extension headers combination, fragmentation techniques, RA-Guard bypass tricks, packet DoS attempts and etc. We also need a proper logging mechanism for the collected results, e,g, a DB for better results analysis.
2. Fragmentation attack detection
As mentioned above, 6Guard can’t detect the attacks using fragmentation techniques. After we read the 6Guard code, we find that the root cause of this is that 6Guard lacks traffic reassembly, when attack packets are fragmented, 6Guard cannot reassemble the packets and detect the attacks. As a result, we often find that 6Guard is capable to detect the attacks initiated by “fake_advertise6” and “fake_route6”, but can’t detect the attack initiated by “fake_advertise6 -D” and “fake_router6 -F”.Besides, I have read some recent materials about IPv6 attacks and defenses,and investigated the details of these attacks (see my notes).
In order to detect these attacks, we read the frag3 module in Snort, developed a defrag6 module, many of which are learned from snort and added it to 6Guard. This module can track fragments in certain time, and reassemble them.
Timestamp: 2013-10-03 11:43:22
Reported by: Globalpot
Name: Fake Neighbor Advertisement to ff02::1
Victim : [The whole network]
Source: [ff02::1] MAC: 00:50:56:ac:71:ae (VMware, Inc.)
Utility: THC-IPv6: fake_advertise6
While we write the defrag6 module in 6guard, we find that the module is also responsible for detecting many other fragment tricks.
a) The TTL inspection. Attackers often use TTL to bypass the firewall, so the TTL inspection is to check the TTL value of each fragment, if the TTL value is too small (The firewall can see the fragment, but the victim can’t see it), 6Guard will discard the fragment and show warning message.
b) tiny fragments detection, Many DoS attackers craft tiny fragments to consume the resource of the system, so if the fragment is too small, 6Guard will show warning message.
c) Apart from that, 6Guard can also detect “Timeout Fragment”,”Too big reasssembled Packet”,”Overlapping Fragments”attacks.
Timestamp: 2013-10-03 11:33:25
Reported by: Globalpot
Type: Invalid Fragment
Name: Overlapping Fragment
Utility: THC-IPv6-fragmentation6, Crafting malformed Packets
3. Extension headers inspection
When we added the defragment module to 6guard, 6guard cannot reassembly the fragments normally due to the abuse of extension headers. For example, if a fragment has two fragment extension header with different offset in them, the defragment module can not decide which fragment header to use. What’s worse, the RFC2460 says “IPv6 nodes must accept and attempt to process extension headers in any order and occurring any number of times in the same packet”, so we can not discard the malformed packet directly.
To solve this problem , we develop a exthdr module which can inspect the extension headers in detail. Now 6Guard can parse the packet headers , when the abnnormal extension headers is detected , it will report it and try to correct the abnormal packet. for example, if there are multiple occurrence of fragment extension header in one packet, we just remove the redundant headers and only keep the first one.
Timestamp: 2013-10-03 11:41:14
Reported by: Globalpot
Type: Invalid Extension Header
Name: Invalid Extension Header in packets
Utility: Crafting malformed Packets
4. Logging mechanism improvement
Another important goal in this project is to improve the logging mechanism of 6Guard. I have investigated the log mechanism of different honeypots(see my note), and improved the logging mechanism of 6guard refer to other honeypots.
Currently the new 6guard have three way to log the attacks, textlog, hpfeeds, and mongodb.And they can be confiured in the new global configfile(6guard.cfg). the three log moudle has the same parent class(dblog.py).
a) Textlog is same as previous attack.log, which means log the attack information into a file, you can file the log file in log/text.log
b) Hpfeedslog means 6guard can publish the attack information to hpfeeds center, and we also add hpfeeds_subsrciber module to test it. You can run “python testing/hpfeeds_subscriber.py -i 96wzTQHn -s Ajgfx9GhgnPuhFey –host hpfeeds.honeycloud.net -p 20000 -c 6guard.attacks subscribe” to subscribe the attack information.
c) mongodblog means 6guard can store the information into mongodb database for future analysis.
5. Other features
a) Detect SLAAC Mitm attack and Neighbor Advertisement Spoofing initialed by Evil Foca
b) Detect ipv6_neighbor_router_advertisement and ipv6_multicast_ping in Metasploit
Timestamp: 2013-10-03 22:05:19
Reported by: Honeypot-apple-25:76:C0
Type: SLAAC attack
Name: SLAAC Mitm attack
Attacker: [fe80::20c:29ff:fe65:cb60] 00:0c:29:65:cb:60 (VMware, Inc.)
Victim : [Honeypot-apple-25:76:C0] 34:15:9E:25:76:C0 (Apple, Inc)
Utility: Evil Foca: SLAACv6 attack
It was a exciting summer and I have learned a lot from this GSoC project. Many thanks to my mentor Tan Kean Siong and my backup mentor Weilin Xu, I cannot complete this project without their help. Thanks to The Honeynet Project and Google for give me the precious opportunity to learn.