racount and src/dst byte counts
Carter Bullard
carter at qosient.com
Wed Sep 26 15:52:12 EDT 2001
Hey Desmond,
Hmmmm, you've got to think from the perspective of
a bi-directional flow. If you used this filter:
racount -n -r ra.out - dst host 142.55.aa.bb
and compared it to the output of
racount -n -r ra.out - src host 142.55.aa.bb
you would see the difference. (a filter of just
"host 142.55.aa.bb" matches the address whether its
the source or the destination, just like in tcpdump).
There are no argus records where 142.55.aa.bb is
the source. This makes sense 142.55.aa.bb is a server,
passively waiting for requests to come to it. It
shouldn't initiate anything (I'm assuming that this is
a pure server), so its not the source of the flow.
In bi-directional flow monitoring you can removing
these half-duplex concepts that cause all sorts of
problems. Argus is designed to resolve the ambiguity.
This allows you to know who is the real client and server,
what port is the real service port, is data flowing out
or is it flowing in, etc.....
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York 10022
carter at qosient.com
Phone +1 212 588-9133
Fax +1 212 588-9134
http://qosient.com
> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of
> Desmond Irvine
> Sent: Wednesday, September 26, 2001 2:40 PM
> To: carter at qosient.com
> Cc: argus-info at lists.andrew.cmu.edu
> Subject: Re: racount and src/dst byte counts
>
>
> Doing what you suggested I get a file with
> these contents:
>
> # ra -ncr ra.out
> 17 Sep 01 07:29:45 man version=2.0 probeid=3848370891
> STA
> 25 Sep 01 13:59:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5633 11257 337980 12140166 EST
> 25 Sep 01 14:00:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5443 10805 326580 11677486 EST
> 25 Sep 01 14:01:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5678 11352 340680 12239504 EST
> 25 Sep 01 14:02:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5484 10966 329040 11823396 EST
> 25 Sep 01 14:03:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5528 11052 331680 11916104 EST
> 25 Sep 01 14:04:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 4999 9996 299940 10775688 EST
> 25 Sep 01 14:05:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5312 10617 318720 11446150 EST
> 25 Sep 01 14:06:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5053 10106 303180 10894268 EST
> 25 Sep 01 14:07:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5266 10525 315960 11346974 EST
> 25 Sep 01 14:08:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5274 10530 316440 11355436 EST
> 25 Sep 01 14:09:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5320 10609 319200 11445718 EST
> 25 Sep 01 14:10:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 4852 9702 291120 10460804 EST
> 25 Sep 01 14:11:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5369 10716 322140 11555944 EST
> 25 Sep 01 14:12:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5585 11170 335100 12041260 EST
> 25 Sep 01 14:13:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 5752 11502 345120 12399156 EST
> 25 Sep 01 14:14:07 tcp 199.212.cc.dd.32862 ->
> 142.55.aa.bb.6891 1282 2555 76928 2752462 FIN
>
> Running racount on the two IP's I'm interested in
> results in:
>
> # racount -n -r ra.out - host 199.212.cc.dd
> racount records total_pkts src_pkts
> dst_pkts total_bytes src_bytes dst_bytes
> sum 16 245290 81830
> 163460 181180324 4909808 176270516
>
> # racount -n -r ra.out - host 142.55.aa.bb
> racount records total_pkts src_pkts
> dst_pkts total_bytes src_bytes dst_bytes
> sum 16 245290 81830
> 163460 181180324 4909808 176270516
>
> As you can see they're both the same output, shouldn't
> racount for one of the hosts (199.212.cc.dd?) produce
> this instead?
>
> racount records total_pkts src_pkts
> dst_pkts total_bytes src_bytes dst_bytes
> sum 16 245290 163460
> 81830 181180324 1762705164 4909808
>
> Carter Bullard wrote:
> >
> > Hey Desmond,
> > So the record is saying that 199.212.cc.dd initiated the TCP
> > connection, the "->" is saying that argus saw the SYN coming from
> > 199.212.cc.dd and EST is saying that argus is sending a
> status record,
> > the TCP is still open but here is an update on the progress of the
> > connection. You should get one of these every 60 seconds
> by default,
> > if the connection is still on going.
> >
> > 199.212.cc.dd is the client and 142.55.aa.bb is the server, and
> > 6891 is the service port.
> >
> > Now none of this will indicate what the load will be.
> > Does the service move data to the server or from the
> server? That's up
> > to the protocol and the service that is running.
> > >From your mail, I don't know what the situation is with
> > racount, as you didn't send its output. A way to test this
> situation
> > and possibly clear up any confusion you may have is to
> filter out just
> > the records that seem puzzling and write them to a
> temporary file. If
> > this particular TCP connection is a concern, capture all
> the records
> > that relate to this single TCP connection.
> >
> > ra -r file -w /tmp/ra.out tcp and src host 199.212.cc.dd \
> > and dst host 142.55.aa.bb and src port 32862 and dst port 6891
> >
> > This should result in a file of records that all relate to
> the single
> > TCP connection that spans a length of time.
> >
> > print out the contents to make sure it makes sense:
> > ra -ncr /tmp/ra.out
> >
> > If you've got them all, you should see most have an 'EST'
> at the end
> > and a 'FIN' or 'CLO' should be somewhere at the end, if you
> actually
> > captured all the records.
> >
> > Take this file and run ragator on it:
> > ragator -ncr /tmp/ra.out
> >
> > and compare ragator's output with racount's
> > racount -r /tmp/ra.out
> >
> > They should be the same. Doing this may help you to
> > see what is going on with the records.
> > If you want labels for the columns, run ra and ragator with
> the "-L 0"
> > option (print only one label at the beginning).
> >
> > I hope this helps!
> > Carter
> >
> >
> >
> > > -----Original Message-----
> > > From: Desmond Irvine [mailto:desmond.irvine at sheridanc.on.ca]
> > > Sent: Wednesday, September 26, 2001 11:46 AM
> > > To: carter at qosient.com
> > > Cc: argus-info at lists.andrew.cmu.edu
> > > Subject: Re: racount and src/dst byte counts
> > >
> > >
> > > How does racount decide which side (src or dst) to add
> the bytes to?
> > > The transaction I was looking at was from what I suspect is some
> > > sort of peer to peer file sharing tool. ra listed a bunch of
> > > connections of the form:
> > >
> > > 25 Sep 01 13:59:07 tcp 199.212.cc.dd.32862 ->
> > > 142.55.aa.bb.6891 EST
> > >
> > > >From this I would assume the flow was from the external
> > > machine to the
> > > local machine so I expected racount for the local machine to show
> > > the larger amount of bytes on the dst side and the
> external machine
> > > to show it on the src side. Regardless of what racount
> considered
> > > src and dst I expect only one machine to be considered the dst;
> > > racount showing both
> > > on the dst side doesn't seem to make sense to me.
> > >
>
> --
> Desmond Irvine Security Analyst, Information Technology
> Sheridan College Phone: 905-845-9430 x2035
> 1430 Trafalgar Road Fax: 905-815-4011
> Oakville, ON L6H 2L1 EMail: desmond.irvine at sheridanc.on.ca
>
More information about the argus
mailing list