radump() shows only the first request [Re: Re: Question about payload
Stéphane Peters
stephane.peters at forem.be
Mon May 3 11:14:11 EDT 2010
Hello,
one thing to note, there is a slight difference between ra() and
radump() when several packets are aggregated in one flow.
ra() shows the first bytes of the flow, while radump() only dumps the
first request.
For example, let's take a DNS argus record.
The output shown by ra() is concatenated in one flow (some lines have
been split for readability):
> -bash-3.2$ ra -nr example.ra -s +suser:200 +duser:200
> StartTime Flgs Proto SrcAddr Sport Dir
> DstAddr Dport SrcPkts DstPkts TotBytes State \
> srcUdata dstUdata
> 30/04 15:01 e udp 1.0.2.1.49055 <->
> 100.0.1.1.53 3 2 640 CON \
> s[115]=V............\
> dnl-07.geo.kaspersky.com......\
> A...........\
> meteo.fr.be.msn.com..................\
> quiz.fr.be.msn.com..... \
> \
> d[128]=V............\
> dnl-07.geo.kaspersky.com..............\
> <.....).............\
> geons4.kaspersky-labs.!.............\
> geons1.M.............
The DNS requests done from the anonymized address 1.0.2.1 during this
DNS flow are unrelated as usual :
dnl-07.geo.kaspersky.com
meteo.fr.be.msn.com
quiz.fr.be.msn.com
radump() shows only the first transaction; once decoded, it displays 45
bytes for the source and 33 bytes for the destination:
> -bash-3.2$ radump -nr example.ra -s +suser:200 +duser:200
> 30/04 15:01 e udp 1.0.2.1.49055 <->
> 100.0.1.1.53 3 2 640 CON \
> s[45]="22176+ [_] A? dnl-07.geo.kaspersky.com. (115)" \
> d[33]="22176 1/4/4 A 195.222.17.41 (128)"
I don't know if it is desirable or possible to show the remaining
requests, ie meteo.fr.be.msn.com and quiz.fr.be.msn.com.
I have searched some clues reading the source of the 3.0.3.5 radump
files, here they are:
s[45] is the string length that radump writes to stdout for the
src payload (use wc() to check )
22176 matches the DNS Transaction ID ("print-domain.c" line 619 )
+ means recursion desired ("print-domain.c" line 620)
("nameser.h" line 224 )
1/4/4 means 1 answer record, 4 authority records, 4 additional
records ("print-domain.c" line 574);
specify -vv to enhance verbosity ("print-domain.c"
line 586)
(115) indicates the length of the buffer before conversion
("print-domain.c" line 706 )
[|domain] means something was truncated ("print-domain.c" line 710)
In fact, you could find nearly the same info launching tcpdump() on the
matching packets:
> -bash-3.2$ tcpdump -nr example.pcap | MyAnonymize
> reading from file example.pcap, link-type EN10MB (Ethernet)
> 15:01:00.823204 IP 1.0.2.1.49055 > 100.0.1.1.domain: 22176+ A?
> dnl-07.geo.kaspersky.com. (42)
> 15:01:00.851334 IP 100.0.1.1.domain > 1.0.2.1.49055: 22176 1/4/4 A
> 195.222.17.41 (221)
> 15:01:05.650905 IP 1.0.2.1.49055 > 100.0.1.1.domain: 2113+ AAAA?
> meteo.fr.be.msn.com. (37)
> 15:01:05.848604 IP 100.0.1.1.domain > 1.0.2.1.49055: 2113 1/0/0 CNAME
> weather.db2.cb3.glbdns.microsoft.com. (84)
> 15:01:06.698140 IP 1.0.2.1.49055 > 100.0.1.1.domain: 2772+ AAAA?
> quiz.fr.be.msn.com. (36)
> 15:01:06.741270 IP 100.0.1.1.domain > 1.0.2.1.49055: 2772 1/0/0 CNAME
> quiz.fr.be.msn.com.itm.asp.msn.com.nsa4c.net. (94)
The src buffer length was (115) in argus; in tcpdump you have: 42 + 37 +
36 = 115,
another proof that the three packets were concatenated in one flow.
The dst buffer was filled to the configured size of 128 bytes.
Let's try radump() with the newly discovered option -vv :
> -bash-3.2$ radump -nr /tmp/example.ra -s +suser:55 +duser:300 -vvv
> 30/04 15:01 e udp 1.0.2.1.49055 <->
> 100.0.1.1.53 3 2 640 CON \
> s[45]="22176+ [_] A? dnl-07.geo.kaspersky.com. (115)" \
> d[220]="22176 q: A? dnl-07.geo.kaspersky.com. \
> 1/4/4 dnl-07.geo.kaspersky.com. \
> A 195.222.17.41 \
> ns: geo.kaspersky.com. \
> NS geons4.kaspersky-labs.com., geo.kaspersky.com. \
> NS geons1.kaspersky-labs.com., geo.kaspersky.com. \
> NS[|domain]"
Carter Bullard a écrit :
> Hey Paul,
> s[51] means that this is the source user buffer and that its 51 bytes long. this
> is the payload of the packet sent from the entity that initiated the flow.
>
> d[135] means that this is the destination user buffer and its 135 bytes long.
> this is the payload of the packet sent from the entity that responded to the
> initiator.
>
> Using ra(), you are asking to print the raw buffer. the default is to print out
> as if its an ascii buffer, the '.'s are unprintable chars. For some protocols,
> like http, the buffers are just ascii strings. For others like DNS, they are a
> mix of binary and ascii.
>
> Definately looks like DNS traffic to me.
>
> radump() will attempt to parse out the user buffers and print out what it understands
> the buffer contents to be. Using radump(), you would get an output that looked
> like tcpdump's output for DNS.
>
> radump -r file -s +suser:128 +duser:135 - port domain
>
> the field lengths (:xxx) are whatever it takes to decode the buffer and print it out in ascii
> successfully.
>
> Carter
>
> On Apr 27, 2010, at 4:43 PM, Paul Schmehl wrote:
>
>
>> We're using argus to capture partial payloads. The output is quite a bit different from tcpdump, and there's some parts I don't understand. I'm hoping the experts here can enlighten me.
>>
>> What does s[51]= mean?
>>
>> What does d[135]= mean?
>>
>> I took the first one to mean the payload, but then the second seems unclear to me.
>>
>> Here's the packet I'm referring to:
>>
>> 27 Apr 10 18:21:39.137180 M udp 129.110.31.40.18677 <-> 92.241.190.252.domain CON s[51]=d............sandra.prichaonica.com.......)........ d[135]=d............sandra.prichaonica.com.................\................ns2...............ns1...V..........\....D..........\.....)........
>>
>> Clearly it's a DNS lookup, but I don't get what the s[51]= and d[135]= refer to.
>>
>> --
>> Paul Schmehl, Senior Infosec Analyst
>> As if it wasn't already obvious, my opinions
>> are my own and not those of my employer.
>> *******************************************
>> "It is as useless to argue with those who have
>> renounced the use of reason as to administer
>> medication to the dead." Thomas Jefferson
>>
>>
>>
>
> Carter Bullard
> CEO/President
> QoSient, LLC
> 150 E 57th Street Suite 12D
> New York, New York 10022
>
> +1 212 588-9133 Phone
> +1 212 588-9134 Fax
>
>
>
>
Regards,
--
Stephane.Peters at forem.be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20100503/4f2bf619/attachment.html>
More information about the argus
mailing list