Does Argus support RST state in UDP flow?

[Carter Bullard]

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 --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7322 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20130823/edecbe27/attachment.bin>