Does Argus support RST state in UDP flow?

Mon Aug 26 09:37:56 EDT 2013

Hi Carter,

If I want to show RST udp flow by state and flgs, usually we use INT state
and eU flgs. But if  I want to show udp time out by state and flgs what
should I do without command?
And is there possible to show TCP time out in argus, it means (1.Tcp syn
sent, but time out) and (2.Tcp syn sent, but got ICMP unreachable) by state
and flgs?

Thanks in advance

On Fri, Aug 23, 2013 at 11:30 PM, Carter Bullard <carter at qosient.com> wrote:

> No, argus does NOT process the application data.
>
> You will use radump() to parse out the application data to
> understand if there is an error.
>
> Carter
>
> On Aug 23, 2013, at 2:24 PM, Rahimeh Khodadadi <
> rahimeh.khodadadi at gmail.com> wrote:
>
> Thanks Carter,
> Just a another question, for a DNS flow (port 53) which is DNS server
> responds errors to a queried domain also use the command?
>
>
>    ra -r argus.file - udp and icmpmap
>
>
>
> On Fri, Aug 23, 2013 at 9:25 PM, Carter Bullard <carter at qosient.com>wrote:
>
>> No, there is no such thing as a UDP flow that is reset.
>> This does not exist.  You should use this command instead:
>>
>>    ra -r argus.file - udp and dst pkts 0
>>
>> This will show you udp flows that do not get a response.
>> This will also show you udp flows that have ICMP packets as response.
>>
>>    ra -r argus.file - udp and icmpmap
>>
>> Your argus must see both sides of the flow for this technique to be
>> useful.
>>
>> Carter
>>
>> On Aug 23, 2013, at 11:17 AM, Rahimeh Khodadadi <
>> rahimeh.khodadadi at gmail.com> wrote:
>>
>> Hi Carter,
>>
>> This means, if I run command below, it is correct and work fine?
>> it gives me udp flow which are reset?
>>
>>  ra -r argus.file - udp / src pkts 1/ dst pkts 1/ dur gt
>> whatever.the.timeout.is.in.
>> seconds
>>
>>
>>
>> On Fri, Aug 23, 2013 at 7:32 PM, Carter Bullard <carter at qosient.com>wrote:
>>
>>> Hey Sebas,
>>> UDP timed out is tested in two ways.  The first is a simple UDP
>>> transactional
>>> failure...i.e. no response.  The second is that the duration of the UDP
>>> transaction is greater than the timeout.
>>>
>>>    ra -r argus.file - udp and dst pkts 0
>>>    ra -r argus.file - udp and src pkts 1 and dst pkts 1 and dur gt
>>> whatever.the.timeout.is.in.seconds
>>>
>>> The lack of a response is really an availability failure, which can be
>>> caused by a reachability, connectivity or availability fault.
>>> Reachability
>>> failure is packet didn't get to the dst, connectivity failure is a
>>> two-way
>>> reachability failure, packet didn't get there or didn't make it back, and
>>> an availability failure is both of these, or a condition where the
>>> application isn't available, or isn't responsive.  argus can
>>> discriminate between
>>> all of these conditions.
>>>
>>> You can test both timeout conditions at the same time.
>>>
>>>    ra -r argus.file - udp and (dst pkts 0 or \
>>>       ( src pkts 1 and dst pkts 1 and dur gt
>>> whatever.the.timeout.is.in.seconds))
>>>
>>> (remember you may have to escape the ' ( ' and ' ) ' to get it to work
>>> from your shell:
>>>
>>>    ra -r argus.file udp and \( dst pkts....  \)
>>>
>>> Where a transaction with no response generates a duration of zero, but
>>> this
>>> is not a reliable test, even when you're argus is configured to produce
>>> nanosecond
>>> timestamps.  Many situations can have the request and response marked
>>> with the same timestamp, so don't use this test " dur 0 ".
>>>
>>> For many UDP protocols, argus uses a 6-tuple flow model, where it
>>> adds the transaction sequence number to the flow key.  The most important
>>> example is DNS.  We for a flow for all packets whose 5-tuple flow
>>> attributes
>>> match, as well as the DNS sequence number.
>>>
>>> Remember argus is a proof of concept project implemented with examples,
>>> so if you're particular UDP transactional protocol has a sequence number,
>>> like SIP for example, and we'd like to create a 6-tuple flow model for
>>> it,
>>> just ask, and we can generally do that.
>>>
>>> Carter
>>>
>>>
>>> On Aug 23, 2013, at 10:39 AM, el draco <eldraco at gmail.com> wrote:
>>>
>>> > Hi Rahimeh.
>>> >
>>> > Ok, so:
>>> > UDP with reset, could be find as I tell you in the last email.
>>> > UDP timeout (filtered port) is difficult, because UDP does not enforce
>>> > you to answer. So, you can not tell the difference between filtered
>>> > port (timeout) and open port (timeout). That's why nmap says
>>> > open|filtered when you scaned a udp port like that. You can be sure
>>> > that the port is open if you see some packets back. But that is not
>>> > always the case. (nmap tries to talk the exact protocol to enforce an
>>> > answer)
>>> > UDP that responds erros. This depends on what you consider an error
>>> > and is not something you can expect to be on a flow. Argus may help
>>> > here if you
>>> > store the payload of the connection. But i think it will be a manual
>>> job.
>>> >
>>> > I'm not sure how argus creates UDP flows, maybe Carter can tell you or
>>> > it is in the code.
>>> > I think it is getting the 5-tupple
>>> > srchost-srcport-dsthost-dstport-proto . But I'm not developing it.
>>> >
>>> > cheers
>>> > sebas
>>> >
>>> > On Fri, Aug 23, 2013 at 11:53 AM, Rahimeh Khodadadi
>>> > <rahimeh.khodadadi at gmail.com> wrote:
>>> >> Hi Sebas,
>>> >>
>>> >> Thanks for your helps and quick reply.
>>> >> I have a pcap file that want to extract  UDP connection which are
>>> reset
>>> >> (like : UDP sent, but got ICMP unreachables or UDP sent, but timed
>>> out or a
>>> >> DNS server responds errors to a queried domain)
>>> >>
>>> >> But  as far as I see argus couldn't extract such an information, is
>>> not it?
>>> >>
>>> >> another question is how argus make a flow from UDP packets?
>>> >>
>>> >> Thanks,
>>> >> Rahimeh
>>> >>
>>> >>
>>> >> On Fri, Aug 23, 2013 at 1:29 PM, el draco <eldraco at gmail.com> wrote:
>>> >>>
>>> >>> Hi Rahimeh.
>>> >>> What do you mean with rest? do you mean reset?
>>> >>> UDP is stateless and transaction-oriented so there are no flag bits
>>> >>> like the reset bit in TCP.
>>> >>>
>>> >>> When you send a UDP packet to close port, you will get an ICMP
>>> >>> port-unreacheable packet back.
>>> >>> In argus (unidirectional and bidirectional), that connection is seen
>>> >>> like this if you use ra:
>>> >>>
>>> >>> ra -s +flgs -n -Z b -S localhost - "host x.x.x.x"
>>> >>>
>>> >>> StartTime       Dur     Proto   SrcAddr Sport   Dir     DstAddr Dport
>>> >>> State   sTos    dTos    TotPkts TotBytes        Flgs
>>> >>> 2013/08/23 10:55:01.759273    0.000158      udp   y.y.y.y 1528  ->
>>> >>> x.x.x.x 234  INT  0 1 42 eU
>>> >>> 2013/08/23 10:55:01.759431    2.053794   icmp x.x.x.x  0x0303  ->
>>> >>> y.y.y.y 0xea00  URP  192 3 210 e
>>> >>>
>>> >>> The state for argus is INT or initial. See man ra
>>> >>> The icmp packet state is URP or Unreachable port.
>>> >>>
>>> >>> However, argus gives you extra information if you print the 'flgs'
>>> >>> field. This field is 'eU' for the UDP flow, meaning :
>>> >>> e       -  Ethernet encapsulated flow
>>> >>> U      -  ICMP Unreachable event mapped to this flow
>>> >>>
>>> >>> The problem is that if you have multiple connections like this I do
>>> no
>>> >>> t know how to find which UDP flow is related to which ICMP port.
>>> >>>
>>> >>> Hope this helps.
>>> >>> sebas
>>> >>>
>>> >>>
>>> >>> On Fri, Aug 23, 2013 at 8:37 AM, Rahimeh Khodadadi
>>> >>> <rahimeh.khodadadi at gmail.com> wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> I want to know which udp flows are rest, but I couldn't see them in
>>> >>>> argus
>>> >>>> file,
>>> >>>> Is it possible to see RST udp flow in argus?
>>> >>>>
>>> >>>>
>>> >>>> Thanks,
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130826/d3d201fc/attachment.html>