As Dale mentioned (Hi Dale), the flow could be received asynchronously. I have seen Cisco switch fabrics break flows as well, sometimes sending the same packet several times. There are a lot of variables involved of course. You could also increase the size qflow captures, system and license management, deployment options, edit host, removing duplicates should be on of course I don't know if that will solve the issue or not. Half closed sessions are a pain to deal with.
Working with IPS\IDS for years, we see firewalls that lose track of sessions and a reply that is part of an established session is seen as a new session. I've never seen a capture with that happening, but I'll bet there was a reset from one end or the other that would confuse the recombination of the flow. Snort has the stream processor for just such issues. Your example was TCP, but it can happen with UDP as well.
If you want me to take a look shoot me a note we can do a webex or teams or something. I'm not sure I can help much, you may be able to put some false positive rule clauses in (improper flags, etc).
------------------------------
Frank Eargle
------------------------------
Original Message:
Sent: Tue September 21, 2021 02:07 PM
From: Seb Dooris
Subject: Incorrect Protocol identification on QFlow and QNI interfaces.
Thanks Frank, So with your previous experience you would expect QRadar to be identifying traffic like this port 80 example. This is creating a lot of false positives. Any idea what could be wrong?
------------------------------
Seb Dooris
Original Message:
Sent: Thu September 16, 2021 07:01 AM
From: Frank Eargle
Subject: Incorrect Protocol identification on QFlow and QNI interfaces.
As I have explained to junior analysts, QRadar decodes the protocol, just like next gen firewalls. It doesn't matter what the port is, it is looking inside the stream. If however you just have netflow or sflow, I have no idea. But QFlow or QNI is usually correct, if you can grab a pcap it will prove it out.
------------------------------
Frank Eargle
Original Message:
Sent: Wed September 15, 2021 05:54 AM
From: Seb Dooris
Subject: Incorrect Protocol identification on QFlow and QNI interfaces.
Hi All,
Having an issue where QRadar 7.4.2 is failing to identify application traffic within TCP conversations which is causing a lot of unwanted offences.
Given the following TCP conversation in network view.
192.168.0.1:48417 to 192.168.1.1:22 QFlow and QNI identify this as "RemoteAccess.SSH"
192.168.1.1:22 to 192.168.0.1:48417 QFlow and QNI identify this as "Other"
Same happens with other protocols like http and https, sure many more.
192.168.0.1:53421 to 192.168.1.1:80 QFlow and QNI identify this as "Web.Web.Misc"
192.168.1.1:80 to 192.168.0.1:53421 QFlow and QNI identify this as "Other"
Is this right QRadar is not conversation aware and can only identify traffic in one direction?
Thanks
------------------------------
Seb Dooris
------------------------------