Bug in direction?

[Rafael Barbosa]

Hi Carter,

I would not care much for a switch to turn the direction logic off. When I
don't care about a field, I simply do not print it (using the -s switch).

As usual, thanks for the fast feedback.

Regards,
Rafael Barbosa
http://www.ewi.utwente.nl/~barbosarr/



On Tue, Jul 31, 2012 at 2:50 PM, Carter Bullard <carter at qosient.com> wrote:

> 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/a169d767/attachment.html>