Discrepancies between TCPFlow v1.5.1 and v1.6.1 number of flows. Violations occurring with 1.6.1 but not with 1.5.1 as well.

[kenn0]

I just recently upgraded from TCPFlow 1.5.1 to 1.6.1. After running each version of tcpflow on the same pcap file, I'm getting different results. I'm trying to figure out why the discrepancies. For example when I run v1.6.1 I get some TCP PROTOCOL VIOLATION: SYN with data! messages that I don't get with 1.5.1. Also, the number of flows are different for each version. The pcap includes SYN scan data. I'm wondering if this is causing the differences. Can someone help me understand why these differences are occurring? Thank you!

The attached pdf file includes the issues experienced with screenshots. The zip file is the pcap I'm running each version of tcpflow against.

TCPFlow version discrepancies.pdf
intrusion.zip

[simsong]

Thanks for the update. Which is the correct result? The version that you were getting with 1.5.1 or with 1.6.1 ?

[kenn0]

I believe 1.5.1 is correct and the SYN scans are causing erroneous flows for 1.6.1. Some of the additional flows that 1.6.1 list contain no data which makes since for a SYN scan.

[simsong]

Have we been able to figure out what caused the error, and if that code was put in place for other reasons?
It may be that we were missing data sometimes and that all we really need to do is to suppress the files created by the SYN scan.

[simsong]

Your writeup is useful but I want to know three things that you do not make clear:
1 - Does v1.5.1 find any flows that v1.6.1 does not find?
2 - Are there any flows that are different in v1.5.1 and in v1.6.1?
3 - Are the protocol violations not in fact protocol violations, or would you rather not be notified about this?

[kenn0]

Sorry, my programming skills are rusty. I haven't looked at the source code. I do think the issue relates to indicating a flow exist when the 3 way handshake hasn't completed. From the pcap I am using, looks like flows are showing up when the attacker scans a closed port (SYN, ACK-RST) although the number of flows are inconsistent. Note the two images attached. Flow to port 2348 is listed 3 times but in the Wireshark image, that flow looks like the other ACK-RST flows. I don't know why it shows up 3 times and the others don't.

No problem.
1 - v1.6.1 shows more flows than v1.5.1
2 - In v1.6.1 TCP connections to closed ports (SYN, ACK-RST) show up as flows. I was expecting flows to consist of a completed 3 way handshake.
3 - In this case I'm just interested in legitimate flows and not protocol violations. Maybe there could be a switch to either turn on protocol violation notification or to turn it off. Also, right now I don't see how the notice of a protocol violation points me to the flow with the violation (I could be missing something here).
Thank you for the inquiries!! Really appreciate it!

[simsong]

I'm excited that you are engaged here. I'm happy to work with you to improve you C++ skills if you wish.
I concur that the protocol violation error should include more info and that there should be a switch to enable or disable reports of protocol violations. Is that what you would like?