Project

General

Profile

Actions

Feature #1696

closed

improve logged flow_id

Added by Victor Julien over 8 years ago. Updated about 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

The current flow_id that is logged in EVE is merely a memory address of the flow. As flows structures are reused internally the same id can appear quite frequently. A scheme that leads to more unique id's is needed.

Actions #1

Updated by Jason Ish over 8 years ago

I've been matching Snort events with Suricata events by using a flow_id that is just an xor or the addresses and ports. Has worked out well, and repeats a lot less than the memory address based flow id.

Actions #2

Updated by Victor Julien about 8 years ago

  • Status changed from New to Assigned
  • Assignee set to Jason Ish

We can also add in the sensor_id if it is set.

Jason do you want to take a stab at this?

Actions #3

Updated by Jason Ish about 8 years ago

Victor Julien wrote:

We can also add in the sensor_id if it is set.

Jason do you want to take a stab at this?

Would it not make sense to use the existing FlowGetKey to get an ID?

Actions #4

Updated by Eric Leblond about 8 years ago

Maybe we could also use the flow hash value that is computed by the card. Looks like this is something we can get in af_packet tpacketv3.

Actions #5

Updated by Jason Ish about 8 years ago

Eric Leblond wrote:

Maybe we could also use the flow hash value that is computed by the card. Looks like this is something we can get in af_packet tpacketv3.

Yes. I've been meaning to do that for the DAG support as it can generate a flow hash as well. But without a hardware provided hash I'm thinking we should use the result of the hashword, not the reduced value provided as the key.

Actions #6

Updated by Eric Leblond about 8 years ago

Fully agree with you. Lower level first then Suricata's own value.

Actions #7

Updated by Victor Julien about 8 years ago

Lets discuss the idea to use the capture method's flow id in it's own ticket, I opened #1741

Actions #8

Updated by Victor Julien about 8 years ago

Jason Ish wrote:

Victor Julien wrote:

We can also add in the sensor_id if it is set.

Jason do you want to take a stab at this?

Would it not make sense to use the existing FlowGetKey to get an ID?

Probably, yeah. One thing to look at is how currently ICMP error packets relate to TCP/UDP flows. I think they get the same flow as the one they have the error about, but not the same port, etc. They will in some way get the correct flow key obviously.

Actions #9

Updated by Jason Ish about 8 years ago

Victor Julien wrote:

Jason Ish wrote:

Victor Julien wrote:

We can also add in the sensor_id if it is set.

Jason do you want to take a stab at this?

Would it not make sense to use the existing FlowGetKey to get an ID?

Probably, yeah. One thing to look at is how currently ICMP error packets relate to TCP/UDP flows. I think they get the same flow as the one they have the error about, but not the same port, etc. They will in some way get the correct flow key obviously.

So I'm currently running with using the 32 bit hashword as a flow_id and results are good. When searching, I may get another flow in the results, but it does have the same 5 tuple. Unlike what I was seeing before where totally unrelated flows would show in the results, somethime only minutes apart.

I didn't consider the ICMP case, and my rather simple XOR approach would not have linked those types of flows. Will check this out.

Actions #10

Updated by Victor Julien about 8 years ago

  • Status changed from Assigned to Closed
  • Target version changed from 70 to 3.0.1RC1
Actions

Also available in: Atom PDF