IBM Security QRadar

Expand all | Collapse all

Incorrect Protocol identification on QFlow and QNI interfaces.

  • 1.  Incorrect Protocol identification on QFlow and QNI interfaces.

    Posted 8 days ago
    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
    ------------------------------


  • 2.  RE: Incorrect Protocol identification on QFlow and QNI interfaces.

    Posted 7 days ago
    Edited by Dale Bowie 7 days ago
    QFlow and QNI are both definitely connection-aware. If we have not observed any traffic in either direction for a full minute, then it will be treated as a new connection. 

    Assuming the traffic is originally being observed by QNI, please ensure the "Enable Asymmetric Flows" is not turned on at the receiving QFlow IPFIX flow source.

    ------------------------------
    Dale Bowie
    QRadar Network Insights and Incident Forensics Product Owner
    IBM
    ------------------------------



  • 3.  RE: Incorrect Protocol identification on QFlow and QNI interfaces.

    Posted 2 days ago
    Thanks Dale I've ensured "Enable Asymmetric Flows" is not ticked on both our interfaces. 


    ------------------------------
    Seb Dooris
    ------------------------------



  • 4.  RE: Incorrect Protocol identification on QFlow and QNI interfaces.

    Posted 7 days ago
    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
    ------------------------------



  • 5.  RE: Incorrect Protocol identification on QFlow and QNI interfaces.

    Posted 2 days ago
    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?
    Flow traffic


    ------------------------------
    Seb Dooris
    ------------------------------



  • 6.  RE: Incorrect Protocol identification on QFlow and QNI interfaces.

    Posted 2 days ago
    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
    ------------------------------



  • 7.  RE: Incorrect Protocol identification on QFlow and QNI interfaces.

    Posted 2 days ago

    A couple more thoughts as to why the flows aren't being combined:

    1. Can you confirm that the "vendor flow ID" property is the same for the two flows? What about the "flow ID" property? 
    2. Are you using a QNI hardware appliance or a software install as a VM or with Intel cards? If it is the latter, are you connecting to multiple network interfaces on this host? 

    The direction issue should mostly resolve itself once the flows are stitched back together into a single flow. The "Use Common Destination Port" looks to be turned off, so turn that on and it should at least orient all these connections so that port 80 is in the destination port column. This setting can be changed via System and License Management -> select your QFlow host (e.g. flow processor, console) -> deployment actions -> edit host -> component management. A deploy would be required after this point.

    ------------------------------
    Dale Bowie
    QRadar Network Insights and Incident Forensics Product Owner
    IBM
    ------------------------------