Bug in direction?

[Carter Bullard]

Hey Rafael,
You make some good points.  I think we should use a ' ? ' to indicate that the TCP state based direction overides are not being used on this flow.  These are obvious TCP errors / spoofs, so better to have the TCP based direction not be reported. Now, if there were data or connection closing packets seen, then we would have a better idea that we're seeing a half-duplex connection, and the direction logic should kick in.  Of course  in this case there are also spoofs which make the direction erroneous, so not always clear what to do here.  Because the clients make the direction decision, maybe have a switch to turn the logic off ?
 
The important thing, IMO, is that we don't miss label the flow.
You start looking for flows where ' src net x.y.z.0/24 ' and because they flipped a bit in the packet, you don't see the activity. That drives me crazy.

So, we'll report ' ?> ' in this case of lone SYN_ACK packets, and leave the direction to represent wire direction.  I'll put it in the next release patch, and put it in the next dev release.

Carter

On Jul 31, 2012, at 3:48 AM, Rafael Barbosa <rrbarbosa at gmail.com> 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/
> 
> 
> 
> On Tue, Jul 31, 2012 at 2:11 AM, Carter Bullard <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> 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, 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, ack 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/
>> 
>> <anon.pcap>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120731/a2c29d52/attachment.html>