Suricata

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.

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?

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.

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.

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

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

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.

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.