Does Argus support RST state in UDP flow?
John Gerth
gerth at graphics.stanford.edu
Mon Aug 26 16:49:38 EDT 2013
Because UDP is stateless there isn't necessisarily any indication because
there is formal definition of timeout.
If you have "icmpmap" in your filter, argus will show in the "flgs" field (see "man ra")
when ICMP errors are returned for UDP flows, e.g.
" I - ICMP events mapped to this flow
U - ICMP Unreachable event mapped to this flow
R - ICMP Redirect event mapped to this flow
T - ICMP Time Exceeded mapped to this flow"
You seem to already by using "U" and you can use the others.
Note that "Time Exceeded" in this context mean the TTL field went to 0 before the
destination was reached which is the one form of timeout you can detect.
On 8/26/2013 12:45 PM, Rahimeh Khodadadi wrote:
> Is it true:
> 1) I use -z in ra command for extracting time out flow and tcp state can be specified?
> 2) in udp I don't know what do I do???
>
> Please help
>
>
>
> On Mon, Aug 26, 2013 at 6:07 PM, Rahimeh Khodadadi <rahimeh.khodadadi at gmail.com <mailto:rahimeh.khodadadi at gmail.com>> wrote:
>
> 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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <http://whatever.the.timeout.is.in/>.
>>> seconds
>>>
>>>
>>>
>>> On Fri, Aug 23, 2013 at 7:32 PM, Carter Bullard <carter at qosient.com <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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,
>>> >>
>>> >>
>>> >
>>>
>>>
>>
>>
>
>
>
More information about the argus
mailing list