Full docs about ra output?
matthewbrown at gmail.com
Wed May 30 09:28:01 EDT 2012
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,
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
> 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
> 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
> 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
> 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
> On May 25, 2012, at 6:31 PM, Matt Brown wrote:
> Here is a pastebin of some of the records I am talking about:
> 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.
> 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.
>> 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).****
>>> ** **
>>> ** **
>>> *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?****
>>> ** **
>>> 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?"****
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the argus