Feature #1696
closedimprove logged flow_id
Added by Victor Julien almost 9 years ago. Updated over 8 years ago.
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.
Updated by Jason Ish almost 9 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.
Updated by Victor Julien over 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?
Updated by Jason Ish over 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?
Updated by Eric Leblond over 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.
Updated by Jason Ish over 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.
Updated by Eric Leblond over 8 years ago
Fully agree with you. Lower level first then Suricata's own value.
Updated by Victor Julien over 8 years ago
Lets discuss the idea to use the capture method's flow id in it's own ticket, I opened #1741
Updated by Victor Julien over 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.
Updated by Jason Ish over 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.
Updated by Victor Julien over 8 years ago
- Status changed from Assigned to Closed
- Target version changed from 70 to 3.0.1RC1