Project

General

Profile

Actions

Bug #3323

open

tracking: ipv6 evasions

Added by Victor Julien almost 2 years ago. Updated 10 days ago.

Status:
Assigned
Priority:
Normal
Target version:
Affected Versions:
Effort:
Difficulty:
Label:
Needs backport, Needs backport to 5.0, Needs backport to 6.0

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?


Subtasks 5 (2 open3 closed)

Bug #4664: ipv6 evasions : fragmentationIn ReviewPhilippe AntoineActions
Bug #4666: http: ipv6 address is a valid hostIn ReviewPhilippe AntoineActions
Bug #4679: IPv6 : decoder event on invalid fragment lengthClosedPhilippe AntoineActions
Bug #4686: IPv6 : decoder event on invalid fragment lengthClosedShivani BhardwajActions
Bug #4691: IPv6 : decoder event on invalid fragment lengthClosedJason IshActions

Related issues

Related to Task #3392: Tracking: protocol detection evasionsNewActions
Actions #1

Updated by Victor Julien almost 2 years ago

  • Assignee set to Andreas Herz
Actions #2

Updated by Andreas Herz almost 2 years ago

  • Target version set to TBD
Actions #3

Updated by Victor Julien almost 2 years ago

  • Priority changed from Normal to High
Actions #4

Updated by Victor Julien almost 2 years ago

  • Target version changed from TBD to 5.0.1
Actions #5

Updated by Victor Julien almost 2 years ago

  • Target version changed from 5.0.1 to 5.0.2
Actions #6

Updated by Philippe Antoine over 1 year ago

  • Related to Task #3392: Tracking: protocol detection evasions added
Actions #8

Updated by Victor Julien over 1 year ago

  • Target version changed from 5.0.2 to 6.0.0beta1
Actions #9

Updated by Victor Julien over 1 year ago

  • Label Needs backport added
Actions #10

Updated by Andreas Herz over 1 year ago

  • Assignee changed from Andreas Herz to Philippe Antoine
Actions #11

Updated by Philippe Antoine over 1 year 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

Actions #12

Updated by Philippe Antoine 2 months 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

Actions #13

Updated by Philippe Antoine 2 months 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

Actions #14

Updated by Philippe Antoine 2 months ago

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

Actions #15

Updated by Philippe Antoine 2 months 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

Actions #16

Updated by Philippe Antoine 2 months 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)

Actions #17

Updated by Philippe Antoine 2 months 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 ?

Actions #18

Updated by Victor Julien 21 days ago

  • Label Needs backport to 5.0, Needs backport to 6.0 added
Actions #19

Updated by Victor Julien 21 days ago

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

Actions #20

Updated by Philippe Antoine 20 days 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

Actions #21

Updated by Philippe Antoine 20 days 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

Actions #22

Updated by Jason Ish 17 days ago

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

Actions #23

Updated by Victor Julien 16 days 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?

Actions #24

Updated by Victor Julien 16 days ago

  • Subject changed from ipv6 evasions to tracking: ipv6 evasions
Actions #25

Updated by Philippe Antoine 14 days ago

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

Actions

Also available in: Atom PDF