Full docs about ra output?

Wed May 30 10:54:46 EDT 2012

Hey Matt,
Check out the routine ArgusPrintDir() in ./common/argus_util.c

Carter

On May 30, 2012, at 9:28 AM, Matt Brown wrote:

> Thanks for the detailed reply.  I suppose to thoroughly understand, reviewing the source would be best.  Where in the source is the code to determine the dir?
> 
> Thanks very much,
> 
> Matt
> 
> On May 29, 2012 12:45 PM, "Carter Bullard" <carter at qosient.com> wrote:
> Hey Matt,
> OK, …, so  ,…., the direction indicator is  the result of a pretty simple algorithm that tries
> to discern who started (initiated) the flow.  This is important, as the destination port,
> from the perspective of the initiator, is almost always the service port, and understanding
> the client / service can be pretty important .
> 
> For connectionless traffic, like UDP traffic, we can't " know " who really initiated a
> request / response volley, but you can attempt to use the protocol and the port numbers
> to surmise who is the requestor, and who is the responder.  Argus doesn't do any of
> this guessing, it tries to be as simple as possible, providing the hints in its output, so
> that the client programs can make the decision.  This may seem more complicated
> that it should need to be, but with so many forged packets trying to beat stateful firewalls,
> its important to try to determine these relationships.
> 
> What argus will do, is guarantee that the flow state, as perceived on the wire, is well
> represented.  So argus will always report flows where the source and destination
> identifiers (IP addrs for example) are derived from the first packet observed.  Argus
> will also provide as many hints as it can, to help client programs change that
> assignment, if needed, to report the state of a flow.
> 
> This is important, when trying to deal with flows with long idle times, asymmetric routing
> situations, failure conditions, spurious packets and forged packets used for scanning.
> 
> The simple status information that netflow like flow models provide is not sufficient for
> understanding the initiator of most TCP connections (masking the TCP flags together,
> loses critical information), so argus tries to provide more information, to solve this
> problem, and the direction indicator is the result of processing this additional information.
> 
> So, the algorithm is pretty simple.  If we're working with TCP, and argus saw the SYN
> or SYN_ACK flag combinations, then we've got a good idea of who initiated
> the connection, and the direction indicator uses a " - " as the central character.  In this
> case, the arrow will point from initiator to responder / target.  Other algorithms may
> flip the addresses, but the error should always point from initiator (source) to target (dest).
> 
> If we haven't met these conditions, you get a " ? ", and the arrow will indicate the direction
> of data.  So ?> and <? are uni-directional flows, without connection setup.  <?> are
> bidirectional flows without connection setup.
> 
> You can do this test yourself with this filter:
> 
>    tcp and (syn or synack)
> 
> 
> For connectionless traffic, UDP for example.  There will not ever be a " ? ", and the arrow
> is there simply to indicate direction of traffic. " -> " and " <- " are unidirectional flows, and
> " <-> " are bi-directional flows.
> 
> You can do this with filters as well:
>    
>    not tcp and src pkts gt 0 and dst pkts 0
>    not tcp and dst pkts gt 0 and src pkts 0
>    not tcp and dst pkts gt 0 and src pkts gt 0
> 
> Just as examples of course.
> 
> Hope this is useful !!!!!!  Don't hesitate to ask, comment, criticize whatever,
> 
> Carter
> 
> 
> 
> On May 25, 2012, at 6:31 PM, Matt Brown wrote:
> 
>> Here is a pastebin of some of the records I am talking about:
>> http://pastebin.com/c12KvNjk
>> 
>> I'm guessing, from your reply, that <? and ?> mean "I tried, some things tell me that it goes in this direction, but I'm not 52-100% sure?"  Or is that 52 a 99?
>> 
>> This is skype traffic for sure.
>> 
>> Thanks for your assistance, Mark.
>> 
>> 
>> -Matt 
>> 
>> 
>> On Thu, May 24, 2012 at 10:33 PM, Matt Brown <matthewbrown at gmail.com> wrote:
>> Thanks Mark.
>> 
>> I'll grab some stuff out of the DB I populated and reply to this thread.
>> 
>> I'm really focusing on creating a variety of macro views and trying to figure out how to consider 'dir' in those derived views.
>> 
>> I'm currently focused on the easy stuff as pivot points, source and destination: bytes, packet count, address and port. But I am interested in leverage other parts of the DSR as well, if they are useful. (am I using DSR right?)
>> 
>> I'll spend more time reviewing other threads as well as the NSMwiki, but any further examples of how people create macro views of the data, versus considering solely 'dir,' would be appreciated.
>> 
>> 
>> Thanks,
>> 
>> Matt
>> 
>> 
>> 
>> On Thu, May 24, 2012 at 9:39 PM, Mark Poepping <poepping at cmu.edu> wrote:
>> Taking a stab (trying to relieve Carter of some of the burden)…
>> 
>>  
>> 
>> For directionality specifically, if it’s a well-defined protocol and argus saw most (if not all) of the packets from the beginning, it will know the direction, but there are many examples of ordinary and hybrid protocols where you won’t necessarily know the direction in all cases: peer-to-peer, ICMP, UDP can all make it hard to understand direction – or direction might not have meaning.  Packet loss (esp. packet sampling) often causes this output, and multi-path routing will ‘look like’ packet loss too, depending on where you’re watching and how your paths are advertised or have evolved over time.
>> 
>>  
>> 
>> On a simple, lightly loaded network (my house), long-running argus probes generally get the directionality right.
>> 
>> At my work, it’s not so simple so it helps to interact with questions that we have for the data and considerations of probe location and efficiency given the use cases.
>> 
>>  
>> 
>> Hope that helps some, it takes a little getting used to.  If you have specific questions or confusions, it does help to snap a packet capture that displays your confusion – that way others may be work with them directly and try to help you (with no explicit promises, of course).
>> 
>> Mark.
>> 
>>  
>> 
>>  
>> 
>> From: argus-info-bounces+poepping=cmu.edu at lists.andrew.cmu.edu [mailto:argus-info-bounces+poepping=cmu.edu at lists.andrew.cmu.edu] On Behalf Of Matt Brown
>> Sent: Thursday, May 24, 2012 9:00 PM
>> To: argus-info at lists.andrew.cmu.edu
>> Subject: [ARGUS] Full docs about ra output?
>> 
>>  
>> 
>> Hello,
>> 
>> I see the man page for ra, but it seems lacking for some DSR value output.  For instance, there are somethings that aren't implicit, but appear like they should/were intended to be.
>> 
>> Specifically, I see this with 'dir's possible values.
>> 
>> The cases if confusion are <? And ?>.  How can argus "not" know the direction of the transaction "sort of?"
>> 
>> Thanks,
>> 
>> Matt
>> 
>> 
>> 
> 

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