racount and src/dst byte counts
Desmond Irvine
desmond.irvine at sheridanc.on.ca
Thu Sep 27 08:52:20 EDT 2001
I see how I can check for the source and destination host of the flow in
a number of ways, what I was hoping was that I could get the bytes
transferred and the direction all in one step from the racount command.
I'm trying to check the bandwidth usage by our residence students who
have a different upload and download bandwidth limits. I guess since
argus isn't monitoring packets, I can really only use it to look at
total bytes consumed easily. Argus isn't the proper tool if I want a
src and dst byte count as I really want it on the packet level. If
someone were using FTP, for instance, they could ftp from an external
host to a local one and either GET or PUT a file, but Argus would see
either transaction as the same since the flow would be initiated from
the external machine - right?
One other question, in order to run ramon against multiple argus files
(each representing different time intervals) and get the top users for
the entire period that all the files cover do I need to first create one
file that contains all the files contents using ra/ragator (which would
be better - ragator)? Running ramon against all the files using a wild
card seems to bring up the top ip's by looking at each individual files
top ip's and then determining which are the top results amongst all of
those. Thus an individual ip might show up multiple times where I
really only want to see one entry which is the cumulative sum of
activity for an ip over the entire time frame.
Sorry for such basic concept questions, but I'm really quite a neophyte
with argus.
Thanks, Desmond.
Carter Bullard wrote:
>
> 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
> >
--
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