Bug #3323
opentracking: ipv6 evasions
Added by Victor Julien about 5 years ago. Updated 6 months ago.
Description
This paper list various issues with IPv6 anomalies:
https://pdfs.semanticscholar.org/00b2/9f5cd4458ad88db2741a5989a4f2b0610411.pdf
Anyone interested in producing pcaps for all the tests?
Updated by Victor Julien about 5 years ago
- Target version changed from TBD to 5.0.1
Updated by Victor Julien almost 5 years ago
- Target version changed from 5.0.1 to 5.0.2
Updated by Philippe Antoine almost 5 years ago
- Related to Task #3392: Tracking: protocol detection evasions added
Updated by Philippe Antoine almost 5 years ago
Updated by Victor Julien almost 5 years ago
- Target version changed from 5.0.2 to 6.0.0beta1
Updated by Andreas Herz over 4 years ago
- Assignee changed from Andreas Herz to Philippe Antoine
Updated by Philippe Antoine over 4 years ago
- Status changed from Feedback to Assigned
- Priority changed from High to Low
- Target version changed from 6.0.0beta1 to TBD
One evasion is understood and "fixed" with a new signature keyword.
The other ones are not understood yet
Updated by Philippe Antoine over 3 years ago
So, here is what I gather from denial6-6
Paper says
It detects the denial6-6 attack that Suricata missed and warns correctly “short fragment, possible DOS attempt” and “fragmentation overlap”.
For me it is not fragmentation overlap, but rather starting many fragments with different identifications cf https://datatracker.ietf.org/doc/html/rfc2460#section-4.5
What should we do about this ?
There is already the defrag.memcap
limit. But maybe we should limit the number of current defragmentation per IPv6 pair
That would change DefragHashGetKey
not to use IPV6_EXTHDR_GET_FH_ID
so that same IPv6 pair ends up in the same bucket, so that we can put a limit on the bucket's linked list length...
What is called by Snort “short fragment, possible DOS attempt” is in fact the RFC saying
The Fragmentable Part of the original packet is divided into fragments, each, except possibly the last ("rightmost") one, being an integer multiple of 8 octets long.
cf EventAnomShortFrag
Updated by Philippe Antoine over 3 years ago
I do not understand the Chiron attack.
dos new ipv6 is about spoofing. The way to detect this would be to have a recorded network structure where each host is identified by MAC and IP-Address
I do not know what we want to do about this :
- nothing : people can use the logs and do some post-processing to tell the difference between the expected network map and what they see
- be able to load a map of the network so as to alert when there is an unknown/spoofing machine appearing
Updated by Philippe Antoine over 3 years ago
That comment about dos new ipv6 goes also for fake mldrouter advertise
Updated by Philippe Antoine over 3 years ago
So, global status :
- covert send6 : S-V PR https://github.com/OISF/suricata-verify/pull/518
- denial6-1, 2, 3, 4, 7 : S-V PR https://github.com/OISF/suricata-verify/pull/518
- denial6-5 : S-V PR https://github.com/OISF/suricata-verify/pull/518
- denial6-6 : Question + Suricata PR https://github.com/OISF/suricata/pull/6271
- dos mld chiron : TODO understand
- dos new ipv6 and fake mldrouter6 advertise : Question
- fake mldrouter6 terminate : nothing to do
- flood* + ndpexhaust26 : question
- frag : TODO investigate
- kill router6 : S-V PR https://github.com/OISF/suricata-verify/pull/518
- parasite6: question
- redir6: TODO understand
- smurf6 : S-V PR https://github.com/OISF/suricata-verify/pull/518
- toobig : done
false positive : http invalid host https://github.com/OISF/libhtp/pull/329 https://github.com/OISF/suricata-verify/pull/520
Updated by Philippe Antoine over 3 years ago
flood advertise6 is interesting.
It is a pure DOS : just send many spoofed messages so that Suricata allocates many ressources when the attacker
As they are spoofed, we cannot see they if share the same origin, the only similarity being that they are icmpv6.type == 136
What could we do about it ?
We already have flow.memcap
, but as for denial6-6, we may want to give up on those attacking flows rather than on the real ones.
Maybe we can have the flows timeout/cleanup try to pick first the flows with only one packet (from only one side)
We could also try to alert about this flood attack, trying to get data to have a flamegraph to visualize all the flows (IPv6 vs IPv4, TCP vs UDP, vs ICP, etc...)
Same goes for other flood attacks.
Beyond flooding Suricata, we should also think about if these flooding attacks are a DOS against another equipment such as a router (maybe MLD messages do this)
flood_rs6 does not seem a concern (only one flow with the same packet over and over again)
Updated by Philippe Antoine over 3 years ago
For parasite6, ie the IPv6 version of an ARP cache poisoning, we could have an alert if we see 2 packets icmpv6.type == 136
with same IP and different MAC addresses (ie if we keep a version of the cache)
But then, we would not know which one is right, unless we have some external data...
Should we do something ?
Updated by Victor Julien over 3 years ago
- Label Needs backport to 5.0, Needs backport to 6.0 added
Updated by Victor Julien over 3 years ago
I think it would be helpful if we do subtickets for the individual issues. Otherwise it will be near impossible to track backports.
Updated by Philippe Antoine over 3 years ago
Victor Julien wrote in #note-19:
I think it would be helpful if we do subtickets for the individual issues. Otherwise it will be near impossible to track backports.
Do you want issues for already merged code ?
For already submitted PRs ? like https://github.com/OISF/libhtp/pull/329
Updated by Philippe Antoine over 3 years ago
So, global status :
- covert send6 : S-V PR https://github.com/OISF/suricata-verify/pull/534
- denial6-1, 2, 3, 4, 7 : S-V PR https://github.com/OISF/suricata-verify/pull/534
- denial6-5 : S-V PR https://github.com/OISF/suricata-verify/pull/534
- denial6-6 : done in https://github.com/OISF/suricata/pull/6310
- dos mld chiron : to understand
- dos new ipv6 and fake mldrouter6 advertise : Question
- fake mldrouter6 terminate : nothing to do
- flood* + ndpexhaust26 : question
- frag : PR https://github.com/OISF/suricata/pull/6367 as for https://redmine.openinfosecfoundation.org/issues/4664
- kill router6 : S-V PR https://github.com/OISF/suricata-verify/pull/534
- parasite6: question
- redir6: to understand
- rsmurf6, smurf6 : S-V PR https://github.com/OISF/suricata-verify/pull/534
- toobig : done
false positive : http invalid host https://github.com/OISF/libhtp/pull/329 https://github.com/OISF/suricata-verify/pull/520
Updated by Jason Ish about 3 years ago
ipv6: decoder event on invalid length:
- commit in master: ca760e305cd74933b685b1bd5be795b24a7d94a7
- commit in 6.0.x: b82f337317b677a790b288189af9cf74e92dc57c
- 5.0.x: backport pending
Updated by Victor Julien about 3 years ago
Jason Ish wrote in #note-22:
ipv6: decoder event on invalid length:
- commit in master: ca760e305cd74933b685b1bd5be795b24a7d94a7
- commit in 6.0.x: b82f337317b677a790b288189af9cf74e92dc57c
- 5.0.x: backport pending
Can we track this in a dedicated ticket?
Updated by Victor Julien about 3 years ago
- Subject changed from ipv6 evasions to tracking: ipv6 evasions
Updated by Philippe Antoine about 3 years ago
Updated by Philippe Antoine about 3 years ago
What remains to be done after 6.0.4 :
- dos mld chiron : to understand
- dos new ipv6 and fake mldrouter6 advertise : Question
- flood* + ndpexhaust26 : question
- parasite6: question
- redir6: to understand
Updated by Victor Julien over 2 years ago
- Label deleted (
Needs backport, Needs backport to 5.0)
Updated by Philippe Antoine over 2 years ago
- Assignee changed from Philippe Antoine to OISF Dev
Updated by Philippe Antoine about 2 years ago
- Related to Task #844: Testing topera against suricata added