[ARGUS] Argus output flows with swapped src/dst IPs and src/dst ports

[carter at qosient.com]

Hey Hang,
Bi-directional flow level semantics are different from packet level semantics, especially with regard to src and dst.  So who is the src and dst in a flow where they are both transmitting and receiving ??    Is it the first to send ??  maybe not when you have very long lived flows that are idle for long periods of time, or in asymmetric routing where you don't see the first packet, or in this case where you anonymize out the time to where multiple packets have the same uSec timestamps and you can’t tell which packet was first.  For some people, the Src and Dst are relative assignements base on geo or net-spatial criteria.  They want the local host be the source when the 2 parties are not in the same local network.   This is legitimate for some ACL tests and useful for visualization and analytics where they want the src / local address on the left (some like the source on the left and dest on the right in tables).

Argus uses a lot of conditions to decide who is the source, or better the initiator of the flow.  As a bi-directional flow sensor, Argus has to deal with matching a packet in either direction to the same flow, so who gets to be the source and who gets to the destination ???   When it's TCP, argus and the clients use the TCP state to determine who initiated the flow.  Who sent the SYN, who sent the SYN/ACK … for some protocols, like DNS where the transaction has client server specific semantics, its who sent the request, who sent the response … should that indicate who the client and server are ?????   For some, its more important to know that the protocol response came from 1.2.3.4, regardless of who transmitted first, or what port is being used.  And of course from a cyber security perspective,  most covert channels and attempts to fool the sensor use well know ports as the source port of a transaction.  All of this is fair game when you’re trying to build a generic sensor ...

OK with that said, what does it mean.  When I run your command, I get …

set:Desktop carter$ argus -r *.pcap -w - | ra
       StartTime   Flgs Proto        SrcAddr Sport. Dir       DstAddr Dport SrcPkts DstPkts SrcBytes DstBytes State 
07/04.20:28:33.1  e       tcp  82.26.219.252.4104   <?   175.16.10.94.443         0       2        0      598   CON

The key to this is the ‘ ? ‘ in the dir(ection) field.  This is a TCP connection, and ‘ ? ‘ indicates that there wasn’t a SYN or SYN/ACK seen to reveal who requested the TCP.  The clients have the option to figure it out (guess).  My clients are configured to put the service port as the destination when the clients get to guess.

In my ~/.rarc 
  RA_PORT_DIRECTION="services,wellknown"

So my clients put the “ 443 “ port on the right, with the arrow going to the left, because there is no additional information to nail down who initiated the connection.  DstPkts become > zero, as the destination is transmitting to the source.

This is all important for argus analytics.  Here is the same flow record, but called without the use of the rarc configuration file … (-X option)

set:Desktop carter$ argus -r *.pcap -w - | ra -X
       StartTime   Flgs Proto        SrcAddr Sport. Dir       DstAddr Dport SrcPkts DstPkts SrcBytes DstBytes State 
07/04.20:28:33.1  e       tcp   175.16.10.94.443    ?> 82.26.219.252.4104        2       0      598        0   CON

Regardless of the configuration, the clients are free to guess only when there is no SYN or SYN/ACK.  You can force the assignments, but you have to tell the clients to force it.  If you cluster a lot of records together, they preserve all the TCP flags such that if this direction-less flow is merged with the previous flow record that has the SYN or SYN/ACK in it, it will figure out what the ‘ real ‘ direction should be.

Hope this helps !!!

Carter
       <http://qosient.com/>    	 	
Carter Bullard   <mailto:carter at qosient.com>•  Chairman / Founder / CTO
150 E 57th Street, Suite 12D
New York, New York 10022-2795
Phone +1.212.588.9133 • Mobile +1.917.497.9494

 

> On Nov 29, 2019, at 2:42 PM, Hang Guo <hangguo at usc.edu> wrote:
> 
> Hi,
> 
> I found argus (Version 3.0.8.2), when fed in some pcaps with tcp packets, could output flows with swapped  src/dst IPs and src/dst ports. I attach an example 2-packet pcap (packet IPs and MAC anonymized, payload cropped) that could trigger this behavior.
> 
> Specifically, when I do  
> argus -r test_anon.pcap -w - | ra -c "," -r - -s stime ltime saddr daddr sport dport proto spkts -nn
>  
> The output is 
> StartTime,LastTime,SrcAddr,DstAddr,Sport,Dport,Proto,SrcPkts
> 1562286513.155328,1562286513.155328,82.26.219.252,175.16.10.94,4104,443,6,0
> 1575055898.822475,1575055897.816590,0,32,0,1,man,0
> 
> While test_anon.pcap shows two tcp packets from 175.16.10.94 to  82.26.219.25, argus output shows a tcp flow from 82.26.219.252 to 175.16.10.94 with 0 packets (since SrcPkt=0). And the src and dst ports in argus output are also swapped. I wonder what goes wrong in this case?
> 
> Thanks and happy thanksgiving! 
> -Hang 
> 
>  
> <test_anon.pcap>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20191130/40dd4c6d/attachment.html>