Suricata

Some 2014 paper evading suricata 2.0.3 with Ipv6
https://www.blackhat.com/docs/sp-14/materials/arsenal/sp-14-Schaefer-Evasion-of-High-End-IDPS-Devices-at-the-IPv6-Era-Slides.pdf
https://www.ernw.de/download/eu-14-Atlasis-Rey-Schaefer-briefings-Evasion-of-HighEnd-IPS-Devices-wp.pdf

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

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

That comment about dos new ipv6 goes also for fake mldrouter advertise

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

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)

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 ?

I think it would be helpful if we do subtickets for the individual issues. Otherwise it will be near impossible to track backports.

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

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

ipv6: decoder event on invalid length:
- commit in master: ca760e305cd74933b685b1bd5be795b24a7d94a7
- commit in 6.0.x: b82f337317b677a790b288189af9cf74e92dc57c
- 5.0.x: backport pending

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?

Victor Julien wrote in #note-23:

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?

https://redmine.openinfosecfoundation.org/issues/4679

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