Bug in direction - TCP SYN/ACK but no SYN

[John Gerth]

Since the direction indicator is a derived field, I think that perhaps '?' would
be more in line as a naked SYN/ACK is illogical with respect to the TCP protocol.
It might be a scan or it might be that the SYN packet wasn't seen by argus which
could be indicative of all sorts of other things (drops, asymmetric routes, etc.).

In general, I like that argus generally sticks to "just the facts" in reporting
what it has seen.

John Gerth      gerth at graphics.stanford.edu  Gates 378   (650) 725-3273

On 7/31/12 12:48 AM, Rafael Barbosa wrote:
> Hi Carter,
> 
> I haven't considered scans. However, I am not sure that using the field direction to display who is the source of the scan is that useful, specially
> when no other field in the transaction record classifies it as a scan (I might be wrong about this). 
> 
> My feeling is that, for TCP connections, you should mark the direction 'client -> server', and not 'scanner -> target'. In the case of my example, I
> think the most appropriate value would be 'scanner ?> target', as data only flows in this direction, and no client/server relation can be stablished.
> If you want to provide more information about the nature of the traffic (i.e., if it is a scan or not), it should be done in another transaction
> field, or maybe even another argus client.
> 
> Regards,
> Rafael Barbosa
> http://www.ewi.utwente.nl/~barbosarr/ <http://www.ewi.utwente.nl/%7Ebarbosarr/>
> 
> 
> 
> On Tue, Jul 31, 2012 at 2:11 AM, Carter Bullard <carter at qosient.com <mailto:carter at qosient.com>> wrote:
> 
>     Hey Rafael,
>     Not sure that there is a bug.  We changed the simple rule of SYN or SYN_ACK
>     specifying the direction, because single SYN_ACK packets are used quite frequently
>     in scanning strategies.  So, if there are no other packets, and just SYN_ACK, we
>     leave the direction to indicate the source of the scan, because, more than likely
>     its a scan job?
> 
>     Maybe we should put a ' ? ' in these cases? or we could put the arrow in the other
>     direction?  What do you think?
> 
>     Carter
> 
>     On Jul 27, 2012, at 9:19 AM, Rafael Barbosa <rrbarbosa at gmail.com <mailto:rrbarbosa at gmail.com>> wrote:
> 
>>     Hi,
>>
>>     I may have fund a bug in the argus with respect to the direction of TCP connections. When only the SYN-ACK message is received in TCPs 3-way
>>     handshake (i.e., the SYN is missing), argus is setting the direction from server to client, instead of client to server.
>>
>>     Small example:
>>     $> tcpdump -r anon.pcap 
>>     reading from file anon.pcap, link-type EN10MB (Ethernet)
>>     14:53:53.713258 IP 117.12.236.14.https > 117.69.107.235.1047: Flags [S.], seq 3044833418 <tel:3044833418>, ack 1678823480, win 5840, options
>>     [mss 1436,nop,nop,sackOK], length 0
>>     14:56:03.341851 IP 117.12.236.14.https > 117.69.107.235.1042: Flags [S.], seq 3194374727 <tel:3194374727>, ack 2254352525 <tel:2254352525>, win
>>     5840, options [mss 1436,nop,nop,sackOK], length 0
>>
>>     $> argus -r anon.pcap -w flows.argus
>>     $> ra -r flows.argus 
>>        13:53:53.713258  *           tcp      117.12.236.14.https     ->     117.69.107.235.1047          1         66   ACC
>>        13:56:03.341851  *           tcp      117.12.236.14.https     ->     117.69.107.235.1042          1         66   ACC
>>
>>     Using the latest stable version, argus-3.0.6.1.
>>
>>     Best regards,
>>     Rafael Barbosa
>>     http://www.ewi.utwente.nl/~barbosarr/ <http://www.ewi.utwente.nl/%7Ebarbosarr/>
>>
>>     <anon.pcap>
> 
>